DEV Community: Sarvar Nadaf

I Followed the n8n AWS Docs and It Broke at the First Command

Sarvar Nadaf — Fri, 25 Sep 2026 14:09:50 +0000

You SSH into a fresh EC2 box, run sudo dnf install -y docker, then the very next command from the guide you're following:

docker compose up -d

And it dies:

docker: 'compose' is not a docker command.

I hit this on camera. Followed the steps, watched n8n never come up, and spent a few minutes convinced I'd broken something. I hadn't. Almost every "self-host n8n on AWS" tutorial has this exact hole in it, because the authors tested on Ubuntu or a VPS where Docker installs differently. On Amazon Linux 2023, the default AMI for EC2, the command they tell you to run gives you half of what you need.

This post is the fix, and the full path from a bare EC2 instance to your first n8n login. Two containers, one paste-ready compose file, no reverse proxy yet (that's the hardening step, and it's its own article). By the end you have n8n on Postgres running on a box you own.

The gotcha, up front

On Amazon Linux 2023:

sudo dnf install -y docker

installs the Docker engine. It does not install the Compose v2 plugin. They're separate now. Compose stopped being a standalone docker-compose binary years ago and became a plugin that lives under Docker's CLI, and dnf's docker package doesn't bundle it. So the engine runs fine, docker run works, and then docker compose throws 'compose' is not a docker command because the plugin isn't there.

On Ubuntu you'd install docker.io plus docker-compose-plugin from Docker's apt repo and never notice. On AL2023 the plugin is on you. Here's the whole install, plugin included:

sudo dnf install -y docker
sudo mkdir -p /usr/local/lib/docker/cli-plugins
sudo curl -fsSL \
  https://github.com/docker/compose/releases/download/v2.29.7/docker-compose-linux-x86_64 \
  -o /usr/local/lib/docker/cli-plugins/docker-compose
sudo chmod +x /usr/local/lib/docker/cli-plugins/docker-compose
sudo systemctl enable --now docker

That third command is the one the other guides skip: it drops Docker's official Compose plugin binary into the directory the CLI actually looks in. Now both answer:

sudo docker --version
# Docker version 25.0.14, build 0bab007
sudo docker compose version
# Docker Compose version v2.29.7

Two version banners is how you know the box is actually ready. If you only check the first one, you find out the plugin is missing at docker compose up, which is the worst time to find out.

One catch on the download URL: it ends in x86_64, which is right for a t3 (Intel) box. If you launched a Graviton/ARM instance (t4g and friends), grab the aarch64 binary instead by swapping the filename to docker-compose-linux-aarch64. The wrong architecture installs cleanly and then fails with an exec-format error the moment you run it, which sends you hunting in the wrong place. Pick the binary that matches your instance. And v2.29.7 is just the version I pinned here; check Docker's releases and use the current one if you'd rather not lag.

Launch the box first

Before any of that, you need the instance:

AMI: Amazon Linux 2023.
Size: t3.small or larger. n8n plus Postgres want about 2 GB of RAM. Skip t2.micro and t3.micro (1 GB) unless you like watching containers get OOM-killed mid-run.
Security Group: SSH (22) from your IP only. For this private first test you can open 5678 to your IP only too. Do not open 5678 to 0.0.0.0/0. An open n8n editor on the public internet is an editor anyone can find and claim.
SSH in: ssh -i your-key.pem ec2-user@<PUBLIC_IP>

Everything below runs on that box as ec2-user.

Why bother self-hosting at all

n8n is a credential aggregator. One instance can hold your Stripe key, your database password, your Slack token, your Google OAuth, all in one place. On n8n Cloud that pile lives on someone else's server, priced per seat, capped on executions. Self-hosting moves it onto a box inside your own AWS account: no seat fees, no execution caps, your data stays home, and you pick the version.

The trade is honest. You now own the patching, the backups, and the security. This article gets it running. The hardening article (next in the series) closes the door behind it.

The stack: two containers

That's the whole thing.

n8n runs the editor and the workflow engine.
Postgres stores workflows and executions so they survive a restart.

Not SQLite. n8n defaults to SQLite, which is fine for a five-minute look, but it handles concurrent executions poorly and migrating off it later is an afternoon you won't enjoy. Start on Postgres.

Clone the repo so you have the compose file on the box:

git clone https://github.com/simplynadaf/self-host-n8n-on-ec2.git
cd self-host-n8n-on-ec2/compose

Here's the compose file:

services:
  n8n:
    image: n8nio/n8n:1.123.64
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_SECURE_COOKIE=false
      - N8N_DIAGNOSTICS_ENABLED=false
      - N8N_PERSONALIZATION_ENABLED=false
      - N8N_ENCRYPTION_KEY=change-me-to-a-long-random-string-please
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=change-me-strong-db-password
    depends_on:
      - postgres

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_DB=n8n
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=change-me-strong-db-password
    volumes:
      - pg_data:/var/lib/postgresql/data

volumes:
  pg_data:

Three lines decide whether this works.

The image is pinned to 1.123.64, not latest. Pinning makes the build reproducible, and this version patches a real issue: CVE-2026-65589, an info-disclosure bug where credentials passed as custom headers in LLM sub-nodes could land in execution records. Run latest and you're one silent restart away from a version you didn't choose.

N8N_ENCRYPTION_KEY encrypts every credential n8n stores. Set a real 32-plus character random string and save it somewhere safe right now. Lose it and every saved credential is unrecoverable. A restored backup without this key is a database full of workflows whose logins can't be decrypted.

The DB password appears twice (DB_POSTGRESDB_PASSWORD in the n8n service, POSTGRES_PASSWORD in postgres) and the two values must match. If they don't, n8n can't reach its own database and the container just restarts in a loop while you wonder why the editor never loads.

Bring it up

Edit the two passwords and the encryption key, then:

sudo docker compose up -d
sudo docker compose ps

First run pulls both images and starts them. Give it twenty to forty seconds, then check n8n is answering:

curl -s -o /dev/null -w 'n8n -> HTTP %{http_code}\n' http://localhost:5678
# n8n -> HTTP 200

200 means n8n is up and serving. Once Compose was actually installed, this came back green on the first try.

First login

Open http://<PUBLIC_IP>:5678 in a browser. A fresh instance shows the setup wizard. Create your owner account with an email and a strong password, submit, and you land on the canvas.

Do this immediately after the box comes up, not tomorrow. The first account created on a fresh n8n becomes the owner, and until someone submits that form, it's open to whoever reaches it first. On a private Security Group that's only you. It's still a habit worth keeping.

One line in the compose file explains itself here: N8N_SECURE_COOKIE=false. That's only so first login works over plain HTTP on a raw IP while testing. It's a development shortcut, not a keeper. In production n8n sits behind HTTPS and this setting goes away.

Before this goes anywhere near the internet

The compose here publishes port 5678 directly. That's fine for a private test where the Security Group only lets your IP in, but it falls apart on the open internet, where certificate transparency logs announce every new HTTPS host within minutes and scanners find fresh boxes fast.

Before you point a domain at this or widen the Security Group:

