DEV Community: Sarvar Nadaf

Sentry's Span Hierarchy Exposed a Silent Retry in My 5-Agent Pipeline. One Agent Took 22.6s, the Others Took 5.

Sarvar Nadaf — Fri, 24 Jul 2026 05:48:09 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

I built an AWS Security Posture Agent: five specialist AI agents that scan your AWS account for security misconfigurations, map findings to CIS benchmarks, score risk, and generate copy-paste fix commands.

The agents run sequentially on CrewAI with Amazon Bedrock Nova Pro as the LLM:

1. ResourceDiscovery    → inventories EC2, S3, Lambda, IAM, SGs, API GW, DynamoDB
2. SecurityScanner      → finds open ports, public buckets, admin roles, insecure configs
3. ComplianceChecker    → maps to CIS AWS Foundations Benchmark
4. RiskScorer           → severity × blast radius × exploitability
5. RemediationPlanner   → generates AWS CLI fix commands

Each agent has custom boto3 tools that make real AWS API calls against a live account with 90 IAM roles, 14 S3 buckets, 9 security groups, and 7 Lambda functions. Not test data. Real findings.

simplynadaf / aws-security-posture-agent

Multi-agent AI system that scans AWS accounts for security misconfigurations using CrewAI + Amazon Bedrock, instrumented with Sentry AI Agent Monitoring. 5 specialist agents discover resources, analyze security, map to CIS benchmarks, score risk, and generate fix commands.

AWS Security Posture Agent

Five AI agents scan your AWS account. Find misconfigurations. Score risk. Get fix commands.

Quick Start | Architecture | Screenshots | Performance Fix

The Problem

Most AWS accounts accumulate security debt silently. Open SSH ports from testing. S3 buckets without encryption. IAM roles with full admin access that nobody remembers creating. Manual audits miss things. AWS Config rules cost money. SecurityHub is noisy.

This agent scans your account in 60 seconds, finds real issues, maps them to CIS benchmarks, scores risk, and gives you the exact AWS CLI command to fix each one.

What It Finds

On a real AWS account (90 IAM roles, 14 S3 buckets, 9 security groups, 7 Lambda functions):

97 security findings
├── CRITICAL: open SSH/RDP from 0.0.0.0/0, IAM users without MFA
├── HIGH:     admin roles, unencrypted EBS, missing public access blocks
├── MEDIUM:   deprecated Lambda runtimes, missing versioning, stale SGs
└──

…

View on GitHub

Demo

Here's the full scan running against my AWS account. The scan portion is sped up 4x, results walkthrough is at normal speed:

Bug Fix or Performance Improvement

My first instinct was to blame Bedrock latency. Every time something is slow you blame the LLM, right?

The SecurityScanner agent was taking 22.6 seconds while every other agent averaged 5-10 seconds. Without visibility into what was happening inside each agent's execution, I would have added time.time() calls and guessed.

Sentry's trace waterfall told a different story. The real problem wasn't Python execution time or network latency. It was the LLM getting a context payload it couldn't process cleanly on the first attempt.

The root cause: my IAMAnalyzer tool was fetching all 90 IAM roles from the account (59 after filtering service-linked roles), serializing them into a 27KB JSON blob, and handing that entire payload to the LLM as tool output. The context window got overwhelmed. CrewAI's internal retry logic kicked in, burning tokens on a second attempt with even more context.

One tool. Wrong default. The entire pipeline suffered.

Code

PR with the fix:

fix: paginate IAM analysis and add token budget guard #1

simplynadaf posted on Jul 20, 2026

What

The IAMAnalyzer tool was fetching every single role in the account (90 of them, 59 after filtering service-linked ones) and dumping the full details into a single JSON blob. That blob hit 26,980 characters. The LLM choked on it, CrewAI retried the task, and the SecurityScanner agent ended up taking 22.6s while every other agent finished in 5-10s.

How I found it

Added Sentry spans to each agent and tool. The trace waterfall made it obvious: SecurityScanner was twice as wide as everything else. Drilled into the tool spans and saw result_length_chars: 26980 on iam_analyzer vs ~4000 on the other tools.

7x output disproportion. That was the problem.

What I changed

Three things in iam_analyzer.py:

Paginate and sort roles by RoleLastUsed date, only analyze the top 20 most active ones. The rest are stale roles nobody has touched in months.
Skip 31 service-linked roles upfront (you cannot modify them anyway, auditing them is noise).
Token budget guard at the end: if the JSON output exceeds 4000 chars, trim the role_summary down to just names and policy lists.

Numbers

Tool output: 26,980 chars down to 15,532 (42% smaller)
SecurityScanner: 22.6s down to 17.8s (21% faster, no more LLM retry)
API calls to IAM: 59 down to 20
Total pipeline: 62s down to 57.7s
Findings: still 27. No coverage loss because the top-20 most active roles contain all the problematic ones (AdminRole, Bedrock-Lambda-Role, etc are all heavily used).

View on GitHub

The core change lives in src/security_posture/tools/iam_analyzer.py. Here's the before and after:

Before (the bug):

# Fetches ALL roles without pagination limit
roles = iam.list_roles(MaxItems=100)
role_details = []

for role in roles["Roles"]:
    role_name = role["RoleName"]
    if role.get("Path", "").startswith("/aws-service-role/"):
        continue
    # Analyzes every single role...
    attached = iam.list_attached_role_policies(RoleName=role_name)
    # ...builds massive JSON output

This produces 26,980 characters of JSON for an account with 90 roles. The LLM chokes on it.

After (the fix):

# FIX: Paginate and sort by relevance
all_roles = []
paginator = iam.get_paginator("list_roles")
for page in paginator.paginate():
    all_roles.extend(page["Roles"])

# Filter service-linked roles (31 roles, can't modify anyway)
auditable_roles = [
    r for r in all_roles
    if not r.get("Path", "").startswith("/aws-service-role/")
]

# Sort by last used date (most active first)
auditable_roles.sort(key=_last_used_sort_key, reverse=True)

# Take only top 20 roles
roles_to_analyze = auditable_roles[:max_roles]

Plus a token budget guard at the end:

# Token budget guard: truncate if output exceeds threshold
if len(output) > 4000:
    result["role_summary"] = [
        {"role_name": r["role_name"], "policies": r.get("attached_policies", [])}
        for r in role_details
    ]
    result["note"] = "Role details truncated to stay within token budget"
    output = json.dumps(result, indent=2, default=str)

Three changes. Pagination, relevance sorting, and a safety valve. The SecurityScanner stopped retrying.

My Improvements

Results first:

Metric	Before	After	Improvement
IAM tool output	26,980 chars	15,532 chars	42% smaller
SecurityScanner time	22.6s	17.8s	21% faster
IAM API calls	59	20	66% fewer
Total pipeline	62.0s	57.7s	7% faster
Security findings	97	97	No coverage loss

The 21% improvement on the SecurityScanner came from the LLM completing analysis in a single pass instead of retrying.

How I found it:

The fix itself is simple. The interesting part is how Sentry pointed me straight to it.

Without the trace waterfall, all I would have seen is "pipeline takes 62 seconds." The trace said otherwise:

Wrap each agent execution in a gen_ai.invoke_agent span
Wrap each tool call in a gen_ai.execute_tool span
Run the pipeline and look at the trace waterfall
The SecurityScanner span was visually obvious: twice the width of everything else
Inside it, the iam_analyzer tool span showed a result_length_chars of 26,980
Compare to security_group_analyzer at 4,200 chars and s3_config_checker at 3,800 chars

The disproportion was the clue. If the tool output is 7x larger than its siblings, reduce it.

Best Use of Sentry

I used Sentry's AI Agent Monitoring to instrument a multi-agent CrewAI pipeline from scratch. This isn't a web app or API. It's five autonomous AI agents making LLM calls and executing custom tools. Standard APM wouldn't help here.

What I instrumented

Every pipeline run creates a Sentry transaction with this span hierarchy:

Transaction: "Security Posture Scan" (57s)
├── gen_ai.invoke_agent: ResourceDiscovery
│   └── gen_ai.execute_tool: aws_resource_scanner
├── gen_ai.invoke_agent: SecurityScanner
│   ├── gen_ai.execute_tool: security_group_analyzer
│   ├── gen_ai.execute_tool: s3_config_checker
│   ├── gen_ai.execute_tool: iam_analyzer
│   ├── gen_ai.execute_tool: ec2_security_checker
│   └── gen_ai.execute_tool: lambda_security_checker
├── gen_ai.invoke_agent: ComplianceChecker
├── gen_ai.invoke_agent: RiskScorer
└── gen_ai.invoke_agent: RemediationPlanner

The instrumentation code

For each agent (in main.py):

with start_span(
    op="gen_ai.invoke_agent",
    name=f"invoke_agent {agent_name}",
) as agent_span:
    agent_span.set_data("gen_ai.operation.name", "invoke_agent")
    agent_span.set_data("gen_ai.agent.name", agent_name)
    agent_span.set_data("gen_ai.request.model", "amazon.nova-pro-v1:0")
    agent_span.set_data("gen_ai.pipeline.name", "security-posture-scan")

    task_output = task_obj.execute_sync(
        agent=task_obj.agent,
        context=context,
        tools=task_obj.agent.tools,
    )

    agent_span.set_data("duration_seconds", round(elapsed, 2))
    agent_span.set_data("output_length_chars", len(str(task_output)))

For each tool (decorator in monitoring.py):

