DEV Community: Sarvar Nadaf

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 🚀

You Don't Need an AWS Account to Learn AWS

Sarvar Nadaf — Thu, 25 Jun 2026 20:26:13 +0000

👋 Hey there, Tech Enthusiasts!

Let's get into it! 🚀

I once woke up to a $14 AWS bill because I forgot to stop an EC2 instance overnight. For a student, that felt like $1400. That one mistake made me afraid to touch anything in AWS for the next three weeks.

I didn't come from a coding background. I didn't have anyone to guide me. I watched videos, read documentation, tried things on the AWS console, and every single time I was terrified of one thing the bill. After that incident, I stopped experimenting freely. I played it safe. And playing it safe is the worst thing you can do when you're trying to learn cloud.

That fear slowed me down by months.

In my first real project, I deployed a Lambda function that wrote to DynamoDB. During development, I never tested what happens when DynamoDB throttles writes because I was too afraid to generate real traffic on AWS. In production, messages started disappearing silently. I spent two days debugging something I could have caught in five minutes if I had a safe local environment to test against.

Today, after years of working as a Cloud Architect across multiple companies and countries, I can tell you this with full confidence the single most important thing that separates a good cloud engineer from a mediocre one is hands-on practice. Not certifications. Not watching 40 hours of video. Hands-on. Breaking things. Fixing things. Understanding why something failed and how to bring it back.

A few months ago I found a tool that solves all of this. It's called Floci an open-source local AWS emulator. You run it in Docker, it gives you 58 AWS services at localhost, and it costs nothing. No AWS account. No credit card. No sign-up. No auth token.

Let me show you how it works.

The Problems You're Probably Facing Right Now

Fear of billing. Every time you try something new creating a VPC, launching an instance, testing Lambda there's this voice saying "what if I forget to delete this?" That fear kills curiosity.

No safe playground. The AWS Free Tier helps, but it has limits. Cross those limits once, and you get charged. For a student or a fresher, even a small unexpected bill feels massive.

Theory without practice. You watched hours of videos about S3 and DynamoDB. You can explain what they are. But can you actually use them? Can you create a bucket from the command line? Can you put data into a table and get it back? If not, you haven't really learned it.

Starting over after every mistake. When something breaks, most beginners delete everything and recreate it. They never learn to troubleshoot. They never learn why it broke. They just run away from the problem and start fresh. I did this for months.

If any of this sounds familiar, keep reading.

Before We Start: What You Need

Two things:

Docker a tool that runs applications in isolated containers. Think of it as a lightweight virtual machine. Floci runs inside Docker.
AWS CLI the command-line tool to interact with AWS services (optional, but I strongly recommend it)

That's it. Here's how to install both:

Note: Everything in this tutorial runs 100% offline on your own machine Mac, Windows, or Linux. I'm using an EC2 instance to demonstrate the steps, but that's just my setup. You don't need a cloud server. The exact same commands work on your laptop, completely offline, with no internet required after the initial install. That's the whole point.

Install Docker

Windows / Mac: Download and install Docker Desktop. Open it once installed that's all.

Ubuntu / Debian:

sudo apt-get update && sudo apt-get install -y docker.io docker-compose-v2
sudo systemctl start docker
sudo usermod -aG docker $USER

Amazon Linux / RHEL / Fedora:

sudo dnf install -y docker
sudo systemctl start docker
sudo usermod -aG docker $USER

Install Docker Compose plugin

sudo mkdir -p /usr/local/lib/docker/cli-plugins
sudo curl -SL "https://github.com/docker/compose/releases/latest/download/docker-compose-linux-$(uname -m)" \
  -o /usr/local/lib/docker/cli-plugins/docker-compose
sudo chmod +x /usr/local/lib/docker/cli-plugins/docker-compose

After running the Linux commands above, log out and log back in (or run newgrp docker) so the group change takes effect. Otherwise you'll get "permission denied" errors.

Install AWS CLI

Ubuntu / Debian / Amazon Linux:

curl "https://awscli.amazonaws.com/awscli-exe-linux-$(uname -m).zip" -o "awscliv2.zip"
unzip awscliv2.zip && sudo ./aws/install

(If unzip is not found, install it first: sudo apt-get install -y unzip or sudo dnf install -y unzip)

Mac:

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /

Windows: Download and run the installer from:
https://awscli.amazonaws.com/AWSCLIV2.msi

Verify the installation on any platform:

aws --version

Getting Floci Running

Open your terminal, create a new folder, and create the compose file:

mkdir floci-playground && cd floci-playground

Now create a file called docker-compose.yml inside this folder. You can use any text editor VS Code, nano, or even notepad. Paste this content:

services:
  floci:
    image: floci/floci:latest
    ports:
      - "4566:4566"
    volumes:
      - ./data:/app/data

Start it:

docker compose up -d

If you get docker compose: command not found, try the older syntax: docker-compose up -d. Both work the same way.

Wait a few seconds, then verify it's running:

# Linux / Mac
curl http://localhost:4566/_localstack/health

# Windows (PowerShell)
Invoke-RestMethod http://localhost:4566/_localstack/health

You should see something like this:

{"services":{"s3":"running","sqs":"running","dynamodb":"running","lambda":"running",...},"version":"1.5.25"}

All services showing "running" you're good to go.

Now tell your AWS CLI to talk to Floci instead of real AWS:

# Linux / Mac
export AWS_ENDPOINT_URL=http://localhost:4566
export AWS_DEFAULT_REGION=us-east-1
export AWS_ACCESS_KEY_ID=test
export AWS_SECRET_ACCESS_KEY=test

# Windows (PowerShell)
$env:AWS_ENDPOINT_URL="http://localhost:4566"
$env:AWS_DEFAULT_REGION="us-east-1"
$env:AWS_ACCESS_KEY_ID="test"
$env:AWS_SECRET_ACCESS_KEY="test"

The credentials can be anything. I use test because it's simple. Floci doesn't validate them it just needs non-empty values.

Your First Win: Create an S3 Bucket

S3 is the storage backbone of AWS. Logs go to S3. Backups go to S3. Static websites live on S3. If you understand S3, you already understand 30% of how AWS works.

aws s3 mb s3://my-first-bucket

Output:

make_bucket: my-first-bucket

That's it. You just created a bucket. One command. No console. No waiting.

Now upload a file:

echo "hello from my laptop" | aws s3 cp - s3://my-first-bucket/greeting.txt

Check if it's there:

aws s3 ls s3://my-first-bucket

2026-06-16 11:43:58         21 greeting.txt

Read it back:

aws s3 cp s3://my-first-bucket/greeting.txt -

hello from my laptop

That felt good, right? You just did exactly what production systems do store and retrieve data from S3. The same commands. The same behavior. When you move to real AWS someday, nothing changes except where the data lives.

Challenge: Upload 3 different files to your bucket, then try to delete the bucket without emptying it first. What error do you get? Now figure out how to fix it using only the CLI. This exact scenario comes up in every cloud job.

Create a DynamoDB Table and Store Data

DynamoDB confused me for weeks when I started. But once I actually created a table and put data into it, everything clicked. Let's make that happen for you right now.

Create a table:

aws dynamodb create-table \
  --table-name Users \
  --attribute-definitions AttributeName=id,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

Put an item in it:

# Linux / Mac
aws dynamodb put-item \
  --table-name Users \
  --item '{"id":{"S":"user-001"},"name":{"S":"Sarvar"},"role":{"S":"Cloud Architect"}}'

# Windows (PowerShell) - use double quotes and escape inner quotes
aws dynamodb put-item --table-name Users --item '{\"id\":{\"S\":\"user-001\"},\"name\":{\"S\":\"Sarvar\"},\"role\":{\"S\":\"Cloud Architect\"}}'

A quick note on the JSON format DynamoDB requires you to specify the data type for each value. "S" means String, "N" means Number. It looks verbose at first, but you get used to it quickly.

Get it back:

aws dynamodb get-item \
  --table-name Users \
  --key '{"id":{"S":"user-001"}}'

{
    "Item": {
        "id": { "S": "user-001" },
        "name": { "S": "Sarvar" },
        "role": { "S": "Cloud Architect" }
    }
}

You just stored and retrieved structured data from a NoSQL database. That's real cloud development.

Challenge: Put another item with the same id but a different name. Does it overwrite? Does it error? Now put 5 different users and try aws dynamodb scan --table-name Users to get all of them. This is how you learn database behavior by seeing it happen, not reading about it.

Send and Receive Messages with SQS

Almost every production system uses message queues. Order processing, notifications, async workflows queues are everywhere.

Create a queue:

aws sqs create-queue --queue-name orders

Send a message:

aws sqs send-message \
  --queue-url http://localhost:4566/000000000000/orders \
  --message-body '{"event":"order.placed","item":"cloud-book"}'

(That 000000000000 is the default AWS account ID that Floci uses. In real AWS, it would be your actual 12-digit account number.)

Receive it:

aws sqs receive-message \
  --queue-url http://localhost:4566/000000000000/orders

{
    "Messages": [
        {
            "MessageId": "ba4ea32c-cfdf-4c28-b705-8bcbb4d8a0d0",
            "Body": "{\"event\":\"order.placed\",\"item\":\"cloud-book\"}"
        }
    ]
}

Your message comes back exactly as you sent it.

Challenge: Receive the same message again. What happens? It disappears for about 30 seconds (this is called "visibility timeout" the time SQS hides a message after someone reads it, giving them time to process it). Wait 30 seconds and try again. It comes back. Now try deleting it after receiving. This is exactly how real applications process queues.

Create a Secret in Secrets Manager

Every application has passwords, API keys, and database credentials. Secrets Manager is where you store them securely.

aws secretsmanager create-secret \
  --name my-app/db-password \
  --secret-string "super-secret-password-123"

Retrieve it:

aws secretsmanager get-secret-value --secret-id my-app/db-password

{
    "Name": "my-app/db-password",
    "SecretString": "super-secret-password-123"
}

That's how real applications fetch database credentials at runtime instead of hardcoding them in code. Simple, but incredibly important in production.

Store Configuration in SSM Parameter Store

Parameter Store is where you keep application configuration feature flags, environment URLs, settings that change between dev and production.

aws ssm put-parameter \
  --name "/myapp/environment" \
  --value "development" \
  --type String

aws ssm put-parameter \
  --name "/myapp/max-retries" \
  --value "3" \
  --type String

Get them back:

aws ssm get-parameter --name "/myapp/environment"
aws ssm get-parameters --names "/myapp/environment" "/myapp/max-retries"

This is how every well-architected application manages configuration. No more hardcoding values in your code.

Use It With Python

If you want to go beyond CLI, here's how your application code talks to Floci. Make sure Python 3 is installed, then:

pip install boto3

import boto3

s3 = boto3.client("s3",
    endpoint_url="http://localhost:4566",
    region_name="us-east-1",
    aws_access_key_id="test",
    aws_secret_access_key="test")

s3.create_bucket(Bucket="my-python-bucket")
s3.put_object(Bucket="my-python-bucket", Key="hello.txt", Body=b"it works!")
print(s3.get_object(Bucket="my-python-bucket", Key="hello.txt")["Body"].read())

Output: b'it works!'

The only difference between this and production code is one line: endpoint_url. When you deploy to real AWS, remove that line. Everything else stays the same. You're writing production-ready code from day one.

The Way I Wish I Had Learned

Looking back at my journey, here's what I would do differently starting today:

Week 1-2: S3 and IAM. Create buckets, upload files, set permissions, try to access things you shouldn't. Break the permissions. Fix them. Understand what "Access Denied" actually means.

Week 3-4: DynamoDB. Create tables with different key structures. Put data. Query it. Understand the difference between get-item and query and scan.

Week 5-6: SQS, SNS, and Secrets Manager. Build a simple message flow. Store secrets. Retrieve configuration. These are the building blocks of every real application.

Week 7-8: Lambda. Write a simple function. Trigger it. See the logs. Floci runs real Lambda containers not mocks.

Throughout: Break everything. Delete tables while data is in them. Send malformed messages. Call APIs with wrong parameters. Read the error messages carefully. This is the real education.

Tips From Years of Cloud Work

1. Don't just create. Troubleshoot.

The skill that got me promoted from L1 Cloud Support to Cloud Architect wasn't creating infrastructure. It was fixing it when it broke. Break things deliberately on Floci and fix them without starting over.

2. Learn the CLI before the console.

In real jobs, you'll use CLI and infrastructure-as-code. Floci forces this habit because there's no console to click around in.

3. Read error messages. Actually read them.

Most beginners see an error and panic. AWS error messages are surprisingly helpful if you actually read them. Practice generating errors on Floci so you learn to read them calmly.

4. Document what you learn.

I filled four notebooks with cloud concepts. Later, I converted those notes into articles. That habit changed my career. Start writing about what you break and fix even if nobody reads it at first.

5. One concept per day is enough.

You don't need to learn all 200 AWS services. Focus on the core: storage, databases, messaging. One solid hour of hands-on practice beats five hours of video watching.

Common Mistakes Beginners Hit

Before you get stuck, here are the issues I see most often:

"Command not found: aws" - You haven't installed AWS CLI yet, or you need to restart your terminal after installation.
Commands hitting real AWS instead of Floci - You forgot to set AWS_ENDPOINT_URL. Always check with echo $AWS_ENDPOINT_URL before running commands.
"Cannot connect to the Docker daemon" - Docker Desktop isn't running. Open it first.
Data disappeared after restart - By default, Floci stores data in memory. Add FLOCI_STORAGE_MODE=hybrid to keep data between restarts:

services:
  floci:
    image: floci/floci:latest
    ports:
      - "4566:4566"
    environment:
      - FLOCI_STORAGE_MODE=hybrid
    volumes:
      - ./data:/app/data

When You're Ready for Real AWS

Here's the transition path:

Learn and practice on Floci (no cost, no risk)
When you feel confident, create an AWS Free Tier account
Deploy the same commands on real AWS they work identically
For your application code, just remove the endpoint_url line

There is no rewrite. No migration. No new learning curve. The skills you build on Floci transfer directly to real AWS because it's the same API, the same CLI, the same SDK.

Cleaning Up

When you're done for the day:

docker compose down

This stops everything. If you used hybrid storage mode, your data stays in the ./data folder for next time.

Final Thoughts

When I started learning cloud, I was scared of bills, confused by services, and paralyzed by the fear of breaking something expensive. I shipped broken code to production because I couldn't test properly locally. I wasted months playing it safe when I should have been experimenting aggressively.

That was then. Today, you have Floci.

If you're a fresher starting your cloud journey, a student preparing for certifications, or a working professional switching to cloud start here. Build things. Break things. Fix things. Do it a hundred times until the commands feel natural and the errors feel familiar.

The cloud rewards people who practice. Not people who watch.

In my next article, I'll show you how to deploy a complete serverless API Lambda + API Gateway + DynamoDB entirely on Floci, and then move it to real AWS with zero code changes. Follow me so you don't miss it.

Resources:

Floci GitHub:
floci-io / floci

Light, fluffy, and always free - The AWS Local Emulator alternative
Light, fluffy, and always free
No account. No auth token. No feature gates. Just docker compose up

Quick Start · Features · Services · SDKs · Testcontainers · Migration · Docs

What is Floci?

Floci is a free, open-source local AWS emulator for development, testing, and CI.

It gives you AWS-shaped services on your machine without requiring a cloud account, an auth token, or paid feature gates. Point your AWS SDK, CLI, Terraform, CDK, OpenTofu, or test suite at http://localhost:4566 and keep your existing workflows.

Floci is named after floccus, the cloud formation that looks like popcorn.

Quick Start

The fastest way to run Floci is with the official CLI
floci start
Export the AWS environment variables:
eval $(floci env)
Use your existing AWS tools normally:
aws s3 mb s3://my-bucket aws dynamodb create-table \ --table-name demo-table \ --attribute-definitions AttributeName=pk,AttributeType=S \ --key-schema AttributeName=pk,KeyType=HASH \ --billing-mode PAY_PER_REQUEST aws
…
View on GitHub
Floci Documentation: floci.io/floci/
Docker Hub: hub.docker.com/r/floci/floci

If this helped you, share it with someone who's starting their cloud journey. Drop a comment if you have questions I'll respond to every one.

Connect with me on LinkedIn for more cloud architecture, DevOps, and career guidance.

📌 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 🚀

My CDK Deploy Takes 7 Minutes: My Local Runner Takes 25ms

Sarvar Nadaf — Mon, 22 Jun 2026 13:45:18 +0000

👋 Hey there, Tech Enthusiasts!

Let's get into it! 🚀

I'm building something I've been excited about for months hosting a CrewAI-powered AI agent on AWS using Amazon Bedrock AgentCore, and exposing it through API Gateway + Lambda so external systems can talk to it over HTTP.

The architecture is straightforward:

Client → API Gateway → Lambda → AgentCore Runtime → CrewAI Agent → Bedrock (Claude)

The Lambda function is the bridge. It receives the HTTP request, formats it for my CrewAI agent running on AgentCore, waits for the response, and sends it back. Standard stuff.

Except the Lambda is where everything is painful.

I'm tweaking the request payload format for AgentCore. cdk deploy. Wait 7 minutes. Hit the endpoint. Response shape is wrong AgentCore returns nested JSON, my Lambda isn't unpacking it correctly. Fix one line. cdk deploy. Another 7 minutes. Realize I need to handle streaming responses differently. Another deploy.