Keep n8n patched (1.123.64 or newer).
Stop publishing 5678. Use expose so it's only reachable inside the Docker network.
Put Caddy in front for automatic TLS, and restrict the editor to your admin IP. Leave only /webhook/* public.
Move the encryption key and DB password into AWS Secrets Manager, read through a least-privilege IAM role.
Security Group: allow 22 (your IP), 80, 443. Never 5678 to 0.0.0.0/0.

That whole checklist is the hardening article in this series. If this box is going public, that's your next read.

Stop and start without losing data

Your data lives in the pg_data volume, so you can stop the stack safely:

sudo docker compose down     # stop, keep the data
sudo docker compose up -d    # start again

down stops the containers and keeps the volume, so your workflows and account are still there on the next up. To also wipe the data, that's down -v, and only when you mean it.

What you have now

n8n running on an EC2 box you control, backed by Postgres.
A pinned, patched image instead of a moving latest target.
An encryption key you actually set and saved.
A clear line for what to do before this faces the internet.

And you know the one thing most AWS n8n guides get wrong: on Amazon Linux 2023, installing Docker does not install Compose, and the fix is one curl into the plugin directory.

Where the series goes

Get it running (this one): bare EC2 to first login, past the Compose gotcha.
Harden it: TLS, closed editor port, Secrets Manager, least-privilege IAM.
Give it a brain: wire this same n8n to Amazon Bedrock and build a real AI agent on the canvas, model running in your account, no OpenAI key anywhere.

The compose file, the install and verify scripts, and the full setup notes are in the repo: github.com/simplynadaf/self-host-n8n-on-ec2.

Per-Agent Cost Tracking for Multi-Agent AI on AWS

Sarvar Nadaf — Wed, 23 Sep 2026 13:41:46 +0000

Your multi-agent run just returned a perfect answer. Clean summary, right resources, no errors. Your APM dashboard (the application performance monitoring you already run: uptime, latency, error rate) says 200 OK, latency fine, everything green.

And you were silently billed about 1.4x what you should have been.

That is the part nobody shows you. Nested traces and per-agent cost are becoming common; the primitives are easy to find now. What stays rare is a data model that lets you act on them: catch the run that looks completely successful while it burns money in the middle. The paper "Why Do Multi-Agent LLM Systems Fail?" (MAST, arXiv:2503.13657) hand-annotated 150 traces across 7 state-of-the-art multi-agent systems, hit an inter-annotator agreement of kappa=0.88, and measured failure rates from 41% to 86.7%. The uncomfortable finding: many of those failures do not crash. They complete. They look fine.

In this article I build a small read-only "AWS Account Investigator" crew, wire real cost into every trace span, and then reproduce three silent-waste patterns with real Amazon Nova Pro dollars. You can run the whole thing for $0 locally. Nothing gets created, modified, or deleted in your AWS account.

If you only have two minutes, jump straight to the unique part: catching silent waste. The build up to it matters, but that section is the payoff.

I spent about a week on this against a real AWS account: a few days probing the SDK's behavior before I trusted it, then several more building the crew, watching the trace design break twice, and reading the SDK source when the docs ran out. What follows is written from that, not from a quickstart. The scars are in here on purpose, because they are the part that saves you the week.

This is for people already building AI agents who have never put a real observability layer under them. You know agents, tools, and crews. Where the tracing vocabulary (spans, traces, OpenTelemetry) is new, I define it the first time it shows up.

Contents

Why agent observability is a different problem
Picking the instrumentation
Prerequisites
Adding Traccia to your code
The stack: AWS native and read only
The cost bridge and one gotcha
Modeling a multi-agent crew in traces
The unique part: catching silent waste
Watching it happen: the live control panel
Build your own, at zero cost and read only
An honest take on Traccia
Honest caveats
FAQ

Why agent observability is a different problem

Traditional application monitoring answers three questions: is it up, is it fast, is it erroring. For a CRUD service that is enough, because the work is deterministic and the failure modes are loud. An AI agent breaks all three assumptions. It decides its own control flow at runtime, it calls tools in an order you did not hardcode, and it pays per token for every reasoning step. A run can be up, fast, and error-free while doing the wrong amount of work: re-reading the same data, dragging bloated context from step to step, looping an extra cycle before it settles. None of that shows up as a 500 or a slow span. It shows up on the bill, and by then it is a trend, not an event.

So agent observability has to record things classic APM never needed: how many reasoning cycles an agent took, which tools it called versus which it was allowed to call, the token count and dollar cost of each step, and which agent in a multi-agent crew did what. Those attributes are what make an invisible regression visible.

This is not a fringe opinion. AWS's own Well-Architected Agentic AI Lens frames the baseline state (its "Level 1") as exactly this problem: agent costs are visible only at the account level, Cost Explorer cannot separate agents or workflows, and "teams react to billing surprises after the fact because per-agent and per-reasoning-phase attribution is missing." The whole point of what follows is to move off Level 1: to make spending "attributable at the reasoning-cycle, agent, workflow, and tenant level rather than only at the account level," which is AWS's own words for the target.

A quick vocabulary anchor, since the rest of the article leans on it. A span is one timed step with attributes attached (one LLM call, one tool call, one AWS read). A trace is the tree of spans for one unit of work. Classic APM records spans too, but only the loud attributes (status, latency). Agent observability is the same trace structure carrying agent-specific attributes: cycle count, tokens, cost, and which agent owned the step. That is the whole idea; everything below is just putting the right attributes on the right spans.

At one run, a 1.4x overspend is a rounding error. At enterprise scale it is a budget line and a governance problem, and it shows up in four concrete ways:

Cost control. A 1.03x-to-1.4x silent overspend per run (the real range I measured across three waste patterns), multiplied across thousands of daily runs and dozens of agents, is real money leaking with no alarm attached. Per-agent, per-tool cost on the trace is the only way to attribute and cap it.
Accountability. When a crew misbehaves, "which agent, owned by which team, cost what" needs to be answerable. Trace-level ownership metadata turns a vague incident into a routed ticket.
Regression detection. Agents change when prompts, models, or tools change. A known-good baseline plus per-run deltas catches the day a prompt tweak silently doubled token usage, before finance does.
Auditability. In regulated environments you need a record of what the agent read, what it decided, and what it cost. A trace is that record.

The theme throughout: a correct-looking answer is not evidence of a healthy run. The evidence lives in the trace, on attributes you put there on purpose. Here is the before and after in one line. Before, a typical demo gives you one lump token count for the whole run, and an inefficient run looks identical to an efficient one. After, every reasoning step and every AWS read is a span carrying real cost, tokens, cycle count, and the owning agent's identity, so two runs that both return the correct answer and both show 200 OK are no longer indistinguishable when one of them costs 43% more.

Picking the instrumentation

Once you know you need per-agent cost, cycle counts, and tool-call attributes on every span, the next question is what to write them with. You could do a lot of this with raw OpenTelemetry, and I nearly did. The reason I did not is that agents need a vocabulary plain OTel does not ship: token counts turned into dollars, a span-level agent identity so one process can render as a real fleet, ownership metadata, and a way to view per-agent cost grouped by session. You end up building all of that yourself, or you find an SDK that already speaks it.

There are options here: LangSmith, Langfuse, and Arize Phoenix all do LLM tracing, and each is worth a look depending on your stack. I went looking for one I would trust in a codebase, which for me means two hard requirements: I can read the source, and I am not locked in. Traccia cleared both cleanly. The SDK is open source, Apache-2.0 licensed, and built on OpenTelemetry (OTel, the vendor-neutral open standard for traces and metrics, the reason you are not locked into any one backend). The spans it produces are standard OTel, the file exporter works with no account and no network, and I could read exactly what it does to my data before committing to it (I did, and the source-grounded critique later in this article is the result). It runs at $0 locally; the hosted dashboard at app.traccia.ai is optional and only comes in when you want the visualization. An open, inspectable SDK with an optional commercial backend is a split I am comfortable adopting, because the instrumentation does not trap me.

That is the real reason it is in this build: agent-native plumbing I did not want to hand-roll, source I could audit, and a real $0 offline path. It also has sharp edges, and I hit several of them; those are documented in full near the end rather than glossed over.

Why not Amazon Bedrock AgentCore Observability or Langfuse, the two obvious AWS-native alternatives? Both are good, and for many teams either is the right call. AgentCore Observability exports traces to CloudWatch and is the natural fit if your agents run on the AgentCore runtime, but AWS's own Well-Architected lens is blunt about the cost gap: "cost reporting stops at the AWS account level, so teams can't separate supervisor overhead from worker execution." Per-agent dollars are something you still assemble. Langfuse is the strong open-source incumbent and I would happily use it; it just was not the tool I was asked to put through its paces here. The point of this build is not "Traccia beats them." It is that whichever tracer you pick, the per-agent cost attribute and the baseline-delta detection are things you wire on purpose, and this article shows exactly how.

Prerequisites

Nothing exotic. Three things to run this yourself:

Python 3.10+ and the SDKs (strands-agents, strands-agents-tools, traccia, boto3). The repo pins the exact tested versions in requirements.txt.
AWS credentials with read-only permissions for the services the crew reads (Cost Explorer, EC2, CloudWatch, S3, Lambda, IAM, GuardDuty), plus bedrock:InvokeModel so the agent can actually call the model. The repo ships a ready-to-use policy at iam/read-only-policy.json; AWS's managed SecurityAudit + ViewOnlyAccess cover the reads, but you still add bedrock:InvokeModel on top of them.
Amazon Nova Pro, which is two separate steps: (a) enable model access once in the Bedrock console (us-east-1, amazon.nova-pro-v1:0) under Model access, and (b) allow bedrock:InvokeModel in your IAM policy. The console grant is not an IAM permission, so you need both.

No Traccia account is required. With no API key it writes traces to a local file, which is the $0 path used throughout this article.

Getting it running is four commands:

git clone https://github.com/simplynadaf/ai-agent-observability-aws.git
cd ai-agent-observability-aws
python3 -m venv .venv && . .venv/bin/activate
pip install -r requirements.txt

Then create the least-privilege policy once (with your own admin credentials) and attach it to whoever runs the crew:

aws iam create-policy \
  --policy-name AgentObservabilityReadOnly \
  --policy-document file://iam/read-only-policy.json

Adding Traccia to your code

Before the crew, here is the smallest version of what "wire cost into a span" actually means, because that is the one non-obvious step. Traccia auto-instruments LangChain, CrewAI, and the OpenAI/Anthropic/Gemini clients, so on those stacks you get most of this for free. It does not yet hook Strands or raw Bedrock, so you stamp the cost yourself. It is a short function, and one attribute name will bite you (more on that below).

def stamp_llm_cost(span, result, model_id="amazon.nova-pro-v1:0"):
    usage = result.metrics.accumulated_usage
    in_tok, out_tok = usage["inputTokens"], usage["outputTokens"]
    cost = (in_tok / 1000 * 0.0008) + (out_tok / 1000 * 0.0032)  # Nova Pro, us-east-1

    span.set_attribute("llm.model", model_id)   # REQUIRED. wrong key = silently zero
    span.set_attribute("span.type", "LLM")
    span.set_attribute("llm.usage.prompt_tokens", in_tok)
    span.set_attribute("llm.usage.completion_tokens", out_tok)
    span.set_attribute("llm.cost.usd", round(cost, 6))

That is the whole idea: read the token usage the SDK already gives you, turn it into dollars against real pricing, and attach it to the span. Everything else in this article is applying this same move across a multi-agent crew and then reading the numbers back. The full wiring (init, the per-agent identity, the tool spans) is in src/crew.py in the repo.

The stack: AWS native and read only

The crew runs on Amazon Nova Pro (amazon.nova-pro-v1:0) through AWS Strands Agents using the agents-as-tools pattern. A supervisor named investigation_run delegates to three specialist sub-agents. Each specialist is a real separation of concerns, owns several read-only tools, and every one of those tools opens its own live span, so in the dashboard you see the agent, then each AWS read nested under it with a real duration. Here is the full fleet and exactly what each agent does.

1. AWS Account Investigator (supervisor, `investigation_run`)

The orchestrator. It does not touch AWS directly; it reads the user's question, decides which specialists are in scope, delegates to them, and synthesizes one report. On its trace span it records agent.delegated_to (which specialists it called this run), and it stamps the shared session.id that ties the whole investigation together.

The delegation is intent-routed, not fan-out-everything. The supervisor's instructions are strict: call ONLY the specialist whose domain the user actually asked about. Ask only about cost and it delegates to the Cost Analyst alone, while Health & Ops and the Security Auditor never run. Ask only about security and only the Security Auditor fires. Only a whole-account question ("what's running, any risks, and where is my spend going?") lights up all three. This matters for the trace and the bill: agent.delegated_to shows exactly which specialists ran, and a scoped question costs a fraction of a full sweep because the agents you did not need never spent a token. You can watch this live in the control panel: a cost-only prompt lights up one agent and leaves the other two idle.

Task	Tool	AWS read-only API
Plan + delegate	`cost_analyst`, `health_ops`, `security_ops`	none directly (delegates)

The supervisor's trace in Traccia: agent.delegated_to records which specialists ran this run, and the shared session.id links the four agents into one investigation.

2. Cost Analyst (`cost_analyst`)

A read-only FinOps specialist. It builds a full spend picture with three tools, and all three show up as separate tool spans in its trace.

Task	Tool	AWS read-only API
Month-to-date total, month-end forecast, top 5 services	`cost_forecast`	`ce:GetCostAndUsage`, `ce:GetCostForecast`
Last full month's total for month-over-month change	`last_month_cost`	`ce:GetCostAndUsage`
Daily cost series to catch a spike	`daily_cost_trend`	`ce:GetCostAndUsage`

What it reports on a real run: actual MTD spend, the account's forecasted month-end total, the top services by spend, the month-over-month direction and rough percentage, and the single most expensive day compared against the daily average (a possible spike).

The Cost Analyst trace: three Cost Explorer tool spans nested under the agent, each with its real read duration and the agent's own per-agent cost. This per-agent cost figure is exactly what turns a "successful" run into a caught overspend later.

3. Health & Ops (`health_ops`)

A read-only SRE specialist. It inventories the account and reads health signals with five tools, so it is usually the heaviest agent on input tokens (it chains the most reads).

Task	Tool	AWS read-only API
List running EC2 instances	`running_instances`	`ec2:DescribeInstances`
Read CPU utilization per instance	`cpu_utilization`	`cloudwatch:GetMetricStatistics`
Find unattached (idle) EBS volumes	`list_volumes`	`ec2:DescribeVolumes`
Inventory Lambda functions	`list_functions`	`lambda:ListFunctions`
Inventory S3 buckets	`list_buckets`	`s3:ListAllMyBuckets`

What it reports: running instances with their CPU, an inventory of volumes, functions, and buckets, and any notable health finding such as an unattached EBS volume.

The Health & Ops trace: five read-only tool spans and, on this run, the highest token count of the fleet (4,772) because it chains the most reads.

4. Security Auditor (`security_ops`)

A read-only security specialist. It runs four independent checks, each its own tool span.

Task	Tool	AWS read-only API
Security groups open to the internet (0.0.0.0/0)	`open_security_groups`	`ec2:DescribeSecurityGroups`
MFA gaps on the root account and IAM users	`mfa_findings`	`iam:GetAccountSummary`, `iam:ListUsers`, `iam:ListMFADevices`
S3 buckets missing a public-access block	`public_s3_buckets`	`s3:ListAllMyBuckets`, `s3:GetPublicAccessBlock`
Whether GuardDuty is enabled	`guardduty_enabled`	`guardduty:ListDetectors`

What it reports: each finding stated plainly with its risk, and it explicitly says so when a check comes back clean.

The Security Auditor trace: four independent read-only checks, each its own tool span with a real duration.

Each specialist stamps its own identity onto its trace span, so from a single crew run the dashboard shows four distinct agents with their own token and cost profiles, not one agent logged four times. Each agent runs as its own top-level trace, tied to the others by a shared session.id, and carries production ownership (type, owner, team) from a catalog file. Every call is a describe or get. There is no create, no modify, no delete. The worst thing this agent can do is read a bit too much, which, as you will see, is exactly the waste we want to catch.

Observability comes from Traccia, an OpenTelemetry-native agent-observability SDK.

pip install traccia

Runs $0 by default using a local file exporter. If you set TRACCIA_API_KEY, it pushes spans to app.traccia.ai. No key, no network, no cost. (The repo pins the exact tested version in requirements.txt; the prose stays unpinned so it does not age.)

Nova Pro pricing, pulled live from the AWS Price List API (effective 2026-08-01, us-east-1):

Token type	Price per 1K
Input	$0.0008
Output	$0.0032

Every dollar figure below is computed from real token counts against these two numbers.

The cost bridge and one gotcha

Here is the part most tutorials skip. Traccia auto-instruments several stacks out of the box (LangChain including BedrockChat, CrewAI, OpenAI Agents, and raw OpenAI/Anthropic/Gemini), and it ships a cost engine with a bundled pricing snapshot that covers Nova and Claude. But there is no Strands integration yet, and it does not hook raw Bedrock converse calls. So for this specific stack, Strands agents-as-tools calling Bedrock directly, you wire the cost in yourself. That is a fair amount of the value proposition for supported frameworks arriving for free, and real manual work for an unsupported one.

Strands hands you the token usage after a run. You read it, compute the cost, and stamp it onto the span, which is exactly the stamp_llm_cost function from earlier. About 40 lines once you handle all four agents and the tool spans; the full version is in src/crew.py.

The gotcha cost me a confused afternoon, and reading the SDK source explained exactly why. Traccia's cost-annotating processor only computes cost for a span when three things are all true: span.type is LLM (or unset), an llm.model attribute is present, and both token counts are set. Miss any one and the processor simply returns, with no error and no warning. I first set llm.request.model (which felt more semantically correct) instead of llm.model, so the processor silently skipped every span, and the "LLM Calls" and "Total Tokens" tiles read zero while my spans clearly had tokens on them. Set llm.model, and the tiles light up. The forgiving fail is reasonable; the fact that it is invisible is the trap. A one-line debug log ("skipping cost: no llm.model") would have saved the afternoon.

No double-counting across agents

The other question that always comes up: if the supervisor calls two sub-agents, and I sum everyone's tokens, am I counting the sub-agent tokens twice?

I wrote probes/probe_doublecount.py to check instead of guessing. Strands runs each sub-agent in its own event loop with its own metrics object. A supervisor's accumulated_usage is exclusive of its sub-agents' tokens. So the arithmetic is clean:

crew total = supervisor + sum(sub-agents)

No subtraction, no overlap, no double-count. Verified, not assumed.

Modeling a multi-agent crew in traces

Once the bridge is in, you get per-agent cost. But here is a design decision worth being explicit about, because most demos hand-wave it: how do you model a supervisor and its specialists in a trace?

You have two reasonable options. You can nest everything under one trace (supervisor is the root, sub-agents are child spans). Or you can give each agent its own top-level trace and tie them together with a shared session.id. I went with the second, because it is what a real production fleet looks like: the Cost Analyst, Health & Ops, and Security Auditor are independently owned, independently operated services. On the Traces page they show up as their own executions, each with its own cost, tokens, and duration; "Group by session" folds them back into one investigation when you want the whole picture.

session 4f4c1ade...  (one investigation, four independent traces)

  investigation_run   AWS Account Investigator   $0.006   delegated -> 3
  cost_analyst        Cost Analyst               $0.004
  health_ops          Health & Ops               $0.005   (highest total tokens: 4,772)
  security_ops        Security Auditor           $0.005
                                          crew total   $0.021

(These are the real per-agent figures from the exported run shown in the trace screenshots above, rounded to the dashboard's own cost tiles; they shift run to run with token usage. The crew total is the investigation_workflow roll-up span, which equals the supervisor's own synthesis plus the three sub-agents, no double-count. Health & Ops carries the highest token count because it chains the most reads, while the supervisor costs about the same because it writes the long final synthesis. The CLEAN and CONTEXT BLOAT numbers later in the article come from separate, labeled runs, so do not expect them to tie back to this one.)

Each agent's own trace still nests its tools underneath it (agent -> tool:running_instances -> the real boto3 call), so you keep the drill-down without pretending four separate services are one call stack. On the Traces page, "Group by session" folds all four agents from one run back into a single investigation, so you can move between the fleet view and the per-agent view without losing either.

(This is a different run from the CLEAN baseline used later; token counts and therefore dollars shift run to run. The point is the per-agent breakdown, not the absolute number.)

Good. Useful. Per-agent cost on its own is becoming common. The reason it matters here is not the number itself but the data model underneath it: once every step carries cost, tokens, cycle count, and an owning agent, you can build the thing that is still rare, which is catching a run that overspends while looking perfectly healthy. That is what the primitives let you build next.

A few things here are easy to get subtly wrong, and I hit them in roughly this order over a couple of days before the trace design held. First, all four agents come from a single crew run in a single process. Traccia bakes the agent identity into the OpenTelemetry resource at init, which is process-level, so my first version labeled every trace with one agent name: three identical "AWS Account Investigator" rows in the dashboard. Reading the SDK's enrichment processor showed that a span-level agent.id / agent.name attribute takes precedence over the process default, so stamping each agent's span with its own identity makes it show up as its own agent. Static ownership (type, owner, team, org) comes from an agent_config.json catalog the SDK auto-discovers, so the dashboard shows a real fleet with owners and teams, not four anonymous rows. No extra processes, no fake agents.

Second, separate traces need a real correlation key or they look disconnected. Every agent stamps the run's session.id, and the supervisor additionally records agent.delegated_to (which specialists it called this run). That is the explicit link that makes four independent traces read as one orchestrated investigation.

Third, the "each agent is its own trace" bit did not happen by wishing, and this one cost me a rebuild. Traccia's span_scope(parent=None) still inherits the current span if one is active, so my agents silently collapsed back into one trace until I detached the OpenTelemetry context before starting each agent's span. One small helper, verified by counting distinct trace IDs in the exported spans.

Fourth, the first time I looked at the timeline every tool span was 0ms, because I was reconstructing tool spans after the fact from the metrics object. The fix was to wrap the real boto3 call in a live span while it runs, so the timeline shows each AWS read's true duration. A 0ms bar is the kind of thing that makes a viewer distrust the whole trace, and it is worth chasing down. Then a subtler follow-on bit me: those live tool spans inherited the process-level default identity, so every tool bucketed under the supervisor and the specialists looked trace-thin. I had to stamp each tool span with its calling agent's identity too. Nothing about that was in the docs; I found it by parsing the exported traces.jsonl and noticing the agent.id was wrong.

One more touch that reads as production, not demo: each agent records both agent.tools_available (the full toolset it was granted) and agent.tools_called (what the model used this run). On this run, Cost Analyst had two tools available (month_to_date_cost and cost_forecast) and used one; Health & Ops had five and used all five. That gap is not a bug to hide, it is real information. "Has two, used one" is exactly the kind of thing you want visible when you are deciding whether an agent is over-provisioned.

The unique part: catching silent waste

Here is my disclaimer up front. I saw versions of all three of these in real runs while building the crew, then engineered them in src/waste_demo.py to trigger reliably so you can watch them on demand instead of waiting for a bad run. That reproduction is on purpose. LLM output is non-deterministic, so in production the same patterns show up on their own, just not on a schedule you can demo. And critically: detection here is delta-vs-baseline, not magic absolute thresholds. That is how real regression detection works. You capture a known-good run, then flag runs that deviate. Every number below is real Nova Pro token usage from a representative run. Your numbers will vary; the ratios are what hold.

First, the clean baseline. This is the "known good" I compare everything against.

CLEAN baseline (one exported run): crew total ~ $0.0083
  health_ops: 2,274 input / 199 output / 3 cycles

Scenario 1: The runaway loop

The agent gets stuck re-reasoning and re-reading the same things.

RUNAWAY LOOP: ~1.2x baseline ($0.0100 vs $0.0083)
  health_ops ran 4 cycles (baseline: 3)
  re-read cpu_utilization twice (baseline: once)
  health_ops input tokens ~1.6x (3,557 vs 2,274)

Same final answer. The APM span is 200 OK. What catches it: agent.cycle_count and tool.call_count. The agent looped more than its baseline and called the same tool repeatedly. No single number is "wrong." The delta is wrong.

Scenario 2: Redundant tool calls

Milder, sneakier. The agent calls a tool it already has the answer for.

REDUNDANT TOOL CALLS: ~1.03x baseline ($0.0085 vs $0.0083)
  running_instances called 3x (baseline: 1x)

A few percent on one run is the kind of thing you never notice. Multiply it across thousands of daily runs and it is a line item. The signal: tool.call_count for running_instances jumped from 1 to 3. Only visible per-tool, per-agent, and easy to miss precisely because the dollar delta is so small on a single run.

Scenario 3: Context bloat (the expensive one)

The agent drags too much context into its prompts. Every extra token in gets paid for, and it cascades.

CONTEXT BLOAT: ~1.4x baseline ($0.0119 vs $0.0083)
  health_ops input tokens elevated, output nearly 4x (803 vs 199)
  supervisor synthesis cost rises too, bloat cascades

This is the meanest one because it compounds. The sub-agent's bloat feeds a bigger blob to the supervisor, whose own synthesis cost then rises too (on this run the supervisor jumped from $0.0032 to $0.0044). The signal: llm.usage.prompt_tokens and llm.cost.usd per agent. You watch prompt tokens creep up where the work did not.

Same answer, different bill

src/compare.py puts CLEAN next to BLOAT side by side.

	CLEAN	CONTEXT BLOAT
Final answer	Correct	Correct
Crew total cost	$0.0083	$0.0119
Delta	-	+43% (~1.4x)
APM status	200 OK	200 OK

Two runs. Both return the right answer. Both are green in any latency-and-errors dashboard. The only place the extra 43% shows up is in the trace, on the per-agent cost attribute you stamped yourself. In the Traccia dashboard this is the moment the tool earns its place: two runs sit side by side, both "successful," and the per-agent cost column is where the bloated one gives itself away. That is the whole argument for agent-native observability in one table.

The detection logic is not clever. It is a delta check: for each agent, compare this run against the baseline and flag three things. More cycles than baseline means a possible runaway loop. Prompt tokens more than 1.25x baseline means possible context bloat. Any tool called more times than baseline means a possible redundant call. That is the whole detector, about fifteen lines in src/compare.py.

The intelligence is in having the baseline and the per-agent attributes to compare against. The trace is what makes those attributes exist.

This detector broke once during the build, and it is a good example of how instrumentation and detection are coupled. When I switched tools to emit one live span per call (the 0ms fix above), the redundant-call check stopped working, because it had been reading a call_count attribute off a single reconstructed span that no longer existed. I had to change it to count span occurrences per tool name instead. The lesson that stuck: change how you record, and you can silently break how you detect. The baseline caught it, which is the whole point.

Watching it happen: the live control panel

This is the panel you saw in the video above. Traces are the source of truth, but a wall of span JSON is not how you show a crew to a teammate. So the repo ships a small live control panel: a single-page UI that runs the real crew and animates the investigation as it happens.

You type a prompt into a command console, hit Investigate, and the view scrolls down to a graph of the crew. The supervisor sits at the top and the three specialists fan out below it, connected by wires. As the run streams, each agent lights up like a traffic signal: idle, then running (with a live activity line, "Reading Cost Explorer", "Scanning security groups"), then done, and the report reveals at the bottom. Every agent card shows the AWS services it touches as small chips, so a viewer can see at a glance that Cost Analyst reads Cost Explorer and the forecast, Health & Ops reads EC2/EBS/Lambda/S3/CloudWatch, and Security Auditor checks security groups, IAM, S3, and GuardDuty.

The panel has two modes. Live runs the real crew: real Nova Pro calls, real read-only AWS reads, real dollars on the trace, about thirteen seconds. Replay animates a saved run from a committed trace file, deterministically and for free, so you can rehearse the visual as many times as you want without spending a token. Both drive the exact same UI from the same event stream; the only difference is whether the events come from a fresh Bedrock run or a recorded one.

The backend is a small FastAPI app that streams the crew's lifecycle as Server-Sent Events. The important part is that the UI is a thin viewer over the same telemetry the trace records; it is not a second, hand-maintained source of truth. What the graph shows is what the crew did.

Build your own, at zero cost and read only

You do not need a paid plan or a live AWS bill to try this. The whole thing runs locally with the file exporter and read-only AWS credentials.

The permission surface is deliberately small: every action is a Get, List, or Describe, across Cost Explorer, EC2, CloudWatch, S3, Lambda, IAM, and GuardDuty. There is no create, no modify, no delete anywhere in the toolset. The full policy JSON is in the repo README; if you would rather not hand-roll it, AWS's managed SecurityAudit and ViewOnlyAccess policies cover the same set. Attach it, invoke Nova Pro through Strands, and you have a crew that can look but never touch. To send traces to the hosted dashboard, set TRACCIA_API_KEY; leave it unset and everything writes to a local file. Same spans either way.

The read-only shape is the same for every tool: wrap the real boto3 describe/get/list call in a live span so its duration in the trace is the true AWS read time, return the fields you need, touch nothing. src/tools.py in the repo has all seven; they are all this shape.

An honest take on Traccia

I shipped a real crew against this SDK and read its source to understand the behavior, so here is the assessment grounded in that, not in the marketing page.

What is genuinely good:

It is OpenTelemetry-native. Spans, processors, and resource attributes are standard OTel underneath, so the data model is not proprietary and you are not locked in.
It runs at $0 and offline by default. With no API key it writes to a local file exporter; set TRACCIA_API_KEY and the same spans push to the hosted dashboard. Same spans either way, which made local development and CI painless.
It ships more than a tracer. There is a real cost engine with a bundled pricing snapshot (covering Nova and Claude, among others), a staleness warning when that snapshot ages, and auto-instrumentation for LangChain, CrewAI, OpenAI Agents, and the raw OpenAI/Anthropic/Gemini clients. If you are on one of those stacks, a lot of what I wired by hand would have come for free.
The span-level agent identity model is the best part. A span-level agent.id and agent.name override the process default, which is precisely what let a single-process crew render as a four-agent fleet with real per-agent cost. That is a thoughtful design decision, not an accident.

Where it made me work, and where it could be better:

No Strands integration yet, and it does not hook raw Bedrock. For this stack the cost bridge was manual. That is fine and it gives you control, but a Strands integration would remove the single biggest chunk of setup for AWS-native builders.
The cost processor fails silently (at the time of writing). It skips a span with no error if llm.model is missing or span.type is not LLM. That forgiving behavior is defensible, but the silence cost me an afternoon of a zeroed dashboard. A debug log on skip would fix it outright, and it is the kind of small papercut an early-stage tool usually closes fast.
A couple of sharp edges are only discoverable in the source (at the time of writing). span_scope(parent=None) still inherits the current context (so separate agent traces silently merge unless you detach first), and span_scope is not a context manager (you call .end() yourself). Neither is obvious from the docs today.
Documentation is the real gap. I learned the identity precedence, the llm.model requirement, and the context-detach behavior by reading the SDK, not the docs. For a bootstrapped, early-version product that is understandable, and the SDK itself is readable enough that this was possible. But better docs would turn a day of spelunking into an hour.

Net: for supported frameworks you get a lot for free, and even off the beaten path the OTel foundation and the cost/identity model are solid. The capability is there; the polish that is missing is mostly documentation and a few developer-experience papercuts, which is exactly what you would expect from a product at this stage.

Honest caveats

I want to be straight about the limits, because that is the whole point of this article.

I saw versions of the three waste scenarios in real runs first; the src/waste_demo.py versions just make them fire on cue. LLM output is non-deterministic. In real life these patterns appear on their own, just not on a schedule you can demo.
Detection is delta-vs-baseline, not fixed magic thresholds. You need a known-good run to compare against, same as any regression system.
Every dollar is real Nova Pro token usage against verified us-east-1 pricing, but the exact numbers shift run to run. Do not treat any single figure as a constant. Treat the relationship (roughly 1.4x on the worst pattern I measured) as the lesson, not the exact decimals.
Traccia does not auto-instrument Strands or Bedrock. The cost bridge is about 40 lines you write and own. That is a feature: you control exactly what goes on the span.
I model each agent as its own trace, grouped by session.id. That is a deliberate choice to match how a real fleet is owned and operated. If you prefer one nested trace per run, keep the supervisor as the parent instead of detaching the context. Both are valid; pick the one that matches how your team reasons about the system.
The agent is read-only by IAM policy, not by hope.

The takeaway is not "buy an observability tool." It is that a correct-looking answer tells you nothing about whether the run was efficient, and the only place the truth lives is in the trace, on attributes you have to put there on purpose.

FAQ

What is AI agent observability, and how is it different from LLM monitoring?
LLM monitoring usually watches one model call: latency, errors, maybe token count. Agent observability watches a whole reasoning session: how many cycles an agent took, which tools it called, the cost of each step, and, in a multi-agent crew, which agent did what. Agent failures show up across a multi-step chain, not on a single call, so you need the full trace to see them.

How do I track per-agent cost on Amazon Bedrock?
Bedrock returns token usage after each call. You multiply input and output tokens by the model's per-1K price (for Nova Pro in us-east-1, $0.0008 in and $0.0032 out) and attach that dollar figure to the trace span for the agent that made the call. That is the stamp_llm_cost function in this article. AWS's own tag-based cost allocation in Cost Explorer works at the account and tag level; per-agent, per-reasoning-cycle attribution is what the trace adds on top.

Can AWS Cost Explorer show per-agent cost by itself?
Not on its own. Per AWS's Well-Architected Agentic AI Lens, the default state is that costs are visible only at the account level and Cost Explorer cannot separate agents or workflows. Tag-based allocation plus AgentCore Observability improves this, but per-agent and per-reasoning-phase attribution comes from instrumenting the trace, which is what this build does.

Why does my multi-agent app cost more than I expected even when it works?
Because a correct answer is not a cheap answer. Agents can loop an extra reasoning cycle, re-call a tool they already have the answer for, or drag bloated context from step to step. None of that returns an error; it just adds tokens. The overspend shows up on the bill, not in a latency-and-errors dashboard, which is the "silent waste" this article is about.

Do I need a paid tool or an AWS account to try this?
No. The whole build runs at $0 locally: the Traccia SDK writes traces to a local file with no API key, and the AWS reads use read-only credentials (or the committed replay run, which needs no AWS access at all). You only need a Bedrock model grant if you want to run the live crew against your own account.

Is Traccia open source?
The SDK (traccia-py) is open source under Apache-2.0 and built on OpenTelemetry, so the spans are standard OTel and you are not locked in. The hosted dashboard at traccia.ai is the optional commercial part; you only reach for it when you want the visualization.

Does Traccia support AWS Strands Agents out of the box?
Not at the time of writing. It auto-instruments LangChain, CrewAI, and the OpenAI/Anthropic/Gemini clients, but not Strands or raw Bedrock converse, so on this stack you stamp cost onto the span yourself (about 40 lines). On a supported framework, most of that is automatic.

Try it

The full code (crew, tools, waste demos, the live control panel, the compare view, and the double-count probe) is on GitHub: ai-agent-observability-aws. There is also a live replay of a run you can click through in the browser: https://simplynadaf.github.io/ai-agent-observability-aws/. Clone it, run python -m src.waste_demo with local export, and watch a perfect answer cost you ~1.4x. Then go instrument your own agents before your bill does the teaching for you.

To put Traccia under your own agents, the on-ramp is deliberately short and free:

Install the SDK (open source, Apache-2.0): pip install traccia. With no API key it writes traces to a local file, so you can see spans at $0 before you sign up for anything. Source and docs: github.com/traccia-ai/traccia-py.
Stamp cost onto your spans using the ~40-line stamp_llm_cost pattern above (or get it for free if you are on LangChain, CrewAI, or the OpenAI/Anthropic/Gemini clients, which Traccia auto-instruments).
See it in the dashboard when you want the visual per-agent cost and the side-by-side run compare: set TRACCIA_API_KEY and the same spans push to traccia.ai. Same spans either way, so nothing about your instrumentation changes.

If you build something with it, tell me what silent waste you found. That is the interesting part.

I Built an AI Agent That Audits AWS (And It Can't Touch Anything)

Sarvar Nadaf — Fri, 18 Sep 2026 15:12:34 +0000

An AI agent just read my AWS account and told me a bucket was open to the internet, SSH was exposed to 0.0.0.0/0, GuardDuty was off, and I was burning $3.65 a month on an Elastic IP attached to nothing.

It did all of that in about two minutes. And here is the part that counts: it physically could not have changed anything even if it tried.

That last sentence is the whole point of this build. Most "give the AI access to my cloud" ideas die on one fear: what if it deletes something, or a bad prompt tricks it into running a destructive command? We remove that fear at the permission layer, not with a polite instruction. The agent runs on a read-only IAM identity. Every write call it could imagine gets rejected by AWS before it happens.

This is a walkthrough of building that agent from scratch. It is one JSON file and one Markdown checklist. By the end you will have a working AWS auditor you can point at your own account, and you will understand every field that makes it work.

The full code is on GitHub: github.com/simplynadaf/aws-auditor-agent.

Who this is for

You use Kiro Crew or the Amazon Q Developer CLI. You know your way around AWS enough to have an account with a few things running. You have heard "AI agent" a hundred times and you want to see what one is built from, without a framework, without a vector database, without 400 lines of Python.

If you can edit a JSON file and write a checklist in Markdown, you can build this.

What an agent is made of (the 6 pieces)
The safety foundation: read-only IAM
Writing the agent config
The skill: your audit checklist
Wiring the AWS tools with MCP
Running it, and what it produced
Making it yours
Why build this when Prowler and Trusted Advisor exist?
What the docs do not tell you

1. What an agent is made of

Strip away the hype and an agent is one JSON file. The filename minus .json is the agent's name. The file describes a chat session: which model to use, what tools it can call, what it is allowed to do without asking you, what extra powers it plugs in, and what knowledge it carries.

Six pieces. That is the entire mental model.

Piece	Field	Plain meaning
Identity	`name`, `description`	What it is called
The brain	`model`	Which LLM answers
Instructions	`prompt`	Its personality and rules
What it can do	`tools`	The toolbox
What runs without asking	`allowedTools`	Pre-signed permission slips
Extra powers	`mcpServers`	Plug in tool servers
Its knowledge	`resources`	Attach skills and files

The one distinction that trips up every beginner is tools versus allowedTools.

tools answers "what CAN this agent use?" If a tool is not listed, it does not exist for the agent.

allowedTools answers "what runs WITHOUT stopping to ask me?" A tool that is in tools but not in allowedTools still works, it just prompts you for approval each time it fires.

Toolbox versus permission slips. Keep that image and the rest is easy.

2. The safety foundation: read-only IAM

Before any config, we build the guardrail. This step is not optional and it is the reason the whole thing is trustworthy.

We attach two AWS-managed policies to the identity the agent uses:

arn:aws:iam::aws:policy/SecurityAudit
arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

SecurityAudit is the policy AWS designed for exactly this job: reading security-relevant configuration across services. ViewOnlyAccess fills the cost gaps, so the agent can see Elastic IPs, volumes, snapshots, and load balancers.

Underneath, both policies are Get*, List*, and Describe* only. There is no Create, no Delete, no Put, no Modify anywhere in them.

aws iam create-user --user-name aws-auditor

aws iam attach-user-policy --user-name aws-auditor \
  --policy-arn arn:aws:iam::aws:policy/SecurityAudit

aws iam attach-user-policy --user-name aws-auditor \
  --policy-arn arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

aws iam create-access-key --user-name aws-auditor
# then paste the keys into: aws configure --profile aws-auditor

Why go through this instead of just telling the model "please do not change anything"?

Because a prompt is a suggestion and IAM is a wall. If the model hallucinates a fix, IAM blocks it. If someone slips a "now delete that bucket" instruction into a file the agent reads, IAM blocks it. The blast radius is zero by construction. You are separating the act of detecting problems from the act of fixing them, which is a security best practice on its own.

The agent has read-only glasses, not a wrench.

3. Writing the agent config

Here is the complete file. Save it as ~/.kiro/agents/aws-auditor.json.

{
  "$schema": "https://raw.githubusercontent.com/aws/amazon-q-developer-cli/refs/heads/main/schemas/agent-v1.json",
  "name": "aws-auditor",
  "description": "Read-only agent that audits an AWS account for security risks and wasted spend, and reports prioritized, cited findings. Never changes anything.",
  "model": "auto",
  "mcpServers": {
    "security": {
      "command": "uvx",
      "args": ["awslabs.well-architected-security-mcp-server@latest"],
      "env": { "AWS_PROFILE": "default", "AWS_REGION": "us-east-1", "FASTMCP_LOG_LEVEL": "ERROR" }
    },
    "cloudtrail": {
      "command": "uvx",
      "args": ["awslabs.cloudtrail-mcp-server@latest"],
      "env": { "AWS_PROFILE": "default", "AWS_REGION": "us-east-1", "FASTMCP_LOG_LEVEL": "ERROR" }
    },
    "pricing": {
      "command": "uvx",
      "args": ["awslabs.aws-pricing-mcp-server@latest"],
      "env": { "AWS_PROFILE": "default", "AWS_REGION": "us-east-1", "FASTMCP_LOG_LEVEL": "ERROR" }
    },
    "awsdocs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": { "FASTMCP_LOG_LEVEL": "ERROR" }
    }
  },
  "tools": ["fs_read", "use_aws", "@security", "@cloudtrail", "@pricing", "@awsdocs"],
  "allowedTools": ["fs_read", "use_aws", "@security", "@cloudtrail", "@pricing", "@awsdocs"],
  "toolsSettings": {
    "use_aws": {
      "allowedServices": ["iam", "s3", "s3api", "ec2", "rds", "guardduty", "accessanalyzer", "securityhub", "elbv2", "elasticloadbalancing", "cloudwatch", "sts"]
    }
  },
  "resources": ["skill://~/.kiro/skills/aws-audit/SKILL.md"],
  "prompt": "You are AWS Auditor, a read-only cloud security and cost reviewer. You have ONLY read permissions (SecurityAudit + ViewOnlyAccess). You cannot and must not attempt to change anything, and you must not recommend that you run a fix yourself. Run the checks defined in your aws-audit skill using the available tools. Cite ONLY real resources you actually observed in tool output (real IDs, real names). NEVER invent a finding, a resource, or a number. If a check could not run, put it in the Gaps section as 'not verified' rather than implying it passed. Produce the report exactly in the format your skill defines. For every cost finding include an estimated monthly dollar impact computed from real pricing data, and state the assumption you used. Recommend fixes; never run them.",
  "welcomeMessage": "AWS Auditor here (read-only). Point me at a region and I will report what is risky and what is wasteful, with real evidence. I cannot change anything."
}

Walk through the fields that carry weight.

model is set to auto, which lets the CLI pick the model. You can pin one (run /model in a session to see valid IDs) but auto is the sensible default.

prompt is where the honesty rules live. Read it closely. "Cite ONLY real resources you actually observed." "NEVER invent a finding, a resource, or a number." "If a check could not run, put it in the Gaps section as not verified rather than implying it passed." Those three lines are what separate a useful audit from a confident-sounding hallucination.

toolsSettings.use_aws.allowedServices is a second wall on top of IAM. Even though IAM already blocks writes, this restricts the use_aws tool to a specific list of services it can even attempt to call. Two independent limits: the tool can only reach these services, and IAM only permits reads inside them. Defense in depth.

Notice tools and allowedTools are identical here. That means the agent runs the audit end to end without stopping to ask permission for each read. That is a deliberate trade-off: convenience for a demo, and it is safe precisely because every one of those tools is read-only. If you were doing anything with write access, you would keep the risky tools out of allowedTools so they prompt you.

4. The skill: your audit checklist

The agent config is the wiring. The skill is the brain of the audit. It is a plain Markdown file at ~/.kiro/skills/aws-audit/SKILL.md, attached through the resources field, and the agent reads it on every run.

This is the file you will edit most. It holds the checks, the severity model, the framework mapping, and the exact output format.

The security checks, each backed by a specific read-only API:

Check	Read-only API	Severity
Public S3 bucket	`s3:GetPublicAccessBlock`, `s3:GetBucketPolicyStatus`	CRITICAL
Root account MFA off	`iam:GetAccountSummary`	CRITICAL
Security group open to 0.0.0.0/0 on 22 / 3389 / DB	`ec2:DescribeSecurityGroups`	HIGH
Unencrypted EBS or RDS	`ec2:DescribeVolumes`, `rds:DescribeDBInstances`	HIGH
IAM users without MFA	`iam:ListUsers`, `iam:ListMFADevices`	HIGH
GuardDuty disabled	`guardduty:ListDetectors`	HIGH
Access Analyzer disabled	`accessanalyzer:ListAnalyzers`	MEDIUM
Security Hub standards incomplete	`securityhub:GetEnabledStandards`	MEDIUM

The cost checks, each of which must carry a real dollar figure:

Check	Read-only API
Unattached EBS volume	`ec2:DescribeVolumes` (state = available)
Unassociated Elastic IP	`ec2:DescribeAddresses`
Old or orphaned snapshot	`ec2:DescribeSnapshots`
gp2 volume that should be gp3	`ec2:DescribeVolumes` (VolumeType = gp2)
Idle load balancer	`elbv2:DescribeLoadBalancers` plus target health

The skill tells the agent how to think about severity (a traffic-light model), which frameworks to cite (Well-Architected Security Pillar for structure, CIS AWS Foundations Benchmark for authority, Trusted Advisor for the cost category), and the precise report shape: executive summary, a Top 3 list, findings grouped by Security and Cost, passing checks, and an honest gaps section.

One design choice worth calling out. The skill ships with a small "demo scope" block that tells the agent to only report resources tagged demo-auditor=true. That keeps a demo repeatable and stops it from surfacing anything real. To audit your whole account, you delete that one block. That is the entire difference between "show me the demo" and "audit everything."

5. Wiring the AWS tools with MCP

The agent needs eyes. MCP (Model Context Protocol) servers are how it sees AWS. Each server in the mcpServers block is a small program that exposes a set of tools, and you reference all of a server's tools with an @ prefix, like @pricing.

This build uses four:

@security (Well-Architected security MCP): checks GuardDuty, Security Hub, Access Analyzer.
@cloudtrail: queries account activity.
@pricing: pulls live rates from the AWS Price List API, which is how cost findings get real numbers instead of guesses.
@awsdocs: reads AWS documentation when the agent needs to confirm a detail.

They run through uvx, so you need uv installed (pip install uv). The first time you launch the agent, uvx fetches each server. No manual install step, no Docker.

The general-purpose use_aws tool covers everything else with direct read-only API calls. Between use_aws and the four MCP servers, the agent can reach every check in the skill.

6. Running it, and what it produced

Install the two files, then start the agent:

mkdir -p ~/.kiro/skills/aws-audit ~/.kiro/agents
cp skill/SKILL.md ~/.kiro/skills/aws-audit/SKILL.md
cp agent/aws-auditor.json ~/.kiro/agents/aws-auditor.json

kirocrew chat --agent aws-auditor

On the Amazon Q Developer CLI the command is q chat --agent aws-auditor, and you put the agent in ~/.aws/amazonq/cli-agents/ with the resources entry changed from skill:// to a file:// path.

Then ask it plainly:

Audit us-east-1. Actually call the tools and produce the report.

I ran this against five resources I created on purpose to be broken (the repo has a script for that, plus a teardown script that removes 100% of them). Here is the real output, trimmed. Nothing here is edited for effect.

# AWS Audit - us-east-1, 2026-09-02

## Executive summary
Scoped to the 5 resources tagged demo-auditor=true, this audit found 8 findings:
1 CRITICAL, 3 HIGH, 2 MEDIUM, and 3 cost items. The single most urgent problem is a
publicly readable S3 bucket (demo-auditor-public-5403) that lets anyone on the
internet download its objects.

## Top 3 - do these now
1. Public S3 bucket demo-auditor-public-5403 - bucket policy grants s3:GetObject to
   everyone (Principal: *). Enable Public Access Block and remove the public policy.
2. Security group sg-055250cbcc6f3b37b - SSH port 22 is open to 0.0.0.0/0. Restrict
   to a known admin IP or use SSM Session Manager.
3. GuardDuty is disabled in us-east-1 - no threat detection is running.

The cost section is where the pricing MCP earns its place:

### [COST] Unassociated Elastic IP - ~$3.65/month
- Resource: eipalloc-000992c9956cfaaa5 (public IP 35.173.72.149, no association)
- Estimated impact: $0.005/hr (USE1-PublicIPv4:IdleAddress, us-east-1) x 730 hrs
  = $3.65/mo. Assumption: idle for a full month, on-demand.
- Fix: Release the Elastic IP if not needed, or associate it with a running resource.

Every resource ID is real. Every rate came from the live Price List API. The agent computed the numbers, it did not make them up.

The most convincing part was not a finding, though. It was the honesty. Three moments stood out:

The agent found a snapshot created that same day. The checklist looks for "old" snapshots. Instead of forcing it into the finding, the agent flagged it for completeness and refused to call a fresh snapshot old.

Root MFA was on. It reported that as a PASS. A tool that only ever finds problems just confirms its own bias. Reporting passes is how you know it looked.

And the gaps section listed what it did not check and why: IAM per-user MFA, RDS encryption, and idle load balancers were out of scope for the demo, so it said "not verified" rather than implying those passed. "Not verified" is not "passed." That line in the prompt did real work.

The whole run cost a few cents in demo resources and about two minutes of wall time.

7. Making it yours

The SKILL.md file is yours to own. It is a checklist, not code.

Add checks your team cares about. Each row names the read-only API that backs it, so extending it is a matter of adding a row and a line of guidance. Change the severities to match your risk appetite. Rewrite the report format if your manager wants it a certain way. Delete the demo-scope block to audit the entire region.

A few natural next steps once it works:

Point it at more regions. The demo is us-east-1 only. Loop the region in the prompt or run it per region.

Schedule it. A read-only agent that runs every morning and mails you a diff of new findings is a genuinely useful thing, and it cannot break anything overnight because it cannot write.

Widen the checklist toward a framework you report against, like the full CIS benchmark, one row at a time.

Why build this when Prowler and Trusted Advisor exist?

Fair question. There are mature tools in this space, and you should know when to reach for them instead.

Prowler is the heavyweight: 600+ checks, mapped to CIS, PCI, HIPAA, and more. If you need exhaustive compliance coverage for an audit, use Prowler. The trade-off is that 600 findings with no narrative is a wall of text. It tells you everything and prioritizes nothing.

ScoutSuite is read-only like our agent and produces a nice HTML report. It is excellent for a point-in-time config review. It does no cost analysis and it is static, not conversational. You cannot ask it a follow-up.

Trusted Advisor has the best native cost checks (idle load balancers, unassociated Elastic IPs, underutilized EBS). The catch: the full cost category requires a Business or Enterprise Support plan (AWS docs). On a Basic plan you do not get them, which is exactly why an agent computing the same things from raw Describe calls is useful to a beginner.

Security Hub is the central dashboard, but it must be configured. Our demo run caught the trap live: the standards were subscribed but reported NO_AVAILABLE_CONFIGURATION_RECORDER. Without an AWS Config recorder, most controls cannot evaluate (AWS docs). The dashboard was on, the checks were off. A human skims a green dashboard and moves on. The agent read the actual status and flagged it.

So here is the decision framework:

Reach for	When
Prowler	You need exhaustive, framework-mapped compliance evidence for an audit
ScoutSuite	You want a thorough static config snapshot, security only
Trusted Advisor	You are on Business/Enterprise Support and want native cost checks
This agent	You want security AND cost in one plain-language, prioritized report you can converse with, on any support plan, provably read-only

The edge of the custom agent is not raw coverage. It is clarity, ruthless prioritization (a Top 3, not 600 rows), security and cost in one voice, detecting the "configured but inert" trap, and a provable read-only guarantee you can hand to a nervous manager.

When NOT to use it: if you need certified compliance evidence, if you want continuous automated remediation (this agent only reads), or if your org already runs Prowler in CI and just needs the raw findings. This is a fast, human-friendly first look, not a compliance system of record.

What the docs do not tell you

Four things I hit building this that are not in any single doc:

The use_aws service allowlist is a real second wall, and it is easy to forget s3api. S3 read calls split between s3 and s3api depending on the operation. Leave s3api out of allowedServices and the public-bucket check silently cannot run. Both belong in the list.

"Not verified" has to be forced in the prompt or the model will paper over gaps. Without the explicit "put it in the Gaps section as not verified" instruction, models tend to imply a skipped check passed. That single sentence changed the behavior in testing.

Idle Elastic IP pricing hides behind a specific usage type. The rate is not under a generic "EIP" filter. It is USE1-PublicIPv4:IdleAddress in us-east-1 (since the Feb 2024 public IPv4 charge). If your cost math comes back empty, you are querying the wrong usage type.

Clean up your demo resources. If you use the demo scripts, the teardown deletes by recorded ID and then sweeps by tag, in this order: snapshot, Elastic IP, volume, security group, bucket. Run it right after, or you keep paying the few cents a month the audit just flagged. The irony writes itself.

The takeaway

An agent is not a mystery. It is a JSON file that names a model, lists some tools, plugs in a few MCP servers, and points at a Markdown checklist. The engineering that makes it trustworthy is not in the model at all. It is in the IAM boundary that makes destructive action impossible, and in a prompt that forbids inventing anything.

Build the guardrail first. Then the agent can be as capable as you like, because the worst it can do is tell you the truth about your account.

Grab the two files, attach the two read-only policies, and run it against your own account: github.com/simplynadaf/aws-auditor-agent.

What would you add to the checklist first, security or cost? I am curious which one bites people more in practice.

AI Agent vs Agentic AI: The Distinction That Changes Your Architecture

Sarvar Nadaf — Fri, 11 Sep 2026 12:59:53 +0000

I was on a call last month where a VP said "we're deploying agentic AI" and what they actually had was a single chatbot connected to a database. That's an agent. A good one, maybe. But calling it "agentic AI" is like calling a single REST endpoint "a microservices architecture." That confusion cost them three months and a budget overrun before anyone caught it.

An AI agent is a thing you build. Agentic AI is how you wire many of those things together. One is a worker. The other is the factory floor.

If you missed Part 1 (AI Assistance vs AI Agents), go read that first. It sets the foundation for what we're covering today.

Why this confusion is dangerous
AI agents: the specialist worker
Agentic AI: the system architecture
The quick comparison
When agentic AI goes wrong
The governance gap nobody talks about
Real-world examples: AWS and beyond
When to use each
The bottom line

Why this confusion is dangerous

You buy an agent when you need a system. A vendor shows a slick demo: one agent handling one task beautifully. You deploy it expecting end-to-end workflow automation. Three months later, you're wondering why it can't handle anything beyond that one task.

You over-engineer when you just need an agent. I've seen teams spend months building multi-agent orchestration for what was essentially a ticket-routing problem. A single well-configured agent would've shipped in a week.

You skip governance entirely. Deploy a fleet of agents with no coordination layer, no monitoring, no human oversight. I've watched that go sideways at 2 AM.

The VP on that call? Their "agentic AI" couldn't even hand off context between conversations. It reset every session. That's a stateless function with a chat interface.

AI agents: the specialist worker

An AI agent is a piece of software that does a specific job on its own. It perceives, decides, uses tools, and takes action within clear boundaries for a defined task. One contractor, one job. They show up, do the thing, leave.

What separates an agent from a fancy API call:

Decides how to approach the task (not just following a script)
Can call tools: APIs, databases, search, code execution
Works autonomously until it hits a "done" state
Has guardrails but makes choices within them

You: "Summarize the latest security findings for my AWS account."

AI Agent: *connects to AWS Security Hub*
          *retrieves findings*
          *categorizes by severity*
          *generates summary*

"Here are your findings:
- 3 Critical: Unencrypted S3 buckets (bucket-a, bucket-b, bucket-c)
- 7 High: Security groups with open ports
- 12 Medium: IAM users without MFA

Would you like me to generate remediation steps?"

One agent. One job. Done well.

Agentic AI: the system architecture

Agentic AI isn't a single agent. It's the design approach for building systems where multiple agents work together with planning, coordination, evaluation, and governance layered on top.

If an AI agent is one contractor, agentic AI is the general contractor running the entire construction site: scheduling the specialists, checking their work, handling exceptions, making sure the building doesn't fall down.

What makes it agentic (not just "multiple agents"):

A planning layer that breaks goals into steps
An orchestrator that sequences and delegates
Evaluators that check whether output is actually good
Memory that persists across runs
Policy enforcement and human-in-the-loop checkpoints
Self-correction when things go sideways

┌─────────────────────────────────────────────┐
│              AGENTIC AI SYSTEM               │
├─────────────────────────────────────────────┤
│                                             │
│  ┌─────────────┐    ┌──────────────────┐   │
│  │   Planner   │───▶│   Orchestrator   │   │
│  └─────────────┘    └──────────────────┘   │
│                            │                │
│         ┌──────────────────┼────────┐       │
│         ▼                  ▼        ▼       │
│  ┌────────────┐  ┌────────────┐ ┌───────┐  │
│  │  Agent A   │  │  Agent B   │ │Agent C│  │
│  │(Research)  │  │(Analysis)  │ │(Write)│  │
│  └────────────┘  └────────────┘ └───────┘  │
│         │                  │        │       │
│         └──────────────────┼────────┘       │
│                            ▼                │
│                   ┌──────────────┐          │
│                   │  Evaluator   │          │
│                   └──────────────┘          │
│                            │                │
│                   ┌──────────────┐          │
│                   │   Memory &   │          │
│                   │  Governance  │          │
│                   └──────────────┘          │
│                                             │
└─────────────────────────────────────────────┘

Real-world example: Incident Response System

I helped architect this for a financial services client. Before the agentic system, their mean-time-to-resolution for P1 incidents was 47 minutes. After: 11 minutes. The system paid for itself in the first month from reduced downtime costs alone.

You: "Handle the production incident on the payments service."

Agentic AI System:

  Planner: "This needs investigation, diagnosis, action, 
            and communication."

  Agent 1 (Monitor): *checks metrics, spots CPU spike at 2:03 AM*
  Agent 2 (Logs):    *analyzes logs... initially flags DB connection 
                      issue, evaluator finds low confidence*
  Agent 2 (retry):   *digs deeper, finds memory leak in v2.3.1*
  Agent 3 (Git):     *identifies the commit that introduced it*

  Evaluator: "Root cause confirmed: memory leak in commit abc123. 
              Recommending rollback."

  Orchestrator: "Rollback is destructive. Paging human."

  [Human approves]

  Agent 4 (Deploy): *rolls back to v2.3.0*
  Agent 5 (Verify): *confirms service restored*
  Agent 6 (Comms):  *posts to Slack, creates JIRA ticket, 
                     updates status page*

  Memory: *stores pattern for faster detection next time*

Agent 2 got it wrong the first time. The evaluator caught it. The system self-corrected. That's the difference between a collection of agents and an agentic system.

Think of it like Uber. You request a ride to the airport, flight in 90 minutes. Driver cancels 2 minutes later. A single agent just says "finding new driver..." and makes you wait. An agentic system? It widens the search radius, filters for high-completion drivers, calculates you'll still make your flight, texts you proactively, applies a discount for the inconvenience, flags the cancelling driver's pattern, and remembers to prioritize reliable drivers for your airport rides next time. Six agents coordinating. Context flowing between them. That's the gap.

The quick comparison

Dimension	AI Agent	Agentic AI
What it is	A software component	A system design paradigm
Scope	Single task	Multi-step, multi-agent orchestration
Analogy	One specialist employee	The entire organization
Memory	Often resets after each task	Persistent across interactions
Coordination	Works alone	Multiple agents collaborating
Quality control	Limited self-checking	Built-in evaluators and critics
Governance	Basic guardrails	Policy enforcement, audit trails
Cost	Low: single model + tools	Higher: orchestration overhead
Complexity	Low to medium	High
Time to value	Days to weeks	Weeks to months

Most of my clients are somewhere in between. They have 3-4 agents running independently with no coordination layer. Just agents in a room with no manager. That's where most companies are stuck in mid-2026.

The simplest analogy:

AI Agent = A single microservice. Does one thing well.

Agentic AI = A microservices architecture. The service mesh, orchestration, observability, and resilience patterns that make dozens of services work together.

Nobody calls a single Lambda function "a serverless architecture." Same logic.

When agentic AI goes wrong

Agentic systems fail in ways that single agents don't. I've seen all of these in production:

Agent conflict. Two agents fighting each other for 20 minutes. One scaling up EC2 instances for a traffic spike, the other scaling them down because cost threshold was breached. Back and forth. We burned $600 in compute before someone killed the loop at 2 AM.

Infinite loops. Agent A writes a draft. Agent B reviews it, rejects. Repeat 47 times. $180 for what should have been a $2 task. Nobody set a max iteration limit.

Cascading failures. One agent failed silently, returned partial results. Every agent downstream built on garbage data. Final output looked confident and was completely wrong. Six hours before anyone noticed.

How to prevent this:

Hard iteration limits and timeouts (we use max 5 retries, 120s timeout per agent)
Budget caps per workflow (kill it if it exceeds $X)
Clear priority rules when agents conflict (cost vs availability: which wins? Decide upfront)
Circuit breakers: if an agent fails, stop the pipeline, don't feed garbage downstream
Observability at every handoff (we log every inter-agent message with correlation IDs)

Skip these in a demo. Never in production.

The governance gap nobody talks about

With a single agent, governance is simple: guardrails on access, actions, and data. Configure once.

With an agentic system, governance becomes distributed. And this is where I see teams get burned:

Data boundaries. Agent A sees customer PII for ticket resolution. Agent B handles analytics, should never see PII. If the orchestrator passes context without filtering, compliance violation. Saw this at a healthcare client. HIPAA auditor caught it before production. Fix took two weeks of re-architecting the context-passing layer.

Approval chains. The combination of actions might need approval even if individual ones don't. Agent 1 finds vulnerability + Agent 2 auto-patches + Agent 3 deploys to production = nobody approved a production deployment. Each agent followed its own rules. The system violated yours.

Audit trails. Regulators want to know which component made which decision, what data informed it, who approved. Multi-agent systems need per-agent logging with correlation IDs across the entire workflow. Retrofitting this is painful. Ask me how I know.

Cost governance. Agentic systems spawn sub-tasks, retry loops, parallel workflows that compound. I've seen a $2 expected workflow cost $200 because three agents kept spawning sub-agents to "be thorough." You need budget enforcement at the orchestrator level, not per-agent.

In regulated industries (finance, healthcare, government), the governance architecture might take longer to design than the agents themselves. That's normal. That's also why most "agentic AI" demos fall apart when compliance asks questions.

Real-world examples: AWS and beyond

Single Agent: Amazon Bedrock Agent

Configure one agent with a foundation model, action groups, knowledge base, and guardrails. It handles one task: answering questions, processing orders, analyzing documents. Quick to deploy, clear boundaries, predictable costs.

Multi-Agent: Amazon Bedrock Multi-Agent Collaboration

Orchestrate multiple agents with a supervisor that plans and delegates, specialized sub-agents, shared memory, evaluation logic, and human approval workflows via Step Functions.

My framework recommendation (opinionated)

I've used four frameworks across client engagements this year. Here's my honest take:

Amazon Bedrock + AWS AgentCore is my default for enterprise clients. Not because it's the most elegant API (it's not), but because IAM boundaries, VPC isolation, CloudWatch observability, and compliance controls come out of the box. When a CISO asks "where does my data go?" I have an answer. With other frameworks, I'm building that answer from scratch.

For prototyping and proving a concept fast, LangGraph gets you there quickest if your team already knows LangChain. But I've debugged graph state issues at 2 AM twice now. Production-hardening it takes real effort.

The framework matters less than the architecture. Planning, evaluation, governance, memory, and human-in-the-loop: get those right and you can swap the underlying framework later. Get those wrong and no framework saves you.

When to use each

Single AI agent when: Task is bounded. One model plus tools handles it start to finish. You want it deployed this week. Think: chatbot, code reviewer, data extractor, alert responder.

Agentic AI when: Workflow crosses domains. Multiple specialists must coordinate. You need planning, self-evaluation, and adaptation. Governance matters. Think: incident response, claims processing, research pipelines, end-to-end DevOps automation.

The honest answer for 80% of teams I talk to: Start with a single agent. A well-built agent delivering value today beats a half-built agentic system delivering nothing for six months.

The maturity spectrum

Stage 1: Single AI Agent
         → Deploy in days. Immediate ROI on one task.

Stage 2: Multiple Independent Agents  
         → Each agent owns a domain. No coordination between them.
         → (Most companies are HERE in mid-2026)

Stage 3: Coordinated Multi-Agent System
         → Shared context, handoffs, basic orchestration.
         → Where the ROI multiplier kicks in.

Stage 4: Full Agentic AI
         → Planning, evaluation, governance, memory, self-correction.
         → 47-min incident resolution → 11-min. That kind of impact.

The jump from Stage 2 to 3 is where I spend most of my consulting time. It's not a technology problem. It's a "who owns the orchestration layer" problem. That's an org chart conversation, not a code review.

The bottom line

AI Agent = A component. One autonomous piece of software that gets a specific job done.

Agentic AI = An architecture. The system that plans, coordinates, evaluates, and governs multiple agents working together.

They're not competing. They're layers. You build agents; you architect agentic systems. The agents live inside the architecture.

The progression from Part 1:

AI Assistant  →  Tells you what to do (responds)
AI Agent      →  Does it for you (executes a task)
Agentic AI    →  Orchestrates multiple agents to achieve complex goals

The real question isn't "which one should I use?" It's: "Do I need one specialist, or a team of specialists with a manager?"

Not sure? Start with an agent. Prove value. Then evolve when the single agent hits a wall. You'll know because someone will say "can it also do X, Y, and Z while considering W?" That's your signal.

Check Part 3: Build Your First AI Agent in 30 Minutes - CrewAI + AWS Bedrock. Hands-on, full code, deploy in 30 minutes.

What stage is your company at right now? Stage 1, 2, 3, or 4? And what's the blocker keeping you from the next one? Drop it in the comments.

If this helped, a ❤️ or 🦄 helps other devs find it too. Follow me for more on AWS architecture, FinOps, and AI infrastructure.

How I Built an AI Agent That Cut My AWS Bill by 40% (CrewAI + Bedrock)

Sarvar Nadaf — Wed, 09 Sep 2026 13:09:58 +0000

Last week my AWS bill hit $300. I knew there was waste hiding somewhere. Forgotten EBS volumes, idle Elastic IPs, snapshots from six months ago that nobody remembered creating.

I could open Cost Explorer. Click through dashboards. Manually cross-reference resources.

Or I could let three AI agents do it in 60 seconds.

I built a multi-agent system with CrewAI and Amazon Bedrock that scans everything, identifies waste, and writes a prioritized report with exact dollar savings. It found $125/month I was burning for nothing.

Who This Is For

You run workloads on AWS. Your bill has crept up. You suspect there's waste but don't have time to audit every resource manually. You have 10+ resources running and haven't done a proper audit in 3 months. You want something that scans your account and tells you exactly what to delete, release, or downsize, with dollar amounts attached.

When this won't help: If your account has fewer than 5 resources or you're still in free tier, the overhead of setting this up isn't worth it. Just check Cost Explorer manually.

The Architecture
Why Not Just Use Trusted Advisor?
Why CrewAI + Bedrock
The Custom Tool
Running It
What It Found
Gotchas You'll Hit
Web UI (Bonus)
Key Lessons
Cleanup

The Architecture

Three agents, one pipeline:

Scanner → Optimizer → Report Writer
   ↓           ↓             ↓
AWS APIs    Reasoning    Executive Report

Each agent has a single job.

Agent 1: Cost Intelligence Analyst scans your account using boto3. EC2 instances, EBS volumes, Elastic IPs, snapshots, S3 buckets, and Cost Explorer data. Raw facts with exact numbers.

Agent 2: Optimization Strategist takes the scan results and identifies savings. Orphaned volumes that can be deleted. Unattached IPs burning $3.60/month each. gp2 volumes that should be gp3. Reserved Instance candidates running 24/7 on On-Demand.

Agent 3: Executive Report Writer produces a markdown report with prioritized actions, dollar amounts, and risk levels. The kind of thing you can hand to a CTO.

The pipeline runs sequentially. Each agent passes context to the next through CrewAI's task handoff.

Why Not Just Use Trusted Advisor?

Fair question. AWS already has cost tools. Here's why they weren't enough for me:

Tool	Limitation
Trusted Advisor (free tier)	Only 7 checks. Misses orphaned volumes, old snapshots, gp2→gp3 opportunities
Compute Optimizer	EC2 and Lambda only. No EBS, no EIPs, no S3 lifecycle gaps
Cost Explorer	Shows WHAT you spent, not WHAT TO DO about it
Infracost	Terraform-only. Useless if you clicked things in the console

The multi-agent approach covers all of these in one pass AND produces an actionable report with prioritized fixes. You get "delete vol-0abc123 to save $20/month" instead of a dashboard you have to interpret yourself.

Plus it runs on YOUR schedule. Cron it weekly. Get a fresh report every Monday morning.

Why CrewAI + Bedrock

I tried a single-prompt approach first. One giant prompt asking the LLM to scan AND analyze AND write a report. The results were mediocre. The model tried to do everything and did nothing well. It hallucinated resource IDs that didn't exist because it was juggling too many concerns at once.

Multi-agent fixes this. Each agent has a focused role, a specific backstory, and constrained output expectations. The scanner doesn't try to optimize. The optimizer doesn't write pretty reports.

Amazon Bedrock Nova Pro handles the reasoning. On EC2, the IAM role handles auth automatically. No API keys to manage:

from crewai import LLM

llm = LLM(
    model="bedrock/amazon.nova-pro-v1:0",
    temperature=0.2,
)

Cost per run: about $0.01. The savings it finds will be 100-1000x that.

The Custom Tool: Scanning AWS

CrewAI agents need tools to interact with the world. I built one custom tool that wraps boto3:

from crewai.tools import BaseTool

class AWSCostScannerTool(BaseTool):
    name: str = "AWS Cost Scanner"
    description: str = (
        "Scans your AWS account for running resources and costs."
    )

    def _run(self, scan_type: str = "all") -> str:
        results = {}
        results["ec2_instances"] = self._scan_ec2()
        results["ebs_volumes"] = self._scan_ebs()
        results["elastic_ips"] = self._scan_eips()
        results["ebs_snapshots"] = self._scan_snapshots()
        results["s3_buckets"] = self._scan_s3()
        results["cost_data"] = self._scan_costs()
        return json.dumps(results, indent=2, default=str)

Each _scan_* method is a simple boto3 call. For example, _scan_ebs() runs ec2.describe_volumes() and flags any volume where Attachments is empty. That's an orphan. The scanner doesn't decide what to do about it. It just reports: "vol-0abc123, 20GB gp2, unattached, $2.00/month."

The optimizer doesn't need tools. It's pure reasoning. Takes the scan output and applies FinOps logic: "This volume has no attachments, it's orphaned, that's $20/month wasted."

Running It

git clone https://github.com/SimplyNadaf/crewai-aws-cost-optimizer-ai-agent.git
cd crewai-aws-cost-optimizer-ai-agent
pip3.11 install -r requirements.txt
export AWS_DEFAULT_REGION=us-east-1
python3.11 main.py

You'll see each agent working in sequence. The scanner calls AWS APIs, the optimizer reasons about the results, the report writer formats the final output.

Total time: under 60 seconds for a typical account.

What It Found on My Account

Three orphaned EBS volumes: $33/month. Two unattached Elastic IPs: $7.20/month. A running t3.medium that should be reserved: $82/month in potential savings. Two snapshots from January that nobody needed anymore.

Here's a trimmed version of the actual report output:

╭────────────────── 📊 Cost Optimization Report ──────────────╮
│                                                              │
│  Executive Summary                                           │
│  Current spend: $300/mo → Savings: $125/mo (41.7%)          │
│                                                              │
│  Top Savings Opportunities                                   │
│                                                              │
│   Priority  Resource             Action           Savings    │
│   ─────────────────────────────────────────────────────────  │
│   1         Orphaned EBS (×3)    Delete volumes   $33.00     │
│   2         Elastic IPs (×2)     Release          $7.20      │
│   3         EC2 i-0f7b...        Reserved (1yr)   $82.00     │
│   4         EBS vol-02b...       gp2 → gp3        $3.00      │
│                                                              │
│  Quick Wins (zero risk)                                      │
│   • Delete 3 orphaned EBS volumes → save $33/month           │
│   • Release 2 unused Elastic IPs → save $7.20/month         │
│                                                              │
╰──────────────────────────────────────────────────────────────╯

The quick wins (deleting orphaned volumes, releasing unused IPs) took five minutes to act on. $40/month saved before lunch.

Gotchas You'll Hit

Saved you the debugging time:

Python version matters. CrewAI requires 3.11+. If you're on Amazon Linux 2023, use python3.11 and pip3.11 explicitly. The default python3 is 3.9 and will throw ModuleNotFoundError.

Enable Nova Pro in Bedrock Console first. Go to Bedrock > Model access > Request access for Amazon Nova Pro. Takes 1-2 minutes to approve. Without this you'll get AccessDeniedException: You don't have access to the model.

Cost Explorer needs 24 hours. If you've never used Cost Explorer before, AWS needs ~24h to start collecting data. First run might return empty cost breakdowns. The agents still find orphaned resources, just no historical spend data.

Set the region as an env var, not just config. CrewAI reads AWS_DEFAULT_REGION from the environment, not from ~/.aws/config. Always export it explicitly or the boto3 calls will fail with NoRegionError.

The Web UI (Bonus)

I also built a Streamlit dashboard that wraps the same agents. One-click scan, visual findings, and remediation buttons that delete the orphaned resources for you.

But the CLI version is the core. No web server needed. SSH into any EC2 instance, clone, run, done.

Key Lessons

Separate scanning from reasoning. Agents with tools should gather data. Agents without tools should think. My first version had one agent doing both. It mixed up resource IDs, merged findings from different services, and produced a report with numbers that didn't add up.

Temperature 0.2 for cost analysis. I tried 0.7 first. The optimizer started "suggesting" resources that might exist and estimating savings based on vibes. At 0.2 it sticks to the facts the scanner reported. Nothing invented.

IAM roles over API keys. On EC2, there's zero credential management. The boto3 client picks up the instance role automatically. One less thing to configure, one less secret to leak. I've seen three repos on GitHub with AWS keys in their .env files pushed by accident. Don't be that person.

CrewAI's sequential process fits pipelines. When agents need each other's output, sequential beats hierarchical. Each task's output becomes the next task's context. Parallel would make sense if the agents were independent, but ours depend on each other's findings.

Cleanup

If you created demo resources for testing, remove them:

# Delete orphaned volumes the agents found
aws ec2 delete-volume --volume-id vol-xxx --region us-east-1

# Release unused Elastic IPs
aws ec2 release-address --allocation-id eipalloc-xxx --region us-east-1

# Or use the included cleanup script
bash scripts/cleanup-demo-resources.sh

⚠️ The demo script (scripts/create-demo-resources.sh) creates ~$40/month in dummy resources for testing. Always run cleanup after.

Try It

simplynadaf / crewai-aws-cost-optimizer-ai-agent

3 AI agents analyze your AWS account and find cost savings — powered by CrewAI + Amazon Bedrock

💰 AWS Cost Optimizer Crew

3 AI agents scan your AWS account, find waste, and produce an executive savings report - in under 60 seconds.

⭐ If this helped you, give it a star! It helps others find it.

Video Tutorial • Getting Started • How It Works • Demo • Contributing

🎬 Video Tutorial

Watch the full demo - from zero to finding $125/month in AWS waste:

▶️ Watch on YouTube: I Built an AI That Finds Hidden AWS Costs (It Found $125 in 60 Seconds)

In the video you'll see:

Browsing the source code and architecture on GitHub
Live deployment on an EC2 instance (Amazon Linux 2023)
All 3 agents working in real-time (Scanner → Optimizer → Report Writer)
Streamlit web dashboard with one-click remediation

🤔 The Problem

Your AWS bill keeps climbing. Resources get created and forgotten - orphaned EBS volumes, unattached Elastic IPs, old snapshots nobody…

View on GitHub

Two minutes to set up. A penny to run. Might save you hundreds.

What's eating YOUR AWS budget? Have you tried multi-agent approaches for infrastructure tasks? Drop your experience below.

ReachAloud: I built a multilingual voice tool that reads emergency alerts aloud for people who can't read the screen

Sarvar Nadaf — Mon, 07 Sep 2026 05:37:57 +0000

This is a submission for Weekend Challenge: Generosity Edition

What I Built

ReachAloud is a multilingual text-to-speech accessibility tool for nonprofits and communities. It turns a written emergency alert into clear, natural, spoken audio in any language, for the people that text-only alerts leave behind: those who can't read, can't see the screen, or don't speak the local language.

I want to be honest about the scope. ReachAloud is not an early-warning system. It does not detect floods, send alerts, or replace official channels. It is the last-mile comprehension layer. The warning already exists as an SMS, a banner, a siren. ReachAloud makes that warning understandable to everyone it reaches.

That distinction came from thinking about one event. In August 2026, more than 1,200 people were lost in the Nepal-Tibet floods, a wall of water that arrived with almost no usable warning. When a warning does go out, it usually goes out as text. But a written alert only helps the people who can read it, on a screen they can see, in a language they know. In a real crowd (an elderly villager, someone who is blind, a trekker who doesn't speak Nepali) the alert that could save a life arrives in a form they cannot use. ReachAloud is dedicated to those victims, and the site carries that dedication too. It exists so the next warning reaches everyone, in a voice they understand.

Here is what it does:

Speaks any alert in any language. One ElevenLabs multilingual model reads whatever text you type, in whatever language it is written.
Emergency broadcast mode. A full-screen, high-contrast takeover plays the alert aloud and cycles a giant caption through every language. Voice for people who can't read the screen. Huge text for people who can't hear it.
Play in every language back-to-back, for mixed crowds where locals and visitors need the same warning in turn.
Works offline. Once the page has loaded, a service worker keeps the alerts playing even when the network is down. That is exactly when a flood kills connectivity.
Download and share each alert as an MP3, for a WhatsApp group, a loudspeaker, or a printed QR poster at a trailhead.

Demo

Live: simplynadaf.github.io/reachaloud

No sign-up needed. Six pre-generated flood alerts (English, Nepali, Marathi, Hindi, Arabic, Chinese) play instantly with zero API calls. To hear your own text spoken, click Hear it now and paste a free ElevenLabs key.

Code

simplynadaf / reachaloud

Multilingual text-to-speech accessibility tool that turns emergency alerts into natural voice in any language. Built with ElevenLabs.

🔊 ReachAloud

Emergency alerts, spoken aloud in every language

The last-mile comprehension layer for emergency alerts. ReachAloud turns a written warning into clear, natural, offline-capable spoken audio in any language, for the people that text-only alerts leave behind: low-literacy, low-vision, and non-native readers.

▶️ Watch the 2-minute demo

Why this exists

When a flash flood hits, the warning goes out as text: an SMS, a banner, a push notification. But a written alert only helps the people who can read it, on a screen they can see, in a language they know. In a mixed, high-stress crowd (elderly villagers, someone who is blind, a trekker who does not speak the local language) the alert that could save a life arrives in a form they cannot use.

ReachAloud is dedicated to the more than 1,200 people lost in the 2026 Nepal-Tibet floods It does not detect disasters or send warnings.…

View on GitHub

The whole app is a single index.html (Tailwind + GSAP, no build step) plus a small serverless function and the pre-generated audio. Everything is MIT licensed.

How I Built It

The design goal was a demo that is impossible to break in front of a judge. It had to work with no API key and no network, while still proving live ElevenLabs voice on demand. That led to a two-mode architecture.

ElevenLabs is the load-bearing core

The whole product is the voice. For someone who can't read the screen, the audio is the deliverable, so the TTS can't be a nice-to-have bolted on the side. I used the eleven_multilingual_v2 model for one specific reason: it auto-detects the language of the text you give it. So the same code path speaks English, Nepali, Marathi, Hindi, Arabic, and Chinese with no per-language branching. You type the alert, ElevenLabs figures out the language, and the same reassuring voice reads it.

I picked a calm, default premade voice (Sarah) on purpose. In an emergency, panic in the delivery makes things worse. A steady voice is part of the accessibility.

Mode 1: pre-generated static clips (judge-proof)

I wrote a small Python script (scripts/generate_demo.py) that renders one flood-evacuation alert into all six languages once, then saves them as static MP3s plus a manifest.json the frontend reads. The whole six-language set costs about 670 characters of the monthly free quota. Generated once, then served forever with zero API calls.

MODEL_ID = "eleven_multilingual_v2"   # auto-detects the language of the text
VOICE_ID = "EXAVITQu4vr4xnSDxMaL"     # Sarah: reassuring, free-tier friendly

def tts(text):
    payload = {
        "text": text,
        "model_id": MODEL_ID,
        "voice_settings": {"stability": 0.5, "similarity_boost": 0.75},
    }
    req = urllib.request.Request(
        f"{BASE}/text-to-speech/{VOICE_ID}",
        data=json.dumps(payload).encode(),
        headers={"xi-api-key": API_KEY, "Content-Type": "application/json"},
        method="POST",
    )
    with urllib.request.urlopen(req, timeout=60) as resp:
        return resp.read()

This is what GitHub Pages serves. It works offline, needs no account, and never touches a quota.

Mode 2: live TTS with no backend at all

I wanted people to hear their own alert live, but GitHub Pages has no server to hide a key behind. So the Hear it now flow calls api.elevenlabs.io directly from the browser using a key the user pastes. The key lives only in localStorage (opt-in checkbox) and is sent only to ElevenLabs, never to me, because there is no "me" server in this path. The modal shows the free-tier facts (10,000 characters a month, no card) and links straight to the key page, so anyone can try it in under a minute.

There is also an optional Vercel proxy (api/speak.js) for anyone who would rather keep a shared key server-side. Both paths hit the same model.

The accessibility work is the interesting part

The emergency broadcast was the piece I cared most about getting right, because it has to serve two opposite disabilities at once:

People who can't see the screen get the alert as loud spoken voice, looping through every language.
People who can't hear get a giant, high-contrast caption that cycles in sync with the audio.

Getting it safe took work. It never auto-plays, because an unexpected siren is its own hazard. It reuses a single Web Audio context for the attention chime, since creating one per click hits the browser's context limit and throws. The loop is capped at three cycles so it always ends on its own. And it is dismissable three ways: a Stop button, the Escape key, or a click on the backdrop. Everything respects prefers-reduced-motion, focus is trapped and restored, and the dialogs use proper role="dialog" and aria-live semantics.

Offline, because that's when it matters

A flood is exactly when connectivity dies. A service worker pre-caches the app shell and all six clips, then serves them cache-first, so after one visit the alerts still play with no internet. One honest limitation: the CDN-loaded fonts and CSS do not cache, so styling degrades offline. The core alert audio, the part that saves someone, still plays.

Prize Categories

Best Use of ElevenLabs.

The voice is not a feature of ReachAloud. It is the whole product. The eleven_multilingual_v2 model is what lets one alert reach a low-literacy elder, a blind neighbor, and a foreign trekker in their own language, from the same box of text. I used it three ways: pre-rendered static clips for a bulletproof offline demo, direct browser-to-ElevenLabs calls for live bring-your-own-key TTS, and an optional server-side proxy. All of it on the free tier.

In memory of the victims of the August 2026 Nepal-Tibet floods.

My Dev.to CLI Got Its First Community PR. Image Uploads From Terminal.

Sarvar Nadaf — Thu, 03 Sep 2026 11:36:02 +0000

Three weeks after launching devpub, I got a notification I wasn't expecting: a pull request from someone I'd never talked to.

Harish / @harishteens had forked the repo, read the issues, picked one that I'd been putting off for weeks, and built a complete solution. Tests included. Design decisions documented. Edge cases handled.

The feature? devpub upload. The one command that should have existed from day one but couldn't, because the Forem API literally doesn't support it.

pip install devpub==0.3.0
devpub upload cover.png

That one command now gives you this:

  Uploaded: cover.png

              Uploaded Images
┏━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ File         ┃ URL                                       ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ cover.png    │ https://dev-to-uploads.s3.amazonaws.com/… │
└──────────────┴──────────────────────────────────────────┘

No more opening dev.to/new in the browser just to drag an image and copy the URL.

The problem
How devpub upload works
The authentication problem
What Harish built
Try it
What's next

The problem: no image endpoint in the API

When I launched devpub in v0.1, the goal was to replace the Dev.to web editor entirely. Write locally, push with one command, track analytics. Done.

But there was a gap. Every time I wrote an article with diagrams or a cover image, I had to:

Open dev.to/new in the browser
Click the image upload button
Select the file
Wait for upload
Copy the URL
Paste it into my local markdown
Close the tab

Seven steps for something that should be devpub upload figure.png.

The reason I hadn't built this: the Forem API V1 has no image upload endpoint. It doesn't exist. You can set cover_image in article frontmatter, but only to a URL that already exists somewhere. The API cannot create that URL.

I filed issue #11 with a note saying "this requires reverse-engineering the web editor's upload mechanism" and moved on to other features.

Harish didn't move on. He figured it out.

How devpub upload works

The Dev.to web editor uploads images to POST /image_uploads. It's a multipart form submission, same as any file upload. But it's not authenticated with your API key. It uses your browser session.

# Upload a single image
devpub upload cover.png

# Upload multiple images
devpub upload *.png

# Get ready-to-paste Markdown
devpub upload architecture.png --markdown
# Output: ![architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/...)

The --markdown flag is the one I use most. Write your article with ![](./figures/diagram.png), then run devpub upload figures/*.png --markdown and paste the output directly over your local references.

The authentication problem

Here's why this feature sat undone for three weeks. The /image_uploads endpoint requires:

A _Devto_Forem_Session cookie (your login session)
A CSRF token (anti-forgery protection)
An Origin header matching https://dev.to

Your API key? Useless. This endpoint doesn't accept it.

So devpub needs two extra credentials beyond your API key. They live in .devpub/.env (which devpub init gitignores by default):

DEVPUB_SESSION_COOKIE=_Devto_Forem_Session=abc123...
DEVPUB_CSRF_TOKEN=a1b2c3d4...

If you run devpub upload without setting these, it doesn't just fail with a cryptic error. It shows you exactly where to find them:

╭─ Session Credentials Required ─────────────────────────────╮
│                                                             │
│  devpub upload needs your browser session (not API key).    │
│                                                             │
│  1. Open https://dev.to/new in Chrome                       │
│  2. Press F12 → Application → Cookies → dev.to             │
│  3. Copy _Devto_Forem_Session value                         │
│  4. View page source → find <meta name="csrf-token">       │
│  5. Add both to .devpub/.env                                │
│                                                             │
╰─────────────────────────────────────────────────────────────╯

One deliberate design choice: these are login credentials, not a scoped token. The .env file is gitignored, and when they expire (you'll get a 401 or 403), you just re-copy them. devpub tells you that upfront rather than leaving you to guess why uploads suddenly stopped working.

What Harish built

Harish's PR wasn't a quick hack. It was a proper module with clear boundaries:

File	Role
`src/devpub/api/uploads.py`	`ImageUploader` class with all HTTP logic
`src/devpub/cli/images.py`	Click command + Rich table output
`tests/test_uploads.py`	29 tests, all HTTP-mocked with respx

Three things stood out in his implementation:

1. Fail before the network. File existence, extension validation, and size check (25 MB limit) all happen before any HTTP request fires. A typo in a filename costs zero network round-trips.

2. Flexible response parsing. Dev.to's upload response isn't documented, so the _extract_url method handles every response shape that's been observed: links.url, image.url, images[0], a raw string. If none match, it raises with the full response body included. A wrong URL silently landing in your article would be worse than a loud error.

3. Cookie flexibility. You can paste the full cookie header (a=1; b=2; _Devto_Forem_Session=xyz) or just the session value. Both work. Because copying one value out of DevTools is easy to get wrong.

The PR description was thorough. Design rationale for keeping ImageUploader separate from DevtoClient (different auth models shouldn't share a class). Explicit call-out that tests pin the request shape, not the live response. A suggestion to smoke-test against a real session before release.

This is what good open source contributions look like. Not just code that works, but code that explains why it works that way.

Other changes in v0.3.0

Beyond the upload feature:

Fixed hardcoded User-Agent: Was stuck at devpub/0.1.0. Now reads the actual version from importlib.metadata.
Fixed empty API key edge case: DevtoClient(api_key='') used to fall through to environment variables silently. Now it raises.
Repo cleanup: Removed personal draft articles from tracking, updated .gitignore for research docs and recordings.

Try it yourself

pip install devpub==0.3.0

For uploads, you need the session credentials (one-time setup):

# Add to .devpub/.env
DEVPUB_SESSION_COOKIE=your_session_cookie_here
DEVPUB_CSRF_TOKEN=your_csrf_token_here

Then:

devpub upload cover.png              # Upload and get URL
devpub upload *.png --markdown       # Ready-to-paste Markdown tags
devpub upload diagram.png --dry-run  # Validate without uploading

Full source: github.com/simplynadaf/devpub

What's next

Two follow-ups that Harish explicitly scoped out of his PR (smart -- ship the primitive first, then build on it):

Auto-rewrite during push: devpub push could detect local image paths like ![](./figures/arch.png), upload them automatically, and rewrite the URLs in-place before publishing.
Cover image shortcut: devpub push -f article.md --cover photo.png to upload the image and set cover_image in frontmatter in one step.

Both become trivial now that the upload primitive exists.

Shoutout

Big thanks to Harish @harishteens for the first external contribution to devpub. The PR was clean, well-tested, and properly documented. If you're looking for an open-source project to contribute to, devpub has open issues ranging from beginner-friendly to architecturally interesting.

What's your image workflow for Dev.to articles? Drag-and-drop in the browser? Hosted on GitHub? Imgur? I'd like to know if devpub upload fills a gap people feel, or if everyone's already solved this differently.

Free AWS Certification for Students: The Complete Step-by-Step Guide

Sarvar Nadaf — Mon, 31 Aug 2026 11:42:29 +0000

👋 Hey there! I'm Sarvar, a Cloud Architect who spends most days building on AWS and Azure, and the rest writing about it. Last year I wrote a guide on getting a free AWS certification voucher. Around 85,000 of you read it. You can still see it here: Unlocking Free AWS Certifications: Your Step-by-Step Guide. Then AWS closed that program (the old AWS Educate ETC route), and for the next year my comment section became a support desk. The same questions came up again and again: "my voucher got denied," "I don't see the reward," "when is it coming back?"

It's back. And this version is better.

On August 20, 2026, AWS launched Student Rewards on AWS Builder Center. If you are a student, you get 12 months of premium training, up to $30 in AWS credits, and a $100 certification exam voucher. Total value: $579. Your cost: $0.

No credit card. Ever. You never pay anything and you never enter a card. If you are a student, this is as close to free money for your career as it gets.

This is the step-by-step guide I promised you last year. I have added a full tips-and-tricks section so you skip the mistakes that got hundreds of people stuck. Take a breath. This is doable, and I will walk you through every step. Let's go. 🚀

What do you get?

When you verify that you are a student and finish your profile, rewards unlock in stages as you earn badges on Builder Center.

Milestone	Reward
Verified + profile complete	12 months Skill Builder premium ($449 value)
7 badges	$10 AWS credits
14 badges	$20 AWS credits
21 badges	$100 Foundational exam voucher

A quick word on those AWS credits: they are like store money for AWS. You use them to run real services (a small server, a database, some storage) while you practice, so you can learn hands-on without paying from your own pocket.

That $100 voucher covers the full price of one Foundational exam. You pay nothing for the exam.

Which exam should I pick?

The voucher works for either of AWS's two beginner certifications:

AWS Certified Cloud Practitioner (CLF-C02): pick this if you are new to cloud and want the classic, most-recognized starter cert.
AWS Certified AI Practitioner: pick this if you are curious about AI and cloud together.

Both are entry-level. Both are made for people with little or no hands-on experience. Both count for the voucher. If you are unsure, go with Cloud Practitioner. It is the one recruiters know best.

One honest heads-up before you start: the credits come fast, the voucher takes longer. I explain why in the timing section, so read that before you plan. The good news is you get your first win in the first two weeks.

Who is eligible?

Three conditions, all confirmed on the official Student Rewards page:

You are 18 or older.
You are a student at an accredited higher education institution.
Your enrollment can be verified (AWS uses a third-party service called SheerID for this).

The program is global, open to students at accredited institutions worldwide, subject to verification and local terms. A small number of countries are excluded by AWS voucher terms (Cuba, Iran, North Korea, Syria, Russia, and Crimea), so if you are there this offer will not apply.

How do I verify as a student?

This is step one, and from my experience with the old program, it is where the first batch of people get stuck. AWS hands verification to SheerID. You sign in with your Builder ID, give SheerID a few details, and it checks enrollment records.

The official page says most verifications finish within minutes. If SheerID needs a document from you, that review typically takes 24 to 48 hours.

You will provide:

Your name
Your college or school name
Your school email address

If the instant check needs backup, SheerID asks for a document showing your name, your school name, and a current enrollment date. Based on SheerID's own student FAQ, these work:

School ID card with an expiration date
Class schedule
Tuition receipt

💡 Tips for passing verification on the first try

These come from watching people fail (and fix) verification on my last guide:

Match your name to your school records, not your nickname. If your university has you as "Mohammed A. Khan" and you type "Mo Khan," the automatic check can fail. In my experience this is the number one reason verification bounces.
Use your school email. The official page asks for it specifically, and it clears the instant check far more often than a personal Gmail.
You are allowed to black out sensitive info on uploaded documents. Cover your ID number or address. Keep your name, school name, and the date visible. SheerID says it deletes documents after review.
Verify on your own device. Shared or public machines that already ran a verification can trip an error.
If you hit an error, check your details for typos first, then contact SheerID support. If the reward itself is the problem after you are verified, that is an AWS/Builder Center issue, not SheerID.

How do I earn the 21 badges?

Here I need to be honest with you about sources. The official Student Rewards page says you earn badges by continuing to take actions on Builder Center: "Publish articles, comment, and maintain streaks." AWS publishes the full badge criteria in its own FAQ at builder.aws.com/faq#badges. What AWS does not publish in a neat table is the exact duration of every streak.

So the breakdown below combines what AWS confirms (badges exist, streaks exist, these actions count) with what students are actively reporting on their profiles and what I have pieced together tracking the program. Treat the exact day counts as community-reported, not gospel, and check the official FAQ for the current criteria.

Badges fall into four kinds, and understanding the mix is the whole game.

One-time badges (the quick wins): completing onboarding, adding a profile photo, reading content, making your first post, submitting your first Wish (a Wish is a feature request you send to AWS through the Wishlist), and publishing your first article. These are the fastest badges you will earn, and you can grab most of them on day one.

Streak badges (the backbone): sign-in, like, and comment streaks. Students report these come in 7-day, 30-day, and 90-day tiers, so the longest ones are what stretch the timeline. I explain how to handle them below.

Weekly streak badges: voting on Wishes and publishing articles on a weekly cadence over several weeks.

Community badges (the hard part): these depend on other builders reacting to you. Getting replies on your comments, collecting likes across your comments, publishing articles that get engagement, and posting Wishes that gain traction. Because they rely on other people, they take the longest to control.

Where are the buttons? (the part that confuses everyone on day one)

When you first open Builder Center, you will not know where anything is. That is normal. I got a hundred messages last year that were basically "I want to do it but I cannot find the button." So here is exactly where to click:

Add your profile photo: open your profile, add a photo, hit save. That alone unlocks your first big reward (12 months of Skill Builder). Do this first.
Your first post: join a Space first (a Space is just a topic room, like a group chat for a subject), then create your post inside it.
Your first Wish: go to the Wishlist, click +, then Create Wish, and write one small AWS idea you wish existed. Tip: look through the Wishlist first and support an existing Wish, AWS prefers that over a duplicate.
Your first article: click +, then Create Article, write, then Preview → Publish. It does not have to be long. A short honest post about what you learned this week is enough.

New to all of this? Bookmark the official Your Guide to Builder Center. It walks you through the platform in plain steps.

Watch your number go up

Here is the part that keeps you motivated. You do not jump from 0 to 21 in one leap. You climb it, and every stage is a small win you can feel:

Finish the easy day-one badges → you are already at about 6 / 21. On your first day. That fast.
Hold your daily habit for a week → around 9 / 21.
Add the weekly article and Wish-vote streaks → about 11 / 21.
Keep going to 30 days → roughly 14 / 21, and by now your $10 and $20 credits have landed. 💰
Build a little community engagement → around 18 / 21.
Finish the long streaks near 90 days → 21 / 21. Voucher unlocked. 🎉

See it? More than half your badges come in the first few weeks. The last stretch is just showing up. If you can open an app once a day, you can do this.

The timing trick nobody tells you

First, the good news, because it matters most. You get real rewards fast. The one-time badges take a day or two. Keep a small daily habit going and you hit 7 badges within your first couple of weeks, which unlocks your first $10 in credits. Reach 14 badges over the next couple of weeks and $20 more lands. So you are not waiting three months for your first reward. You get an early win almost right away, and that early win is what keeps you going.

Now the part nobody explains, and it is based on how the streaks work rather than an official AWS statement.

The streaks stack. They do not reset each stage. Think of it as one simple daily habit: sign in, like a post, leave a real comment. That same habit feeds the 7-day, 30-day, AND 90-day streak badges all at once. You are not doing three separate things. You are doing one small thing every day, and it counts three times.

Here is the honest truth about the $100 voucher: if the longest streak really is 90 days (which is what students are reporting), then the voucher takes about 90 days of showing up daily. There is no shortcut past a time-based streak. But that is fine, because your credits already arrived early, and 90 days is exactly the time you need to study anyway. More on that later.

So the plan is simple:

Day 1: grab all the one-time badges, and start your daily habit (sign in, one like, one comment). That is it for today.
First 2 to 4 weeks: you clear the short streaks and weekly streaks. $10 credit at 7 badges, $20 at 14 badges. Your first wins.
Around 90 days: the long streaks finish, you cross 21 badges, and the voucher unlocks.

The single most important move: start the daily habit on day one. Everything else follows from that.

🎯 More badge tips and tricks

Based on my experience running the last program and watching how this one behaves:

Set a phone alarm for the daily three. Sign in, one like, one comment. Ten minutes a day. On a long streak, one missed day is expensive, so protect the habit.
For article streaks, keep them small. A few short, honest articles beat one giant post you never finish. Write about what you learned in your course that week. That is enough.
Comment with substance, not "nice post." The community badges need other people to like and reply to you. A real question at the end of your comment earns replies. "Great article" gets ignored.
Check the Wishlist before posting a Wish. AWS suggests commenting on an existing Wish rather than duplicating one. Better engagement, and it still counts.
Start the community badges early. They depend on other builders, which you do not control, so give them the most runway.

How do I claim and use the voucher?

Once you hit 21 badges, the voucher appears in your rewards. From my last guide's comment section, this is where the real confusion lived, so let me pre-answer it.

⚠️ The mistakes that got people stuck last time

I answered these same questions dozens of times in my last guide's comments. Here is what I learned, so you skip the queue.

"My reward isn't showing after I hit the milestone." I lost count of how many people panicked here. The dashboard lags. Last year it took two to three days to update for most people. Wait it out before you open a ticket.
"The voucher got denied." One reader tried three times in a row and kept failing. The fix was almost always the same: their training account email did not match their program email, so their progress was split across two profiles. Confirm you are using one account, one email, everywhere.
"I have an existing AWS training account and can't link it." A reader hit a 500 error every time he tried to reset his password to link accounts. This is a known issue. Reset your password at the AWS Training and Certification portal first, then link. If the reset still errors, use a different email or contact support.
Do not let the voucher expire. This is the one that hurts most. You will have done months of work to earn it. AWS exam vouchers carry a redemption deadline, and yours will state its own expiry date when it lands. Book your exam that same day. From my experience, people grind for months and then lose the voucher to the clock. Do not be that person.

To book: take the voucher code into the AWS Certification portal, schedule the CLF-C02 or AI Practitioner exam, and apply the code at checkout. Cost drops to $0.

Turn the voucher into a real certificate, for free

A voucher is not a certificate. You still have to pass the exam. Here is the best part, though: the same program already gave you 12 months of premium Skill Builder the day you verified. That is your study material. You do not need to buy a single course or pay for anything.

And do not be scared of the exam. Cloud Practitioner is the easiest AWS certification. It is built for people with zero hands-on experience. It tests whether you understand cloud basics, not whether you can build complex systems. Most people pass with three to four weeks of steady study. If you have been doing your daily badge habit, you already have the time built in.

The exam (CLF-C02) is 65 questions, 90 minutes, and you pass at 700 out of 1000. It covers four areas:

Cloud Technology and Services (34%)
Security and Compliance (30%)
Cloud Concepts (24%)
Billing, Pricing, and Support (12%)

📚 A free 4-week study plan from your Skill Builder access

Weeks 1 to 2: work through the official CLF-C02 exam prep course in Skill Builder. Start with Security and Cloud Technology, since together they are 64% of the exam.
Week 3: do the hands-on labs your premium access unlocks. Clicking around S3, EC2, and IAM yourself sticks far better than reading about them. Use your free credits here.
Week 4: take the official practice question set. If you score above 75% a few times in a row, book the real exam. You are ready.

Notice the rhythm: the badges take around 90 days, and that is also plenty of time to study. Do both together. Study a little while you keep your daily streak alive. By the time badge 21 hits, you are exam-ready and the exam costs you nothing.

Why bother? What this does for you

Let me be clear about why 90 days of small daily effort is worth it. This certificate goes on your CV and your LinkedIn. Recruiters search for it. For a student with no work experience yet, an AWS certification is proof you can learn cloud, and cloud skills are in demand everywhere. You walk out with a real, verifiable credential that companies recognize, and it cost you nothing but consistency.

Wrapping up

Last year, 80,000 people wanted a free AWS certification. The program they used closed. This one replaced it, and it gives you more: training, credits, and the voucher, all free for students.

The whole path costs nothing but time and showing up. Verify today. Start your daily habit today. Study a little each week while the badges add up. In about 90 days you can sit a free exam already prepared, and walk away certified.

You can do this. Thousands of students are doing it right now, and so can you.

Your turn: which exam are you going for, Cloud Practitioner or AI Practitioner? Drop it in the comments and tell me what day of your streak you are on. I reply to comments, and we can keep each other going. 👇

Happy learning. 🚀

NexPath Review: The Prompt Quality Layer for Cursor, Windsurf and Claude Code

Sarvar Nadaf — Thu, 27 Aug 2026 13:21:53 +0000

I've been building devpub, an open-source CLI that publishes and tracks articles on Dev.to. Last week I was in Cursor, adding a new analytics feature - full vibe coding mode, rapid-fire prompts, one after another:

"add caching to the API client."

"fix the rate limiter."

"make the analytics faster."

Three prompts, three pieces of code generated instantly. I moved on. Two days later I realized the "fix" had silently broken my retry logic, the "caching" had no invalidation strategy, and "faster" meant the agent had removed the safety throttle that prevents Dev.to from banning my API key.

None of those prompts said what shouldn't change. None specified how I'd know it worked. I wrote them in flow, and the agent did exactly what I asked. Which wasn't what I meant.

That's when I tried NexPath, a prompt quality layer for AI coding agents. It sits between you and your agent, catches vague prompts at the moment you submit them, and offers a stronger version. I thought: why not try this on devpub? A real codebase I know inside out, with real prompts I'd actually type. If it works here, it works anywhere.

The vibe coding pattern nobody talks about
What if something caught you before you hit Enter?
What the enhanced version includes
My hands-on experience with NexPath
NexPath agent support: Cursor, Windsurf and Claude Code
Who NexPath is for: Cursor, Windsurf and Claude Code users
What NexPath costs
Bottom line

The vibe coding pattern nobody talks about

Every developer using AI coding agents has a version of this story. Not because the agents are bad. They're incredibly good at generating code from whatever you give them. The problem is what we give them.

"Fix this." "Make it work." "Clean up the code." "Add auth."

These prompts feel productive. The agent responds instantly. Code appears. You move to the next thing. But six prompts later, your codebase has grown in directions you didn't plan, with assumptions you didn't state, skipping checks you didn't ask for.

The same mistakes repeat: no acceptance criteria, no rollback plan, no mention of what shouldn't change. Not because we don't know better. Because momentum makes it easy to skip.

The answer, I thought, was more discipline. Be better at prompting. Write longer, more detailed requests every time.

That lasted about three days.

What if something caught you before you hit Enter?

NexPath is not another coding agent. It doesn't generate code. It doesn't replace your agent. It doesn't try to be clever. It sits between you and your AI agent, and when you submit a vague prompt, it holds it for a second and says: "Here's a stronger version of what you meant. Want to use it instead?"

The simplest way I'd describe it: "NexPath is the thing that keeps AI-generated code from becoming a mess."

The workflow:

You write your prompt in Cursor, Windsurf, or Claude Code
NexPath intercepts it at submit time
A popup shows your original alongside an enhanced version
You pick which one gets sent
The chosen version auto-submits to your agent

Your original intent stays visible throughout. Nothing auto-sends without your approval. If a prompt doesn't need enhancement, NexPath stays silent.

What the enhanced version includes

When the enhancement fires, it doesn't rewrite your prompt. It wraps your original request with:

Scope boundaries: what should change, what shouldn't
Acceptance criteria: how you'll know it worked
Verification steps: tests to run after
Safety requirements: rollback plan for risky operations
Sequencing: if the task is complex, break it into ordered steps

Here's a real example from my devpub testing. I typed:

fix the rate limiter

NexPath enhanced it to something like:

Fix the rate limiter in DevtoClient._throttle(). Scope: only modify the timestamp tracking logic in src/devpub/api/devto.py. Do not change RATE_LIMIT_REQUESTS or RATE_LIMIT_WINDOW constants. Do not modify the retry logic in _request(). Acceptance: 30 requests per 30-second window still enforced, no sleep longer than 30s. Verify: run pytest tests/test_api.py after changes.

That's what I should have written in the first place. But I didn't, because I was in flow.

Another one. I typed:

push all drafts to dev.to as published

NexPath flagged the risk and added:

Push all draft articles to Dev.to with published=true. WARNING: This is a destructive action. Published articles are immediately visible to readers and cannot be easily unpublished. Scope: only modify the published field in article payloads. Safety: list all affected articles first and confirm count before proceeding. Rollback: note all article IDs changed so they can be reverted to draft if needed. Verify: check each article URL returns 200 after publishing.

The difference between "just do it" and "do it carefully," surfaced at exactly the right moment.

My hands-on experience with NexPath

I tested NexPath in two environments: Cursor on my laptop for the popup experience with devpub, and Claude Code on my EC2 server to stress-test the CLI and dig into the internals.

Installation (2-3 minutes, clean)

git clone https://github.com/hi0001234d/nexpath.git
cd nexpath
npm install        # 16 seconds, 298 packages
npm run build      # Build + 1,175 test validation
npm link
nexpath install    # Auto-detected my agents, wrote hooks

The nexpath status command gives you a complete picture: prompt store stats, hook activity, config state, environment detection. The level of observability in the CLI surprised me. Structured JSON logs, proper error codes, debuggable output.

What I liked

Privacy holds up. Everything lives in ~/.nexpath/. A SQLite database stores your prompts locally. The only outbound calls are to OpenAI's API (GPT-4o-mini for classification). Telemetry is disabled by default, confirmed in config. Secret redaction strips API keys from stored prompts automatically.

The engineering is solid. 1,803 commits from a team of three. 1,175 tests in the VS Code extension alone. Structured logging. Environment detection (OS, WSL, CI, devcontainer). Proper config system with keychain integration. This is not a weekend hackathon project abandoned after the demo, even though it started at one (AI Hackfest 2026 by MLH).

It knows when to shut up. The system classifies your prompts into development stages (idea, architecture, implementation, testing, etc.) and only fires when it detects a transition or an absence signal: a missing spec, a skipped test strategy, a risky shortcut. When your prompts are already well-structured, it stays out of the way.

The popup experience just works. In Cursor, you type your prompt, hit Enter, and NexPath holds it for a beat. A popup appears showing your original alongside the enhanced version. You pick one, it auto-submits. No context switch, no copy-paste, no extra windows. It feels like a natural part of the workflow, not an interruption.

Environment awareness is thorough. The nexpath env command probes your OS, detects WSL, devcontainers, CI pipelines, shell type, project framework, version control, test runner, and deploy config, all locally. It uses this context to calibrate when and how it intervenes. That level of situational awareness is rare in developer tooling.

What needs work

API key handling has a rough edge. NexPath requires an OpenAI API key (for GPT-4o-mini). Their docs say it falls back gracefully to local classification when no key is available. In practice, after the first prompt, subsequent calls throw an unhandled OpenAIError: Missing credentials exception instead of degrading silently. It's a v1 edge case, easily fixable, but worth knowing if you're setting up on a fresh machine without a key configured yet.

The CLI advisory and the VS Code popup are different systems. The submit-time popup (Cursor/Windsurf) is the primary product. It intercepts every prompt at the moment you press Enter. The CLI advisory for Claude Code is a different mechanism that builds up session history before intervening. In my CLI stress test, it captured 18 prompts and intervened zero times because it needs longer session context to detect meaningful transitions. The popup experience doesn't have this limitation. It evaluates each prompt independently. If you're on Claude Code, expect a quieter experience than the Cursor/Windsurf popup.

Single LLM provider for now. It currently uses gpt-4o-mini as the classification model, a reasonable v1 tradeoff that limits flexibility for teams using other providers. The API costs are tiny (pennies per day), but multi-provider support would make it more accessible to teams with existing Anthropic or Groq setups.

NexPath agent support: Cursor, Windsurf and Claude Code

Agent	Status (Aug 2026)
Claude Code	✅ Supported via CLI + MCP hooks
Cursor	✅ Supported via VS Code extension (submit-time popup)
Windsurf / Devin	✅ Supported via VS Code extension (submit-time popup)

The VS Code extension (for Cursor and Windsurf) intercepts prompts at submit time and shows the popup inline. For Claude Code, it works through the CLI's hook system, firing between prompt submissions.

Important distinction: the Cursor/Windsurf experience is the polished one. You type, hit Enter, NexPath catches it, shows a popup, you pick, it sends. The Claude Code experience works through terminal hooks, which is less visual but functional.

Who NexPath is for: Cursor, Windsurf and Claude Code users

NexPath makes sense if you:

Prompt in short bursts ("fix this", "add that") and want guardrails without slowing down
Work on production codebases where a vague prompt can cause real damage
Want prompt discipline without having to be disciplined every single time
Use Cursor or Windsurf as your primary agent environment

It's less useful if you already write detailed, structured prompts consistently, or if you're building throwaway prototypes where quality doesn't matter.

What NexPath costs

NexPath itself is free (Apache 2.0, open source). The only cost is your OpenAI API key usage for GPT-4o-mini. In a typical coding session, that's $0.01 to $0.05 per day. Negligible, but not zero.

Bottom line

NexPath solves a problem I have: I write lazy prompts when I'm in flow, and those lazy prompts produce code that bites me later. The idea of a quality layer that catches me at the moment of submission, not after the damage is done, is genuinely useful.

I tested it on devpub, my own open-source project with a real API client, real rate limiting, real push-to-production workflows. The prompts I'd normally fire off ("fix the rate limiter", "push all drafts as published") came back stronger, scoped, and safe. That's the value.

The implementation on Cursor/Windsurf (submit-time popup, choose your version, auto-submit) is well-designed. The CLI experience for Claude Code needs more polish. The engineering underneath is serious, the privacy model is honest, and the team ships fast (20+ PRs merged in the 48 hours before launch).

Is it perfect? No. The API key handling has a rough edge. The single-provider model limits flexibility. The CLI advisory needs longer sessions to activate. But for a v0.1.4 open-source tool from a three-person team, it's solving the right problem in the right place, and the Cursor/Windsurf popup experience is genuinely well-executed.

I'll keep it installed. The first time it catches a dangerous prompt I would have sent unthinking, it pays for itself.

Try it yourself:

GitHub: NexPath on GitHub
VS Code Marketplace: NexPath VS Code extension for Cursor and Windsurf
Open VSX: NexPath on Open VSX
Demo: Prompt Enhancement in action

NexPath is running a Launch Feedback Challenge (ends Sep 2, 2026). They're looking for honest feedback, not praise. If you try it and have opinions, good or bad, share them at their discussion thread.

What's your approach to prompt quality? Do you write detailed prompts every time, or do you also fall into the "fix this" trap? Let me know in the comments.

I Built an AWS DevOps AI Agent Using Kiro Crew + MCP

Sarvar Nadaf — Mon, 24 Aug 2026 11:30:54 +0000

At 3:17 AM last Tuesday, my payment-api ECS service entered a terminal failure loop. 7,279 failed tasks since August 13th. The health check expected /api/health but the container only served static content. Every 60 seconds, ECS killed the task and replaced it. Burning compute the entire time.

No alarm fired. I never set one up. No PagerDuty page. No Slack alert. Just a service churning through resources that nobody was watching.

I slept through the whole thing. And woke up to a solved problem.

Not because I got lucky. Because my Kiro Crew agent was awake. It spawned 5 parallel investigations, called AWS DevOps Agent for a health assessment, found the root cause across ECS, CodeBuild, CodePipeline, and Lambda, and flagged everything with severity-prioritized fixes. By 3:24 AM, done.

This is Part 6 of my Kiro Crew series. Parts 1 to 5 showed what Crew can do: orchestrate agents, run cron jobs, enforce security, build custom apps. This one shows what happens when you connect it to AWS's production intelligence engine.

Watch the 12-min demo above to see the full autonomous investigation in action.

The problem nobody talks about
What AWS DevOps Agent actually is
The integration: one MCP config block
The architecture
Live demo: what the agent found
Applying the fixes
The cron job: check every 30 minutes
The investigate skill: deep root-cause analysis
The security model: why this is safe
The self-learning layer
34 tools at your agent's fingertips
Cost considerations
Try it yourself (complete walkthrough)

The problem nobody talks about

Every DevOps team I've worked with has the same gap: the space between "something went wrong" and "someone noticed."

PagerDuty fires when alarms trigger. But what about the things you never set alarms for? The ECS service silently cycling through failed tasks for four days straight. The CodeBuild project that's been FAILED since last week with nobody looking at it. The Lambda with a 3-second timeout calling a service that needs 6 seconds to respond.

These aren't incidents. They're slow leaks. And they only become incidents when a customer complains or the bill arrives.

I've seen this pattern across a dozen client engagements. The monitoring is always incomplete. The alarms cover the obvious cases. The subtle failures accumulate silently until something visible breaks.

The enterprise reality today

Here's what incident response looks like at most organizations I've consulted for:

Step	Who	Time	Problem
Alert fires	PagerDuty/OpsGenie	0 min	Only works if alarm exists
Engineer wakes up	On-call human	5-15 min	Context switch, fatigue, stress
Login to console	Human	5 min	MFA, VPN, finding the right account
Check CloudWatch	Human	10 min	Which metrics? Which log group? Which time window?
Correlate signals	Human	15-30 min	Was there a deployment? Config change? Upstream issue?
Identify root cause	Human	15-60 min	Experience-dependent, often wrong first guess
Write fix	Human	10-30 min	Under pressure, at 3 AM, with fatigue
Apply + verify	Human	10 min	Hope it doesn't make things worse
Total MTTR		1-3 hours	And that's IF an alarm existed

The real killer: if no alarm was configured, this entire process never starts. The failure just accumulates until someone notices manually.

How our approach changes this

Step	Who	Time	Difference
Cron fires (every 30 min)	Kiro Crew	0 min	No alarm needed, proactive scanning
Check all services	Crew + DevOps Agent	30 sec	Parallel, covers everything
Correlate signals	DevOps Agent	60-90 sec	X-Ray, CloudWatch, deployments, topology
Identify root cause	DevOps Agent	2-3 min	Consistent, no fatigue, no wrong guesses
Generate mitigation plan	DevOps Agent	90 sec	Exact CLI commands, rollback steps included
Apply fixes	Kiro Crew	30 sec	Or: open PR for human review
Verify healthy	Kiro Crew	30 sec	Automated validation
Total MTTR		5-7 minutes	No human woken up

The architectural insight

AWS designed DevOps Agent as a read-only investigator. It observes, correlates, and produces mitigation plans with exact commands. But it never executes anything. That's intentional (security: no prompt injection risk from write operations).

Kiro Crew fills that gap. It takes DevOps Agent's mitigation plan and executes it (or opens a PR for human approval in production).

The separation:

DevOps Agent = the brain (read-only, investigates, produces exact fix commands)
Kiro Crew = the hands (orchestrates, executes, verifies, learns from past incidents)

Neither alone solves the problem. Together: autonomous incident response that runs 24/7, catches issues before customers notice, and gets smarter with every incident.

What enterprises gain

No more silent failures. Cron catches issues whether or not alarms exist.
Consistent investigation quality. DevOps Agent doesn't get tired at 3 AM or skip steps under pressure.
75% lower MTTR. AWS reports 75% reduction in customers using DevOps Agent. Adding Crew automation pushes it further.
Institutional memory. Crew's Knowledge base remembers every past incident. New team members inherit years of operational wisdom.
Audit trail by default. Every investigation, every fix, every decision logged in CloudTrail and Crew sessions.
Human-in-the-loop when you want it. Trust mode for non-critical environments, PR approval for production.

What if an agent checked for you? Every 30 minutes. Autonomously. While you sleep, eat dinner, or take your kid to the park.

What AWS DevOps Agent actually is

AWS DevOps Agent went GA in March 2026. Think of it as an always-on SRE that knows your AWS infrastructure intimately:

What it monitors:

Amazon ECS (services, tasks, deployments, health checks)
AWS Lambda (invocations, errors, duration, throttles, cold starts)
Amazon API Gateway (5xx errors, latency, integration failures)
Amazon RDS (connections, CPU, storage, replication lag)
Amazon DynamoDB (throttles, capacity, latency)
Amazon EC2 (status checks, CPU, network)
Amazon S3 (error rates, request patterns)
Amazon CloudWatch (alarms, metrics, anomalies)

What it does with that data:

Discovers and maps your service topology automatically
Correlates signals across metrics, traces, deployments, and configuration changes
Investigates incidents with deep async root-cause analysis (takes 5 to 8 minutes per investigation)
Generates recommendations with specific, actionable mitigations prioritized by severity
Reviews releases by checking pull requests for production risk patterns before they ship

The feature that makes this article possible: DevOps Agent exposes all of this over MCP (Model Context Protocol). That means any MCP-compatible client can call its 34 tools programmatically. Including Kiro Crew.

MCP Endpoint: https://connect.aidevops.{region}.api.aws/mcp

A2A Endpoint (agent-to-agent): https://connect.aidevops.{region}.api.aws/a2a/*

Supported Regions: us-east-1, us-west-2, eu-west-1 (as of August 2026)

The integration: one MCP config block

Connecting DevOps Agent to Kiro Crew takes one config block. I did this live in the terminal during the demo. Before adding it, I had 9 MCP servers configured in Crew. After: 10.

import json

config = json.load(open('/home/ubuntu/.kiro/settings/mcp.json'))
config['mcpServers']['aws-devops-agent'] = {
    'url': 'https://connect.aidevops.us-east-1.api.aws/mcp',
    'headers': {'X-Agent-Space-Id': '7ab2314d-15e8-4744-a1a7-3f96692fcd83'},
    'description': 'AWS DevOps Agent (34 tools)',
    'disabled': False
}
json.dump(config, open('/home/ubuntu/.kiro/settings/mcp.json', 'w'), indent=2)
# Output: ✅ Added aws-devops-agent (10 total servers)

I verified the connection by calling tools/list against the MCP endpoint:

Tools available:
  • get_service
  • list_agent_spaces
  • get_agent_space
  • create_agent_space
  • update_agent_space
  • create_access_token
  • get_access_token
  • list_access_tokens
  • revoke_access_token
  ... and 24 more

Endpoint: https://connect.aidevops.us-east-1.api.aws/mcp
Space:    7ab2314d-15e8-4744-a1a7-3f96692fcd83

34 tools. Live connection confirmed. Your Crew agent can now call any of them.

Alternative: SigV4 authentication (recommended for production)

If you don't want to manage bearer tokens, use AWS SigV4 via mcp-proxy-for-aws:

{
  "mcpServers": {
    "aws-devops-agent": {
      "command": "uvx",
      "timeout": 120000,
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://connect.aidevops.us-east-1.api.aws/mcp",
        "--service", "aidevops",
        "--region", "us-east-1"
      ]
    }
  }
}

This uses your existing AWS credentials (from ~/.aws/credentials or instance profile). No separate token to rotate.

The architecture

Here's the full autonomous pipeline:

┌──────────────────────────────────────────────────────────────┐
│                       KIRO CREW                               │
│                                                               │
│  ┌───────────────┐     ┌──────────────────┐                  │
│  │  Cron Job     │────▶│  Orchestrator    │                  │
│  │  (*/30 * * *) │     │  (claude-sonnet) │                  │
│  └───────────────┘     └────────┬─────────┘                  │
│                                 │                             │
│                    Spawns 5 parallel subagents                │
│                                 │                             │
│        ┌────────────────────────┼────────────────────┐       │
│        ▼            ▼           ▼          ▼         ▼       │
│  ┌──────────┐ ┌──────────┐ ┌────────┐ ┌────────┐ ┌──────┐  │
│  │   ECS    │ │  CI/CD   │ │CloudW. │ │DevOps  │ │Lambda│  │
│  │  Check   │ │  Check   │ │ Check  │ │ Agent  │ │Check │  │
│  └────┬─────┘ └────┬─────┘ └───┬────┘ └───┬────┘ └──┬───┘  │
│       │             │           │          │         │       │
│       └─────────────┴───────────┴──────────┴─────────┘       │
│                              │                                │
│                    Consolidated findings                      │
│                    (severity-prioritized)                     │
│                              │                                │
│                    ┌─────────▼──────────┐                    │
│                    │  Coding Agent      │                    │
│                    │  (writes fix, PR)  │                    │
│                    └─────────┬──────────┘                    │
└──────────────────────────────┼───────────────────────────────┘
                               │
              ┌────────────────┼────────────────┐
              ▼                                 ▼
   ┌────────────────────┐            ┌──────────────────┐
   │  AWS DevOps Agent  │            │     GitHub       │
   │  (MCP endpoint)    │            │  (Pull Request)  │
   │                    │            │                  │
   │  - chat            │            │  Human reviews   │
   │  - investigate     │            │  in the morning  │
   │  - recommend       │            │                  │
   └────────────────────┘            └──────────────────┘