def trace_tool(tool_name: str):
    def decorator(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            with start_span(
                op="gen_ai.execute_tool",
                name=f"execute_tool {tool_name}",
            ) as span:
                span.set_data("gen_ai.tool.name", tool_name)
                result = func(*args, **kwargs)
                span.set_data("result_length_chars", len(result))
                try:
                    data = json.loads(result)
                    if "findings_count" in data:
                        span.set_data("findings_count", data["findings_count"])
                except (json.JSONDecodeError, KeyError):
                    pass
                return result
        return wrapper
    return decorator

What Sentry revealed

The trace waterfall made the bottleneck visually obvious. The SecurityScanner span was nearly twice the width of any other agent, 22.6 seconds while others averaged 5-10s.

Inside it, the iam_analyzer tool span showed result_length_chars: 26980 while s3_config_checker showed 3,800 and security_group_analyzer showed 4,200. The granularity goes down to individual boto3 calls. Every GetPublicAccessBlock, ListRoles, and ListAttachedRolePolicies shows up as its own span.

Before the fix (SecurityScanner dominates the trace at 22.6s):

After the fix (all agents proportional, no single bottleneck):

The iam_analyzer output dropped from 26,980 chars to 15,532, and the SecurityScanner stopped triggering retry logic.

Sentry features used

Feature	How I Used It
Distributed Tracing	Full pipeline trace from start to final report
AI Agent Monitoring	`gen_ai.invoke_agent` spans for all 5 agents
Tool Execution Tracing	`gen_ai.execute_tool` spans for all 5 boto3 tools
Custom Span Data	Token counts, output sizes, duration, finding counts
Error Monitoring	Exception capture with `sentry_sdk.capture_exception()`
Breadcrumbs	Agent completion events via task callbacks
Transaction Metadata	Model name, pipeline config, agent count

Why this matters for AI agent observability

Standard logging tells you an agent "finished." It doesn't tell you which tool inside which agent returned a 27KB payload that triggered a retry you never asked for.

With five agents each making their own LLM calls and tool executions, you need span-level visibility. Sentry's gen_ai.invoke_agent and gen_ai.execute_tool conventions gave me exactly that. I could see the problem in the trace waterfall before I even looked at the code.

That's the difference between "add some logging" and actual AI observability.

If you're running multi-agent pipelines, what's your observability setup? Curious if anyone else has hit similar tool-output-size problems with CrewAI or LangGraph.

The agent found 97 real security findings in my AWS account. The fix is in production.

4 Silent Failures, 2 Undocumented APIs, and a Container That Crashed Because of a Missing User Directive

Sarvar Nadaf — Mon, 20 Jul 2026 18:20:15 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

I spent a week deploying a CrewAI agent to AWS Bedrock AgentCore. The SDK wasn't on PyPI. The error messages were 200 OKs. The container crashed without logs. And the naming regex rejected hyphens without telling me why.

This is the full debugging trail. Every failure was silent. Every fix required reading source code nobody documented.

The Project
Failure 1: The SDK That Doesn't Exist on PyPI
Failure 2: The 200 OK That Means Failure
Failure 3: The Container That Crashed With No Logs
Failure 4: The Naming Regex Nobody Documented
The Two-Client Split Nobody Mentions
What I Learned

The project

I built a resume-tailoring AI agent with CrewAI and Amazon Bedrock. It takes a job description, analyzes your resume, identifies gaps, and rewrites bullet points to match what the role actually needs.

Locally it worked perfectly. CrewAI orchestrates the agents, Bedrock Nova Pro handles the LLM calls, and the output is solid. Deploying it to production was the problem.

AWS launched Bedrock AgentCore in June 2026 as a managed runtime for AI agents. You containerize your agent, push the image, and AgentCore handles scaling, memory, and invocation. Sounds simple.

It was not simple.

Failure 1: The SDK that doesn't exist on PyPI

The docs say to install bedrock-agentcore-client. I ran:

pip install bedrock-agentcore-client

It installed successfully. No errors. That's because there's a placeholder package on PyPI with that name. It installs, imports fail silently, and your container builds successfully with a broken dependency inside.

The real SDK lives in AWS's CodeArtifact registry. You need to configure pip to pull from a private index:

aws codeartifact login --tool pip \
  --domain amazon-agent-runtimes \
  --repository agent-runtimes-pypi \
  --domain-owner 600427722194

Then install from there. The PyPI package is a trap. Nobody warns you.

Hours lost: 3. The error only appears at runtime when the container tries to import the module. The build succeeds. The push succeeds. The deployment succeeds. The invocation returns an empty payload.

Failure 2: The 200 OK that means failure

After fixing the SDK, I deployed and invoked the agent:

aws bedrock-agentcore-control invoke-agent-runtime \
  --agent-runtime-id abc123 \
  --payload '{"job_description": "..."}'

Response: HTTP 200. Payload: empty string.

Not a 500. Not a 400. Not an error message. A successful HTTP response with nothing inside.

I checked CloudWatch. No logs. I checked the container status. Running. I checked the agent runtime status. Active.

The problem: my IAM role was missing bedrock:GetAgentRuntime permission. Without it, the invocation endpoint accepts the request, routes it nowhere, and returns a 200 with an empty body.

There is no error message. There is no log entry. The service returns success when it fails.

Hours lost: 5. I tried different payloads, different content types, different SDK versions, curl vs boto3, synchronous vs streaming. All 200 OK, all empty. The fix was one IAM permission that produces zero error signal when missing.

{
  "Effect": "Allow",
  "Action": "bedrock:GetAgentRuntime",
  "Resource": "*"
}

Failure 3: The container that crashed with no logs

Next failure. Container starts, passes health checks for 30 seconds, then dies. No exception in CloudWatch. No crash log. Status shows "Failed" with no reason.

I added every logging statement I could think of. Print statements. Structured logging. Exception handlers wrapping every import. Nothing appeared in CloudWatch because the container never got far enough to initialize the logging framework.

The cause: missing USER 1000 directive in the Dockerfile.

# This crashes silently
FROM python:3.12-slim
WORKDIR /app
COPY . .
RUN pip install -e .
CMD ["python", "-m", "my_agent"]

# This works
FROM python:3.12-slim
RUN useradd -m -u 1000 agentuser
WORKDIR /app
COPY . .
RUN pip install -e .
USER 1000
CMD ["python", "-m", "my_agent"]

AgentCore requires the container to run as UID 1000. If it doesn't, the runtime kills the container. The error message in the console says "Failed." Just "Failed." No mention of user directives, permissions, or UID requirements.

I found this by reading the AgentCore team's GitHub sample repos. Not the docs. The sample Dockerfile.

Hours lost: 4.

Failure 4: The naming regex nobody documented

I wanted to name my agent runtime resume-tailor-agent. Deployment failed:

An error occurred (ValidationException): 
  Name must match pattern: ^[a-zA-Z0-9_]+$

No hyphens allowed. Fine. I renamed to resume_tailor_agent and moved on.

But the error message only appears if you use the control plane client. If you use the console, it just... doesn't submit. No red border, no error toast, no validation message. The button does nothing.

Hours lost: 1. Small one, but the pattern: silent failures.

The two-client split nobody mentions

Here's where it gets architectural. AgentCore has TWO Python clients:

bedrock-agentcore-control for managing runtimes (create, update, delete)
bedrock-agentcore for the runtime SDK (what runs inside your container)

The documentation uses both interchangeably. Code samples import from one in the setup section and the other in the invocation section. They have different install paths, different CodeArtifact repositories, and different API surfaces.

If you install the wrong one, nothing tells you. Your code runs until it hits an import that doesn't exist in the package you installed. And since both packages have overlapping module names in some versions, the error might be an AttributeError deep in a function call, not a clean ImportError at the top.

I mapped out which client does what:

Client	Purpose	Install From
`bedrock-agentcore-control`	Create/manage runtimes	CodeArtifact (domain: amazon-agent-runtimes)
`bedrock-agentcore`	Runtime SDK (inside container)	CodeArtifact (same domain)
`boto3` (bedrock-agent)	Invoke from outside	Standard pip

This table doesn't exist in any documentation I found.

What I learned

Five days of debugging. Four distinct silent failures. Zero useful error messages.

Every single problem shared the same pattern: the system accepted the bad input, returned success, and failed somewhere downstream without signaling what went wrong. The 200 OK that means failure. The build that succeeds with a placeholder SDK. The container that crashes without logs.

If I'd had Sentry in the container from day one, I would have caught the import failure, the UID crash, and the empty response pattern within hours instead of days. Observability isn't optional for agent deployments. The infrastructure actively hides failures from you.

Three principles I'm carrying forward:

1. Never trust a 200 OK from a new service. Validate the response body. If it's empty, something broke silently upstream.

2. Test imports at container startup, before anything else. A try/except around every critical import with an explicit log line. If the SDK is fake, you'll know in the first second.

3. Read the sample repos, not just the docs. The Dockerfile in AWS's example repo had USER 1000. The documentation never mentioned it. The sample code is sometimes the real documentation.

I've since added Sentry to my agent pipeline for my security posture scanner project. The trace waterfalls catch problems in seconds that would have taken me hours with print statements. Lesson learned the hard way.

All errors described above are from July 2026 on AgentCore's GA release. Some may be fixed by the time you read this. The patterns of silent failure in new AWS services are probably eternal.

Introducing AWS SimuLearn Badges: Free Proof That You Can Actually Build in the Cloud

Sarvar Nadaf — Fri, 17 Jul 2026 15:47:29 +0000

If someone asked me ten years ago what it takes to break into cloud, I would have said "get certified and hope someone gives you a chance."

I was wrong. And I watched dozens of freshers follow that exact advice, collect a certification, then sit in interviews unable to explain why they chose one architecture over another.

The problem was never knowledge. It was proof. Proof that you can gather requirements from a confused client, design something that works, and actually build it with your own hands.

AWS just launched something that helps close that gap. And two of these credentials cost nothing.

What AWS SimuLearn Badges Actually Are
Why This Matters More Than Another Certification
The 12 Badges Available Right Now
The Free Starting Path I Would Follow Today
The LinkedIn Advantage Nobody Is Talking About
For Career Switchers: Your Existing Skills Are the Cheat Code
My Honest Take After 10 Years in Cloud

What AWS SimuLearn Badges Actually Are

SimuLearn is not another video course. Not another multiple-choice exam.

You sit in a simulated client meeting powered by generative AI. A virtual customer explains their business problem. You ask questions, uncover requirements, handle objections, and propose an architecture. The AI evaluates your communication, your technical accuracy, and your decision-making in real time.

Then you build the solution. In a live AWS environment. Not a sandbox with three buttons. The real console.

After that, an automated validation confirms your solution actually works.

Complete every assignment in a learning plan, and AWS issues you a badge through Credly. Automatically. No exam booking. No proctored test. Just demonstrated capability across the full workflow.

Each badge represents the entire journey: customer conversations, architecture design, hands-on building, and validated outcomes. Not a single quiz. Not one lab. The whole thing.

Why This Matters More Than Another Certification

I hold 7 AWS certifications. Let me tell you what they prove: I can answer questions about cloud services under time pressure.

What they do NOT prove: that I can sit with a client, understand their problem, design something appropriate, and build it without breaking things.

That gap is exactly where freshers struggle. You study for months, pass the exam, and then face an interviewer who asks "Tell me about a time you designed a solution for a customer." You have nothing.

Last year I sat across from a candidate with three AWS certifications. I asked him to walk me through a time he gathered requirements from a non-technical stakeholder. Thirty seconds of silence. Three certs, zero stories. That is the gap SimuLearn closes.

Here is how the credential types compare:

Certifications prove you KNOW it. Knowledge of services, best practices, theory.

Microcredentials prove you can DO it. Specific hands-on skills in a live environment. No multiple choice.

SimuLearn Badges prove you can DELIVER it. The full cycle from client conversation to working solution.

For someone with zero professional cloud experience, that third one is useful. It gives you something concrete to discuss in interviews. "I gathered requirements from a retail client who needed personalized recommendations, designed a serverless pipeline, and built it in the console." That sentence alone makes you more memorable than someone who just lists a cert.

The 12 Badges Available Right Now

Two of these are completely free. No subscription. No credit card. Nothing.

Free:

With Skill Builder subscription ($29/month or $299/year):

Solutions Architect
Serverless Developer
AI Architect
Machine Learning
Security
Networking
Data Analytics
Healthcare
Manufacturing and Automotive
Financial Services

The free ones cover cloud fundamentals and AI. The two hottest entry points in cloud right now.

The Free Starting Path I Would Follow Today

If I were starting from zero in 2026, here is exactly what I would do.

Month 1-2: Build the foundation (cost: $0)

Start with the SimuLearn Cloud Practitioner learning plan. Take your time. The platform offers two modes: Scripted mode guides you through the conversation with prompts, and Open Dialogue mode lets you drive the meeting yourself. Begin with Scripted to see how a proper client conversation flows, then switch to Open Dialogue once you feel ready.

The customer conversations will feel awkward at first. That is normal. Real client meetings are awkward too. You are practicing that discomfort in a safe environment.

When you finish, you have your first verified badge.

Month 3: Add the AI layer (cost: $0)

Complete the AI Practitioner learning plan. Generative AI shows up in most cloud job descriptions now. This badge tells employers you understand how AI fits into cloud architecture. Not just theory. You built something.

Month 4: Take the certification exam (cost: $100)

Now take the Cloud Practitioner certification. You already have hands-on practice from SimuLearn. The exam covers some ground you have already worked through, though it also tests pricing models, support plans, and global infrastructure that SimuLearn may not cover in depth. Study those gaps, but you will not be starting from zero.

Total investment: $100 and four months.

What you have at the end: 2 SimuLearn badges and 1 certification. Three verified AWS credentials on your LinkedIn profile. All proving different things. All verifiable by any recruiter who clicks the link.

Bonus: AWS also made microcredentials free in April 2026. Four are available: Serverless, Agentic AI, Application Networking, and Incident Response. These are pure hands-on assessments. If you want to stack more credentials after your certification, these are worth looking at.

Many people spend those same four months watching tutorials and collecting notes they never revisit. This path gives you something verifiable at the end of each month.

The LinkedIn Advantage Nobody Is Talking About

Every badge issued through Credly becomes a verified credential on LinkedIn. Not a self-declared skill. Not a line on your resume anyone could type. A verified badge that links back to exactly what you did to earn it. Anyone can click it and confirm it is real.

When a recruiter clicks your badge, they see:

Who issued it (Amazon Web Services)
What it represents (full learning plan completion)
What skills it validates (specific, detailed)
When you earned it

This cannot be faked. That matters when you have no work experience to reference.

When you share a badge as a LinkedIn post, your network sees it. People engage with achievement posts. That engagement puts your name in front of people who might not have found you otherwise. For freshers with a small network, a badge post can be good visibility.

How effective is this model? AWS says Cloud Quest badge earners share their accomplishments "at rates well above industry benchmarks." Across the broader AWS Education Programs (Academy, Educate, re/Start), Credly's survey data shows 99% of badge earners consider them valuable, 42% got a new job, and 85% received a raise, promotion, or new role. Those programs include full training and career support, not just a badge. SimuLearn follows the same Credly model, but these numbers are not guaranteed outcomes for every badge earner.

Verified badges on your profile send a signal: this person is actively investing in cloud skills, and they can back it up.

For Career Switchers: Your Existing Skills Are the Cheat Code

If you are moving into cloud from another field, SimuLearn gives you something certifications never could: a way to leverage what you already know.

Coming from sales or consulting? The customer conversation component is YOUR strength. You already know how to ask questions, handle objections, and translate technical concepts into business value. SimuLearn lets you combine that with new technical skills and prove both in one credential.

Coming from healthcare, manufacturing, or finance? Look at those industry-specific learning plans. A SimuLearn Healthcare badge tells employers: "I understand compliance, I understand the domain problems, AND I can build cloud solutions for them." I have seen people transition from clinical roles into cloud at consulting clients. The combination of domain knowledge plus technical proof is what gets them past the resume screen when pure technologists cannot.

The subscription costs $29/month. Subscribe for three months, earn your role-specific or industry-specific badge, cancel. You spent $87 total. Compare that to a bootcamp at $10K or a master's degree at $40K.

That $87 gets you a verified AWS credential on LinkedIn, hands-on experience in a live console, and client simulation practice you can reference in every interview. For a career pivot, that is a solid starting investment. One honest note: the paid badges are newer to the market than certifications. Not every recruiter will recognize them yet. But the hands-on experience you gain is yours regardless of badge recognition.

My Honest Take After 10 Years in Cloud

I have not personally completed a SimuLearn learning plan yet. Full disclosure. I also do not know how long each plan takes to finish. AWS does not publish that number anywhere I could find. Could be 10 hours, could be 60. That matters if you are working full time and planning your evenings around this.

What I do know: SimuLearn badges are the first AWS credential that evaluates both your communication skills and your technical ability in one package. That combination is what the actual job requires. Every architecture review I have ever been in required both.

But let me be honest about limitations too. This is still a simulation, not real client work. A hiring manager who has never heard of SimuLearn might not know what the badge means yet. These are new, launched July 2026. It will take time for the market to recognize them the way it recognizes AWS certifications.

These badges will not replace certifications. Hiring managers still filter by cert. But they fill a gap that certifications cannot: evidence that you practiced the full job, not just the exam.

If you are a fresher reading this, your path is clearer than it was a year ago. Start with the free plans. Build the habit of doing, not just studying. Earn something verifiable before you spend a single dollar on an exam.

The old way: study, memorize, pass, hope.

The new way: build, prove, share, get noticed.

Start here:

AWS SimuLearn Cloud Practitioner (free)
AWS SimuLearn AI Practitioner (free)

Have you tried SimuLearn yet? What was your experience with the customer simulation part? I am genuinely curious whether the Open Dialogue conversations feel realistic or scripted. Drop your thoughts below.

If this helped clarify the credential landscape, a ❤️ helps other beginners find it too.

Follow me for more on AWS architecture, DevOps, and AI tooling:
sarvarnadaf.com | LinkedIn | Dev.to

Kiro CLI Gets Worse After an Hour. Here's How I Fixed It.

Sarvar Nadaf — Thu, 16 Jul 2026 14:37:01 +0000

Two hours into a Kiro CLI session, it gave me a generic IAM trust policy example. We had literally set up the OIDC provider together 30 minutes earlier. It forgot.

This is not a bug. It has a name: context rot. And once I understood the mechanics, I stopped fighting it and started managing it.

I use Kiro CLI every day. Checking CloudWatch alarms, debugging IAM policies, reviewing security groups, looking at cost reports, setting up infrastructure. It is my go-to tool for anything AWS.

But after a few weeks I noticed the pattern. The longer I keep a session going, the worse Kiro gets. Early in the session it is sharp. Finds the right file, gives the right answer, runs the right command. Two hours later it starts doing odd things. It re-reads files it already looked at. It gives vague answers. It suggests things I already tried.

What actually happens when context fills up

Kiro has up to a 200k token context window (depending on model). Every message you send, every response it gives, every file it reads, every command output: all of it goes into that window. It adds up fast.

A typical morning for me looks like this:

"Check if there are any CloudWatch alarms firing in us-east-1"
"Show me the IAM policy attached to the lambda-processor role"
"Why is this S3 bucket policy denying access from the VPC endpoint"
"Look at the cost explorer data for the last 7 days"
"What EC2 instances are running in the staging account"

Each of those triggers multiple tool calls. Kiro reads files, runs AWS CLI commands, processes the output. By the fifth question, the context window has maybe 30-40% filled.

Sounds fine. That's the trap.

I keep going. I debug a CloudFormation deployment. I check a few security groups. I look at some ECS task definitions. By lunch, I am at 60-70% context usage and Kiro starts struggling.

What struggling looks like:

It runs aws sts get-caller-identity again even though it already knows which account I am in
It re-reads the same terraform files it read an hour ago
Responses get longer and less useful (more filler, less action)
It starts suggesting solutions to problems I already fixed earlier in the session

If you manage 5+ AWS accounts across environments, context fills 3x faster because every describe-instances call across accounts dumps more output into the window.

Why this happens (and why "try harder" does not fix it)

The model can see everything in the context window but it cannot focus on everything equally. Research calls this the "Lost in the Middle" problem. A Stanford paper (Liu et al., 2023) demonstrated that LLMs exhibit a U-shaped attention pattern. They attend strongly to information at the beginning and end of their context window. Everything in the middle gets reduced attention.

A 2025 follow-up study found the effect is strongest when inputs fill up to 50% of the context window. Beyond that, primacy bias weakens and recency bias dominates, meaning the model increasingly favors whatever you talked about in the last few minutes over the rules and context from the start of your session.

The Kiro team calls this phenomenon "context rot." Anthropic's own engineering docs define it directly: "Context must be treated as a finite resource with diminishing marginal returns."

Here is what that means in practice. When the window is full of old conversations about IAM policies, cost reports, and security groups, and you ask about an ECS deployment, the model has to sort through all that irrelevant context to find what matters. It cannot selectively ignore the old stuff. Every token participates in every inference step, regardless of whether it is relevant to your current question.

The really frustrating part: the model does not know it is degraded. It will confidently tell you it is following all your instructions while demonstrably not doing so. You cannot fix this by telling it to "try harder" or "pay more attention." The degradation is architectural, not motivational.

When the context hits 100%, Kiro auto-compacts. It summarizes the old conversation to make room. The problem is that summaries lose detail. That IAM policy you debugged earlier? After compaction, Kiro only remembers "we fixed an IAM issue," not the specific policy ARN or the condition key that was wrong. In measured sessions, auto-compaction can reduce 132,000 tokens to about 2,300, a 98% reduction. The token count is small. The cognitive capital destroyed is enormous.

The 5 failure modes (in order of how often I hit them)

Context rot is the foundation, but it cascades into other behaviors. Once you recognize these patterns, you stop blaming yourself or the model:

1. Context rot itself. Attention on your early instructions fades as the window fills. The model stops following rules it was given at the start. You told it "never modify production resources without asking first" in minute 1. In minute 90, it just runs the command.

2. Pattern matching over reasoning. Instead of checking what actually exists, Kiro copies patterns from earlier in the conversation. It writes an IAM role that duplicates one you already created three prompts ago. It is coding from its conversation context, not from your actual files.

3. Completion bias. When you push back on a bad result, the model does not get more careful. It gets more agreeable. It ships something that looks different but is equally wrong. The angrier you get, the faster it produces plausible-looking garbage to end the conflict.

4. Re-verification loops. The model forgets it already verified something. It calls aws sts get-caller-identity again. It re-reads your terraform state file. It asks "which region are you working in?" for the third time. Each redundant call wastes context and accelerates the rot.

5. Advisory compliance decay. Early in a session, Kiro respects guardrails: "I'll ask before modifying production resources." Late in a session, it rationalizes around them: "Since we've been working in this account, I'll go ahead and apply the change." The constraint fades because the instruction that set it is now buried in the middle of a bloated context window.

What I do now

One task per session

This is the biggest change. I used to keep one session open all day. Now I start a new session for each distinct task.

Debugging a CloudFormation stack failure? New session.
Checking cost reports? New session.
Writing a new Lambda function? New session.

Each session stays focused, context stays small, and Kiro stays sharp. Each wasted minute re-explaining context is a minute I am not solving the actual problem. Over a week, that adds up to 30-60 minutes of lost productivity.

To start a new session in Kiro CLI, just exit and re-enter:

exit
kiro-cli

This gives you a completely fresh session. The old one stays on disk if you need to go back to it.

If you just want to reset the conversation without leaving the process, use /clear:

/clear

The difference: exit + kiro-cli starts a brand new session with a new ID. /clear wipes the conversation but keeps the same process running.

Use /compact before it auto-triggers

If I am in a session that has been going for a while and I am not done yet, I run /compact manually before Kiro does it automatically.

/compact

Why? Because when I trigger it myself, I know what just got summarized. I can immediately re-state the important bits.

After compacting, re-state the important context:

We are debugging a CloudFormation stack called prod-api-gateway that failed 
on an AWS::ApiGateway::RestApi resource. The error was "Invalid stage identifier specified".

Now Kiro has a fresh context with only the relevant details. The same question that took 12 seconds before compaction takes 3 seconds after.

Put persistent context in steering files (the biggest token saver)

Things I tell Kiro every single session (which AWS accounts I work with, naming conventions, preferred regions) go in steering files. Kiro supports three scopes:

Workspace steering (.kiro/steering/), applies to one project:

mkdir -p .kiro/steering

# .kiro/steering/aws-environment.md

## AWS Environment
- Production account: 111111111111 (us-east-1)
- Staging account: 222222222222 (us-east-1)
- Default profile: production
- All infrastructure is in Terraform under /infra

## Preferences
- Use AWS CLI v2 commands
- Always specify --region explicitly
- Check CloudTrail before making IAM changes
- Never modify production resources without asking first

Global steering (~/.kiro/steering/), applies to ALL your workspaces:

# ~/.kiro/steering/aws-defaults.md

## Global AWS Conventions
- Always use --output json for parseable results
- Prefer least-privilege IAM policies (never use * in Resource)
- Tag all resources with Environment, Team, and CostCenter
- Use ap-south-1 as default region unless specified

Global steering is loaded in every session regardless of which project you are in. If workspace steering conflicts with global steering, workspace wins. This is where I put my org-wide standards.

Team steering: you can push steering files to your entire team via MDM or a shared repository. Everyone gets the same conventions without explaining them:

# Team lead pushes to shared repo
git clone internal-repo/kiro-steering ~/.kiro/steering

Kiro automatically loads everything in .kiro/steering/ at the start of every session. Verify what is loaded with /context show.

The difference this makes: my baseline context went from wasting 15-20% on repeated instructions to 0%. Every new session already knows my environment.

Use conditional steering with fileMatch

Not all context is needed all the time. Kiro supports inclusion modes that load steering only when relevant:

---
inclusion: fileMatch
glob: "infra/**/*.tf"
---

# Terraform Conventions
- Use modules for all repeatable infrastructure
- State stored in S3 with DynamoDB locking
- Never hardcode AMI IDs, use data sources

This file only loads when Kiro reads a .tf file under the infra/ directory. When I am working on Lambda code, these Terraform conventions do not eat my context window.

Three modes:

always (default): loaded every session
fileMatch: loaded only when a matching file is in context
manual: loaded only when you invoke it with a slash command

I split my steering into 5 focused files with appropriate modes instead of one giant file. Token usage for steering dropped from 8% of my context to about 3%.

Watch the percentage

Kiro shows context usage in the sidebar. You can also check it explicitly:

/context show

This shows a breakdown: how much your steering files use, how much tools use, how much your conversation uses. My rule of thumb:

Under 40%: keep going, no issues
40-60%: finish current task, then start fresh
Over 60%: responses are getting worse, wrap up now

If you find yourself repeating instructions or Kiro starts re-reading files, do not fight it. Start fresh.

Use knowledge bases for large reference material

If you work with big Terraform repos or lots of CloudFormation templates, do not add them as context files. They will eat your context window on every single request, even when you are not asking about them.

Kiro's /knowledge feature (experimental, enable it first) indexes your files locally and only pulls in relevant chunks when you ask about them:

# Enable the feature
kiro-cli settings chat.enableKnowledge true

# Add your infrastructure code
/knowledge add --name "terraform-infra" --path /path/to/infra --include "**/*.tf" --exclude ".terraform/**"

# Add documentation
/knowledge add --name "runbooks" --path /path/to/runbooks --include "**/*.md" --index-type Best

Two index types matter here:

Fast (lexical/bm25): for code, configs, logs. Quick keyword matching.
Best (semantic): for documentation and runbooks. Understands natural language queries.

I use Fast for my Terraform code (I search by resource names and module names) and Best for our runbooks and architecture decision records (I search by questions like "how do we handle cross-account access").

My baseline context dropped from 35% to 12% after moving Terraform files out of steering and into the knowledge base. Kiro searches your files when needed without them sitting in context all the time.

The knowledge base persists across sessions. Index once, use forever. Run /knowledge update periodically when your files change, or /knowledge update with no arguments to re-index everything at once.

Delegate exploration to sub-agents

This one is underused. When Kiro needs to investigate something (scan a directory, read multiple files, research an error) it can delegate to a sub-agent with its own isolated context window.

Why this matters: if the main session reads 20 files to debug an issue, all 20 files stay in your context forever. If a sub-agent does that exploration, it returns a focused summary and your main context stays clean.

I noticed Kiro does this automatically for some tasks, but you can nudge it:

Investigate why the ECS task is failing to pull from ECR. 
Check the task definition, the ECR repository policy, and the VPC endpoints. 
Give me a summary of the root cause. Do not dump all the raw output.

The key phrase is "give me a summary." It signals that you want focused results, not raw exploration dumped into your session.

A real example

I am currently testing Terraform code for an upcoming EKS article in my Terraform series. The setup is complex: VPC with private subnets, EKS cluster, managed node groups, IAM roles for service accounts, security groups, and add-ons like CoreDNS and kube-proxy.

I started a Kiro session asking it to help me structure the modules. Then I asked it to write the VPC config. Then the EKS cluster resource. Then the node group. Then I asked it to review the IAM OIDC provider setup.

By this point the session had all the previous Terraform code, all the plan outputs, and all my back-and-forth corrections in context.

When I asked "add the aws-load-balancer-controller IAM role with the correct trust policy," Kiro gave me a generic example from the docs. It did not reference my actual cluster name or OIDC provider ARN that we had set up 30 minutes earlier. Gone.

It was like talking to someone who forgot the last hour of conversation.

I ran /clear, started fresh, and said:

I am building a production EKS cluster with Terraform. The cluster is called 
prod-platform in us-east-1. The OIDC provider is already set up. I need an 
IAM role for aws-load-balancer-controller with the correct trust policy that 
references my cluster's OIDC issuer. Here is my existing oidc provider ARN: 
arn:aws:iam::111111111111:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/ABCDEF123456

Kiro immediately gave me the exact trust policy with my ARN, my namespace, my service account name. No generic examples. No confusion with earlier VPC or node group context.

Total time wasted before clearing: 15 minutes of re-explaining.
Time to get the right answer after clearing: 20 seconds.

The context budget cheat sheet

Context Usage	What's Happening	Action
Under 30%	Sharp, focused, fast	Keep working
30-50%	Still good, starting to accumulate noise	Finish current task, then evaluate
50-70%	"Lost in the Middle" kicks in hard	Wrap up NOW or `/compact`
Over 70%	Active degradation: repeating, re-reading, vague answers	Start fresh. Do not push through.
Auto-compaction triggers	98% information loss incoming	You waited too long. `/compact` earlier next time.

What this is NOT

I want to be clear about something. This is not a Kiro-specific bug. Every AI coding tool with a context window has this problem: Claude Code, Cursor, Copilot Chat, Windsurf. The architecture is the same transformer attention mechanism underneath.

The difference is whether you manage context deliberately or let it manage you. Most developers do not think about context at all. They open a session, work for 3 hours, get frustrated that "the AI got dumb," close it, and start fresh the next day.

That cycle wastes an hour of degraded work every single day. Across a team of 5 engineers, that is 25 hours per week of suboptimal AI output. The fix takes zero extra tools. Just awareness and a habit change.

I shared this approach with two engineers on my team. Both had been complaining about Kiro "getting dumb" by afternoon. Turns out they were running single sessions for 4-5 hours straight. Once they switched to session-per-task, the complaints stopped within a day.

The model is not getting dumber. Your context window is getting noisier. Fix the noise, and the model stays as sharp at hour 3 as it was at minute 1.

Links:

Kiro CLI context management: kiro.dev/docs/cli/chat/context/
Steering files documentation: kiro.dev/docs/cli/steering/
Knowledge management (experimental): kiro.dev/docs/cli/experimental/knowledge-management/
/compact command changelog: kiro.dev/changelog/cli/1-24/
Ralph Loop technique: developer.mamezou-tech.com
"Lost in the Middle" research: arxiv.org/abs/2307.03172
Context rot whitepaper (Empromptu): empromptu.ai/resources/context-rot-progressive-prompt-ephemerality

How do you manage long sessions with AI coding tools? Do you start fresh or push through? Drop your approach in the comments. I am genuinely curious if others hit the same wall around the 50% mark or if it depends on the type of work.

Follow me for more on AWS architecture, DevOps, and AI tooling: sarvarnadaf.com | LinkedIn

Secure Database Deployment - RDS + Secrets Manager

Sarvar Nadaf — Mon, 13 Jul 2026 09:40:34 +0000

👋 Hey there, tech enthusiasts!

I'm Sarvar, a Cloud Architect with a passion for transforming complex technological challenges into elegant solutions. With extensive experience spanning Cloud Operations (AWS & Azure), Data Operations, Analytics, DevOps, and Generative AI, I've had the privilege of architecting solutions for global enterprises that drive real business impact. Through this article series, I'm excited to share practical insights, best practices, and hands-on experiences from my journey in the tech world. Whether you're a seasoned professional or just starting out, I aim to break down complex concepts into digestible pieces that you can apply in your projects.

Secure Database Deployment: RDS + Secrets Manager with Terraform

"A password in your code is like leaving your house key under the doormat everyone knows where to look."

🎯 Welcome Back!

Remember in Article 9 when you deployed IAM roles and security policies? You built secure access controls without access keys. Now let's protect your most sensitive asset your data.

Here's the reality: Web servers are stateless. They can crash and restart without losing anything. But what about:

User accounts and profiles?
Shopping cart data?
Transaction history?
Application state?

You need a database. But here's the catch databases hold your most sensitive data, and one mistake can expose everything.

That's where RDS and Secrets Manager come in.

By the end of this article, you'll:

✅ Deploy RDS MySQL database with Terraform
✅ Store credentials securely in AWS Secrets Manager
✅ Never hardcode passwords in your code
✅ Configure private subnets for databases
✅ Set up IAM roles for secure access
✅ Connect EC2 to RDS without access keys

Time Required: 50 minutes (25 min read + 25 min practice)

Cost: ~$15/month for db.t3.micro (free tier eligible for 12 months)

Difficulty: Intermediate

Let's build secure database infrastructure! 🚀

💔 The Problem: Password Catastrophes

The Horror Story

It's Monday morning. Your security team sends this:

SECURITY INCIDENT REPORT
Severity: CRITICAL
Issue: Database credentials found in public GitHub repository
Exposure Time: 6 months
Impact: 500,000 user records potentially compromised
Estimated Cost: $2.5 million (fines + remediation)
Root Cause: Hardcoded password in Terraform code

How it happened:

Developer hardcoded DB password in main.tf
Committed to Git: git commit -m "Add database"
Pushed to GitHub: git push origin main
Security scanner found it 6 months later
By then, password was in 47 commits across 3 branches

The damage:

❌ Password exposed in version control history
❌ Visible in Terraform state file (plain text)
❌ Copied to multiple developer machines
❌ Indexed by GitHub search
❌ Potentially scraped by bots
❌ Impossible to know who accessed it

Common Password Mistakes:

❌ Hardcoded in Code:

resource "aws_db_instance" "db" {
  password = "MyPassword123!"  # Everyone can see this!
}

❌ In Environment Variables:

export DB_PASSWORD="secret123"  # Still visible in shell history

❌ In terraform.tfvars (committed to Git):

db_password = "MySecretPass"  # In version control!

❌ In State File:

{
  "password": "MyPassword123",  // Plain text in S3!
}

❌ Shared via Slack/Email:

"Hey, the DB password is MyPassword123"  // Now it's everywhere

Sound familiar? Let's fix this properly.

🌟 What is AWS Secrets Manager? (Quick Theory)

Simple Definition

AWS Secrets Manager = Encrypted vault for sensitive data. It:

Stores passwords, API keys, tokens securely
Encrypts everything with AWS KMS
Rotates credentials automatically
Provides audit logs of who accessed what
Integrates with IAM for access control

Think of it like this:

Without Secrets Manager:

Developer → Hardcodes password → Git → Everyone sees it → 💥 Breach

With Secrets Manager:

Terraform → Generates password → Secrets Manager (encrypted) → 
EC2 (IAM role) → Retrieves password → Connects to RDS ✅

Why You Need This

Scenario 1: Security Breach

Hardcoded password: Exposed forever in Git history
Secrets Manager: Rotate password in 30 seconds, breach contained
Result: Minimal damage

Scenario 2: Employee Leaves

Hardcoded password: They know all your passwords
Secrets Manager: Revoke IAM access, rotate secrets
Result: Zero risk

Scenario 3: Compliance Audit

Hardcoded password: Fail audit, face fines
Secrets Manager: Pass audit, show encryption + rotation
Result: Compliance achieved

What is RDS?

RDS (Relational Database Service) = Managed database service. AWS handles:

Automated backups
Software patching
Hardware maintenance
High availability
Monitoring and alerts

You focus on: Your application and data, not database administration.

📋 Prerequisites

Before starting, make sure you have:

✅ Completed Article 9: IAM Roles and Security
✅ Terraform installed (v1.0+)
✅ AWS CLI configured
✅ Understanding of VPC and security groups
✅ SSH key pair in AWS

🏗️ What We're Building

Internet
    ↓
EC2 Instance (Public Subnet)
    ↓ (IAM Role)
    ├─→ Secrets Manager (Get Credentials)
    └─→ RDS MySQL (Private Subnet)

Architecture Components:

VPC - Isolated network
Public Subnet - EC2 instance
Private Subnets - RDS database (2 AZs required)
Security Groups - Network firewall
RDS MySQL - Managed database
Secrets Manager - Encrypted credential storage
IAM Role - Secure access without keys

📁 Project Structure

10-rds-secrets/
├── main.tf           # Infrastructure code
├── variables.tf      # Input variables
├── outputs.tf        # Output values
└── terraform.tfvars  # Variable values

🔧 Step 1: Define Variables

Create variables.tf:

# AWS Region
variable "aws_region" {
  description = "AWS region"
  type        = string
  default     = "us-east-1"
}

# Project Name
variable "project_name" {
  description = "Project name"
  type        = string
  default     = "terraform-db"
}

# Environment
variable "environment" {
  description = "Environment name"
  type        = string
  default     = "dev"
}

# VPC CIDR
variable "vpc_cidr" {
  description = "VPC CIDR block"
  type        = string
  default     = "10.0.0.0/16"
}

# Public Subnet CIDR
variable "public_subnet_cidr" {
  description = "Public subnet CIDR"
  type        = string
  default     = "10.0.1.0/24"
}

# Private Subnet CIDRs
variable "private_subnet_1_cidr" {
  description = "Private subnet 1 CIDR"
  type        = string
  default     = "10.0.11.0/24"
}

variable "private_subnet_2_cidr" {
  description = "Private subnet 2 CIDR"
  type        = string
  default     = "10.0.12.0/24"
}

# Database Configuration
variable "db_name" {
  description = "Database name"
  type        = string
  default     = "myappdb"
}

variable "db_username" {
  description = "Database master username"
  type        = string
  default     = "admin"
}

variable "db_instance_class" {
  description = "RDS instance class"
  type        = string
  default     = "db.t3.micro"
}

variable "db_allocated_storage" {
  description = "Allocated storage in GB"
  type        = number
  default     = 20
}

# EC2 Configuration
variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t2.micro"
}

