DEV Community: Utkarsh Rastogi

Tracking AWS KMS Costs by Service — When Cost Explorer Can't Help

Utkarsh Rastogi — Mon, 13 Jul 2026 04:13:29 +0000

Why KMS Costs Are Hard to Track

Every AWS account that uses encryption is paying for KMS. If you're using S3 with SSE-KMS, EBS encrypted volumes, RDS encryption, Lambda environment variables, DynamoDB with KMS keys — you're making KMS API calls. Every Encrypt, Decrypt, and GenerateDataKey call costs $0.03 per 10,000 (after a free tier of 20,000 requests/month).

That sounds small. But it adds up fast when your services make millions of these calls per day without you realizing it. AWS-managed keys don't have the $1/month storage fee that customer-managed keys do — so the entire cost is purely from API calls. And those calls are invisible unless you go looking.

The real problem isn't the cost itself — it's that you can't see WHERE it's coming from.

AWS Cost Explorer shows you one line item: "KMS: $X." You can see total API request charges, but you can't break it down by key, by caller, or by which service generated the calls. There's no way to tell if it's your S3 buckets, your EBS volumes, your Lambda functions, or your RDS instances.

And here's the catch: AWS-managed KMS keys (aws/s3, aws/ebs, aws/rds) cannot be tagged. This is confirmed in AWS docs — "You cannot tag AWS managed keys, AWS owned keys, or KMS keys in other AWS accounts." These keys are shared across all services of that type in your account and region. So even if you're good at tagging everything else, KMS keys remain a black box.

What Makes This Different from Cost Explorer or CloudWatch

So what already exists and why didn't it work?

Cost Explorer shows aggregate KMS spend per account. Can't break down by key, by caller, by service, or by resource. You know you spent $X but not why.

CloudWatch Metrics — KMS doesn't publish per-key call count metrics. There's no built-in dashboard that shows "this key got called 5M times today by this role."

AWS Cost Anomaly Detection is great for catching sudden account-wide spikes. But it doesn't tell you which specific S3 bucket or Lambda function is the culprit. It works at the billing level, not the API call level.

Tagging works for customer-managed keys. Doesn't work for aws-managed keys. If most of your KMS cost comes from aws/s3 or aws/ebs keys (which is common), tags won't help.

CloudTrail manually — yes, CloudTrail logs every KMS call with full context. But have you tried querying CloudTrail logs with Athena to find who called what key how many times? It's doable but painful. You'd need to set up partitions, write Presto queries, and do it regularly. I tried this first and gave up after the third time.

This project automates all of that. Real-time processing, automatic aggregation, daily email with the answer.

The Core Idea

CloudTrail logs contain everything you need. Each log entry tells you:

Which KMS key was used (even aws-managed keys)
Which IAM role made the call
The encryption context (S3 bucket ARN, EBS volume ID, table name)
The API action (Encrypt, Decrypt, GenerateDataKey)
Timestamp

From one record you can map: aws/s3 key + data-lake-role + arn:aws:s3:::my-bucket/file.json = "this bucket is generating KMS calls through this role."

The problem is volume. A busy account generates millions of these per day. You can't grep through them. You need something that processes them as they arrive, counts the calls, and gives you a summary.

How the System Works

Real-time Processing

CloudTrail delivers KMS events to CloudWatch Logs. A subscription filter pushes these events to a Lambda function in real-time (within seconds of the API call).

The Lambda (Aggregator) does:

Decode the CloudWatch Logs payload (base64 + gzip)
Parse each CloudTrail record
Extract: which key, which caller, which action, which resource, what hour
Group identical calls (same key + same caller + same action + same hour)
Save an atomic counter to DynamoDB using UpdateItem ADD

This means DynamoDB always has the current count. No batch jobs, no waiting until end of day.

Spike Detection

The Aggregator also watches for unusual volume. After each save, DynamoDB returns the new hourly total. If it crosses a configured threshold (e.g., 500 calls in one hour for a single key+caller), it sends an alert immediately via SES.