By lunch I'd deployed 9 times and shipped maybe 40 lines of actual logic.

The CrewAI agent itself was working fine I'd already tested it locally with crewai run. The Bedrock model was responding perfectly. But the Lambda layer in between? Every tiny change to the request/response mapping cost me 7 minutes. That's where all my time was going.

Something had to change.

I Tried the Obvious Stuff

SAM CLI

First thing I reached for. sam local start-api that's literally what it's for, right?

Problem is, SAM wants a template.yaml. My infrastructure is CDK. I'm not maintaining two definitions of the same stack just to test locally. I tried passing cdk.out/MyStack.template.json directly to SAM and it half-worked some routes loaded, some didn't, the asset references were broken. I spent 45 minutes debugging SAM instead of building my feature.

Also, every request spins up a Docker container. On my MacBook that's 3-4 seconds of cold start per invocation. When I'm iterating on how my Lambda formats the AgentCore request testing different prompt structures, response parsing, error handling that completely kills the feedback loop.

And there's no hot reload. Change a file, stop SAM, run sam build, start SAM again. For five functions that's a 30-second rebuild cycle. Better than 7 minutes but still way too slow.

LocalStack

I've used LocalStack before for integration testing. It's impressive mocks basically all of AWS. But for this use case:

It took 20 minutes just to get the Lambda hot reload working. You have to deploy to some magic S3 bucket with a specific naming convention. Then it still wasn't picking up my changes consistently.

The Lambda hot reload features I needed are behind LocalStack's paid tier. I'm not paying monthly to test my API Gateway → Lambda mapping logic.

For a full event-driven system with SQS and Step Functions, sure, LocalStack makes sense. For "I want to hit my API and see what comes back" it's way overkill.

The Realization

I was staring at my cdk.out/ directory one morning I'd just run cdk synth to verify my stack before yet another deploy and it hit me:

Everything I need is right here.

The CloudFormation template has every route POST /agent/invoke, GET /agent/status, GET /agent/history, the whole thing. It has every Lambda function with its handler path and environment variables. It even has the authorizer config.

When you use CDK's NodejsFunction, esbuild metadata is written alongside the bundled assets in cdk.out/. That metadata traces back to the original TypeScript source file. So the synth output gives us the full route map and the entry points no extra config needed.

I don't need SAM to interpret this. I don't need LocalStack to mock it. I just need to read the JSON and wire up an Express server.

So that's what I built.

How It Works

cdk synth → cdk.out/MyStack.template.json
     ↓
  extract (parse the CF template → route manifest)
     ↓
  serve (Express + esbuild bundling + file watcher)

Extract reads your CloudFormation template and figures out which API Gateway routes map to which Lambda functions. It resolves the Fn::GetAtt references, walks the API Gateway resource tree to reconstruct full paths, and traces each handler back to its TypeScript source file.

Entry points are resolved in priority order:

esbuild metadata if your CDK project uses NodejsFunction, the .esbuild.meta.json in the asset directory traces back to the original source file. This is the zero-config path.
Fallback convention if metadata isn't available, it falls back to src/handlers/{logicalId}.ts. You can override this with a custom CDK aspect that annotates the template.

Serve takes that manifest and boots Express. Each route gets registered. When a request comes in, esbuild bundles the handler on-demand (takes about 20ms the first time), constructs a proper APIGatewayProxyEvent from the Express request, and invokes the handler. Response goes back to the client.

That's it. No Docker. No template to maintain. No magic.

The Hot Reload Part

This is where it actually gets good.

I've got chokidar watching my source directories. When I save a file, it checks: is this file a handler entry point? If yes, it invalidates just that one handler's cache. If it's a shared utility file, it clears all caches.

The Express server never restarts. The routes stay registered. The next request to a changed handler re-bundles it with esbuild (about 5ms for a typical handler) and runs the fresh code.

So my workflow for the AgentCore project became:

Tweak how my Lambda formats the CrewAI request payload
Save
curl -X POST localhost:3001/agent/invoke -d '{"task": "summarize this document"}'
See the result in under 50ms

No deploy. No container spin-up. No rebuild step. Just save and curl.

I went from "is my Lambda correctly parsing the AgentCore response?" being a 7-minute question to a 5-second question. That changed everything.

Here's what I measured on my dev machine:

Request	Time
First hit (cold bundle)	~25ms
Subsequent hits (cached)	<2ms
After file change (re-bundle)	~5ms

Versus 5-10 minutes per cdk deploy. I genuinely can't go back.

The Failure That Made Me Build This

Let me show you the exact moment that pushed me over the edge.

I had my Lambda calling AgentCore's invoke endpoint. The response was coming back as:

{
  "output": {
    "content": [
      {"type": "text", "text": "Here's the analysis..."}
    ]
  },
  "stopReason": "end_turn"
}

But my Lambda was returning:

{
  "statusCode": 200,
  "body": "[object Object]"
}

Classic. I forgot JSON.stringify() on a nested object. One line fix:

// Before (broken)
body: result.output.content

// After (fixed)  
body: JSON.stringify({ response: result.output.content[0].text })

That one-character-level fix cost me 7 minutes to discover because I had to deploy to see the output. With the local runner, I'd have seen [object Object] instantly, fixed it, saved, curled again done in 10 seconds.

After that, I spent a weekend building this tool. Never looked back.

The Comparison Nobody Asked For

	SAM CLI	LocalStack	This
Extra config	template.yaml	Docker + deploy setup	None*
Docker needed	Yes	Yes	No
Hot reload	Nope	Kinda works	Yes
Request latency	3-5s	~2s	<25ms
Monthly cost	Free	Paid for hot reload	Free
Drift risk	High (second template)	Medium (mock env)	None (reads cdk synth)