variable "key_name" {
  description = "SSH key pair name"
  type        = string
  default     = "my-key"
}

variable "my_ip" {
  description = "Your IP for SSH access"
  type        = string
  default     = "0.0.0.0/0"
}

Key Points:

No password variable! We'll generate it automatically
Two private subnets required for RDS (multi-AZ)
db.t3.micro - Free tier eligible

🌐 Step 2: Create VPC with Private Subnets

Add to main.tf:

# Terraform Configuration
terraform {
  required_version = ">= 1.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    random = {
      source  = "hashicorp/random"
      version = "~> 3.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

# Data Sources
data "aws_availability_zones" "available" {
  state = "available"
}

data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-*-x86_64"]
  }
}

# Random Password for Database
resource "random_password" "db_password" {
  length  = 16
  special = true
  override_special = "!#$%&*()-_=+[]{}<>:?"
}

# VPC
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name        = "${var.project_name}-vpc"
    Environment = var.environment
    ManagedBy   = "Terraform"
  }
}

# Internet Gateway
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name        = "${var.project_name}-igw"
    Environment = var.environment
  }
}

# Public Subnet
resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = var.public_subnet_cidr
  availability_zone       = data.aws_availability_zones.available.names[0]
  map_public_ip_on_launch = true

  tags = {
    Name = "${var.project_name}-public-subnet"
    Type = "Public"
  }
}

# Private Subnets (for RDS)
resource "aws_subnet" "private_1" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_1_cidr
  availability_zone = data.aws_availability_zones.available.names[0]

  tags = {
    Name = "${var.project_name}-private-subnet-1"
    Type = "Private"
  }
}

resource "aws_subnet" "private_2" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_2_cidr
  availability_zone = data.aws_availability_zones.available.names[1]

  tags = {
    Name = "${var.project_name}-private-subnet-2"
    Type = "Private"
  }
}

# Public Route Table
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }

  tags = {
    Name = "${var.project_name}-public-rt"
  }
}

resource "aws_route_table_association" "public" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public.id
}

New Concept: Random Provider

resource "random_password" "db_password" {
  length  = 16
  special = true
}

Generates a secure random password automatically. Never hardcode passwords!

Why Two Private Subnets?

RDS requires subnets in at least 2 availability zones
Provides high availability
Automatic failover if one AZ fails

🔒 Step 3: Configure Security Groups

Add to main.tf:

# Security Group for EC2
resource "aws_security_group" "ec2" {
  name        = "${var.project_name}-ec2-sg"
  description = "Security group for EC2 instance"
  vpc_id      = aws_vpc.main.id

  ingress {
    description = "SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = [var.my_ip]
  }

  ingress {
    description = "HTTP"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "${var.project_name}-ec2-sg"
  }
}

# Security Group for RDS
resource "aws_security_group" "rds" {
  name        = "${var.project_name}-rds-sg"
  description = "Security group for RDS database"
  vpc_id      = aws_vpc.main.id

  ingress {
    description     = "MySQL from EC2"
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    security_groups = [aws_security_group.ec2.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "${var.project_name}-rds-sg"
  }
}

Security Architecture:

Internet → EC2 (SSH from your IP, HTTP from anywhere)
           ↓
           RDS (MySQL port 3306 ONLY from EC2)

Key Security Practices:

RDS is NOT accessible from internet
RDS only accepts connections from EC2 security group
No direct database access from outside
This is called "defense in depth"

🔐 Step 4: Set Up AWS Secrets Manager

Add to main.tf:

# Secrets Manager Secret
resource "aws_secretsmanager_secret" "db_credentials" {
  name        = "${var.project_name}-db-credentials-${random_password.db_password.id}"
  description = "Database credentials for ${var.project_name}"

  tags = {
    Name        = "${var.project_name}-db-secret"
    Environment = var.environment
  }
}

# Store Database Credentials in Secrets Manager
resource "aws_secretsmanager_secret_version" "db_credentials" {
  secret_id = aws_secretsmanager_secret.db_credentials.id
  secret_string = jsonencode({
    username = var.db_username
    password = random_password.db_password.result
    engine   = "mysql"
    host     = aws_db_instance.main.address
    port     = aws_db_instance.main.port
    dbname   = var.db_name
  })
}

What's Happening:

Create Secret: Empty container for credentials
Store Credentials: JSON with all connection info
Encryption: Automatically encrypted at rest
Access Control: IAM controls who can read it

Secret Structure:

{
  "username": "admin",
  "password": "randomly-generated-16-chars",
  "engine": "mysql",
  "host": "terraform-db.xxxxx.rds.amazonaws.com",
  "port": 3306,
  "dbname": "myappdb"
}

🗄️ Step 5: Deploy RDS MySQL Database

Add to main.tf:

# DB Subnet Group
resource "aws_db_subnet_group" "main" {
  name       = "${var.project_name}-db-subnet-group"
  subnet_ids = [aws_subnet.private_1.id, aws_subnet.private_2.id]

  tags = {
    Name = "${var.project_name}-db-subnet-group"
  }
}

# RDS Instance
resource "aws_db_instance" "main" {
  identifier             = "${var.project_name}-db"
  engine                 = "mysql"
  engine_version         = "8.0"
  instance_class         = var.db_instance_class
  allocated_storage      = var.db_allocated_storage
  storage_type           = "gp3"
  storage_encrypted      = true

  db_name  = var.db_name
  username = var.db_username
  password = random_password.db_password.result

  db_subnet_group_name   = aws_db_subnet_group.main.name
  vpc_security_group_ids = [aws_security_group.rds.id]

  backup_retention_period = 7
  backup_window          = "03:00-04:00"
  maintenance_window     = "mon:04:00-mon:05:00"

  skip_final_snapshot       = true
  final_snapshot_identifier = "${var.project_name}-final-snapshot"

  enabled_cloudwatch_logs_exports = ["error", "general", "slowquery"]

  tags = {
    Name        = "${var.project_name}-db"
    Environment = var.environment
  }
}

Breaking Down the Configuration:

1. DB Subnet Group:

subnet_ids = [aws_subnet.private_1.id, aws_subnet.private_2.id]

Tells RDS which subnets to use (must be in different AZs).

2. Storage:

storage_type      = "gp3"
storage_encrypted = true

gp3 - Latest generation SSD (better performance)
storage_encrypted - Encryption at rest

3. Backups:

backup_retention_period = 7
backup_window          = "03:00-04:00"

Automatic daily backups
Retained for 7 days
Runs at 3 AM UTC

4. Maintenance:

maintenance_window = "mon:04:00-mon:05:00"

AWS performs updates during this window.

5. CloudWatch Logs:

enabled_cloudwatch_logs_exports = ["error", "general", "slowquery"]

Sends MySQL logs to CloudWatch for monitoring.

👤 Step 6: Create IAM Role for EC2

Add to main.tf:

# IAM Role for EC2 to access Secrets Manager
resource "aws_iam_role" "ec2_secrets_role" {
  name = "${var.project_name}-ec2-secrets-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "ec2.amazonaws.com"
      }
    }]
  })

  tags = {
    Name = "${var.project_name}-ec2-role"
  }
}

# IAM Policy for Secrets Manager Access
resource "aws_iam_role_policy" "secrets_access" {
  name = "${var.project_name}-secrets-policy"
  role = aws_iam_role.ec2_secrets_role.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Action = [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ]
      Resource = aws_secretsmanager_secret.db_credentials.arn
    }]
  })
}

# Instance Profile
resource "aws_iam_instance_profile" "ec2_profile" {
  name = "${var.project_name}-ec2-profile"
  role = aws_iam_role.ec2_secrets_role.name
}

Understanding IAM Components:

1. IAM Role:

Identity that EC2 can assume
No permanent credentials needed

2. Assume Role Policy:

{
  "Principal": {
    "Service": "ec2.amazonaws.com"
  }
}

Says "EC2 service can use this role"

3. IAM Policy:

{
  "Action": [
    "secretsmanager:GetSecretValue"
  ],
  "Resource": "arn:aws:secretsmanager:..."
}

Grants permission to read ONLY this specific secret.

4. Instance Profile:
Attaches the role to EC2 instance.

Security Benefits:

✅ No access keys on EC2
✅ Credentials rotate automatically
✅ Least privilege access
✅ Auditable in CloudTrail

🖥️ Step 7: Deploy EC2 with Database Access

Add to main.tf:

# EC2 Instance
resource "aws_instance" "app" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = var.instance_type
  key_name      = var.key_name
  subnet_id     = aws_subnet.public.id

  vpc_security_group_ids = [aws_security_group.ec2.id]
  iam_instance_profile   = aws_iam_instance_profile.ec2_profile.name

  user_data = <<-EOF
              #!/bin/bash
              yum update -y
              yum install -y mysql jq aws-cli

              # Get database credentials from Secrets Manager
              SECRET_ARN="${aws_secretsmanager_secret.db_credentials.arn}"
              SECRET_JSON=$(aws secretsmanager get-secret-value --secret-id $SECRET_ARN --region ${var.aws_region} --query SecretString --output text)

              DB_HOST=$(echo $SECRET_JSON | jq -r '.host')
              DB_PORT=$(echo $SECRET_JSON | jq -r '.port')
              DB_USER=$(echo $SECRET_JSON | jq -r '.username')
              DB_PASS=$(echo $SECRET_JSON | jq -r '.password')
              DB_NAME=$(echo $SECRET_JSON | jq -r '.dbname')

              # Create connection script
              cat > /home/ec2-user/connect-db.sh <<SCRIPT
              #!/bin/bash
              mysql -h $DB_HOST -P $DB_PORT -u $DB_USER -p$DB_PASS $DB_NAME
SCRIPT

              chmod +x /home/ec2-user/connect-db.sh
              chown ec2-user:ec2-user /home/ec2-user/connect-db.sh

              # Create info file
              cat > /home/ec2-user/db-info.txt <<INFO
              Database Connection Information
              ================================
              Host: $DB_HOST
              Port: $DB_PORT
              Database: $DB_NAME
              Username: $DB_USER

              To connect: ./connect-db.sh
INFO

              chown ec2-user:ec2-user /home/ec2-user/db-info.txt
              EOF

  tags = {
    Name        = "${var.project_name}-app-server"
    Environment = var.environment
  }

  depends_on = [
    aws_db_instance.main,
    aws_secretsmanager_secret_version.db_credentials
  ]
}

User Data Magic:

Install Tools:

yum install -y mysql jq aws-cli

mysql - Database client
jq - JSON parser
aws-cli - AWS commands

Fetch Credentials:

aws secretsmanager get-secret-value --secret-id $SECRET_ARN

Uses IAM role (no keys needed!)

Parse JSON:

DB_HOST=$(echo $SECRET_JSON | jq -r '.host')

Extracts values from JSON.

Create Helper Script:

cat > /home/ec2-user/connect-db.sh

User can run ./connect-db.sh to connect to database.

Depends On:

depends_on = [
  aws_db_instance.main,
  aws_secretsmanager_secret_version.db_credentials
]

Ensures database and secrets exist before EC2 starts.

📤 Step 8: Define Outputs

Create outputs.tf:

# VPC Outputs
output "vpc_id" {
  description = "VPC ID"
  value       = aws_vpc.main.id
}

# Subnet Outputs
output "public_subnet_id" {
  description = "Public subnet ID"
  value       = aws_subnet.public.id
}

output "private_subnet_ids" {
  description = "Private subnet IDs"
  value       = [aws_subnet.private_1.id, aws_subnet.private_2.id]
}

# RDS Outputs
output "rds_endpoint" {
  description = "RDS endpoint"
  value       = aws_db_instance.main.endpoint
}

output "rds_address" {
  description = "RDS address"
  value       = aws_db_instance.main.address
}

output "rds_port" {
  description = "RDS port"
  value       = aws_db_instance.main.port
}

output "database_name" {
  description = "Database name"
  value       = aws_db_instance.main.db_name
}

# Secrets Manager Output
output "secret_arn" {
  description = "Secrets Manager secret ARN"
  value       = aws_secretsmanager_secret.db_credentials.arn
}

output "secret_name" {
  description = "Secrets Manager secret name"
  value       = aws_secretsmanager_secret.db_credentials.name
}

# EC2 Output
output "ec2_public_ip" {
  description = "EC2 instance public IP"
  value       = aws_instance.app.public_ip
}

output "ec2_instance_id" {
  description = "EC2 instance ID"
  value       = aws_instance.app.id
}

# Connection String (Sensitive)
output "connection_command" {
  description = "MySQL connection command"
  value       = "mysql -h ${aws_db_instance.main.address} -P ${aws_db_instance.main.port} -u ${var.db_username} -p ${var.db_name}"
  sensitive   = true
}

Sensitive Outputs:

sensitive = true

Hides output value from terminal. Use terraform output connection_command to view.

⚙️ Step 9: Set Variable Values

Create terraform.tfvars:

aws_region = "us-east-1"
project_name = "terraform-db"
environment = "dev"

# Network Configuration
vpc_cidr = "10.0.0.0/16"
public_subnet_cidr = "10.0.1.0/24"
private_subnet_1_cidr = "10.0.11.0/24"
private_subnet_2_cidr = "10.0.12.0/24"

# Database Configuration
db_name = "myappdb"
db_username = "admin"
db_instance_class = "db.t3.micro"
db_allocated_storage = 20

# EC2 Configuration
instance_type = "t2.micro"
key_name = "my-key"
my_ip = "0.0.0.0/0"

🚀 Step 10: Deploy the Infrastructure

1. Initialize Terraform

terraform init

2. Review the Plan

terraform plan

You should see:

Plan: 17 to add, 0 to change, 0 to destroy.

Resources being created:

1 VPC
1 Internet Gateway
3 Subnets (1 public, 2 private)
1 Route Table
2 Security Groups
1 Random Password
1 Secrets Manager Secret + Version
1 DB Subnet Group
1 RDS Instance
1 IAM Role + Policy + Instance Profile
1 EC2 Instance

3. Apply the Configuration

terraform apply

Type yes when prompted.

⏰ This will take 5-10 minutes because:

RDS takes 5-7 minutes to provision
Multi-AZ setup requires time
Backups need to be configured

✅ Step 11: Test Database Connection

1. Get EC2 Public IP

terraform output ec2_public_ip

2. SSH to EC2 Instance

ssh -i my-key.pem ec2-user@<EC2_PUBLIC_IP>

3. Check Database Info

cat db-info.txt

Output:

Database Connection Information
================================
Host: terraform-db.xxxxx.us-east-1.rds.amazonaws.com
Port: 3306
Database: myappdb
Username: admin

To connect: ./connect-db.sh

4. Connect to Database

./connect-db.sh

You're now connected to MySQL!

5. Test Database

-- Show databases
SHOW DATABASES;

-- Create a table
CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Insert data
INSERT INTO users (name, email) VALUES 
    ('John Doe', 'john@example.com'),
    ('Jane Smith', 'jane@example.com');

-- Query data
SELECT * FROM users;

-- Exit
EXIT;

🔍 Verify Secrets Manager

From Your Local Machine

# Get secret ARN
SECRET_ARN=$(terraform output -raw secret_arn)

# Retrieve secret
aws secretsmanager get-secret-value \
  --secret-id $SECRET_ARN \
  --query SecretString \
  --output text | jq .

Output:

{
  "username": "admin",
  "password": "Xy9#mK2$pL5@qR8!",
  "engine": "mysql",
  "host": "terraform-db.xxxxx.rds.amazonaws.com",
  "port": 3306,
  "dbname": "myappdb"
}

Notice: Password is randomly generated and securely stored!

🧪 Advanced Testing

Test IAM Role Access

# SSH to EC2
ssh -i my-key.pem ec2-user@<EC2_IP>

# Try to get secret (should work)
aws secretsmanager get-secret-value \
  --secret-id <SECRET_ARN> \
  --region us-east-1

# Try to delete secret (should fail - no permission)
aws secretsmanager delete-secret \
  --secret-id <SECRET_ARN> \
  --region us-east-1

Test Database Backups

# List automated backups
aws rds describe-db-snapshots \
  --db-instance-identifier terraform-db-db

# Create manual snapshot
aws rds create-db-snapshot \
  --db-instance-identifier terraform-db-db \
  --db-snapshot-identifier terraform-db-manual-snapshot

Monitor Database

# Check database status
aws rds describe-db-instances \
  --db-instance-identifier terraform-db-db \
  --query 'DBInstances[0].DBInstanceStatus'

# View CloudWatch logs
aws logs tail /aws/rds/instance/terraform-db-db/error --follow

🐛 Troubleshooting

Issue 1: "Cannot connect to database"

Cause: RDS still provisioning or security group issue.

Solution:

# Check RDS status
aws rds describe-db-instances \
  --db-instance-identifier terraform-db-db \
  --query 'DBInstances[0].DBInstanceStatus'

# Should show "available"

# Check security group
aws ec2 describe-security-groups \
  --group-ids <RDS_SG_ID>

Issue 2: "Access Denied" when getting secret

Cause: IAM role not attached or policy incorrect.

Solution:

# Check instance profile
aws ec2 describe-instances \
  --instance-ids <INSTANCE_ID> \
  --query 'Reservations[0].Instances[0].IamInstanceProfile'

# Should show the instance profile

# Check IAM role policies
aws iam list-role-policies --role-name terraform-db-ec2-secrets-role

Issue 3: RDS creation fails

Error:

Error: DB Subnet Group doesn't meet availability zone coverage requirement

Solution: Ensure private subnets are in different AZs:

availability_zone = data.aws_availability_zones.available.names[0]  # First AZ
availability_zone = data.aws_availability_zones.available.names[1]  # Second AZ

Issue 4: "mysql: command not found"

Cause: User data script hasn't completed.

Solution:

# Wait 2-3 minutes after instance launch

# Check user data logs
sudo cat /var/log/cloud-init-output.log

# Manually install if needed
sudo yum install -y mysql

💰 Cost Breakdown

Monthly Costs (us-east-1):

Resource	Quantity	Cost/Month	Total
db.t3.micro RDS	1	$12.41	$12.41
Storage (20 GB gp3)	20 GB	$2.30	$2.30
Backup Storage (20 GB)	20 GB	$0.95	$0.95
t2.micro EC2	1	$8.50	$8.50
Secrets Manager	1 secret	$0.40	$0.40
Total			~$24.56

Free Tier Benefits:

750 hours/month of db.t3.micro (first 12 months)
750 hours/month of t2.micro
20 GB storage
Actual cost with free tier: ~$1.35/month

Cost Optimization:

Use free tier instances
Delete when not in use
Reduce backup retention (7 days → 1 day)
Use smaller storage (20 GB → 10 GB minimum)

🔐 Security Best Practices

✅ What We Did Right

No Hardcoded Passwords
- Generated automatically
- Stored encrypted
- Never in code
Private Subnets for Database
- No internet access
- Only accessible from EC2
Security Group Restrictions
- RDS only accepts connections from EC2
- Least privilege access
IAM Roles Instead of Keys
- No access keys on EC2
- Automatic credential rotation
- Auditable access
Encryption
- Storage encrypted at rest
- Secrets encrypted in Secrets Manager
- TLS for connections
Automated Backups
- 7-day retention
- Point-in-time recovery
- Disaster recovery ready

🔒 Additional Security Recommendations

For Production:

Enable Multi-AZ:

multi_az = true

Use Parameter Groups:

resource "aws_db_parameter_group" "main" {
  family = "mysql8.0"

  parameter {
    name  = "slow_query_log"
    value = "1"
  }
}

Enable Enhanced Monitoring:

monitoring_interval = 60
monitoring_role_arn = aws_iam_role.rds_monitoring.arn

Use Secrets Rotation:

resource "aws_secretsmanager_secret_rotation" "db" {
  secret_id           = aws_secretsmanager_secret.db_credentials.id
  rotation_lambda_arn = aws_lambda_function.rotate.arn

  rotation_rules {
    automatically_after_days = 30
  }
}

Enable Deletion Protection:

deletion_protection = true

🧹 Cleanup

Important: RDS deletion takes 5-10 minutes.

# Destroy everything
terraform destroy

# Type 'yes' when prompted

What gets deleted:

✅ EC2 Instance
✅ RDS Database
✅ Secrets Manager Secret
✅ IAM Roles and Policies
✅ Security Groups
✅ VPC and Subnets

Verify deletion:

# Check RDS
aws rds describe-db-instances

# Check Secrets
aws secretsmanager list-secrets

📚 Key Concepts Learned

1. Random Provider

resource "random_password" "db_password" {
  length = 16
}

Generate secure random values.

2. AWS Secrets Manager

resource "aws_secretsmanager_secret_version" "db" {
  secret_string = jsonencode({...})
}

Secure credential storage.

3. IAM Roles for EC2

resource "aws_iam_role" "ec2_role" {
  assume_role_policy = jsonencode({...})
}

No access keys needed!

4. RDS Configuration

resource "aws_db_instance" "main" {
  storage_encrypted = true
  backup_retention_period = 7
}

Managed database with backups.

5. Sensitive Outputs

output "password" {
  sensitive = true
}

Hide sensitive data from logs.

6. Depends On

depends_on = [aws_db_instance.main]

Control resource creation order.

🎯 Real-World Applications

This architecture is used for:

1. Web Applications

WordPress with RDS
E-commerce platforms
SaaS applications

2. API Backends

REST APIs with database
GraphQL servers
Microservices

3. Data Analytics

ETL pipelines
Reporting systems
Data warehouses

4. Mobile Backends