This catches runaway services the same day they're deployed, not next month on the bill.

To prevent alert fatigue, there's a 24-hour cooldown. If the same key+caller triggers a spike, you only get one alert per day. The cooldown state is stored in DynamoDB with TTL so it cleans itself up.

Daily Report

Every morning at 8 AM UTC, a second Lambda (Reporter) runs:

Queries DynamoDB for yesterday's data using a GSI (efficient, no table scan)
Builds stats: total calls, cost, per-key breakdown, top callers
Compares with the previous day (day-over-day change, who increased the most)
Calculates hourly heatmap (which hour was busiest)
Groups costs by AWS service (S3 vs Lambda vs DynamoDB vs EBS)
Calls Bedrock Nova Lite for AI-powered recommendations
Sends an HTML email with a CSV attachment via SES

The AI recommendations are short and specific. They reference actual keys and callers from your data. If your cost is low, it just says "usage is low, no action needed" instead of giving generic advice.

Weekly Summary

Every Monday, the system also sends a weekly summary:

7-day daily breakdown (calls and cost per day)
Peak day highlighted
Week-over-week comparison (this week vs last week, percentage change)

This helps you see trends that don't show up in a single day's report.

Cost Threshold Alert

If the daily cost exceeds a configured threshold, a separate alert fires. This is different from the spike alert (spike = one key going crazy, cost alert = total daily spend too high).

What the Daily Email Contains

The email has:

Header: day name, date, region, time range
Summary cards: total calls, daily cost, projected monthly cost, number of keys used
Day-over-day comparison: yesterday vs today, percentage change, who moved the most
By service: pills showing S3: X calls, Lambda: Y calls, DynamoDB: Z calls
Top actions: breakdown of Encrypt vs Decrypt vs GenerateDataKey (tells you if it's read-heavy or write-heavy)
Peak hour: busiest hour of the day
Top keys table: key name, total calls, cost, top caller for each key
AI recommendations: 2-3 specific actions with expected savings
CSV attachment: full data for anyone who wants to dig deeper in Excel

It's designed to be scannable in 30 seconds. You open the email, see the numbers, check if anything spiked, and move on.

Common Culprits This System Finds

From my experience and what the reports surface:

S3 buckets without Bucket Keys — This is the biggest one. Without Bucket Keys, every PutObject and GetObject makes its own KMS call. A bucket with 1M objects accessed daily = 1M KMS calls = $3/day just for that bucket. Enable Bucket Keys and it drops to ~100 calls/day regardless of object count.

Lambda functions decrypting environment variables — Every cold start decrypts encrypted env vars. High-concurrency Lambdas with short execution times can generate thousands of Decrypt calls per hour.

DynamoDB with SSE-KMS — If you chose "AWS managed key" or "Customer managed key" for encryption, every read/write makes a KMS call. Switching to "AWS owned key" (the default for new tables) eliminates this entirely — and it's free.

High-IOPS EBS volumes — Every I/O operation on an encrypted EBS volume involves KMS. High-IOPS workloads (io2, gp3 with high IOPS) can generate millions of calls. Not much you can fix here except being aware of the cost.

Secrets Manager rotation — Frequent secret access or rotation generates Decrypt calls. Usually not expensive but shows up in the report.

Architecture

CloudTrail (KMS data events)
      |
      v
CloudWatch Logs
      |
      v
Subscription Filter (kms.amazonaws.com only)
      |
      v
Aggregator Lambda (real-time)
  - Counts per key/caller/hour
  - Saves to DynamoDB (atomic counters)
  - Spike detection with 24h cooldown
  - Alerts via SES
      |
      v
DynamoDB (90-day TTL, date-index GSI)
      |
      v (daily 8 AM via EventBridge)
Reporter Lambda
  - Queries yesterday's data (GSI, no scan)
  - Day-over-day comparison
  - Bedrock AI recommendations
  - HTML email + CSV via SES
  - Cost threshold alerts
  - Weekly summary (Mondays)
      |
      v
SES (all emails) + CloudWatch Dashboard

Tech Decisions and Tradeoffs

CloudWatch subscription filter vs Athena queries — Real-time processing means I get spike alerts immediately. Athena would require scheduled queries and adds cost for scanning.

DynamoDB with atomic counters vs raw event storage — Storing every CloudTrail record would cost a fortune in storage. Aggregating per key/caller/hour means the table stays small (thousands of records vs millions).

GSI for daily queries — The Reporter needs all records for one day. Without a GSI, you'd scan the entire table. The reportDate GSI makes this a single efficient Query.

SES over SNS — SNS adds an unsubscribe footer to every email. SES gives full control over formatting. Both Lambdas use SES directly.

Content-hash deploys — Lambda code is zipped with an MD5 hash in the S3 key. Same code = same hash = CloudFormation skips the update. Prevents unnecessary cold starts when only infra changes.

24-hour spike cooldown — Without cooldown, a sustained spike generates an alert every few minutes. The cooldown uses DynamoDB records with TTL so they auto-delete.

Self-call filtering — The system itself makes KMS calls (DynamoDB encryption, Lambda env var decryption). These are filtered out at both the aggregator level (skip saving) and reporter level (skip displaying).

What It Costs to Run

Component	Monthly Cost	Why
CloudTrail KMS data events	~$60	$2 per 100K events. Scales with your KMS call volume
S3 (CloudTrail log storage)	~$2	14-day lifecycle, auto-deletes old logs
Lambda - Aggregator	~$2	Runs per CloudTrail batch, 256MB, ~60ms per invocation
Lambda - Reporter	~$0	Runs once daily, 256MB, ~3s per invocation
DynamoDB (on-demand)	~$1	Pay per read/write. 90-day TTL auto-deletes old records
Bedrock Nova Lite	~$0	1 call/day, ~500 input tokens, ~150 output tokens
SES	~$0	Free tier covers 62K emails/month
CloudWatch Dashboard	$3	Fixed cost per dashboard
CloudWatch Logs	~$1	7-day retention on Lambda logs
Total	~$69/month

The biggest variable is CloudTrail. If your account makes 100M KMS calls/month, CloudTrail data events cost ~$60. If you make 10M calls, it's ~$6. The rest stays constant regardless of volume.

Time to Build

Infrastructure (8 CloudFormation stacks): designed and deployed in a day
Aggregator Lambda: the parsing and DynamoDB logic took a few hours
Reporter Lambda: email formatting, AI integration, weekly summary took longer
Testing and edge cases: caller identification, reserved keywords, self-call filtering

What You Get for $69/month

Real-time spike alerts (catch runaway services same day)
Daily cost attribution (know exactly which service uses which key)
AI recommendations (specific, actionable fixes)
Weekly trends (is cost going up or down)
Cost threshold alerts (get notified before the bill surprises you)
CSV data for auditing or sharing with your team

The ROI

The system finds savings you can't find any other way. Common fixes:

Enable S3 Bucket Keys: can save $10-50/day per bucket
Switch DynamoDB from SSE-KMS to AWS-owned: saves the entire DynamoDB KMS cost
Identify unused encrypted resources still generating calls

If your KMS bill is over $200/month, this system will likely pay for itself in the first week by identifying one fix. If your bill is under $50/month, it's probably not worth running.

AWS Free Tier

Some of these services have free tier:

Lambda: 1M requests/month free (more than enough)
DynamoDB: 25 read/write capacity units free
SES: 62K emails/month free
CloudWatch: 10 custom metrics free

In practice, the only real cost is CloudTrail data events. Everything else is either free tier or under $5/month.

Deploy and Test

git clone <repo>
cd ai-kms-sentinel
cp .env.example .env
# Edit: SENDER_EMAIL, RECIPIENT_EMAIL

./deploy.sh all           # 8 CloudFormation stacks
./test-kms.sh all         # Generate test KMS calls
# Wait 10-15 minutes for CloudTrail
./test-report.sh status   # Check if data arrived
./test-report.sh today    # Trigger report

One command to deploy. One command to destroy. Everything is infrastructure-as-code.

When You Don't Need This

If your KMS bill is under $10/month — not worth the CloudTrail cost
If you only use customer-managed keys with proper tags — Cost Explorer allocation tags work fine
If you have a single service using KMS — you already know where the cost is

This system is for accounts where multiple services share aws-managed keys and you can't tell from the bill who's responsible for what.

What's Next

Slack integration for spike alerts and multi-account aggregation are on the list. But for now, daily email + real-time spikes covers 90% of what I need.

Do You Even Have This Problem?

Before building anything, check if KMS is actually costing you money. Run this:

aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics BlendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["AWS Key Management Service"]}}' \
  --query 'ResultsByTime[0].Total.BlendedCost.Amount' \
  --output text