The flow:

Cron fires every 30 minutes (*/30 * * * *)
Orchestrator (claude-sonnet-4) spawns 5 parallel subagents
Each subagent checks one domain: ECS, CI/CD, CloudWatch, DevOps Agent consultation, Lambda
All run simultaneously (not sequential, this matters for speed)
Results consolidated into severity-prioritized findings
If actionable: Coding Agent writes the fix, opens a PR on GitHub
Human reviews the PR in the morning

The agent can investigate but never deploy. That's the safety boundary.

Live demo: what the agent found

I triggered the investigation with one natural prompt:

"Something's wrong with my payment-api service. I think builds are failing and the pipeline is stuck. Check everything: ECS, CodeBuild, CodePipeline, Lambda timeouts, and CloudWatch alarms. Also try calling DevOps Agent via awscurl for a health assessment. Tell me what's broken and how to fix it, prioritized by severity."

The agent spawned 5 parallel subagents. I watched them work in real time:

Subagent	ID	Focus	Tools Used
ECS Investigation	921383af	Service status, task definitions, health checks	14 tools
CI/CD Investigation	6a99eac8	CodeBuild status, CodePipeline state, build logs	14 tools
CloudWatch Investigation	7e55ac60	Alarms, logs, metrics for service health	14 tools
DevOps Agent Consultation	ae0b20b6	MCP endpoint call via awscurl	3 tools
Lambda Investigation	488d2596	Timeouts, errors, Step Functions state	11 tools