User authentication
Content management
Push notifications

🚀 What's Next?

Congratulations! You've completed the Terraform By Sarvar foundation series! 🎉

You now know how to:

Build complete AWS infrastructure with Terraform
Deploy VPCs, EC2, Lambda, IAM, and RDS
Secure everything with IAM roles and Secrets Manager
Follow production-ready best practices

Stay tuned for advanced topics:

Terraform Modules
Remote State Management
Multi-Environment Setup
CI/CD Integration

📖 Additional Resources

Official Documentation:

📂 Source Code

The complete source code and Terraform configuration used in this article can be found on GitHub:

simplynadaf / terraform-by-sarvar

Terraform Series

🚀 Terraform By Sarvar

Complete Terraform tutorial series from basics to advanced concepts

📖 Read the Series • 🌐 Portfolio • 💼 LinkedIn

📚 Series Overview

This repository contains ONLY Terraform code examples for the Terraform By Sarvar tutorial series.

⚠️ IMPORTANT: This repo contains only .tf files and infrastructure code. Articles are published on dev.to, not stored here.

📖 Read the series on dev.to: https://dev.to/sarvar_04/series/36963

🎯 What You'll Learn

✅ Infrastructure as Code (IaC) fundamentals
✅ Terraform basics to advanced concepts
✅ AWS resource provisioning
✅ Best practices and real-world patterns
✅ Production-ready configurations

📊 Series Progress

📖 Article Series

📘 Foundation (Articles 1-5) ✅ Complete

Introduction to Terraform & IaC - ✅ Published
Installation & Setup - ✅ Published
Your First AWS Resource - ✅ Published
Understanding Terraform State - ✅ Published
Variables and Outputs - ✅ Published

📗 Real Infrastructure (Articles 6-10) ✅ Complete

Building a VPC…

View on GitHub

Getting Started

Follow these steps to run the project on your local machine:

Clone the repository:

git clone https://github.com/simplynadaf/terraform-by-sarvar.git

Navigate to the project directory:

cd terraform-by-sarvar/articles/10-rds-secrets

📌 Wrapping Up

Thank you for reading. I hope this article provided practical insights and a clearer understanding of the topic.

If you found this useful:

❤️ Like if it added value
🦄 Unicorn if you’re applying it today
💾 Save it for your next optimization session
🔄 Share it with your team

💡 What’s Next

More deep dives are coming soon on:

Cloud Operations
GenAI & Agentic AI
DevOps Automation
Data & Platform Engineering

Follow along for weekly insights and hands-on guides.

🌐 Portfolio & Work

You can explore my full body of work, certifications, architecture projects, and technical articles here:

👉 Visit My Website

🛠️ Services I Offer

If you're looking for hands-on guidance or collaboration, I provide:

Cloud Architecture Consulting (AWS / Azure)
DevSecOps & Automation Design
FinOps Optimization Reviews
Technical Writing (Cloud, DevOps, GenAI)
Product & Architecture Reviews
Mentorship & 1:1 Technical Guidance

🤝 Let’s Connect

I’d love to hear your thoughts. Feel free to drop a comment or connect with me on:

🔗 LinkedIn

For collaborations, consulting, or technical discussions, reach out at:

📧 simplynadaf@gmail.com

Found this helpful? Share it with your team.

⭐ Star the repo • 📖 Follow the series • 💬 Ask questions

Made by Sarvar Nadaf

🌐 https://sarvarnadaf.com

AWS IAM Roles with Terraform: Security Best Practices

Sarvar Nadaf — Mon, 13 Jul 2026 09:39:23 +0000

👋 Hey there, tech enthusiasts!

AWS IAM Roles with Terraform: Security Best Practices

"Access keys are like house keys lose them once and you have to change all the locks. IAM roles are like a doorman who knows who you are."

🎯 Welcome Back!

Remember in Article 8 when you deployed Lambda with API Gateway? You used IAM roles to let Lambda access S3 and CloudWatch. That was just the beginning.

Here's the reality: Every AWS service needs permissions. And there are two ways to grant them:

Access Keys - Like giving everyone a copy of your house key
IAM Roles - Like having a smart lock that knows who should enter

Most developers start with access keys because they're simple. Then they face:

Keys leaked in Git repositories
Keys stolen from compromised servers
Keys that never expire
No idea who's using which keys
Nightmare rotation process

That's where IAM roles save you.

By the end of this article, you'll:

✅ Create IAM roles and policies with Terraform
✅ Implement least privilege access
✅ Use instance profiles for EC2
✅ Attach AWS managed policies
✅ Create custom IAM policies
✅ Configure S3 bucket policies
✅ Never use access keys again

Time Required: 45 minutes (25 min read + 20 min practice)

Cost: $0 (IAM is free, only pay for resources used)

Difficulty: Intermediate

Let's secure your infrastructure properly! 🚀

💔 The Problem: Access Key Disasters

The Nightmare Scenario

It's 3 AM. Your phone explodes with alerts:

AWS BILLING ALERT
Unusual Activity Detected
Current Charges: $47,000 and climbing
Services: 500 EC2 instances in 12 regions
Cryptocurrency mining detected
Estimated Time: Started 6 hours ago

What happened:

Developer put AWS access keys in code
Committed to public GitHub repo
Bot scraped keys within 15 minutes
Attacker launched mining operation
Your bill: $47,000 in one night

This is a real scenario that happens daily.

Common Access Key Mistakes:

❌ Hardcoded in Application:

# app.py
AWS_ACCESS_KEY = "AKIAIOSFODNN7EXAMPLE"
AWS_SECRET_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCY"

❌ In Environment Variables (on EC2):

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG"

❌ In Docker Images:

ENV AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
ENV AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG

❌ In Configuration Files:

# config.yml
aws:
  access_key: AKIAIOSFODNN7EXAMPLE
  secret_key: wJalrXUtnFEMI/K7MDENG

❌ Shared in Slack/Email:

"Hey, use these keys for the dev environment:
Access Key: AKIAIOSFODNN7EXAMPLE
Secret: wJalrXUtnFEMI/K7MDENG"

The Real Cost:

💰 Financial: $47K average for crypto mining attacks
🔒 Security: Data breaches, compliance violations
⏰ Time: Days to investigate and remediate
😰 Stress: Explaining to management why this happened
📉 Reputation: Customer trust damaged

Sound familiar? Let's fix this permanently.

🌟 What are IAM Roles? (Quick Theory)

Simple Definition

IAM Role = Temporary credentials that AWS services can assume. Think of it as:

A badge that proves who you are
Automatically renewed every hour
Can't be stolen because it's not stored anywhere
Specific to one service or resource

IAM Policy = List of permissions. What you're allowed to do.

Think of it like this:

Access Keys (Bad):

Developer → Creates keys → Puts in code → Git → 
Everyone has keys → 💥 Leaked → Attacker uses them

IAM Roles (Good):

EC2 Instance → Assumes role → AWS gives temporary credentials →
Uses them for 1 hour → Automatically renewed → 
Can't be stolen (not stored anywhere) ✅

Why You Need This

Scenario 1: Developer Leaves Company

Access Keys: They still have keys, can access everything
IAM Roles: Revoke their IAM access, all roles stop working instantly
Result: Zero risk

Scenario 2: Server Compromised

Access Keys: Attacker steals keys, uses them forever
IAM Roles: Temporary credentials expire in 1 hour, limited damage
Result: Contained breach

Scenario 3: Compliance Audit

Access Keys: "Who used this key?" → No idea
IAM Roles: CloudTrail shows exactly who did what, when
Result: Pass audit

IAM Components

1. Role - Identity that can be assumed
2. Policy - Permissions (what you can do)
3. Trust Policy - Who can assume the role
4. Instance Profile - Attaches role to EC2

Example:

EC2 Instance → Instance Profile → IAM Role → IAM Policy → S3 Access ✅

EC2 Instance → Instance Profile → IAM Role → IAM Policy → S3 Access ✅

📋 Prerequisites

Before starting, make sure you have:

✅ Completed Article 8: Lambda Serverless
✅ Terraform installed (v1.0+)
✅ AWS CLI configured
✅ Basic understanding of AWS permissions
✅ SSH key pair in AWS

🏗️ What We're Building

EC2 Instance
    ↓ (IAM Role)
    ├─→ S3 Bucket (Read/Write)
    ├─→ CloudWatch (Metrics/Logs)
    └─→ SSM (Session Manager)

Lambda Function
    ↓ (IAM Role)
    └─→ S3 Bucket (Read Only)

Components:

IAM Roles - Identity for services
IAM Policies - Permissions
Instance Profile - Attaches role to EC2
S3 Bucket Policy - Resource-based access
Managed Policies - AWS pre-built policies
Custom Policies - Your specific permissions

📁 Project Structure

09-iam-security/
├── main.tf
├── variables.tf
├── outputs.tf
└── terraform.tfvars

🔧 Step 1: Define Variables

Create variables.tf:

variable "aws_region" {
  description = "AWS region"
  type        = string
  default     = "us-east-1"
}

variable "project_name" {
  description = "Project name"
  type        = string
  default     = "terraform-iam"
}

variable "environment" {
  description = "Environment"
  type        = string
  default     = "dev"
}

variable "s3_bucket_name" {
  description = "S3 bucket name (must be globally unique)"
  type        = string
  default     = "terraform-iam-demo-bucket-2026"
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t2.micro"
}

variable "key_name" {
  description = "SSH key pair name"
  type        = string
  default     = "my-key"
}

variable "my_ip" {
  description = "Your IP for SSH"
  type        = string
  default     = "0.0.0.0/0"
}

🪣 Step 2: Create S3 Bucket with Policy

Add to main.tf:

terraform {
  required_version = ">= 1.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]
  filter {
    name   = "name"
    values = ["al2023-ami-*-x86_64"]
  }
}

# S3 Bucket
resource "aws_s3_bucket" "app_bucket" {
  bucket        = var.s3_bucket_name
  force_destroy = true

  tags = {
    Name        = var.s3_bucket_name
    Environment = var.environment
    ManagedBy   = "Terraform"
  }
}

resource "aws_s3_bucket_versioning" "app_bucket" {
  bucket = aws_s3_bucket.app_bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

# S3 Bucket Policy
resource "aws_s3_bucket_policy" "app_bucket" {
  bucket = aws_s3_bucket.app_bucket.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "AllowEC2RoleAccess"
        Effect = "Allow"
        Principal = {
          AWS = aws_iam_role.ec2_role.arn
        }
        Action = [
          "s3:GetObject",
          "s3:PutObject",
          "s3:ListBucket"
        ]
        Resource = [
          aws_s3_bucket.app_bucket.arn,
          "${aws_s3_bucket.app_bucket.arn}/*"
        ]
      },
      {
        Sid    = "DenyUnencryptedUploads"
        Effect = "Deny"
        Principal = "*"
        Action = "s3:PutObject"
        Resource = "${aws_s3_bucket.app_bucket.arn}/*"
        Condition = {
          StringNotEquals = {
            "s3:x-amz-server-side-encryption" = "AES256"
          }
        }
      }
    ]
  })
}

Understanding Bucket Policy:

Statement 1: Allow EC2 Role