*Requires NodejsFunction (CDK's standard Lambda construct for TypeScript/JS) for zero-config entry point resolution.

Before/After

BEFORE (my AgentCore project):
  tweak Lambda → cdk deploy (7 min) → curl → wrong response → cdk deploy (7 min) → curl
  1 iteration = 14+ minutes

AFTER:
  tweak Lambda → save → curl (25ms) → wrong response → fix → save → curl (5ms) → done
  1 iteration = 10 seconds

Rough math: 12 fewer deploys × 7 minutes each = ~84 minutes saved per day. Over a week that's nearly a full workday I got back.

Using It

npm install --save-dev cdk-local-lambda

In your package.json:

{
  "scripts": {
    "synth": "cdk synth",
    "local": "npx cdk-local dev --cdk-out cdk.out --stack MyStack --port 3001",
    "dev": "npm run synth && npm run local"
  }
}

Then:

npm run dev

Found 5 route(s)
  POST   /agent/invoke       → src/handlers/invokeAgent.ts
  GET    /agent/status/{id}  → src/handlers/getStatus.ts
  GET    /agent/history      → src/handlers/getHistory.ts
  POST   /agent/feedback     → src/handlers/submitFeedback.ts
  GET    /health             → src/handlers/health.ts

🚀 CDK Local Lambda running on http://localhost:3001

Save a file. Hit the endpoint. Done.

Note: If you cloned the repo to contribute, run npm run build first. As an installed dependency, the CLI is ready to use.

Real Example: Testing My AgentCore Handler

Here's what my actual dev loop looks like now. My invoke handler takes a task, calls AgentCore, and returns the result:

# Test the invoke endpoint
curl -s -X POST http://localhost:3001/agent/invoke \
  -H "Content-Type: application/json" \
  -d '{"task": "summarize the Q2 report", "context": "finance"}' | python3 -m json.tool

Response:

{
  "requestId": "a1b2c3d4-e5f6-7890",
  "status": "completed",
  "response": "Here's the Q2 summary: Revenue increased 12% YoY...",
  "model": "claude-3.5-sonnet",
  "tokens": { "input": 847, "output": 234 }
}

Now I change how the response is formatted maybe I want to add execution time:

// src/handlers/invokeAgent.ts - add timing
const start = Date.now();
const result = await callAgentCore(task, context);
const duration = Date.now() - start;

return {
  statusCode: 200,
  body: JSON.stringify({ ...result, executionMs: duration }),
};

Save. Curl again. Fresh response with executionMs field. No deploy.

What It Doesn't Do

I'm not going to pretend this replaces a full deployment pipeline. It doesn't.

Works	Doesn't Work
API Gateway → Lambda (REST)	SQS / SNS / EventBridge triggers
Custom authorizers (TOKEN type)	REQUEST authorizers
Path params, query strings, headers	WebSocket APIs
JSON request/response bodies	API Gateway request validation
Environment variables (literals)	Cross-stack references (Fn::ImportValue)
Hot reload	Step Functions

Your handlers still call real AWS services. If your Lambda talks to AgentCore, it calls real AgentCore. If it writes to DynamoDB, it writes to real DynamoDB. This tool only mocks the API Gateway → Lambda invocation, not the services your code uses.

For my project, that's actually what I want I need to test with real AgentCore responses to make sure my parsing logic handles the actual response shape. I just don't want to wait 7 minutes to test that parsing.

Who Should NOT Use This

Being honest about where this doesn't fit:

You use Serverless Framework → use serverless-offline instead. It reads your serverless.yml directly.
You need SQS/EventBridge/Step Functions locally → use LocalStack. This only handles API Gateway → Lambda.
You don't use CDK → this reads cdk.out/. No CDK, no use.
Your Lambdas are Python/Go/Java → TypeScript/JavaScript only (esbuild is the bundler).
You need to mock downstream AWS services → this doesn't mock DynamoDB, S3, Bedrock, etc. Your handlers call real services.

When You Still Deploy

Before merging a PR (integration test with real services)
Validating IAM permissions actually work
Load testing
Anything async (SQS consumers, EventBridge rules)
First-time AgentCore endpoint validation (does the IAM role have bedrock-agentcore:InvokeAgent permission?)

I deploy maybe 2-3 times a day now instead of 15+. The local runner handles the "am I returning the right JSON shape" iterations. Deploy handles the "does my IAM policy actually let me call AgentCore" questions.

What's Coming

I'm actively using this daily on the AgentCore project and hitting edges:

[ ] HTTP API (v2) support different event format
[ ] REQUEST authorizer support
[ ] Lambda layers resolution
[ ] .env.local overrides for those [REF:xxx] placeholders
[ ] Multi-stack support

If any of those are blocking you, open an issue or better, a PR.

The Point

Here's what bugged me about both SAM and LocalStack for this use case: they add things. Another template. Another environment. Another service to configure and keep in sync.

CDK already knows everything about your API. It's sitting right there in cdk.out/. Reading it directly means nothing can drift, because there's nothing to drift.

Tools like serverless-offline and Architect's arc sandbox offer something similar for their own frameworks, but nothing that reads CDK synth output directly. That's the key difference your CDK code remains the single source of truth, locally and in production.

I wish I'd built this before starting the AgentCore project. Would've saved me an entire week of deploy-wait-test cycles.

Try It Yourself

Here's how to try it yourself in under 5 minutes. The complete source code is on GitHub:

simplynadaf / cdk-local-lambda

I Built a Local Lambda Runner for CDK - No Docker, No SAM, Sub-Second Reload

⚡ cdk-local-lambda

Run your CDK Lambda functions locally. No Docker. No SAM. Sub-second hot reload.

┌─────────────────────────────────────────────────────┐
│                                                     │
│   cdk synth → extract → serve                       │
│                                                     │
│   Change code. Save. Hit endpoint. Done.            │
│   No deploy. No Docker. No waiting.                 │
│                                                     │
└─────────────────────────────────────────────────────┘

Quick Start • How It Works • CLI Reference • Hot Reload • Examples

🤔 The Problem

Every CDK developer knows this loop:

Change 1 line → cdk deploy → wait 5-10 min → test → realize it's wrong → repeat

Existing solutions aren't great for CDK:

Tool	Issue
SAM CLI	Requires separate `template.yaml`, Docker cold starts, no hot reload
LocalStack	Heavy, Lambda hot reload behind paid tier, awkward setup

💡 The Insight

After cdk synth, everything you need is already in cdk.out/ — routes, handlers, env vars, authorizers. Why maintain a second config when the source of truth already exists?

…

View on GitHub

Step 1: Clone the Repository

git clone https://github.com/simplynadaf/cdk-local-lambda.git
cd cdk-local-lambda

This gives you the full project source code, example handlers, and a mock cdk.out/ template that simulates real CDK synth output.

Step 2: Install Dependencies

npm install

This installs Express, esbuild, chokidar, and commander everything the local runner needs. No global installs, no Docker, no AWS CLI required.

Step 3: Start the Local Server

npx tsx src/cli.ts dev --cdk-out examples/cdk.out --stack MyStack --port 3001

This uses tsx for development. In a published package you'd use npx cdk-local dev ... after building.

You should see the server boot with all routes listed:

Found 3 route(s)
  GET  /users      → examples/src/handlers/listUsers.ts
  GET  /users/{id} → examples/src/handlers/getUser.ts
  POST /users      → examples/src/handlers/createUser.ts

🚀 CDK Local Lambda running on http://localhost:3001

Step 4: Hit the Endpoints

Open a new terminal and test:

List all users:

curl -s http://localhost:3001/users | python3 -m json.tool

{
  "users": [
    {"id": "1", "name": "Alice", "email": "alice@example.com"},
    {"id": "2", "name": "Bob", "email": "bob@example.com"},
    {"id": "3", "name": "Charlie", "email": "charlie@example.com"}
  ],
  "count": 3
}

Get a specific user:

curl -s http://localhost:3001/users/1 | python3 -m json.tool

{
  "id": "1",
  "name": "Alice",
  "email": "alice@example.com"
}

Create a new user:

curl -s -X POST http://localhost:3001/users \
  -H "Content-Type: application/json" \
  -d '{"name":"Alice","email":"alice@example.com"}' | python3 -m json.tool

{
  "id": "1749637842910",
  "name": "Alice",
  "email": "alice@example.com",
  "createdAt": "2026-06-11T09:30:42.910Z"
}

Step 5: Test Hot Reload

This is the magic part. With the server still running:

Open examples/src/handlers/getUser.ts in any editor
Add a new field to the response for example, add "source": "hot-reloaded!" to the return object
Save the file

Watch the server terminal you'll see:

  ♻ Changed: examples/src/handlers/getUser.ts - invalidated 1 handler

Now curl the same endpoint again:

curl -s http://localhost:3001/users/1 | python3 -m json.tool

The response now includes your new field. No restart. No rebuild. Sub-second.

Step 6: Try Breaking Things

Test error handling:

# User that doesn't exist - should return 404
curl -s http://localhost:3001/users/999 | python3 -m json.tool

{
  "error": "User not found"
}

# Missing required field - should return 400
curl -s -X POST http://localhost:3001/users \
  -H "Content-Type: application/json" \
  -d '{}' | python3 -m json.tool

{
  "error": "name is required"
}

That's it. Six steps, no AWS account needed, no Docker, no deploy. The example uses mock handlers, but in a real project you'd point --cdk-out at your actual cdk synth output and it works the same way like I'm doing with my AgentCore project right now.

What I'm Building Next

The AgentCore integration is still in progress. Once it's stable, I'm planning a follow-up article showing the full architecture how I'm hosting a CrewAI multi-agent system on AgentCore and exposing it through the API Gateway + Lambda layer that this tool helped me iterate on 100x faster.

If you're working with AgentCore or any AI agent framework that needs an HTTP API layer, this same pattern applies. The Lambda is just a bridge and bridges need fast iteration.

If this is useful, star the repo. If something's broken, open an issue. If you want a feature, tell me in the comments
I'm building this for my own workflow anyway, might as well make it work for yours too.

📌 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!

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.

"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)

Building a VPC from Scratch…

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

My AI Agent Hit a Login Wall: BrowserAct Let It Ask for Help and Resume

Sarvar Nadaf — Tue, 16 Jun 2026 13:42:35 +0000

👋 Hey there, Tech Enthusiasts!

Let's get into it! 🚀

I'm a cloud architect. I manage infrastructure across multiple AWS accounts, run CI/CD pipelines, and keep monitoring dashboards healthy for clients. A lot of my day involves checking web-based tools Grafana, GitHub, vendor portals, internal dashboards most of which sit behind login walls and anti-bot protection.

But there was always a gap: the agent couldn't browse the web. It couldn't check a dashboard, read a protected page, or handle a login flow.

That changed when I integrated BrowserAct into my workflow. It's a browser layer that gives AI agents the ability to browse real websites with anti-detection, session management, and human handoff built in.

If you missed the first article where I covered the full setup, start there: I Gave My AI Agent a Real Browser - Here's What Actually Happened. This article focuses on the headless + human handoff pattern I've been running in production.

A Note on Tooling

I'm using Kiro as my AI agent it's free during preview and can execute CLI commands directly. But BrowserAct works with anything that can run shell commands: Claude Code, Cursor, Codex, CrewAI, LangChain, or even a simple bash script. The pattern is the same regardless of agent.

The Setup

I run BrowserAct on a Linux server no desktop, no display, just a terminal. This is how it runs in production for my client: headless on a server, triggered by cron or the agent.

Prerequisites

Before getting started, make sure the following components are installed on your system.

Verify Installed Versions

Run the following commands:

python3 --version
# Python 3.12+

node --version
# v18+

google-chrome --version
# Google Chrome 149.x.x.x

Install UV (If Not Already Installed)

BrowserAct uses Python tooling, and uv is the recommended package manager.

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

Install Google Chrome (If Not Already Installed)

Ubuntu / Debian

wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo apt install -y ./google-chrome-stable_current_amd64.deb

Amazon Linux

wget https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm
sudo yum localinstall -y google-chrome-stable_current_x86_64.rpm

Creating a BrowserAct API Key

To allow your AI agent to control a real browser, you'll need a BrowserAct API key.

Step 1: Sign In

Step 2: Open API Key Management

Click your profile email address in the top-right corner.
Select API Keys from the dropdown menu.
Click Manage Keys.

Step 3: Create a New API Key

Click Create Key.
Enter a descriptive name such as:

Amazon-Q
MCP-Server
Development
1. Click Create.

Step 4: Save the API Key

Copy the generated API key and store it securely. For security reasons, you may not be able to view the complete key again after leaving the page.

Treat your API key like a password. Never share it publicly or commit it to source code repositories.

Configure BrowserAct Authentication

Once you have your API key, authenticate BrowserAct using the following command:

browser-act auth set <your-api-key>

Successful authentication will return:

API key saved.

At this point, BrowserAct is connected and ready to provide browser access to your AI agent. The integration takes less than a minute and requires no additional configuration.

After that, the agent has a browser. One more step create a stealth browser instance:

browser-act browser create --type stealth --name "research"

id=101758963005571124 name="research" type=stealth

That id is your browser ID you'll use it every time you open a session. Think of it like a browser profile: it keeps its own fingerprint, cookies, and anti-detection settings. You create it once and reuse it across sessions.

Note: The browser ID shown in this article (101758963005571124) is from my account. When you run browser create, you'll get your own unique ID. Use that in place of mine throughout the examples.

Managing Sessions

Before starting new sessions, check if any are already running:

browser-act session list

session_name: research-gh
browser_type: stealth
browser_id: 101758963005571124
title: Trending repositories on GitHub today · GitHub
url: https://github.com/trending

session_name: research-hn
browser_type: stealth
browser_id: 101758963005571124
title: news.ycombinator.com
url: https://news.ycombinator.com/

session_name: research-ph
browser_type: stealth
browser_id: 101758963005571124
title: Product Hunt – The best new products in tech.
url: https://www.producthunt.com/

To close a specific session:

browser-act --session research-hn session close

session_name=research-hn closed=true

Tip: Always close sessions when you're done. Open sessions keep the browser running and consume resources. If you hit a "session already in use" error, it means that session name is still active either close it or use a different name.

Real Scenario: Morning Tech Research

One of the things I do for a client is compile a daily tech digest what's trending, what's launching, what competitors are shipping. Used to take me 30 minutes of tab-switching every morning.

Now my agent does it. Here's what that looks like.

Quick Extract One Session, One Page

# Open a stealth browser session on the target page
browser-act --session research-hn browser open 101758963005571124 https://news.ycombinator.com

# Get the page state
browser-act --session research-hn state

The agent got back clean, structured content page title, URL, and all interactive elements. From there it can extract exactly what it needs using JS eval:

browser-act --session research-hn eval 'JSON.stringify(Array.from(document.querySelectorAll(".athing")).slice(0,3).map(el => ({title: el.querySelector(".titleline a")?.textContent, points: el.nextElementSibling?.querySelector(".score")?.textContent})))'

[
  {"title": "AI agent bankrupted their operator while trying to scan DN42", "points": "171 points"},
  {"title": "Nobody ever gets credit for fixing problems that never happened", "points": "348 points"},
  {"title": "If you are asking for human attention, demonstrate human effort", "points": "537 points"},
  {"title": "Show HN: Homebrew 6.0.0", "points": "1145 points"}
]

Two commands to open, one to extract. The agent can summarize this, filter by topic, or flag anything relevant to the client.

Where this fits: Any team that needs a daily briefing tech trends, industry news, competitor launches. The agent grabs it, the team reads a summary instead of spending 30 minutes browsing.

Parallel Research - Three Sites at Once

For the full morning digest, the agent opens three parallel sessions on the same browser.

You can use the browser you already created, or create a separate one to keep research isolated from other workflows:

browser-act browser create
# Returns: id=101764340218654773

Then open sessions on it:

# Session 1: GitHub Trending
browser-act --session research-gh browser open 101764340218654773 https://github.com/trending

# Session 2: Hacker News
browser-act --session research-hn browser open 101764340218654773 https://news.ycombinator.com

# Session 3: Product Hunt
browser-act --session research-ph browser open 101764340218654773 https://www.producthunt.com

All three run independently. No conflicts. The agent works through each one:

browser-act session list

session_name: research-gh
browser_type: stealth
browser_id: 101764340218654773
title: Trending repositories on GitHub today · GitHub
url: https://github.com/trending

session_name: research-hn
browser_type: stealth
browser_id: 101764340218654773
title: news.ycombinator.com
url: https://news.ycombinator.com/

session_name: research-ph
browser_type: stealth
browser_id: 101764340218654773
title: Product Hunt – The best new products in tech.
url: https://www.producthunt.com/

Where this fits: Product teams that need multi-source intelligence before standup. Marketing teams tracking launches. DevOps engineers checking status pages across providers. Anything where you'd normally open 5+ tabs.

Structured Data Extraction

Instead of parsing full page HTML, the agent runs targeted JavaScript and gets clean JSON:

browser-act --session research-gh eval "JSON.stringify(Array.from(document.querySelectorAll('article.Box-row')).slice(0,3).map(r => ({repo: r.querySelector('h2 a')?.textContent.trim(), stars: r.querySelector('span.d-inline-block.float-sm-right')?.textContent.trim()})))"

[
  {"repo":"iptv-org /\n\n      iptv","stars":"2,650 stars today"},
  {"repo":"teslamate-org /\n\n      teslamate","stars":"35 stars today"},
  {"repo":"Panniantong /\n\n      Agent-Reach","stars":"1,045 stars today"}]

The agent navigated within the same session Python trending, then TypeScript without opening a new browser. Took a screenshot for the report. I covered extraction patterns in depth in previous article.

Where this fits: Competitor monitoring prices, features, reviews. The agent extracts exactly the data points you need as structured JSON. No scraping framework. No maintenance when the page layout changes. BrowserAct isn't a standalone scraping tool it's a browser layer. Your AI agent is the brain that decides what to do. BrowserAct is the eyes and hands that execute on the web.

Then the Agent Hits a Wall

Everything was going smoothly. The agent had data from three sources, screenshots saved, research compiling nicely. Then it tried to check my GitHub profile settings:

browser-act --session research-gh navigate https://github.com/settings/profile

Response:

url=https://github.com/login?return_to=https%3A%2F%2Fgithub.com%2Fsettings%2Fprofile
title=Sign in to GitHub · GitHub

Redirected to login. The agent checked the page state:

[2]<label />
    Username or email address
[3]<input type=text name=login />
[5]<input type=password />
[7]<input type=submit value=Sign in />
[8]<button />
    Continue with Google

With any other automation setup, this is where the workflow dies. Script crashes. Logs an error. Someone restarts it manually tomorrow.

Here's what my agent did instead.

The Agent Asks for Help

browser-act --session research-gh remote-assist --objective "Sign in to GitHub to access profile settings"

Remote assist session created.

Share this URL with the user:
  https://www.browseract.com/remote-cli/1c08b0f3e0cb46168c9dd836ead748d2
expires in 1h 0m

Human assist is now active - the browser is under user control.
Do not send browser commands until the user finishes the assist session.

The agent recognized it couldn't solve this. It generated a live URL and asked me for help.

Step 1: Open the Remote Assist URL

I opened that URL on my phone. I saw the actual browser the GitHub login page, exactly as the agent left it.

After opening the link in your browser, you'll see the remote session interface. Click "Take Control" to interact with the browser directly. The session remains active for up to 1 hour.

Step 2: Complete the Login

Once you click Take Control, you'll see the GitHub login UI. Enter your credentials and complete the OTP/2FA to sign in.

Step 3: Confirm Access

Once you log in successfully, you'll see the GitHub profile page confirming the session is now authenticated.

Step 4: Hand Control Back to the Agent

Click "Complete" in the top-right corner to end the human assist session and return control to the agent.

Once you click Done, the step is completed. The agent is now rerouted back to the BrowserAct terminal to continue its work.

The Agent Resumes Same Session, No Restart

After the human signs in and closes the remote-assist session, the agent picks up exactly where it left off:

# Verify: agent checks where it is now
browser-act --session research-gh state

url=https://github.com/settings/profile
title=Your profile

[14]<a class=color-fg-default />
    Sarvar's (simplynadaf)
[15]<a class=btn btn-sm />
    Go to your personal profile
[16]<a />  Public profile
[17]<a />  Account
[18]<a />  Appearance

No login prompt. The agent now has full access to the authenticated GitHub session.

Proof: Navigating Authenticated Content

The agent can now access any authenticated resource without interruption:

browser-act --session research-gh navigate https://github.com/simplynadaf/devsecops-pipeline-demo

url=https://github.com/simplynadaf/devsecops-pipeline-demo
title=simplynadaf/devsecops-pipeline-demo: DevSecOps Pipeline Demo with Security Scanning
new_tab=False

It shows the repo title instead of redirecting to /login proving the authenticated session is active and persisted through the handoff.

The agent continued from where it left off. Same session. Same browser state. No restart. No lost context.

The Handoff Flow

Input	BrowserAct Action	Output
`navigate github.com/settings/profile`	Detects login redirect	Login wall identified
`remote-assist --objective "Sign in to GitHub"`	Generates live URL, pauses agent	URL sent to human via Slack
Human signs in + 2FA on phone	Session state preserved	Agent resumes with authenticated session
`state`	Reads authenticated page	Profile settings data extracted

Morning Report Output

After the agent completes all checks (including the ones that needed human login), it posts this to #team-status:

DAILY INFRASTRUCTURE REPORT - Mon Jun 15, 2026 06:04 UTC

Grafana (prod):     All dashboards green. No alerts in 24h.
GitHub (org):       3 PRs merged overnight. 1 pending review.
AWS Health:         No scheduled maintenance. All regions healthy.
Vendor Portal:     SSL cert expires in 12 days. Ticket created.
Uptime Monitor:     99.97% across all endpoints (7-day avg).

Auth events:       1 remote-assist triggered (GitHub session expired).
                   Resolved in 38 seconds by on-call.

Next run: Tomorrow 06:00 UTC

Why This Is a Design Pattern

Most automation falls into two camps:

Fully automated (breaks when anything unexpected happens)
Fully manual (defeats the purpose of automation)

The human handoff is a third option: the agent does 95% of the work autonomously. When it hits the 5% that requires a human a login, a 2FA prompt, a CAPTCHA it can't solve it pauses, asks for help, and resumes.

I've been building automation for years. Every time I tried to make something "fully automated" that involved login-protected tools, it would break within a week. Session expired. MFA rotated. Cookie invalidated.

The answer was always "just add a human step" but there was never a clean way to do that without killing the whole automation. This is the clean way.

It Runs Headless - That's What Makes It Production Ready

This entire test ran on a Linux server with no display:

echo $DISPLAY
# (empty - no GUI)

No screen. No desktop. The agent and BrowserAct run completely headless. But when remote-assist triggers, it gives the human a visual interface to that headless browser through a URL.

You see the browser as if it were on your desktop even though it's running on a server with no monitor attached.

This means:

Your agent runs on any server, any cloud, any CI pipeline
No VNC, no desktop environment, no display needed
When human help is needed, the URL works from any device - phone, laptop, tablet
After the human is done, the headless agent continues

Where this fits: DevOps and SRE teams running agents on headless servers or in containers. When the agent needs a human, tap the link from your phone on a train, in a meeting, or at 2 AM.

How This Runs in Production

Here's the actual workflow I built for my client's infrastructure monitoring:

6:00 AM - Cron triggers the agent

Agent (headless, on Linux Server):
  → Opens parallel sessions on 5 dashboards
  → Extracts status data, takes screenshots
  → Hits a login wall on one dashboard (session expired overnight)
  → Sends remote assist URL to Slack

6:01 AM - Slack notification on the on call engineer's phone

Engineer (half awake):
  → Taps the URL
  → Sees the login page
  → Signs in, taps MFA approve
  → Closes

6:02 AM - Agent resumes, finishes remaining checks, posts morning report to #team-status

Authentication happens maybe once or twice a week. The agent handles everything else every day. That's the ratio 95% automated, 5% human, zero broken pipelines.

The Honest Review

What worked:

Human handoff works exactly as described. URL generates instantly, state persists after.
The agent-to-browser integration is clean. Commands are simple, outputs are agent-friendly.
Anti-detection gets through Cloudflare without the agent doing anything special.
Headless mode on a server with no display works perfectly with remote assist.
Parallel sessions are stable and independent.
JS eval gives the agent precision extraction without any scraping libraries.

What could be better:

Documentation is dense. The skill reference is thorough but overwhelming the first time.
Error messages aren't always helpful. "Connection closed" doesn't tell you much.
Speed is slower than raw Puppeteer. The anti-detection adds a few seconds per session.
You need an API key for the stealth features.

FAQ

Can AI agents handle login walls?

Not on their own. When an agent hits a login page, it can't type your password or tap your MFA prompt. It just gets stuck. BrowserAct solves this with remote assist the agent pauses, sends you a link, you handle the login, and the agent picks up where it left off.

What is BrowserAct remote assist?

It's a feature that lets your agent ask a human for help mid workflow. The agent generates a URL that opens the live browser in your phone or laptop. You do the human step (login, 2FA, CAPTCHA), close it, and the agent continues automatically. No restart, no lost state.

Does BrowserAct need an API key?

Yes, for the stealth browser features (anti-detection, fingerprint masking, proxy rotation). You can get one at browseract.com. There are free credits on signup to test with.

Can this run on a headless server?

Yes. That's how I run it on an Linux Server with no display, no desktop environment. The browser runs headless. When the agent needs a human, the remote-assist URL gives you a visual interface to that headless browser from any device.

Getting Started

If you want to try this with your own agent:

Install: npx skills add browser-act/skills --skill browser-act --yes
Install CLI: uv tool install browser-act-cli --python 3.12
Get an API key from browseract.com
Set it: browser-act auth set <your-key>
Your agent can now browse.

Works with Kiro, Claude Code, Cursor, Codex, CrewAI, or any tool that can run shell commands. The agent doesn't need to be special it just needs to call the CLI.

The Bottom Line

The browser was always the gap in agent automation. Not because agents can't reason about web content they can. But because the web is built for humans, and the moment authentication enters the picture, pure automation dies. The human handoff pattern fixes this: the agent does 95% of the work, asks for help on the 5% it can't handle, and resumes without missing a beat. It's practical, it runs in production, and it replaced a workflow that used to break every other week.

If you're a DevOps engineer, SRE, or cloud architect running AI agents and your agents can't touch the web this is worth 30 minutes of your time to test.

Resources

📌 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 AWS FinOps Agent - An AI That Investigates Your Cloud Costs

Sarvar Nadaf — Thu, 11 Jun 2026 19:10:23 +0000

👋 Hey there, Tech Enthusiasts!

Let's get into it! 🚀

If you have managed AWS costs across multiple accounts, you know the pain. You get an alert at 9 AM that something spiked overnight. You open Cost Explorer, filter by service, then by account, then by region. Then it is over to CloudTrail to figure out what changed. By the time you trace it to a developer who launched a new instance type in a test account, two hours have passed. And that was just one anomaly.

I have been doing this for years across organizations running 50 to 500 AWS accounts. Monthly cost reviews, chasing engineers for explanations, building reports in spreadsheets that nobody reads until budget meetings. When AWS announced the FinOps Agent in public preview on June 9, 2026, I cleared my afternoon and set it up.

This article is my honest take after spending real time with it what it does well, where it fits in an enterprise setup, and how it changes the daily work for architects and FinOps teams.

What Is AWS FinOps Agent, in Plain Terms?

It is an AI agent that sits on top of your existing AWS cost tools Cost Explorer, Cost Anomaly Detection, Cost Optimization Hub, Compute Optimizer, and CloudTrail and does the manual work you have been doing yourself.

You ask it questions in plain English. It pulls data from those services, correlates events, and gives you answers. You can also tell it to run tasks on a schedule or react when a cost anomaly fires.

It runs in us-east-1 during the preview, but it can see cost data from all your regions (except GovCloud and China). It is free during the preview period with a monthly usage cap.

The underlying engine uses Amazon Bedrock foundation models, but you do not need to know or care about that. You just talk to it.

Setting It Up Genuinely Simple

I was expecting a 30-minute setup with IAM policy headaches. It took about 5 minutes.

Here is the actual flow:

Open the AWS Console, switch to us-east-1, find FinOps Agent
Click "Get Started" and give your agent a name
It creates an IAM role for you with one click read-only access to billing and cost management services
Optionally connect Jira and Slack
Open the web application and start asking questions

That is it. No CloudFormation stack, no Terraform module, no custom Lambda functions. The whole process felt like it was designed for people who have better things to do than fight with IAM policies.

One thing to note: if you have multi-session enabled in your AWS Console, disable it first. I hit a permissions error during Slack setup that traced back to this. The documentation does not make this obvious upfront.

Also, if you are setting up Slack, you need to add the FinOps Agent app as a member of the channel before configuring the integration in the console. Miss that step and you will get an error with no helpful message. The AWS docs mark it as "Important" but it is easy to skip over.

The First Question I Asked

I opened the chat and typed:

"What were my top 5 cost drivers last month, grouped by service and account?"

Within about 15 seconds, it came back with a table showing exactly that. It pulled from Cost Explorer, broke it down by service, showed the account names, and included the percentage change from the previous month.

No dashboard to build. No saved report to configure. Just a question and an answer.

I then asked a follow-up about why EC2 costs went up in one of my accounts. The agent went deeper it identified the instance type that caused the increase, surfaced the relevant CloudTrail event showing when those instances were launched, and pointed to the IAM role that made the API call.

That kind of investigation jumping between Cost Explorer and CloudTrail, matching timestamps, finding the right principal usually takes me 20 to 30 minutes. The agent did it in under a minute.

One thing I learned quickly: by default, costs shown include credit adjustments. If you want pre-credit numbers (which is what most enterprises care about for budgeting), you need to say that in your prompt. I told the agent to always exclude credits, and it remembered that preference in my next session without me repeating it.

Where This Solves Real Enterprise Pain

Let me map this to the problems I have seen in every organization I have worked with.

Problem 1: Cost Anomalies Go Uninvestigated

Every enterprise I know has AWS Cost Anomaly Detection turned on. Most of them also have a shared email inbox or Slack channel where those alerts land. And in most cases, those alerts sit there for hours or days before someone looks at them.

The reason is simple investigation is manual and time-consuming. AWS FinOps Agent automates this. You set up an automation that says: "When a cost anomaly is detected above $500, investigate it, find the root cause, and post the findings to our #finops-alerts Slack channel."

From that point, every anomaly gets investigated the moment it arrives. The output includes what changed, the CloudTrail event that caused it, the IAM principal responsible, and a summary of the likely root cause.

For a small FinOps team supporting many accounts, this is the difference between catching problems in hours versus catching them in days.

Problem 2: Engineers Cannot Self-Serve Cost Information

In most enterprises, if a developer wants to understand their team's cost, they either need Cost Explorer access (which many organizations restrict) or they file a request with the central FinOps team.

This creates a bottleneck. In my experience, the FinOps team ends up spending a significant chunk of their time answering basic questions like "How much did our staging environment cost last month?" or "Which of our Lambda functions is the most expensive?"

With FinOps Agent, engineers ask their question, the agent answers it using real data, and the FinOps team never gets involved.

You can also upload context files a CSV that maps accounts to team owners, a document that explains your tagging conventions, a list of which cost centers map to which business units. The agent uses this context to understand questions like "What is Team Alpha spending?" without anyone having to explain which accounts belong to Team Alpha.

Problem 3: Monthly Reports Are a Time Sink

Every FinOps team I have worked with produces some version of a monthly cost report. It goes to finance, to engineering leadership, sometimes to the CTO. Building it involves exporting data from Cost Explorer, formatting it in a slide deck or spreadsheet, adding commentary about what changed, and sending it out.

This takes 4 to 8 hours per month in my experience. Some teams spend even longer because different stakeholders want different views.

FinOps Agent lets you schedule these. You tell it: "Every Monday at 8 AM, generate a cost report for last week broken down by business unit, highlight any changes over 10%, and deliver it as a PDF to the #finops-weekly Slack channel."

It runs on schedule. No human involvement. The report shows up in Slack every Monday. You can set up different reports for different audiences a detailed one for engineering leads, a summary for finance, an executive view for the CTO.

The output formats are HTML, PDF, or PPT all presentation-ready.

Problem 4: Optimization Recommendations Sit in a Dashboard Nobody Checks

AWS Cost Optimization Hub and Compute Optimizer both produce solid recommendations rightsizing opportunities, idle resources, Savings Plans suggestions. The problem is that these recommendations live in AWS dashboards that engineers rarely check.

FinOps Agent can pull these recommendations, summarize them, and create Jira tickets assigned to the team that owns each resource. Instead of a FinOps analyst manually reviewing the dashboard and creating tickets, the agent does it on a schedule.

Example automation: "Every Thursday, check Cost Optimization Hub for new recommendations over $100/month in potential savings. For each one, create a Jira ticket in the INFRA project with the recommendation details, the affected resource, and the estimated savings."

Now optimization work flows into engineering sprints naturally, without someone manually copying data between tools.

How It Fits Into an Enterprise Architecture

Let me describe how I would deploy this in a typical multi-account enterprise setup.

Management Account Setup

You create the FinOps Agent in your management account (or the account that has the consolidated billing payer role). This gives it visibility across all member accounts. The IAM role it creates is read-only by default it cannot make changes to your infrastructure.

Member account owners can also create their own agent scoped to just their account if they want independent cost visibility without management account access. This means you can have multiple agents with different scopes a central one for the FinOps team and individual ones for teams that want their own view without seeing the full organization.

Access Patterns

Role	How They Use It
FinOps Team	Set up automations for anomaly investigation, scheduled reports, optimization ticket creation
Engineering Leads	Ask ad-hoc cost questions about their team's spend
Finance	Receive scheduled reports in their preferred format
Platform Team	Monitor shared infrastructure costs, investigate spikes in shared services
Individual Engineers	Self-serve answers about their service's cost impact

How the Pieces Connect

The agent reads from your existing AWS cost services Cost Explorer for spend data, Cost Anomaly Detection for alerts, Cost Optimization Hub and Compute Optimizer for recommendations, and CloudTrail for change history. It writes only to Jira and Slack when you configure those integrations and trigger a task. It does not modify any AWS resources.

Security Model

IAM role-based access (you control what it can read)
Read-only by default against billing services
Write actions (Jira tickets, Slack posts) only happen when you configure and trigger them
All activity logged in CloudTrail for audit
No cross-account write permissions
The agent uses Amazon Bedrock foundation models to process your queries your cost data is accessed through IAM roles within your own account and does not leave AWS

One thing worth noting for architects evaluating risk: this service has zero infrastructure dependency. Your actual cost tools, accounts, and resources are unchanged. If the agent were deprecated tomorrow, you would be back to manual work not rebuilding systems. That makes it a low-risk addition to your environment during preview.

What I Noticed During Hands-On Testing

The Good

Speed of answers. Asking a cost question and getting a real answer in 15-30 seconds changes your workflow. I found myself asking follow-up questions I would never have bothered investigating manually.

Root cause correlation. The fact that it connects Cost Anomaly Detection alerts to CloudTrail events automatically is genuinely useful. This is the step that takes the most time in manual investigation.

Scheduled tasks actually work. I set up a weekly report for Thursday morning. It fired within 2 minutes of the scheduled time, and the PDF it produced was clean and readable. Results also get stored in an "Artifacts" tab in the web app for later access.

Context files are powerful. After uploading an account-to-team mapping, the agent started answering team-level questions correctly without any additional configuration.

Memory across sessions. I told it to always exclude credits when showing cost totals. In my next session, it remembered that preference without me repeating it.

The Rough Edges (It Is Preview After All)

Slack messages are links, not inline content. When the agent posts to Slack, it sends a link back to the FinOps Agent web app rather than the full analysis inline. This means you still need to click through to see the details. For a quick glance during a busy morning, this adds friction.

Sending to Slack is not automatic. After the agent completes an analysis in a chat session, you still need to explicitly prompt "Please send this to Slack." Event-triggered automations handle routing on their own, but for ad-hoc queries you need that extra step.

English only. Prompts in other languages sometimes work, but responses are always in English. Some prompts get a flat "Only English is supported" response. Global enterprises will need multi-language support at GA.

Single region availability. The agent only runs in us-east-1 during preview. It can see multi-region cost data, but the console experience requires you to be in that region.

No IaC support yet. You cannot create the agent via CloudFormation or Terraform. Console-only setup for now. For enterprises that mandate infrastructure as code for everything, this is a blocker until GA.

Compute Optimizer queries are region-scoped. When I asked for rightsizing recommendations, it only checked us-east-1 by default. You need to specify other regions explicitly in your prompt. Easy to miss if you have workloads spread across multiple regions.

Trust but verify. Like any AI system, the agent can occasionally misidentify a root cause or produce an incomplete analysis. In the early days, treat its output as a strong starting point that still needs a human eye before you act on it or forward it to engineering. Once you have seen enough accurate results to build confidence, you can reduce oversight.

Real Workflow: Before and After

Let me lay out what a typical week looks like for a FinOps team before and after adopting this. These numbers assume automations are tuned and the agent is producing reliable output getting there takes a week or two of initial validation.

Before FinOps Agent

Monday morning:

Check Cost Anomaly Detection alerts from the weekend (5 alerts) - 10 minutes
Open Cost Explorer for each alert, filter by account/service/time - 15 minutes per alert
Open CloudTrail, search for relevant API calls - 10 minutes per alert
Write up findings and post to Slack - 5 minutes per alert
Total: about 2.5 hours for 5 anomalies

Wednesday:

Pull Cost Optimization Hub, review new recommendations - 30 minutes
Create Jira tickets for engineering teams - 45 minutes

Friday:

Build weekly cost report for leadership - 1.5 hours

Weekly total for routine FinOps work: roughly 5-6 hours

After FinOps Agent (once automations are stable)

Monday morning:

Check Slack - 5 anomaly investigations already posted over the weekend with root causes identified
Review findings, confirm no false positives - 15 minutes

Wednesday:

Check Jira - optimization tickets already created for engineering teams
Review for accuracy - 10 minutes

Friday:

Weekly report already delivered to Slack on Thursday evening
Quick review for anything unusual - 5 minutes

Weekly total: roughly 30 minutes of review instead of 5-6 hours of manual work

That freed-up time goes to strategic work: Savings Plans analysis, architecture reviews for cost efficiency, building chargeback models, negotiating Enterprise Discount Programs.

Who Should Try This Today

If you are in one of these situations, set it up this week:

FinOps team of 1-3 people supporting many accounts. The automation alone justifies the setup time.
Engineering organization where developers do not have Cost Explorer access. Give them the agent instead.
Any team that produces recurring cost reports manually. Automate them immediately.
Organizations where cost anomaly alerts go uninvestigated. Event-triggered investigation fixes this.

If you are a solo developer with one account and minimal spend, this is probably more than you need right now. But if your monthly bill is complex enough that you spend time understanding it, it is worth trying.

A word of caution: This is a preview service. There is no SLA, features may change before GA, and you should not wire it into critical production workflows without a plan for what happens if the service changes or pricing is introduced. Use it to learn and validate, and be ready to adjust when GA arrives.

What Early Customers Are Reporting

Several companies shared their experience during the preview period. Here is what stood out to me:

Workday runs their AI platform across many AWS accounts. Their team was spending hours every month chasing cost outliers and building leadership reports. They said that anomaly detection and reporting now happens from one natural-language interface, replacing what used to be hours of manual dashboard work.

Convera, a global commercial payments company in a regulated environment, focused on catching small cost changes before they compound. They described the agent completing the full loop detecting anomalies, investigating root cause, and creating Jira tickets for the right engineer so issues reach the owner directly instead of sitting in a shared queue.

Mitre 10, a New Zealand retailer with a lean platform team, was splitting time between reliability work and cost governance. They now define investigation workflows once and have them run continuously, instead of relying on someone remembering to check.

AVIV Group operates digital marketplaces across France, Germany, and Belgium with hundreds of AWS accounts. As they shift to a hybrid FinOps model, the agent answers engineer questions directly, freeing the central team for strategy and leadership reporting.

What I Am Watching For at GA

A few things I want to see before this moves from "useful preview" to "enterprise standard":

Pricing at GA. It is free during preview. Enterprise adoption depends on what it costs relative to the time it saves.
IaC support. We need CloudFormation and Terraform support to deploy this in governed environments.
Inline Slack responses. The current link-based approach adds friction. Full findings posted inline would make the Slack integration much more natural.
Multi-language support. Global enterprises need this.
IAM Identity Center integration. For SSO-based access control in organizations that have moved away from IAM users.
Deeper Slack interaction. Currently delivery-only engineers cannot ask the agent questions from within Slack. That would complete the loop.
Multi-region Compute Optimizer queries by default. Should not require specifying regions manually.

Bottom Line

AWS FinOps Agent does not replace your FinOps team. It replaces the repetitive, manual investigation work that consumes most of their time. It takes the data that already exists across Cost Explorer, CloudTrail, Cost Optimization Hub, and Compute Optimizer, and makes it accessible through conversation instead of dashboards.

For architects, it means getting cost answers during design reviews without waiting for someone to run a report. For FinOps teams, it means spending time on strategy instead of triage. For engineering teams, it means getting cost context delivered to them in Jira and Slack instead of learning yet another AWS console.

It took me 5 minutes to set up, and within the first hour I had it answering questions, investigating anomalies, and scheduling weekly reports. For a preview service, that is a strong start.

The setup guide is at: https://docs.aws.amazon.com/finops-agent/latest/userguide/what-is.html

The console is at: https://us-east-1.console.aws.amazon.com/finops-agent/home

Try it while it is free. Worst case, you spend 10 minutes setting it up and decide it is not for you yet. Best case, you automate away hours of weekly grunt work and spend that time on work that actually needs a human brain.

Written after hands-on testing during the public preview period (June 2026). All features and behaviors described reflect the preview state and may change at general availability.

📌 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 🚀

Can AI Agents Browse Login-Protected Dashboards? I Tested It

Sarvar Nadaf — Tue, 09 Jun 2026 11:35:23 +0000

👋 Hey there, Tech Enthusiasts!

Let's get into it! 🚀

"Your agent can write Terraform, deploy infrastructure, and debug pipelines. But ask it to check a dashboard behind Cloudflare? It's useless."

If you read my previous article I Let an AI Agent Become My DevOps Engineer you know I've been pushing AI agents into real operational workflows. Code generation, CI/CD pipelines, infrastructure provisioning agents handle all of that now.

But there's one area where every agent I've used just... stops working. The browser.

Here's the reality: Most of the tools I monitor daily Grafana dashboards, AWS Console, CI pipelines, internal wikis live behind login walls, CAPTCHAs, and anti-bot protection. My agents can't touch them.

That's where BrowserAct comes in.

I found this tool that claims to give AI agents real browser control not headless puppeteer scripts that get blocked instantly, but actual anti-detection browsing with CAPTCHA handling and human handoff built in.

I spent a week testing it. Here's what I found.

By the end of this article, you'll:

Understand why AI agents fail at real browser tasks
Install BrowserAct and run your first extraction
See how anti-detection browsing actually works
Test human handoff for 2FA/login scenarios
Run parallel browser sessions without cross-contamination
Turn a repeated workflow into a reusable Skill

Time Required: 30 minutes (15 min read + 15 min hands-on)
Difficulty: Intermediate
Prerequisites: Python 3.12+, Node.js 18+, Google Chrome, terminal access

The Problem: Agents Can't Browse the Real Web

The Reality of AI Agent Automation in 2026

I manage infrastructure across multiple AWS accounts. Every morning I check:

CloudWatch dashboards
GitHub notifications and PR reviews
CI/CD pipeline status
Internal monitoring tools
Competitor product pages (for research)

That's easily 30-40 minutes of tab-switching, scrolling, and context-gathering before I even start real work.

I thought my agent can write Terraform and deploy entire VPCs. Surely it can open a webpage and read some data?

Nope.

Attempt 1: Basic web fetch

curl https://monitoring-dashboard.internal.com

403 Forbidden - Access Denied

Attempt 2: Headless Puppeteer

const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://dashboard.example.com');
// Blocked by Cloudflare challenge

Error: Page stuck on verification challenge

Attempt 3: Selenium
Same story. Detected as bot within 2 seconds.

Problems:

Anti-bot systems detect headless browsers instantly
CAPTCHAs stop automation cold
2FA/login flows need a human but there's no way to hand off
Running multiple accounts in one browser gets all of them flagged
Every script breaks when the site changes layout

My daily routine before BrowserAct:

Open 6 tabs manually
Log into GitHub, AWS Console, Grafana MFA for each
Scroll through notifications, check pipeline status
Copy-paste data into Slack for the team
Repeat next morning

40 minutes. Every. Day.

Sound familiar? I needed something built specifically for this a browser that agents can actually use on the real web.

What is BrowserAct?

Simple Version

BrowserAct is a CLI that gives your AI agent a real Chrome browser with anti-detection, CAPTCHA solving, and human handoff built in.

Think of it like this:

Puppeteer/Playwright = giving your agent a browser that screams "I'M A BOT"
BrowserAct = giving your agent a browser that looks and behaves like a real person

The Five Things It Actually Does

Gets past anti-bot walls: Real fingerprints, proxy rotation, stealth browsing. Sites don't know it's automated.
Handles CAPTCHAs automatically: Cloudflare, DataDome, reCAPTCHA. Solves what it can, escalates what it can't.
Hands off to humans when stuck: Hit a QR code login? SMS verification? It generates a URL. You (or a teammate) open it on your phone, do the human step, and the agent continues from where it stopped.
Runs parallel tasks without interference: Three sessions checking three different things under the same account. They don't step on each other.
Turns workflows into reusable Skills: Did something once? Package it. Run it again without the agent having to figure it out from scratch.

Prerequisites

Before starting, make sure you have:

Python 3.12+ (BrowserAct CLI is Python-based)
Node.js 18+ (for npx skills Skill installation)
uv package manager (or pip)
Google Chrome installed
Terminal/CLI access
An AI agent that can run shell commands (Claude Code, Cursor, Kiro, Codex or just run commands yourself)

Quick Check

python3 --version
# Python 3.12+

node --version
# v18+

google-chrome --version
# Google Chrome 149.x.x.x

If you don't have uv (fast Python package manager):

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

If you don't have Chrome:

# Ubuntu/Debian
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo apt install -y ./google-chrome-stable_current_amd64.deb

# Amazon Linux
wget https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm
sudo yum localinstall -y google-chrome-stable_current_x86_64.rpm

What We're Building

Here's what we're going to test today:

┌─────────────────────────────────────────────────┐
│                 AI Agent (You/Claude/Cursor)    │
└─────────────────────┬───────────────────────────┘
                      │ CLI commands
                      ▼
┌─────────────────────────────────────────────────┐
│              BrowserAct CLI                     │
│  ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│  │ Stealth  │ │ Sessions │ │  Human Handoff   │ │
│  │ Browser  │ │ Manager  │ │  (remote-assist) │ │
│  └──────────┘ └──────────┘ └──────────────────┘ │
└─────────────────────┬───────────────────────────┘
                      │ Real Chrome
                      ▼
┌─────────────────────────────────────────────────┐
│  Protected Websites (Cloudflare, Login Walls)   │
└─────────────────────────────────────────────────┘

Step 1: Install BrowserAct

Two parts here the Skill definition (for AI agents) and the actual CLI.

Install the Skill (for agent integration):

npx skills add browser-act/skills --skill browser-act --yes

Output:

◇  Installation complete

│  ✓ ~/.agents/skills/browser-act
│    universal: Amp, Antigravity, Antigravity CLI, Cline, Codex +12 more

Install the CLI itself:

uv tool install browser-act-cli --python 3.12

Output:

Resolved 90 packages in 437ms
Installed 90 packages in 2.09s
Installed 1 executable: browser-act

Verify it works (required on first install):

browser-act get-skills core --skill-version 2.0.2

This returns the environment state, available browsers, and command reference. Run this before anything else it completes the version handshake.

How to Get Your BrowserAct API Key

Go to BrowserAct and sign in to your account.
Click on your profile email address in the top-right corner.
From the dropdown menu, select API Keys.
Click Manage Keys.
Select Create Key.
Enter a name for your API key (for example, Amazon-Q, MCP-Server, or Development).
Click Create.
Copy the generated API key and store it securely. You may not be able to view the full key again after leaving the page.

Note: Treat your API key like a password. Do not share it publicly or commit it to source code repositories.

Set your API key

browser-act auth set <your-api-key>

API key saved.

Step 2: Your First Extraction (Zero Config)

The simplest thing BrowserAct can do extract content from a page without any setup:

browser-act stealth-extract https://httpbin.org/ip

Output from my test:

{
  "origin": "100.54.212.44"
}

Clean, rendered content. No HTML tags, no noise. Just the data.

Let's try something with actual content:

browser-act stealth-extract https://example.com

Output:

# Example Domain
This domain is for use in documentation examples without needing permission. Avoid use in operations.
[Learn more](https://iana.org/domains/example)

Already in markdown format. My agent can read this directly without any parsing.

What stealth-extract does under the hood:

Spins up a lightweight stealth browser
Visits the URL with anti-detection fingerprint
Renders JavaScript (unlike curl)
Returns content in markdown
Tears down the browser

Important note from testing: stealth-extract works great for quick reads on most sites. For heavily protected sites (like nowsecure.nl with aggressive Cloudflare), you'll need a full browser session (Step 3) it has stronger anti-detection because it maintains a persistent fingerprint and proxy.

Step 3: Full Browser Control

Now let's do something more interesting interactive browser automation. First, you need a stealth browser:

browser-act browser create --name "test-stealth" --type stealth --desc "Testing for article"

Output:

id=99703194156616493 name="test-stealth" type=stealth
  desc="Testing for article"

Now open a session:

browser-act --session my-research browser open 99703194156616493 https://github.com/trending

Output:

session_name=my-research
browser_type=stealth
url=https://github.com/trending
title=github.com/trending

See what's on the page (indexed elements):

browser-act --session my-research state

Real output from my test:

url=https://github.com/trending
title=Trending repositories on GitHub today · GitHub

|SCROLL|<html class=js-focus-visible /> (0.0 pages above, 1.2 pages below)

  [1]<a aria-label=Homepage />
  [3]<button type=button aria-expanded=false />
      Platform
  [4]<button type=button aria-expanded=false />
      Solutions
  [8]<a class=NavLink-module__link__EG3d4 />
      Pricing
  [9]<qbsearch-input class=search-input />
      [10]<div class=search-input-container search-with-dialog />
  [12]<a />
      Sign in
  [15]<a class=js-selected-navigation-item />
      Explore
  [17]<a class=js-selected-navigation-item selected />
      Trending

See those numbers? That's how the agent interacts. No DOM parsing, no CSS selectors. Just:

# Click the search input (element 10)
browser-act --session my-research click 10

clicked=10

The page updates search box opens. Now type:

browser-act --session my-research input 10 "browser automation AI"

input="browser automation AI" element=10

This is what they mean by "designed for agent reasoning." The output is compact, indexed, and token-efficient. My agent doesn't waste tokens parsing HTML.

You can also grab the full page as markdown:

browser-act --session my-research get markdown

Returns the entire page content in clean markdown format. Useful when you want to extract data rather than interact.

When you're done:

browser-act session close my-research

session_name=my-research closed=true

Step 4: Anti-Bot in Action

Here's where it gets real. I pointed BrowserAct at nowsecure.nl a site specifically designed to test anti-bot detection. It runs Cloudflare challenges.

# Full browser session on a Cloudflare-protected site
browser-act --session antibot browser open 99703194156616493 https://nowsecure.nl

Output:

session_name=antibot
browser_type=stealth
url=https://nowsecure.nl/
title=nowsecure.nl

It got through. Let me verify by pulling the content:

browser-act --session antibot get markdown

nowsecure.nl
NOWSECURE
---------
### by nodriver

And checking the network traffic shows exactly what happened Cloudflare's turnstile challenge was handled automatically:

browser-act --session antibot network requests

# format: csv
...
GET,200,Script,application/javascript,...,https://challenges.cloudflare.com/turnstile/v0/g/8fc8ed1d8752/api.js
GET,200,Document,text/html,...,https://challenges.cloudflare.com/cdn-cgi/challenge-platform/h/g/turnstile/...

The stealth browser handled the Cloudflare verification without any manual intervention. No CAPTCHA prompt, no block.

BrowserAct uses three layers to get through:

Environment layer - Stealth fingerprint, TLS config, proxy switching. Most blocks never trigger.
Execution layer - If a CAPTCHA appears, solve-captcha handles it automatically.
Human layer - If auto-solve fails, it can hand off to you (more on this next).

I'm not going to claim it works on every site. It doesn't. No tool does. But for the monitoring dashboards and research pages I tested, it got through where Puppeteer and Selenium couldn't.

Step 5: Human Handoff (This Is the Killer Feature)

This is the part that sold me. Here's the scenario:

Your agent is automating a workflow. It hits a login page that requires SMS verification or QR code scan. In Puppeteer world, the automation just dies. Game over.

BrowserAct does something different:

browser-act --session login-task remote-assist --objective "complete 2FA verification"

Real output from my test:

Remote assist session created.

Share this URL with the user:
  https://www.browseract.com/remote-cli/d83544c39e4a4e6ba1cc98f95050e615
expires in 1h 0m

Human assist is now active - the browser is under user control.
Do not send browser commands until the user finishes the assist session.

You open that URL on your phone or another device. You see the browser the actual live browser state. You complete the SMS verification, scan the QR code, whatever. Then you close it.

The agent gets notified and continues from the exact same browser state.

Why this matters for DevOps:

Internal tools with SSO that requires periodic re-auth
AWS Console with MFA
Third-party dashboards with 2FA
Any workflow where "fully automated" isn't realistic

The agent doesn't crash. It doesn't restart. It waits, you help, it continues. That's practical automation.

Step 6: Parallel Sessions (Multi-Task Without Conflicts)

Here's a real use case from my work: I want an agent to check three things simultaneously under the same account.

# Session 1: Check GitHub trending
browser-act --session check-trending browser open 99703194156616493 https://github.com/trending

session_name=check-trending
browser_type=stealth
url=https://github.com/trending
title=github.com/trending

# Session 2: Check GitHub topics (same browser, parallel session)
browser-act --session check-topics browser open 99703194156616493 https://github.com/topics

session_name=check-topics
browser_type=stealth
url=https://github.com/topics
title=github.com/topics

Two sessions. One browser. They don't interfere with each other.

# See all active sessions
browser-act session list

session_name: check-trending
browser_type: stealth
browser_id: 99703194156616493
title: Trending repositories on GitHub today · GitHub
url: https://github.com/trending

session_name: check-topics
browser_type: stealth
browser_id: 99703194156616493
title: Topics on GitHub · GitHub
url: https://github.com/topics

Each session has its own navigation state but shares the login cookies. So you log in once, and all tasks can work in parallel.

The three concurrency models:

Model	What's shared	Use case
Cross-browser parallel	Nothing (independent identity)	Multi-account monitoring
Same-browser multi-session	Login state	Parallel tasks, one account
Privacy mode	Nothing (fresh each time)	One-off scraping, anonymity

When done:

browser-act session close check-trending
browser-act session close check-topics

session_name=check-trending closed=true
session_name=check-topics closed=true

Sessions auto-reclaim after 8 hours if you forget. But clean up after yourself.

Step 7: Skill Forge Make It Reusable

Let's say Step 6 worked great. I want to run that "check my GitHub morning routine" every day without the agent figuring it out from scratch each time.

First, install Skill Forge:

npx skills add browser-act/skills --skill browser-act-skill-forge --yes

Output:

◇  Installation complete

│  ✓ ~/.agents/skills/browser-act-skill-forge
│    universal: Amp, Antigravity, Antigravity CLI, Cline, Codex +12 more

Then tell your agent:

"Forge a Skill that checks GitHub notifications, extracts unread count and top 5 notification titles."

Skill Forge will:

Explore the page structure
Discover the best extraction path
Generate a reusable Skill file
Test it

Next time, the agent just runs the Skill. No re-exploration, no token waste. Same stable path every time.

Where I'd use this:

Daily dashboard checks
Competitor price monitoring
Pull request summary generation
CI/CD status aggregation

Where I wouldn't:

Sites that change layout constantly
One-off tasks that'll never repeat
Anything that needs real-time interaction (chat, live support)

Bonus: How I'd Use This in Production

I ran a few extra tests to see how BrowserAct fits into a real cloud operations workflow. Here's what I found.

Monitoring AWS Health Dashboard

browser-act --session aws-health browser open 99703194156616493 https://status.aws.amazon.com

session_name=aws-health
browser_type=stealth
url=https://health.aws.amazon.com/health/status
title=health.aws.amazon.com/health/status

Then extract the status:

browser-act --session aws-health get markdown

AWS Health Dashboard
====================
Service health - Jun 09, 2026

Take a screenshot for your Slack channel:

browser-act --session aws-health screenshot /tmp/aws-health.png

saved: /tmp/aws-health.png

Real screenshot, 315KB, exactly what the dashboard looks like. Ship that to a Slack webhook and your team gets a visual status check every morning.

Checking GitHub Status (CI Monitoring)

browser-act --session aws-health navigate https://www.githubstatus.com
browser-act --session aws-health get markdown

All Systems Operational
-----------------------
Git Operations   99.85% uptime  Normal
Webhooks         99.96% uptime  Normal
API Requests     99.99% uptime  Normal
Issues           99.97% uptime  Normal
Pull Requests    99.61% uptime  Normal

Now my agent has real uptime data it can act on. If Pull Requests drops below 99%, alert me.

Browsing Cloudflare's Own Product Page (Their Anti-Bot)

The ultimate test can BrowserAct get through Cloudflare's own website?

browser-act --session aws-health navigate https://www.cloudflare.com/products/
browser-act --session aws-health get markdown

Cloudflare Products
-------------------
Everything you need to build, deploy, and scale applications...
Workers Global serverless functions
D1 - Serverless SQL database
R2 - Object storage...

Yes. It extracted their full product catalog through their own protection. That's something.

JavaScript Evaluation (Custom Data Extraction)

Need something specific that the markdown extraction doesn't give you? Run JavaScript directly:

browser-act --session aws-health eval "document.title"

Products | Cloudflare

browser-act --session aws-health eval "document.querySelectorAll('a').length"

This lets you write precise extraction logic without relying on the markdown parser.

My Production Architecture (What I'd Actually Build)

Here's the setup I'm planning for my AWS monitoring workflow:

┌────────────────────────────────────────────────────────────────┐
│                    Cron Job (Every Morning 8 AM)                │
└──────────────────────────┬─────────────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────────────┐
│                   AI Agent (Kiro / Claude Code)                 │
│                                                                │
│  1. browser-act --session grafana browser open <id> <url>      │
│  2. browser-act --session grafana get markdown                 │
│  3. browser-act --session grafana screenshot ./grafana.png     │
│  4. browser-act --session cloudwatch browser open <id> <url>   │
│  5. browser-act --session cloudwatch get markdown              │
│  6. Parse data → Generate summary                             │
│  7. Post to Slack with screenshots                            │
│  8. Close all sessions                                         │
└──────────────────────────┬─────────────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────────────┐
│                 Slack Channel: #morning-status                  │
│                                                                │
│  Morning Infra Report - Jun 04, 2026                           │
│  All AWS services operational                                  │
│  GitHub: 99.85% uptime                                         │
│  Grafana: CPU alert on prod-api-3                              │
│  [dashboard-screenshot.png]                                    │
└────────────────────────────────────────────────────────────────┘

Why this works better than API-only monitoring:

Some dashboards don't expose APIs (internal Grafana, vendor portals)
Screenshots give visual context that JSON data can't
Human handoff means SSO re-auth doesn't break the whole pipeline
One browser session stays logged in no re-auth every day

Production considerations:

Run on a dedicated EC2 instance (t3.medium is enough tested)
Use static proxy for stable identity (avoids triggering "new device" alerts)
Set --desc on browsers with site/account info so future sessions know what's what
Monitor credit usage each session costs credits, budget accordingly
Store screenshots in S3, link in Slack messages
If login expires, remote-assist lets you re-auth from your phone without SSH-ing in

Before vs After: How This Changed My Morning

Let me be real about what my daily routine looked like before and after testing BrowserAct.

Before BrowserAct (My Old Morning)

8:00 AM - Open laptop
8:02 AM - Open GitHub, hit MFA prompt on phone, wait
8:04 AM - Check notifications (12 unread), scan PRs (3 need review)
8:08 AM - Open AWS Console, MFA again, navigate to CloudWatch
8:12 AM - Check 3 dashboards across 2 accounts, screenshot for team
8:18 AM - Open Grafana, login, scroll through panels looking for alerts
8:23 AM - Check GitHub Actions 2 repos have failing builds
8:27 AM - Open competitor's changelog page (Cloudflare protected)
8:30 AM - Copy-paste a summary into Slack for the team
8:35 AM - Realize I missed one account, go back to AWS...
8:40 AM - Actually start working

40 minutes of monkey work. Every morning. On good days.

On bad days a session expires mid-check, or MFA doesn't arrive, or Cloudflare blocks my automation script. Then it's 50+ minutes.

After BrowserAct (What I'm Building Now)

8:00 AM - Agent runs automatically (cron trigger)

Agent:
  → Opens stealth session on GitHub
  → Extracts: 12 notifications, 3 PRs pending review
  → Navigates to GitHub Actions: 2 failing builds (api-server, docs-deploy)
  → Opens parallel session: AWS Health Dashboard
  → Extracts: "All Systems Operational"
  → Screenshots CloudWatch dashboard → saves to S3
  → Navigates to competitor changelog: extracts new features list
  → Posts summary to Slack #morning-status

8:01 AM - Slack notification pops up with the full morning report.

8:02 AM - I read the summary with my coffee. Actually start working.

Time saved: ~38 minutes/day. That's 3+ hours/week.

And the thing is it's not just the time. It's the mental context switching. Opening six different login-protected dashboards pulls you out of focus. Having a one-page summary waiting in Slack means I start my day knowing exactly what needs attention.

The Honest Part

It's not fully there yet. Here's my current reality:

What works today: The extraction, screenshots, and parallel sessions all work as shown in this article. I tested every command above on a real EC2 instance.
What I'm still setting up: The cron automation + Slack integration pipeline. That's a week of wiring. I'll write a follow-up when it's running.
The one catch: First login to each site needs me to remote-assist from my phone (handle MFA manually). After that, the session stays authenticated for days. So it's "almost" fully automated I handle MFA once a week, the agent handles the other 4 days.

Where I Wouldn't Use This

Being honest not everything needs browser automation:

AWS resource monitoring - Use CloudWatch alarms + SNS. APIs exist. Don't browser-scrape what you can API-call.
Simple uptime checks - Use UptimeRobot or similar. Don't overkill it.
Data that changes every second - BrowserAct isn't real-time. It's periodic checks.
Banking or highly sensitive portals - Too risky. Keep that manual.

Where It Shines

Dashboards without APIs - Grafana (free tier), internal tools, vendor portals
Multi-account visual checks - AWS Console across 3 accounts, screenshot each
Competitor monitoring - Product pages behind Cloudflare, pricing pages that block scrapers
CI/CD status aggregation - Pull data from GitHub Actions, CircleCI, Jenkins (web UI) into one summary
Any "check and report" workflow that you do manually more than twice a week

What Worked and What Didn't

Worked Well

Stealth browser sessions - get through Cloudflare where Puppeteer/Selenium can't. Tested on nowsecure.nl and cloudflare.com itself both passed.
Real dashboard extraction - pulled structured data from AWS Health Dashboard, GitHub Status, and Cloudflare product pages. Real production use cases, all worked.
Screenshots - screenshot command saves PNGs directly. 315KB for a full-page capture. Great for visual monitoring and Slack reports.
Indexed interaction - the state/click/input model is clean. Way better than parsing DOM. Real element indices, real clicks.
Human handoff - generates a live URL instantly. This solves a real problem I've had for years.
Session isolation - ran two parallel sessions on the same browser, completely independent. No conflicts.
Navigation within sessions - navigate command lets you move across sites within one session. Open AWS Health, then navigate to GitHub Status, same session.
JavaScript eval - eval lets you run custom extraction when markdown isn't precise enough.
Network capture - network requests shows exactly what's happening under the hood. Great for debugging.
Install was clean - uv tool install pulled 90 packages, had it running in under a minute on a t3.medium.

Mixed

stealth-extract vs full sessions - stealth-extract works for quick reads on normal sites, but for heavily protected sites you need a full stealth browser session. Not obvious from the docs.
CAPTCHA solving - solve-captcha returned "no compatible captcha found" when I tested (page had already loaded past it). Couldn't trigger a scenario where it was needed during my testing.
Speed - stealth browsing is slower than raw Puppeteer. Takes a few seconds to open sessions. Makes sense (it's doing more work) but worth noting.

Could Be Better

Documentation - the get-skills command dumps a massive guide. Useful but overwhelming on first read.
Error messages - "Browser launch failed: Connection closed" doesn't tell you much. Took trial and error to figure out I needed a full session for protected sites.
Requires API key for stealth - can't use the anti-detection features without signing up first. Fair, but the free tier is limited.

Pricing & Credits

BrowserAct runs on a credit system:

Free credits: 100 credits on signup.
Paid plans: Check browseract.com/pricing for current rates

For testing and writing this article, the free credits were enough. For production monitoring workflows running daily, you'd need a paid plan.

Troubleshooting

Issue 1: "browser-act: command not found"

bash: browser-act: command not found

Fix: Install via uv (not npm):

curl -LsSf https://astral.sh/uv/install.sh | sh
uv tool install browser-act-cli --python 3.12

The binary installs to ~/.local/bin/ make sure it's in your PATH.

Issue 2: "Browser launch failed: Connection closed"

Error: Browser launch failed: Browser.close: Connection closed while reading from the driver

Fix: This happens when stealth-extract can't handle a heavily protected site. Use a full browser session instead:

browser-act browser create --name "my-stealth" --type stealth --desc "browsing"
browser-act --session task1 browser open <browser-id> <url>

Issue 3: "api_key: not configured"

CLI:
  api_key: not configured

Fix: You need an API key for stealth browser features:

browser-act auth set <your-api-key>

Get one at browseract.com.

Issue 4: Chrome not found

Error: Chrome executable not found

Fix: Install Chrome:

# Ubuntu
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo apt install -y ./google-chrome-stable_current_amd64.deb

# Amazon Linux
wget https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm
sudo yum localinstall -y google-chrome-stable_current_x86_64.rpm

Issue 5: Session already exists

Error: Session name 'my-task' already in use

Fix: Close it first:

browser-act session close my-task

Real-World Use Cases

As a cloud architect, here's where I see this fitting:

1. Infrastructure Monitoring

Check multiple dashboards (Grafana, CloudWatch, Datadog) through a single agent
Generate daily summaries from web-based monitoring tools
Alert on visual changes in dashboards that don't have API access

2. DevOps Workflows

Automate PR review summaries across repos
Check CI/CD status across multiple platforms
Monitor deployment pipelines with login-protected UIs

3. Multi-Account Operations

Manage multiple AWS accounts through Console (when CLI isn't enough)
Monitor multiple SaaS dashboards
Cross-account compliance checks on web portals

4. Research & Data Collection

Track competitor features and pricing pages
Aggregate release notes from multiple vendor sites
Collect public data from protected listing pages

Key Concepts Learned

1. Sessions = Task Workspaces

browser-act --session <name> <command>

Every task gets its own session. Sessions don't interfere. Name them descriptively.

2. Browsers = Identities

Different browsers = different fingerprints, proxies, cookies. Use separate browsers for separate accounts. Three types:

chrome - imports your local Chrome login state
chrome-direct - controls your running Chrome directly
stealth - anti-detection browser with fingerprint masking (needs API key)

3. Skills = Reusable Workflows

Once something works, package it as a Skill. Next time it runs without re-exploration.

4. Three-Layer Anti-Blocking

Environment (fingerprint) → Execution (auto-solve) → Human (handoff). Progressive escalation.

5. Two Extraction Modes

stealth-extract - quick, zero-config, good for simple reads. Lightweight.
Full browser session - persistent, stronger anti-detection, needed for heavily protected sites.

What's Next?

I'm building the full pipeline I described above. Here's my roadmap:

Week 1 (done): Test BrowserAct on real sites this article
Week 2: Wire up the morning monitoring agent (cron + BrowserAct + Slack webhook)
Week 3: Add Skill Forge package the workflow so it's stable across page layout changes
Week 4: Run for 30 days, track: time saved, credits consumed, failures, manual interventions

If there's interest, I'll write a follow-up with:

Actual production usage data (cost per month, reliability %)
The Skill file I built for GitHub monitoring
How many times remote-assist saved me from a broken pipeline
Token usage comparison vs doing the same thing with raw Playwright

The goal is simple: I want my mornings back. 40 minutes of tab-switching replaced by a 2-minute Slack read. BrowserAct is the missing piece between "my agent can code" and "my agent can actually see what's happening in production."

Resources

BrowserAct:

My Previous Article:

I Let an AI Agent Become My DevOps Engineer

Summary

Here's what I found after testing BrowserAct on an EC2 instance (Amazon Linux, t3.medium):

Stealth browser sessions get through Cloudflare tested on nowsecure.nl and cloudflare.com itself
Extracted real data from AWS Health Dashboard, GitHub Status actual production monitoring working
Screenshots save as PNG ready to pipe to Slack/S3 for visual dashboards
Human handoff generates a live remote URL in seconds actually works
Parallel sessions run independently on the same browser no conflicts
Navigation + eval let you build complex multi-step extraction workflows
Indexed interaction (state, click, input) is agent-friendly and token-efficient
Skill Forge makes repeated workflows reusable
stealth-extract has limits use full sessions for protected sites
Needs API key for anti-detection features
Error messages could be clearer when things fail

Bottom line: If you're running AI agents and they need to interact with real websites not just APIs this is worth testing. I'm already planning a daily monitoring pipeline with it. It's not magic. It won't bypass everything. But it solves real problems that I haven't seen other tools handle this cleanly.

Connect & Share

If this was useful:

Star the BrowserAct GitHub repo
Drop a comment what workflows would you automate?
Share with your team
Follow me for the follow-up article

📌 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 🚀

I Built an AI Agent That Tailors My Resume - Here's How Agents Actually Work

Sarvar Nadaf — Mon, 25 May 2026 13:32:31 +0000

👋 Hey there, tech enthusiasts!

Let's get into it! 🚀

This article is for beginners who've heard about AI agents but haven't built one yet.

The Problem That Started It All

You're looking for a job. You open LinkedIn, Naukri, Indeed search "Senior Python Developer." Hundreds of results pop up. Every company wants something slightly different. One wants AWS + Django. Another wants FastAPI + Kubernetes. The third one wants Flask + microservices.

You have all these skills. That's not the problem.

The problem is time. To stand out, you need to customize your resume for each role. Read the job description carefully. Figure out what they care about. Rewrite your summary. Reorder skills. Tweak bullet points. Write a cover letter. Hit submit.

That's ONE application. Now do that 10 more times.

It's not a skill problem. It's a time problem. You're doing the same thing over and over read, match, rewrite, submit.

What if you could build something that handles all of this for you?

You give it your resume and say "Find Senior Python roles in Bangalore, 20-35 LPA (Lakhs Per Annum ₹20-35 lakh salary), remote-friendly" and it goes to work. It reads job descriptions, matches your skills, finds gaps, rewrites your resume for each role, writes cover letters, and ranks everything by how well you fit.

Same you. Same resume. Same job market. But the boring repetitive part? Done automatically.

That's what got me into agentic AI. Not the hype. The simple thought: "I can automate this annoying thing."

ChatGPT vs AI Agents What's the Difference?

People ask me this all the time. "Isn't ChatGPT already an agent?"

Not really. Here's the simple difference.

ChatGPT - you ask a question, you get text back. Yes, it can browse the web and run code now. But YOU are still driving. You ask, it responds. You ask again, it responds again. It waits for you at every step.

An AI Agent - you give it a goal and it goes and does the work. Multiple steps. Multiple tools. Without you guiding each step. It decides what to do next on its own.

Here's a simple comparison:

You ask: "Find me Senior Python jobs in Bangalore"
ChatGPT	"Here are some tips: update your LinkedIn, use relevant keywords..." (gives advice, waits for your next question)
AI Agent	Actually searches job boards, finds 47 matches, filters to 12 relevant ones, tailors your resume for each (does the work start to finish)

One waits for you. The other goes and does the work. That's the whole difference.

How Agents Think?

Every agent follows the same basic pattern:

Think → Do → Check → Repeat

Here's what that looks like:

┌─────────┐     ┌─────────┐     ┌─────────┐
│  THINK  │───▶│   DO    │────▶│  CHECK  │
│ What's  │     │ Take    │     │ Did it  │
│ next?   │     │ action  │     │ work?   │
└─────────┘     └─────────┘     └─────┬───┘
     ▲                                │
     │          Not done yet          │
     └────────────────────────────────┘
              ✅ Done? → Stop

That's it. The agent looks at the goal, figures out the next step, does it, checks if it worked, and keeps going until the job is done.

(You might hear people call this "ReAct" which stands for Reason + Act. It's a formal way of saying the agent thinks about what to do, then does it, then thinks again. But at its core, it's just the loop above.)

Let me show you how this works with the resume example:

Goal: "Tailor this resume for an Amazon SDE role."

Agent reads the job description. Amazon wants Python, AWS, and distributed systems.
Agent reads your resume. Python and AWS are there. But distributed systems? It's buried in one bullet point that nobody would notice.
Agent rewrites that bullet point to make distributed systems stand out.
Agent checks again are all the important keywords from the job description covered? Not yet. Kafka is missing.
Agent looks at your experience. You actually used Kafka at your last job but never put it on the resume. (We all do this.)
Agent adds Kafka to the relevant section.
Final check. Everything important is covered. Done.

Seven steps. No human needed. The agent figured out what was missing, fixed it, checked its work, and moved on.

This is how every agent works whether it's tailoring resumes, monitoring servers, or analyzing data. Same loop, different tasks. (Okay, I'm oversimplifying a bit real agents sometimes have more complex decision trees. But this mental model will get you through 90% of what you'll build.)

The Autonomy Spectrum How Much Freedom Should an Agent Have?

Before we look at how to build an agent, let's understand how much freedom you can give one. "Agent" isn't all-or-nothing. It's a range.

Level	What Happens	Example	Risk
Fully Manual	Human does everything	You tailor your resume by hand	None
Assisted	AI suggests, human does	ChatGPT suggests bullet points, you copy-paste	Low
Orchestrated	Human defines steps, agent follows them	You say "Step 1: read JD, Step 2: rewrite summary" agent does exactly that	Low-Medium
Semi-Autonomous	Agent decides steps, pauses for approval	Agent figures out what to do, asks before submitting	Medium
Fully Autonomous	Agent does everything, no human involved	Agent searches, tailors, submits you just get a report	High

Most real-world agents today are in the middle some human control, some agent freedom.

My advice: Start with orchestrated you define the workflow, the agent executes it. Once you trust it, give it more freedom gradually. Add human checkpoints for important steps. Fully autonomous? Maybe someday. Not yet for anything that matters.

The resume tailor agent we're building in this series? Semi-autonomous. It figures out what to fix and does the work, but shows you the result before anything gets submitted.

The Building Blocks of Every Agent

Now that you know how much freedom an agent can have, let's look at what you actually configure to make one work. Most frameworks I've used have these same pieces. Let's group them by what they do.

The Core: Who does what?

LLM (The Brain) - The AI model that does the thinking. GPT-4, Claude, Amazon Nova, Llama. Don't always use the most expensive model. Use cheap models for easy tasks, powerful models for hard tasks.

Role (The Identity) - Tell the agent WHO it is. Example: "You are a Senior Tech Recruiter with 15 years of experience." The more specific the role, the better the output. Vague roles give vague results.

Goal (The Finish Line) - When should the agent stop?

❌ Bad: "Help with job search"
✅ Good: "Find 5 Senior Python roles in Bangalore, 20-35 LPA, remote-friendly, from companies older than 3 years"

Task (The Instruction) - The specific work to do right now. "Read this job description. Compare it against the resume. List the top 5 skill gaps." Be as specific as possible the more you leave unclear, the more the agent makes up.

The Context: What does the agent know?

Backstory (The Personality) - Shapes HOW the agent approaches work. Same task, different backstory, different style:

"Seasoned recruiter" → practical, beats resume-scanning software
"Career coach" → encouraging, focused on growth
"Brutally honest reviewer" → tears your resume apart (but you learn the most)

Knowledge Base (The Facts) - Information you hand the agent upfront. "The candidate is a Senior Python Developer. Based in Bangalore. Prefers remote. Salary: 20-35 LPA." Without this, the agent guesses. And it guesses wrong.

Memory (What It Remembers) - Two types:

Short-term: Remembers what happened earlier in the current task. "I already found Python listed in the resume."
Long-term: Remembers across sessions. Run it next week, it knows what worked last time.

The Safety Net: What keeps it under control?

Tools (The Hands) - What the agent can actually DO beyond generating text: search the web, read files, call APIs, run code. Without tools, it just writes. With tools, it takes action. Not every agent needs tools a resume rewriter just processes text, but a job searcher needs API access.

Guardrails (The Limits) - Rules that keep the agent in check:

Max attempts → stop after X tries (otherwise it loops forever and burns your budget)
Allowed actions → limit which tools it can use
Output checks → verify the result makes sense

I always set guardrails. Always. I learned this at 2 AM watching my bill climb because an agent got stuck in a loop.

Human-in-the-Loop (The Pause Button) - For important decisions, make the agent stop and ask. The agent tailored your resume and is about to submit it. Instead of auto-submitting, it shows you the final version. "Should I submit this?" You review, approve, it continues.

Automate the boring parts. Keep human judgment for the important decisions.

Quick Reference

Group	Pieces	One-line summary
The Core	LLM, Role, Goal, Task	Who is this agent and what's it doing?
The Context	Backstory, Knowledge Base, Memory	What does it know?
The Safety Net	Tools, Guardrails, Human-in-the-Loop	What can it do and what stops it?

Ten pieces, three groups. Now let's see how multiple agents work together.

Multiple Agents Working Together

One agent is useful. But what if the job is too big for one?

You split the work. Just like a real team each person handles what they're best at.

Think of it like a restaurant:

One chef doesn't do everything. There's someone who preps ingredients, someone who cooks, and someone who plates the dish.
Each person does one thing well. Together, they serve a full meal.

Agents work the same way.

Our resume example with 3 agents:

Agent	Job	Output
Job Analyzer	Reads the job description, pulls out what matters most	"They want Python, AWS, and distributed systems experience"
Resume Writer	Takes that analysis and rewrites the resume to match	A tailored resume highlighting the right skills
Cover Letter Writer	Uses both outputs to write a personalized letter	A cover letter that connects your experience to their needs

Each agent does one thing. Together, they handle the full workflow.

How Do They Pass Work to Each Other?

Three patterns. You only need to know the first one for now.

1. Sequential - Like a relay race A→B→C

Agent 1 finishes → hands output to Agent 2 → hands to Agent 3.

This is what we'll use. It's the simplest. Easy to understand, easy to fix when something breaks you know exactly which agent caused the problem.

2. Hierarchical - Like a manager assigning tasks

One "boss" agent gives work to others and collects results. Useful when you need coordination, but more complex to set up.

3. Parallel - Everyone works at the same time

Multiple agents work on independent tasks simultaneously. Faster, but the tasks can't depend on each other. Example: three agents searching three different job boards at the same time.

For this series, we're using sequential. Agent 1 passes to Agent 2 passes to Agent 3. Simple, predictable, easy to debug. You can explore the other patterns later once you're comfortable.

Here's how our 3 agents work together:

┌──────────────┐       ┌───────────────┐       ┌─────────────────────┐
│ Job Analyzer │──────▶│ Resume Writer │──────▶│ Cover Letter Writer │
│              │       │               │       │                     │
│ "They want   │       │ Rewrites your │       │ Writes a letter     │
│  Python, AWS,│       │ resume to     │       │ connecting your     │
│  distributed │       │ highlight     │       │ experience to       │
│  systems"    │       │ those skills  │       │ their needs         │
└──────────────┘       └───────────────┘       └─────────────────────┘

CrewAI - The Framework We'll Use

I tried several agent frameworks. I picked CrewAI because it's simple and respects your time.

Why CrewAI?

Free and open source - active community, regular updates
Ready-made templates - gives you a working project structure immediately
Plain English configuration - define agents and tasks in YAML (simple text files), not complex code
Fast to start - first working agent in about 10 minutes once your environment is set up

Project Structure

When you create a CrewAI project, you get this folder structure:

my-agent-project/
├── src/
│   └── my_agent_project/
│       ├── config/
│       │   ├── agents.yaml      ← WHO: define your agents here
│       │   └── tasks.yaml       ← WHAT: define tasks here
│       ├── tools/
│       │   └── custom_tool.py   ← HOW: custom tools agents can use
│       ├── crew.py              ← WIRING: connects agents to tasks
│       └── main.py              ← START: entry point, kicks everything off
├── knowledge/                   ← FACTS: static files agents can read
├── .env                         ← SECRETS: API keys, model settings
└── pyproject.toml               ← DEPENDENCIES: Python packages needed

You only need to write three things: agent definitions, task definitions, and the wiring between them. Everything else is scaffolding that CrewAI handles.

CrewAI vs LangChain - When to Use Which

	CrewAI	LangChain/LangGraph
Approach	Define agents in simple YAML files	Build custom chains and graphs in code
Learning time	A weekend	A week or more
Setup time	~10 minutes	30+ minutes of boilerplate
Best for	Clear roles, clear handoffs	Complex branching, conditional logic
Feels like	Writing job descriptions for a team	Building a flowchart with many "if/else" paths

Use CrewAI when you know your agents and the flow is straightforward. Agent A does X, passes to Agent B which does Y. Done.

Use LangChain/LangGraph when you need complex logic like "if confidence is above 80% go to Agent A, otherwise retry with Agent B, and if that fails ask a human."

My take: Start with CrewAI. You can always add complexity later. Removing complexity? That's painful.

MCP - How Agents Talk to the Outside World

Your agent can think. But can it actually reach out and grab information from somewhere else? Like a database full of job listings? Or a file stored in the cloud?

That's what MCP does. It gives your agent a way to connect to outside services.

The Simplest Way to Understand MCP

Imagine you buy a new phone. You need to charge it. Now imagine every phone brand had a completely different charger one for Samsung, one for Apple, one for OnePlus, all different shapes.

That's what life was like before USB-C. Now? One cable works for almost everything.

MCP is the USB-C of AI agents. One standard way to connect to any service databases, file storage, APIs, messaging apps. You don't write different connection code for each one.

Back to Our Resume Agent

Our agent needs job listings. Where do those come from?

Maybe a database with thousands of job posts
Maybe files stored in the cloud (like AWS S3)
Maybe a job board API

Without MCP: You write separate connection code for each one. Different code for the database. Different code for S3. Different code for the API. Every new service = more custom code.

With MCP: You configure the connection once in a simple settings file. The agent uses the same standard method to talk to all of them. New service? Just add another configuration. No new code.

The first time I set this up, it took me about 5 minutes. Writing custom database connection code used to take me an hour. That's the difference.

What Else Can Agents Connect To?

Databases - fetch job listings, store results
File Storage (S3) - read resumes, save tailored versions
GitHub - read code, create pull requests
Slack - send notifications, read messages
Web Search - find information online

One standard way to connect to all of these. That's MCP.

We'll set this up hands-on in the next article. For now, just remember: MCP is how your agent reaches out to the world beyond its own code.

What Agents Can't Do Well (Yet)

Let me be honest about the limitations:

They make things up. I've had an agent tell me it "successfully completed" something it definitely didn't do. Always check important outputs yourself.
They cost money. One task = 5-20 AI model calls. A chatbot costs pennies. An agent can cost dollars per run. Multiply by hundreds of runs and your bill gets serious.
They get stuck in loops. Without a maximum attempt limit, an agent will happily retry the same failing approach forever. (I learned this the hard way at 2 AM.)
Same input, slightly different output. This makes testing tricky because you can't always predict the exact result.
They're slow. Multiple AI calls + tool usage = seconds to minutes per task. Not milliseconds.
They "fix" things you didn't ask about. When fixing one issue, an agent sometimes decides to also change nearby code. In a demo, fine. In production, you get unexpected changes. Set tight boundaries.

How I Handle These Problems

Use cheap models for simple tasks. Amazon Nova Lite for easy stuff, Nova Pro for complex reasoning.
Keep prompts short. Every word costs money.
Always set max attempts. Non-negotiable.
Log everything. I send all agent activity to CloudWatch Logs token counts, step durations, success/failure at each step. When something breaks at step 5 of 7, I can trace exactly what went wrong.
Validate outputs. For critical tasks, I add a checking step either another agent that verifies the work, or structured checks that confirm the output meets requirements.

When NOT to Use Agents

Not everything needs an agent. I've seen people over-engineer simple problems because "agents are cool." Skip agents when:

One AI call is enough - Summarize this text? Translate this paragraph? That's one API call, not an agent.
The logic never changes - If there are no decisions to make and the steps are always the same, a simple script is cheaper, faster, and more reliable.
You need instant responses - Agents take seconds to minutes. If you need millisecond responses for a real-time API, agents are too slow.
High volume + simple task - 5-20 AI calls per task × 10,000 tasks per day = a very expensive month. If the task is simple and repetitive, write a rule-based system.
Mistakes are unacceptable - Agents make errors. If a wrong answer has serious consequences (medical, legal, financial), don't rely on an agent without heavy human oversight.
It's just a database query - Reading from a database and returning results? That's a simple API, not an agent.

My rule: If you can draw the logic as a simple flowchart with no "it depends" decisions, you don't need an agent. Use a script. Agents are valuable when there's ambiguity, judgment calls, and multi-step reasoning involved.

What's Next

In the next article, I'm building the resume tailor agent step by step using CrewAI on an EC2 instance with Amazon Nova Pro as the AI model. From setting up the server to running the agent against a real job description.

Stay tuned.

📌 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 🚀

I Installed Kiro CLI on EC2: Here's Why My First Attempt Failed

Sarvar Nadaf — Fri, 15 May 2026 04:37:18 +0000

👋 Hey there, tech enthusiasts!

Let's dive in and explore the fascinating world of cloud technology together! 🚀

I've been using Amazon Q CLI for nearly two years. It became part of my daily workfloquick infrastructure lookups, generating boilerplate, debugging at odd hours. It was reliable, familiar, and I never thought about replacing it.

Then the end-of-support announcement dropped.

At first, I felt that familiar frustration. Another tool sunset. Another migration. But then I paused. Instead of scrambling for a 1:1 replacement, I asked myself: what do I actually need from a terminal AI in 2026?

My answer wasn't "the same thing I had." It was more. I wanted something that understood my team's standards without me repeating them. Something that could pull real AWS data not just guess at it. Something I could shape into different personas for different tasks.

That's when I discovered that Kiro which I'd only known as an IDE also ships a CLI. And it's not just a CLI. It's the tool I didn't know I was waiting for.

Why This Isn't Just Another Migration

Let me be clear: I'm not switching because I have to. I'm switching because Kiro CLI solves problems Q CLI never addressed.

Here's what changed my mind in the first 30 minutes:

🧠 Custom Agents

Define specialized personas with restricted tool access, scoped file permissions, and custom prompts. I now have a DevOps agent that can only touch infrastructure files, and a reviewer agent that's physically incapable of modifying anything. Different tools for different jobs from the same CLI.

📏 Steering Files

Persistent rules that shape every response. My team's infrastructure standards Graviton instances, GP3 volumes, mandatory tags, Lambda best practices are baked into every interaction automatically. No more repeating "use ARM64" in every prompt.

🔌 MCP Server Ecosystem

Connect to AWS Cost Explorer, Pricing API, CloudTrail, Well-Architected tools, and more. This isn't "AI guessing at your costs." This is real data flowing into real recommendations. Within my first week, it found a forgotten NAT Gateway costing $180/month.

📋 Planning Mode

Press Shift+Tab and Kiro switches from "do the thing" to "let's think about the thing first." Structured requirements gathering before implementation. Essential for anything touching multiple services.

📊 Real-Time Usage Tracking

/usage shows exactly where you stand credits consumed, tier limits, what's left. No end-of-month surprises.

🔐 Multiple Auth Options

Builder ID, IAM Identity Center, GitHub, Google. Teams get centralized billing and access control. Solo developers get flexibility.

Amazon Q CLI was a good conversational assistant. Kiro CLI is an extensible development platform that happens to live in your terminal.

That distinction is why I'm writing this guide instead of a "how to cope with deprecation" post.

A Quick Comparison

For those coming from Q CLI, here's what's different at a glance:

	Amazon Q CLI	Kiro CLI
Auth options	Builder ID, IAM Identity Center	+ GitHub, Google
Entry point	`q chat`	`kiro-cli chat` (`q` still works)
Model selection	Manual	Auto-selects per task
Cost visibility	End of month surprise	`/usage` command, real-time
Custom agents	Basic	Full tool/path scoping, hooks
Steering/Rules	Simple rules	Rich markdown standards files
MCP ecosystem	Limited	20+ official AWS MCP servers
Planning mode	❌	✅ Structured requirements first
License	Apache 2.0	AWS IP License

The license change matters if your org has strict open-source requirements. For most of us, it doesn't affect day-to-day use.

Infrastructure Requirements

Before installing, make sure your machine meets these specs:

Requirement	Minimum	Recommended
Architecture	x86_64 or ARM64	Either works fine
OS	Ubuntu, Fedora, or Amazon Linux 2023	Ubuntu 22.04 LTS
glibc	2.34+	2.35+ (ships with Ubuntu 22.04)
RAM	2 GB	4 GB
CPU	2 vCPUs	2 vCPUs is fine
Disk	5 GB free	10 GB+
Network	Internet access	Stable connection

If your glibc is older than 2.34 (check with ldd --version), grab the musl version instead it's the one with -musl.zip in the filename.

My Setup

I'm running this on an EC2 instance:


Instance Type	t3.medium
OS	Ubuntu 22.04.5 LTS
Architecture	x86_64
vCPUs	2
RAM	4 GB
Storage	50 GB GP3
Region	us-east-1

I went with t3.medium (4 GB RAM) to keep things comfortable. AI model interactions benefit from headroom, and the cost difference is negligible for a development tool you use daily.

Installation (Under 5 Minutes)

The whole process is straightforward. Nine steps, no surprises.

Step 1: Download Kiro CLI

SSH into your instance and pull the package:

curl --proto '=https' --tlsv1.2 -sSf 'https://desktop-release.q.us-east-1.amazonaws.com/latest/kirocli-x86_64-linux.zip' -o 'kirocli.zip'

Takes about 10 seconds on a decent connection. The file is around 350 MB.

Step 2: Extract It

unzip kirocli.zip

Step 3: Run the Installer

./kirocli/install.sh

Step 4: Let It Configure Your Shell

It'll ask:

Do you want kiro-cli to modify your shell config (you will have to manually do this otherwise)?

Type yes. This adds the necessary PATH entries so you can run kiro-cli from anywhere.

Step 5: Authenticate

Now it needs to know who you are. I'm using Builder ID it's free, quick to set up, and works well for individual use. You can also use IAM Identity Center for teams, or GitHub/Google if you prefer.

Step 6: Open the Auth URL

Kiro generates a URL for you. Copy it and open it in your browser.

Step 7: Confirm Access

Click Confirm and Continue:

Then click Allow when it asks for data access:

The browser tab closes automatically. You're done with the web part.

Step 8: Back to the Terminal

You should see a success message:

Step 9: Verify It Works

kiro-cli

If you see the Kiro interface, you're in:

That's it. Under five minutes from download to working CLI.

Automatic Migration from Q CLI

This is the part that made me smile. When Kiro CLI installed, it automatically detected and migrated my existing Q CLI setup:

Agents from ~/.aws/amazonq → ~/.kiro/agents/
MCP config from ~/.aws/amazonq/mcp.json → ~/.kiro/settings/mcp.json
Rules from ~/.aws/amazonq/rules → ~/.kiro/steering/

Two years of custom configurations carried over in seconds. The only thing I had to fix was one MCP server with a hardcoded path to ~/.aws/amazonq/ in its environment variables. Everything else just worked.

No starting from scratch. No rebuilding your setup. That's how migrations should feel.

One More Thing: Classic Mode

By default, Kiro opens in the new Terminal UI. It looks polished, but on remote servers and SSH sessions, I prefer classic mode faster rendering, no UI lag, works perfectly in tmux.

Try it once:

kiro-cli --classic

Make it permanent:

kiro-cli settings chat.ui "classic"

Now every time you run kiro-cli, it starts in classic mode:

Why I Prefer Classic Mode on Remote Servers

Faster rendering over SSH
No UI lag
Works perfectly in tmux
More predictable behavior in long sessions

If you ever want the full UI back:

kiro-cli settings chat.ui "tui"

Or just run kiro-cli --tui for a one-off session.

Cleanup (Optional)

That 350 MB zip file is still sitting there. Once you've verified everything works:

rm ~/kirocli.zip

First Impressions After One Week

After seven days of daily use, here's what stood out:

The q command still works. Muscle memory preserved. Kiro CLI responds to both kiro-cli and q.
Model auto-selection is smart. Simple questions get fast responses. Complex architecture questions get deeper reasoning. I don't have to think about which model to pick.
MCP servers change everything. Going from "AI that guesses" to "AI that queries real data" is a paradigm shift. Cost optimization alone justified the switch.
Steering files are addictive. Once you teach it your standards, you can't go back to repeating yourself.

I went from "reluctant migrator" to "why didn't this exist sooner" in about three days.

What's Next

Now that it's installed, the real value starts. In the next article, I'll cover how I use Kiro CLI for actual work setting up MCP servers for cost optimization, creating custom agents that enforce team standards, writing steering files, and the daily workflows that made this tool indispensable.

👉 Part 2: From Budget Alerts to AI-Powered Optimization The Complete Kiro CLI Guide

📌 Wrapping Up

Thank you for reading! I hope this article gave you practical insights and a clearer perspective on the topic.

Was this helpful?

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

Follow me for more on:

AWS architecture patterns
FinOps automation
Multi-account strategies
AI-driven DevOps

💡 What’s Next

More deep dives coming soon on cloud operations, GenAI, Agentic-AI, DevOps, and data workflows follow for weekly insights.

🌐 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 drop a comment or connect with me on LinkedIn.

For collaborations, consulting, or technical discussions, feel free to reach out directly at simplynadaf@gmail.com

Happy Learning 🚀

Deploy Web Servers with Terraform: EC2 + Load Balancer Tutorial

Sarvar Nadaf — Mon, 27 Apr 2026 09:40:05 +0000

👋 Hey there, tech enthusiasts!

"A single server is a single point of failure. A load balancer is your insurance policy."

🎯 Welcome Back!

Remember in Article 6 when you built your first VPC with public and private subnets? You created the network foundation, but it was empty—no servers, no applications, nothing running.

Here's the reality: A VPC without compute resources is like building a highway with no cars. You need:

Web servers to run your applications
A way to handle traffic spikes
Protection against server failures
Zero-downtime deployments

That's where EC2 instances and Load Balancers come in.

By the end of this article, you'll:

✅ Deploy EC2 instances with Terraform
✅ Configure security groups for web servers
✅ Use user data to automate server setup
✅ Create an Application Load Balancer (ALB)
✅ Implement health checks and target groups
✅ Build high-availability web infrastructure

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

Cost: ~$33/month (~$16 with free tier for ALB)

Difficulty: Intermediate

Let's deploy some real infrastructure! 🚀

💔 The Problem: Single Server Syndrome

The Nightmare Scenario

It's 2 AM. Your phone rings.

Monitoring Alert: Website Down
Status: 503 Service Unavailable
Cause: EC2 instance crashed
Impact: 100% of users affected
Revenue Loss: $500/minute

You scramble to:

SSH into the server (if you can)
Restart the application
Hope it comes back up
Watch users leave your site

The root cause? You had one server running everything.

Common Single-Server Problems:

❌ Traffic Spike: Black Friday hits, server crashes from load

❌ Hardware Failure: AWS instance dies, site goes down

❌ Deployment Risk: Update breaks something, entire site offline

❌ No Redundancy: One point of failure = business risk

❌ Manual Recovery: You're the human load balancer at 2 AM

❌ Poor User Experience: Slow response times, timeouts, errors

Sound familiar? Let's fix this with load balancing.

🌟 What is a Load Balancer? (Quick Theory)

Simple Definition

Load Balancer = Traffic cop for your servers. It:

Distributes incoming requests across multiple servers
Monitors server health automatically
Routes traffic only to healthy servers
Enables zero-downtime deployments

Think of it like this:

Without Load Balancer:

All Users → Single Server → 💥 Overloaded/Crashed

With Load Balancer:

Users → Load Balancer → Server 1 (healthy) ✅
                     → Server 2 (healthy) ✅
                     → Server 3 (unhealthy) ❌ (no traffic)

Why You Need This

Scenario 1: Traffic Spike

Normal: 100 requests/sec → 2 servers handle it easily
Black Friday: 10,000 requests/sec → Load balancer distributes across all servers
Result: Site stays up, users happy

Scenario 2: Server Failure

Server 1 crashes at 2 AM
Load balancer detects failure in 30 seconds
Automatically stops sending traffic to Server 1
Server 2 handles all traffic
Result: You sleep through the night

Scenario 3: Deployment

Deploy new code to Server 1
Load balancer keeps sending traffic to Server 2
Test Server 1, then switch traffic
Result: Zero downtime deployment

📋 Prerequisites

Before starting, make sure you have:

✅ Completed Article 6: Building Your First AWS VPC
✅ Terraform installed (v1.0+)
✅ AWS CLI configured
✅ Basic understanding of VPC and networking
✅ An SSH key pair in AWS (or we'll create one)

🏗️ What We're Building

Internet
    ↓
Application Load Balancer (ALB)
    ↓
    ├─→ EC2 Instance 1 (Apache)
    └─→ EC2 Instance 2 (Apache)

Architecture Components:

VPC - Our isolated network
Public Subnet - Where our resources live
Internet Gateway - Internet access
Security Groups - Firewall rules
EC2 Instances - Web servers running Apache
Application Load Balancer - Traffic distributor
Target Group - Manages server health

📁 Project Structure

Create this folder structure:

07-ec2-load-balancer/
├── main.tf           # Main infrastructure code
├── variables.tf      # Input variables
├── outputs.tf        # Output values
└── terraform.tfvars  # Variable values

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)

Building a VPC from Scratch…

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: Define Variables

Create variables.tf:

# AWS Region
variable "aws_region" {
  description = "AWS region where resources will be created"
  type        = string
  default     = "us-east-1"
}

# Project Name
variable "project_name" {
  description = "Project name for resource naming"
  type        = string
  default     = "terraform-web"
}

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

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

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

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

# Instance Count
variable "instance_count" {
  description = "Number of EC2 instances"
  type        = number
  default     = 2
}

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

# My IP for SSH Access
variable "my_ip" {
  description = "Your IP address for SSH access (CIDR format)"
  type        = string
  default     = "0.0.0.0/0"  # Change this to your IP for security
}

Key Points:

instance_count = 2 - We'll create 2 web servers
instance_type = "t2.micro" - Free tier eligible
my_ip - Restrict SSH access (change from 0.0.0.0/0 in production!)

🌐 Step 2: Create VPC and Networking

Add to main.tf:

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

# Provider Configuration
provider "aws" {
  region = var.aws_region
}

# Data source: Get latest Amazon Linux 2023 AMI
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

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

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

# Data source: Get available availability zones
data "aws_availability_zones" "available" {
  state = "available"
}

# 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
    ManagedBy   = "Terraform"
  }
}

# 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"
    Environment = var.environment
    Type        = "Public"
    ManagedBy   = "Terraform"
  }
}

# Public Route Table

# Public Subnet 2 (Different AZ for ALB)
resource "aws_subnet" "public_2" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.2.0/24"
  availability_zone       = data.aws_availability_zones.available.names[1]
  map_public_ip_on_launch = true

  tags = {
    Name        = "${var.project_name}-public-subnet-2"
    Environment = var.environment
    Type        = "Public"
    ManagedBy   = "Terraform"
  }
}
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"
    Environment = var.environment
    Type        = "Public"
    ManagedBy   = "Terraform"
  }
}