All five running simultaneously. The DevOps Agent consultation alone took 67 seconds (it calls multiple AWS APIs behind the scenes). Total investigation: under 3 minutes.

Here's what came back:

🚨 CRITICAL OUTAGE (4+ Days Down)

ECS Service in Terminal Failure Loop

Finding	Detail
Failed tasks	7,279 since August 13th
Root Cause	Health check expects `/api/health` but nginx:alpine only serves static content
Current State	4 tasks running (should be 2), all UNHEALTHY, replaced every 60-90 seconds
Resource Impact	Continuous failed task churn burning compute costs
Cluster	payment-api-cluster
Service	payment-api-service

Complete CI/CD Pipeline Breakdown

Finding	Detail
CodeCommit	Empty repository with no branches or code
CodeBuild	FAILED (can't build from empty repo)
CodePipeline	FAILED, can't find 'main' branch that doesn't exist
Impact	Builds fail every time, pipeline permanently stuck

🟡 MEDIUM PRIORITY: Configuration Hardening

Set health check grace period to 30+ seconds (currently 0)
Add proper logging and monitoring configuration
Implement proper security groups and networking

⚠️ Lambda Timeout Issue

The Demo function has a 3-second timeout calling downstream services that need 4 to 6 seconds to respond. Every invocation times out silently. Zero alarms configured to catch it.

📊 CloudWatch: Zero Observability

Zero alarms configured in the entire account. 8 Lambda functions, 5 API Gateways, 1 ECS cluster, all running completely blind. If anything fails, nobody gets notified.

None of these would have triggered a PagerDuty alert. The ECS service was burning compute for four days straight with nobody noticing.

Applying the fixes

Based on the agent's severity-prioritized recommendations, I applied two immediate fixes in the terminal:

Fix 1: Lambda timeout 3s to 30s

aws lambda update-function-configuration \
  --function-name Demo \
  --timeout 30 \
  --region us-east-1 \
  --query "[FunctionName,Timeout]" --output text
# Output: Demo    30

aws lambda update-function-configuration \
  --function-name Demo-API \
  --timeout 30 \
  --region us-east-1 \
  --query "[FunctionName,Timeout]" --output text
# Output: Demo-API    30

Fix 2: Add CloudWatch alarms (was ZERO)

# ECS task failure alarm
aws cloudwatch put-metric-alarm \
  --alarm-name "ECS-PaymentAPI-TaskFailures" \
  --metric-name CPUUtilization \
  --namespace AWS/ECS \
  --statistic Average \
  --period 300 \
  --threshold 0 \
  --comparison-operator LessThanOrEqualToThreshold \
  --evaluation-periods 2 \
  --dimensions Name=ClusterName,Value=payment-api-cluster \
               Name=ServiceName,Value=payment-api-service \
  --alarm-description "Payment API: no tasks running" \
  --region us-east-1
# Output: ✅ ECS alarm created

# Lambda error alarm
aws cloudwatch put-metric-alarm \
  --alarm-name "Lambda-Demo-Errors" \
  --metric-name Errors \
  --namespace AWS/Lambda \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --dimensions Name=FunctionName,Value=Demo \
  --alarm-description "Demo Lambda errors" \
  --region us-east-1
# Output: ✅ Lambda alarm created

Verified state after fixes:

Lambda Demo:     30s (was 3s)
Lambda Demo-API: 30s (was 3s)
Alarms:          2 active (was 0)

In the production Crew workflow, these become a PR. The agent writes the IaC change (CloudFormation, CDK, or Terraform depending on your stack), pushes to a branch, and opens the PR with investigation findings in the description. A human reviews it in the morning.

The cron job: check every 30 minutes

Here's the cron that makes this autonomous. I added it through the Crew Schedule page:

Field	Value
Name	production-health-check
Schedule	Every 30 minutes (`/30 * * *`)
Agent	default (claude-sonnet-4)
Message	Check production health: ECS, CodeBuild, Pipeline, Lambda, CloudWatch. Flag issues with severity and fixes.

Every 30 minutes, Crew spawns a session, the agent checks infrastructure health, and reports findings. If everything's green, session ends quietly. If something's flagged, it investigates deeper and proposes fixes.

No daemon process to maintain. No EC2 instance running a cron script. No custom monitoring infrastructure. One entry in the Schedule page.

Scaling this: You can have multiple cron jobs for different concerns:

production-health    → */30 * * * *  → Full infrastructure scan
cost-anomaly-check   → 0 8 * * *    → Daily cost spike detection  
security-drift       → 0 */6 * * *  → Every 6h IAM/SG audit
release-readiness    → 0 9 * * 1-5  → Weekday pre-deploy check

The investigate skill: deep root-cause analysis

The chat tool is fast (seconds). But for real incidents, DevOps Agent has an investigate skill that runs 5 to 8 minutes of deep analysis across your infrastructure.

What the investigation does:

Pulls CloudWatch metrics: invocations, errors, duration, throttles, anomaly bands
Checks recent deployments: CodeDeploy, ECS task definitions, Lambda versions
Correlates downstream latency: X-Ray traces, API Gateway integration errors
Analyzes temporal patterns: did this start after a specific deployment?
Checks resource topology: which services depend on the failing component?
Returns root-cause analysis with prioritized recommendations

This is the same analysis flow a senior SRE would do manually. Check metrics, correlate with deployments, trace downstream, identify root cause. The difference: it happens at 3 AM without waking anyone up.

In the demo, the DevOps Agent subagent took 67 seconds to complete its assessment (you can see it in the recording: 174s • 3 tools on the subagent panel). That's because it's making multiple API calls behind the scenes to build the full picture.

The security model: why this is safe

"Autonomous agent fixing production" sounds terrifying. After running this for weeks, here's why it's not:

1. DevOps Agent is read-only by default

The IAM role uses ReadOnlyAccess. Full visibility, zero write permissions:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "aidevops.amazonaws.com"},
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "aws:SourceAccount": "123456789012"
      }
    }
  }]
}

