Forem: Utkarsh Rastogi

How to Build an AI Customer Support System with AWS Bedrock Guardrails (Complete Tutorial + Free Code)

Utkarsh Rastogi — Sat, 10 Jan 2026 12:19:28 +0000

Quick Summary: Built an AI system that sorts 500+ daily support tickets automatically. Went from 4 hours daily sorting to 10 minutes reviewing. 95% accuracy, $9/month cost, protects customer privacy. Full code included.

The Problem

Monday morning: 347 unread support tickets. Urgent payment issues buried in password reset requests. Spending 3+ hours daily just figuring out priorities.

Solution: AI that reads tickets, categorizes them, and protects sensitive data automatically.

What I Built

Simple flow:

Customer sends ticket → API Gateway
AWS Bedrock Guardrails scan for sensitive data
Claude AI categorizes: Technical, Billing, Account, Feature, General
Results stored → Team gets organized, safe tickets

Processing time: Under 3 seconds

Accuracy: 95% correct

Cost: $9/month for 1,000 tickets

The Privacy Magic

Before Guardrails:
"Hi, I'm John Smith, email john@company.com, phone (555) 123-4567, credit card 4532-1234-5678-9012 was charged twice!"

After Guardrails:
"Hi, I'm [NAME_REDACTED], email [EMAIL_REDACTED], phone [PHONE_REDACTED], credit card [BLOCKED] was charged twice!"

What gets protected:

✅ Emails, names, phones → Redacted but readable
🚫 Credit cards, SSNs → Completely blocked
🚫 Inappropriate content → Blocked with professional response

Real Results

Before AI:

4 hours daily sorting tickets
Missing urgent issues
Privacy incidents waiting to happen

After AI:

10 minutes daily reviewing classifications
Zero privacy incidents
96% time reduction
$990/month saved vs $9/month cost = 10,900% ROI

Quick Deploy

cd infrastructure
./deploy.sh dev us-east-1 your-email@example.com

That's it. One command sets up everything:

AI classification system
Privacy protection
Database
Monitoring dashboard
Cost alerts

Test It Instantly

Import the included Postman collection with 12 test scenarios:

Basic Tests:

Account issues → Categorized as "ACCOUNT", HIGH priority
Billing problems → "BILLING", URGENT
Technical bugs → "TECHNICAL", priority based on impact

Privacy Tests:

Email in ticket → john@company.com becomes [EMAIL_REDACTED]
Credit card → Request completely blocked with error
Multiple PII → All sensitive data removed automatically

Safety Tests:

Threatening language → Blocked, team never sees it
Inappropriate content → Professional error response

Postman Test Results (Screenshots)

Here's what the actual API responses look like when testing different scenarios:

Successful Classification:

PII Protection in Action:

Content Safety Blocking:

Multiple PII Detection:

Credit Card Blocking:

Upload your own screenshots here to show your results! The Postman collection makes it easy to test all scenarios.

What Surprised Me

The accuracy: 95% correct from day one. No training needed.

The privacy protection: Catches stuff I never thought about (VIN numbers, passport numbers, AWS keys).

The speed: Under 3 seconds including all privacy scanning.

The cost: $9/month. I spend more on coffee.

Team reaction: Support team became the system's biggest advocates. Removing tedious work made them love their jobs again.

Common Questions

"What if AI gets it wrong?"

Happens 5% of the time, usually just slightly off. Still better than my tired-at-11PM error rate.

"Is it secure?"

More secure than manual processing. Auto-strips sensitive data, runs in your AWS account, full audit logs.

"What about costs at scale?"

Linear: 10,000 tickets = ~$90/month. Way cheaper than hiring people to sort manually.

The Bottom Line

Six months ago: Drowning in tickets, stressed team, missing urgent issues.

Today: 10 minutes daily review, happy team, zero privacy incidents.

The real win: Getting your life back. When you're not stressed about missing urgent issues, you can focus on actually helping customers.

Get The Code

GitHub: AI Support Ticket Classifier

What you get:

Complete AWS infrastructure code
One-command deployment
12 Postman test scenarios
Real examples you can run immediately

Built with help from:

🤖 Kiro AI - Helped with AWS integration patterns
🔗 MCP servers - Generated architecture diagrams
📮 Postman - Comprehensive testing suite

📊 Guardrail Monitoring

CloudWatch Dashboard: Real-time metrics show intervention count and Total hit count.

Key metrics: Intervention count and total api count.

Built something cool with this? Share your story! The code is open source because every startup should have access to tools like this.

Day 4: Structured Outputs with LangChain Output Parsers

Utkarsh Rastogi — Sun, 21 Dec 2025 07:23:48 +0000

AI models love to chat, but apps need structured data. Today we're learning Output Parsers - your solution for getting clean JSON, lists, and custom formats from AI responses.

What You'll Learn:

JSON, List, and Custom Schema parsers
Converting AI text to structured data
Practical implementation examples

The Problem

AI gives you essays when you need structured data:

{
  "service": "AWS Lambda",
  "purpose": "Serverless compute service",
  "analogy": "Like hiring a contractor - you pay only when they work"
}

Output Parsers solve this.

What Are Output Parsers?

Translators between AI's natural language and your app's data structures:

JSON Parser → Clean objects
List Parser → Simple lists
Custom Schema → Exact templates

Key Concepts

PydanticOutputParser - Enforces data structure
BaseModel - Your data template
Field - Descriptions for AI guidance
get_format_instructions() - Auto-generates AI instructions

Setup First!

Check Day 1 for environment setup.

Basic JSON Output Parser

Let's start with the most common use case - getting JSON from AI responses:

import boto3
from langchain.prompts import PromptTemplate
from langchain_aws import ChatBedrock
from langchain.output_parsers import PydanticOutputParser
from langchain.schema.output_parser import StrOutputParser
from pydantic import BaseModel, Field
import json

# Initialize Bedrock client
bedrock_client = boto3.client('bedrock-runtime', region_name='us-east-1')

llm = ChatBedrock(
    client=bedrock_client, 
    model_id="anthropic.claude-3-sonnet-20240229-v1:0",
    model_kwargs={
        "max_tokens": 300,
        "temperature": 0.3  # Lower temperature for consistent structure
    }
)

# Define the structure we want
class ServiceInfo(BaseModel):
    service: str = Field(description="AWS service name")
    purpose: str = Field(description="Main purpose in one sentence")
    analogy: str = Field(description="Simple analogy to explain the service")

# Create parser
parser = PydanticOutputParser(pydantic_object=ServiceInfo)

# Create prompt with format instructions
prompt = PromptTemplate(
    template="""Extract information about the AWS service mentioned in this text.

{format_instructions}

Text: {text}

Return only the JSON, no additional text.""",
    input_variables=["text"],
    partial_variables={"format_instructions": parser.get_format_instructions()}
)

# Build the chain
chain = prompt | llm | parser

# Test with AWS Bedrock description
bedrock_text = """
AWS Bedrock is a fully managed service that offers a choice of high-performing 
foundation models (FMs) from leading AI companies like AI21 Labs, Anthropic, 
Cohere, Meta, Stability AI, and Amazon via a single API. It provides the 
easiest way to build and scale generative AI applications with security, 
privacy, and responsible AI.
"""

print("Processing AWS Bedrock description...")
result = chain.invoke({"text": bedrock_text})

print("Structured Output:")
print(f"Service: {result.service}")
print(f"Purpose: {result.purpose}")
print(f"Analogy: {result.analogy}")

List Output Parser

Sometimes you need lists instead of objects. Here's how to extract structured lists:

from langchain.output_parsers import CommaSeparatedListOutputParser

llm = ChatBedrock(
    client=bedrock_client,
    model_id="anthropic.claude-3-sonnet-20240229-v1:0",
    model_kwargs={
        "max_tokens": 300,
        "temperature": 0.3  # Lower temperature for consistent structure
    }
)

# Create list parser
list_parser = CommaSeparatedListOutputParser()

# Create prompt for extracting use cases
list_prompt = PromptTemplate(
    template="""List the main use cases for this AWS service. 

{format_instructions}

Service description: {text}

Provide exactly 4 use cases.""",
    input_variables=["text"],
    partial_variables={"format_instructions": list_parser.get_format_instructions()}
)

# Build list extraction chain
list_chain = list_prompt | llm | list_parser

bedrock_text = """
AWS Bedrock is a fully managed service that offers a choice of high-performing 
foundation models (FMs) from leading AI companies like AI21 Labs, Anthropic, 
Cohere, Meta, Stability AI, and Amazon via a single API. It provides the 
easiest way to build and scale generative AI applications with security, 
privacy, and responsible AI.
"""

print("\nExtracting use cases...")
use_cases = list_chain.invoke({"text": bedrock_text})

print("Use Cases List:")
for i, use_case in enumerate(use_cases, 1):
    print(f"{i}. {use_case.strip()}")

Custom Schema Parser

For complex applications, define exact data structures:

from typing import List
from pydantic import BaseModel, Field
import boto3
from langchain_aws import ChatBedrock
from langchain.output_parsers import PydanticOutputParser

# Initialize Bedrock client
bedrock_client = boto3.client('bedrock-runtime', region_name='us-east-1')

llm = ChatBedrock(
    client=bedrock_client,
    model_id="anthropic.claude-3-sonnet-20240229-v1:0",
    model_kwargs={
        "max_tokens": 300,
        "temperature": 0.3
    }
)

# Define comprehensive service schema
class AWSServiceAnalysis(BaseModel):
    service_name: str = Field(description="Official AWS service name")
    category: str = Field(description="Service category (compute, storage, database, etc.)")
    pricing_model: str = Field(description="How the service is priced")
    key_features: List[str] = Field(description="List of 3 main features")
    best_for: str = Field(description="What type of applications this service is best for")
    complexity_level: str = Field(description="Beginner, Intermediate, or Advanced")

# Create comprehensive parser
comprehensive_parser = PydanticOutputParser(pydantic_object=AWSServiceAnalysis)

# Create detailed analysis prompt
analysis_prompt = PromptTemplate(
    template="""Analyze this AWS service comprehensively.

{format_instructions}

Service description: {text}

Provide detailed analysis following the exact schema.""",
    input_variables=["text"],
    partial_variables={"format_instructions": comprehensive_parser.get_format_instructions()}
)

# Build comprehensive analysis chain
analysis_chain = analysis_prompt | llm | comprehensive_parser

# Test with AWS Bedrock description
bedrock_text = """
AWS Bedrock is a fully managed service that offers a choice of high-performing 
foundation models (FMs) from leading AI companies like AI21 Labs, Anthropic, 
Cohere, Meta, Stability AI, and Amazon via a single API. It provides the 
easiest way to build and scale generative AI applications with security, 
privacy, and responsible AI.
"""
print("\nPerforming comprehensive analysis...")
analysis = analysis_chain.invoke({"text": bedrock_text})

print("Comprehensive Analysis:")
print(f"Service: {analysis.service_name}")
print(f"Category: {analysis.category}")
print(f"Pricing: {analysis.pricing_model}")
print(f"Key Features:")
for feature in analysis.key_features:
    print(f"  • {feature}")
print(f"Best For: {analysis.best_for}")
print(f"Complexity: {analysis.complexity_level}")

Parser Comparison

PydanticOutputParser → Structured objects with validation
CommaSeparatedListOutputParser → Simple lists
OutputFixingParser → Error recovery

Key Takeaways

Lower temperature (0.1-0.3) for consistent outputs
Use Field descriptions to guide AI
Test with various inputs
Start simple, add complexity as needed

About Me

Hi! I'm Utkarsh, a Cloud Specialist & AWS Community Builder who loves turning complex AWS topics into fun chai-time stories ☕

👉 Explore more

This is part of my "LangChain with AWS Bedrock: A Developer's Journey" series. Follow along as I document everything I learn, including the mistakes and the victories.

Day 3: Modern Chaining with LangChain Expression Language

Utkarsh Rastogi — Tue, 26 Aug 2025 05:12:57 +0000

Welcome back to our LangChain journey! Yesterday we explored prompt engineering. Today, we are mastering LCEL (LangChain Expression Language) - the modern way to chain multiple steps together.

What You'll Learn:

How LCEL replaces deprecated LangChain chains
Building sequential workflows with pipe operators
Managing data flow between processing steps
Real-world multi-step text processing

What is LCEL Sequential Processing?

Imagine you're cooking a meal:

Prep ingredients (chop vegetables)
Cook (sauté in pan)
Plate (arrange beautifully)

Each step depends on the previous one. That's exactly how LCEL chaining works!

LCEL Patterns:

Simple Chain: prompt | llm | parser - Linear processing
Complex Chain: Multiple inputs/outputs with data transformation

Real-world analogy:

Simple LCEL = Email → Spell check → Send
Complex LCEL = Email + Recipient info + Priority → Format + Route + Log

Key Advantage: LCEL chains are composable - you can easily combine, modify, or reuse parts of your workflow.

Setup First!

If you haven't set up your environment yet, check Day 1 for package installation.

LCEL Sequential Processing in Action

Let's build our AWS S3 definition processor using modern LCEL:

import boto3
from langchain.prompts import PromptTemplate
from langchain_aws import ChatBedrock
from langchain.schema.output_parser import StrOutputParser
import time

# Initialize Bedrock client
bedrock_client = boto3.client('bedrock-runtime', region_name='us-east-1')