{
  "Principal": { "AWS": "arn:aws:iam::123456789012:role/ec2-role" },
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": ["arn:aws:s3:::bucket/*"]
}

Allows our EC2 role to read/write objects.

Statement 2: Enforce Encryption

{
  "Effect": "Deny",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

Blocks unencrypted uploads. Security best practice!

👤 Step 3: Create IAM Role for EC2

Add to main.tf:

# IAM Role for EC2
resource "aws_iam_role" "ec2_role" {
  name = "${var.project_name}-ec2-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "ec2.amazonaws.com"
      }
    }]
  })

  tags = {
    Name = "${var.project_name}-ec2-role"
  }
}

Assume Role Policy:

{
  "Principal": {
    "Service": "ec2.amazonaws.com"
  }
}

This says: "EC2 service can assume this role"

Key Concepts:

Role = Identity (who)
Assume Role Policy = Trust policy (who can use this role)
Permissions Policy = What the role can do

📜 Step 4: Create Custom IAM Policy

Add to main.tf:

# Custom IAM Policy for S3 Access
resource "aws_iam_policy" "s3_access" {
  name        = "${var.project_name}-s3-access"
  description = "Allow S3 access for application"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "s3:GetObject",
          "s3:PutObject",
          "s3:DeleteObject",
          "s3:ListBucket"
        ]
        Resource = [
          aws_s3_bucket.app_bucket.arn,
          "${aws_s3_bucket.app_bucket.arn}/*"
        ]
      }
    ]
  })
}

# Attach S3 Policy to EC2 Role
resource "aws_iam_role_policy_attachment" "ec2_s3" {
  role       = aws_iam_role.ec2_role.name
  policy_arn = aws_iam_policy.s3_access.arn
}

Policy Structure:

{
  "Effect": "Allow",           // Allow or Deny
  "Action": ["s3:GetObject"],  // What actions
  "Resource": ["arn:..."]      // On which resources
}

Resource ARN Patterns:

arn:aws:s3:::bucket - The bucket itself
arn:aws:s3:::bucket/* - Objects in the bucket

Least Privilege:

Only allows specific actions
Only on specific bucket
No wildcard permissions

🔗 Step 5: Attach AWS Managed Policies

Add to main.tf:

# Attach CloudWatch Policy
resource "aws_iam_role_policy_attachment" "ec2_cloudwatch" {
  role       = aws_iam_role.ec2_role.name
  policy_arn = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"
}

# Attach SSM Policy (for Session Manager)
resource "aws_iam_role_policy_attachment" "ec2_ssm" {
  role       = aws_iam_role.ec2_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

# Instance Profile
resource "aws_iam_instance_profile" "ec2_profile" {
  name = "${var.project_name}-ec2-profile"
  role = aws_iam_role.ec2_role.name
}

AWS Managed Policies:

Pre-built by AWS
Maintained and updated by AWS
Follow best practices
Use when possible!

Common Managed Policies:

CloudWatchAgentServerPolicy - Send metrics/logs
AmazonSSMManagedInstanceCore - Session Manager access
AmazonS3ReadOnlyAccess - Read S3
AWSLambdaBasicExecutionRole - Lambda logging

Instance Profile:
Attaches IAM role to EC2 instance. Required!

🔐 Step 6: Create Lambda IAM Role

Add to main.tf:

# IAM Role for Lambda
resource "aws_iam_role" "lambda_role" {
  name = "${var.project_name}-lambda-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "lambda.amazonaws.com"
      }
    }]
  })

  tags = {
    Name = "${var.project_name}-lambda-role"
  }
}

# Lambda Basic Execution Policy
resource "aws_iam_role_policy_attachment" "lambda_basic" {
  role       = aws_iam_role.lambda_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

# Custom Lambda Policy for S3 Read-Only
resource "aws_iam_policy" "lambda_s3_read" {
  name        = "${var.project_name}-lambda-s3-read"
  description = "Allow Lambda to read from S3"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Action = [
        "s3:GetObject",
        "s3:ListBucket"
      ]
      Resource = [
        aws_s3_bucket.app_bucket.arn,
        "${aws_s3_bucket.app_bucket.arn}/*"
      ]
    }]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_s3" {
  role       = aws_iam_role.lambda_role.name
  policy_arn = aws_iam_policy.lambda_s3_read.arn
}

Different Assume Role Policy:

{
  "Principal": {
    "Service": "lambda.amazonaws.com"  // Lambda, not EC2!
  }
}

Least Privilege for Lambda:

Only GetObject and ListBucket
No PutObject or DeleteObject
Read-only access

🖥️ Step 7: Deploy EC2 with IAM Role

Add to main.tf:

# Security Group for EC2
resource "aws_security_group" "ec2" {
  name        = "${var.project_name}-ec2-sg"
  description = "Security group for EC2"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = [var.my_ip]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "${var.project_name}-ec2-sg"
  }
}

# EC2 Instance
resource "aws_instance" "app" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = var.instance_type
  key_name      = var.key_name

  iam_instance_profile   = aws_iam_instance_profile.ec2_profile.name
  vpc_security_group_ids = [aws_security_group.ec2.id]

  user_data = <<-EOF
              #!/bin/bash
              yum update -y
              yum install -y aws-cli

              # Create test file
              echo "Hello from Terraform IAM Demo" > /home/ec2-user/test.txt
              chown ec2-user:ec2-user /home/ec2-user/test.txt

              # Create helper scripts
              cat > /home/ec2-user/test-s3.sh <<'SCRIPT'
              #!/bin/bash
              echo "Testing S3 Access..."

              # List bucket
              echo "1. Listing bucket contents:"
              aws s3 ls s3://${var.s3_bucket_name}/

              # Upload file
              echo "2. Uploading test file:"
              aws s3 cp /home/ec2-user/test.txt s3://${var.s3_bucket_name}/test.txt

              # Download file
              echo "3. Downloading file:"
              aws s3 cp s3://${var.s3_bucket_name}/test.txt /home/ec2-user/downloaded.txt

              echo "S3 test complete!"
SCRIPT

              chmod +x /home/ec2-user/test-s3.sh
              chown ec2-user:ec2-user /home/ec2-user/test-s3.sh

              # Create IAM info script
              cat > /home/ec2-user/show-iam-info.sh <<'SCRIPT'
              #!/bin/bash
              echo "=== IAM Role Information ==="
              echo "Instance Profile:"
              curl -s http://169.254.169.254/latest/meta-data/iam/info | jq .

              echo -e "\n=== Current IAM Identity ==="
              aws sts get-caller-identity

              echo -e "\n=== Attached Policies ==="
              ROLE_NAME=$(aws sts get-caller-identity --query Arn --output text | cut -d'/' -f2)
              aws iam list-attached-role-policies --role-name $ROLE_NAME 2>/dev/null || echo "Cannot list policies (expected)"
SCRIPT

              chmod +x /home/ec2-user/show-iam-info.sh
              chown ec2-user:ec2-user /home/ec2-user/show-iam-info.sh
              EOF

  tags = {
    Name        = "${var.project_name}-instance"
    Environment = var.environment
  }
}

Key Line:

iam_instance_profile = aws_iam_instance_profile.ec2_profile.name

This attaches the IAM role to EC2!

User Data Scripts:

test-s3.sh - Test S3 permissions
show-iam-info.sh - Show IAM role info

📤 Step 8: Define Outputs

Create outputs.tf:

# S3 Bucket Output
output "s3_bucket_name" {
  description = "S3 bucket name"
  value       = aws_s3_bucket.app_bucket.id
}

output "s3_bucket_arn" {
  description = "S3 bucket ARN"
  value       = aws_s3_bucket.app_bucket.arn
}

# IAM Role Outputs
output "ec2_role_name" {
  description = "EC2 IAM role name"
  value       = aws_iam_role.ec2_role.name
}

output "ec2_role_arn" {
  description = "EC2 IAM role ARN"
  value       = aws_iam_role.ec2_role.arn
}

output "lambda_role_name" {
  description = "Lambda IAM role name"
  value       = aws_iam_role.lambda_role.name
}

# EC2 Output
output "ec2_public_ip" {
  description = "EC2 public IP"
  value       = aws_instance.app.public_ip
}

output "ec2_instance_id" {
  description = "EC2 instance ID"
  value       = aws_instance.app.id
}

# Test Commands
output "test_commands" {
  description = "Commands to test IAM permissions"
  value = <<-EOT
    SSH to EC2:
    ssh -i ${var.key_name}.pem ec2-user@${aws_instance.app.public_ip}

    Test S3 access:
    aws s3 ls s3://${aws_s3_bucket.app_bucket.id}
    aws s3 cp test.txt s3://${aws_s3_bucket.app_bucket.id}/

    Test CloudWatch:
    aws cloudwatch put-metric-data --namespace TestApp --metric-name TestMetric --value 1
  EOT
}

⚙️ Step 9: Set Variable Values

Create terraform.tfvars:

aws_region = "us-east-1"
project_name = "terraform-iam"
environment = "dev"

# Change this to a unique bucket name
s3_bucket_name = "terraform-iam-demo-bucket-2026"

instance_type = "t2.micro"
key_name = "my-key"
my_ip = "0.0.0.0/0"

Important: Change s3_bucket_name to something unique!

🚀 Step 10: Deploy Infrastructure

1. Initialize Terraform

terraform init

2. Review Plan

terraform plan

You should see:

Plan: 13 to add, 0 to change, 0 to destroy.

3. Apply Configuration

terraform apply

Type yes when prompted.

✅ Step 11: Test IAM Permissions

1. Get EC2 IP

EC2_IP=$(terraform output -raw ec2_public_ip)
echo $EC2_IP

2. SSH to EC2

ssh -i my-key.pem ec2-user@$EC2_IP

3. Check IAM Role

./show-iam-info.sh

Output:

{
  "Code": "Success",
  "InstanceProfileArn": "arn:aws:iam::123456789012:instance-profile/terraform-iam-ec2-profile",
  "InstanceProfileId": "AIPAI...",
  "LastUpdated": "2026-03-24T16:00:00Z"
}

{
  "UserId": "AROAI...:i-0123456789abcdef0",
  "Account": "123456789012",
  "Arn": "arn:aws:sts::123456789012:assumed-role/terraform-iam-ec2-role/i-0123456789abcdef0"
}

Notice: No access keys! Using IAM role.

4. Test S3 Access

./test-s3.sh

Output:

Testing S3 Access...
1. Listing bucket contents:
(empty or shows files)

2. Uploading test file:
upload: ./test.txt to s3://terraform-iam-demo-bucket-2026/test.txt

3. Downloading file:
download: s3://terraform-iam-demo-bucket-2026/test.txt to ./downloaded.txt

S3 test complete!

5. Test CloudWatch Access

aws cloudwatch put-metric-data \
  --namespace TestApp \
  --metric-name TestMetric \
  --value 1

Should succeed (no output = success).

6. Test Denied Action

# Try to list all S3 buckets (should fail)
aws s3 ls

Output:

An error occurred (AccessDenied) when calling the ListBuckets operation

Perfect! Least privilege working - can only access our specific bucket.

🔍 Understanding IAM Components

IAM Role vs IAM User

IAM User:

Permanent identity
Has access keys
For humans or long-term apps

IAM Role:

Temporary identity
No access keys
For services (EC2, Lambda)
Credentials rotate automatically

Trust Policy vs Permissions Policy

Trust Policy (Assume Role):

{
  "Principal": { "Service": "ec2.amazonaws.com" }
}

WHO can use this role.

Permissions Policy:

{
  "Action": ["s3:GetObject"],
  "Resource": ["arn:aws:s3:::bucket/*"]
}

WHAT the role can do.

Identity-Based vs Resource-Based

Identity-Based (IAM Policy):

resource "aws_iam_policy" "s3_access" {
  policy = jsonencode({
    Action   = ["s3:GetObject"]
    Resource = ["arn:aws:s3:::bucket/*"]
  })
}

Attached to identity (role/user).

Resource-Based (Bucket Policy):

resource "aws_s3_bucket_policy" "bucket" {
  policy = jsonencode({
    Principal = { AWS = "arn:aws:iam::123:role/my-role" }
    Action    = ["s3:GetObject"]
  })
}

Attached to resource (bucket).

When to use which:

Identity-based: Default choice
Resource-based: Cross-account access, specific resource control

🧪 Advanced Testing

Test Policy Evaluation

# SSH to EC2
ssh -i my-key.pem ec2-user@$EC2_IP

# Test allowed actions
aws s3 cp test.txt s3://YOUR-BUCKET/test.txt  # ✅ Should work
aws s3 ls s3://YOUR-BUCKET/                   # ✅ Should work

# Test denied actions
aws s3 ls                                     # ❌ Should fail
aws s3 rm s3://OTHER-BUCKET/file.txt         # ❌ Should fail
aws ec2 describe-instances                    # ❌ Should fail

View CloudTrail Logs

# From local machine
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=terraform-iam-ec2-role \
  --max-results 10

Shows all actions performed by the role!

Test Session Manager (No SSH Keys!)

# From local machine
aws ssm start-session --target $(terraform output -raw ec2_instance_id)

Connect without SSH keys - using IAM role!

🐛 Troubleshooting

Issue 1: "Access Denied" on S3

Cause: IAM policy or bucket policy issue.

Solution:

# Check role is attached
aws ec2 describe-instances \
  --instance-ids <INSTANCE_ID> \
  --query 'Reservations[0].Instances[0].IamInstanceProfile'

# Check policies attached to role
aws iam list-attached-role-policies \
  --role-name terraform-iam-ec2-role

Issue 2: "No credentials found"

Cause: Instance profile not attached.

Solution:

# Ensure this line exists in aws_instance
iam_instance_profile = aws_iam_instance_profile.ec2_profile.name

Issue 3: Bucket policy conflicts

Error:

Error: error putting S3 Bucket Policy: MalformedPolicy

Solution: Check JSON syntax:

# Validate JSON
echo '{"Version":"2012-10-17"}' | jq .

Issue 4: Can't assume role

Error:

User: arn:aws:sts::123:assumed-role/role/i-xxx is not authorized to perform: sts:AssumeRole

Solution: Check assume role policy allows the service:

{
  "Principal": {
    "Service": "ec2.amazonaws.com"  // Must match service
  }
}

💰 Cost Breakdown

Monthly Costs:

Resource	Cost
IAM Roles	$0.00 (Free)
IAM Policies	$0.00 (Free)
S3 Bucket	$0.00 (Free tier)
t2.micro EC2	$8.50 or Free tier
Total	~$0-8.50/month

IAM is FREE!

No charge for roles
No charge for policies
No charge for users (up to limits)

🔐 Security Best Practices

✅ What We Did Right

No Access Keys
- Used IAM roles instead
- Automatic credential rotation
Least Privilege
- Only necessary permissions
- Specific resources only
Separate Roles
- Different roles for EC2 and Lambda
- Each with minimum permissions
Resource-Based Policies
- Bucket policy enforces encryption
- Defense in depth
Managed Policies
- Used AWS-maintained policies
- Automatically updated

🔒 Additional Recommendations

1. Use Policy Conditions:

policy = jsonencode({
  Statement = [{
    Condition = {
      IpAddress = {
        "aws:SourceIp" = "203.0.113.0/24"
      }
    }
  }]
})

2. Enable MFA for Sensitive Actions:

Condition = {
  BoolIfExists = {
    "aws:MultiFactorAuthPresent" = "true"
  }
}

3. Use Permission Boundaries:

resource "aws_iam_role" "limited" {
  permissions_boundary = aws_iam_policy.boundary.arn
}

4. Regular Audits:

# List unused roles
aws iam get-credential-report

# Check last used
aws iam get-role --role-name my-role

5. Use SCPs (Service Control Policies):
Organization-level restrictions.

🧹 Cleanup

terraform destroy

Type yes when prompted.

What gets deleted:

✅ EC2 Instance
✅ S3 Bucket (if empty)
✅ IAM Roles
✅ IAM Policies
✅ Security Group

Note: If S3 bucket has objects, delete them first:

aws s3 rm s3://YOUR-BUCKET --recursive

📚 Key Concepts Learned

1. IAM Roles

resource "aws_iam_role" "role" {
  assume_role_policy = jsonencode({...})
}

2. IAM Policies

resource "aws_iam_policy" "policy" {
  policy = jsonencode({...})
}

3. Policy Attachments

resource "aws_iam_role_policy_attachment" "attach" {
  role       = aws_iam_role.role.name
  policy_arn = aws_iam_policy.policy.arn
}

4. Instance Profiles

resource "aws_iam_instance_profile" "profile" {
  role = aws_iam_role.role.name
}

5. Bucket Policies

resource "aws_s3_bucket_policy" "policy" {
  policy = jsonencode({...})
}

🎯 Real-World Applications

1. Web Applications

EC2 with S3 access for uploads
RDS access for database
CloudWatch for logging

2. Data Processing

Lambda reading from S3
Writing to DynamoDB
SNS notifications

3. CI/CD Pipelines

CodeBuild with ECR access
CodeDeploy with EC2 access
S3 for artifacts

4. Microservices

Each service with own role
Least privilege per service
Service-to-service auth

🚀 What's Next?

In the next article, we'll add:

RDS Database - Managed PostgreSQL/MySQL
Secrets Manager - Secure credential storage
Private Subnets - Database isolation
Security Groups - Network-level access control

Coming Up: Article 10: RDS + Secrets Manager with Terraform

📖 Additional Resources

📂 Source Code

The complete source code and Terraform configuration used in this article can be found on GitHub:

simplynadaf / terraform-by-sarvar

Terraform Series

🚀 Terraform By Sarvar

Complete Terraform tutorial series from basics to advanced concepts

📖 Read the Series • 🌐 Portfolio • 💼 LinkedIn

📚 Series Overview

This repository contains ONLY Terraform code examples for the Terraform By Sarvar tutorial series.

⚠️ IMPORTANT: This repo contains only .tf files and infrastructure code. Articles are published on dev.to, not stored here.

📖 Read the series on dev.to: https://dev.to/sarvar_04/series/36963

🎯 What You'll Learn

✅ Infrastructure as Code (IaC) fundamentals
✅ Terraform basics to advanced concepts
✅ AWS resource provisioning
✅ Best practices and real-world patterns
✅ Production-ready configurations

📊 Series Progress

📖 Article Series

📘 Foundation (Articles 1-5) ✅ Complete

Introduction to Terraform & IaC - ✅ Published
Installation & Setup - ✅ Published
Your First AWS Resource - ✅ Published
Understanding Terraform State - ✅ Published
Variables and Outputs - ✅ Published

📗 Real Infrastructure (Articles 6-10) ✅ Complete

Building a VPC…

View on GitHub

Getting Started

Follow these steps to run the project on your local machine:

Clone the repository:

git clone https://github.com/simplynadaf/terraform-by-sarvar.git

Navigate to the project directory:

cd terraform-by-sarvar/articles/09-iam-security

✅ Summary

Today you learned:

✅ Create IAM roles and policies
✅ Implement least privilege access
✅ Use instance profiles for EC2
✅ Attach managed and custom policies
✅ Configure bucket policies
✅ Avoid access keys completely
✅ Test and verify permissions
✅ Follow security best practices

You now understand AWS IAM security! 🎉

🔗 Connect & Share

If you found this helpful:

⭐ Star the GitHub repo
💬 Leave a comment below
🔄 Share with your network
📧 Subscribe for updates

Next Article: Secure Database Deployment with RDS + Secrets Manager

Written by: Sarvar Nadaf

Series: Terraform By Sarvar

Part: 9 of 20

Tags: #Terraform #AWS #DevOps #IaC #IAM #Security #CloudComputing

📌 Wrapping Up

Thank you for reading. I hope this article provided practical insights and a clearer understanding of the topic.

If you found this useful:

❤️ Like if it added value
🦄 Unicorn if you’re applying it today
💾 Save it for your next optimization session
🔄 Share it with your team

💡 What’s Next

More deep dives are coming soon on:

Cloud Operations
GenAI & Agentic AI
DevOps Automation
Data & Platform Engineering

Follow along for weekly insights and hands-on guides.

🌐 Portfolio & Work

You can explore my full body of work, certifications, architecture projects, and technical articles here:

👉 Visit My Website

🛠️ Services I Offer

If you're looking for hands-on guidance or collaboration, I provide:

Cloud Architecture Consulting (AWS / Azure)
DevSecOps & Automation Design
FinOps Optimization Reviews
Technical Writing (Cloud, DevOps, GenAI)
Product & Architecture Reviews
Mentorship & 1:1 Technical Guidance

🤝 Let’s Connect

I’d love to hear your thoughts. Feel free to drop a comment or connect with me on:

🔗 LinkedIn

For collaborations, consulting, or technical discussions, reach out at:

📧 simplynadaf@gmail.com

Found this helpful? Share it with your team.

⭐ Star the repo • 📖 Follow the series • 💬 Ask questions

Made by Sarvar Nadaf

🌐 https://sarvarnadaf.com

PassionCast: I Built an AI Hype Man for World Cup Fans Using Gemini + ElevenLabs

Sarvar Nadaf — Sun, 12 Jul 2026 16:57:52 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

The World Cup quarter-finals are on right now. I'm watching matches, yelling at my screen, and I thought: what if I could bottle that feeling into an audio clip?

PassionCast lets you pick your team, choose a passion mode (hype speech, glory moment, rivalry fire, heartbreak, fan anthem, or custom), and generates a 60-second AI commentary clip. Not the generic "your team is amazing" stuff. Actual references to your team's players, history, and rivals.

Pick India, select "Rivalry Fire," hit generate. You get a breathless commentator talking about the India-Pakistan cricket-meets-football tension, with real names and real context. Try Argentina and you get Maradona, La Albiceleste, the Diego legacy. That's what I was going for.

Demo

👉 Try PassionCast Live

Three pre-generated sample clips are on the page. Hit play, no keys needed. You'll hear:

Argentina rivalry fire (Match Commentator voice)
India pre-match hype (Epic Narrator voice)
England heartbreak (Epic Narrator voice)

To generate your own, you'll need free API keys (30 seconds each):

The flow:

Code

simplynadaf / PassionCast

🔥 PassionCast

Your personal AI hype man for the World Cup 2026.

Pick your team. Choose a moment. Get a passionate, AI-generated audio commentary that captures the fire of football fandom.

👉 Try PassionCast Live

How It Works

Pick your team from 48 World Cup 2026 nations
Choose your passion — hype speech, glory moment, rivalry fire, heartbreak, or fan anthem
Select a voice — epic narrator, match commentator, or poetic storyteller
Generate — Gemini writes the script, ElevenLabs brings it to life as audio

Tech Stack

Layer	Technology	Why
Script generation	Google AI (Gemini 2.0 Flash)	High temperature (0.9) + cultural context = scripts that feel personal, not generic
Voice synthesis	ElevenLabs (Multilingual v2)	Low stability (0.4) for emotional range, high style (0.6) for expressiveness
Frontend	Vanilla JS + Vite	Fast, no framework overhead, deploys anywhere
Hosting	GitHub Pages	Free, automatic deploys via GitHub Actions

No backend. No database…

View on GitHub

How I Built It

No backend. No framework. One page, vanilla JS, two API calls. Vite for bundling, GitHub Pages for hosting.

Browser → Gemini 2.0 Flash (writes script) → ElevenLabs (speaks it) → Audio playback

I specifically didn't want a backend here. The whole point is that someone can fork this, drop in their own keys, and have it running in 30 seconds.

The Gemini Part (where I spent most of my time)

Getting Gemini to write passionate content was harder than I expected. At temperature 0.7, everything came out bland. "Your team has a proud history. The fans are excited." Useless.

At 0.9, things got interesting. Combined with a detailed system prompt that includes the team name, their rivals, their football culture, and the specific style I want (narrator vs commentator vs poet), the output started feeling real.

The trick was constraining length. I needed 150-200 words, the sweet spot for 45-60 seconds of audio. Too short and it feels empty. Too long and ElevenLabs starts rushing or the clip drags.

// Note: ${apiKey} is a template literal variable, not a real key. 
// Users provide their own free key from aistudio.google.com/apikey
const response = await fetch(
  `https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=${apiKey}`,
  {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      contents: [{ parts: [{ text: prompt }] }],
      generationConfig: { temperature: 0.9, maxOutputTokens: 500 }
    })
  }
);

The ElevenLabs Part (where the magic happens)

I tested default voice settings first. Sounded flat. Like a GPS reading football commentary.

The fix: crank down stability to 0.4 (default is higher). This adds emotional variation. The voice wavers, speeds up, gets louder on key phrases. Exactly what you want for sports commentary.

Then style to 0.6 for extra expressiveness, and speaker boost on for clarity.

Three voices, matched to content:

Brian (dramatic narrator) for glory moments
Liam (energetic) for rivalry and hype
George (poetic storyteller) for heartbreak and anthems

body: JSON.stringify({
  text: script,
  model_id: 'eleven_multilingual_v2',
  voice_settings: {
    stability: 0.4,
    similarity_boost: 0.8,
    style: 0.6,
    use_speaker_boost: true,
  }
})

Other Decisions

I used flag images from flagcdn.com instead of emoji because emoji flags don't render on Windows for England, Wales, and Scotland (they show as black rectangles). Learned that the hard way after building the whole grid with emoji first.

Dark theme with gold/fire accents because... it's a passion app. Light mode would feel wrong.

What I'd Add

If I had another weekend: social sharing (let people post their clips), match-day mode that checks today's fixtures and auto-suggests hype content, and a gallery so you can hear what other fans generated. PRs welcome if you want to tackle any of these.

Prize Categories

Best Use of Google AI: Gemini 2.0 Flash with temperature 0.9 and detailed cultural prompting. Produces scripts with real player names, real rivalry history, and team-specific fan culture for 48 nations. Three distinct writing styles (narrator, commentator, poet) via style instructions in the prompt.
Best Use of ElevenLabs: Multilingual v2 model with deliberately tuned settings. Stability at 0.4 for emotional range (default sounds robotic for sports content). Style at 0.6 for expressiveness. Three voices paired to content types. The output sounds like broadcast commentary, not text-to-speech.

Introducing AWS Sandbox Environment: Learn AWS for Free Without a Credit Card

Sarvar Nadaf — Thu, 09 Jul 2026 10:11:18 +0000

I was scrolling through the AWS What's New feed when one announcement stopped me. AWS Builder Center now lets you spin up a free sandbox environment directly from a workshop page. No AWS account. No credit card. No billing alerts at 3am because you forgot to terminate a NAT Gateway.

I've spent the last decade helping clients onboard teams to AWS. The number one friction point was never the technology. It was the signup. "What if I get charged?" kills more cloud careers before they start than any certification exam ever will.

That friction just disappeared.

What AWS Actually Announced

On July 8, 2026, AWS launched free sandbox environments inside AWS Builder Center. Here are the confirmed details straight from the announcement:

Cost: Zero. Completely free.
Duration: 8 hours from the moment you activate it
Frequency: One sandbox per week, resets every Sunday
Provisioning time: Most environments ready within 15 minutes
Cleanup: Fully automatic after your 8 hours expire
Requirements: No personal AWS account needed, no credit card

The sandbox is a pre-provisioned AWS account that you access through eligible workshops. These are step-by-step guided labs covering topics like building serverless APIs, setting up VPCs, deploying containers, or working with AI services. You're not getting a stripped-down simulator. You're deploying real resources into a real AWS account.

Why This Matters More Than You Think

I've onboarded probably 40+ engineers to AWS across different client engagements. The pattern repeats every single time. Day one of training, someone raises their hand: "What happens if I accidentally leave something running?" That question comes from fear. And fear makes people skip hands-on practice entirely. They read docs. Watch videos. Never deploy a thing.

The AWS Free Tier tried to solve this. It helped, but didn't kill the fear because you still needed a credit card on file. I remember my early days after graduation. No steady income, learning AWS on Free Tier, feeling like I was on borrowed time. When the tier expired and a $4.50 charge showed up for some resource I forgot to terminate, it felt like $45. When you're broke and learning, even a small unexpected bill makes you close the console and not come back for weeks.

AWS recently revamped the Free Tier into a proper "Free Plan" with $200 in credits and auto-closure after 6 months. Big improvement. But Builder Center Sandbox goes further: you don't even need an account. The barrier is zero.

How It Compares to Other Free Options

AWS now has four distinct paths to hands-on practice without paying. Each serves a different need.

Option	Cost	Credit Card	Time Limit	Access Type	Best For
Builder Center Sandbox (NEW)	Free	No	8 hrs/session, 1/week	Workshop-guided	Zero-commitment first experience
Free Tier (Free Plan)	Free ($200 credits)	No	6 months	Full console, 90+ services	Self-directed projects
Skill Builder	$29/mo or $449/yr	Yes	Subscription	Labs + exam prep	Certification prep
Educate	Free	No	Self-paced	Curated courses + labs	Students, career-switchers (13+)

Let me break down when you'd pick each one.

Builder Center Sandbox is for when you want to try AWS without creating anything. No account, no commitment, no trace. You follow a workshop, deploy real resources, learn by doing, and everything vanishes after 8 hours.

Free Tier (Free Plan) is for when you want to build your own thing. A side project, a portfolio piece, an experiment. You get an actual account with $200 in credits and 6 months to use them. It auto-closes, so no surprise bills.

Skill Builder is for professionals investing in certifications. The $29/month gets you immersive labs, exam prep courses, and practice exams. Worth it if you're targeting a specific cert.

Educate is the entry ramp for students and people switching careers. Free, beginner-friendly, and includes a job board for ages 18+.

The Decision Framework

"I want to try AWS for the first time without any commitment" → Builder Center Sandbox

"I want to build my own side project on AWS for free" → Free Tier (Free Plan)

"I'm preparing for an AWS certification exam" → Skill Builder subscription

"I'm a student or career-switcher with no tech background" → AWS Educate

"I'm an experienced dev who wants to test a specific architecture pattern" → Free Tier (Free Plan) or Builder Center Sandbox (if a relevant workshop exists)

What You Can't Do (Limitations)

Based on the announcement, here are the real constraints:

Workshop-specific, not open console. You can't open the AWS Console and freelance. The sandbox is tied to eligible workshops. At launch, only select workshops support it, with more being enabled over time.
8-hour hard limit. If you're building something that takes multiple sessions, this won't work. The environment gets wiped completely after 8 hours. No saving progress.
One per week. You can't chain multiple sandboxes in a day. One activation, resets Sunday. Plan your learning accordingly.

What I'd Like to Know (But Can't Confirm Yet)

A few questions the announcement doesn't answer:

Do you need an AWS Builder ID to access it? (Probably yes, but unconfirmed)
Which specific workshops are sandbox-enabled at launch?
What services are available inside the sandbox? (Likely varies per workshop)
Are there geographic restrictions?
Can you export your work (code, configs) before the 8-hour window closes?

I'll update this article as those details become clear.

Who Should Use This Today

If you fall into any of these categories, go to builder.aws.com/workshops right now:

You've been "meaning to learn AWS" for months but never started
You teach or mentor others and need a zero-friction lab environment for your students
You're evaluating AWS services before committing your company's budget
You want guided, structured practice without managing your own cleanup
You already know AWS but want to explore workshops on topics outside your comfort zone

My Take

As someone with 7 AWS certifications and four years as an AWS Community Builder, I've watched this problem from both sides. Watched clients spend thousands on training environments that collected dust. Watched junior engineers accumulate surprise bills that killed their curiosity. I've seen people give up on cloud because the onboarding felt hostile.

This sandbox removes a massive psychological barrier. It seems like a small feature. It's not.

The best way to learn cloud is to break things in cloud. AWS just made breaking things free, temporary, and consequence-free. That's the right move.

Have you tried the Builder Center Sandbox yet? Which workshops are available in your region? Drop your findings in the comments. I'll compile a list as people report back.

This article is actively updated. AWS Builder Center Sandbox launched July 8, 2026 with select workshops. As AWS enables more workshops, expands features, or changes limits, I'll update this post. Follow me to stay current.

Follow me for more on AWS architecture, DevOps, and AI tooling: sarvarnadaf.com | LinkedIn

BrowserAct Hit #1 on Product Hunt - Why 629 Builders Voted for a BrowserAct That Gets Stuck

Sarvar Nadaf — Mon, 06 Jul 2026 19:02:18 +0000

👋 Hey there, Tech Enthusiasts!

I'm Sarvar, a Cloud Architect who loves turning complex tech problems into simple solutions. I've worked with AWS, Azure, DevOps, Data, Analytics, Generative-AI and Agentic-AI building real systems for real companies. In this article series, I'll share what I've learned in a way that's easy to follow, whether you're experienced or just getting started.

Let's get into it! 🚀

So BrowserAct hit #1 Product of the Day on Product Hunt.

629 upvotes. 69 comments on the maker post alone. Beat products from established companies with larger teams on the same launch day. Ended up #3 for the week. Their GitHub has grown from 2.3k stars when I first wrote about them to 3.6k now.

I wasn't surprised.

I've been running this tool in production for 6 weeks. Published two articles Article 1 - Full hands-on testing and Article 2 - Headless + human handoff pattern it's covering full hands-on testing, real workflows, headless servers, the whole thing. So when I saw it trending on Product Hunt, my first thought was: yeah, that tracks.

But here's what's more interesting than the vote count the questions people asked in the comments.

What 629 Builders Actually Wanted to Know

I read through the entire Product Hunt thread. And the questions developers asked reveal more about the state of browser automation in 2026 than any feature comparison table could.

"When BrowserAct hands off to a human during a stuck flow, what does that experience look like?" - swati_paliwal

"Does BrowserAct re-anchor to elements semantically when the DOM drifts?" - David

"Where does BrowserAct pull ahead vs Browser Use and Browserbase?" - Gal Dayan

"Solve rates tend to rot fast. How do you keep CAPTCHA handling holding up over time?" - Kwan Tsui

"Sites serve degraded or stale content instead of erroring out. How do you handle silent soft-blocks?" - Dipankar Sarkar

"Does session state survive a locale/IP change mid-flow?" - Art Stavenka

These aren't feature requests. They're pain points. Every one of them comes from someone who's been burned before.

And honestly reading that thread felt like reading my own notes from 6 weeks ago.

I Can Answer Most of These

I'm not on the BrowserAct team. I'm a cloud architect who integrated this into my actual work monitoring dashboards, extracting data from protected pages, running agents that need to browse real sites behind Cloudflare and login walls.

So let me map the community's questions to what I've actually experienced.

Human handoff UX? I tested this extensively in article 2. The agent hits a login wall, calls remote-assist, generates a URL. I open that URL on my phone, complete the 2FA, close the tab. The agent picks up right where it was. Same session, same cookies, same page state. No restart. Took me about 40 seconds the first time. Now it's under 15.

Most automation tools treat human intervention as failure. BrowserAct treats it as a feature. The agent decides to ask for help. That's intentional.

Anti-detection longevity? I ran the same stealth browser against nowsecure.nl and Cloudflare's bot detection page across multiple weeks. Still passing the environment layer hasn't degraded on sites I first tested in week 1. The 3-layer system (fingerprint environment → auto-CAPTCHA solving → human fallback) means even if one layer degrades, the others catch it. In 6 weeks I haven't had a session get permanently blocked.

Though I'm not hammering sites at scale. A few hundred requests a day, not tens of thousands. Your mileage will vary at volume.

Parallel sessions without cross-contamination? Multiple browser profiles simultaneously different accounts, different sites, different fingerprints. No cookie leakage, no fingerprint overlap. Each session gets its own identity.

Agent-native output? BrowserAct outputs clean, indexed text not raw HTML. Fewer tokens, lower cost, better reasoning. Every token your agent spends parsing DOM soup is a token it's not spending on solving your problem. This is what my agent sees when it looks at a page no markup, just numbered elements it can act on:

I'd rather say "I don't know" than make something up.

The Features That Won the Vote

629 people didn't upvote because browser automation is exciting. They upvoted because this solves specific frustrations that existing tools don't.

1. It gets stuck on purpose.

This sounds backwards. Why would you want your automation to stop? Because the alternative is worse it crashes silently, retries infinitely, or returns garbage data while pretending everything's fine.

I had a moment at 2am a few weeks ago client's monitoring dashboard alert went off, my agent tried to check it, hit a new CAPTCHA type it hadn't seen before. Instead of failing silently and me waking up to stale data, it pinged me. I solved the CAPTCHA half-asleep on my phone, agent continued, I went back to sleep. Old tool? I would've found out 6 hours later that nothing was collected.

2. Local-first in a cloud-first world.

Browserbase runs your sessions in the cloud. BrowserAct runs on YOUR machine. Your Chrome, your cookies, your logins. Nothing leaves your device unless you explicitly send it.

For me this isn't optional. I manage client AWS accounts, access their internal dashboards I'm not sending authenticated sessions through someone else's infrastructure. I ran it on my Linux server, headless, no display needed. My sessions, my machine, my client's data stays where it should.

3. The 3-layer escalation model.

Most tools have one approach to anti-detection. Fingerprint spoofing, and pray. BrowserAct stacks three:

Environment layer: fingerprints, TLS rotation, navigator patching, headless concealment
Execution layer: auto-solves CAPTCHAs when they pop up (reCAPTCHA, Turnstile, DataDome)
Human layer: when automation can't solve it, a human can jump in live

I tested this across real sites with actual Cloudflare protection. The environment layer handled 90% of cases. The CAPTCHA solver caught most of the rest. I only needed human handoff for sites with custom 2FA flows. If layer 1 fails, layer 2 catches it. Layer 2 fails? You get a human. With Puppeteer, if fingerprint detection catches you session's dead. No fallback.

What I've noticed after 6 weeks: the escalation isn't just a safety net it changes how you design workflows. You stop building for the happy path only and start trusting that edge cases won't silently break things.

4. Built for multi-account operations and for agents, not humans.

Cross-contamination between sessions isn't just annoying it's a breach. One leaked cookie, one shared fingerprint between Client A and Client B, and you've got a trust problem that no apology email fixes. The isolation model here isn't a feature checkbox. It's risk management.

And the agent-native output that's not about developer experience. It's about cost. I measured it roughly: a raw HTML page burns 3-5x more tokens than BrowserAct's indexed output for the same content. At a few sessions a day, whatever. At hundreds? That's real money. My workflows got noticeably cheaper once I stopped piping full DOM through the LLM.

5. Session state survives more than you'd expect.

This is the one I didn't appreciate until week 3. The browser state cookies, page position, auth tokens, everything persists through handoffs, through network interruptions, through the agent pausing overnight and resuming in the morning.

I had a session authenticated to a client's Grafana dashboard. My agent checked it Monday. Checked it again Wednesday. Same session, still logged in, no re-auth needed. With Playwright, you'd serialize cookies, hope nothing expired, rebuild context from scratch. Here the session just... exists. Waiting.

And when a human completes a step during remote-assist and the page changes new elements loaded, a redirect happened the agent doesn't try to replay stale assumptions. It reads the current page as the new truth. BrowserAct's approach (from Maggie on their team, in the PH thread): "We treat the post-handoff page as the new source of truth rather than trying to replay stale DOM assumptions." After I completed GitHub login manually, my agent immediately extracted content from the authenticated state. No stale references, no "element not found" errors.

Whether session state survives a locale/IP change mid-flow I haven't explicitly tested that. Sessions survived my remote-assist handoffs without issue, but proxy rotation mid-session is something I'd need to verify.

6. Works with whatever agent you're using tomorrow.

I switched agents three times in the last 6 months. Claude Code, then Cursor, then Kiro. Every time I switch, I dread re-integrating my tools. BrowserAct? Didn't care. It's a CLI. Anything that can run a shell command can drive it. No SDK to install, no Python library to pin, no WebSocket connection to manage. Just browser-act --session X do-thing.

I've run it from bash scripts, from cron jobs on a headless server, from three different agents. The integration took 5 minutes each time. In a world where everyone's switching agents every few months, not being locked into one framework isn't a nice-to-have it's survival.

7. This isn't a weekend project.

I'll be honest when I first tested BrowserAct, I assumed it was early-stage. Small team, niche tool, might disappear in 6 months. I checked their AWS Marketplace listing because I needed to know this thing would still exist when my client's contract renews in Q4.

Then I looked at the actual numbers: 500M+ pages automated, 10M+ CAPTCHAs solved, 10K+ concurrent sessions running on the platform. G2 rating of 4.8/5. Available on AWS Marketplace. Partners include AWS, Azure, and GCP.

That's not a side project. That's infrastructure. And for anyone choosing a tool they'll depend on in production knowing it's not going to vanish matters more than any single feature.

What the Product Hunt Voters Don't Know Yet

Here's the part I can write that a vote count can't tell you. Stuff I wish someone had told me before I started.

Speed isn't instant. Stealth browsers take longer to launch than a raw Puppeteer instance. You're paying for anti-detection with startup time. A stealth browser launch takes a few seconds versus near-instant for bare Chrome. For one-off tasks, fine. For tight loops that need sub-second response, you'll feel it.

Error messages could be better. When something fails especially around proxy configuration or session naming conflicts the error output is terse. I had a session name collision once (globally unique names required, even across browsers) and the error just said the session couldn't be created. No hint about why. Took me 10 minutes of docs-diving. This is the kind of thing that improves over time, but right now, expect some head-scratching moments.

Credits add up. The pricing is credit-based, and in dollar terms it breaks down to:

100 credits per stealth browser (~$0.064 per browser)
5 credits per workflow step (~$0.003 per step)
5,000 credits per GB of proxy traffic (~$3.20/GB)

For my usage a few browser sessions a day, some proxy requests it's cheap. But if you're running hundreds of concurrent sessions with dynamic proxies, do the math first. Full plan details and credit bundles are on their pricing page. The free tier covers basic Chrome automation with no signup, which is great for testing.

It's not for everything. If a site has an API, use the API. I wouldn't use it for high-frequency data collection at massive scale there are cheaper, dumber tools for pure scraping where you don't need anti-detection.

Silent soft-blocks are an open question. Someone on the PH thread asked about sites that serve degraded or stale content instead of erroring out. Honest answer: I haven't hit this scenario but I also wasn't looking for it specifically. My workflows extract structured data and I'd notice if the numbers were wrong. Whether BrowserAct has detection for this at the platform level, I genuinely don't know.

It shines when you need a real browser experience: logins, multi-step flows, sites that actively fight automation, workflows where failure needs to be handled gracefully instead of silently.

My Verdict

Would I keep using BrowserAct? Already am.

It sits in my workflow for anything that requires a real browser session monitoring protected dashboards, extracting data from authenticated portals, running agents against sites that block everything else. There are 30+ browser automation tools right now and hundreds of millions in funding flowing into this space. I deep-tested this one for 6 weeks, and it solved problems I couldn't solve before with Puppeteer or Playwright.

It's not perfect. The speed could be better. Error messages need work. And I genuinely don't know how the CAPTCHA solving holds up at scale.

But the core design decision automate what works, ask for help when stuck, resume from the same state that's the right architecture. And 629 Product Hunt voters seem to agree.

Next on my list: deep-testing Skill Forge for packaging repeatable workflows. If it holds up, that's article 4.

Links:

I test tools in production, not sandboxes. Questions about running BrowserAct in real workflows? Drop a comment.

📌 Wrapping Up

Thanks for reading! If this was helpful:

❤️ Like if it added value
💾 Save for later
🔄 Share with your team

Follow me for more on: AWS architecture, FinOps, DevOps, and AI Infrastructure.

👉 Visit my website | Connect on LinkedIn | Email: simplynadaf@gmail.com

Happy Learning 🚀

Build Your First AI Agent in 30 Minutes - CrewAI + AWS Bedrock

Sarvar Nadaf — Fri, 03 Jul 2026 17:18:42 +0000

👋 Hey there, Tech Enthusiasts!

Let's get into it! 🚀

Hey, welcome back.

In the last article, we covered what AI agents are, how they think in loops, and why they're different from just asking ChatGPT for help. We looked at the building blocks role, goal, backstory, tasks, tools and how CrewAI lets you define all of this in simple YAML files.

We ended with a promise: we're going to build the thing.

This is that article. No more theory. We're building the resume tailor agent from scratch. By the end, you'll have a working agent with a web UI that takes a job description, analyzes it, and tailors your resume to match in seconds.

Why a Resume Tailor Agent?

This isn't a random project idea. It comes from a real problem I've faced repeatedly.

I've been working in MNCs for over 10 years. Every time a job switch comes up, the cycle is the same update the resume, start applying, wait for calls. And the calls don't come. Not because I lack the skills or experience. Not because there's a position mismatch. The problem is simpler and more frustrating than that: the things they're looking for I've actually done them. I just didn't mention them on my resume.

That's where I was lagging. My resume had my experience, but it wasn't speaking the language of the job description. The keywords weren't there. The framing wasn't right. And in today's market, where competition is fiercer than ever and most resumes go through automated screening first, that gap is enough to get you filtered out before a human ever reads your application.

Most companies today use ATS (Applicant Tracking Systems) that scan resumes for keywords before a recruiter ever sees them. If your resume doesn't have the right terms the exact ones from the job description it gets filtered out automatically. You could be a perfect fit and still never make it past the screen.

So now that we can build AI agents that actually do things why not build one that fixes this? Give it a job description, give it your resume, and in a few seconds it extracts the keywords that matter, identifies what's missing, and rewrites your bullet points to be ATS-friendly. Result: your resume actually gets past the bots and onto someone's desk.

That's what we're building. Not because it's a cool demo because I needed it.

What We're Building

A single AI agent that takes a job description (required) and optionally your resume, then gives you:

With JD + Resume (full analysis):

JD Summary - what they're actually looking for (5-6 sentences)
Matching Skills - key technologies to highlight in your resume (e.g., LLM, MCP, RAG, Kubernetes, Terraform)
Skill Gaps - short bullet points, one gap per bullet
Career Guidance - short career path bullets showing what to prepare (learn X, get certified in Y, build project with Z)
Tailored Resume - rewritten bullet points ready to copy-paste

With JD only (no resume):

JD Summary - what the role needs
Key Technologies - tech keywords the JD demands
Career Path - what to prepare for this role

Resume is optional so even if someone doesn't have one ready, they can still get value by understanding what a JD requires and what path to follow.

No fancy multi-agent setup. One agent with a good prompt handles all of this in a single pass. Simpler code, faster execution, cheaper to run.

Input & Output - What Goes In, What Comes Out

Input (what you provide):

Field	Required?	Description
Job Description	✅ Yes	The JD you're targeting
Years of Experience	✅ Yes	Helps adjust suggestions to your level
Expertise Level	✅ Yes	Fresher / Junior / Mid-Level / Senior / Lead / Architect
Resume	❌ Optional	Your current resume (paste as text)

Output (what you get):

If you provide JD + Resume:

Section	Format	Example
JD Summary	5-6 sentences	"They want a senior cloud engineer who owns AWS infra end-to-end"
Matching Skills	Key technology keywords	`Terraform, Kubernetes, Python, AWS Lambda, CloudWatch`
Skill Gaps	Bullet points	• No Kafka experience • Missing distributed systems
Career Guidance	Career path bullets	• Learn Kafka basics • Get AWS Solutions Architect cert • Build a microservices project
Tailored Resume	Ready to copy-paste	Rewritten bullet points matching the JD

If you provide JD only (no resume):

Section	Format	Example
JD Summary	5-6 sentences	"Looking for a GenAI engineer with RAG and LLM experience"
Key Technologies	Keywords	`LLM, RAG, MCP, LangChain, Vector DB, Python`
Career Path	Bullet points	• Learn RAG patterns • Build an agent with CrewAI • Study vector databases

What You'll Need

An AWS account with Bedrock access (Amazon Nova Pro model enabled)
An EC2 instance (t3.medium or bigger) or any Linux machine with Python
About 30-45 minutes
Basic comfort with the terminal

I'm using an EC2 instance running Amazon Linux 2023. You can use Ubuntu, your local Mac, WSL doesn't matter. The commands are the same.

One thing before we start make sure you've enabled the Amazon Nova Pro model in your AWS Bedrock console. It's not enabled by default. Go to Bedrock > Model access > Request access to Nova Pro. Takes a minute to get approved.

High-Level Architecture

Before we jump into code, here's how everything fits together:

How it works:

User opens the Streamlit web UI in their browser and pastes a job description, resume, and experience level
Streamlit (running on EC2) passes the inputs to the CrewAI orchestrator
crew.py loads the agent configuration (agents.yaml + tasks.yaml) and constructs the prompt
The prompt is sent to Amazon Bedrock Nova Pro a foundation model that does the actual analysis
Bedrock returns the analysis skill gaps, career guidance, and tailored resume
Results flow back through CrewAI → Streamlit → displayed to the user

The entire stack runs on a single EC2 instance (t3.medium). The only external service is Amazon Bedrock, which handles the LLM inference. No databases, no queues, no complex infra just a Python app talking to a foundation model.

Setting Up the Environment

First, SSH into your server. If you're working locally, skip this.

ssh -i your-key.pem ec2-user@your-server-ip

Install Python 3.11

CrewAI needs Python 3.11 or higher.

sudo dnf install python3.11 python3.11-pip -y

Check it worked:

python3.11 --version

You should see something like Python 3.11.x.

Install uv

uv is a fast Python package manager. CrewAI uses it under the hood for dependency management. Think of it like npm for Python, but faster.

curl -LsSf https://astral.sh/uv/install.sh | sh

Now add it to your PATH so you can use it right away:

export PATH=$HOME/.local/bin:$PATH

Verify:

uv --version

Install CrewAI CLI

This gives you the crewai command the tool you'll use to create projects, install dependencies, and run agents.

uv tool install crewai-cli --python python3.11 --with crewai

Two things to note here:

It's crewai-cli, not crewai. If you install just crewai, you get the library but not the CLI command.
The --with crewai flag is important it includes the crewai library in the CLI tool's environment. Without it, crewai install will fail later with a ModuleNotFoundError.

Verify:

crewai version

That's it. Environment is ready.

Creating the Project

CrewAI has a scaffolding command that creates the entire project structure for you. No need to create folders manually.

crewai create crew resume_tailor --classic

The --classic flag gives you the standard Python/YAML project structure (which is what we want). Without it, newer versions of CrewAI may generate a JSON-based structure instead.

It'll ask you a few questions:

Provider: Choose bedrock (option 9 in the menu)

Model: Choose bedrock/us.amazon.nova-pro-v1:0 (option 28)

AWS keys: Press Enter to skip we'll use the IAM role attached to the instance (or your AWS CLI credentials)

This creates a folder called resume_tailor with everything you need.

Quick fix - pyproject.toml (if needed)

Check your generated pyproject.toml. If you see a pinned pre-release version like crewai[tools]==1.14.5a2, change it to:

crewai[bedrock,tools]>=1.14.0,<2.0.0

The scaffolding sometimes generates crewai[tools] with a pre-release pin. We're changing it to include the bedrock extra (since we're using Amazon Bedrock) and pinning to a stable version range.

What You Get - CrewAI Project Structure

Let's look at what was generated. This is the standard CrewAI project structure every CrewAI project looks like this:

resume_tailor/
├── src/resume_tailor/
│   ├── config/
│   │   ├── agents.yaml        ← WHO: define your agents here
│   │   └── tasks.yaml         ← WHAT: define what agents do
│   ├── tools/
│   │   └── custom_tool.py     ← HOW: custom tools (we won't need this)
│   ├── crew.py                ← WIRING: connects agents to tasks
│   └── main.py                ← START: entry point, kicks everything off
├── knowledge/                 ← FACTS: files agents can read
├── .env                       ← SECRETS: API keys, model config
└── pyproject.toml             ← DEPENDENCIES: Python packages

Here's how to think about it:

agents.yaml - you're writing a job description for your AI worker. Who are they? What's their expertise?
tasks.yaml - you're writing a work order. What exactly should they do? What should the output look like?
crew.py - you're the manager connecting the worker to the work order.
main.py - you're pressing the "start" button.

That's the whole framework. Four files that matter.

Now let's go into the project:

cd resume_tailor

Configuring the Agent

Open src/resume_tailor/config/agents.yaml. This is where you define WHO your agent is.

Replace everything in the file with this:

resume_tailor:
  role: >
    Senior Resume Tailor & Career Advisor
  goal: >
    Analyze the job description, compare it with the candidate's resume,
    identify skill gaps, and rewrite the resume to match the job requirements.
  backstory: >
    You're a seasoned career advisor with 15+ years of experience in tech recruiting.
    You've reviewed thousands of resumes and job descriptions. You know exactly what
    hiring managers look for, can instantly spot skill gaps, and you rewrite resumes
    that get interviews. You're direct, practical, and never give generic fluff.

Three things here:

Role - tells the agent who it is. "Senior Resume Tailor & Career Advisor" not just "helper" or "assistant." The more specific the role, the better the output.
Goal - tells it what to achieve. This is the finish line.
Backstory - gives it personality. "15+ years in tech recruiting" makes it write like someone who's actually done this, not like a generic chatbot.

Think of it like hiring a contractor. You wouldn't say "do some work." You'd say "You're a senior plumber. Your job is to fix the kitchen leak. You've been doing this for 20 years." Same idea.

Configuring the Task

Open src/resume_tailor/config/tasks.yaml. This is the work order what exactly should the agent do?

Replace everything with this:

tailor_resume_task:
  description: >
    Analyze the following job description and produce career guidance.

    Job Description:
    {job_description}

    Candidate's Resume:
    {resume}

    Years of Experience: {years_experience}
    Expertise Level: {expertise_level}

    IMPORTANT: Tailor your suggestions based on the candidate's experience and expertise level.
    A Fresher needs different guidance than a Senior or Architect. Adjust complexity, depth, and expectations accordingly.

    IMPORTANT: If the candidate's resume is "Not provided", skip sections 2, 3, and 5.
    Instead, provide: JD Summary, Key Technologies, and Career Path.

    If the resume IS provided, include all 5 sections:

    1. JD Summary - One or two sentences max. What role/expertise are they looking for?

    2. Matching Skills - List as key technologies/keywords the candidate should highlight in their resume (e.g., LLM, MCP, RAG, Kubernetes, Terraform, CrewAI). Just the tech keywords, no sentences.

    3. Skill Gaps - Bullet points, short and simple. One gap per bullet. No paragraphs.

    4. Career Guidance - Short bullet points showing the preparation path for this JD based on their expertise level. Like a career roadmap with heads/topics to learn. Example:
       - Learn X
       - Get certified in Y
       - Build a project using Z

    5. Tailored Resume - Rewrite the candidate's resume bullet points to match the job description. Adjust tone and depth based on expertise level. Ready to copy-paste.

  expected_output: >
    If resume provided: JD Summary, Matching Skills (key technologies as keywords), Skill Gaps (bullet points), Career Guidance (short career path bullets based on expertise level), Tailored Resume.
    If resume not provided: JD Summary, Key Technologies, Career Path (adjusted for expertise level).
  agent: resume_tailor

A few things to notice:

{job_description}, {resume}, {years_experience}, {expertise_level} these are variables. They get filled in at runtime when you pass inputs. CrewAI handles the interpolation.
The agent adapts based on expertise level a Fresher gets beginner-friendly guidance, a Senior gets advanced recommendations.
The resume is optional if "Not provided", the agent adapts and gives a shorter but still useful output (JD Summary, Key Technologies, Career Path).
Matching Skills outputs key technology keywords (like LLM, RAG, Kubernetes) that the candidate should add to their resume.
Skill Gaps are short bullet points one gap per bullet, no paragraphs.
Career Guidance gives a career roadmap with actionable steps tailored to your level.
agent: resume_tailor this connects the task to the agent we defined in agents.yaml. The names must match.

Wiring It Up - crew.py

Open src/resume_tailor/crew.py. This is where you connect the agent to the task.

Replace everything with this:

from crewai import Agent, Crew, Process, Task
from crewai.project import CrewBase, agent, crew, task
from crewai.agents.agent_builder.base_agent import BaseAgent


@CrewBase
class ResumeTailor():
    """ResumeTailor crew"""

    agents: list[BaseAgent]
    tasks: list[Task]

    @agent
    def resume_tailor(self) -> Agent:
        return Agent(
            config=self.agents_config['resume_tailor'],  # type: ignore[index]
            verbose=True
        )

    @task
    def tailor_resume_task(self) -> Task:
        return Task(
            config=self.tasks_config['tailor_resume_task'],  # type: ignore[index]
            output_file='tailored_resume.md'
        )

    @crew
    def crew(self) -> Crew:
        return Crew(
            agents=self.agents,
            tasks=self.tasks,
            process=Process.sequential,
            verbose=True,
        )

What's happening here:

@CrewBase - tells CrewAI this class is a crew. It automatically loads your YAML configs.
@agent method - creates the agent from the YAML config. The method name resume_tailor must match the key in agents.yaml.
@task method - creates the task from the YAML config. Same rule tailor_resume_task must match tasks.yaml.
output_file='tailored_resume.md' - saves the result to a file. Nice for reviewing later.
Process.sequential - tasks run one after another. We only have one task, so this doesn't matter much here. But if you add more agents later, this controls the order.
verbose=True - shows you what the agent is thinking while it works. Great for debugging. Turn it off in production.

Setting Up the Entry Point - main.py

Open src/resume_tailor/main.py. This is where you pass inputs and kick off the agent.

Replace everything with this:

#!/usr/bin/env python
import warnings

from resume_tailor.crew import ResumeTailor

warnings.filterwarnings("ignore", category=SyntaxWarning, module="pysbd")


def run():
    inputs = {
        'job_description': 'We are looking for a Senior Cloud Engineer with experience in AWS, Terraform, Kubernetes, and CI/CD pipelines. Must have 5+ years experience with cloud infrastructure, strong Python skills, and experience with monitoring tools like Datadog or CloudWatch.',
        'resume': 'Cloud Engineer with 3 years experience. Skills: AWS (EC2, S3, Lambda), Docker, Jenkins, Python, CloudFormation. Built CI/CD pipelines for microservices. Managed monitoring with CloudWatch. Deployed applications on ECS.',
        'years_experience': '3',
        'expertise_level': 'Mid-Level',
    }

    try:
        ResumeTailor().crew().kickoff(inputs=inputs)
    except Exception as e:
        raise Exception(f"An error occurred while running the crew: {e}")

This is just for testing. We're hardcoding a sample resume and job description so we can verify everything works before adding the UI. The Streamlit app will replace these hardcoded inputs with whatever the user types.

Configuring the Environment

Open the .env file in the project root. Remove anything that was auto-generated and just keep these two lines:

MODEL=bedrock/us.amazon.nova-pro-v1:0
AWS_REGION_NAME=us-east-1

That's it. The model to use and the AWS region.

If you're on EC2 with an IAM role attached, you don't need AWS keys the SDK picks up credentials automatically from the instance profile. Don't put AWS access keys in this file if you're using an IAM role it's unnecessary and a security risk. If you're running locally without an IAM role, make sure your AWS CLI is configured:

aws configure

When it asks for region, set it to us-east-1.

Don't pass a region parameter in the model name Nova Pro is a cross-region model and adding a region breaks it. Just set AWS_REGION_NAME in the .env and leave it at that.

Installing Dependencies and Running

First, lock and install all the dependencies:

crewai install

This creates a uv.lock file and installs everything the project needs.

Now add Bedrock support if you already updated your pyproject.toml to include crewai[bedrock,tools], you can skip this step. Otherwise, add it now:

uv add "crewai[bedrock]"

Now, the moment of truth:

crewai run

You'll see the agent start up, show you what it's thinking, and then produce the output. The whole thing takes about 20-30 seconds.

The result also gets saved to tailored_resume.md in your project folder.

If you got output congratulations. You just built your first AI agent. It read a job description, compared it to a resume, found the gaps, and rewrote the resume to match. All on its own.

Adding a Streamlit UI

Running agents from the terminal is fine for testing. But try showing that to someone who doesn't code. "Look at this terminal output!" doesn't impress anyone.

Streamlit gives us a web interface in about 30 lines of code. Two text boxes, a button, results on screen. Anyone can use it.

Install Streamlit

uv add streamlit

Create the UI

Create a file called streamlit_app.py in the project root (not inside src/):

import streamlit as st
from resume_tailor.crew import ResumeTailor

st.set_page_config(page_title="Resume Tailor Agent", page_icon="📄", layout="wide")

# Header
st.markdown("""
<h1 style='text-align: center;'>📄 Resume Tailor Agent</h1>
<p style='text-align: center; color: gray; font-size: 1.1em;'>Paste a job description → Get career guidance, skill gaps, and a tailored resume in seconds.</p>
<hr>
""", unsafe_allow_html=True)

# Input section
st.subheader("📥 Input")

col1, col2 = st.columns(2)
with col1:
    job_description = st.text_area("Job Description *", height=250, placeholder="Paste the job description here (required)...")
with col2:
    resume = st.text_area("Your Resume (Optional)", height=250, placeholder="Paste your resume here leave empty if you don't have one yet...")

col3, col4, col5 = st.columns(3)
with col3:
    years_experience = st.number_input("Years of Experience *", min_value=0, max_value=40, value=3)
with col4:
    expertise_level = st.selectbox("Expertise Level *", ["Fresher", "Junior", "Mid-Level", "Senior", "Lead", "Architect"])
with col5:
    st.markdown("<br>", unsafe_allow_html=True)
    analyze_btn = st.button("🚀 Analyze", type="primary", use_container_width=True)

# Info box
if not job_description:
    st.info("💡 **Tip:** Even without a resume, you'll get JD analysis, key technologies, and a career path to follow.")

# Process
if analyze_btn:
    if not job_description:
        st.error("⚠️ Please paste the job description to continue.")
    else:
        st.divider()
        st.subheader("📊 Analysis Results")
        with st.spinner("🤖 Agent is analyzing... this takes about 30 seconds."):
            inputs = {
                "job_description": job_description,
                "resume": resume if resume else "Not provided",
                "years_experience": str(years_experience),
                "expertise_level": expertise_level,
            }
            result = ResumeTailor().crew().kickoff(inputs=inputs)

        st.success("✅ Analysis complete!")
        st.markdown(result.raw)

        # Download button
        st.download_button(
            label="📥 Download Results",
            data=result.raw,
            file_name="resume_analysis.md",
            mime="text/markdown",
        )

# Footer
st.divider()
st.markdown("""
<p style='text-align: center; color: gray; font-size: 0.85em;'>
Built with CrewAI + Amazon Bedrock Nova Pro | By <a href="https://sarvarnadaf.com">Sarvar Nadaf</a>
</p>
""", unsafe_allow_html=True)

A few things to notice compared to a bare-bones approach:

Wide layout and styled header for a cleaner look
An info tip box when JD is empty reminds users they can still get value without a resume
A download button so users can save the analysis as a markdown file
A footer with attribution

If you're on EC2, make sure port 8501 is open in your security group before running. Go to EC2 console > your instance > Security > Security group > Edit inbound rules > Add rule: Custom TCP, port 8501, source 0.0.0.0/0. Save. (For production, restrict this to your IP instead of opening to the world.)

Run It

uv run streamlit run streamlit_app.py --server.address 0.0.0.0 --server.port 8501

Open your browser and go to http://your-server-ip:8501.

Paste a job description on the left, your resume on the right, click the button, and watch the agent work.

Let's Test It - Real Input, Real Output

Now that it's working, let's throw some real-ish data at it and see how good the output actually is.

For this test, I'm using a resume of an AI Engineer with 6 years of total experience, applying for a Senior GenAI Developer role. Both are kept short 5-6 bullet points each. I'm using random data here; you can use your own.

The Resume (what we already have):

- Developed machine learning and Generative AI solutions using Python, TensorFlow, PyTorch, Scikit-learn, and LLM frameworks.
- Built and deployed RAG-based chatbots, AI assistants, and NLP applications using LangChain, LangGraph, and vector databases.
- Designed and optimized data pipelines, performed feature engineering, and trained predictive models for business use cases.
- Developed REST APIs with FastAPI/Flask and deployed AI applications on AWS, Azure, or Google Cloud using Docker and Kubernetes.
- Integrated foundation models, embeddings, prompt engineering, and MCP-based tools into enterprise AI workflows.
- Worked with SQL/NoSQL databases, data visualization tools, and cloud-native services to support AI and analytics solutions.
- Collaborated with cross-functional teams to deliver scalable, production-ready AI applications while following MLOps and DevOps best practices.

The Job Description (what we're targeting):

- Design, develop, and deploy enterprise-grade Generative AI applications using Large Language Models (LLMs).
- Build AI agents, RAG pipelines, and MCP-based integrations using frameworks such as LangChain, LangGraph, and LlamaIndex.
- Develop scalable backend services and REST APIs using Python, FastAPI, or Flask, and deploy them on cloud platforms (AWS/Azure/GCP).
- Integrate vector databases, embeddings, and foundation models to deliver intelligent search and conversational AI solutions.
- Optimize AI applications for performance, scalability, security, cost efficiency, and responsible AI practices.
- Implement CI/CD pipelines, containerization (Docker/Kubernetes), monitoring, and MLOps/LLMOps best practices.
- Collaborate with cross-functional teams, mentor junior developers, and contribute to solution architecture and technical design.

The Settings:

Years of Experience: 6
Expertise Level: Mid-Level

A quick note on expertise level this isn't your total years in tech. It's how deep you are specifically in the GenAI space. You might have 6 years overall but still be mid-level when it comes to GenAI work. The agent adjusts its guidance and resume rewriting based on this, so set it based on your domain expertise, not your total career length.

The Results

Let's see what the agent gives us. Remember the output has five sections when you provide both a JD and a resume.

1. JD Summary

2. Matching Skills

3. Skill Gaps

4. Career Guidance

5. Tailored Resume

Why This Test Matters

You might be wondering - why pick two slightly different skill sets? The resume is an AI Engineer. The JD is a Senior GenAI Developer. They overlap, but they're not identical.

That's the point. I wanted to see how the agent handles the gap between "close but not quite" - and the results are genuinely impressive. It identified exactly where the resume falls short, suggested a clear path to bridge the gap, and rewrote the bullet points to speak the JD's language.

And here's the thing - you can customize the output further. Want exactly 8 tailored resume points? Add that to the task description. Want the career guidance to focus only on certifications? Tweak the prompt. The agent does what you tell it to. You control the output by controlling the instructions.

What Just Happened

Let's step back and look at what we built:

One YAML file to define the agent (who it is, what it's good at)
One YAML file to define the task (what to do, what the output should look like)
One Python file to wire them together
One Python file for the web UI

Four files. That's a working AI agent with a web interface.

The agent reads the job description, compares it to the resume (if provided), identifies key technologies to highlight, lists skill gaps as clean bullet points, gives a career roadmap, and rewrites the entire resume to match all in one pass, in about 30 seconds.

Even without a resume, it still delivers value JD analysis, key technologies, and a preparation path. So anyone can use it, whether they have a resume ready or not.

No training data. No fine-tuning. No complex pipelines. Just a well-written prompt, a good LLM, and a framework that handles the plumbing.

Source Code

The complete source code for this project is available on GitHub:

simplynadaf / resume-tailor-agent

AI agent that analyzes job descriptions, identifies skill gaps, and tailors your resume - built with CrewAI and Amazon Bedrock.

📄 Resume Tailor Agent

AI-powered resume tailoring — paste a job description, get a perfect match in seconds.

⭐ If this helped you, give it a star! It helps others find it.

Getting Started • How It Works • Demo • Contributing

🤔 The Problem

You're job hunting. Every company wants something slightly different. You've done the work — but your resume doesn't say it in the JD's language. ATS systems scan for keywords before a human ever sees your application. Wrong framing = filtered out automatically.

One application = 30 minutes of tweaking. Multiply that by 10+ applications.

This agent does it in 30 seconds.

✨ What It Does

One agent. One pass. Five powerful outputs.

🎯 With JD + Resume

Output	What You Get
📋 JD Summary	What they're actually looking for
🔑 Matching Skills	ATS keywords to highlight (e.g., `LLM`, `RAG`, `K8s`)
⚠️ Skill

…

View on GitHub

Getting Started

Follow these steps to run the project on your machine:

Clone the repository:

git clone https://github.com/simplynadaf/resume-tailor-agent.git

Navigate to the project and set up:

cd resume-tailor-agent
cp .env.example .env
crewai install
uv add "crewai[bedrock]"

Run the agent:

crewai run

Or launch the web UI:

uv run streamlit run streamlit_app.py --server.address 0.0.0.0 --server.port 8501

What's Next

We built one agent that does everything analyzes the JD, finds gaps, rewrites the resume. It works. But what if we split the work across specialists? A recruiter who decodes the JD, an analyst who finds the gaps, and a writer who nails the rewrite. Each one focused, each one sharper.

In the next article, we're upgrading to a multi-agent crew and you'll see how collaboration between specialized agents produces noticeably better results than one agent doing it all.

Until then try it with your own resume. Paste a real job description you're interested in. See what the agent comes up with. You might be surprised how good it is

📌 Wrapping Up

Thanks for reading! If this was helpful:

❤️ Like if it added value
💾 Save for later
🔄 Share with your team

Follow me for more on: AWS architecture, FinOps, DevOps, and AI Infrastructure.

👉 Visit my website | Connect on LinkedIn | Email: simplynadaf@gmail.com

Happy Learning 🚀

Introducing Lambda MicroVMs - Isolated, Stateful Sandboxes for Running Untrusted Code on AWS

Sarvar Nadaf — Tue, 30 Jun 2026 13:42:54 +0000

👋 Hey there, Tech Enthusiasts!

Let's get into it! 🚀

On June 22, 2026, AWS launched Lambda MicroVMs. It is a new compute primitive inside Lambda that gives you a dedicated Firecracker virtual machine per user or session. It is not an update to Lambda functions. It is a different thing with a different model, different pricing, and different use cases.

If you are building anything where users or AI agents execute arbitrary code and you need strong isolation, fast startup, and persistent state this is what you reach for now.

What Existed Before and Why It Was Not Enough

Before this launch, if you needed to sandbox untrusted code on AWS, you had three options. Each one forced a compromise.

EC2 instances give you full VM isolation and persistent state. But they are not fast enough for interactive use. Between AMI boot, instance initialization, and user data scripts, you are looking at 30 seconds to several minutes before a user can do anything. That kills the experience for coding assistants or on-demand sandboxes.

Containers (ECS/Fargate) start faster and keep state while running. But containers share a kernel with the host. That shared kernel is a security boundary you cannot fully trust when running code from strangers on the internet. You can layer security on top, but the fundamental model is weaker.

Lambda functions give you real VM-level isolation (they already run on Firecracker) and start in milliseconds. But they die after 15 minutes. They are stateless between invocations. They follow a request/response model. You cannot give a user a persistent environment where they write code, run it, see the output, install a package, and run again all within the same session.

Teams building coding assistants, AI agent sandboxes, or multi-tenant notebook platforms had to stitch together custom solutions. EC2 with a lifecycle manager. ECS with heavy security configuration. Running Firecracker directly on bare metal. All of it was operational overhead solving a problem that should have had a managed answer.

What Lambda MicroVMs Actually Is

Lambda MicroVMs is that managed answer.

You package your application code and a Dockerfile into a zip archive, upload it to S3, and call the Lambda API to create a MicroVM image. Lambda executes your Dockerfile, starts your application, and captures a snapshot of the fully initialized environment.

When you need a sandbox for a user, you call run-microvm. Lambda launches a MicroVM from that snapshot with rapid startup.

Each MicroVM gets:

Its own dedicated HTTPS endpoint (no load balancers or ingress infrastructure needed)
Full VM-level isolation (separate kernel, no shared resources with other tenants)
Persistent state for up to 8 hours (memory and disk survive suspend/resume)
Automatic suspend when idle (you stop paying for compute)
Automatic or programmatic resume when traffic arrives (picks up where it left off)
Vertical scaling up to 4x the configured baseline CPU and memory (e.g., 2 GB / 1 vCPU baseline scales to 8 GB / 4 vCPU)

Users connect over HTTP/2, gRPC, or WebSockets. Authentication is handled through bearer tokens you generate via the CreateMicrovmAuthToken API.

The Mental Model Shift

This is important: Lambda MicroVMs is not request/response.

With Lambda functions, a request comes in, your code runs, it returns a response, the invocation ends. Scaling is automatic. You think in terms of individual invocations.

With Lambda MicroVMs, you spin up a persistent VM for a user or session. It stays alive. It has a dedicated URL. Multiple requests hit the same VM. State accumulates. The user installs a package, it is still there on the next request.

You manage the fleet yourself. You decide when to create a MicroVM, which user it belongs to, and when to tear it down. There is no automatic horizontal scaling. Your application owns that logic.

This is closer to managing a pool of servers than it is to writing Lambda functions. The difference is you do not manage the infrastructure underneath no AMIs, no instance types, no patching, no capacity planning for the host.

What It Looks Like in Practice

Here is the basic workflow using the AWS CLI. Command names below follow the API naming convention. Check the CLI reference for your SDK version.

# Step 1: Upload your application package (Dockerfile + code) to S3
aws s3 cp my-sandbox-app.zip s3://my-bucket/my-sandbox-app.zip

# Step 2: Create a MicroVM image from your package
aws lambda create-microvm-image \
  --image-name my-sandbox \
  --s3-bucket my-bucket \
  --s3-key my-sandbox-app.zip

# Step 3: Launch a MicroVM for a user session
aws lambda run-microvm \
  --image-name my-sandbox \
  --memory-size 2048

# Step 4: Generate an auth token for the user to connect
aws lambda create-microvm-auth-token \
  --microvm-id mvm-abc123

# Step 5: When session ends, terminate
aws lambda terminate-microvm \
  --microvm-id mvm-abc123

The user connects to the dedicated HTTPS endpoint returned by run-microvm using their auth token. From there, they interact over HTTP/2, gRPC, or WebSockets depending on what your application exposes.

For shell access (giving users a terminal inside the VM):

aws lambda create-microvm-shell-auth-token \
  --microvm-id mvm-abc123

This returns credentials that connect directly to a pseudo-terminal inside the MicroVM. AI coding tools use this to provide real terminal experiences to end users.

Practical Details That Matter

Startup: MicroVMs launch from pre-initialized snapshots, similar to how Lambda SnapStart works. This skips application initialization entirely your environment is already warm when it starts.

Duration: Up to 8 hours per session. After that, the MicroVM is terminated.

Suspend/Resume: When no traffic hits a MicroVM, it suspends automatically based on an idle timeout you configure (how long it waits with no inbound traffic before suspending). You stop paying for compute. When a request arrives, it resumes with memory and disk state fully intact. You can also trigger suspend and resume programmatically via suspend-microvm and resume-microvm APIs. Resume latency is not a full cold start it restores from a memory snapshot, which is significantly faster than booting from scratch. AWS has not published exact resume latency numbers at launch, so expect to benchmark this for your specific workload.

Vertical scaling: You configure a baseline (default is 2 GB memory / 1 vCPU, allocated in a 2:1 memory-to-CPU ratio). During peak activity, the MicroVM can burst to 4x that baseline automatically. For example, a 2 GB / 1 vCPU baseline can burst to 8 GB / 4 vCPU. An 8 GB / 4 vCPU baseline can burst to 32 GB / 16 vCPU. You only pay for the burst resources during the time they are actually consumed.

Shell access: Full pseudo-terminal (/dev/ptmx) support. The CreateMicrovmShellAuthToken API lets you give users a real terminal inside their VM. This is how AI coding tools provide interactive terminal experiences.

Docker inside: You can run containers inside your MicroVM. Full OS capabilities are available installing system packages, mounting filesystems, running nested containers. One gotcha: outbound UDP is blocked by default, which breaks DNS resolution inside nested containers. Community workarounds exist for this.

Architecture: ARM64 (Graviton) only at launch.

Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Tokyo).

Pricing

Lambda MicroVMs pricing has three components: compute, snapshots, and data transfer.

Compute (US East, ARM/Graviton):

vCPU: $0.0000276944 per vCPU-second
Memory: $0.0000036667 per GB-second
Billed per second (not per millisecond like Lambda functions)

Snapshots:

Snapshot write (on suspend): $0.0038 per GB
Snapshot read (on launch or resume): $0.00155 per GB
Image storage: $0.08 per GB-month (1-week minimum retention)

Concrete example - coding assistant platform:

100 developers, each using a 2 GB / 1 vCPU MicroVM for 2.5 hours per day over 20 working days. Each environment suspends 6 times per day during idle periods. Monthly cost: approximately $1,241 total, or about $12.41 per developer per month.

Concrete example - CI/CD job runner:

10,000 jobs per month, each running for 10 minutes in an 8 GB / 4 vCPU environment. No suspend/resume (jobs run to completion). Monthly cost: approximately $1,124 total, or about $0.11 per job.

This pricing is closer to Fargate economics than Lambda function economics. You are paying for dedicated compute time, not per-invocation.

When to Use This

Use Lambda MicroVMs when:

You are building a coding assistant and need to execute AI-generated code safely
You have a multi-tenant platform where each user runs custom scripts
You need agent sandboxes where AI agents execute tools, install packages, and maintain state across steps
You are building an interactive notebook or REPL that needs per-user isolation
You run a vulnerability scanner that executes untrusted payloads
You need game servers that run user-supplied scripts with isolation
You are building reinforcement learning environments where each run needs a fresh, isolated sandbox

Do not use Lambda MicroVMs when:

You have a standard API backend (use Lambda functions)
You need automatic horizontal scaling without managing fleet logic (use Lambda functions or Fargate)
You want a fully managed agent hosting platform (use Bedrock AgentCore Runtime)
Your workload does not involve untrusted code execution (you probably do not need this level of isolation)
You need x86 architecture (ARM64 only at launch)

How It Compares to Bedrock AgentCore Runtime

Both services run on Firecracker. Both support 8-hour sessions. Both have shell access. But they solve different problems.

AgentCore Runtime is a managed agent platform. You deploy your agent code, AWS handles session routing, scaling, teardown, agent communication protocols, and authentication. You do not think about VMs. Your users talk to your agent through a managed endpoint.

Lambda MicroVMs is a raw compute primitive. You get the VM. You manage which user gets which VM. You handle lifecycle, cleanup, and routing. You have full control of what runs inside.

The analogy: AgentCore Runtime is to Lambda MicroVMs what Fargate is to EC2. Same isolation technology underneath, different level of abstraction on top.

If you are building an AI agent and want managed hosting AgentCore. If you are building a platform where each user gets their own isolated environment to run whatever they want Lambda MicroVMs.

Getting Started

You can provision Lambda MicroVMs through the AWS Console, CloudFormation, CDK, or the Agent Toolkit for AWS.

The developer guide is here: Lambda MicroVMs Guide

API reference: MicroVM API

Final Thought

Lambda MicroVMs fills a gap that has existed since serverless became mainstream. The question "how do I safely run someone else's code?" finally has a straightforward answer on AWS that does not involve stitching together three services and writing a custom orchestrator.

It is not magic. You still have to manage your fleet of MicroVMs, handle routing, and build the lifecycle logic. But the hard part fast, isolated, stateful VMs without managing infrastructure is handled for you.

For teams building AI-powered developer tools, this is probably the most relevant compute launch of 2026 so far.

📌 Wrapping Up

Thanks for reading! If this was helpful:

❤️ Like if it added value
💾 Save for later
🔄 Share with your team

Follow me for more on: AWS architecture, FinOps, DevOps, and AI Infrastructure.

👉 Visit my website | Connect on LinkedIn | Email: simplynadaf@gmail.com

Happy Learning 🚀

Going Serverless with Terraform - Deploying AWS Lambda Functions

Sarvar Nadaf — Fri, 19 Jun 2026 13:33:44 +0000

👋 Hey there, tech enthusiasts!

"Servers are like pets you feed them, nurse them, and cry when they die. Lambda functions are like cattle spin them up, use them, forget them."

🎯 Welcome Back!

Remember in Article 7 when you deployed web servers with a load balancer? You built EC2 instances running 24/7 behind an ALB. That's great for high-traffic web apps. But what about workloads that only run occasionally?

Here's the reality: You've been paying for EC2 instances 24/7 even when nobody's using them. That internal tool that processes files once a day? Running on a t3.medium at $30/month for 5 minutes of actual work.

Lambda changes the equation:

Pay only when code runs
No servers to patch or maintain
Scales from zero to thousands automatically
IAM roles handle permissions (you know this now!)

By the end of this article, you'll:

✅ Deploy Lambda functions with Terraform
✅ Create API Gateway endpoints for HTTP access
✅ Trigger Lambda from S3 file uploads
✅ Configure IAM roles with least privilege
✅ Set up CloudWatch logging automatically
✅ Test everything with real invocations

Time Required: 45 minutes (20 min read + 25 min practice)

Cost: $0 (Lambda free tier)

Difficulty: Intermediate

Let's go serverless! 🚀

💔 The Problem: Paying for Idle Servers

The Wake-Up Call

Monthly AWS bill review. Something doesn't add up:

EC2 Instances:
- file-processor (t3.medium)  → $30.37/month
  Actual compute time: 12 minutes/day
  Utilization: 0.8%

- api-backend (t3.small)      → $15.18/month
  Actual requests: 200/day
  Utilization: 2.1%

- cron-worker (t2.micro)      → $8.47/month
  Runs one script at midnight
  Utilization: 0.03%

Total: $54/month for services used less than 1% of the time.

With Lambda, that same workload costs under $1/month. Not a typo. Under one dollar.

When EC2 Doesn't Make Sense:

❌ Event-driven processing: File uploaded → process it → done

❌ Low-traffic APIs: Dozen requests per hour

❌ Scheduled tasks: Run once a day or hour

❌ Webhook handlers: Wait for external events

❌ Data transformations: Input → transform → output

Sound familiar? Let's move these to Lambda.

🌟 What is AWS Lambda?

Simple Definition

Lambda = Your code runs only when triggered. No servers. No patching. No scaling configuration.

Think of it like this:

EC2 is renting an apartment you pay monthly whether you're home or not
Lambda is a hotel room you pay only for the nights you stay

How Lambda Works:

Trigger (API call, S3 upload, schedule)
    ↓
AWS spins up your function (milliseconds)
    ↓
Your code runs
    ↓
Result returned
    ↓
Function shuts down (you stop paying)

Lambda + Terraform = Perfect Match

Why Terraform for Lambda?

Version control your function configuration
Consistent deployments across environments
IAM roles defined alongside functions (Article 9 skills!)
Connected resources (API Gateway, S3, CloudWatch) in one config

📋 Prerequisites

Before starting:

✅ Terraform installed (Article 2)
✅ AWS credentials configured
✅ Understand VPCs and Security Groups (Article 6)
✅ Basic Python knowledge (for Lambda code)

🏗️ What We're Building

┌─────────────────────────────────────────────────────┐
│                    Our Architecture                 │
│                                                     │
│  ┌──────────┐       ┌──────────────┐                │
│  │   User   │──────▶│ API Gateway  │                │
│  └──────────┘       └──────┬───────┘                │
│                            │                        │
│                            ▼                        │
│                     ┌──────────────┐                │
│                     │ Hello Lambda │──▶ CloudWatch │
│                     └──────────────┘                │
│                                                     │
│  ┌──────────┐       ┌──────────────┐                │
│  │ S3 Upload│──────▶│S3 Processor  │──▶ CloudWatch │
│  │  (.txt)  │       │   Lambda     │                │
│  └──────────┘       └──────────────┘                │
└─────────────────────────────────────────────────────┘

Two Lambda functions:

Hello API - HTTP endpoint via API Gateway, returns JSON
S3 Processor - Triggered when .txt files are uploaded to S3

Source Code

The complete source code and Terraform configuration used in this article can be found on GitHub:

simplynadaf / terraform-by-sarvar

Terraform Series

🚀 Terraform By Sarvar

Complete Terraform tutorial series from basics to advanced concepts

📖 Read the Series • 🌐 Portfolio • 💼 LinkedIn

📚 Series Overview

This repository contains ONLY Terraform code examples for the Terraform By Sarvar tutorial series.

⚠️ IMPORTANT: This repo contains only .tf files and infrastructure code. Articles are published on dev.to, not stored here.

📖 Read the series on dev.to: https://dev.to/sarvar_04/series/36963

🎯 What You'll Learn

✅ Infrastructure as Code (IaC) fundamentals
✅ Terraform basics to advanced concepts
✅ AWS resource provisioning
✅ Best practices and real-world patterns
✅ Production-ready configurations

📊 Series Progress

📖 Article Series

📘 Foundation (Articles 1-5) ✅ Complete

Introduction to Terraform & IaC - ✅ Published
Installation & Setup - ✅ Published
Your First AWS Resource - ✅ Published
Understanding Terraform State - ✅ Published
Variables and Outputs - ✅ Published

📗 Real Infrastructure (Articles 6-10) ✅ Complete

Building a VPC…

View on GitHub

Getting Started

Follow these steps to run the project on your local machine:

Clone the repository:

git clone https://github.com/simplynadaf/terraform-by-sarvar.git

Navigate to the project directory:

cd terraform-by-sarvar/articles/08-lambda-serverless

🔧 Step 1: Write the Lambda Functions

Before Terraform, we need the actual code. Create a lambda/ directory:

mkdir -p lambda

lambda/hello.py - Simple API handler:

import json

def lambda_handler(event, context):
    """
    Simple Hello World Lambda function
    """
    print(f"Event received: {json.dumps(event)}")

    # Get name from query parameters or use default
    name = "World"
    if event.get('queryStringParameters'):
        name = event['queryStringParameters'].get('name', 'World')

    response_body = {
        'message': f'Hello, {name}!',
        'timestamp': context.aws_request_id,
        'function_name': context.function_name,
        'memory_limit': context.memory_limit_in_mb
    }

    return {
        'statusCode': 200,
        'headers': {
            'Content-Type': 'application/json',
            'Access-Control-Allow-Origin': '*'
        },
        'body': json.dumps(response_body)
    }

lambda/s3_processor.py - Processes uploaded files:

import json
import urllib.parse

def lambda_handler(event, context):
    """
    Process files uploaded to S3
    """
    print(f"Event received: {json.dumps(event)}")

    for record in event['Records']:
        bucket = record['s3']['bucket']['name']
        key = urllib.parse.unquote_plus(record['s3']['object']['key'])
        size = record['s3']['object']['size']
        event_name = record['eventName']

        print(f"Processing file: {key}")
        print(f"Bucket: {bucket}")
        print(f"Size: {size} bytes")
        print(f"Event: {event_name}")

        result = {
            'status': 'processed',
            'file': key,
            'bucket': bucket,
            'size': size
        }

        print(f"Result: {json.dumps(result)}")

    return {
        'statusCode': 200,
        'body': json.dumps('File processed successfully')
    }

Key points:

lambda_handler is the entry point AWS calls
event contains trigger data (HTTP request, S3 event, etc.)
context has runtime info (request ID, function name, memory)
Always return a proper response with statusCode

🔧 Step 2: Terraform Configuration

main.tf - Here's the complete infrastructure:

terraform {
  required_version = ">= 1.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    archive = {
      source  = "hashicorp/archive"
      version = "~> 2.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

Notice the archive provider Terraform uses this to zip your Python files into deployment packages. No manual zipping.

Package the Lambda code:

data "archive_file" "hello_lambda" {
  type        = "zip"
  source_file = "${path.module}/lambda/hello.py"
  output_path = "${path.module}/lambda/hello.zip"
}

data "archive_file" "s3_processor_lambda" {
  type        = "zip"
  source_file = "${path.module}/lambda/s3_processor.py"
  output_path = "${path.module}/lambda/s3_processor.zip"
}

The archive_file data source creates zip files at plan time. When you change the Python code, Terraform detects the hash change and redeploys automatically.

🔧 Step 3: IAM Role (Applying Article 9 Knowledge)

resource "aws_iam_role" "lambda_role" {
  name = "${var.project_name}-lambda-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "lambda.amazonaws.com"
      }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_basic" {
  role       = aws_iam_role.lambda_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

resource "aws_iam_policy" "lambda_s3" {
  name = "${var.project_name}-lambda-s3-policy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Action = [
        "s3:GetObject",
        "s3:PutObject"
      ]
      Resource = "${aws_s3_bucket.lambda_trigger.arn}/*"
    }]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_s3" {
  role       = aws_iam_role.lambda_role.name
  policy_arn = aws_iam_policy.lambda_s3.arn
}

Key decisions:

AWSLambdaBasicExecutionRole AWS managed policy for CloudWatch Logs access. Every Lambda needs this.
Custom S3 policy Only GetObject and PutObject on our specific bucket. Least privilege from Article 9.
The assume role policy says "only Lambda service can use this role." No human, no other service.

🔧 Step 4: Lambda Functions

resource "aws_lambda_function" "hello" {
  filename         = data.archive_file.hello_lambda.output_path
  function_name    = "${var.project_name}-hello"
  role             = aws_iam_role.lambda_role.arn
  handler          = "hello.lambda_handler"
  source_code_hash = data.archive_file.hello_lambda.output_base64sha256
  runtime          = "python3.11"
  timeout          = 10
  memory_size      = 128

  environment {
    variables = {
      ENVIRONMENT = var.environment
      PROJECT     = var.project_name
    }
  }

  tags = {
    Name        = "${var.project_name}-hello"
    Environment = var.environment
  }
}

resource "aws_lambda_function" "s3_processor" {
  filename         = data.archive_file.s3_processor_lambda.output_path
  function_name    = "${var.project_name}-s3-processor"
  role             = aws_iam_role.lambda_role.arn
  handler          = "s3_processor.lambda_handler"
  source_code_hash = data.archive_file.s3_processor_lambda.output_base64sha256
  runtime          = "python3.11"
  timeout          = 30
  memory_size      = 256

  environment {
    variables = {
      ENVIRONMENT = var.environment
      PROJECT     = var.project_name
    }
  }

  tags = {
    Name        = "${var.project_name}-s3-processor"
    Environment = var.environment
  }
}

Why these settings:

source_code_hash Terraform redeploys when code changes. Without this, it won't detect updates.
timeout = 10 for Hello (API calls should be fast), timeout = 30 for S3 processor (file processing needs more time)
memory_size = 128 for Hello (minimal), 256 for S3 processor (more processing power)
handler = "hello.lambda_handler" format is filename.function_name

🔧 Step 5: CloudWatch Log Groups

resource "aws_cloudwatch_log_group" "hello_lambda" {
  name              = "/aws/lambda/${aws_lambda_function.hello.function_name}"
  retention_in_days = 7
}

resource "aws_cloudwatch_log_group" "s3_processor_lambda" {
  name              = "/aws/lambda/${aws_lambda_function.s3_processor.function_name}"
  retention_in_days = 7
}

Lambda creates log groups automatically, but Terraform-managed groups give you:

Controlled retention (7 days, not infinite)
Proper cleanup on terraform destroy
Cost control (old logs don't pile up)

🔧 Step 6: S3 Bucket with Lambda Trigger

resource "aws_s3_bucket" "lambda_trigger" {
  bucket = var.s3_bucket_name

  tags = {
    Name        = var.s3_bucket_name
    Environment = var.environment
  }
}

resource "aws_lambda_permission" "s3_invoke" {
  statement_id  = "AllowS3Invoke"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.s3_processor.function_name
  principal     = "s3.amazonaws.com"
  source_arn    = aws_s3_bucket.lambda_trigger.arn
}

resource "aws_s3_bucket_notification" "lambda_trigger" {
  bucket = aws_s3_bucket.lambda_trigger.id

  lambda_function {
    lambda_function_arn = aws_lambda_function.s3_processor.arn
    events              = ["s3:ObjectCreated:*"]
    filter_suffix       = ".txt"
  }

  depends_on = [aws_lambda_permission.s3_invoke]
}

Critical detail: The aws_lambda_permission must come before the bucket notification. The depends_on ensures this. Without it, S3 can't invoke your Lambda because the permission doesn't exist yet.

The filter_suffix = ".txt" means only .txt file uploads trigger the function. Upload a .jpg? Nothing happens. This prevents accidental infinite loops if your Lambda writes back to the same bucket.

🔧 Step 7: API Gateway

resource "aws_api_gateway_rest_api" "main" {
  name        = "${var.project_name}-api"
  description = "API Gateway for Lambda functions"

  endpoint_configuration {
    types = ["REGIONAL"]
  }
}

resource "aws_api_gateway_resource" "hello" {
  rest_api_id = aws_api_gateway_rest_api.main.id
  parent_id   = aws_api_gateway_rest_api.main.root_resource_id
  path_part   = "hello"
}

resource "aws_api_gateway_method" "hello_get" {
  rest_api_id   = aws_api_gateway_rest_api.main.id
  resource_id   = aws_api_gateway_resource.hello.id
  http_method   = "GET"
  authorization = "NONE"
}

resource "aws_api_gateway_integration" "hello_lambda" {
  rest_api_id             = aws_api_gateway_rest_api.main.id
  resource_id             = aws_api_gateway_resource.hello.id
  http_method             = aws_api_gateway_method.hello_get.http_method
  integration_http_method = "POST"
  type                    = "AWS_PROXY"
  uri                     = aws_lambda_function.hello.invoke_arn
}

resource "aws_api_gateway_deployment" "main" {
  rest_api_id = aws_api_gateway_rest_api.main.id

  triggers = {
    redeployment = sha1(jsonencode([
      aws_api_gateway_resource.hello.id,
      aws_api_gateway_method.hello_get.id,
      aws_api_gateway_integration.hello_lambda.id,
    ]))
  }

  lifecycle {
    create_before_destroy = true
  }

  depends_on = [aws_api_gateway_integration.hello_lambda]
}

resource "aws_api_gateway_stage" "main" {
  deployment_id = aws_api_gateway_deployment.main.id
  rest_api_id   = aws_api_gateway_rest_api.main.id
  stage_name    = var.environment
}

resource "aws_lambda_permission" "api_gateway" {
  statement_id  = "AllowAPIGatewayInvoke"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.hello.function_name
  principal     = "apigateway.amazonaws.com"
  source_arn    = "${aws_api_gateway_rest_api.main.execution_arn}/*/*"
}