Attached policy: arn:aws:iam::aws:policy/ReadOnlyAccess

It can observe everything. It can change nothing.

2. Crew's deny patterns block destructive commands

Even if the agent tries to deploy, Crew blocks it:

{
  "deny_patterns": [
    "kubectl apply",
    "aws deploy create-deployment",
    "terraform apply",
    "aws ecs update-service",
    "aws lambda update-function-code",
    "aws cloudformation execute-change-set"
  ]
}

The agent can write code. It cannot execute deployments.

3. The output is always a Pull Request

Never a direct change to production. The agent creates a branch, writes the fix, and opens a PR with:

Investigation findings in the description
Severity assessment
Links to relevant CloudWatch metrics
Diff showing exactly what changes

Human reviews and approves.

4. Full CloudTrail audit trail

Every MCP call to DevOps Agent is logged with:

{
  "eventSource": "aidevops.amazonaws.com",
  "eventName": "InvokeMcpTool",
  "requestParameters": {
    "agentSpaceId": "7ab2314d-...",
    "accessTokenId": "at-...",
    "protocol": "MCP",
    "toolName": "chat"
  },
  "sourceIPAddress": "172.31.20.246"
}

Every action traceable. Every tool invocation recorded.

5. Token scoping and rotation

Control	Detail
Scope	`read` or `operate` (choose minimum needed)
Expiration	1 to 60 days (forced rotation)
IP Allowlist	Optional, restrict to your Crew instance IP
Client Type	`agent` (for autonomous integrations)
Revocation	One-click disable all tokens