# LLM = Large Language Model (the AI that processes text)
llm = ChatBedrock(
    client=bedrock_client, 
    model_id="anthropic.claude-3-sonnet-20240229-v1:0",
    model_kwargs={
        "max_tokens": 200,
        "temperature": 0.7
    }
)


# Create the complete chain using LCEL with time tracking
def overall_chain(inputs):
    print("> Starting chain...\n")

    # Step 1: Summarize
    print("> Step 1: Summarizing...")
    start_time = time.time()

    summary_prompt = PromptTemplate(
        input_variables=["text"],
        template="Summarize this in exactly 2 sentences (max 50 words): {text}"
    )
    summary = (summary_prompt | llm | StrOutputParser()).invoke({"text": inputs["text"]})

    step_time = time.time() - start_time
    print(f"> Finished step ({step_time:.2f}s)")
    print(summary)
    print()

    # Step 2: Translate
    print("> Step 2: Translating...")
    start_time = time.time()

    translate_prompt = PromptTemplate(
        input_variables=["summary"],
        template="Translate this to Hindi (keep it concise): {summary}"
    )
    hindi_text = (translate_prompt | llm | StrOutputParser()).invoke({"summary": summary})

    step_time = time.time() - start_time
    print(f"> Finished step ({step_time:.2f}s)")
    print(hindi_text)
    print()

    # Step 3: Format as Tweet
    print("> Step 3: Formatting for social media...")
    start_time = time.time()

    tweet_prompt = PromptTemplate(
        input_variables=["hindi_text"],
        template="Convert to tweet format with 2-3 emojis (max 280 chars): {hindi_text}"
    )
    tweet = (tweet_prompt | llm | StrOutputParser()).invoke({"hindi_text": hindi_text})

    step_time = time.time() - start_time
    print(f"> Finished step ({step_time:.2f}s)")
    print(tweet)
    print()
    print("> Chain complete.")

    return tweet

Running Our Chain

s3_definition = """
Amazon Simple Storage Service (Amazon S3) is an object storage service 
offering industry-leading scalability, data availability, security, and 
performance. Customers of all sizes and industries can store and protect 
any amount of data for virtually any use case, such as data lakes, 
cloud-native applications, and mobile apps.
"""

# Execute the chain
result = overall_chain({"text": s3_definition})
print(result)

Actual Output

Here's what our chain produces:

LCEL Components Explained

Key Components:

llm: The Large Language Model (ChatBedrock) that processes text
StrOutputParser(): Converts LLM's complex response object to simple string
| (pipe): Connects components - output of left becomes input of right

Why This Approach Works Better:

Modern: Uses latest LangChain syntax (no deprecation warnings)
Clean Output: StrOutputParser() gives you just the text, not metadata
Flexible: Easy pipe operator chaining
Type-Safe: Better error handling and validation
Readable: Clear data flow with | operators

Advanced: Complex LCEL Chains

For more complex workflows with multiple inputs/outputs, use advanced LCEL patterns:

import time

# Complex chain with multiple inputs and time tracking
def complex_chain(inputs):
    print("> Starting complex analysis chain...\n")

    # Step 1: Analyze service (Detailed analysis - more tokens)
    print("> Step 1: Analyzing service...")
    start_time = time.time()

    analyze_llm = ChatBedrock(
        client=bedrock_client,
        model_id="anthropic.claude-3-sonnet-20240229-v1:0",
        model_kwargs={"max_tokens": 300, "temperature": 0.3}
    )
    analysis_prompt = PromptTemplate(
        input_variables=["service_text", "focus_area"],
        template="Analyze this AWS service focusing on {focus_area} (max 200 words): {service_text}"
    )
    analysis = (analysis_prompt | analyze_llm | StrOutputParser()).invoke({
        "service_text": inputs["service_text"],
        "focus_area": inputs["focus_area"]
    })

    step_time = time.time() - start_time
    print(f"> Finished analysis ({step_time:.2f}s)")
    print(f"Analysis: {analysis[:100]}...")
    print()

    # Step 2: Create summary (Medium tokens)
    print("> Step 2: Creating summary...")
    start_time = time.time()

    summary_llm = ChatBedrock(
        client=bedrock_client,
        model_id="anthropic.claude-3-sonnet-20240229-v1:0",
        model_kwargs={"max_tokens": 150, "temperature": 0.5}
    )
    summary_prompt = PromptTemplate(
        input_variables=["analysis", "target_audience"],
        template="Summarize for {target_audience} in 3-4 sentences: {analysis}"
    )
    summary = (summary_prompt | summary_llm | StrOutputParser()).invoke({
        "analysis": analysis,
        "target_audience": inputs["target_audience"]
    })

    step_time = time.time() - start_time
    print(f"> Finished summary ({step_time:.2f}s)")
    print(f"Summary: {summary}")
    print()

    # Step 3: Generate recommendation (Short and decisive)
    print("> Step 3: Making recommendation...")
    start_time = time.time()

    recommend_llm = ChatBedrock(
        client=bedrock_client,
        model_id="anthropic.claude-3-sonnet-20240229-v1:0",
        model_kwargs={"max_tokens": 100, "temperature": 0.2}
    )
    recommendation_prompt = PromptTemplate(
        input_variables=["summary", "use_case"],
        template="Recommend YES/NO for {use_case} with 2-sentence reason: {summary}"
    )
    recommendation = (recommendation_prompt | recommend_llm | StrOutputParser()).invoke({
        "summary": summary,
        "use_case": inputs["use_case"]
    })

    step_time = time.time() - start_time
    print(f"> Finished recommendation ({step_time:.2f}s)")
    print(f"Recommendation: {recommendation}")
    print()
    print("> Complex chain complete.")

    return {
        "analysis": analysis,
        "summary": summary,
        "recommendation": recommendation
    }

# Add input_keys for compatibility
complex_chain.input_keys = ["service_text", "focus_area", "target_audience", "use_case"]

# Run with multiple inputs
result = complex_chain({
    "service_text": s3_definition,
    "focus_area": "security and scalability",
    "target_audience": "developers",
    "use_case": "mobile app backend"
})

print("\nFinal Results:")
print("Analysis:", result["analysis"])
print("Summary:", result["summary"]) 
print("Recommendation:", result["recommendation"])

Actual Output

Here's what our chain produces:

Simple vs Complex LCEL Chains

Feature	Simple LCEL	Complex LCEL
Inputs	Single input	Multiple inputs
Outputs	Single output	Multiple outputs
Use Case	Linear pipeline	Complex workflows
Data Flow	Auto-passed	Custom transformation
Complexity	Simple	Moderate
Best For	Content processing	Decision workflows
Learning Curve	1-2 hours	4-6 hours
Maintenance	Easy	Requires planning

Practical Applications:

Simple LCEL: Content processing, translation, formatting, social media automation
Complex LCEL: Business analysis, decision-making, multi-criteria evaluation, recommendation systems

Key Differences Between Our Examples

Example 1: Simple Chain

# Single input
overall_chain({"text": "AWS S3 definition..."})

# Fixed flow: Text → Summarize → Translate → Tweet
# Same LLM settings for all steps
# Returns: Final tweet string

Example 2: Complex Chain

# Multiple inputs
complex_chain({
    "service_text": "AWS S3 definition...",
    "focus_area": "security and scalability", 
    "target_audience": "developers",
    "use_case": "mobile app backend"
})

# Business flow: Analyze → Summarize → Recommend
# Different LLM settings per step
# Returns: Dictionary with all results

Different LLM Configurations:

# Analyze: More tokens, less creative (factual analysis)
analyze_llm = ChatBedrock(model_kwargs={"max_tokens": 300, "temperature": 0.3})

# Summary: Medium tokens, balanced creativity
summary_llm = ChatBedrock(model_kwargs={"max_tokens": 150, "temperature": 0.5})

# Recommend: Fewer tokens, very focused (decisions)
recommend_llm = ChatBedrock(model_kwargs={"max_tokens": 100, "temperature": 0.2})

Temperature Guide:

0.2 = Very focused, factual responses (recommendations)
0.5 = Balanced creativity and accuracy (summaries)
0.7 = More creative and varied responses (content creation)

Token Management Strategy:

100 tokens = Short, concise responses (decisions)
150 tokens = Medium-length responses (summaries)
300 tokens = Detailed, comprehensive responses (analysis)

LCEL vs Legacy Chains

Modern LCEL Approach:

# Clean, readable, no deprecation warnings
chain = prompt | llm | StrOutputParser()
result = chain.invoke({"text": input_text})

Legacy Approach (Deprecated):

# Old way - causes deprecation warnings
chain = LLMChain(llm=llm, prompt=prompt)
result = chain.run(input_text)

Real-World Use Cases

Simple LCEL Patterns:

Content Pipeline: Write → Edit → Format → Publish
Customer Support: Query → Analyze → Respond → Log
Document Review: Read → Analyze → Suggest → Format

Complex LCEL Patterns:

Service Recommendation: Requirements + Budget → Analyze + Compare → Recommend + Justify
Document Processing: Text + Metadata → Extract + Classify → Store + Index
Multi-language Support: Content + Target + Tone → Translate + Adapt + Validate

Token Optimization Strategies:

Use smaller models for simple steps (summarization)
Use larger models for complex reasoning (analysis)
Set lower temperature for factual tasks
Set higher temperature for creative tasks

Key Takeaways

Sequential chains = Multi-step automation with control
Simple LCEL for linear processing (A→B→C)
Complex LCEL for multi-input scenarios (A+B→C+D→E)
Use verbose=True for debugging and learning
Control response length per step to manage costs
Different processor settings for different complexity levels
Each step builds on the previous one

Pro Tips:

Start with simple LCEL, upgrade when needed
Monitor usage with verbose=True
Use specific instructions to control response length
Test each step individually first

About Me

Hi! I'm Utkarsh, a Cloud Specialist & AWS Community Builder who loves turning complex AWS topics into fun chai-time stories ☕

👉 Explore more

This is part of my "LangChain with AWS Bedrock: A Developer's Journey" series. Follow along as I document everything I learn, including the mistakes and the victories.

Day 2: Prompt Engineering Basics with LangChain

Utkarsh Rastogi — Mon, 25 Aug 2025 01:38:26 +0000

Welcome to Day 2 of our LangChain + AWS Bedrock journey! Today we dive into the art and science of prompt engineering - the skill that transforms simple text into powerful AI interactions.

What We'll Learn Today

Zero-shot prompting: Getting results without examples
Few-shot prompting: Learning from examples
Role prompting: Making AI adopt specific personas
Model parameters: Fine-tuning AI behavior (temperature, top_p, max_tokens)

Setup (Continuing from Day 1)

Assuming you have the packages and bedrock client from Day 1, let's initialize our Claude model with specific parameters for today's experiments:

from langchain_aws import ChatBedrock
from langchain.prompts import PromptTemplate

# Initialize Claude with parameters for prompt engineering
llm = ChatBedrock(
    model_id="anthropic.claude-3-sonnet-20240229-v1:0",
    region_name="us-east-1",
    model_kwargs={
        "max_tokens": 150,
        "temperature": 0.7,
        "top_p": 0.9
    }
)

Understanding Prompt Engineering

Prompt engineering is the art of crafting instructions that guide AI models to produce desired outputs. Think of it like being a director giving instructions to an actor - the clearer and more specific your direction, the better the performance.

The key principles are:

Clarity: Be specific about what you want
Context: Provide relevant background information
Constraints: Set boundaries (length, format, tone)
Examples: Show the desired output style when needed

1. Zero-Shot Prompting

Zero-shot prompting is like asking someone to perform a task they've never seen before, relying purely on their general knowledge and understanding. The model uses its pre-trained knowledge without any specific examples.

When to use Zero-shot:

Simple, well-defined tasks
When the model already understands the domain
For general knowledge questions
When you want the model's "natural" response

Advantages:

Quick and simple
No need to prepare examples
Works well for common tasks

Limitations:

May not follow specific formats
Less control over output style
Can be inconsistent for complex tasks

# Zero-shot prompt - no examples given
zero_shot_prompt = PromptTemplate(
    input_variables=["service"],
    template="Explain {service} in simple terms for a beginner."
)

# Use it
prompt = zero_shot_prompt.format(service="Amazon S3")
response = llm.invoke(prompt)
print(response.content)

2. Few-Shot Prompting

Few-shot prompting is like showing someone examples before asking them to do a task. You provide 2-5 examples of the desired input-output pattern, then ask the model to follow the same pattern.

When to use Few-shot:

When you need consistent formatting
For complex or unusual tasks
When zero-shot results are inconsistent
To establish a specific style or tone

Advantages:

Better control over output format
More consistent results
Can teach complex patterns
Reduces need for detailed instructions

Best practices:

Use 2-5 examples (more isn't always better)
Make examples diverse but consistent
Show edge cases if relevant
Keep examples concise

# Few-Shot Prompting

few_shot_prompt = PromptTemplate(
    input_variables=["service"],
    template="""
Explain AWS services using this format:

Example 1:
Service: Amazon EC2
Simple Explanation: Virtual computers in the cloud that you can rent by the hour.

Example 2:
Service: Amazon RDS
Simple Explanation: Managed database service that handles backups and updates automatically.

Now explain:
Service: {service}
Simple Explanation:"""
)

# Use the few-shot prompt
prompt = few_shot_prompt.format(service="Amazon Lambda")
response = llm.invoke(prompt)
print(response.content)

3. Role Prompting

Role prompting assigns a specific identity, profession, or perspective to the AI. It's like asking the model to "act as" someone with particular expertise, personality, or viewpoint.

Why Role Prompting works:

Models have learned associations between roles and communication styles
Provides context for appropriate language and knowledge level
Helps generate more engaging and targeted responses
Leverages the model's understanding of different perspectives

Types of roles:

Professional roles: "You are a software architect", "You are a teacher"
Personality traits: "You are enthusiastic", "You are patient and methodical"
Expertise levels: "You are a beginner", "You are an expert"
Creative personas: "You are a poet", "You are a storyteller"

Best practices:

Be specific about the role's characteristics
Include relevant context about the audience
Combine roles with other prompting techniques
Test different roles to find what works best

role_prompt = PromptTemplate(
    input_variables=["service", "role"],
    template="""
You are a {role}. Explain {service} from your perspective.
Keep it engaging and use language appropriate to your role.
"""
)

# Test different roles
roles = ["friendly teacher", "creative poet", "cricket commentator"]

for role in roles:
    print(f"\n{role.title()}:")
    prompt = role_prompt.format(service="Amazon Lambda", role=role)
    response = llm.invoke(prompt)
    print(response.content)
    print("-" * 40)

Model Parameters

The model_kwargs parameter controls AI behavior:

Key Parameters

max_tokens: Response length (50-150 for short, 200-500 for detailed)
temperature: Creativity level (0.2 = focused, 0.7 = balanced, 0.9 = creative)
top_p: Word diversity (0.8 = focused, 0.9 = balanced)

Quick Examples

# Factual responses
factual_kwargs = {"max_tokens": 150, "temperature": 0.2, "top_p": 0.8}

# Creative responses  
creative_kwargs = {"max_tokens": 300, "temperature": 0.9, "top_p": 0.95}

Key Takeaways

Core Prompting Techniques:

Zero-shot: Direct instructions, relies on model knowledge
Few-shot: Provide examples to guide format and style
Role prompting: Adopt personas for engaging explanations

Model Control:

Parameters: Fine-tune behavior with temperature, top_p, max_tokens

Best Practices

Getting Started:

Start Simple: Begin with zero-shot, add complexity as needed
Be Specific: Vague prompts lead to inconsistent results
Test Iteratively: Refine prompts based on outputs

Improving Results:

Use Examples: Show don't just tell what you want
Set Constraints: Guide the model with clear boundaries
Consider Context: Provide relevant background information

Optimization:

Monitor Parameters: Adjust temperature and top_p for your use case
Test Edge Cases: Try unusual inputs to test robustness

Common Pitfalls to Avoid

Over-prompting: Too many instructions can confuse the model
Ambiguous language: Be precise in your requirements
Ignoring context length: Very long prompts may get truncated
Not testing edge cases: Try unusual inputs to test robustness
Fixed parameters: Different tasks need different temperature/top_p values
Inconsistent examples: Make sure few-shot examples follow the same pattern

About Me

Hi! I'm Utkarsh, a Cloud Specialist & AWS Community Builder who loves turning complex AWS topics into fun chai-time stories ☕

👉 Explore more

This is part of my "LangChain with AWS Bedrock: A Developer's Journey" series. Follow along as I document everything I learn, including the mistakes and the victories.

Day 1: LangChain Basics - My First Chat with Claude and Titan

Utkarsh Rastogi — Sun, 24 Aug 2025 06:17:03 +0000

Hey there! Welcome to my journey of learning LangChain with AWS Bedrock. I'm documenting everything as I go, so you can learn alongside me. Today was my first day diving into this fascinating world of AI models, and honestly, it felt like having a conversation with the future.

Quick Setup Note: I'm using AWS SageMaker Studio notebooks for this entire series - it comes with all AWS permissions pre-configured and makes the learning process super smooth. Just create a notebook and you're ready to go!

What is LangChain and Why Use It?

LangChain is a Python framework that makes working with Large Language Models (LLMs) incredibly simple. Instead of writing complex API calls and handling raw JSON responses, LangChain provides a clean, intuitive interface.

Why LangChain?

Simplicity: One line of code instead of 20+ lines of API handling
Consistency: Same interface for different AI models (Claude, GPT, Titan, etc.)
Power: Built-in features like memory, chains, and prompt templates
Flexibility: Easy to switch between models or combine multiple AI calls

Think of LangChain as a bridge between your Python code and powerful AI models. Instead of dealing with complex API calls and JSON responses, LangChain makes it feel like you're just chatting with a really smart friend who happens to live in the cloud.

Setting Up Our Playground

First things first - let's get our tools ready. It's like preparing chai before a good conversation:

!pip install boto3==1.39.13 botocore==1.39.13 langchain==0.3.27 langchain-aws==0.2.31

import boto3
from langchain_aws import ChatBedrock

# Initialize Bedrock client
bedrock_client = boto3.client(
    service_name="bedrock-runtime",
    region_name="us-east-1"
)

This is our foundation. The bedrock_client is like getting a VIP pass to AWS's AI models. Simple, right?

Meeting Claude - The Thoughtful AI

Claude is like that friend who always gives thoughtful, well-structured answers. Let's set him up:

# Create a LangChain ChatBedrock
llm = ChatBedrock(
    client=bedrock_client,
    model_id="anthropic.claude-3-sonnet-20240229-v1:0",
    model_kwargs={"max_tokens": 256, "temperature": 0.7}
)

response = llm.invoke("Write a short poem about AWS In Human Feel Based on Indian Desi Version")
print("Claude Response:\n", response.content)

The magic happens in that invoke() call. It's like asking a question and getting back a thoughtful response. The temperature: 0.7 makes Claude a bit creative - not too robotic, not too wild.

Meeting Titan - The Quick Responder

Now, let's try Amazon's own Titan model. But here's where I learned something important the hard way:

# Try with Titan model (shorter completion)
titan_llm = ChatBedrock(
    client=bedrock_client,
    model_id="amazon.titan-text-lite-v1",
    model_kwargs={"maxTokenCount": 128, "temperature": 0.5}
)

prompt = """You are a creative Indian poet with a friendly desi vibe. Write a short poem (4 lines max) about AWS cloud services. 
Use simple human feelings and desi cultural touches (like chai, monsoon, Bollywood style). Keep the tone warm, positive, and 
free of any bad or offensive words.
"""
response = titan_llm.invoke(prompt)
print("Titan Response:\n", response.content)

The Gotchas I Discovered

1. Model Names Matter

I initially used amazon.titan-text-lite-v1, but for chat interactions, amazon.titan-text-express-v1 works better. It's like calling someone by the right name - details matter!

2. Parameter Confusion: maxTokenCount vs max_tokens

This one got me! Different models expect different parameter names:

Claude models: Use max_tokens
Some Titan models: Might expect maxTokenCount in certain contexts
LangChain standard: Generally uses max_tokens

Think of it like this - it's the same concept (limiting response length), but different models speak slightly different dialects. Always check the documentation!

3. Using the Right Model Instance

I made a silly mistake - created titan_llm but then used llm for the Titan response. It's like preparing two different teas but serving the wrong one to your guest!

What I Learned Today

LangChain simplifies everything - No more wrestling with raw API responses
Each model has personality - Claude is thoughtful, Titan is quick
Parameter names vary - Always double-check the docs
Temperature controls creativity - Lower = more focused, Higher = more creative
Model IDs are specific - Use the right one for your use case

Wrapping Up

Day 1 was all about getting comfortable with the basics. Like learning to ride a bike, the first day is about balance and not falling off. Each day we'll be discovering new concepts through hands-on experimentation!

The beauty of LangChain is that it makes powerful AI feel approachable. You don't need a PhD in machine learning - just curiosity and willingness to experiment.

Happy coding! If you found this helpful, leave a comment and follow this whole series as we explore more LangChain magic together.

About Me

Hi! I'm Utkarsh, a Cloud Specialist & AWS Community Builder who loves turning complex AWS topics into fun chai-time stories ☕

👉 Explore more

This is part of my "LangChain with AWS Bedrock: A Developer's Journey" series. Follow along as I document everything I learn, including the mistakes and the victories.

AWS VPC to ECS - Day 5: ECS Service with Smart Auto-Scaling

Utkarsh Rastogi — Sat, 23 Aug 2025 13:13:56 +0000

Hey everyone! Today I'm diving deep into ECS services and auto-scaling. After setting up the load balancer on Day 4, it's time to deploy my FastAPI application with intelligent scaling that responds to real traffic patterns.

What We're Building Today

ECS Service that keeps containers running and healthy
Smart Auto-Scaling that maintains optimal performance (1-5 containers)
FastAPI Application with multiple endpoints for testing
CloudWatch Monitoring with email alerts
Load Testing Endpoints to validate scaling behavior

The Complete ECS Service with Auto-Scaling

Note: We already created the ECS cluster in our previous setup, so we'll focus on the service configuration.

Here's the full ECS service configuration with intelligent auto-scaling:

# infra/ecs/ecs_service.yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Creating ECS Service for Learning Purpose'

Parameters:
  TeamNameValue:
    Type: String
    Description: TeamName Tag Value
    Default: "awslearner"
  EnvironmentValue:
    Type: String
    Description: Environment Tag Value
    Default: "dev"
  ServiceName:
    Type: String
    Description: Name of the ECS service
    Default: "learner-svc"
  ExecutionRoleName:
    Type: String
    Description: Name of the service execution role
    Default: "learner-ecs-role"
  TaskRoleName:
    Type: String
    Description: Name of the service execution role
    Default: "learner-ecs-task-exc-role"
  ImageARN:
    Type: AWS::SSM::Parameter::Value<String>
    Description: Image ARN
    Default: "/learner/imagearn/value"
  ECSCluster:
    Type: String
    Description: ECS Cluster Name
    Default: "learner-cluster"
  PublicSubnetIds:
    Type: AWS::SSM::Parameter::Value<String>
    Description: Subnet ID
    Default: "/learner/public/subnetids"
  SecurityGroup:
    Type: AWS::SSM::Parameter::Value<String>
    Description: Security Group
    Default: "/learner/public/sgid"
  TargetGroupArn:
    Type: AWS::SSM::Parameter::Value<String>
    Description: Target Group ARN
    Default: "/learner/target/value"
  AlertEmail:
    Type: String
    Description: Email address for alerts
    Default: <Provide Email Address>

Resources:
  # Storage for your container logs
  ECSLogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub /ecs/${ServiceName}-logs
      RetentionInDays: 14
      Tags:
        - Key: Name
          Value: !Sub /ecs/${ServiceName}-logs
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  # Blueprint that tells ECS how to run your containers
  TaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
      Family: !Sub ${ServiceName}-task
      Cpu: 256                   
      Memory: 512       
      NetworkMode: awsvpc
      RequiresCompatibilities:
        - FARGATE
      ExecutionRoleArn: !Sub arn:aws:iam::${AWS::AccountId}:role/${ExecutionRoleName}
      TaskRoleArn: !Sub arn:aws:iam::${AWS::AccountId}:role/${TaskRoleName}
      ContainerDefinitions:
        - Name: !Sub ${ServiceName}-container
          Image: !Ref ImageARN
          PortMappings:
            - ContainerPort: 80
          LogConfiguration:
            LogDriver: awslogs
            Options:
              awslogs-group: !Ref ECSLogGroup
              awslogs-region: !Ref AWS::Region
              awslogs-stream-prefix: ecs
      Tags:
        - Key: Name
          Value: !Sub ${ServiceName}-task
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  # Service that keeps your containers running and healthy
  ECSService:
    Type: AWS::ECS::Service
    Properties:
      Cluster: !Ref ECSCluster
      ServiceName: !Sub ${ServiceName}-service
      TaskDefinition: !Ref TaskDefinition
      LaunchType: FARGATE
      DesiredCount: 1
      PropagateTags: SERVICE
      NetworkConfiguration:
        AwsvpcConfiguration:
          AssignPublicIp: ENABLED   
          Subnets: !Split 
            - ","
            - !Ref PublicSubnetIds
          SecurityGroups:
            - !Ref SecurityGroup
      LoadBalancers:
        - ContainerName: !Sub ${ServiceName}-container 
          ContainerPort: 80
          TargetGroupArn: !Ref TargetGroupArn
      Tags:
        - Key: Name
          Value: !Sub ${ServiceName}-service
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  # Defines scaling limits for your containers (1-5 tasks)
  AutoScalingTarget:
    Type: AWS::ApplicationAutoScaling::ScalableTarget
    DependsOn: ECSService
    Properties:
      ServiceNamespace: ecs
      ResourceId: !Sub "service/${ECSCluster}/${ServiceName}-service"
      ScalableDimension: ecs:service:DesiredCount
      MinCapacity: 1          
      MaxCapacity: 5

  # Target tracking scaling policy - maintains CPU around 40%
  AutoScalingPolicy:
    Type: AWS::ApplicationAutoScaling::ScalingPolicy
    Properties:
      PolicyName: !Sub ${EnvironmentValue}-${ServiceName}-target-tracking
      PolicyType: TargetTrackingScaling
      ScalingTargetId: !Ref AutoScalingTarget
      TargetTrackingScalingPolicyConfiguration:
        TargetValue: 40.0                    # Target 40% CPU utilization
        PredefinedMetricSpecification:
          PredefinedMetricType: ECSServiceAverageCPUUtilization
        ScaleOutCooldown: 120               # Wait 2 minutes before scaling up
        ScaleInCooldown: 300                # Wait 5 minutes before scaling down
        DisableScaleIn: false

  # Email notification system for alerts
  AlertTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: !Sub ${EnvironmentValue}-${ServiceName}-alerts
      DisplayName: !Sub "${ServiceName} ECS Alerts"
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentValue}-${ServiceName}-alerts
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  # Connects your email to the alert system
  AlertSubscription:
    Type: AWS::SNS::Subscription
    Properties:
      Protocol: email
      TopicArn: !Ref AlertTopic
      Endpoint: !Ref AlertEmail

  # Alert when CPU is high at maximum capacity
  CriticalCPUAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: !Sub ${EnvironmentValue}-${ServiceName}-CriticalCPU-AtMaxCapacity
      AlarmDescription: !Sub "CRITICAL: ${ServiceName} CPU >70% at max capacity (5 tasks)"
      MetricName: CPUUtilization
      Namespace: AWS/ECS
      Statistic: Average
      Period: 60
      EvaluationPeriods: 2
      Threshold: 70
      ComparisonOperator: GreaterThanThreshold
      AlarmActions:
        - !Ref AlertTopic
      Dimensions:
        - Name: ServiceName
          Value: !Sub ${ServiceName}-service
        - Name: ClusterName
          Value: !Ref ECSCluster

  # Alert when you reach maximum number of containers
  MaxCapacityAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: !Sub ${EnvironmentValue}-${ServiceName}-MaxCapacity-Reached
      AlarmDescription: !Sub "WARNING: ${ServiceName} reached maximum capacity (5 tasks)"
      MetricName: RunningTaskCount
      Namespace: AWS/ECS
      Statistic: Maximum
      Period: 60
      EvaluationPeriods: 1
      Threshold: 5
      ComparisonOperator: GreaterThanOrEqualToThreshold
      AlarmActions:
        - !Ref AlertTopic
      Dimensions:
        - Name: ServiceName
          Value: !Sub ${ServiceName}-service
        - Name: ClusterName
          Value: !Ref ECSCluster