API Gateway is verbose in Terraform. That's 7 resources for one endpoint. Here's what each does:

rest_api - The API itself
resource - The /hello path
method - GET on /hello
integration - Connect method to Lambda (always POST for Lambda proxy)
deployment - Snapshot of the API config
stage - Named deployment (dev, prod)
lambda_permission - Allows API Gateway to invoke the function

The triggers block on deployment ensures redeployment when any resource changes. Without it, API Gateway serves stale configurations.

🔧 Step 8: Variables and Outputs

variables.tf:

variable "aws_region" {
  description = "AWS region"
  type        = string
  default     = "us-east-1"
}

variable "project_name" {
  description = "Project name"
  type        = string
  default     = "terraform-lambda"
}

variable "environment" {
  description = "Environment"
  type        = string
  default     = "dev"
}

variable "s3_bucket_name" {
  description = "S3 bucket name for Lambda triggers"
  type        = string
  default     = "terraform-lambda-demo-2026"
}

outputs.tf:

output "api_gateway_url" {
  description = "API Gateway URL"
  value       = "${aws_api_gateway_stage.main.invoke_url}/hello"
}

output "hello_lambda_name" {
  description = "Hello Lambda function name"
  value       = aws_lambda_function.hello.function_name
}

output "s3_bucket_name" {
  description = "S3 bucket name"
  value       = aws_s3_bucket.lambda_trigger.id
}