The pattern: observe everything, change nothing, suggest via PR, human approves.

The self-learning layer

Here's where Kiro Crew adds something DevOps Agent alone cannot do.

First time the agent investigates the ECS failure loop, it learns:

payment-api uses nginx:alpine as the base image
The health check path /api/health doesn't exist in that container
Health check grace period of 0 seconds means immediate failure on deploy
7,279 tasks failed before anyone noticed because zero alarms were configured

Crew stores this as a lesson in its Knowledge base. Next time it sees the same ECS task churn pattern (running count higher than desired, tasks being replaced every 60-90 seconds), it skips the full investigation and goes straight to: "Check if health check path exists in the container image. Check grace period setting."

After 30 days of running, your SRE agent has seen every failure pattern your infrastructure produces. It doesn't just find issues faster. It finds them immediately because it's seen them before.

This is the compounding advantage. PagerDuty doesn't learn from past incidents. CloudWatch Alarms don't adapt their thresholds based on patterns. Your Crew agent does.

34 tools at your agent's fingertips

When you connect DevOps Agent via MCP, your Crew agent gets access to these tools:

Investigation & Monitoring:

Tool	Description
`chat`	Instant health check, cost analysis, architecture review, topology mapping
`investigate`	Deep async root-cause analysis across all monitored services
`create_investigation`	Start investigation with priority level (P1/P2/P3)
`list_recommendations`	Get AI-generated mitigations with severity
`get_recommendation`	Detailed mitigation specification
`list_journal_records`	Stream investigation findings in real-time
`start_evaluation`	Evaluate against operational goals (SLOs)
`list_tasks`	Track async investigation status
`get_task`	Check if an investigation has completed