If it returns under $10, you probably don't need this. If it returns $50+ and you don't know why, keep reading.

You can also check in the AWS Console: Billing > Cost Explorer > filter by Service = "AWS Key Management Service" > group by Usage Type. You'll see "KMS-Requests" as one big number with no further breakdown.

S3 Bucket Keys: The #1 Fix

If you take nothing else from this post, remember this.

When you upload an object to an encrypted S3 bucket (SSE-KMS), S3 normally makes a separate KMS GenerateDataKey call for every single object. Upload 1 million objects per day = 1 million KMS calls = $3/day just for that one bucket. I didn't believe this until I saw it in the data.

S3 Bucket Keys fix this. When enabled, S3 generates a bucket-level key from KMS and reuses it for multiple objects. Instead of 1 call per object, it makes roughly 1 call per few minutes regardless of how many objects you upload.

1M objects/day without Bucket Keys: 1M KMS calls ($3/day).
1M objects/day with Bucket Keys: ~100 KMS calls ($0.0003/day).

That's not a typo. 99.99% reduction.

To enable it:

aws s3api put-bucket-encryption \
  --bucket your-bucket-name \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms"
      },
      "BucketKeyEnabled": true
    }]
  }'

Or in the console: S3 > Bucket > Properties > Default encryption > Edit > Enable Bucket Key.

This only affects new objects. Existing ones still use the old key style. But for high-write buckets, the savings start on day one.

The daily report identifies these buckets automatically — when it sees aws/s3 getting millions of calls from one role, the AI recommendation tells you which bucket to fix.

Before and After

Without this system:

You get the monthly bill. It says KMS: $X. You open Cost Explorer, see one line item, shrug, and move on. Maybe you spend 30 minutes in CloudTrail once, get overwhelmed by the volume, and give up. Repeat next month.

With this system:

8 AM email: "aws/s3 key: 12M calls from data-lake-role, resource: data-lake-raw bucket."

You know exactly what's happening. Enable Bucket Keys on that bucket. Next day's report shows calls dropped by 99%. Done. Move on to the next biggest key.

The difference is attribution. "KMS costs $58/day" is not actionable. "Your data-lake-raw bucket is generating 12M calls because Bucket Keys are not enabled" — that you can fix in 30 seconds.

Limitations

Being honest about what this won't do:

AWS-owned keys (like DynamoDB's default encryption) don't show up in CloudTrail and don't cost you anything. This only tracks aws-managed and customer-managed keys.
Cross-account — each AWS account needs its own deployment. No aggregation across accounts yet.
Cross-region — deploys in one region. Multi-region needs separate deployments or a multi-region trail.
Historical data — starts tracking from deployment. Can't tell you what happened last month.
No auto-fix — tells you what to fix but doesn't do it for you.
Per-resource granularity — attributes cost at key+caller level. If one role accesses 10 buckets, you see the total for that role (though encryption context often reveals the specific bucket).

I Built an AI System That Reads My AWS Error Logs and Tells Me What Went Wrong (in 5 Seconds)

Utkarsh Rastogi — Tue, 23 Jun 2026 04:09:00 +0000

The Problem

I run about 200 Lambda functions and a few Glue jobs in production. Every couple of weeks, something breaks. I get the CloudWatch alarm email instantly -- "Error count: 12." Great, I know something is wrong. But that is where the easy part ends.

Now I have to figure out WHAT went wrong. That is the part that takes 30-45 minutes:

Open CloudWatch, find the right log group out of 200+
Scroll through log streams looking for the actual error message
Read the stack trace, try to understand what happened
Check if someone deployed recently (open Lambda console, compare timestamps)
Check if other services are also broken
Google the error, figure out the fix
Tell the team what happened

The alert was instant. But the investigation was not. I still spent 30-45 minutes every time just reading logs and connecting dots.

I got tired of that part. The error is sitting right there in the logs. The deploy timestamp is in the Lambda config. The traffic metrics are in CloudWatch. All the information exists. I just need something to read the logs, connect the dots, and tell me the answer.

So I built a system that does exactly that. It catches the error, gathers all the context automatically, sends it to Amazon Bedrock, and emails me the root cause with the fix. The investigation that took me 30-45 minutes now takes 5 seconds.

What This Project Does

AI Ops Sentinel watches all your Lambda functions, Glue jobs, ECS tasks -- everything that writes to CloudWatch Logs. When something errors:

It catches the error instantly (push model, not polling)
It strips any credentials or PII from the logs (using Bedrock Guardrails)
It checks if this function was recently deployed
It checks how much traffic is affected right now
It checks if other services broke at the same time
It checks if this same error happened before
It sends all of that context to Bedrock for root cause analysis
It emails you the diagnosis with the fix

One deploy covers your entire account. New functions you create next week are automatically included. No per-function setup.

Why Not Just Use CloudWatch Alarm + SNS

Everyone already has that. A CloudWatch alarm fires when error count goes above zero and sends an SNS email. Here is what that email gives you:

Subject: ALARM: payment-processor-errors

StateChangeTime: 2025-06-19T09:05:03Z
NewStateValue: ALARM
Threshold: 1

That is it. You still have to do all the manual investigation yourself.

Here is what AI Ops Sentinel sends for the same error -- the root cause, the fix, whether it was a recent deploy, how many users are affected, and CLI commands to investigate. All in one email, 5 seconds later.

The alarm tells you there is a fire. This tells you which room, what started it, and hands you the extinguisher.

The Architecture

Here is how the whole system fits together:

The flow is simple:

All your services (Lambda, Glue, ECS, anything) write logs to CloudWatch. This happens automatically, you do not configure anything.
One account-level subscription filter watches ALL log groups. When any log event matches the error pattern (ERROR, Task timed out, OOM, missing modules), CloudWatch pushes it to the Analyzer Lambda instantly. This is a push, not a poll. No delay.
The Analyzer Lambda is the brain. It does everything: decodes the log event, identifies which service it came from, runs it through Bedrock Guardrails to strip credentials, gathers context (deploy history, blast radius, past incidents, correlated failures), sends everything to Bedrock Nova Lite for diagnosis, saves the incident to DynamoDB, and sends the alert via SNS.
You get an email about 5 seconds after the error happened.

Additionally, a separate Weekly Digest Lambda runs every Monday at 9 AM. It scans all incidents from the past week, asks Bedrock to write a summary, and sends you a formatted HTML report via SES.

There is also a CloudWatch Dashboard that shows the Analyzer's invocations, errors, and duration so you can monitor the monitor.

Services used: CloudWatch Logs, CloudWatch Subscription Filter, CloudWatch Metrics, CloudWatch Dashboard, Lambda (3 functions), Amazon Bedrock Guardrails, Amazon Bedrock Nova Lite, SNS, SES, DynamoDB, SSM Parameter Store, EventBridge, S3, and CloudFormation. 15 services total, deployed as 11 modular stacks.

Why the AI Works Well Here

If you paste an error message into ChatGPT and ask "what is wrong", you get a generic answer. "Check your input." "Validate the payload." Not helpful.

The reason AI Ops Sentinel gives useful answers is that it does not just send the error. It sends the full story:

The error happened at 9:05 AM
This function was deployed at 8:53 AM (12 minutes before)
The same error has occurred 4 times in the past week
Right now, 1200 requests per hour are hitting this function and 15 percent are failing
Two other services (a Glue job and another Lambda) also started erroring within the last 5 minutes

With all that context, even the cheapest Bedrock model (Nova Lite, which costs about $0.001 per call) gives genuinely useful root cause analysis. It is not about using an expensive model. It is about giving the model the right information.

Credentials Safety

This is the part I want to be clear about. Production error logs contain secrets. I have seen database connection strings with passwords, JWT tokens, API keys, email addresses, and even credit card numbers show up in error messages because someone logged the raw request.

If you send those logs to any AI model, you are leaking credentials.

Before Bedrock sees any error text, it goes through Bedrock Guardrails. The Guardrail replaces sensitive data with placeholders:

Database URLs become {DatabaseConnectionString}
Bearer tokens become {BearerToken}
Emails become {EMAIL}
API keys become {GenericApiKey}

The AI still understands "database connection failed" -- it just never sees the actual password. And the email you receive never contains raw credentials either.

I use ANONYMIZE for everything, not BLOCK. Blocking would mean the AI gets no context and cannot diagnose anything. Anonymizing keeps the story intact while removing the sensitive parts.

Smart Deduplication

If a function errors 50 times in 10 minutes, you do not want 50 emails. You want one.

But if the same function throws a different error type 2 minutes later, you do want that alert. It could be a cascading failure.

The rule: same function plus same error type equals suppressed for 30 minutes. Different error type always alerts immediately.

Weekly Digest (Monday 9 AM)

Separate from the real-time alerts, a Weekly Digest Lambda runs every Monday morning. It scans all incidents from the past 7 days in DynamoDB, sends them to Bedrock for a summary, and emails you a formatted HTML report via SES.

The report includes:

Total incidents that week
Top 5 failing functions/jobs
Severity breakdown (how many critical, high, medium)
AI-written summary: patterns, biggest risk, one recommendation

You do not have to check a dashboard or remember to review incidents. The summary comes to you. If it was a quiet week, the email just says "no incidents, all systems healthy."

This uses SES (not SNS) because SES supports HTML formatting -- tables, colors, stats. The real-time alerts stay on SNS because speed matters there, not formatting.

How to Deploy

The project is open source. Everything is in one repo with deploy scripts.

Prerequisites:

AWS CLI configured
Bedrock Nova Lite model access enabled in your region
An email address for alerts

Steps:

# Clone
git clone https://github.com/utkarsh-rastogi-aws/ai-ops-sentinel.git
cd ai-ops-sentinel

# Configure (add your email)
cp .env.example .env
# Edit .env: ALERT_EMAIL=your-email@example.com

# Deploy all 11 stacks (takes about 8 minutes)
./deploy.sh all

# Confirm the SNS email subscription (check inbox, click the link)

# Check everything is up
./deploy.sh status

Testing It

The project includes a test Lambda and a test Glue job that generate errors on purpose:

# Lambda tests
./test-errors.sh lambda key_error         # Missing dictionary key
./test-errors.sh lambda connection        # Logs DB password (guardrail strips it)
./test-errors.sh lambda pii_in_logs       # Logs emails and credit cards
./test-errors.sh lambda timeout           # Exceeds timeout limit
./test-errors.sh lambda import_error      # Missing module

# Glue tests
./test-errors.sh glue key_error           # ETL processing failure
./test-errors.sh glue connection          # DB credentials in Glue logs
./test-errors.sh glue oom                 # Out of memory

# Run everything
./test-errors.sh all

After running any test, check your email in about 10 seconds. The AI diagnosis will be there.

The connection test is the interesting one for seeing Guardrails in action. It deliberately logs a full database URL with a password and a Bearer token. In the email you receive, those will be replaced with placeholders. The AI still correctly diagnoses "database connection failed" without ever seeing the actual credentials.

What Gets Deployed

11 CloudFormation stacks:

DynamoDB table (incidents, dedup tracking, fingerprints)
Bedrock Guardrail (PII and credentials anonymization)
SNS topic (real-time email alerts)
SES identity (weekly HTML digest emails)
IAM roles (centralized, least-privilege)
Analyzer Lambda (the AI brain)
Subscription filter (account-level, covers all services)
Test Lambda (5 error scenarios)
Test Glue job (4 error scenarios)
Weekly Digest Lambda with EventBridge schedule
CloudWatch Dashboard

To remove everything: ./destroy.sh all

What It Costs

Situation	Monthly cost
No errors happen	$3 (just the CloudWatch dashboard)
About 100 errors per day	Around $4
About 1000 errors per day	Around $7

Most of that is the dashboard ($3/month) and Bedrock calls. If you remove the dashboard, the cost with no errors is $0.

For comparison: Datadog charges $15 per host per month. PagerDuty is $20 per user per month. This covers your entire account for less than a coffee.

Cleanup

./destroy.sh all

Deletes all 11 stacks in reverse dependency order. Empties S3 buckets automatically. Asks for confirmation before proceeding.

What I Would Build Next

Bedrock Knowledge Bases so the AI can check our internal runbooks before diagnosing
Slack integration for teams that prefer Slack over email
Severity-based routing where CRITICAL goes to PagerDuty and LOW goes to weekly digest only
A simple React dashboard to browse incident history

The Repo

GitHub: https://github.com/Utkarshlearner/ai-ops-sentinel

The README covers everything: architecture, prerequisites, customization, limitations, cost breakdown. All the code is inline Python in CloudFormation templates. No Docker, no layers, no build step. Deploy with one command, destroy with one command.

If you try it, let me know what it catches. And if you find a bug in the error-catching system, that would be genuinely funny.

Utkarsh Rastogi
LinkedIn | dev.to/awslearnerdaily

I Built a Serverless AI Summarizer That Blocks Harmful Content on AWS

Utkarsh Rastogi — Fri, 19 Jun 2026 05:02:49 +0000

How it started

We've all done it — paste something into ChatGPT without thinking twice. Sometimes that "something" has a phone number, an email, or worse.

There's nothing stopping it. No safety check. No filter.

I thought — what if the AI had a security guard? Something that checks every input before the AI sees it, and every output before the user sees it.

So I built it.

What it does

AI Content Guard — a text summarizer with a safety layer.

Normal text → clean 2-3 line summary ✅
Phone/email/name in text → hidden as {PHONE}, {EMAIL}, {NAME}, summary still generated ✅
Credit card / SSN → fully blocked, AI never sees it 🚫
Hate speech, violence, prompt attacks → blocked instantly 🚫

The guardrail runs twice — once on your input, once on the AI's output. Safety before and after.

Architecture

The flow:

User → Amplify (React UI) → API Gateway → Lambda
  → Guardrail INPUT check (block or continue)
  → Bedrock AI Model (generates summary)
  → Guardrail OUTPUT check (block or continue)
  → DynamoDB (log result)
  → Response back to user

Blocked = 0.4 seconds. Success = 1.5 seconds.
Blocked is faster because the AI model is never called.

Why serverless?

No servers to manage or patch
Pay nothing when nobody's using the app
Auto-scales if 100 people hit it at once
Deploy with one command, tear down with one command

I write code. AWS runs it. That's the deal.

The stack

Service	What it does
Lambda (Python 3.12)	Runs the logic
Bedrock (Nova Lite)	AI summarization
Bedrock Guardrails	Content safety + PII detection
API Gateway	REST API with rate limiting
DynamoDB	Audit logs (auto-deletes in 30 days)
SSM Parameter Store	Config without redeployment
Amplify	Hosts the React frontend
CloudFormation	Infrastructure as Code (6 templates)

Why guardrails matter

This isn't academic. It's a real requirement now.

Samsung banned ChatGPT after employees leaked code into it.
EU AI Act requires safety measures. No guardrails = non-compliant.
India's DPDP Act makes you liable for unprotected personal data.
One screenshot of your chatbot generating hate speech = your product is dead.

Guardrails solve this at infrastructure level. You don't ask the AI to be safe. You put a wall in front of it.

For students & early-career devs

This project covers what actually comes up in interviews:

"Have you worked with serverless?" → Yes. Lambda, API Gateway, DynamoDB.
"How do you handle security?" → Least-privilege IAM, encryption, defense in depth.
"Tell me about an AI project." → Built a summarizer with guardrails for content safety.
"How do you deploy?" → Infrastructure as Code. One command.

Companies like Razorpay, CRED, Swiggy use the exact same services. Same patterns. Different scale.

My honest advice: Don't just read this. Clone it. Deploy it. Break something. Fix it.

Nobody cracked an interview by reading about Lambda. They cracked it by using Lambda. Hands-on is the only thing that sticks.

Try it

Live app: https://main.d1244888rwbz47.amplifyapp.com

Source code: https://github.com/Utkarshlearner/ai-content-guard

Run your own:

git clone [your-repo-url]
cd ai-content-guard
./deploy.sh all
./deploy-frontend.sh

5 minutes. Done.

What I learned

Safety is infrastructure, not prompt engineering.
Blocked is faster than success (fewer API calls).
ANONYMIZE ≠ BLOCK — know when to be strict vs lenient.
Config (SSM) and code (Lambda) should live separately.
"We'll add safety later" is how companies end up in the news.

About me

I'm Utkarsh. I build on AWS and write about it.

🚀 Your turn

What would you add? Cognito login? Hindi support? Admin dashboard? Slack bot?

Fork it. Build something. Tag me.

Or just drop your ideas in the comments — I'm picking the best ones for the next version.

Build with AI. But build safe. 🛡️

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

DEV Community: Utkarsh Rastogi

Tracking AWS KMS Costs by Service — When Cost Explorer Can't Help

Why KMS Costs Are Hard to Track

What Makes This Different from Cost Explorer or CloudWatch

The Core Idea

How the System Works

Real-time Processing

Spike Detection

Daily Report

Weekly Summary

Cost Threshold Alert

What the Daily Email Contains

Common Culprits This System Finds

Architecture

Tech Decisions and Tradeoffs

What It Costs to Run

Time to Build

What You Get for $69/month

The ROI

AWS Free Tier

Deploy and Test

When You Don't Need This

What's Next

Do You Even Have This Problem?

S3 Bucket Keys: The #1 Fix

Before and After

Limitations

Links

I Built an AI System That Reads My AWS Error Logs and Tells Me What Went Wrong (in 5 Seconds)

The Problem

What This Project Does

Why Not Just Use CloudWatch Alarm + SNS

The Architecture

Why the AI Works Well Here

Credentials Safety

Smart Deduplication

Weekly Digest (Monday 9 AM)

How to Deploy

Testing It

What Gets Deployed

What It Costs

Cleanup

What I Would Build Next

The Repo

I Built a Serverless AI Summarizer That Blocks Harmful Content on AWS

How it started

What it does

Architecture

Why serverless?

The stack

Why guardrails matter

For students & early-career devs

Try it

What I learned

About me

🚀 Your turn

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

The Problem

What I Built

The Privacy Magic

Real Results

Quick Deploy

Test It Instantly

Postman Test Results (Screenshots)

What Surprised Me

Common Questions

The Bottom Line

Get The Code

📊 Guardrail Monitoring

Day 4: Structured Outputs with LangChain Output Parsers

The Problem

What Are Output Parsers?

Key Concepts

Setup First!

Basic JSON Output Parser

List Output Parser

Custom Schema Parser

Parser Comparison

Key Takeaways

About Me