🚀 Deploy and Test

# Initialize (downloads aws + archive providers)
terraform init

# Preview
terraform plan

# Deploy (creates ~18 resources)
terraform apply

Deployment takes about 2 minutes. Most of that is API Gateway.

✅ Testing

Test 1: API Gateway → Hello Lambda

# Get the API URL
API_URL=$(terraform output -raw api_gateway_url)

# Basic call
curl $API_URL

Expected output:

{
  "message": "Hello, World!",
  "timestamp": "abc123-def456",
  "function_name": "terraform-lambda-hello",
  "memory_limit": 128
}

# With query parameter
curl "$API_URL?name=Terraform"

Expected output:

{
  "message": "Hello, Terraform!",
  "timestamp": "xyz789",
  "function_name": "terraform-lambda-hello",
  "memory_limit": 128
}

Test 2: S3 Upload → Processor Lambda

# Create a test file
echo "Hello from Terraform Lambda demo" > test.txt

# Upload to S3 (triggers Lambda)
aws s3 cp test.txt s3://$(terraform output -raw s3_bucket_name)/test.txt


![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zliyk4zjtqmkcmszsncp.png)


# Check CloudWatch logs (wait 10 seconds)
sleep 10
aws logs tail /aws/lambda/terraform-lambda-s3-processor --since 2m