Release & Deployment Safety:

Tool	Description
`create_release_readiness_review`	Analyze PRs for production risk patterns
`create_release_testing_job`	Run exploratory tests on deployed apps

Service & Space Management:

Tool	Description
`get_service`	Detailed service topology, dependencies, health
`list_agent_spaces`	Manage multiple monitoring environments
`get_agent_space`	Space configuration details
`create_agent_space`	Provision new monitoring environments
`update_agent_space`	Modify space settings

Access & Security:

Tool	Description
`create_access_token`	Issue new credentials programmatically
`get_access_token`	Inspect token details
`list_access_tokens`	Audit all active tokens
`revoke_access_token`	Revoke compromised credentials immediately

Plus 14 more for full CRUD on spaces, associations, and configurations.

Your agent picks the right tool based on context. Ask "is anything broken?" and it calls chat. Say "investigate the payment API latency" and it calls investigate. No routing logic. MCP handles tool selection.

Cost considerations

Running this autonomously has cost implications worth understanding:

Kiro Crew costs:

Claude Sonnet 4 token usage per cron run (approximately $0.02 to $0.08 depending on investigation depth)
48 runs per day at */30 = roughly $1 to $4/day for continuous monitoring
Compare with: a single on-call engineer costs $200+/night

AWS DevOps Agent costs:

Included with your Agent Space (no per-API-call charges for chat/investigate as of August 2026)
The IAM role uses ReadOnlyAccess, so no resource creation costs from the agent itself

What this SAVES:

4 days of ECS task churn burning compute (in my case: ~$15-20 wasted before I noticed)
Engineer investigation time (30-60 min per incident at $100+/hr senior rate)
Customer-facing downtime (the real cost nobody measures until it happens)

The math: $2/day for continuous monitoring vs $200+ per missed incident. After one catch, it pays for itself for months.

Try it yourself (complete walkthrough)

Prerequisites

Kiro Crew installed and running (install guide)
AWS account with resources to monitor (at minimum: one Lambda function or ECS service)
IAM permissions: aidevops:* for Agent Space management
AWS CLI v2 configured with credentials
Region: us-east-1, us-west-2, or eu-west-1

Step 1: Create an Agent Space

aws devops-agent create-agent-space \
  --name "production-monitoring" \
  --description "Autonomous production health monitoring" \
  --region us-east-1

Save the agentSpaceId from the output. You'll need it for every subsequent step.

Step 2: Create an IAM role for DevOps Agent

DevOps Agent needs a role to assume when accessing your account's resources:

# Create trust policy
cat <<'EOF' > devops-agent-trust.json
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Service": "aidevops.amazonaws.com"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "aws:SourceAccount": "YOUR_ACCOUNT_ID"
      }
    }
  }]
}
EOF

# Create the role
aws iam create-role \
  --role-name DevOpsAgentSourceRole \
  --assume-role-policy-document file://devops-agent-trust.json \
  --description "Read-only access for AWS DevOps Agent monitoring"

# Attach ReadOnlyAccess (observe everything, change nothing)
aws iam attach-role-policy \
  --role-name DevOpsAgentSourceRole \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

Important: Use ReadOnlyAccess not AdministratorAccess. The agent needs to observe, not modify. Least privilege applies here.

Step 3: Associate your AWS account with the Agent Space

aws devops-agent associate-service \
  --agent-space-id YOUR_SPACE_ID \
  --service-id aws \
  --configuration '{
    "aws": {
      "assumableRoleArn": "arn:aws:iam::YOUR_ACCOUNT_ID:role/DevOpsAgentSourceRole",
      "accountId": "YOUR_ACCOUNT_ID",
      "accountType": "monitor"
    }
  }' \
  --region us-east-1

Step 4: Enable access tokens on the Agent Space

aws devops-agent update-agent-space \
  --agent-space-id YOUR_SPACE_ID \
  --access-token-configuration '{"enabled": true}' \
  --region us-east-1

Step 5: Create an access token for Kiro Crew

aws devops-agent create-access-token \
  --agent-space-id YOUR_SPACE_ID \
  --name "kiro-crew-monitor" \
  --scope "operate" \
  --client-type "agent" \
  --expires-in-days 60 \
  --region us-east-1

Save the token value securely. You won't see it again.

Step 6: Add MCP server to Kiro Crew

In your Crew dashboard: Agent Capabilities > Integrations (MCP) > Add

{
  "mcpServers": {
    "aws-devops-agent": {
      "url": "https://connect.aidevops.us-east-1.api.aws/mcp",
      "headers": {
        "X-Agent-Space-Id": "YOUR_SPACE_ID"
      },
      "description": "AWS DevOps Agent (34 tools)",
      "disabled": false
    }
  }
}

Or via the CLI:

kirocrew config mcp add aws-devops-agent \
  --url "https://connect.aidevops.us-east-1.api.aws/mcp" \
  --header "X-Agent-Space-Id=YOUR_SPACE_ID"

Step 7: Add the production health cron job

Go to Schedule in the Crew dashboard, click + Add Job:

Field	Value
Name	production-health-check
Schedule	`/30 * * *`
Agent	default
Message	Check production health via AWS DevOps Agent. Scan ECS, Lambda, CodeBuild, CodePipeline, and CloudWatch. Flag any issues found with severity and recommended fixes.

Step 8: Verify it works

Trigger the cron manually by clicking Run in the Schedule page. You should see the agent:

Check available MCP tools
Call DevOps Agent's chat tool for a health assessment
Return findings with severity levels

If it returns "Overall: HEALTHY" with no flags, your infrastructure is in good shape. If it finds issues, you'll get severity-prioritized recommendations.

What's next

This is the setup I run daily. DevOps Agent handles observation and intelligence. Kiro Crew handles orchestration, memory, and action. Together: autonomous ops that get smarter every week.

Articles 1 to 5 built the foundation. This one connects Crew to the real world, where production issues don't wait for business hours.

The full Kiro Crew series:

Introducing Kiro Crew
I Spent a Day With Kiro Crew
Cron Jobs Replaced 4 Hours of Weekly Toil
The Security Model That Got CISO Approval
I Built a Custom App in 5 Minutes
This article: Crew + DevOps Agent autonomous ops

GitHub repo with all configs: SimplyNadaf/kiro-crew-devops-agent

What's eating your 3 AM pages? I'm betting DevOps Agent plus a cron job could handle half of them. Drop your scenario in the comments.

I Added Terminal Charts to My Dev.to CLI. Here's What My Data Looks Like.

Sarvar Nadaf — Fri, 21 Aug 2026 14:13:00 +0000

TL;DR: pip install devpub==0.2.1 → devpub stats --graph → color-gradient bar charts, sparklines, trend arrows, and multi-period breakdowns for your Dev.to analytics. Zero new dependencies. GitHub repo / PR #10.

I check my Dev.to stats obsessively. Page views, reactions, which articles are climbing, which ones flatlined. But switching to the browser, clicking through dashboards, waiting for pages to load... it breaks my flow every single time.

So I built charts directly into devpub.

pip install devpub==0.2.1
devpub stats --graph

That one command now gives me this:

  Views (last 30 days)  ↘ -18%

     871 ┤                 █
         │                ██ ▂██     █▂
     653 ┤                ██ ███▇ ▆  █▆
         │               ▃██▅████▁█▆ ███
     435 ┤·▃····▁········███████████·███▃ ← avg (451)
         │▄█    █▆▁    ▂ ███████████▄████
     217 ┤████▇██████▅███████████████████
         │███████████████████████████████
         └───────────────────────────────
          Jul 21      Aug 05      Aug 20

  trend: ▃▄▃▃▂▃▄▃▃▃▃▂▃▃▃▄▆█▄▆▆▇▆▄▆▄▃▇▆▅▄

  Total: 14.0K │ Avg: 451/day │ Peak: 871 ▲ Aug 07

  Period Breakdown

   7 days: ▅▆▅▄█▆▆▄                         ↗ +9%   Total: 3.8K
  14 days: █▄▆▆▇▆▄▆▄▃▇▆▅▄                  ↘ -18%   Total: 8.5K
  21 days: ▃▂▃▃▃▄▆█▄▆▆▇▆▄▆▄▃▇▆▅▄           ↘ -18%   Total: 10.9K
  30 days: ▄▃▃▂▃▄▃▃▃▃▂▃▃▃▄▆█▄▆▆▇▆▄▆▄▃▇▆▅▄  ↘ -18%   Total: 13.7K

That's real data from my account. 257K total views, 24K followers, rendered in 0.3 seconds. No browser needed.

What changed in v0.2
The color gradient system
Multi-period sparklines
The average line
How I built it (zero new dependencies)
Try it yourself
What's next

What changed in v0.2

Version 0.1 had --graph as a flag that did nothing. I shipped the flag first, then built the feature. Classic.