FastAPI Application with Testing Endpoints

Here's my FastAPI application with endpoints designed to test different scenarios:

# source/app.py
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import logging
import time
import hashlib
import boto3
import threading
import multiprocessing
import uvicorn

app = FastAPI()
logger = logging.getLogger("ecs_service")
active_requests = 0

# Initialize ECS client for monitoring
try:
    ecs_client = boto3.client('ecs')
except Exception as e:
    logger.warning(f"Could not initialize ECS client: {e}")
    ecs_client = None

class SubmitData(BaseModel):
    name: str = "User"

@app.get("/")
def home():
    """Simple welcome message"""
    return "Hello from ECS Fargate Service!"

@app.get("/api/health")
def health():
    """Health check endpoint for load balancer"""
    return {"status": "healthy"}

@app.post("/api/submit")
def api_submit(data: SubmitData):
    """Accepts user data and returns personalized message"""
    logger.info(f"Data received: {data.model_dump()}")
    return {"message": f"Happy learning, {data.name}!", "data": data.model_dump()}

@app.get("/api/load")
def generate_load():
    """Generates heavy CPU load for 60 seconds to test auto-scaling"""
    def cpu_intensive_task():
        start_time = time.time()
        while time.time() - start_time < 60:
            for _ in range(10000):
                hashlib.sha256(str(time.time()).encode()).hexdigest()
                sum(range(1000))

    # Use multiple threads to maximize CPU usage
    cpu_count = multiprocessing.cpu_count()
    threads = []
    for _ in range(cpu_count * 2):
        thread = threading.Thread(target=cpu_intensive_task)
        thread.start()
        threads.append(thread)

    for thread in threads:
        thread.join()

    logger.info("CPU load generation completed")
    return {"status": "load_generated", "duration": "60s", "threads": cpu_count * 2}

@app.get("/api/quickload")
def quick_load():
    """Generates 10-second CPU burst for quick scaling tests"""
    def burst_task():
        start_time = time.time()
        while time.time() - start_time < 10:
            for _ in range(50000):
                hashlib.sha256(str(time.time()).encode()).hexdigest()

    cpu_count = multiprocessing.cpu_count()
    threads = []
    for _ in range(cpu_count * 3):
        thread = threading.Thread(target=burst_task)
        thread.start()
        threads.append(thread)

    for thread in threads:
        thread.join()

    return {"status": "burst_completed", "duration": "10s"}

@app.get("/api/scalinginfo")
def get_scaling_info():
    """Returns current ECS service scaling status"""
    if not ecs_client:
        return {"error": "ECS client not available"}

    try:
        response = ecs_client.describe_services(
            cluster='learner-cluster',
            services=['learner-svc-service']
        )

        if response['services']:
            service = response['services'][0]
            return {
                "cluster": "learner-cluster",
                "service": "learner-svc-service",
                "desired_count": service['desiredCount'],
                "running_count": service['runningCount'],
                "pending_count": service['pendingCount'],
                "status": service['status'],
                "active_requests": active_requests
            }
        else:
            return {"error": "Service not found"}

    except Exception as e:
        logger.error(f"Error getting scaling info: {str(e)}")
        return {"error": "Unable to fetch scaling information"}

@app.get("/api/error")
def trigger_error():
    """Triggers 500 error for testing error handling"""
    logger.error("Intentional error triggered")
    raise HTTPException(status_code=500, detail="Internal server error")

@app.get("/api/notfound")
def not_found():
    """Triggers 404 error for testing not found responses"""
    logger.warning("Resource not found")
    raise HTTPException(status_code=404, detail="Resource not found")

if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0.0", port=8000)

Requirements File

# source/requirements.txt
fastapi==0.104.1
uvicorn==0.24.0
boto3==1.34.0
pydantic==2.5.0

Deployment Commands

Important: Before deploying the ECS service, we need to build and push our container image using the CodeBuild project we set up in Day 4.

Deploy in this order:

# 1. First, build and push your container image
# This uses the CodeBuild project from Day 4
aws codebuild start-build --project-name learner-project

# Wait for the build to complete (check in AWS Console or CLI)
# This typically takes 2-3 minutes

# 2. Deploy ECS service with auto-scaling
aws cloudformation deploy \
  --template-file infra/ecs/ecs_service.yaml \
  --stack-name AWSLearner-ECS-Stack \
  --capabilities CAPABILITY_NAMED_IAM

Auto-Scaling Scenario's

1. Check Current Status

curl http://your-alb-url/api/scalinginfo

Response:

{
  "desired_count": 1,
  "running_count": 1,
  "pending_count": 0,
  "status": "ACTIVE"
}

2. Trigger Heavy Load

curl http://your-alb-url/api/load

This creates 60 seconds of intense CPU load. Watch CloudWatch metrics to see:

CPU utilization spike to 80-90%
Auto-scaling trigger after 2 minutes
New containers start (desired_count increases)
Load distributes across containers
CPU drops back to target 40%

3. Quick Burst Test

curl http://your-alb-url/api/quickload

Perfect for testing rapid scaling response with a 10-second burst.

Postman Testing

GET /api/health - Health check status

POST /api/submit - Data submission with JSON body

GET /api/scalinginfo - Current container status

GET /api/load - Load generation response

GET /api/quickload - Quick burst response

GET /api/error - Error handling test

GET /api/notfound - 404 error test

Note: To see auto-scaling in action, you'll need to hit the load endpoints multiple times or use multiple browser tabs/terminals simultaneously to generate enough traffic that triggers the CPU threshold.

What Each Endpoint Does

Endpoint	Purpose	Response Time
`/api/health`	Load balancer health check	Instant
`/api/submit`	Data processing test	Instant
`/api/load`	Sustained CPU load (60s)	60 seconds
`/api/quickload`	CPU burst (10s)	10 seconds
`/api/scalinginfo`	Current container status	Instant
`/api/error`	Error handling test	Instant
`/api/notfound`	404 error test	Instant

Auto-Scaling Behavior

How it works:

Target: Maintains 40% CPU utilization
Scale Out: Adds containers when CPU > 40% (2-minute cooldown)
Scale In: Removes containers when CPU < 40% (5-minute cooldown)
Limits: 1-5 containers
Alerts: Email notifications at critical thresholds

Scaling Timeline:

0-2 minutes: High CPU detected, evaluation period
2-4 minutes: New container launching
4-6 minutes: Container healthy, receiving traffic
6+ minutes: Load distributed, CPU normalizes

Key Learnings

Target tracking scaling is much smarter than threshold-based scaling
Cooldown periods prevent rapid scaling that could cause instability
Email alerts provide peace of mind without constant monitoring
Load testing endpoints are essential for validating your setup
ECS Fargate eliminates server management completely

What's Next in This Series?

In this comprehensive series, we've learned how to deploy a complete containerized application from VPC to ECS service using Fargate. We covered:

VPC Setup with multi-AZ networking
Security Groups and IAM roles
ECR Repository for container images
CodeBuild Pipeline for CI/CD
Application Load Balancer for traffic distribution
ECS Service with intelligent auto-scaling

The auto-scaling system feels really robust now. I can throw traffic at it, watch it scale intelligently, and get notified if anything needs attention. Perfect foundation for a production workload!

Complete Day 5 Learning Summary

What we accomplished in Day 5:

Infrastructure Built

ECS Service with Fargate launch type (256 CPU, 512 MB RAM)
Task Definition with proper IAM roles and logging
Auto-Scaling Target (1-5 containers) with target tracking policy
CloudWatch Alarms for critical CPU and max capacity alerts
SNS Email Notifications for real-time monitoring

Application Features

7 FastAPI Endpoints for comprehensive testing
Load Testing Capabilities (60s sustained + 10s burst)
Real-time Monitoring with ECS service status
Error Handling and health checks
Structured Logging to CloudWatch

Auto-Scaling Intelligence

Target Tracking: Maintains 40% CPU utilization
Smart Cooldowns: 2min scale-out, 5min scale-in
Proportional Scaling: Responds to load intensity
Email Alerts: Critical thresholds and capacity warnings

Key Takeaway: We now have a fully automated, scalable containerized application that can handle real-world traffic patterns while maintaining cost efficiency and operational visibility.

💻 About Me

Hi! I'm Utkarsh, a Cloud Specialist & AWS Community Builder who loves turning complex AWS topics into fun chai-time stories ☕

👉 Explore more

AWS VPC to ECS - Day 4: Security Groups, Load Balancer & CodeBuild Setup

Utkarsh Rastogi — Sun, 17 Aug 2025 12:52:54 +0000

Hey everyone! Welcome back to our AWS ECS journey. Today we're diving into three crucial components that will make our containerized application secure, scalable, and automatically deployable.

If you've been following along, we've already set up our VPC, subnets, and ECS cluster. Now it's time to add the security layer, traffic distribution, and automated builds.

What We're Building Today

Today we'll create:

Security Groups - Our network firewall rules
Application Load Balancer - Traffic distribution across containers
CodeBuild Project - Automated container image builds

Think of security groups as your network bouncer, the load balancer as your traffic director, and CodeBuild as your automated factory worker.

Security Groups - Your Network Firewall

Security groups act like a firewall for your AWS resources. They control what traffic can come in and go out of your services.

Why Security Groups Matter

Without proper security groups, your application could be:

Exposed to unwanted traffic
Vulnerable to attacks
Unable to communicate with other services

Let's create our security group configuration:

# infra/securitygroup/sg.yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Creating Security Group for Learning Purpose'

Parameters:
  TeamNameValue:
    Type: String
    Description: TeamName Tag Value
    Default: "awslearner"
  EnvironmentValue:
    Type: String
    Description: Environment Tag Value
    Default: "dev"
  SGName:
    Type: String
    Description: Name of the Security Group
    Default: "learner-public-sg"
  VpcCidr:
    Type: String
    Default: 10.0.0.0/18
    Description: VPC CIDR range for allowed inbound traffic
  VPC:
    Type: AWS::SSM::Parameter::Value<String>
    Description: VPC ID
    Default: "/learner/vpcid"
  SSMName:
    Type: String
    Description:  SG ID
    Default: "/learner/public/sgid"

Resources:
  # Firewall rules for your containers
  ECSPublicSG:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Ref SGName
      GroupDescription: "Security group for ECS service accessible only inside VPC"
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: !Ref VpcCidr
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: !Ref VpcCidr
      SecurityGroupEgress:
        - IpProtocol: -1
          CidrIp: 0.0.0.0/0
      Tags:
        - Key: Name
          Value: !Ref SGName
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  # Saves security group ID for ECS to use
  SGSSM:
    Type: AWS::SSM::Parameter
    Properties:
      Name: !Ref SSMName
      Type: String
      Value: !Ref ECSPublicSG
      Description: "Security Group ID for ECS Fargate service"
      Tags:
        Name: !Ref SSMName
        TeamName: !Ref TeamNameValue
        Environment: !Ref EnvironmentValue

Outputs:
  ECSServiceSecurityGroupId:
    Description: Security Group ID for ECS Fargate Service
    Value: !Ref ECSPublicSG

What This Security Group Does

This configuration creates a security group that:

Allows HTTP traffic (port 80) from both VPC and internet
Allows HTTPS traffic (port 443) from within VPC
Stores the security group ID in SSM Parameter Store for other services to reference
Allows all outbound traffic for container operations