Expected log output:

Processing file: test.txt
Bucket: terraform-lambda-demo-2026
Size: 35 bytes
Event: ObjectCreated:Put
Result: {"status": "processed", "file": "test.txt", ...}

Test 3: Verify Non-.txt Files Don't Trigger

# Upload a .jpg - should NOT trigger Lambda
echo "not a text file" > test.jpg
aws s3 cp test.jpg s3://$(terraform output -raw s3_bucket_name)/test.jpg

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7a3sdyjpcrqhf1rnxej9.png)


# Check logs - no new entries
aws logs tail /aws/lambda/terraform-lambda-s3-processor --since 1m

Nothing. The .txt filter works.

🔍 Understanding the Cost

Lambda pricing:

First 1 million requests/month: FREE
After that: $0.20 per million requests
Compute: $0.0000166667 per GB-second

Our usage estimate:

API: 1,000 requests/day = 30,000/month → FREE
S3 processor: 100 files/day = 3,000/month → FREE

Compare to EC2:

Approach	Monthly Cost	Maintenance
EC2 t3.medium (24/7)	$30.37	Patch, monitor, scale
Lambda (30K requests)	$0.00	Zero maintenance

That's not a typo. For low-traffic workloads, Lambda is effectively free.

🐛 Troubleshooting

Issue 1: "Unable to import module 'hello'"

Error:

Runtime.ImportModuleError: Unable to import module 'hello': No module named 'hello'

Cause: Handler doesn't match filename. If your file is hello.py, handler must be hello.lambda_handler.

Fix: Verify handler in Terraform matches filename.function_name.

Issue 2: S3 Trigger Not Firing

Symptoms: Upload file, nothing in logs.

Check:

Is the file suffix .txt? Other files are filtered out.
Did the permission deploy before the notification? Check depends_on.
Check Lambda permission: aws lambda get-policy --function-name terraform-lambda-s3-processor

Issue 3: API Gateway Returns 500

Cause: Usually a Lambda execution error.

Debug:

# Check Lambda logs directly
aws logs tail /aws/lambda/terraform-lambda-hello --since 5m

# Test Lambda directly (bypass API Gateway)
aws lambda invoke \
  --function-name terraform-lambda-hello \
  --payload '{"queryStringParameters":{"name":"Test"}}' \
  response.json

cat response.json

Issue 4: "AccessDeniedException" on S3

Cause: IAM policy doesn't include the bucket or action needed.

Fix: Verify the custom policy references the correct bucket ARN with /* suffix for object-level actions.

💡 Best Practices

Set source_code_hash - Without it, Terraform won't redeploy when code changes.
Use archive_file data source - Let Terraform handle zipping. Manual zip files drift.
Set retention on log groups - Default is infinite. At $0.03/GB stored, this adds up.
Timeout appropriately - API handlers: 10-30s. Processing: 30-300s. Never use the 900s max unless you know why.
Memory = CPU - Lambda allocates CPU proportionally to memory. 128MB gets minimal CPU. 1024MB gets significantly more. If your function is slow, increase memory before optimizing code.
Environment variables for config - Never hardcode bucket names, table names, or URLs in your Lambda code. Pass them through environment variables in Terraform.

🧹 Cleanup

# Remove S3 objects first (bucket must be empty)
aws s3 rm s3://$(terraform output -raw s3_bucket_name) --recursive

# Destroy everything
terraform destroy

S3 buckets can't be deleted if they contain objects. Empty it first, then Terraform handles the rest.

✅ Summary

Today you learned:

✅ Deploy Lambda functions with Terraform
✅ Package Python code with archive_file
✅ Create API Gateway endpoints
✅ Trigger Lambda from S3 uploads
✅ Apply least-privilege IAM (Article 9 skills!)
✅ Manage CloudWatch logs with retention
✅ Test functions via API and S3

The serverless mindset: Stop paying for idle servers. Lambda runs your code only when needed, scales automatically, and costs nearly nothing for typical workloads.

🚀 What's Next?

In the next article, we'll add:

Terraform modules for reusability
Package your Lambda + API Gateway as a reusable module
Share infrastructure patterns across projects

Coming Up: Article 9: Secure Database Deployment: RDS + Secrets Manager with Terraform

📌 Wrapping Up

Thank you for reading. I hope this article provided practical insights and a clearer understanding of the topic.

If you found this useful:

❤️ Like if it added value
🦄 Unicorn if you’re applying it today
💾 Save it for your next optimization session
🔄 Share it with your team

💡 What’s Next

More deep dives are coming soon on:

Cloud Operations
GenAI & Agentic AI
DevOps Automation
Data & Platform Engineering

Follow along for weekly insights and hands-on guides.

🌐 Portfolio & Work

You can explore my full body of work, certifications, architecture projects, and technical articles here:

👉 Visit My Website

🛠️ Services I Offer

If you're looking for hands-on guidance or collaboration, I provide:

Cloud Architecture Consulting (AWS / Azure)
DevSecOps & Automation Design
FinOps Optimization Reviews
Technical Writing (Cloud, DevOps, GenAI)
Product & Architecture Reviews
Mentorship & 1:1 Technical Guidance

🤝 Let’s Connect

I’d love to hear your thoughts. Feel free to drop a comment or connect with me on:

🔗 LinkedIn

For collaborations, consulting, or technical discussions, reach out at:

📧 simplynadaf@gmail.com

Found this helpful? Share it with your team.

⭐ Star the repo • 📖 Follow the series • 💬 Ask questions

Made by Sarvar Nadaf

🌐 https://sarvarnadaf.com

DEV Community: Sarvar Nadaf

Sentry's Span Hierarchy Exposed a Silent Retry in My 5-Agent Pipeline. One Agent Took 22.6s, the Others Took 5.

Project Overview

simplynadaf / aws-security-posture-agent

Multi-agent AI system that scans AWS accounts for security misconfigurations using CrewAI + Amazon Bedrock, instrumented with Sentry AI Agent Monitoring. 5 specialist agents discover resources, analyze security, map to CIS benchmarks, score risk, and generate fix commands.

AWS Security Posture Agent

The Problem

What It Finds

Demo

Bug Fix or Performance Improvement

Code

fix: paginate IAM analysis and add token budget guard #1

What

How I found it

What I changed

Numbers

My Improvements

Best Use of Sentry

What I instrumented

The instrumentation code

What Sentry revealed

Sentry features used

Why this matters for AI agent observability

4 Silent Failures, 2 Undocumented APIs, and a Container That Crashed Because of a Missing User Directive

Table of Contents

The project

Failure 1: The SDK that doesn't exist on PyPI

Failure 2: The 200 OK that means failure

Failure 3: The container that crashed with no logs

Failure 4: The naming regex nobody documented

The two-client split nobody mentions

What I learned

Introducing AWS SimuLearn Badges: Free Proof That You Can Actually Build in the Cloud

Table of Contents

What AWS SimuLearn Badges Actually Are

Why This Matters More Than Another Certification

The 12 Badges Available Right Now

The Free Starting Path I Would Follow Today

The LinkedIn Advantage Nobody Is Talking About

For Career Switchers: Your Existing Skills Are the Cheat Code

My Honest Take After 10 Years in Cloud

Kiro CLI Gets Worse After an Hour. Here's How I Fixed It.

What actually happens when context fills up

Why this happens (and why "try harder" does not fix it)

The 5 failure modes (in order of how often I hit them)

What I do now

One task per session

Use /compact before it auto-triggers

Put persistent context in steering files (the biggest token saver)

Use conditional steering with fileMatch

Watch the percentage

Use knowledge bases for large reference material

Delegate exploration to sub-agents

A real example

The context budget cheat sheet

What this is NOT

Secure Database Deployment - RDS + Secrets Manager

Secure Database Deployment: RDS + Secrets Manager with Terraform

🎯 Welcome Back!

💔 The Problem: Password Catastrophes

The Horror Story

Common Password Mistakes:

🌟 What is AWS Secrets Manager? (Quick Theory)

Simple Definition

Why You Need This

What is RDS?

📋 Prerequisites

🏗️ What We're Building

📁 Project Structure

🔧 Step 1: Define Variables

🌐 Step 2: Create VPC with Private Subnets

🔒 Step 3: Configure Security Groups

🔐 Step 4: Set Up AWS Secrets Manager

🗄️ Step 5: Deploy RDS MySQL Database

👤 Step 6: Create IAM Role for EC2

🖥️ Step 7: Deploy EC2 with Database Access

📤 Step 8: Define Outputs

⚙️ Step 9: Set Variable Values

🚀 Step 10: Deploy the Infrastructure

1. Initialize Terraform