Version 0.2.1 makes it real:

Feature	What it does
Color gradient bars	Bars fade blue (low) → cyan → green → gold (peak)
Sparkline one-liner	Compact 30-character trend below the chart
Trend indicator	Arrow + percentage comparing recent vs previous period
Average line	Dotted line across chart showing mean, with label
Peak marker	Gold highlight with date in the summary
Box-drawing axes	Clean tick marks using Unicode characters
12-row height	More vertical resolution than before
Multi-period breakdown	7d, 14d, 21d, 30d sparklines with individual trends
Period flag	`-p 7d`, `-p 90d`, `-p 3m` for any timeframe

All of this renders in the terminal. No image generation. No external services. No new dependencies.

The color gradient system

Most terminal charts use one color. Cyan. Green. Whatever. Every bar looks the same regardless of value.

I wanted the peak to visually pop. So bars shift color based on their height relative to the maximum:

Value range	Color	Purpose
0–25%	Blue	Low days, weekends
25–50%	Cyan	Below average
50–75%	Green	Good days
75–95%	Lime	Great days
95–100%	Gold	Peak day

The implementation is simple. One function that maps a 0–1 ratio to an RGB color string:

def _value_to_color(ratio: float) -> str:
    if ratio < 0.25:
        g = int(100 + ratio * 4 * 80)
        return f"rgb(50,{g},220)"
    elif ratio < 0.50:
        r = int((ratio - 0.25) * 4 * 50)
        return f"rgb({r},200,200)"
    elif ratio < 0.75:
        b = int(200 - (ratio - 0.50) * 4 * 150)
        return f"rgb(0,210,{b})"
    elif ratio < 0.95:
        r = int((ratio - 0.75) * 5 * 200)
        return f"rgb({r},220,50)"
    else:
        return "rgb(255,200,0)"

Rich handles the RGB rendering. Works in any modern terminal that supports 24-bit color (iTerm2, Windows Terminal, Ghostty, Kitty, Alacritty, WezTerm).

Multi-period sparklines

This is my favorite addition. After the main chart, you get a breakdown:

  Period Breakdown

   7 days: ▅▆▅▄█▆▆▄                         ↗ +9%   Total: 3.8K
  14 days: █▄▆▆▇▆▄▆▄▃▇▆▅▄                  ↘ -18%   Total: 8.5K
  21 days: ▃▂▃▃▃▄▆█▄▆▆▇▆▄▆▄▃▇▆▅▄           ↘ -18%   Total: 10.9K
  30 days: ▄▃▃▂▃▄▃▃▃▃▂▃▃▃▄▆█▄▆▆▇▆▄▆▄▃▇▆▅▄  ↘ -18%   Total: 13.7K

Why this matters: the 30-day trend might be down, but the 7-day trend tells you if you're recovering. In my case, overall traffic dropped 18% (I didn't publish for a week), but the last 7 days show +9% (new articles bringing it back).

Without multi-period comparison, you'd just see "down 18%" and feel bad. With it, you see the recovery in progress.

The sparkline characters (▁▂▃▄▅▆▇█) give you 8 levels of resolution per character. A 30-character sparkline shows 30 days of data in a single line. Your eye can instantly spot patterns: weekday/weekend cycles, post-publish spikes, gradual decay.

The average line

One detail that took surprisingly long to get right: the dotted average line.

     435 ┤·▃····▁········███████████·███▃ ← avg (451)

It runs across the chart at the mean value height. Bars above it are above average. Bars below are below. The ← label tells you the exact number.

Why it matters: without it, you're guessing whether a day was "good" or "bad." The line gives you an instant reference. Tuesday's 500 views looks small next to Monday's 871 peak, but the average line shows it's actually above average.

How I built it (zero new dependencies)

The entire chart system uses:

Rich (already a dependency) for colored output and console.print
Python stdlib for math, datetime, and string operations
Unicode block characters (▁▂▃▄▅▆▇█) for sub-character resolution

No matplotlib. No plotext. No termgraph. No asciichart. I looked at all of them. They either add heavy dependencies, produce output that doesn't integrate with Rich's markup system, or require complex setup.

Pure Python + Rich gives me:

Full control over every character
Rich markup ([bold], [rgb(r,g,b)]) works inline
Zero import time penalty
41 tests covering all helper functions
Works on Python 3.10+

The whole implementation is ~200 lines in one file. No architecture astronautics needed.

Full implementation: PR #10 — 41 tests, lint clean, handles edge cases (zero data, single day, large accounts with 90+ days).

Try it yourself

pip install devpub==0.2.1

Set your Dev.to API key (get it at dev.to/settings/extensions):

export DEVPUB_API_KEY=your_key_here

Then:

devpub stats --graph              # 30-day chart (default)
devpub stats --graph -p 7d        # Last 7 days
devpub stats --graph -p 90d       # Last 90 days (auto-downsamples)
devpub stats --graph -p 2w        # Last 2 weeks

⭐ Star the repo if terminal analytics resonates with you.

What's next

v0.3 will add the Concepts API integration. Dev.to has an ML-powered topic classification system that most people don't know exists. It classifies articles into semantic concepts with daily metrics. devpub concepts will let you discover trending topics, find gaps in coverage, and see which concepts your articles fit into.

But that's next week. For now, try devpub stats --graph and tell me what your chart looks like.

What's your Dev.to stats workflow right now? Browser dashboard? Ignoring it entirely? Something else? Drop it in the comments — I'm curious how other writers track their content performance.

This is part 2 of the "Building DevPub in Public" series. Part 1: Introducing DevPub

How I Built a Kiro Crew App in 5 Minutes - Full Tutorial With Code

Sarvar Nadaf — Tue, 18 Aug 2026 12:05:57 +0000

Parts 1-4 showed you what Kiro Crew can do. Investigate incidents. Automate weekly toil. Block dangerous commands. All using the built-in agent.

Solves persistent cross-session memory limits

Sarvar Nadaf for AWS Community Builders

Aug 5

Introducing Kiro Crew: AWS's Open-Source AI Agent Orchestrator

#discuss #agents #ai #aws

12 min read

Unsupervised agents cost $2.10 weekly

Sarvar Nadaf for AWS Community Builders

Aug 7

How Kiro Crew's Cron Jobs Replaced 4 Hours of Weekly Toil

#showdev #agents #ai #devops

7 min read

But here's what nobody's talking about: Kiro Crew has an App Store. And you can build your own apps for it. In five minutes.

Not plugins. Not scripts. Full apps with their own agents, skills, cron jobs, and dashboard pages. Package them. Publish them. Other users install with one click.

I built one. A Daily Standup Bot. It reads my git commits every morning and generates standup notes so I never have to write "worked on X" again. Let me show you how.

What the App Kit actually is
What we're building
Step 1: The manifest (app.json)
Step 2: The agent
Step 3: The skill
Step 4: The dashboard page
Step 5: The cron job
Install and run
What it looks like live
Publishing to the App Store
What else you could build
Try it yourself

What the App Kit actually is

An app is a package that contributes any combination of:

Component	What it does
Agents	Custom AI agent with its own model, prompt, and tool access
Skills	On-demand knowledge files that teach the agent specific capabilities
MCP servers	New tools the LLM can call
Cron jobs	Scheduled tasks the app owns
UI pages	Custom pages in the dashboard sidebar
Backend processes	HTTP servers reverse-proxied through the gateway

An app that only ships a skill is one markdown file. An app that ships everything is a full project. You decide the scope.

The key difference from "just adding a skill": apps are installable, versioned, publishable, and isolated. Crew manages their lifecycle. Users install from the App Store with one click.

What we're building

A Daily Standup Bot that:

Reads git commits from the last 24 hours
Formats them as "What I Did / What's Blocked / What's Next"
Runs every weekday at 9 AM automatically
Shows standup history in a custom dashboard page

Five files. Five minutes. A real app you'd actually use.

standup-bot/
├── app.json                    ← manifest (identity + resources)
├── agents/
│   └── standup-agent.json      ← agent definition
├── skills/
│   └── standup-format/
│       └── SKILL.md            ← formatting rules
└── ui/
    └── src/App.tsx             ← dashboard page

Step 1: The manifest (app.json)

Every app needs one file: app.json. This is the single source of truth.

{
  "name": "standup-bot",
  "version": "1.0.0",
  "displayName": "Daily Standup Bot",
  "description": "Auto-generates standup notes from git commits.",
  "author": "sarvar_04",
  "agents": ["agents/standup-agent.json"],
  "skills": ["skills/standup-format"],
  "ui": {
    "entry": "dist/index.mjs",
    "pages": [{
      "route": "/apps/standup-bot",
      "label": "Standups",
      "icon": "ClipboardList"
    }]
  },
  "crons": [{
    "name": "morning-standup",
    "cron_expr": "0 9 * * 1-5",
    "message": "Generate today's standup summary from yesterday's git activity",
    "agent": "standup-agent"
  }]
}

That's agents, skills, a dashboard page, and a cron job. All declared in one file. Crew reads this and wires everything up.

Step 2: The agent

agents/standup-agent.json:

{
  "name": "standup-agent",
  "model": "auto",
  "description": "Generates standup summaries from git activity",
  "prompt": "You are a standup summary assistant. Analyze git commits from the last 24 hours and generate concise standup notes. Format: What I Did, What's Blocked, What's Next.",
  "tools": ["@kirocrew-core"]
}

Eight lines. The @kirocrew-core tool reference gives it access to spawn processes, read files, and interact with the system. The model: "auto" lets Crew pick the best available model.

Step 3: The skill

skills/standup-format/SKILL.md:

---
name: standup-format
description: How to format daily standup updates
triggers: [standup, daily, summary, morning]
always: false
---

# Standup Format

When generating standup notes:

1. **What I did** - List completed work from git commits (group by feature/fix)
2. **What's blocked** - Identify stale PRs, failing CI, unresolved issues
3. **What's next** - Infer from branch names and open issues

Rules:
- One line per bullet
- Past tense for "did", present for "blocked", future for "next"
- Group related commits into one bullet
- Skip merge commits and dependency bumps
- Flag anything unmerged for >24 hours

Skills are markdown. They load on-demand when trigger words appear in the conversation. No code. No compilation. Just knowledge the agent uses when relevant.

Step 4: The dashboard page

ui/src/App.tsx:

import { useAppApi, useAppEvents } from '@kirocrew/app-sdk'
import { Card, CardTitle, PageHeader, StatCard, Badge } from '@kirocrew/app-sdk/ui'
import { useState, useEffect } from 'react'

export default function StandupDashboard() {
  const api = useAppApi()
  const [standups, setStandups] = useState([])

  useEffect(() => {
    api.get('/api/apps/standup-bot/history').then(setStandups)
  }, [])

  return (
    <>
      <PageHeader title="Daily Standups" subtitle="Auto-generated from git activity" />
      <div className="px-6 pb-8">
        <div className="grid gap-3.5 grid-cols-4 mb-6">
          <StatCard label="Today" value="Pending" accent />
          <StatCard label="This Week" value={`${standups.length} standups`} />
          <StatCard label="Total Commits" value="0" />
          <StatCard label="Next Run" value="Mon 9:00 AM" />
        </div>
      </div>
    </>
  )
}

You don't npm install @kirocrew/app-sdk. The dashboard provides it at runtime. Your app stays tiny. Build with Vite, mark Crew's SDK as external, output a single .mjs file.

Step 5: The cron job

Already declared in app.json:

"crons": [{
  "name": "morning-standup",
  "cron_expr": "0 9 * * 1-5",
  "message": "Generate today's standup summary from yesterday's git activity",
  "agent": "standup-agent"
}]

Crew registers the cron on enable. Deregisters on disable. Every weekday at 9 AM, it spawns a session, runs the message through standup-agent, and stores the result. No daemon. No systemd timer. Just a line in your manifest.

Install and run

# Get your auth token
TOKEN=$(kirocrew token | grep -oP 'token=\K[^&]+')

# Install (one command - point to your app directory)
curl -s -X POST "http://localhost:5476/api/apps/install?token=$TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"source": "./standup-bot"}' | python3 -m json.tool

# Enable - agents, skills, crons all activate
curl -s -X POST "http://localhost:5476/api/apps/standup-bot/enable?token=$TOKEN" \
  | python3 -m json.tool

Response:

{
    "ok": true,
    "name": "standup-bot",
    "message": "enabled standup-bot",
    "registration": {
        "agents": ["standup-bot/standup-agent"],
        "skills": ["standup-bot/standup-format"],
        "crons": ["standup-bot/morning-standup"],
        "mcp_servers": [],
        "errors": []
    },
    "hooks": {
        "crons_registered": ["standup-bot/morning-standup"]
    }
}

Agent registered. Skill loaded. Cron scheduled. Dashboard page live.

Refresh the dashboard. "Standups" is now in your sidebar. That's it.

What it looks like live

After installation, "Standups" appears in the sidebar. The dashboard shows stat cards and an empty state waiting for the first standup.

Trigger it manually in a chat session:

Use the standup-agent to generate today's standup from ~/projects/payment-api.
Run git log, analyze every commit, group by feature area.

The agent runs git log --since="24 hours ago" --oneline --no-merges, analyzes each commit, and produces:

What I Did:

Payment Processing:

Implemented rate limiting middleware for /api/payments (max 100 req/min per API key)
Fixed currency conversion rounding bug - was truncating before conversion
Added retry logic for failed Stripe webhook deliveries (exponential backoff, max 5)

API & Docs:

Updated OpenAPI spec with new error codes (429, 503, 504)
Added request validation for multi-currency checkout (USD, EUR, GBP, JPY)
Refactored payment intent creation to use idempotency keys

Infrastructure:

Configured DynamoDB TTL for expired sessions (7-day retention)
Added CloudWatch alarms for payment failure rate > 5%

What's Blocked:

PCI compliance security review - waiting on AppSec team (2 days)
Stripe Connect onboarding - blocked on legal approval

What's Next:

Subscription billing with usage-based metering
Payment analytics dashboard (revenue, failure rates, top merchants)

11 commits analyzed. 9 seconds. Navigate to the Standups page - it's already there.

Publishing to the App Store

The App Store is a curated registry. Publishing means opening a PR:

// In app-registry.json:
{
  "name": "standup-bot",
  "gitUrl": "https://github.com/simplynadaf/kiro-crew-standup-bot",
  "branch": "main"
}

Once merged, your app shows up in Explore → Library for all Crew users. Search "standup" and there it is:

Daily Standup Bot
v1.0.0 · Enabled · Registry

Auto-generates standup notes from git commits. Runs daily at 9 AM Mon-Fri.

sarvar_04
1 agent · 1 skill · 1 cron · 1 page

[Open]  [Disable]  [Sync]  [Uninstall]

Your app sits alongside the built-in ones - Code Review Sage, Research Lab, Task Runner. First-class citizen. Teams can also host private registries for internal apps that shouldn't be public.

What else you could build

The standup bot took 5 files and 5 minutes. Here's what's possible with the same pattern:

App idea	Components
PR Review Bot	Agent + skill (code review rules) + cron (check PRs hourly)
Incident Postmortem Generator	Agent + skill (postmortem template) + UI (history page)
Cost Anomaly Alerter	Agent + cron (daily AWS cost check) + Slack notification
Onboarding Buddy	Agent + skill (team knowledge) + UI (progress tracker)
Sprint Health Monitor	Agent + cron (daily Jira check) + UI (burndown chart)

Any workflow that's "check something + format it + deliver it on schedule" is a Crew app waiting to happen.

Try it yourself

Kiro Crew is open source (Apache 2.0). The standup-bot code is in this article.

# Install Crew
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh
kirocrew gateway

# Enable third-party apps
# In ~/.kiro/crew/config.json set: "apps_allow_third_party": true

# Create the app
mkdir -p standup-bot/agents standup-bot/skills/standup-format standup-bot/ui/src
# Create the 5 files shown above (app.json, agent, skill, UI, vite config)

# Build UI
cd standup-bot/ui && npm install && npm run build && cd ../..

# Install + enable
TOKEN=$(kirocrew token | grep -oP 'token=\K[^&]+')
curl -s -X POST "http://localhost:5476/api/apps/install?token=$TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"source": "./standup-bot"}'
curl -s -X POST "http://localhost:5476/api/apps/standup-bot/enable?token=$TOKEN"

# Open dashboard - "Standups" is in the sidebar
kirocrew open

The full app code and docs: Build your first app

simplynadaf / kiro-crew-standup-bot

Daily Standup Bot — A Kiro Crew app that reads git commits and generates standup notes. Agent + Skill + Cron + Dashboard in 5 files.

🤖 Daily Standup Bot

A Kiro Crew App That Writes Your Standups For You

5 files. 5 minutes. Never write "worked on X" again.

An AI agent that reads your git commits every morning and generates formatted standup notes - installed with one command on Kiro Crew.

📺 Watch the Demo · 🚀 Quick Start · 📦 App Structure · 📝 Article

✨ Features

Component	What It Does
🤖 Agent	Reads git commits from the last 24 hours, groups by feature area
📚 Skill	Teaches the agent the standup format (What I Did / Blocked / Next)
⏰ Cron	Runs every weekday at 9 AM automatically
📊 Dashboard	Shows standup history, stats, and today's summary in the sidebar

🎬 Demo

Agent analyzes 11 commits → generates standup in 9 seconds → dashboard updates live

🚀 Quick Start

# Prerequisites: Kiro Crew running
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh
kirocrew gateway

…

View on GitHub

kirodotdev / KiroCrew

A persistent workspace for development work that self-improves and continues beyond one session.

Kiro Crew

A persistent workspace for development work that self-improves and continues beyond one session.

Kiro Crew is an open source development workspace that runs locally or remotely on your hardware. It is persistent, self-learning, and self-evolving. Work with it from the desktop app, web dashboard, and CLI, or continue the same work through connection tools like Slack and Discord Your multi-step tasks can run unattended, recurring jobs run on your schedule and heartbeats monitor systems until something needs attention. Kiro Crew Apps tailor that experience to a specific job, combining a purpose-built interface with agents, skills, schedules, integrations, and backend services.

Quick start · Build from source · Why Kiro Crew · Capabilities · How it works · Security · Install · Telemetry · Docs

Quick start

You choose how to run Kiro Crew: the desktop app with automatic updates, a one-line install on your machine or a remote…

View on GitHub

What's next

Part 6 will show the multi-interface story. Start a task on CLI. Continue it on Slack. Check progress on the dashboard. Get notified on your phone. Same agent, same memory, zero context loss.

The App Kit is what turns Kiro Crew from "my AI coding assistant" into "my team's AI platform." The store is empty right now. First movers win.

What would you build? A PR reviewer? A docs-from-code generator? An automated changelog? Drop it in the comments. If it's interesting enough, I'll build it in Part 7.

DEV Community: Sarvar Nadaf

I Followed the n8n AWS Docs and It Broke at the First Command

The gotcha, up front

Launch the box first

Why bother self-hosting at all

The stack: two containers

Bring it up

First login

Before this goes anywhere near the internet

Stop and start without losing data

What you have now

Where the series goes

Per-Agent Cost Tracking for Multi-Agent AI on AWS

Why agent observability is a different problem

Picking the instrumentation

Prerequisites

Adding Traccia to your code

The stack: AWS native and read only

1. AWS Account Investigator (supervisor, investigation_run)

2. Cost Analyst (cost_analyst)

3. Health & Ops (health_ops)

4. Security Auditor (security_ops)

The cost bridge and one gotcha

No double-counting across agents

Modeling a multi-agent crew in traces

The unique part: catching silent waste

Scenario 1: The runaway loop

Scenario 2: Redundant tool calls

Scenario 3: Context bloat (the expensive one)

Same answer, different bill

Watching it happen: the live control panel

Build your own, at zero cost and read only

An honest take on Traccia

Honest caveats

FAQ

Try it

I Built an AI Agent That Audits AWS (And It Can't Touch Anything)

Who this is for

Table of contents

1. What an agent is made of

2. The safety foundation: read-only IAM

3. Writing the agent config

4. The skill: your audit checklist

5. Wiring the AWS tools with MCP

6. Running it, and what it produced

7. Making it yours

Why build this when Prowler and Trusted Advisor exist?

What the docs do not tell you

The takeaway

AI Agent vs Agentic AI: The Distinction That Changes Your Architecture

Table of Contents

Why this confusion is dangerous

AI agents: the specialist worker

Agentic AI: the system architecture

The quick comparison

When agentic AI goes wrong

The governance gap nobody talks about

Real-world examples: AWS and beyond

Single Agent: Amazon Bedrock Agent

Multi-Agent: Amazon Bedrock Multi-Agent Collaboration

My framework recommendation (opinionated)

When to use each

The maturity spectrum

The bottom line

How I Built an AI Agent That Cut My AWS Bill by 40% (CrewAI + Bedrock)

Who This Is For

Table of Contents

The Architecture

Why Not Just Use Trusted Advisor?

Why CrewAI + Bedrock

The Custom Tool: Scanning AWS

Running It

What It Found on My Account

Gotchas You'll Hit

The Web UI (Bonus)

Key Lessons

Cleanup

Try It

simplynadaf / crewai-aws-cost-optimizer-ai-agent

3 AI agents analyze your AWS account and find cost savings — powered by CrewAI + Amazon Bedrock

1. AWS Account Investigator (supervisor, `investigation_run`)

2. Cost Analyst (`cost_analyst`)

3. Health & Ops (`health_ops`)

4. Security Auditor (`security_ops`)