Application Load Balancer - Your Traffic Director

The Application Load Balancer distributes incoming traffic across multiple containers and handles routing based on URL paths.

# infra/alb/alb.yaml
AWSTemplateFormatVersion: "2010-09-09"
Description: "Creating Application Load Balancer for Learning Purpose"

Parameters:
  Name:
    Type: String
    Description: The name of the load balancer.
    Default: "learner-alb"
  Type:
    Type: String
    Description: The type of load balancer. The default is application
    Default: application
  Scheme:
    Type: String
    Description: The nodes of an Internet-facing load balancer have public IP addresses
    Default: internet-facing
  TeamNameValue:
    Type: String
    Description: TeamName Tag Value
    Default: "awslearner"
  EnvironmentValue:
    Type: String
    Description: Environment Tag Value
    Default: "dev"
  PublicSubnetIds:
    Type: AWS::SSM::Parameter::Value<String>
    Description: Subnet ID
    Default: "/learner/public/subnetids"
  SecurityGroup:
    Type: AWS::SSM::Parameter::Value<String>
    Description: Security Group
    Default: "/learner/public/sgid"
  VpcId:
    Type: AWS::SSM::Parameter::Value<String>
    Description: VPC ID
    Default: "/learner/vpcid"
  SSMName:
    Type: String
    Default: "/learner/target/value"

Resources:
  # Traffic distributor that spreads requests across your containers
  ApplicationLoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      LoadBalancerAttributes: 
        - Key: 'idle_timeout.timeout_seconds'
          Value: '600'
      Name: !Ref Name
      Scheme: !Ref Scheme
      SecurityGroups: 
        - !Ref SecurityGroup
      Subnets: !Split 
            - ","
            - !Ref PublicSubnetIds
      Type: !Ref Type
      Tags:
        - Key: Name
          Value: !Ref Name
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  # Group of containers that will receive traffic
  TargetGroup1:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      Name: "learner-tg"
      Port: 80
      Protocol: HTTP
      VpcId: !Ref VpcId
      TargetType: ip

  # Saves target group info for ECS service to use
  Target1SSM:
    Type: AWS::SSM::Parameter
    Properties:
      Name: !Ref SSMName
      Type: String
      Value: !Ref TargetGroup1
      Description: "Target SSM"
      Tags:
        Name: !Ref SSMName
        TeamName: !Ref TeamNameValue
        Environment: !Ref EnvironmentValue

  # Listens for incoming web requests on port 80
  MyListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    DependsOn: ApplicationLoadBalancer
    Properties:
      LoadBalancerArn: !Ref ApplicationLoadBalancer
      Port: 80
      Protocol: HTTP
      DefaultActions:
        - Type: fixed-response
          FixedResponseConfig:
            ContentType: "text/plain"
            MessageBody: "Error: Page not found. Please check the URL and try again."
            StatusCode: "404"

  # Routes API requests to your containers
  ApiListenerRule:
    Type: AWS::ElasticLoadBalancingV2::ListenerRule
    Properties:
      ListenerArn: !Ref MyListener
      Priority: 1
      Actions:
        - Type: forward
          ForwardConfig:
            TargetGroups:
              - TargetGroupArn: !Ref TargetGroup1
      Conditions:
        - Field: path-pattern
          Values:
            - "/api/*"

Load Balancer Features

This setup includes:

Smart Routing: Only /api/* requests go to containers, others get 404
SSM Integration: Stores target group ARN for ECS service to reference
Extended Timeout: 10-minute idle timeout for long-running requests
Multi-AZ: Distributes across both availability zones using subnet IDs from SSM

CodeBuild - Your Automated Factory

Note: Update the GitHubRepo parameter default value with your own repository details before deployment.

CodeBuild automatically builds your container images from your GitHub repository. The GitHub connection should already be established through the AWS Console before deploying this template.

Setting Up GitHub Connection

Before deploying CodeBuild, make sure you've connected your GitHub account in the AWS Console:

Go to CodeBuild → Settings → Source providers
Connect to GitHub and authorize AWS access
This allows CodeBuild to access your repository

# infra/codebuild/codebuild.yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: "Creating CodeBuild Project for Learning Purpose"

Parameters:
  TeamNameValue:
    Type: String
    Description: TeamName Tag Value
    Default: "awslearner"
  EnvironmentValue:
    Type: String
    Description: Environment Tag Value
    Default: "dev"
  ProjectName:
    Type: String
    Default: learner-project
  GitHubRepo:
    Type: String
    Description: "GitHub repository in format: owner/repo"
    Default: <Provide Repo Details>
  GitHubBranch:
    Type: String
    Default: feature/setup
  CodeBuildRoleName:
    Type: String
    Description: "Name of IAM role for CodeBuild"
    Default: "learner-build-role"

Resources:
  # Log storage for your build process
  CodeBuildLogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub "/aws/codebuild/${ProjectName}"
      RetentionInDays: 14  
      Tags:
        - Key: Name
          Value: !Sub "/aws/codebuild/${ProjectName}"
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  # Automated builder that creates your container images
  CodeBuildProject:
    Type: AWS::CodeBuild::Project
    Properties:
      Name: !Ref ProjectName
      ServiceRole: !Sub arn:aws:iam::${AWS::AccountId}:role/${CodeBuildRoleName}
      Artifacts:
        Type: NO_ARTIFACTS
      Environment:
        Type: LINUX_CONTAINER
        ComputeType: BUILD_GENERAL1_SMALL
        Image: aws/codebuild/standard:6.0
      Source:
        Type: GITHUB
        Location: !Sub "https://github.com/${GitHubRepo}"
        GitCloneDepth: 1
        BuildSpec: buildspec.yml
        ReportBuildStatus: true
      SourceVersion: !Ref GitHubBranch
      TimeoutInMinutes: 30
      LogsConfig:
        CloudWatchLogs:
          GroupName: !Ref CodeBuildLogGroup
          Status: ENABLED
      Tags:
        - Key: Name
          Value: !Ref ProjectName
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

Outputs:
  CodeBuildProjectName:
    Value: !Ref CodeBuildProject
    Description: "Name of the CodeBuild Project"

The Build Process (buildspec.yml)

Your buildspec.yml file defines what happens during the build:

# buildspec.yml
version: 0.2
env:
  variables:
    REPO_NAME: "learner-ecr"
    APP_NAME: "myapp"

phases:
  pre_build:
    commands:
      - echo Getting AWS account ID...
      - ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
      - echo Account ID is $ACCOUNT_ID
      - echo Logging in to Amazon ECR...
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
      - echo generating buildnumber...
      - NEW_BUILD_NUMBER=$CODEBUILD_BUILD_NUMBER
      - echo Build number value is  $NEW_BUILD_NUMBER
  build:
    commands:
      - echo Building Docker image...
      - docker build -t $APP_NAME:$NEW_BUILD_NUMBER  .
      - docker tag $APP_NAME:$NEW_BUILD_NUMBER $ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$REPO_NAME:$NEW_BUILD_NUMBER
  post_build:
    commands:
      - echo Pushing the Docker image to ECR...
      - docker push $ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$REPO_NAME:$NEW_BUILD_NUMBER 
      - echo Docker image pushed to ECR successfully
      - echo Updating SSM Parameter with new image arn
      - IMAGE_URI="$ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$REPO_NAME:$NEW_BUILD_NUMBER"
      - echo Updating SSM Parameter with image URI $IMAGE_URI
      - aws ssm put-parameter --name "/learner/imagearn/value" --value "$IMAGE_URI" --type String --overwrite --region $AWS_DEFAULT_REGION

What This Build Process Does

Gets Account Info: Retrieves AWS account ID for ECR login
ECR Authentication: Logs into your private container registry
Builds Image: Creates Docker image with unique build number
Tags Image: Properly tags for ECR repository
Pushes to ECR: Stores the built image in your registry
Updates SSM: Stores the new image URI for ECS service to use

Deployment Steps

Now let's deploy everything in the right order:

Step 1: Deploy Security Groups

aws cloudformation deploy \
  --template-file infra/securitygroup/sg.yaml \
  --stack-name AWSLearner-SG-Stack \
  --capabilities CAPABILITY_NAMED_IAM

Step 2: Deploy Application Load Balancer

aws cloudformation deploy \
  --template-file infra/alb/alb.yaml \
  --stack-name AWSLearner-ALB-Stack \
  --capabilities CAPABILITY_NAMED_IAM

Step 3: Deploy CodeBuild Project

aws cloudformation deploy \
  --template-file infra/codebuild/codebuild.yaml \
  --stack-name AWSLearner-CodeBuild-Stack \
  --capabilities CAPABILITY_NAMED_IAM

Common Issues and Solutions

Security Group Problems

Issue: Can't access load balancer
Solution: Check that port 80 is open in ALB security group

Load Balancer Health Checks Failing

Issue: Target group shows unhealthy targets
Solution: Ensure your app responds to /api/health endpoint

CodeBuild Failures

Issue: Build fails with permission errors
Solution: Verify ECR permissions in CodeBuild role

What's Next?

In Day 5, we'll:

Deploy our ECS service with auto-scaling
Connect everything together
Test the complete application flow

Key Takeaways

Today we built the security and automation foundation:

Security Groups protect your resources with firewall rules
Load Balancers distribute traffic and ensure high availability
CodeBuild automates your container image creation

These components work together to create a secure, scalable, and maintainable container platform.

The security groups ensure only authorised traffic reaches your containers, the load balancer provides high availability and health monitoring, and CodeBuild keeps your deployments automated and consistent.

Tomorrow we'll bring it all together with the ECS service deployment. Stay tuned!

This is part of my AWS learning journey. Follow along as we build a complete containerized application on AWS using Infrastructure as Code.

Previous Posts:

Day 1: VPC and Networking Setup
Day 2: Internet Gateway, Public Route Table & ECR Repository
Day 3: IAM Roles, SSM & ECS Cluster

Coming Next:

Day 5: ECS Service with Auto-Scaling

💻 About Me

Hi! I'm Utkarsh, a Cloud Specialist & AWS Community Builder who loves turning complex AWS topics into fun chai-time stories ☕

AWS VPC to ECS – Day 3: IAM Roles, SSM & ECS Cluster

Utkarsh Rastogi — Sat, 16 Aug 2025 12:08:52 +0000

What's up everyone! 👋 Welcome back to my "AWS VPC to ECS with CloudFormation" series - Day 3 is here!

So in my last blog posts, I got the networking foundation sorted with VPC and subnets. Now I'm diving into something that honestly used to give me nightmares - IAM permissions and security stuff. But you know what? Once I stopped being scared of it and actually understood what's happening, it became way less intimidating!

What I'm Tackling Today

Alright, so before I can actually run any containers, I need these three things set up:

IAM Roles - Because AWS won't let you do anything without proper permissions (and rightfully so!)
SSM Parameters - My secret weapon for managing configurations
ECS Cluster - The actual home where my containers will live

Real talk - I used to just copy IAM policies from Stack Overflow and pray they worked. Bad idea. Trust me, learn from my mistakes! 😅

Today's Architecture - What We're Building

┌─────────────────────────────────────────────────────────────────────────────────┐
│                           Day 3: Security & Orchestration                      │
│                                                                                 │
│  ┌─────────────────┐    ┌─────────────────┐    ┌─────────────────────────────┐ │
│  │   IAM Roles     │    │ SSM Parameters  │    │      ECS Cluster            │ │
│  │                 │    │                 │    │                             │ │
│  │ ┌─────────────┐ │    │ ┌─────────────┐ │    │ ┌─────────────────────────┐ │ │
│  │ │ECS Execution│ │    │ │Image ARN    │ │    │ │     Fargate Platform    │ │ │
│  │ │    Role     │ │    │ │Parameter    │ │    │ │                         │ │ │
│  │ └─────────────┘ │    │ └─────────────┘ │    │ │  ┌─────────────────────┐ │ │ │
│  │                 │    │                 │    │ │  │   Container Tasks   │ │ │ │
│  │ ┌─────────────┐ │    │ ┌─────────────┐ │    │ │  │   (Future Home)     │ │ │ │
│  │ │ECS Task     │ │    │ │Config Values│ │    │ │  └─────────────────────┘ │ │ │
│  │ │    Role     │ │    │ │(Future)     │ │    │ │                         │ │ │
│  │ └─────────────┘ │    │ └─────────────┘ │    │ │  Auto Scaling Ready     │ │ │
│  │                 │    │                 │    │ └─────────────────────────┘ │ │
│  │ ┌─────────────┐ │    │                 │    │                             │ │
│  │ │CodeBuild    │ │    │                 │    │                             │ │
│  │ │    Role     │ │    │                 │    │                             │ │
│  │ └─────────────┘ │    │                 │    │                             │ │
│  └─────────────────┘    └─────────────────┘    └─────────────────────────────┘ │
│           │                       │                           │                 │
│           └───────────────────────┼───────────────────────────┘                 │
│                                   │                                             │
│                    ┌──────────────▼──────────────┐                            │
│                    │        Secure Foundation     │                            │
│                    │     Ready for Containers    │                            │
│                    └─────────────────────────────┘                            │
└─────────────────────────────────────────────────────────────────────────────────┘

1. IAM Roles - Finally Making Peace with Permissions

Okay, confession time. IAM used to be my biggest AWS fear. All those JSON policies, trust relationships, conditions... I'd just copy-paste stuff and hope it worked. Spoiler alert: it usually didn't, and I'd spend hours debugging "Access Denied" errors.

But here's what changed everything for me - I started thinking of IAM roles like job descriptions. Each role has specific responsibilities, and AWS just wants to make sure the right "employee" is doing the right job.

Here's my complete IAM setup:

AWSTemplateFormatVersion: "2010-09-09"
Description: "Creating IAM Roles for Learning Purpose"

Parameters:
  RoleName:
    Type: String
    Description: Name of IAM Role
    Default: "learner-ecs-role"
  TaskRoleName:
    Type: String
    Description: Name of IAM Role
    Default: "learner-ecs-task-exc-role"
  BuildRoleName:
    Type: String
    Description: Name of IAM Role
    Default: "learner-build-role"
  PolicyName:
    Type: String
    Description: Name of IAM Policy
    Default: "learner-ecs-permission-policy"
  PolicyName1:
    Type: String
    Description: Name of IAM Policy
    Default: "learner-ecs-policy"
  TeamNameValue:
    Type: String
    Description: TeamName Tag Value
    Default: "awslearner"
  EnvironmentValue:
    Type: String
    Description: Environment Tag Value
    Default: "dev"

Resources:
  # Permissions for ECS to manage your containers
  ECSRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Ref RoleName
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ecs-tasks.amazonaws.com
            Action: sts:AssumeRole
      Path: /
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
      Policies:
        - PolicyName: !Ref PolicyName 
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - 'ecs:*'
                  - 'ec2:Describe*'
                  - 'elasticloadbalancing:Describe*'
                Resource: '*'
      Tags:
        - Key: Name
          Value: !Ref RoleName
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  # Permissions for containers to start and access logs
  ECSTaskExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Ref TaskRoleName
      AssumeRolePolicyDocument:
        Statement:
          - Effect: Allow
            Principal:
              Service: [ecs-tasks.amazonaws.com]
            Action: ['sts:AssumeRole']
            Condition:
              ArnLike:
                aws:SourceArn: !Sub arn:aws:ecs:${AWS::Region}:${AWS::AccountId}:*
              StringEquals:
                aws:SourceAccount: !Ref AWS::AccountId
      Path: /
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
      Policies:
        - PolicyName: !Ref PolicyName1
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - 'ecs:*'
                Resource: '*'
      Tags:
        - Key: Name
          Value: !Ref TaskRoleName
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  # Permissions for CodeBuild to build and push images
  CodeBuildRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Ref BuildRoleName
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service: codebuild.amazonaws.com
            Action: sts:AssumeRole
      Policies:
        - PolicyName: CodeBuildECRAccess
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: Allow
                Action:
                  - ecr:GetAuthorizationToken
                  - ecr:BatchCheckLayerAvailability
                  - ecr:CompleteLayerUpload
                  - ecr:InitiateLayerUpload
                  - ecr:PutImage
                  - ecr:UploadLayerPart
                Resource: "*"
              - Effect: Allow
                Action:
                  - logs:CreateLogGroup
                  - logs:CreateLogStream
                  - logs:PutLogEvents
                Resource: "*"
              - Effect: Allow
                Action:
                  - s3:GetObject
                Resource: "arn:aws:s3:::*"
              - Effect: Allow
                Action:
                  - codeconnections:*
                Resource: "*"
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AWSCodeBuildDeveloperAccess
        - arn:aws:iam::aws:policy/AmazonSSMFullAccess
      Tags:
        - Key: Name
          Value: !Ref BuildRoleName
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

Time to deploy this bad boy:

aws cloudformation deploy \
  --template-file infra/roles/iam.yaml \
  --stack-name AWSLearner-IAM-Stack \
  --capabilities CAPABILITY_NAMED_IAM

Quick heads up: That --capabilities CAPABILITY_NAMED_IAM flag is super important - CloudFormation needs your explicit permission to mess with IAM stuff. Learned that one the hard way when my first deployment just sat there doing nothing! 🤦‍♂️

2. SSM Parameters - My New Best Friend

Okay, can we talk about SSM Parameter Store for a sec? This thing has literally changed my life! No more hardcoding database URLs, API keys, or any other config values directly in my templates.

I remember my early days when I'd hardcode everything and then spend hours trying to figure out why my dev environment was hitting production databases. Yeah... not my proudest moments.

Here's my SSM setup:

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Creating SSM Parameters for Learning Purpose'

Parameters:
  TeamNameValue:
    Type: String
    Description: TeamName Tag Value
    Default: "awslearner"
  EnvironmentValue:
    Type: String
    Description: Environment Tag Value
    Default: "dev"
  SSMName:
    Type: String
    Default: "/learner/imagearn/value"

Resources:
  # Placeholder for storing your container image location
  ImageSSM:
    Type: AWS::SSM::Parameter
    Properties:
      Name: !Ref SSMName
      Type: String
      Value: '1'
      Description: "Image ARN"
      Tags:
        Name: !Ref SSMName
        TeamName: !Ref TeamNameValue
        Environment: !Ref EnvironmentValue

Why SSM Parameters Rock My World

Look, once you start using these, there's no going back:

No more secrets in code - Everything stays encrypted and secure
Change stuff without redeploying - Update a parameter, restart your service, boom!
Super organized - That hierarchical naming (/learner/imagearn/value) keeps everything neat
Plays nice with everything - Other AWS services can grab these values directly

Let's get this deployed:

aws cloudformation deploy \
  --template-file infra/ssm/ssm.yaml \
  --stack-name AWSLearner-SSM-Stack \
  --capabilities CAPABILITY_NAMED_IAM

3. ECS Cluster - The Container Playground

Now we're getting to the fun stuff! The ECS Cluster is basically the stage where all my containers are going to perform their magic. I'm going with Fargate because honestly? I don't want to deal with managing EC2 instances if I can avoid it.

Here's what I'm setting up:

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Creating ECS Cluster for Learning Purpose'

Parameters:
  TeamNameValue:
    Type: String
    Description: TeamName Tag Value
    Default: "awslearner"
  EnvironmentValue:
    Type: String
    Description: Environment Tag Value
    Default: "dev"
  ClusterName:
    Type: String
    Description: Name of the ECS Cluster
    Default: "learner-cluster"

Resources:
  # Container hosting platform where your apps will run
  ECSCluster:
    Type: AWS::ECS::Cluster
    Properties:
      ClusterName: !Ref ClusterName
      CapacityProviders:
        - FARGATE
      DefaultCapacityProviderStrategy:
        - CapacityProvider: FARGATE
          Weight: 1
      Tags:
        - Key: Name
          Value: !Ref ClusterName
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

Why Fargate is Perfect for This

Let me tell you why I'm obsessed with Fargate:

Serverless containers - I just tell AWS what I want, and they handle all the infrastructure nonsense
Scales like crazy - Traffic spike? No problem, Fargate's got my back
Secure by default - Each task gets its own little isolated bubble
Pay for what you use - Only charged for the actual compute time

Time to deploy:

aws cloudformation deploy \
  --template-file infra/cluster/cluster.yaml \
  --stack-name AWSLearner-Cluster-Stack \
  --capabilities CAPABILITY_NAMED_IAM

How These Three Play Together

Here's the cool part - these aren't just random components. They work together like a well-oiled machine:

IAM Roles are like the security guards - they make sure only the right services can access the right resources
SSM Parameters are the configuration managers - they store all the dynamic stuff our services need
ECS Cluster is the execution platform - where the actual magic happens

What's Coming Next?

In my next post (Day 4), I'm going to add the final pieces to this puzzle:

Security Groups - Network-level firewall rules
Application Load Balancer - Traffic distribution and health checks

We're getting close to actually running some containers! 🎉

My Key Takeaways

Don't be scared of IAM - Take time to understand it instead of just copying policies
SSM Parameters are life-changing - Use them for anything that might need to change
ECS Cluster setup is actually pretty simple - The complexity comes with the services and tasks

When Things Go Wrong (They Will!)

Here's what I've learned from my many failures:

IAM issues: Check the trust policy - make sure the right service can actually assume the role
SSM parameter not found: Double-check the parameter name matches exactly what you're referencing
ECS cluster stuck: Give it a few minutes - these things take time to spin up

That's Day 3 in the books! We now have a solid, secure foundation that's ready for containers. Next time, we'll add the final infrastructure pieces and get ready to deploy our actual application.

How's your AWS journey going? Ever had any epic IAM fails? Share your war stories in the comments! 👇

Up next: Day 4 - Security Groups & Load Balancer Setup

💻 About Me

Hi! I'm Utkarsh, a Cloud Specialist & AWS Community Builder who loves turning complex AWS topics into fun chai-time stories ☕

AWS VPC to ECS – Day 2: Internet Gateway, Public Route Table & ECR Repository

Utkarsh Rastogi — Sun, 10 Aug 2025 07:34:58 +0000

Welcome back to our "AWS VPC to ECS with CloudFormation" series, which is on its second day!

We constructed the VPC and subnets on Day 1, which you can catch up on here:
🔗 Day 1: AWS VPC Basics with CloudFormation

We'll set up a Elastic Container Registry (ECR) to house our container images and enable our VPC to communicate with the internet today.

📌 What We’ll Build Today

By the end of this post, you will:

Attach an Internet Gateway to your VPC
Create a Public Route Table and link it to your public subnets
Create an ECR Repository for storing Docker images

Internet Gateway (IGW)

An Internet Gateway can be thought of as the primary gateway that connects your VPC to the internet.

Without it, you're stranded on a remote island with no supplies.

AWSTemplateFormatVersion: "2010-09-09"
Description: "Creating Internet Gateway for Learning Purpose"
Parameters:
  VPC:
    Type: AWS::SSM::Parameter::Value<String>
    Description: VPC ID
    Default: "/learner/vpcid"
  TeamNameValue:
    Type: String
    Description: TeamName Tag Value
    Default: "awslearner"
  EnvironmentValue:
    Type: String
    Description: Environment Tag Value
    Default: "dev"
  SSMName:
    Type: String
    Description:  IGW
    Default: "/learner/igw"

Resources:
  InternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentValue}internetgateway
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  InternetGatewayAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    DependsOn: InternetGateway
    Properties:
      InternetGatewayId: !Ref InternetGateway
      VpcId: !Ref VPC

  SSMParameter:
    Type: "AWS::SSM::Parameter"
    DependsOn: InternetGatewayAttachment
    Properties:
      Name: !Ref SSMName
      Type: "String"
      Value: !Ref InternetGateway 
      Description: "IGW"
      Tags:
        Name: !Ref SSMName
        TeamName: !Ref TeamNameValue
        Environment: !Ref EnvironmentValue

Outputs:
  InternetGatewayDetails:
    Description: IGW Details
    Value: !Ref InternetGateway

Deployment

aws cloudformation deploy \
  --template-file internet_gateway.yaml \
  --stack-name AWSLearner-IGW-Stack \
  --capabilities CAPABILITY_NAMED_IAM

Public Route Table

The Route Table determines the path of network traffic.

To enable our public subnet to send and receive internet traffic, we will in this instance establish a Public Route Table.

A rule that routes all internet traffic (0.0.0.0/0) through our Internet Gateway (IGW) will be added.

AWSTemplateFormatVersion: '2010-09-09'
Description: 'AWS CloudFormation template to create a public route table and associate it with an internet gateway and a public subnet'

Parameters:
  VpcId:
    Type: AWS::SSM::Parameter::Value<String>
    Description: VPC ID
    Default: "/learner/vpcid"
  InternetGatewayId:
    Type: AWS::SSM::Parameter::Value<String>
    Description: ID of the Internet Gateway to associate with the route table
    Default: "/learner/igw"
  PublicSubnetId:
    Type: AWS::SSM::Parameter::Value<String>
    Description: Subnet ID to associate with the route table
    Default: "/learner/public/subnetids"
  PublicRouteTableName:
    Type: String
    Description: Name Tag Value
    Default: "awslearner-publicroutetable"
  TeamNameValue:
    Type: String
    Description: TeamName Tag Value
    Default: "awslearner"
  EnvironmentValue:
    Type: String
    Description: Environment Tag Value
    Default: "dev"

Resources:
  PublicRouteTable:
    Type: 'AWS::EC2::RouteTable'
    Properties:
      VpcId: !Ref VpcId
      Tags:
        - Key: Name
          Value: !Ref PublicRouteTableName
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  InternetGatewayRoute:
    Type: 'AWS::EC2::Route'
    DependsOn: PublicRouteTable
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGatewayId

  PublicSubnetRouteTableAssociation:
    Type: 'AWS::EC2::SubnetRouteTableAssociation'
    Properties:
      SubnetId: !Select 
        - 0
        - !Split 
          - ","
          - !Ref PublicSubnetId
      RouteTableId: !Ref PublicRouteTable

  PublicSubnetRouteTableAssociation1:
    Type: 'AWS::EC2::SubnetRouteTableAssociation'
    Properties:
      SubnetId: !Select 
        - 1
        - !Split 
          - ","
          - !Ref PublicSubnetId
      RouteTableId: !Ref PublicRouteTable

Outputs:
  RouteTableId:
    Description: The ID of the created public route table
    Value: !Ref PublicRouteTable

Deployment

aws cloudformation deploy \
  --template-file public_route_table.yaml \
  --stack-name AWSLearner-PRT-Stack \
  --capabilities CAPABILITY_NAMED_IAM

Elastic Container Registry (ECR)

Prior to deploying our Docker images to ECS, we require a location to store them.

Securely storing, managing, and deploying container images is made simple with AWS's fully-managed, private container registry, Amazon ECR (Elastic Container Registry), which works smoothly with ECS.

Why use ECR?

Private, secure storage for Docker images.
Integrates directly with ECS and IAM for permissions.
Supports image versioning and lifecycle policies.

We’ll create an ECR repository to store our application’s Docker image before deploying it to our ECS service.

AWSTemplateFormatVersion: '2010-09-09'
Description: 'AWS CloudFormation template to create  ECR Repository'

Parameters:
  TeamNameValue:
    Type: String
    Description: TeamName Tag Value
    Default: "awslearner"
  EnvironmentValue:
    Type: String
    Description: Environment Tag Value
    Default: "dev"
  RepositoryName:
    Type: String
    Description: Name of the ECR Repository
    Default: "learner-ecr"


Resources:
  MyECRRepository:
    Type: AWS::ECR::Repository
    Properties:
      RepositoryName: !Ref RepositoryName
      LifecyclePolicy:
        LifecyclePolicyText: |
          {
            "rules": [
              {
                "rulePriority": 1,
                "description": "Keep only latest 1 image",
                "selection": {
                  "tagStatus": "any",
                  "countType": "imageCountMoreThan",
                  "countNumber": 1
                },
                "action": {
                  "type": "expire"
                }
              }
            ]
          }
        RegistryId: !Ref AWS::AccountId
      Tags:
        - Key: Name
          Value: !Ref RepositoryName
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

Deployment

aws cloudformation deploy \
  --template-file ecr.yaml \
  --stack-name AWSLearner-ECR-Stack  \
  --capabilities CAPABILITY_NAMED_IAM

📝 Recap

Today, we:

For our public resources to have internet access, we set up a Public Route Table and connected it to our Internet Gateway.
We set up a Elastic Container Registry (ECR) in AWS to safely store our Docker images.

📢 Stay tuned for the next part

💡 To understand how to set up VPC → ECS step-by-step using distinct YAML files for each AWS resource, follow this series.

📬 Please remember to bookmark this blog series, share it with your cloud friends, and if you found it helpful, leave a remark 💬 and a like 👍.

Your criticism inspires me to produce more hands-on AWS content and helps me get better! 🚀

👨‍💻 About Me

Hi! I'm Utkarsh, a Cloud Specialist & AWS Community Builder who loves turning complex AWS topics into fun chai-time stories ☕

👉 Explore more

AWS VPC to ECS – Day 1: Apna VPC Banaate Hain! 😎

Utkarsh Rastogi — Sat, 09 Aug 2025 10:08:15 +0000

Namaste doston! 🙏

Aaj se hum ek CloudFormation Blog Series shuru kar rahe hain – jisme hum VPC se ECS service tak ka safar step-by-step cover karenge.

Socho jaise hum apna gali (VPC), ghar (Subnet), aur road (Route Table) bana rahe hain – taaki baad me apni gaadi (ECS) waha chal sake. 🚗

🎯 Day 1 ka Goal

Apna VPC create karna
Usme Public aur Private Subnets banana
Basic networking ka base ready karna

🧠 Thoda Theory – VPC Kya Hai?

VPC ka matlab hai Virtual Private Cloud.

Yeh AWS ka ek private area hai jaha aap apne resources (servers, databases, containers) ko rakho, aur networking rules set karo.

Think of it like – "Apni private society jaha kaun aayega, kaun jayega, sab aap decide karoge." 🏡

🗺 Architecture Samajh Lo Pehle

Day 1 ke baad humare paas yeh hoga:

VPC
├── Public Subnet (Internet se connected)
└── Private Subnet (Sirf internal access)

1️⃣ VPC Banana – `vpc.yaml`

AWSTemplateFormatVersion: "2010-09-09"
Description: "Creating VPC for Learning Purpose"

Parameters:
  CidrBlockValue:
    Type: String
    Description: The IPv4 network range for the VPC, in CIDR notation
    Default: "10.0.0.0/18"
  EnableDnsSupportValue:
    Type: String
    Description: Indicates whether the instances launched in the VPC get DNS hostnames. If enabled, instances in the VPC get DNS hostnames; otherwise, they do not. Disabled by default for nondefault VPCs.
    Default: "true"
  EnableDnsHostnamesValue:
    Type: String
    Description: Indicates whether the DNS resolution is supported for the VPC
    Default: "true"
  NameValue:
    Type: String
    Description: Name Tag Value
    Default: "awslearnervpc"
  TeamNameValue:
    Type: String
    Description: TeamName Tag Value
    Default: "awslearner"
  EnvironmentValue:
    Type: String
    Description: Environment Tag Value
    Default: "dev"
  SSMName:
    Type: String
    Description:  VPC ID
    Default: "/learner/vpcid"


Resources:
  LearnerVPC:
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: !Ref CidrBlockValue
      EnableDnsSupport: !Ref EnableDnsSupportValue
      EnableDnsHostnames: !Ref EnableDnsHostnamesValue
      Tags:
        - Key: Name
          Value: !Ref NameValue
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue


  SSMParameter:
    Type: "AWS::SSM::Parameter"
    DependsOn: LearnerVPC
    Properties:
      Name: !Ref SSMName
      Type: "String"
      Value: !Ref LearnerVPC 
      Description: "VPC"
      Tags:
        Name: !Ref SSMName
        TeamName: !Ref TeamNameValue
        Environment: !Ref EnvironmentValue

Outputs:
  VPCId:
    Description: The ID of the VPC
    Value: !Ref LearnerVPC

🚀 Deployment

aws cloudformation deploy \
  --template-file vpc.yaml \
  --stack-name AWSLearner-VPC-Stack \
  --capabilities CAPABILITY_NAMED_IAM

2️⃣ Public Subnet Banana – `public_subnet.yaml`

AWSTemplateFormatVersion: "2010-09-09"
Description: "Creating Public Subnet for Learning Purpose"

Parameters:
  VPC:
    Type: AWS::SSM::Parameter::Value<String>
    Description: VPC ID
    Default: "/learner/vpcid"
  TeamNameValue:
    Type: String
    Description: TeamName Tag Value
    Default: "awslearner"
  EnvironmentValue:
    Type: String
    Description: Environment Tag Value
    Default: "dev"
  PublicSubnet1CIDR:
    Type: String
    Description: PublicSubnet1A IP Range
    Default: "10.0.0.0/24"
  PublicSubnet2CIDR:
    Type: String
    Description: PublicSubnet1B IP Range
    Default: "10.0.1.0/24"
  SSMName:
    Type: String
    Description:  VPC ID
    Default: "/learner/public/subnetids"


Resources:
  PublicSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      AvailabilityZone: !Select [ 0, !GetAZs '' ]
      CidrBlock: !Ref PublicSubnet1CIDR
      MapPublicIpOnLaunch: true
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentValue}PublicSubnet(AZ1)
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  PublicSubnet2:
    Type: AWS::EC2::Subnet
    DependsOn: PublicSubnet1
    Properties:
      VpcId: !Ref VPC
      AvailabilityZone: !Select [ 1, !GetAZs '' ]
      CidrBlock: !Ref PublicSubnet2CIDR
      MapPublicIpOnLaunch: true
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentValue}PublicSubnet(AZ2)
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  SSMParameter:
    Type: "AWS::SSM::Parameter"
    DependsOn: PublicSubnet2
    Properties:
      Name: !Ref SSMName
      Type: "StringList"
      Value: !Join [ ",", [ !Ref PublicSubnet1, !Ref PublicSubnet2 ]]
      Description: "VPC"
      Tags:
        Name: !Ref SSMName
        TeamName: !Ref TeamNameValue
        Environment: !Ref EnvironmentValue

Outputs:
  PublicSubnets:
    Description: A list of the public subnets
    Value: !Join [ ",", [ !Ref PublicSubnet1, !Ref PublicSubnet2 ]]

🚀 Deployment

aws cloudformation deploy \
  --template-file public_subnet.yaml \
  --stack-name AWSLearner-PublicSubnet-Stack \
  --capabilities CAPABILITY_NAMED_IAM

3️⃣ Private Subnet Banana – `private_subnet.yaml`

AWSTemplateFormatVersion: "2010-09-09"
Description: "Creating Private Subnet for Learning Purpose"
Parameters:
  VPC:
    Type: AWS::SSM::Parameter::Value<String>
    Description: VPC ID
    Default: "/learner/vpcid"
  TeamNameValue:
    Type: String
    Description: TeamName Tag Value
    Default: "awslearner"
  EnvironmentValue:
    Type: String
    Description: Environment Tag Value
    Default: "dev"
  PrivateSubnet1CIDR:
    Type: String
    Description: PublicSubnet1A IP Range
    Default: "10.0.20.0/20"
  PrivateSubnet2CIDR:
    Type: String
    Description: PublicSubnet1B IP Range
    Default: "10.0.32.0/20"
  SSMName:
    Type: String
    Description:  VPC ID
    Default: "/learner/private/subnetids"


Resources:
  PrivateSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      AvailabilityZone: !Select [ 0, !GetAZs '' ]
      CidrBlock: !Ref PrivateSubnet1CIDR
      MapPublicIpOnLaunch: false
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentValue}PrivateSubnet(AZ1)
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  PrivateSubnet2:
    Type: AWS::EC2::Subnet
    DependsOn: PrivateSubnet1
    Properties:
      VpcId: !Ref VPC
      AvailabilityZone: !Select [ 1, !GetAZs '' ]
      CidrBlock: !Ref PrivateSubnet2CIDR
      MapPublicIpOnLaunch: false
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentValue}PrivateSubnet(AZ2)
        - Key: TeamName
          Value: !Ref TeamNameValue
        - Key: Environment
          Value: !Ref EnvironmentValue

  SSMParameter:
    Type: "AWS::SSM::Parameter"
    DependsOn: PrivateSubnet2
    Properties:
      Name: !Ref SSMName
      Type: "StringList"
      Value: !Join [ ",", [ !Ref PrivateSubnet1, !Ref PrivateSubnet2 ]]
      Description: "VPC"
      Tags:
        Name: !Ref SSMName
        TeamName: !Ref TeamNameValue
        Environment: !Ref EnvironmentValue

Outputs:
  PrivateSubnets:
    Description: A list of the private subnets
    Value: !Join [ ",", [ !Ref PrivateSubnet1, !Ref PrivateSubnet2 ]]

🚀 Deployment

aws cloudformation deploy \
  --template-file private_subnet.yaml \
  --stack-name AWSLearner-PrivateSubnet-Stack \
  --capabilities CAPABILITY_NAMED_IAM

📝 Recap so far

By now, we have:

1️⃣ VPC – Our gated community 🏡 (everything will live here).
2️⃣ Public Subnet – The gali ka open plot 🏞 (open to the world).
3️⃣ Private Subnet – The secret mango farm 🥭 (safe from the world).

✅ Network foundation is ready! 🎯
We are just warming up — the real ECS magic is coming soon. 🛠

📢 Stay tuned for the next part

💡 Follow this series if you want to learn VPC → ECS setup step-by-step using separate YAML files for each AWS resource.

📬 Make sure to bookmark this blog and share it with your cloud buddies — let’s build this together!

👨‍💻 About Me

Hi! I'm Utkarsh, a Cloud Specialist & AWS Community Builder who loves turning complex AWS topics into fun chai-time stories ☕

👉 Explore more

AWS WebSocket Wonders – Part 2: Build & Test a WebSocket API

Utkarsh Rastogi — Sun, 03 Aug 2025 15:00:55 +0000

In Part 1, we learned what WebSocket APIs are and why they’re awesome for real-time apps.

In Part 2, we’ll deploy our WebSocket API using separate CloudFormation templates for IAM, Lambda, and API Gateway — and then test it in Postman. 🚀

🧠 Why Modular Templates?

Splitting CloudFormation into multiple templates:

Keeps code clean and manageable
Lets teams work on different stacks independently
Makes redeployment faster
Improves reusability for future projects

1️⃣ IAM Role Template – `iam.yaml`

AWSTemplateFormatVersion: 2010-09-09
Description: IAM Role for WebSocket Lambdas

Parameters:
  LambdaRoleName:
    Type: String
    Default: WebSocketLambdaExecutionRole
    Description: Lambda role


Resources:
  LambdaExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Ref LambdaRoleName
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: sts:AssumeRole
      Policies:
        - PolicyName: LambdaLogsPolicys
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: Allow
                Action:
                  - logs:CreateLogGroup
                  - logs:CreateLogStream
                  - logs:PutLogEvents
                Resource: "*"
      Tags:
        - Key: Project
          Value: WebSocketAPI
        - Key: Owner
          Value: Utkarsh

Outputs:
  LambdaExecutionRoleArn:
    Description: ARN of the Lambda Execution Role
    Value: !GetAtt LambdaExecutionRole.Arn
    Export:
      Name: LambdaExecutionRoleArn

2️⃣ Lambda Functions Template – `lambda.yaml`

AWSTemplateFormatVersion: 2010-09-09
Description: Lambda functions for WebSocket API with Tags and CloudWatch Log Groups

Parameters:
  LambdaRoleName:
    Type: String
    Default: WebSocketLambdaExecutionRole
    Description: ARN of IAM Role for Lambdas

Resources:
  ########################
  # LAMBDA FUNCTIONS
  ########################
  OnConnectFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: OnConnectFunction
      Handler: index.lambda_handler
      Role: !Sub arn:aws:iam::${AWS::AccountId}:role/${LambdaRoleName}
      Runtime: python3.12
      Code:
        ZipFile: |
          def lambda_handler(event, context):
              print("Client connected:", event["requestContext"]["connectionId"])
              return {"statusCode": 200}
      Tags:
        - Key: Project
          Value: WebSocketAPI
        - Key: Owner
          Value: Utkarsh

  OnDisconnectFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: OnDisconnectFunction
      Handler: index.lambda_handler
      Role: !Sub arn:aws:iam::${AWS::AccountId}:role/${LambdaRoleName}
      Runtime: python3.12
      Code:
        ZipFile: |
          def lambda_handler(event, context):
              print("Client disconnected:", event["requestContext"]["connectionId"])
              return {"statusCode": 200}
      Tags:
        - Key: Project
          Value: WebSocketAPI
        - Key: Owner
          Value: Utkarsh

  SendMessageFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: SendMessageFunction
      Handler: index.lambda_handler
      Role: !Sub arn:aws:iam::${AWS::AccountId}:role/${LambdaRoleName}
      Runtime: python3.12
      Code:
        ZipFile: |
          import json
          def lambda_handler(event, context):
              body = json.loads(event["body"])
              print("Message received:", body)
              return {"statusCode": 200}
      Tags:
        - Key: Project
          Value: WebSocketAPI
        - Key: Owner
          Value: Utkarsh



  ########################
  # CLOUDWATCH LOG GROUPS
  ########################
  OnConnectLogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub /aws/lambda/${OnConnectFunction}
      RetentionInDays: 14
      Tags:
        - Key: Project
          Value: WebSocketAPI
        - Key: Owner
          Value: Utkarsh

  OnDisconnectLogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub /aws/lambda/${OnDisconnectFunction}
      RetentionInDays: 14
      Tags:
        - Key: Project
          Value: WebSocketAPI
        - Key: Owner
          Value: Utkarsh

  SendMessageLogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub /aws/lambda/${SendMessageFunction}
      RetentionInDays: 14
      Tags:
        - Key: Project
          Value: WebSocketAPI
        - Key: Owner
          Value: Utkarsh

Outputs:
  OnConnectFunctionArn:
    Value: !GetAtt OnConnectFunction.Arn
    Export:
      Name: OnConnectFunctionArn

  OnDisconnectFunctionArn:
    Value: !GetAtt OnDisconnectFunction.Arn
    Export:
      Name: OnDisconnectFunctionArn

  SendMessageFunctionArn:
    Value: !GetAtt SendMessageFunction.Arn
    Export:
      Name: SendMessageFunctionArn

3️⃣ API Gateway WebSocket Template – `apigateway.yaml`

AWSTemplateFormatVersion: 2010-09-09
Description: API Gateway WebSocket API with Lambda integrations, Tags, and CloudWatch logging

Parameters:
  OnConnectFunctionName:
    Type: String
    Default: OnConnectFunction
    Description: OnConnect Lambda
  OnDisconnectFunctionName:
    Type: String
    Default: OnDisconnectFunction
    Description: OnDisconnect Lambda
  SendMessageFunctionName:
    Type: String
    Default: SendMessageFunction
    Description: SendMessage Lambda

Resources:
  ########################
  # API GATEWAY - WEBSOCKET API
  ########################
  ChatWebSocketAPI:
    Type: AWS::ApiGatewayV2::Api
    Properties:
      Name: ChatWebSocketAPI
      ProtocolType: WEBSOCKET
      RouteSelectionExpression: "$request.body.action"
      Tags:
        Project: WebSocketAPI
        Owner: Utkarsh

  ########################
  # INTEGRATIONS
  ########################
  ConnectIntegration:
    Type: AWS::ApiGatewayV2::Integration
    Properties:
      ApiId: !Ref ChatWebSocketAPI
      IntegrationType: AWS_PROXY
      IntegrationUri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${OnConnectFunctionName}/invocations

  DisconnectIntegration:
    Type: AWS::ApiGatewayV2::Integration
    Properties:
      ApiId: !Ref ChatWebSocketAPI
      IntegrationType: AWS_PROXY
      IntegrationUri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${OnDisconnectFunctionName}/invocations

  SendMessageIntegration:
    Type: AWS::ApiGatewayV2::Integration
    Properties:
      ApiId: !Ref ChatWebSocketAPI
      IntegrationType: AWS_PROXY
      IntegrationUri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${SendMessageFunctionName}/invocations

  ########################
  # ROUTES
  ########################
  ConnectRoute:
    Type: AWS::ApiGatewayV2::Route
    Properties:
      ApiId: !Ref ChatWebSocketAPI
      RouteKey: $connect
      AuthorizationType: NONE
      Target: !Join ["/", ["integrations", !Ref ConnectIntegration]]

  DisconnectRoute:
    Type: AWS::ApiGatewayV2::Route
    Properties:
      ApiId: !Ref ChatWebSocketAPI
      RouteKey: $disconnect
      AuthorizationType: NONE
      Target: !Join ["/", ["integrations", !Ref DisconnectIntegration]]

  SendMessageRoute:
    Type: AWS::ApiGatewayV2::Route
    Properties:
      ApiId: !Ref ChatWebSocketAPI
      RouteKey: sendmessage
      AuthorizationType: NONE
      Target: !Join ["/", ["integrations", !Ref SendMessageIntegration]]

  ########################
  # PERMISSIONS
  ########################
  ConnectLambdaPermission:
    Type: AWS::Lambda::Permission
    Properties:
      Action: lambda:InvokeFunction
      FunctionName: !Sub arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${OnConnectFunctionName}
      Principal: apigateway.amazonaws.com

  DisconnectLambdaPermission:
    Type: AWS::Lambda::Permission
    Properties:
      Action: lambda:InvokeFunction
      FunctionName: !Sub arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${OnDisconnectFunctionName}
      Principal: apigateway.amazonaws.com

  SendMessageLambdaPermission:
    Type: AWS::Lambda::Permission
    Properties:
      Action: lambda:InvokeFunction
      FunctionName: !Sub arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${SendMessageFunctionName}
      Principal: apigateway.amazonaws.com

  ########################
  # DEPLOYMENT + STAGE
  ########################
  WebSocketDeployment:
    Type: AWS::ApiGatewayV2::Deployment
    Properties:
      ApiId: !Ref ChatWebSocketAPI
    DependsOn:
      - ConnectRoute
      - DisconnectRoute
      - SendMessageRoute

  DevStage:
    Type: AWS::ApiGatewayV2::Stage
    Properties:
      StageName: dev
      ApiId: !Ref ChatWebSocketAPI
      DeploymentId: !Ref WebSocketDeployment
      AccessLogSettings:
        DestinationArn: !GetAtt ApiGatewayLogGroup.Arn
        Format: '{"requestId":"$context.requestId","ip":"$context.identity.sourceIp","routeKey":"$context.routeKey","status":"$context.status","connectionId":"$context.connectionId"}'
      Tags:
        Project: WebSocketAPI
        Owner: Utkarsh

  ########################
  # API GATEWAY LOG GROUP
  ########################
  ApiGatewayLogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub /aws/apigateway/${ChatWebSocketAPI}-dev
      RetentionInDays: 14
      Tags:
        - Key: Project
          Value: WebSocketAPI
        - Key: Owner
          Value: Utkarsh

Outputs:
  WebSocketURL:
    Description: WebSocket connection URL
    Value: !Sub wss://${ChatWebSocketAPI}.execute-api.${AWS::Region}.amazonaws.com/dev

🚀 Deploy in 3 Steps

Note: Make sure you have the AWS CLI installed and configured with appropriate credentials (aws configure) before running these commands.

Step 1: Deploy IAM Role

aws cloudformation deploy --template-file iam.yaml --stack-name WebSocket-IAM-Stack --capabilities CAPABILITY_NAMED_IAM

Step 2: Deploy Lambda Functions

aws cloudformation deploy --template-file lambda.yaml --stack-name WebSocket-Lambda-Stack --capabilities CAPABILITY_NAMED_IAM

Step 3: Deploy API Gateway WebSocket API

aws cloudformation deploy --template-file apigateway.yaml --stack-name WebSocket-APIGateway-Stack --capabilities CAPABILITY_NAMED_IAM

🧪 Test with Postman

Once the deployment is complete, you can test your WebSocket API using Postman.

1️⃣ Connect to WebSocket API

Open Postman and create a new request.
Change the request type to WebSocket (dropdown to the left of the URL bar).
In the URL field, paste your WebSocket endpoint from the CloudFormation output:
```
wss://<API_ID>.execute-api.<REGION>.amazonaws.com/dev
```
Click Connect

✅ This triggers the OnConnectFunction Lambda. Check CloudWatch Logs for a Client connected message.

2️⃣ Send a Message

In the WebSocket message box, paste:

{
  "action": "sendmessage",
  "message": "Welcome To WebSocket Learning!"
}

2.Click Send

✅ This triggers the SendMessageFunction Lambda. Check CloudWatch Logs.

3️⃣ Disconnect

In Postman, click Disconnect in the WebSocket tab.
✅ This triggers the OnDisconnectFunction Lambda.
Check CloudWatch Logs

📜 Summary

In this part, we:

Deployed an AWS WebSocket API using three separate CloudFormation templates:
- IAM Role (iam.yaml)
- Lambda Functions (lambda.yaml)
- API Gateway WebSocket (apigateway.yaml)
Connected to the WebSocket API using Postman
Triggered and verified:
- $connect → OnConnectFunction
- sendmessage → SendMessageFunction
- $disconnect → OnDisconnectFunction
Viewed CloudWatch Logs to confirm each Lambda executed successfully

With this modular approach, you now have a fully functional real-time WebSocket API ready to extend.

💡 Coming in Part 3:

We’ll integrate DynamoDB to store chat messages and update the SendMessageFunction to broadcast messages to all connected clients for a complete real-time chat experience.

👨‍💻 About Me

Hi! I'm Utkarsh, a Cloud Specialist & AWS Community Builder who loves turning complex AWS topics into fun chai-time stories ☕

👉 Explore more

📡 WebSocket API in AWS API Gateway – Real-time Magic Explained

Utkarsh Rastogi — Sat, 02 Aug 2025 11:22:58 +0000

Namaste Developers! 🙏
Are you fed up with polling APIs every few seconds? Desire real-time updates similar to those glitzy chat programs?
WebSocket APIs in AWS API Gateway are here to save the day — desi style. 🌶️

🧠 What is a WebSocket API?

Using a WebSocket API in Amazon API Gateway is similar to communicating with your backend in both directions. In contrast to the typical request-response paradigm (such as REST), in this case *the client and server are free to communicate at any time! *

Imagine:

A friend keeps messaging you only after you poke them (REST 😅)
Another friend can ping you anytime with updates — that’s WebSocket!

🧪 Why Use WebSockets?

✅ Real-time communication
✅ No need to poll every few seconds
✅ Reduced latency
✅ Backend can push data to clients
✅ Scalable with AWS Lambda and other services

💡 Use Cases (Made in India Style 😄)

Use Case	Example
💬 Chat App	Real-time messaging like WhatsApp
📊 Financial App	Live stock price updates
🕹️ Game Server	Multiplayer games like Ludo King
🧑‍🤝‍🧑 Collaboration	Real-time whiteboards or Google Docs
📡 IoT Devices	Smart home device updates

🔁 REST vs WebSocket: Table of Truth

Feature	REST API	WebSocket API
Communication	One-way (Client → Server)	Two-way (Client ⇄ Server)
Latency	Higher (polling)	Lower (push-based)
Real-time	❌	✅
Connection	New connection every time	Persistent connection
Protocol	HTTP	ws / wss

🏗️ WebSocket API Components in API Gateway

Let’s simplify the AWS docs:

Routes → Think of them as message types ($connect, $disconnect, custom ones like sendmessage)
Integrations → Backend Lambda, HTTP, or AWS service that handles route logic
Connection ID → Unique ID for each client connection, like a WhatsApp contact

🔄 WebSocket API Lifecycle

Client connects → $connect route triggers a Lambda
Client sends a message → Route like sendmessage triggers another Lambda
Backend responds → Can use callback URL to push messages back to client
Client disconnects → $disconnect route triggers clean-up Lambda

🧱 How to Create One? (Teaser)

In the next post, I will show how to create a WebSocket API using:

API Gateway
AWS Lambda
DynamoDB for chat persistence
Postman for testing
Bonus: CloudFormation version 🎯

📚 Blog Series Roadmap: Real-Time Chat App using AWS WebSocket API

Blog	Topic
✅ Part 1	Intro to WebSocket API in API Gateway (This Post)

🧩 Summary

WebSocket API in API Gateway brings real-time capabilities to your app — effortlessly. Whether you’re building the next chatting app, stock dashboard, or a Ludo room — this is the tech you need.

🛎️ Stay tuned for Part 2 where we start building our real-time chat app using WebSockets, Lambda & DynamoDB.

👨‍💻 About Me

Hi! I'm Utkarsh, a Cloud Specialist & AWS Community Builder who loves turning complex AWS topics into fun chai-time stories ☕

👉 Explore more