# Route Table Association
resource "aws_route_table_association" "public" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public.id
}

# Route Table Association for Public Subnet 2
resource "aws_route_table_association" "public_2" {
  subnet_id      = aws_subnet.public_2.id
  route_table_id = aws_route_table.public.id
}

New Concept: Data Sources

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

Data sources query existing AWS resources. Here we're finding the latest Amazon Linux AMI automatically - no need to hardcode AMI IDs!

🔒 Step 3: Configure Security Groups

Security groups are like firewalls. Add to main.tf:

# Security Group for ALB
resource "aws_security_group" "alb" {
  name        = "${var.project_name}-alb-sg"
  description = "Security group for Application Load Balancer"
  vpc_id      = aws_vpc.main.id

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

  egress {
    description = "Allow all outbound traffic"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

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

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

  ingress {
    description     = "HTTP from ALB"
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

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

  egress {
    description = "Allow all outbound traffic"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

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

Security Architecture:

Internet → ALB (Port 80) → EC2 Instances (Port 80)
                            EC2 Instances (Port 22 from your IP)

Key Security Practices:

ALB accepts HTTP (80) from anywhere
EC2 instances only accept HTTP from ALB (not directly from internet!)
SSH (22) only from your IP address
This is called "defense in depth"

🖥️ Step 4: Deploy EC2 Instances

Now for the exciting part - creating web servers! Add to main.tf:

# EC2 Instances
resource "aws_instance" "web" {
  count = var.instance_count

  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.instance.id]

  user_data = base64encode(<<-EOF
    #!/bin/bash
    dnf update -y
    dnf install -y httpd
    systemctl start httpd
    systemctl enable httpd
    echo "<h1>Terraform Web Server - Instance: $(ec2-metadata --instance-id | cut -d' ' -f2)</h1><p>AZ: $(ec2-metadata --availability-zone | cut -d' ' -f2)</p>" > /var/www/html/index.html
    EOF
  )

  tags = {
    Name        = "${var.project_name}-web-${count.index + 1}"
    Environment = var.environment
    ManagedBy   = "Terraform"
    Server      = "web-${count.index + 1}"
  }
}

Breaking Down the Code:

1. Count Meta-Argument:

count = var.instance_count

Creates multiple instances. With instance_count = 2, we get 2 servers!

2. User Data - The Magic:

user_data = <<-EOF
  #!/bin/bash
  yum update -y
  yum install -y httpd
  # ...
EOF

User data runs automatically when the instance starts. It:

Updates the system
Installs Apache web server
Starts Apache
Creates a custom HTML page

3. Dynamic Naming:

Name = "${var.project_name}-web-${count.index + 1}"

First instance: terraform-web-web-1
Second instance: terraform-web-web-2

⚖️ Step 5: Create Application Load Balancer

The load balancer distributes traffic. Add to main.tf:

# Application Load Balancer
resource "aws_lb" "main" {
  name               = "${var.project_name}-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = [aws_subnet.public.id, aws_subnet.public_2.id]

  enable_deletion_protection = false

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

# Target Group
resource "aws_lb_target_group" "main" {
  name     = "${var.project_name}-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  health_check {
    enabled             = true
    healthy_threshold   = 2
    unhealthy_threshold = 2
    timeout             = 5
    interval            = 30
    path                = "/"
    protocol            = "HTTP"
    matcher             = "200"
  }

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

# Target Group Attachment
resource "aws_lb_target_group_attachment" "main" {
  count = var.instance_count

  target_group_arn = aws_lb_target_group.main.arn
  target_id        = aws_instance.web[count.index].id
  port             = 80
}

# ALB Listener
resource "aws_lb_listener" "main" {
  load_balancer_arn = aws_lb.main.arn
  port              = "80"
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.main.arn
  }

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

Understanding Load Balancer Components:

1. Application Load Balancer (ALB):

The main load balancer resource
internal = false - Internet-facing
load_balancer_type = "application" - Layer 7 (HTTP/HTTPS)

2. Target Group:

Manages the backend servers
Performs health checks every 30 seconds
Marks servers healthy after 2 successful checks
Marks servers unhealthy after 2 failed checks

3. Target Group Attachment:

count = var.instance_count
target_id = aws_instance.web[count.index].id

Registers each EC2 instance with the target group.

4. Listener:

Listens on port 80
Forwards traffic to the target group

Health Check Flow:

ALB → Checks "/" every 30s → Expects HTTP 200 → 
  ✅ Healthy (2 successes) → Receives traffic
  ❌ Unhealthy (2 failures) → No traffic

📤 Step 6: Define Outputs

Create outputs.tf:

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

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

# EC2 Instance Outputs
output "instance_ids" {
  description = "IDs of EC2 instances"
  value       = aws_instance.web[*].id
}

output "instance_public_ips" {
  description = "Public IPs of EC2 instances"
  value       = aws_instance.web[*].public_ip
}

# Load Balancer Outputs
output "alb_dns_name" {
  description = "DNS name of the Application Load Balancer"
  value       = aws_lb.main.dns_name
}

output "alb_url" {
  description = "URL to access the load balancer"
  value       = "http://${aws_lb.main.dns_name}"
}

# Security Group Outputs
output "alb_security_group_id" {
  description = "ID of ALB security group"
  value       = aws_security_group.alb.id
}

output "instance_security_group_id" {
  description = "ID of instance security group"
  value       = aws_security_group.instance.id
}

Splat Expression:

aws_instance.web[*].id

The [*] gets ALL instance IDs as a list. Super useful with count!

⚙️ Step 7: Set Variable Values

Create terraform.tfvars:

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

# Network Configuration
vpc_cidr = "10.0.0.0/16"
public_subnet_cidr = "10.0.1.0/24"

# EC2 Configuration
instance_type = "t2.micro"
instance_count = 2
key_name = "my-key"

# Security - Change this to your IP address
my_ip = "0.0.0.0/0"

⚠️ Important: Change my_ip to your actual IP address for security!

Find your IP:

curl ifconfig.me

Then update:

my_ip = "203.0.113.0/32"  # Your IP

🚀 Step 8: Deploy the Infrastructure

1. Create SSH Key Pair (if you don't have one)

# Create key pair in AWS
aws ec2 create-key-pair \
  --key-name my-key \
  --query 'KeyMaterial' \
  --output text > my-key.pem

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ttadkcyqnuxbsnpwdqs7.png)


# Set permissions
chmod 400 my-key.pem

2. Initialize Terraform

terraform init

Expected output:

Initializing the backend...
Initializing provider plugins...
- Finding hashicorp/aws versions matching "~> 5.0"...
- Installing hashicorp/aws v5.100.0...

Terraform has been successfully initialized!

3. Review the Plan

terraform plan

You should see:

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

Resources being created:

1 VPC
1 Internet Gateway
1 Subnet
1 Route Table + Association
2 Security Groups
2 EC2 Instances
1 Application Load Balancer
1 Target Group
2 Target Group Attachments
1 ALB Listener

4. Apply the Configuration

terraform apply

Type yes when prompted.

This will take 3-5 minutes because:

EC2 instances need to boot
User data script runs
ALB needs to provision
Health checks need to pass

✅ Step 9: Test Your Infrastructure

1. Get the Load Balancer URL

terraform output alb_url

Output:

http://terraform-web-alb-1740709428.us-east-1.elb.amazonaws.com

2. Test in Browser

Open the URL in your browser. You should see:

🚀 Terraform Web Server
Deployed with Infrastructure as Code

Instance ID: i-09305fc7d4638360a
Availability Zone: us-east-1a
Server: 1

3. Test Load Balancing

Refresh the page multiple times. You'll see the Instance ID and Server number change - that's the load balancer distributing traffic!

First request  → Server: 1
Second request → Server: 2
Third request  → Server: 1

4. Test Individual Instances

# Get instance IPs
terraform output instance_public_ips

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jbibepofm64vdjwyk9kj.png)


# Test directly (should work)
curl http://<instance-ip>

🔍 Understanding What Happened

Traffic Flow

User Request
    ↓
ALB DNS (terraform-web-alb-xxx.elb.amazonaws.com)
    ↓
ALB Listener (Port 80)
    ↓
Target Group (Health Check: ✅)
    ↓
Round-Robin Distribution
    ├─→ EC2 Instance 1 (Apache) → Response
    └─→ EC2 Instance 2 (Apache) → Response

Health Check Process

Every 30 seconds:
ALB → GET / → EC2 Instance
    ↓
HTTP 200 OK?
    ├─ Yes (2 times) → Mark Healthy → Send Traffic
    └─ No (2 times)  → Mark Unhealthy → Stop Traffic

🧪 Advanced Testing

Test High Availability

Scenario: What if one server fails?

# Get instance IDs
terraform output instance_ids

# Stop one instance
aws ec2 stop-instances --instance-ids i-xxxxx

# Wait 1 minute for health check to fail

# Test the ALB URL - still works!
curl http://<alb-dns>

The ALB automatically stops sending traffic to the unhealthy instance!

Monitor Health Status

# Check target health
aws elbv2 describe-target-health \
  --target-group-arn <target-group-arn>

Output:

{
  "TargetHealthDescriptions": [
    {
      "Target": {
        "Id": "i-xxxxx",
        "Port": 80
      },
      "HealthCheckPort": "80",
      "TargetHealth": {
        "State": "healthy"
      }
    }
  ]
}

🐛 Troubleshooting Common Issues

Issue 1: "InvalidKeyPair.NotFound"

Error:

Error: creating EC2 Instance: InvalidKeyPair.NotFound

Solution:

# List your key pairs
aws ec2 describe-key-pairs

# Create if missing
aws ec2 create-key-pair --key-name my-key \
  --query 'KeyMaterial' --output text > my-key.pem
chmod 400 my-key.pem

# Update terraform.tfvars with correct key name

Issue 2: ALB Shows "503 Service Unavailable"

Cause: Instances are unhealthy or still booting.

Solution:

# Wait 2-3 minutes for:
# 1. Instances to boot
# 2. User data to complete
# 3. Health checks to pass

# Check target health
aws elbv2 describe-target-health \
  --target-group-arn $(terraform output -raw target_group_arn)

Issue 3: Can't SSH to Instances

Cause: Security group blocks your IP.

Solution:

# Get your current IP
curl ifconfig.me

# Update terraform.tfvars
my_ip = "YOUR_IP/32"

# Apply changes
terraform apply

Issue 4: "Subnet must have at least 2 availability zones"

Error with ALB:

Error: creating ELBv2 Load Balancer: ValidationError

Solution: ALBs require at least 2 subnets in different AZs. Update main.tf:

# Add second subnet
resource "aws_subnet" "public_2" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.2.0/24"
  availability_zone       = data.aws_availability_zones.available.names[1]
  map_public_ip_on_launch = true

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

# Update ALB subnets
resource "aws_lb" "main" {
  # ...
  subnets = [aws_subnet.public.id, aws_subnet.public_2.id]
}

💰 Cost Breakdown

Monthly Costs (us-east-1):

Resource	Quantity	Cost/Month	Total
t2.micro EC2	2	$8.50	$17.00
Application Load Balancer	1	$16.20	$16.20
Data Transfer (1GB)	-	$0.09	$0.09
Total			~$33.29

Free Tier Benefits:

First 750 hours/month of t2.micro (covers both instances!)
First 15 GB data transfer out
Actual cost with free tier: ~$16.20/month (just the ALB)

Cost Optimization Tips:

Use t2.micro (free tier eligible)
Delete resources when not in use
Use Network Load Balancer ($10.95/month) if you don't need Layer 7 features
Consider using Auto Scaling (covered in future articles)

🧹 Cleanup

Important: Don't forget to destroy resources to avoid charges!

# Destroy everything
terraform destroy

# Type 'yes' when prompted

This will delete:

✅ Load Balancer
✅ Target Group
✅ EC2 Instances
✅ Security Groups
✅ VPC and networking

Verify deletion:

# Check EC2 instances
aws ec2 describe-instances --filters "Name=tag:ManagedBy,Values=Terraform"

# Check load balancers
aws elbv2 describe-load-balancers

📚 Key Concepts Learned

1. Count Meta-Argument

count = 2

Creates multiple identical resources. Access with [count.index].

2. Data Sources

data "aws_ami" "amazon_linux" { }

Query existing AWS resources instead of hardcoding values.

3. User Data

user_data = <<-EOF
  #!/bin/bash
  # Bootstrap script
EOF

Automate instance configuration at launch.

4. Security Group References

security_groups = [aws_security_group.alb.id]

Reference one security group from another for layered security.

5. Splat Expressions

aws_instance.web[*].id

Get all values from resources created with count.

6. Health Checks

health_check {
  path     = "/"
  interval = 30
}

Automatic monitoring and traffic routing.

🎯 Real-World Applications

This architecture is used for:

1. Web Applications

WordPress sites
E-commerce platforms
SaaS applications

2. API Backends

REST APIs
GraphQL servers
Microservices

3. Content Delivery

Static websites
Media streaming
File downloads

4. Development Environments

Staging servers
Testing environments
Demo applications

🚀 What's Next?

In the next article, we'll add:

RDS Database - Persistent data storage
AWS Secrets Manager - Secure credential management
Private Subnets - Enhanced security
Database Connection - Connect EC2 to RDS

Coming Up: Article 8: Secure Database Deployment: RDS + Secrets Manager with Terraform

📖 Additional Resources

Official Documentation:

Related Articles:

💬 Questions?

Common Questions:

Q: Can I use different instance types for each server?

A: Yes! Use for_each instead of count for more flexibility (covered in Article 13).

Q: How do I add HTTPS/SSL?

A: You'll need an ACM certificate and update the listener to port 443. We'll cover this in a future article.

Q: Can I deploy to multiple regions?

A: Yes! Use Terraform workspaces or separate state files per region.

Q: How do I add auto-scaling?

A: Replace EC2 instances with an Auto Scaling Group. We'll cover this in Article 15.

✅ Summary

Today you learned how to:

✅ Deploy multiple EC2 instances with Terraform
✅ Use count to create multiple resources
✅ Configure security groups for layered security
✅ Automate server setup with user data
✅ Create an Application Load Balancer
✅ Implement health checks and high availability
✅ Test load balancing in action

You now have production-ready web infrastructure! 🎉

📌 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