DEV Community: Ajaykumar k v

I Broke My Own Serverless App on Purpose, Then Asked AWS DevOps Agent What Happened

Ajaykumar k v — Sat, 01 Aug 2026 20:09:01 +0000

A hands-on field report: real account, real incident, real investigation output — graded claim by claim against CloudWatch, including the two things the agent got wrong.

Why another DevOps Agent post
What AWS DevOps Agent actually is
The five nouns you need: Agent Space, Topology, Skills, Journal, Goal
Pricing you can predict before you switch it on
The lab: a serverless order API engineered to fail in a diagnosable way
Onboarding in 20 minutes — and the four things that bite
Wiring alarms to the agent: two paths, and which one to pick
Breaking production on purpose: the incident, minute by minute
The evidence chain: what the agent actually has to work with
Asking the agent — and the moment it refused to answer
The investigation, graded claim by claim
The second root cause, and what it proves
Reading the agent's mind: the audit journal over the API
Fixing it, and what prevention should give you
Closing the loop: EventBridge, tickets, Slack, and the handoff to Kiro
Making the agent yours: skills, instructions, triggers, custom SRE agents
What this cost, and how to tear it down
Honest scorecard
Appendix: copy-paste checklist

1. Why another DevOps Agent post

Most posts about AWS DevOps Agent follow the same arc: quote the "up to 75% lower MTTR" figure, paste the architecture diagram, show a screenshot of a root cause analysis, conclude that on-call is solved.

The exceptions are worth your time. The AWS Networking & Content Delivery and Security blogs have genuinely good walkthroughs that deploy a broken workload, wire CloudWatch alarms into the agent, and step through real scenarios. I reference them in §7 rather than pretending I found that path first.

But they're all written from the outside in: here is the feature, here is it working. This post is written from the inside out — the questions you'll actually have at 09:00 on the Monday you're asked to evaluate it:

What breaks during onboarding?
My alerts are CloudWatch alarms. How do those reach the agent? (There's no native trigger. AWS ships samples for two different bridges, and they are not equivalent — §7.)
How do I tell whether the thing is working, or just sitting there?
What does it cost per incident, in dollars?
When its root cause analysis is wrong, how would I know?

That last one is the reason this post exists. I built an application designed to fail with more than one plausible cause, broke it, then handed the agent the aftermath and checked every single number it produced against CloudWatch. It got the verdict right and two mechanism details wrong — and one of those two would have sent an engineer looking for a configuration setting that does not exist.

Everything below is from one real AWS account in us-west-2 on 31 July 2026. Every timestamp, capacity figure and error count is copied out of CloudWatch or the agent's own output. Nothing is reconstructed or illustrative. Account IDs, the Agent Space ID and the API ID are redacted as <account-id> and <agentSpaceId>; everything else is verbatim.

2. What AWS DevOps Agent actually is

AWS DevOps Agent went GA on 31 March 2026, after a preview announced at re:Invent 2025. It's one of the AWS "frontier agents" — the family that also includes Kiro and the security testing agent — and it's built on Amazon Bedrock AgentCore, with dedicated infrastructure for memory, policies, evaluations and observability, rather than being a thin wrapper over a model.

It splits into two halves.

Production operations (GA). This is the part worth your attention today.

Capability	What it means in practice
Automated incident investigation	An alert arrives; the agent starts working immediately, correlating metrics, logs, traces, deployments and code
Actionable mitigation plans	Specific steps to fix, verify and roll back — plus agent-ready instructions another agent (Kiro) can implement
Proactive incident prevention	A scheduled evaluation reads your incident history and proposes observability, infra, pipeline and resilience changes
Automated incident coordination	Posts findings into Slack, ServiceNow, PagerDuty, Microsoft Teams
On-demand SRE tasks	Natural-language chat grounded in your topology: "how many Lambdas are on Python 3.8?", "which alarms fired overnight?"
AWS Support integration	Escalate an investigation to a support case with the whole investigation log attached

Release management (preview, us-east-1 only). Release readiness review and autonomous release testing — it reviews a change for blast radius and permission expansion before merge, then generates change-specific tests rather than running a static suite. Free during preview. Genuinely interesting, but evaluate it separately: different region, different maturity.

Where it runs. Eleven regions at the time of writing: us-east-1, us-west-2, ca-central-1, sa-east-1, ap-south-1, ap-southeast-1, ap-southeast-2, ap-northeast-1, eu-central-1, eu-west-1, eu-west-2.

The bit people miss: an Agent Space monitors resources in any region of an associated account, regardless of where the Agent Space itself lives. You pick the Agent Space region for data residency and team proximity, not to match your workloads. You do not need one per region.

How it differs from things you already have

vs. Amazon DevOps Guru — DevOps Guru is ML anomaly detection: it learns normal operating bounds from metrics, logs, events and traces, then flags deviations and aggregates them into insights. DevOps Agent runs an investigation: it forms hypotheses, queries logs, code and deployment history to test them, and writes a conclusion with a mitigation plan. Detection vs. diagnosis. Different jobs, and the overlap is smaller than the names suggest.
vs. your coding agent + a CloudWatch MCP server — the honest comparison, and the answer is context and governance. Your coding agent can query CloudWatch if you wire it up. What it can't do is hold a continuously-refreshed cross-account topology, share it with your whole team without per-engineer setup, enforce IAM boundaries on what the agent may touch, or keep an immutable audit journal of every reasoning step. §12 is the concrete example of why that matters.
vs. an SRE — not a replacement. A very fast first responder that never sleeps, and that you still have to check. §11.

3. The five nouns you need

Skip these and the docs will feel like fog.

Agent Space — a logical container defining what the agent can see: which AWS accounts, which third-party tools, which MCP servers, which users. Isolation is real: AWS-account isolation via dedicated IAM roles, user access isolation, and data isolation — investigations, chat history and recommendations do not leak between spaces. Use separate spaces for prod vs non-prod, or per business unit.

Topology — the auto-discovered map of your resources and how they relate. A background learning agent scans infrastructure, telemetry and code to infer application and service boundaries. In my account it correctly grouped resources into applications purely from CloudFormation stack boundaries, and explicitly discarded CDKToolkit and aws-sam-cli-managed-default as scaffolding. That's the difference between "I can query CloudWatch" and "I know what this system is".

Skills — modular Markdown instruction sets, an implementation of the open Agent Skills spec (non-executable files only: Markdown, PDFs, images, data). Three tiers:

AWS-provided — built in, maintained by AWS
User-defined — yours; runbooks, standards, correlation rules, skip rules
Learned — the agent writes these itself from your environment and past investigations

Each skill has frontmatter with name and description, and the description is load-bearing: the agent decides whether to activate the skill by reading it. "RDS skill" gets ignored. "Use this skill when investigating database latency, connection errors, or query timeouts for Amazon RDS instances" does not.

Journal — the immutable, append-only record of every message, tool call and reasoning step in an execution. The agent cannot rewrite it. This is your audit trail and, as §13 shows, your only real debugging tool.

Goal — a scheduled objective. Every new space gets one by default: an ONCALL_REPORT goal on rate(7 days) producing weekly post-incident analysis with prevention recommendations.

4. Pricing you can predict before you switch it on

One number to remember: $0.0083 per agent-second, billed per second, for all three categories (investigations, evaluations, on-demand SRE tasks). Nothing for idle time. No commitment.

That's $0.50 per agent-minute, which makes mental math easy:

Activity	Duration	Cost
One investigation	8 min	$3.98
One chat question	30 sec	$0.25
Weekly prevention evaluation	15 min	$7.47
Daily ops report from a custom agent	2 min × 30	$29.88/mo

A small team doing 10 investigations a month: ~$40. An active team at 80 investigations plus 100 chats: ~$344. Enterprise scale in AWS's own example: ~$2,366.

Free money, in order of how much you should care:

AWS Support credits. On a paid support plan you get monthly DevOps Agent credits as a percentage of the prior month's support charge: 100% for Unified Operations, 75% for Enterprise, 30% for Business Support+. Credits are issued by the 10th, apply within that month, and expire at month end. For a lot of Enterprise Support customers this makes DevOps Agent effectively free. Check this before building a business case from scratch.
Two-month free trial for new customers, starting at your first operational task: up to 10 agent spaces, 20h investigations, 15h evaluations, 20h on-demand tasks per trial month.
Included in the AWS Free Tier free plan for new AWS customers.
Release management is free during preview.

The cost that isn't on the pricing page: the agent pays your CloudWatch bill by proxy. Every Logs Insights query and trace retrieval it runs is billed by CloudWatch at standard rates. On a chatty log group this is not nothing. Budget for it.

Check your own consumption any time:

aws devops-agent get-account-usage --region us-west-2

{
  "monthlyAccountInvestigationHours":   { "limit": -1, "usage": 0.0 },
  "monthlyAccountEvaluationHours":      { "limit": -1, "usage": 0.0 },
  "monthlyAccountSystemLearningHours":  { "limit": -1, "usage": 0.0 },
  "monthlyAccountOnDemandHours":        { "limit": -1, "usage": 0.0 },
  "usagePeriodStartTime": "2026-07-01T00:00:00+00:00"
}

limit: -1 means no cap configured. Note the fourth category: system learning hours are metered separately, and the background learning agent runs whether or not you've had an incident.

What this post actually cost, measured

Here is the real meter after the chat session in §10 and the investigation in §11:

Category	Agent-seconds	Cost
Investigation (§11)	191	$1.59
On-demand / chat (§10)	632	$5.25
Evaluations	0	$0.00
System learning	0	$0.00
		$6.83

Two things in there surprised me, and they're both worth planning around.

The conversation cost 3.3× more than the investigation. Every pricing example — AWS's included — is built around investigations as the billable unit. In practice the investigation ran for 3.2 minutes, well under the 8-minute figure the pricing page uses, while the handful of chat turns that led up to it burned 10.5 minutes of agent time. Chat feels free because each reply is quick; it isn't, and it accumulates silently. If you roll this out to a team, the line item that surprises you will be monthlyAccountOnDemandHours, not investigations.

Investigations may be cheaper than you budget for. At 3.2 minutes this one cost less than a coffee, and it correlated four services and reconstructed a two-cause failure chain (§11). If cost is the thing making you hesitate on investigations, the number is probably smaller than your instinct says.

One caveat on reading your own meter: usage resets on the calendar month, and usagePeriodStartTime tells you which period you're looking at. My incident ran late on 31 July UTC and the investigation landed on 1 August, so the two showed up in different billing periods — easy to misread as "nothing was billed" if you only check one.

5. The lab

To evaluate an investigation agent you need an incident with more than one plausible cause. A Lambda that throws KeyError on line 12 proves nothing — any log search finds it. I wanted a failure where the symptom and the cause sit in different services.

Architecture

              POST /orders
                   │
        ┌──────────▼──────────┐
        │  API Gateway HTTP   │   access logs → CloudWatch
        │   API (prod stage)  │
        └──────────┬──────────┘
                   │
        ┌──────────▼──────────┐
        │  Lambda             │   X-Ray tracing on
        │  devops-lab-orders  │   structured JSON logs
        │  arm64, py3.13      │   env: WRITE_FANOUT
        └──────────┬──────────┘
                   │
        ┌──────────▼──────────┐
        │  DynamoDB           │   PROVISIONED
        │  devops-lab-orders  │   1 RCU / 1 WCU   ← the trap
        └─────────────────────┘

  4 CloudWatch alarms ──► SNS ──► Lambda bridge ──► DevOps Agent webhook
  EventBridge (source: aws.aidevops) ──► CloudWatch Logs

The whole trick, in two parameters

WriteFanout:          # items written per API request. 1 = healthy.
  Default: '1'
TableWriteCapacity:   # provisioned WCU. Deliberately tiny.
  Default: 1

The Lambda branches on WRITE_FANOUT:

if WRITE_FANOUT <= 1:
    _table.put_item(Item=_order_item(order_id))          # healthy
    return _response(201, {"orderId": order_id, "writes": 1})

# the "optimisation" that broke production
with _table.batch_writer() as batch:
    for line_no in range(WRITE_FANOUT):
        batch.put_item(Item=_order_item(f"{order_id}#{line_no}", line_no))

Three details make this behave like a real incident rather than a toy.

Padded items. Each item carries a 900-byte notes field so it costs a full write capacity unit. Without padding, DynamoDB's per-item rounding hides the problem.

A deliberately short retry budget.

_ddb = boto3.resource("dynamodb",
    config=Config(retries={"max_attempts": 2, "mode": "standard"}))

The boto3 default of ~10 adaptive retries would absorb the throttling and turn a hard failure into mysterious latency. Two attempts means throttling surfaces as a real error, a real Lambda invocation failure, and a real API 5xx.

One BatchWriteItem, not 25 calls. batch_writer() buffers and flushes in batches of 25, which is the BatchWriteItem API maximum. With WRITE_FANOUT=25 each invocation issues exactly one request carrying 25 items. Remember this detail — it becomes the cleanest proof in §11.

Everything is in one SAM template with structured JSON logging, X-Ray on, 7-day log retention, and four alarms whose AlarmDescription fields contain actual runbook text. That last point matters more than it looks; see §7.

6. Onboarding in 20 minutes

Four supported paths: Console, AWS CLI, CloudFormation/CDK (AWS::DevOpsAgent::AgentSpace + AWS::DevOpsAgent::Association), and Terraform (awscc_devopsagent_agent_space). If you have a choice, use IaC — this is production access configuration and it belongs in version control.

The CLI path, condensed:

REGION=us-west-2
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)

# 1. role the service assumes to read your account
cat > trust.json <<EOF
{"Version":"2012-10-17","Statement":[{
  "Effect":"Allow",
  "Principal":{"Service":"aidevops.amazonaws.com"},
  "Action":"sts:AssumeRole",
  "Condition":{
    "StringEquals":{"aws:SourceAccount":"$ACCOUNT"},
    "ArnLike":{"aws:SourceArn":"arn:aws:aidevops:$REGION:$ACCOUNT:agentspace/*"}}}]}
EOF

aws iam create-role --role-name DevOpsAgentRole-AgentSpace \
  --assume-role-policy-document file://trust.json
aws iam attach-role-policy --role-name DevOpsAgentRole-AgentSpace \
  --policy-arn arn:aws:iam::aws:policy/AIDevOpsAgentAccessPolicy

# 2. role your humans use in the web app
#    (same trust policy, plus sts:TagSession)
aws iam attach-role-policy --role-name DevOpsAgentRole-WebappAdmin \
  --policy-arn arn:aws:iam::aws:policy/AIDevOpsOperatorAppAccessPolicy

# 3. the space
aws devops-agent create-agent-space --name "prod-ops" --region $REGION

# 4. let it discover the account
aws devops-agent associate-service --agent-space-id $SPACE --service-id aws \
  --configuration "{\"aws\":{\"assumableRoleArn\":\"arn:aws:iam::$ACCOUNT:role/DevOpsAgentRole-AgentSpace\",\"accountId\":\"$ACCOUNT\",\"accountType\":\"monitor\"}}" \
  --region $REGION

# 5. turn on the web app
aws devops-agent enable-operator-app --agent-space-id $SPACE --auth-flow iam \
  --operator-app-role-arn "arn:aws:iam::$ACCOUNT:role/DevOpsAgentRole-WebappAdmin" \
  --region $REGION

The four things that bite

1. Your AWS CLI is probably too old. The first wall:

$ aws --version
aws-cli/2.32.22 Python/3.13.11 Windows/11 exe/AMD64

$ aws devops-agent help
aws: [ERROR]: argument command: Found invalid choice 'devops-agent'

winget upgrade --id Amazon.AWSCLI --accept-source-agreements
# or download https://awscli.amazonaws.com/AWSCLIV2.msi

The CLI and the SDK move independently, and that bites in both directions. On the same machine, at the same moment: the CLI rejects devops-agent outright, while boto3 1.43.6 / botocore 1.43.7 has a working devops-agent client. So every aws devops-agent … command in this post has a two-line Python equivalent that works before you upgrade anything:

import boto3
boto3.client("devops-agent", region_name="us-west-2").get_account_usage()

The subtler version of the same problem: that boto3 build has get_operator_app and it returns HTTP 200 — but its response model is missing the operatorAppUrl field a newer botocore returns. You get a successful call with silently absent data, no error. If a field the docs promise isn't in your response, upgrade before you debug anything else.

(If you're stuck: the web app URL is deterministic — https://<agentSpaceId>.aidevops.global.app.aws.)

2. iam:CreateServiceLinkedRole is not in the managed policy. Topology discovery uses AWS Resource Explorer, and the agent role needs to create Resource Explorer's service-linked role. AIDevOpsAgentAccessPolicy doesn't grant it:

{"Version":"2012-10-17","Statement":[{
  "Sid":"AllowCreateServiceLinkedRole",
  "Effect":"Allow",
  "Action":["iam:CreateServiceLinkedRole"],
  "Resource":["arn:aws:iam::ACCOUNT:role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer"]}]}

Skip it and discovery quietly under-performs.

3. The IAM auth link into the web app expires in 10 minutes. Fine for a first look, useless for an on-call rotation. Wire up IAM Identity Center (or a direct OIDC IdP — Okta, Entra ID) before handing this to a team.

4. Two consoles, and the split is not intuitive. Admins configure Agent Spaces in the AWS Management Console. Operators do all actual work — investigations, chat, topology, recommendations — in a separate web app on its own domain, outside the AWS console. If you're hunting for the investigation UI in the AWS console, you won't find it.

Confirm it's actually alive

Onboarding "succeeding" and the agent working are different things. I wrote a status script (lab/scripts/agent_status.py) that pulls the whole picture in one go. Its real output against my space, before I did anything:

=== account agent-hours this month (us-west-2) ===
  investigations : 0.00h (no cap)
  evaluations    : 0.00h (no cap)
  learning       : 0.00h (no cap)
  on-demand/chat : 0.00h (no cap)

=== my-first-devops-agent  (<agentSpaceId>) ===
  web app     : https://<agentSpaceId>.aidevops.global.app.aws
  association : aws <account-id> monitor -> valid
    webhooks  : none  <-- nothing can page this agent
  tasks       : 1
    [FAILED   ] SYSTEM_LEARNING  Create Agent Space Understanding Skills  <-- FAILED
  prevention recommendations : 0
  goal        : ONCALL_REPORT [ACTIVE] rate(7 days) (ENABLED)

Read that carefully, because it's the honest state of a "successfully onboarded" Agent Space:

association valid ✓
zero webhooks — nothing in the world could trigger an investigation
the initial learning task FAILED three weeks earlier and nothing told me
zero recommendations, zero agent-hours consumed

This space had been sitting there doing nothing since 6 July. That's less a criticism of the product than a warning about the onboarding experience: there is no green light. Run something like this on a schedule.

7. Wiring alarms to the agent

The user guide lists three ways an investigation starts:

Built-in integrations — a ServiceNow ticket, a Dynatrace problem, a Datadog event, a Splunk or New Relic alert, a PagerDuty incident
Webhooks — generic HTTP POST, HMAC or bearer-token authenticated
A human clicking Start investigation in the web app

A CloudWatch alarm is not on that list, and neither is SNS. There's no alarm action, no built-in CloudWatch integration, no EventBridge-as-input. If CloudWatch alarms are your alerting — which for most AWS-native serverless shops they are — you have to build glue.

I want to be careful here, because when I first drafted this section I got it wrong twice, and both errors are instructive.

Correction 1: this is well documented, just not in the user guide. AWS has published this pattern at least four times — the Networking & Content Delivery blog's automated network incident response post (with a deployable CloudFormation template on aws-samples), the Security blog's Network Firewall troubleshooting post, and two repost.aws articles. One of those repost articles opens by noting CloudWatch Alarms are the most commonly requested integration. So: a real gap in the product, thoroughly covered in the blogs. Search them before you write anything — the samples are good and will save you an afternoon.

Correction 2: there is an API path, and I missed it. I originally wrote that no StartInvestigation API exists, which is true of the name and false in substance:

aws devops-agent create-backlog-task \
  --agent-space-id $SPACE \
  --task-type INVESTIGATION \
  --priority HIGH \
  --title "devops-lab-api-5xx in ALARM" \
  --description "$ENRICHED_CONTEXT" \
  --client-token "cw-devops-lab-api-5xx-2026-07-31T16:56:30" \
  --region us-west-2

--task-type accepts INVESTIGATION, EVALUATION, RELEASE_READINESS_REVIEW and RELEASE_TESTING. create-backlog-task was sitting in the command surface I'd already enumerated and I read it as ops-backlog bookkeeping rather than an investigation entrypoint. It's the mechanism behind the repost.aws pattern that bridges Incident Detection and Response alarms via EventBridge → Lambda → CreateBacklogTask.

That matters, because it means there is a path with no webhook, no shared secret, and no console step.

The two paths, side by side

	Path A: SNS → Lambda → webhook	Path B: EventBridge → Lambda → `CreateBacklogTask`
Auth	HMAC-SHA256 or bearer token	SigV4 / IAM
Secret to manage	Yes — signing secret in Secrets Manager	None
Console step required	Yes — generic webhook creation has no API	No
Fully IaC-able	No (the webhook is created by hand)	Yes
Idempotency	`incidentId` you construct	`--client-token`
Links back to an external system	Via `data` payload	`--reference` (system, id, URL, association)
Incident lifecycle updates	`action: created\	updated\
Same wire format third-party tools use	Yes	No
AWS sample available	Yes, CloudFormation on aws-samples	Yes, repost.aws walkthrough

Which to pick. If you want the whole thing in version control with no click-ops and no secret rotation, Path B. If you're already receiving alerts from Datadog or PagerDuty and want CloudWatch alarms arriving through the same door in the same shape, Path A. Path A is also the better-trodden route — it's what the aws-samples templates use.

One thing I have not verified, and neither AWS post addresses: whether a {% raw %}CreateBacklogTask investigation passes through the same triage stage that webhook-delivered incidents do — the stage that decides LINKED / SKIPPED / PROCEED and dedupes related alarms inside a ~20-minute window (§8). That behaviour is documented for incoming incidents, not for API-created tasks. If you depend on triage correlation to avoid paying for three investigations of one outage, test this before committing to Path B. I'd rather flag the unknown than guess.

Path A, and the parts the samples leave to you

I built Path A, because I wanted the same payload shape a Datadog or PagerDuty alert would arrive in. It's about 40 lines.

Step 1 — generate a generic webhook. This step genuinely has no API. In the console: your Agent Space → Capabilities → Webhook → Configure → Generate webhook, and choose HMAC or API key.

Choose HMAC, and know why:

	HMAC	Bearer token
Payload integrity	Verified — tampering invalidates the signature	Not verified
Replay protection	Built in via the signed timestamp	None; a captured token works until rotated
Secret on the wire	Never sent, only the signature	Sent on every request
Setup	Compute a signature per request	Paste a static header

Store the secret in Secrets Manager. You cannot retrieve it again.

Step 2 — SNS → Lambda → webhook. Signing is stdlib-only:

timestamp = datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%S.000Z")
signature = base64.b64encode(
    hmac.new(secret.encode(),
             f"{timestamp}:{body.decode()}".encode(),
             hashlib.sha256).digest()
).decode()

headers = {
    "Content-Type": "application/json",
    "x-amzn-event-timestamp": timestamp,
    "x-amzn-event-signature": signature,
}

The signed string is timestamp:payload, not the payload alone. Get that wrong and you get a 4xx with no useful detail.

Step 3 — translate properly. Getting a 200 back is the easy part, and it's where the published samples stop. Translation quality is what separates a useful investigation from four paid minutes of the agent rediscovering your account layout. The schema:

{
  "eventType": "incident",
  "incidentId": "string",                  // dedupe key
  "action": "created|updated|closed|resolved",
  "priority": "CRITICAL|HIGH|MEDIUM|LOW|MINIMAL",
  "title": "string",
  "description": "string",                 // the agent reads this first
  "timestamp": "2026-07-31T16:56:31.000Z",
  "service": "string",
  "data": { }                              // raw upstream event
}

Three things a naive JSON.stringify(alarm) gets wrong:

CloudWatch alarms have no severity. The triage stage uses priority to decide whether to investigate independently, link, or skip. Map it deliberately:

PRIORITY_RULES = (
    ("api-5xx",             "CRITICAL"),   # customers see this
    ("ddb-write-throttled", "HIGH"),
    ("errors",              "HIGH"),
    ("latency",             "MEDIUM"),
)

incidentId must be stable per transition, not per delivery. SNS is at-least-once. Key on alarm name plus state-change time truncated to the second, so redeliveries dedupe instead of spawning duplicate paid investigations:

f"cw-{alarm_name}-{alarm['StateChangeTime'][:19]}"

The description is your prompt. A raw alarm gives the agent a metric name and a threshold. Give it identifiers instead — and this is where those AlarmDescription runbooks pay off:

Threshold Crossed: 1 datapoint [161.0 (31/07/26 16:55:00)] was >= threshold (1.0).

Alarm: devops-lab-ddb-write-throttled
Intent: Orders table is rejecting writes. Customer order submissions are failing.
        Runbook: check ConsumedWriteCapacityUnits against provisioned WCU and
        recent deploys to devops-lab-orders.
Account: <account-id>
Region: US West (Oregon)
Metric: AWS/DynamoDB/ThrottledRequests
Dimensions: {"TableName": "devops-lab-orders", "Operation": "BatchWriteItem"}
Application: devops-agent-lab (serverless order API: API Gateway HTTP API ->
             Lambda devops-lab-orders -> DynamoDB devops-lab-orders)

That's the actual payload my bridge produced during the incident, copied from CloudWatch Logs. Every line is something the agent would otherwise burn paid agent-seconds discovering — or guess wrong about.

Practical note: write your bridge so it works before the webhook exists. Mine takes the webhook URL as a template parameter, and when it's empty it logs the exact payload it would have sent under {"event": "webhook_not_configured", "wouldHaveSent": {...}}. That let me verify the entire pipeline — priority mapping, dedupe keys, description assembly — without spending a cent, and gave me the payloads quoted above. The AWS samples take the equivalent precaution differently: their bridge skips delivery while the secret still holds a placeholder.

One piece of advice in the AWS post I'd push back on. Its "further considerations" section suggests adding correlation logic to the Lambda — buffering alarms in DynamoDB on a 60-second window, grouped by application — to stop one root cause spawning duplicate investigations. The problem is real: my incident fired three alarms 71 seconds apart for one cause. But the agent already has a triage stage that correlates incoming incidents within roughly a 20-minute look-back and marks them LINKED, which is a wider window and a richer comparison than name-matching in your own Lambda. Before you build and operate a DynamoDB dedupe table, send the alarms through unbuffered and watch for Investigation Linked on the EventBridge bus (§15). If triage is already doing the job, you've saved yourself a stateful component in your alerting path — and if it isn't, you'll have the evidence to justify building one.

8. Breaking production on purpose

Deploy healthy, prove it's healthy, ship the bad change, apply load. All timestamps UTC, 31 July 2026.

Baseline — 60 requests, 10 concurrent:

sent      : 60 in 6.0s (10.0 rps)
status    : {201: 60}
p50 / p95 : 0.79s / 2.03s
error rate: 0.0%

The bad deploy — WriteFanout: 1 → 25. Nothing else changes. No IAM change, no new resource, no infrastructure diff. Exactly the kind of one-line change that sails through review.

16:54:52  deploy starts
16:55:34  deploy completes   (UPDATE_COMPLETE, OrdersFunction updated)

Load — 400 requests, 40 concurrent:

16:55:47  load starts
sent      : 400 in 13.6s (29.3 rps)
status    : {201: 88, 500: 52, 503: 260}
p50 / p95 : 0.87s / 2.55s
error rate: 78.0%
16:56:00  load ends

78% of customer requests failed. Note the split: 52 × 500 and 260 × 503. Two different failure modes, and that turns out to matter (§12).

A note on latency numbers, because two sets appear in this post and they disagree. The p50 / p95 figures above are client-side, measured by my load generator, so they include TLS handshake and connection setup from a cold Python client. The p99 figures the agent reports in §11 are API Gateway's server-side Latency metric. Server-side p99 at baseline was 1,228 ms against my client-side p95 of 2,030 ms — not a contradiction, just a different measuring point. When you cross-reference an agent's output against your own numbers, check you're comparing the same vantage point before you conclude it's wrong.

The pages, from CloudWatch alarm history:

16:55:51  first ProvisionedThroughputExceededException in Lambda logs
16:56:30  devops-lab-api-5xx            OK -> ALARM   (55 5xx in the 16:55 minute)
16:56:31  bridge posts CRITICAL incident to DevOps Agent
16:56:56  devops-lab-orders-errors      OK -> ALARM   (50 Lambda errors at evaluation
                                                     time; the minute finalised at 52)
16:56:56  bridge posts HIGH incident
16:57:41  devops-lab-ddb-write-throttled OK -> ALARM  (161 throttled BatchWriteItems)
16:57:41  bridge posts HIGH incident

Two numbers worth writing down:

39 seconds from first customer-visible error to first page. That's the floor for a 1-minute-period, 1-datapoint CloudWatch alarm, and no agent can beat it — detection latency is yours to own.
~1 second from alarm state change to the agent having a signed, enriched incident. The bridge is not the bottleneck.

Also: the three alarms fire 71 seconds apart for one root cause — exactly the pattern the triage stage exists to handle.

9. The evidence chain

An investigation is only as good as what's on the table. Everything the agent could reach, straight from CloudWatch.

DynamoDB consumed write capacity (Sum per minute, against 1 provisioned WCU = 60 WCU/minute):

Minute	ConsumedWriteCapacityUnits	Verdict
16:53	0	idle
16:54	60	baseline, exactly at budget
16:55	2,200	36.7× over budget
16:56	0	load over — trailing throttles, no successful writes

Throttling — and this is where you need to be careful which metric you read:

Metric	16:55	16:56	17:00	What it counts
`WriteThrottleEvents`	4,025	125	6	individual throttled write events (items)
`ThrottledRequests` (`Operation=BatchWriteItem`)	161	5	0	throttled requests

4,025 = 161 × 25, and 125 = 5 × 25. The ratio between the two metrics is exactly the fanout factor. That's not a coincidence, and the DynamoDB docs explain why: a single request produces multiple write events, WriteThrottleEvents increments once per throttled event, and for BatchWriteItem the ThrottledRequests metric is only incremented when all the individual put/delete events in the batch are throttled. So 161 fully-throttled batches × 25 items each = 4,025 throttled item-events.

Two implications:

Pick your metric on purpose. ThrottledRequests masks the true extent of throttling — the AWS docs say so explicitly and recommend comparing it against the event-level metrics. My alarm used ThrottledRequests, which is fine for detection but understates blast radius by 25×.
This arithmetic is also the proof of what the code did — one BatchWriteItem per invocation carrying 25 items. Hold that thought until §11.

Lambda: Errors 52, Throttles 260, both in the 16:55 minute. Average duration 52.6 ms → 625.2 ms, max 2,917 ms.

The log line that names the culprit:

{
  "event": "order_write_failed",
  "level": "ERROR",
  "requestId": "BYX_lg6wvHcEPjw=",
  "route": "POST /orders",
  "errorType": "ProvisionedThroughputExceededException",
  "error": "An error occurred (ProvisionedThroughputExceededException) when calling
            the BatchWriteItem operation (reached max retries: 2): The level of
            configured provisioned throughput for the table was exceeded...",
  "table": "devops-lab-orders",
  "writeFanout": 25
}

That "writeFanout": 25 is deliberate, and it's the single highest-leverage thing in this lab. Log the feature flags and config values that changed behaviour, in the error path. It converts "correlate the deployment timeline against metric anomalies and hypothesise" into "read one field". It costs nothing and saves an entire investigative branch.

The chain the agent needs to assemble:

customer 5xx
  → Lambda invocation errors
    → ProvisionedThroughputExceededException on BatchWriteItem
      → 2,200 WCU consumed vs 1 WCU provisioned
        → BatchWriteItem where there used to be PutItem
          → CloudFormation UPDATE_COMPLETE on OrdersFunction at 16:55:34,
            12 seconds before the first error
            → WriteFanout parameter 1 → 25

Seven hops across four services, symptom three services away from cause. This is the shape of problem DevOps Agent is built for.

10. Asking the agent

The DevOps Agent web app chat panel. Left sidebar: Pages (Incidents, Improvements, Artifacts, Topology), Chats, Agents, Knowledge, Settings, and the account/space footer <account-id> / my-first-devops-agent. The conversation shows the stack-history question and the agent's tool count.

I started in chat rather than through the webhook, because that's what an engineer actually does when they notice something odd. First question, deliberately mundane:

Me: so can you say about my devops-agent-lab cloudformation stack — how many times it is updated and with what changes

Agent: Let me look into the CloudFormation stack history for devops-agent-lab — I'll check the update history and what changes were made each time.

10 tools · 1 agent used

It came back with a table:

#	Operation	Time (UTC)	Duration	What Changed
1	CREATE	16:51:40	~1m 15s	Full stack creation
2	UPDATE	16:55:14	~14s	OrdersFunction — WRITE_FANOUT set to "25"
3	UPDATE	16:59:35	~14s	OrdersFunction — WRITE_FANOUT reverted to "1"
4	UPDATE	17:01:28	~2m 33s	OrdersTable — billing mode switched to PAY_PER_REQUEST

All four rows match my deploy logs. But the part I didn't expect was the closing note:

Notable Context — The stack description identifies it as "a deliberately fragile serverless order API used to generate real, diagnosable production incidents" — so the fan-out injection was intentional lab activity, not an accidental misconfiguration.

It read the CloudFormation Description field and used it to reason about intent. Nobody told it this was a lab. That's a small thing, but it's the difference between a metrics query and an operational teammate: it distinguished "someone broke this on purpose" from "this is an incident", which is exactly the judgement call you want before it starts paging people.

The moment it refused

Then I pushed:

Me: so does that load thing happened on dynamodb can you investigate

And the agent declined to answer in chat:

Agent: This sounds like open-ended root-cause work — figuring out what actually happened to DynamoDB during that write fanout spike is the kind of multi-signal investigation (metrics, logs, traces, changes) that the Investigation agent is built for.

Want me to open a tracked investigation into the DynamoDB load impact from the WRITE_FANOUT spike, or keep digging here in chat?

Me: Open an investigation

Agent: Let me get that started right away!

1 tool · 1 skill used

The investigation is up and running! 🎉 DynamoDB load impact from WRITE_FANOUT spike on devops-agent-lab — It's scoped to the key questions: DynamoDB throttling, Lambda errors during the fanout window, whether the billing mode switch resolved things, and any downstream blast radius. It'll correlate metrics, logs, and the change timeline from July 31st.

This is worth dwelling on, and it's the single most useful product behaviour I saw.

The chat agent recognised that my question exceeded what a conversational answer should cover, named the reason, and offered to escalate to a tracked, billable investigation rather than silently producing a confident-sounding chat reply. It asked before spending my money. It also pre-scoped the investigation — throttling, Lambda errors, whether the fix worked, blast radius — which is a better scope than the one-line question I'd typed.

Two practical notes for anyone budgeting this:

Chat and investigations are metered separately (monthlyAccountOnDemandHours vs monthlyAccountInvestigationHours) at the same $0.0083/agent-second. The chat exchanges above are on-demand seconds; the investigation is investigation seconds.
This is a third way to start an investigation that isn't in the docs' list of three — a human escalating from chat. Practically it's the same as clicking Start investigation, but the ergonomics are much better because the agent writes the scope for you.

11. The investigation, graded claim by claim

The investigation detail view with **Investigation timeline* and Root cause tabs, showing the agent's generated latency charts: average latency peaking at 245 ms during throttling, p99 spiking to 2,401 ms, and a backend-latency chart used to confirm Lambda/DynamoDB as the bottleneck. Note the chart x-axis renders in browser-local time (IST) while the narrative text is UTC.*

Here's what it produced. I've quoted it, then checked every number against CloudWatch myself.

What it said

Impact 1 — DynamoDB OrdersTable massive write throttling during WRITE_FANOUT=25 window

DynamoDB table devops-lab-orders experienced 4,025 WriteThrottleEvents at 16:55 UTC and 125 at 16:56 UTC when WRITE_FANOUT was changed from 1 to 25. ConsumedWriteCapacityUnits spiked 36.7x from baseline 60 to 2,200. The provisioned capacity was completely overwhelmed. Throttling dropped to 6 residual events at 17:00 and ceased after the PAY_PER_REQUEST billing mode change at 17:01. Impact lasted approximately 5 minutes.

Impact 2 — Lambda OrdersFunction errors (52) and throttles (260) during fanout burst

52 errors (ProvisionedThroughputExceededException after 2 retries on BatchWriteItem) and 260 invocation throttles at 16:55 UTC. Duration spiked 12x from 52ms to 625ms average (max 2917ms). Concurrency was pegged at 10 (reserved limit). The combination of longer-running invocations (due to DDB retry backoff) and capped concurrency caused massive throttling. Recovery by 17:04.

Impact 3 — API Gateway returned 312 5xx errors (78% error rate) at peak

312 out of 400 requests as 5xx at 16:55 UTC (78% error rate). p99 latency peaked at 2.4 seconds (from ~1.2s baseline). No 4xx errors. Full recovery by 17:04.

Root cause

At 16:55 UTC the WRITE_FANOUT environment variable on Lambda function devops-lab-orders was changed from '1' to '25'. This caused each Lambda invocation to execute 25 BatchWriteItem operations to DynamoDB instead of 1, resulting in a 36.7x increase in consumed write capacity units (60 → 2,200 WCU/min).

Key finding 2 — Lambda concurrency exhaustion due to increased invocation duration from DDB retry backoff

With DynamoDB throttling, the Lambda SDK retried BatchWriteItem with exponential backoff, causing average duration to spike from 52ms to 625ms (max 2917ms). With a reserved concurrency limit of 10 and invocations taking 12x longer, the function could only serve ~16 requests/second. This resulted in 260 Lambda throttles at 16:55 — the vast majority of incoming requests were rejected before even reaching the function code.

What checks out

I re-pulled every metric. The impact numbers are not approximately right, they're exactly right:

Agent's claim	My measurement
4,025 / 125 / 6 `WriteThrottleEvents`	4,025 / 125 / 6	✅
36.7× spike, 60 → 2,200 WCU	60 → 2,200 (2200/60 = 36.67)	✅
52 errors, 260 throttles	52 / 260	✅
52 ms → 625 ms avg, max 2,917 ms	52.6 → 625.2, max 2,917.3	✅
312 of 400 = 78% error rate	API Gateway `5xx` = 312, `Count` = 400 at 16:55. Client histogram: 52×500 + 260×503 = 312	✅
"No 4xx errors"	`4xx` = 0 across every datapoint	✅
Trailing errors: 5 at 16:59, 2 at 17:00, 15 at 17:04	5 / 2 / 15 — datapoint for datapoint	✅
"Total ~334 5xx during incident"	sum of all `5xx` datapoints = 334	✅
p99 2,401 ms at 16:55, from ~1.2 s baseline	`Latency` p99 = 2,401 ms at 16:55; 1,228 ms at 16:54	✅
p99 elevated 1,199–1,729 ms through 17:00, recovered to 172 ms by 17:04	1,199 / 1,729 / 172	✅
Average latency peaked at 245 ms, 184 ms at 16:59, ~32 ms by 17:04	245 / 184 / 32	✅
"Backend latency nearly identical to total latency"	`IntegrationLatency` p99 2,401 vs `Latency` p99 2,401	✅
Root cause: `WRITE_FANOUT` 1 → 25	exactly what I injected	✅
Recovery by 17:04, throttling ceased after 17:01	matches	✅

The trailing-error breakdown deserves a callout. 5 at 16:59, 2 at 17:00, 15 at 17:04 is not a rounded summary — those are three individual CloudWatch datapoints reproduced exactly, and they're the fingerprint of my rollback (the 7 errors at 16:59–17:00) and my final verification run (the 15 at 17:04). It didn't just find the incident; it found the two things I did after the incident and folded them into the recovery narrative correctly.

More impressive than the numbers: the causal chain in Key Finding 2 is better than the one I had written down before running it. I had the 500s and the 503s as two separate root causes. The agent connected them: DynamoDB throttling → SDK retry backoff → 12× longer invocations → concurrency slots drained → invocations rejected before the code runs → 503s. The two failure modes weren't independent after all; the first amplified the second. That's a genuinely better explanation and I had to go back and correct my own draft.

Two of its methodological choices are worth stealing.

It chose WriteThrottleEvents over ThrottledRequests — the event-level metric AWS docs recommend for understanding true extent (§9). That's the right call, and not the obvious one; the request-level metric is the one most people alarm on.

It compared IntegrationLatency against Latency to localise the delay. API Gateway emits both: total round-trip and time spent waiting on the backend. If they track each other, the time is downstream; if Latency exceeds IntegrationLatency, the gateway itself is the problem. At 16:55 both p99s were 2,401 ms — identical — which is what let it state "confirming Lambda/DynamoDB as the bottleneck" rather than guessing. That's a textbook diagnostic technique applied unprompted, and it's the sort of thing that separates this from a metric dump.

What doesn't

Two mechanism errors. Both reach the right conclusion by a wrong route.

Error 1 — "execute 25 BatchWriteItem operations instead of 1." It's one BatchWriteItem carrying 25 items. BatchWriteItem maxes out at 25 items per request and boto3's batch_writer() flushes at exactly that boundary, so WRITE_FANOUT=25 produces a single request per invocation.

The proof is in the metrics the agent itself quoted. Across the two burst minutes (16:55 and 16:56): ThrottledRequests 161 + 5 = 166, WriteThrottleEvents 4,025 + 125 = 4,150 — a ratio of exactly 25. If there had been 25 separate BatchWriteItem calls per invocation, ThrottledRequests would have been in the thousands, not 166.

Impact: cosmetic here. It doesn't change the diagnosis or the fix.

Error 2 — "a reserved concurrency limit of 10." This one matters.

$ aws lambda get-function-concurrency --function-name devops-lab-orders
{}

$ aws lambda get-account-settings
{ "AccountLimit": { "ConcurrentExecutions": 10,
                    "UnreservedConcurrentExecutions": 10 } }

There is no reserved concurrency on this function — my template never sets any, and GetFunctionConcurrency returns empty. The limit of 10 is the account-level concurrency quota, where the Lambda default is 1,000. This account has never had a quota increase and is sharing 10 slots across 43 functions in the region.

The agent saw ConcurrentExecutions max out at 10 and inferred a function-level reservation. Understandable, and wrong in a way that changes what you'd do about it:

If it were reserved concurrency: edit the function's concurrency configuration. Two minutes, self-service, in the template.
Because it's the account quota: raise it through Service Quotas, which is a support request with a turnaround, and it affects all 43 functions in the region.

An engineer handed this RCA at 3 AM would go looking for a setting that isn't there.

The honest reading of this

AWS markets "94% root cause accuracy" for DevOps Agent. Having now graded one investigation line by line, I think I understand the shape of the residual, and it's not what I expected. The failure mode isn't "the agent hallucinates an unrelated cause". It's:

The verdict is right. The numbers are right, sometimes to the decimal. And a mechanism detail in the middle is stated with exactly the same confidence as everything else, while being wrong.

There's no hedging in the output, no confidence score on individual claims, nothing that flags "I inferred this rather than read it". Concurrency was pegged at 10 (reserved limit) reads identically to 4,025 WriteThrottleEvents at 16:55, and one is a direct metric read while the other is an inference that happens to be false.

Which is a completely workable tool, as long as you use it as "here is a correct conclusion and an evidence trail, check the middle before you act" rather than "here is the answer". That's also precisely why §13 matters more than any feature on the pricing page.

A small presentation nit while I'm here: the chart axes in the investigation view render in browser-local time while the narrative text is in UTC. My screenshots show a 22:23–22:34 axis for a 16:53–17:04 UTC window — correct, but +5:30, and easy to misread when you're cross-referencing against CloudWatch at speed.

12. The second root cause

This section originally argued that DevOps Agent would find the concurrency limit where a code-focused agent never would. It's worth reporting what actually happened, because the outcome was better than my prediction in one way and worse in another.

The setup: my load test returned 52 × 500 and 260 × 503. The 500s are DynamoDB throttling. The 503s are something else — Throttles, not Errors, meaning those invocations never ran. The cause is an account-level Lambda concurrency quota of 10, against a default of 1,000, shared across 43 functions. With 40 concurrent client threads and 10 available slots, most requests were rejected before my code executed.

I did not plant this. I found it while working out why the two error codes disagreed.

What I predicted: point any code-focused AI at this repository and it finds the WRITE_FANOUT bug immediately — it's right there in the diff. It never finds the concurrency limit, because the limit isn't in the code, isn't in the template, isn't in the logs and isn't in the alarm. It's an account-level quota that only exists in the environment.

What happened: DevOps Agent found the concurrency exhaustion, unprompted, and did better than I did by connecting it causally to the DynamoDB throttling via retry backoff. Then it mislabelled the source of the limit as reserved concurrency.

So the thesis holds, with a sharper edge than I'd have written on my own: the environment-level cause is exactly the class of thing only an environment-aware agent surfaces at all — and also exactly the class of thing it's most likely to get subtly wrong, because quotas, reservations and defaults all present identically in a metric graph. The metric shows you a ceiling at 10. It does not tell you which of four different mechanisms put it there.

That combination is the real argument for the audit journal.

One more finding, mine not the agent's: I had no alarm on Lambda Throttles, so 260 of 312 failed requests — 83% — never paged anyone. The alarms I did have fired on the smaller failure mode. Exactly the kind of gap the prevention evaluation is supposed to hand you.

13. Reading the agent's mind

Every execution writes an immutable journal you can read over the API:

aws devops-agent list-journal-records \
  --agent-space-id $SPACE --execution-id $EXECUTION --region us-west-2

Remember the FAILED learning task from §6? Here's what actually happened, reconstructed from its 119 journal records.

It started at 08:14 UTC with the prompt understanding-agent-space: Create understanding of the agent space. Its first move was to read its own instructions and check for code repositories:

"I need to create an understanding-agent-space skill, which falls within my capabilities. I'm starting by reading the relevant skill documentation and gathering context about the agent space by listing available repositories."

Finding no repositories, it reasoned about which workflow steps to skip:

"Looking at what's available: the repository list is empty so there's no codebase to discover, I have one AWS account active, and today's date is July 6, 2026. Most steps will be skipped — no prior state files exist, no observability tools are configured beyond AWS, and no member skills are loaded. The main work is discovering the topology for that AWS account."

Then it partitioned my account by CloudFormation stack:

"This is one AWS account hosting **multiple independent applications, concentrated in us-east-1 and us-west-2, with minimal footprint in ap-south-1. CloudFormation stacks give me strong boundary signals: **AiTravelConcierge* — 5 stacks (Api, Compute, Data, MockApi, Orchestration); HealthFormMvp, RetailMindAI, SelfHealingAiAgent, email-agent — 1 stack each. Scaffolding to ignore: CDKToolkit, aws-sam-cli-managed-default."*

All five applications, correctly bounded, scaffolding correctly discarded — from stack topology alone, with no repository access.

It then spawned seven sub-agents in parallel, wrote 11 container reference files, and self-validated its own output:

"All 11 container reference files and SKILL.md are written. Now let me validate the skill output before mirroring to memory. Let me check for template/placeholder leftovers and confirm every graph node has both icon and description."

The journal also exposes the machinery. Aggregated from the utilization records:

--- summary ---
peak context window : 74.7%
sub-agents spawned  : 7  [disc-aitravelconcierge, disc-emailagent, disc-healthform,
                          disc-retailmind, disc-selfhealing, disc-useast1-apsouth1,
                          scope-discovery]
tool calls          :
  fs_write                          13
  fs_read                           12
  list_resources                     5
  fs_tree                            4
  use_aws                            4
  fs_grep                            3
  list_repositories                  1
  get_topology_map                   1
  get_associations                   1
  get_account_cloudformation_stacks  1

So the agent has a working filesystem (fs_read/fs_write/fs_tree/fs_grep over paths like /aidevops/skills/learned/understanding-agent-space/SKILL.md), a generic use_aws escape hatch, and purpose-built topology tools. Context peaked at 74.7% with zero compactions.

And then — at 09:02 UTC, 48 minutes in, minutes after that final validation step — the task was marked FAILED.

Two conclusions, and I think they're the most useful paragraphs here.

The good one. After §11, this is no longer a nice-to-have. The agent produces confident prose containing occasional confidently-wrong details, and the journal is the only place you can see which claims came from a metric read and which came from an inference. No other agent product I've used lets me reconstruct a 48-minute autonomous run to this fidelity. Do not treat the journal as a compliance artifact. It's your primary verification surface, and you should know how to read it before an outage, not during one.

The bad one. The failure was invisible. The console gave me a working Agent Space. list-associations said valid. Nothing surfaced that the environment understanding the entire product is built on had never completed — and I only looked because I went digging with the API. Then, when I did find it, the journal recorded 119 records of successful work and no terminal error explaining the failure.

So: poll list-backlog-tasks and alarm on FAILED. Treat your agent as a production dependency with its own health check, because AWS hasn't given you one.

14. Fixing it

Mitigation 1 — roll back. The first thing any agent should recommend: revert the change, don't fix forward during an outage.

16:59:13  rollback starts  (WriteFanout 25 -> 1)
16:59:54  rollback complete

Result at 12.8 rps:

status    : {201: 113, 500: 2, 503: 5}
error rate: 5.8%

78% → 5.8%. But not zero, and that residual is the interesting part: at 12.8 rps with 1 KB items I need ~13 WCU and have 1. The rollback removed the 25× amplification, not the underlying fragility. It made the incident survivable; it did not fix the system. Any mitigation plan that stops at "reverted, closing the incident" is wrong.

Mitigation 2 — the durable fix. Switch the table to on-demand:

TableBillingMode:
  Type: String
  Default: PROVISIONED
  AllowedValues: [PROVISIONED, PAY_PER_REQUEST]

sent      : 200 in 6.6s (30.2 rps)
status    : {201: 185, 503: 15}
p50 / p95 : 0.78s / 0.93s
error rate: 7.5%

Zero 500s. Every DynamoDB error gone, at 2.4× the request rate that was still failing before. p95 improved from 1.83 s to 0.93 s — a 49% reduction, because the SDK is no longer burning retries against a throttled table. The agent independently confirmed this from the other direction: "Throttling … ceased after the PAY_PER_REQUEST billing mode change at 17:01."

The remaining 15 × 503 are the concurrency quota from §12 — which is the correct end state for this lab: one incident, two independent causes, one fixed by a deploy and one requiring a quota increase. Real outages look like this.

What prevention should produce

The ONCALL_REPORT goal runs on rate(7 days) across observability, infrastructure, pipelines and application resilience. Mine hadn't run against this incident at the time of writing (list-recommendations returns empty — I created the incident on the last day of the cycle). So rather than invent output, here's the list I derived by hand, which is the standard I'd hold it to:

#	Category	Recommendation	Evidence
1	Observability	Alarm on `AWS/Lambda Throttles`	260 throttles, 0 alarms — 83% of failures were invisible
2	Infrastructure	Raise the account concurrency quota from 10 (default 1,000)	40 concurrent clients, 10 slots
3	Infrastructure	`PAY_PER_REQUEST` on `devops-lab-orders`	2,200 WCU consumed vs 1 provisioned
4	Observability	Alarm on `ConsumedWriteCapacityUnits` > 80% of provisioned	the throttling alarm fired at 16:57:41, 110 s after the first customer error at 16:55:51
5	Observability	Alarm on `WriteThrottleEvents`, not just `ThrottledRequests`	the request-level metric understated blast radius by 25×
6	Pipeline	Load-test gate on changes to write-path parameters	a one-line parameter change caused a 78% error rate with no test that could catch it
7	Resilience	Handle `ProvisionedThroughputExceededException` explicitly; queue or shed instead of 500	every throttle became a customer-visible error
8	Pipeline	Canary or staged rollout for `devops-lab-orders`	the change went to 100% of traffic instantly

If your evaluation returns items 1 and 2 — the ones that require looking at the environment rather than the diff — it's earning its $7.47. If it only returns 3 and 7, you've paid for a linter.

15. Closing the loop

Getting a root cause into the web app is half a workflow.

Read the agent's decisions with EventBridge. DevOps Agent publishes to the default event bus under source aws.aidevops:

Investigation lifecycle: Created, Pending Triage, Priority Updated, In Progress, Completed, Failed, Timed Out, Cancelled, Linked, Skipped
Mitigation lifecycle: In Progress, Completed, Failed, Timed Out, Cancelled

Capture all of it from day one — cheapest possible instrumentation of your agent, and how you build an MTTR dashboard that isn't vibes:

InvestigationEventRule:
  Type: AWS::Events::Rule
  Properties:
    EventPattern:
      source: [aws.aidevops]
    Targets:
      - Id: log
        Arn: !GetAtt InvestigationEventLogs.Arn

Then filter for what you act on:

{ "source": ["aws.aidevops"],
  "detail-type": ["Investigation Completed", "Investigation Failed"] }

Watch Investigation Skipped and Investigation Linked especially closely in the first month. Those are the triage stage making judgement calls on your behalf.

Two-way flow needs a ticketing system. Only the built-in integrations (ServiceNow, PagerDuty, Slack, Microsoft Teams) get updates written back. A generic webhook is one-way: you push an incident in, findings appear in the web app, and nothing lands in the tool your team watches. If you want the agent posting an investigation timeline into Slack and updating the ticket as it goes, you need one of those integrations. Budget for it in your evaluation.

The Kiro handoff. Investigation output includes agent-ready instructions: a mitigation spec another frontier agent can implement. For my incident that's a clean division of labour — DevOps Agent determines that WRITE_FANOUT=25 against a 1-WCU table is the cause, Kiro implements the template change and the missing throttle alarm, release management reviews the PR for blast radius before merge. Three agents with different context boundaries, handing work between them, humans approving at the transitions.

Worth noting after §11: the handoff is also where a wrong mechanism detail would propagate. "Reserved concurrency limit of 10" fed to a coding agent produces a template change setting reserved concurrency — which would make things worse, since reserving from a pool of 10 starves the other 41 functions. Verify at the transition, not after.

Access from anywhere. The Agent Space runs as a remote server speaking MCP, ACP and A2A, so your own tools and agents can trigger investigations or query operational health without going through the web app.

16. Making the agent yours

Defaults get you a generic SRE. These knobs get you your SRE.

Skills — reusable Markdown instruction sets, optionally targeted to a specific agent type (Generic, On-demand, Incident Triage, Incident RCA, Incident Mitigation, Evaluation). Targeting matters: a triage-only skill doesn't consume context during RCA.

The highest-value first skill is a triage skip rule, because it stops you paying for investigations you don't want:

---
name: skip-scheduled-maintenance
description: Skip low-priority incidents during a scheduled maintenance window.
  Use this skill to automatically filter MEDIUM and LOW severity alarms that
  fire during planned maintenance, avoiding unnecessary investigations for
  expected disruptions.
---

# Skip Scheduled Maintenance

Skip incidents meeting BOTH criteria:
1. Arrived between 2026-08-15 02:00 UTC and 2026-08-15 06:00 UTC
2. Severity is MEDIUM or LOW

Do NOT skip HIGH or CRITICAL, even during the maintenance window.

Target it at Incident Triage. Every new Agent Space ships this as an inactive sample — activate and adapt rather than starting from scratch.

The second skill I'd write is the one §11 taught me to write. Note that it exists specifically to prevent the mistake the agent made:

---
name: serverless-throttle-triage
description: Investigation procedure for API Gateway 5xx and 503 responses on
  serverless order-processing APIs. Use when investigating elevated 5xx, 503,
  Lambda invocation errors, or DynamoDB throttling on devops-lab-orders.
---

# Serverless Throttle Triage

Distinguish 500 from 503 before forming a hypothesis. They have different causes,
and in this application the first one amplifies the second.

## 503 responses
Check `AWS/Lambda Throttles`. Then establish WHICH ceiling was hit, because the
remediation differs and the metric graph looks identical either way:
  1. `lambda get-function-concurrency` - is reserved concurrency set on the function?
     If empty, it is NOT reserved concurrency. Do not report it as such.
  2. `lambda get-account-settings` - `ConcurrentExecutions` is the account quota.
     Default is 1,000. A lower value means this account has never had an increase,
     and the fix is a Service Quotas request, not a function config change.
Concurrency exhaustion produces 503 with no application log entry at all.

## 500 responses
Check Lambda `Errors`, then search the log group for `order_write_failed` and read
the `writeFanout` field - it records the write-amplification config active at
failure time.
Compare `ConsumedWriteCapacityUnits` against provisioned WCU
(provisioned WCU x 60 = per-minute budget).

## Reading DynamoDB throttling correctly
`ThrottledRequests` counts requests and only increments when EVERY item in a
BatchWriteItem is throttled. `WriteThrottleEvents` counts individual items.
Prefer `WriteThrottleEvents` for blast radius. If the ratio between them is a
round number, that number is the batch size - which tells you the fanout.
boto3 `batch_writer()` flushes at 25 items, and BatchWriteItem accepts at most
25, so N<=25 items is ONE request, not N requests.

## Always
Check CloudFormation stack events for `devops-agent-lab` in the 15 minutes before
the first error. A parameter-only update changes behaviour without changing
resources and will not appear as a resource diff.

That's institutional knowledge that normally lives in one senior engineer's head — and writing it as a skill is how you stop the agent repeating an error you've already caught once.

Instructions — the AGENTS.md equivalent, applied to every task or scoped to specific agents. Use it for standing context: which accounts are production, who owns what, what "customer-impacting" means to you.

Memories — learned knowledge, created either by directing the agent in chat or by the managed learning skill distilling past investigations. The mechanism behind "the third DynamoDB throttling incident investigates faster than the first".

Triggers and custom agents — schedule work with create-trigger (cron/rate conditions), and build custom SRE agents for recurring tasks. AWS's own example is a daily ops report: 2 minutes a day, $29.88/month.

Ask for artifacts in chat. Chat generates versioned documents — "generate a weekly operational health report", then "add a section on Lambda cold starts" — which beats screenshotting dashboards into Confluence. You can also attach files (dashboard screenshots, YAML, a runbook PDF; 3.75 MB each, 20 per message) and have the agent reason over them.

Give feedback on investigations. After §11 this is not a nicety. A completed investigation has an Add feedback action where you rate the root cause correct/incorrect, supply the actual root cause, and note whether steering was needed. Feedback feeds accuracy metrics you can query in chat. For my investigation the honest verdict is "root cause correct, mitigation detail incorrect — the concurrency limit is the account quota, not reserved concurrency", and recording that is how the next one gets better.

17. What this cost, and how to tear it down

Roughly $0.15 in AWS infrastructure charges. Everything is serverless and short-lived: ~500 Lambda invocations on 256 MB arm64 (many requests were throttled before they ever invoked), ~2,600 DynamoDB write capacity units consumed in total, four alarms at $0.10/month, some CloudWatch queries. The 7-day log retention on every log group is deliberate — it's the line item that quietly grows in labs like this.

DevOps Agent charges: $6.83, measured. 191 agent-seconds of investigation ($1.59) plus 632 agent-seconds of chat ($5.25) — see §4 for the full breakdown and why the chat, not the investigation, was the expensive half. Check your Support-plan credits before you treat that as a cost (§4); for Enterprise Support customers it's likely fully covered.

Teardown:

sam delete --stack-name devops-agent-lab --region us-west-2

# only if you're done with the agent entirely - irreversible, destroys all
# investigations, topology and recommendations in the space
aws devops-agent delete-agent-space --agent-space-id $SPACE --region us-west-2

The Agent Space itself costs nothing while idle — it's per-agent-second, not per-space. Leave it. But do delete the SAM stack: a DynamoDB table provisioned at 1 WCU is a footgun to leave lying around.

18. Honest scorecard

Where it clearly earns its keep

Multi-service, multi-cause incidents. Mine had two causes in two layers, one of them not in the code at all. The agent found both and connected them causally better than I had.
Environment knowledge that isn't written down. The concurrency ceiling is invisible to anything reading only the repository.
Judgement, not just retrieval. It inferred from a CloudFormation Description that the fault injection was intentional. It declined to answer an open-ended RCA question in chat and asked permission to open a billable investigation instead. Both are the behaviour of a colleague, not a query engine.
Auditability. The journal is the best I've seen in any agent product, and §11 is why it's essential rather than nice.
Zero-setup onboarding for the team. One admin configures the space; every engineer inherits full context.
The economics on Enterprise Support. 75% of your support spend back as credits changes the calculation entirely.

Where you should temper expectations

It states inferences with the same confidence as measurements. Right verdict, exact numbers, and a mechanism detail in the middle that was confidently wrong and would have sent someone to a nonexistent setting. Verify the middle before you act on it. There is no per-claim confidence signal.
It cannot see your alarms without glue. No alarm action, no CloudWatch integration, no EventBridge input. You will write a Lambda. A genuine product gap, though a well-documented one — AWS covers both bridge patterns with deployable samples (§7). Read those first, then spend your effort on translation quality.
There is no health check. My learning task failed silently for three weeks in a space the console reported as fine.
Detection latency is still yours. 39 of my seconds-to-page were CloudWatch alarm evaluation, and the alarm I most needed didn't exist.
Garbage in, garbage out, and you pay per second either way. Structured logs that include changed config values are worth more than any feature on the pricing page.
One-way by default. Without a ticketing integration, findings live in a web app nobody has open.
Preview means preview. Release management is us-east-1 only.

Would I run it? For a single small serverless app with two alarms, no — a CloudWatch dashboard and a coding agent cover it. For a team on-call across a dozen services and multiple accounts, where the expensive part of every incident is the 30 minutes spent working out which service is broken: yes, and Support-plan credits probably make it free.

The honest summary: this is a very fast, very well-instrumented first responder that knows things about your account that aren't in your repository, and that occasionally gets a detail confidently wrong in the middle of a correct answer. Used as a starting point with an audit trail, it's genuinely good. Used as an oracle, it will eventually cost you an hour chasing a setting that doesn't exist. The work you put into your logs, your alarm descriptions and your webhook payload determines which one you get — and that part is entirely within your control.

19. Appendix: copy-paste checklist

Before you start

[ ] Upgrade AWS CLI v2 and boto3/SDK. Verify with aws devops-agent help.
[ ] Check your Support plan tier — you may already have credits covering all of this.
[ ] Pick an Agent Space region for data residency, not to match your workloads.

Onboarding

[ ] Create DevOpsAgentRole-AgentSpace with AIDevOpsAgentAccessPolicy.
[ ] Add the iam:CreateServiceLinkedRole inline policy for Resource Explorer.
[ ] Create DevOpsAgentRole-WebappAdmin with AIDevOpsOperatorAppAccessPolicy (trust policy needs sts:TagSession).
[ ] Create the space, associate the account as monitor, enable the operator app.
[ ] Do it all in CloudFormation, CDK or Terraform — not by hand.
[ ] Wire up IAM Identity Center or an OIDC IdP before handing it to a team. The IAM link expires in 10 minutes.

Make it triggerable — pick a path first (§7)

[ ] Read the two AWS sample posts before writing anything; don't reinvent the bridge.
[ ] Path A (webhook): generate a generic webhook in the console, choose HMAC, store the secret in Secrets Manager, build SNS → Lambda, sign timestamp:payload.
[ ] Path B (API): EventBridge → Lambda → create-backlog-task --task-type INVESTIGATION. No secret, no console step, fully IaC-able. Grant the Lambda role aidevops:CreateBacklogTask and use --client-token for idempotency.
[ ] If you choose Path B, verify whether triage correlation (LINKED/SKIPPED) applies to API-created tasks.
[ ] Map alarm names to CRITICAL/HIGH/MEDIUM deliberately — CloudWatch has no severity field.
[ ] Make the dedupe key stable per alarm transition, not per delivery.
[ ] Put account, region, metric, dimensions and the application's service chain in the description.
[ ] Write real runbook text into every AlarmDescription and forward it.
[ ] Send alarms through unbuffered first and watch for Investigation Linked before building your own dedupe table.

Make it observable

[ ] EventBridge rule on source: aws.aidevops → CloudWatch Logs, from day one.
[ ] Schedule list-backlog-tasks and alarm on FAILED.
[ ] Check get-account-usage monthly — including learning hours.
[ ] Know how to read list-journal-records before you need it.

Make it trustworthy

[ ] Treat every mechanism detail in an RCA as a hypothesis until you've checked it. The verdict is usually right; a detail in the middle may not be.
[ ] For any concurrency finding, confirm which ceiling: get-function-concurrency (reserved) vs get-account-settings (account quota). Different fixes.
[ ] For DynamoDB throttling, read WriteThrottleEvents for blast radius, not just ThrottledRequests.
[ ] Submit investigation feedback (correct/incorrect root cause) every time. It feeds accuracy metrics and future investigations.
[ ] Verify at the agent-to-agent handoff. A wrong mechanism passed to a coding agent becomes a wrong code change.

Make it good

[ ] Log changed config and feature-flag values in your error paths.
[ ] Activate and adapt the sample triage skip skill.
[ ] Write one skill per recurring incident class, with a description written from the agent's perspective — and encode the corrections you've already had to make.
[ ] Add a ticketing or chat integration so findings reach where your team looks.

Kiro Powers aren’t just about adding tools — they solidify developer workflows and remove the chaos of context overload. What makes them powerful is how they naturally align with the AI-Driven Development Lifecycle (AI-DLC)

Ajaykumar k v — Tue, 28 Apr 2026 13:12:49 +0000

Ajaykumar k v for AWS Community Builders

Apr 28

Kiro Powers: Give Your AI Agent Superpowers — Not Context Overload

#ai #kiro #agents #mcp

21 min read

Kiro Powers: Give Your AI Agent Superpowers — Not Context Overload

Ajaykumar k v — Tue, 28 Apr 2026 08:14:45 +0000

How Kiro Powers bring on-demand expertise to the AI-Driven Development Lifecycle — demonstrated through four independent real-world use cases.

Introduction: The Context Problem in AI-Assisted Development
What Is the AI-Driven Development Lifecycle (AI-DLC)?
Enter Kiro Powers: On-Demand Expertise for AI Agents
- 3.1 The Problem Powers Solve
- 3.2 How Powers Work Under the Hood
- 3.3 Anatomy of a Power
- 3.4 What Makes Powers Different
Kiro Powers Across the AI-DLC Phases
Four Powers, Four Real-World Use Cases
- 5.1 Use Case 1 — AWS Draw.io: Designing a Multi-Region Disaster Recovery Architecture
- 5.2 Use Case 2 — Stripe Payments: Building a SaaS Subscription Platform with Usage-Based Billing
- 5.3 Use Case 3 — Postman: Contract-First API Development for a Microservices Migration
- 5.4 Use Case 4 — Amazon Bedrock AgentCore: Building an Internal Knowledge Assistant for Enterprise
How Powers Fit Into Your Developer Workflow
Building and Sharing Your Own Powers
Conclusion: The Future of Agent Capabilities

1. Introduction: The Context Problem in AI-Assisted Development

You're building a checkout flow. You've used Stripe before, but you're still hunting through docs for the right pattern. Should you use idempotent keys here? What's the best way to handle webhooks? Your AI coding assistant should give you instant access to that framework expertise so you can ship faster. But here's the reality: without built-in knowledge, today's AI agents guess and iterate — just like you do.

This is the context problem in AI-assisted development, and it manifests in two ways:

Without framework context, agents guess. Your agent can call APIs, but does it know the right patterns and best practices? Does it understand connection pooling for serverless? Without built-in expertise, both you and your agent are manually reading documentation and refining approaches until the output is right. This trial-and-error repeats for every tool, every framework, every domain outside your core expertise.

With too much context, agents slow down. MCP (Model Context Protocol) servers were meant to solve this. But connect five MCP servers and your agent loads 100+ tool definitions before writing a single line of code. Five servers might consume 50,000+ tokens — 40% of your context window — before your first prompt. More tools should mean better results, but unstructured context overwhelms the agent, leading to slower responses and lower quality output. This is what the community calls context rot.

What if there was a way to give your AI agent exactly the expertise it needs, exactly when it needs it — and nothing more?

2. What Is the AI-Driven Development Lifecycle (AI-DLC)?

Before we dive into the solution, let's set the stage. AWS has introduced the AI-Driven Development Lifecycle (AI-DLC), a methodology that positions AI as a central collaborator — not just an assistant — throughout the entire software development process.

AI-DLC operates on two dimensions:

AI-Powered Execution with Human Oversight: AI creates detailed work plans, seeks clarification, and defers critical decisions to humans. Only humans possess the contextual understanding and knowledge of business requirements needed to make informed choices.
Dynamic Team Collaboration: As AI handles routine tasks, teams unite in collaborative spaces for real-time problem solving, creative thinking, and rapid decision-making.

The lifecycle flows through three phases:

Phase	What Happens	AI's Role
Inception	Business intent → detailed requirements, stories, and units	AI transforms intent into specs; team validates through "Mob Elaboration"
Construction	Validated context → architecture, code, and tests	AI proposes solutions; team clarifies technical decisions through "Mob Construction"
Operations	Accumulated context → infrastructure and deployments	AI manages IaC and deployments with team oversight

Each phase provides richer context for the next, enabling AI to deliver increasingly informed suggestions. Traditional sprints are replaced by "bolts" — shorter, more intense work cycles measured in hours or days rather than weeks.

The key insight: AI-DLC requires AI agents that can dynamically access specialized knowledge across design, development, deployment, and observability. That's exactly what Kiro Powers delivers.

3. Enter Kiro Powers: On-Demand Expertise for AI Agents

Kiro Powers provide a unified approach for a broad range of development and deployment use cases: MCP tools and framework expertise — packaged together and loaded dynamically.

Think of it like Neo downloading martial arts in The Matrix. Powers give the Kiro agent instant access to specialized knowledge for any technology. The key difference from traditional MCP? Dynamic context loading.

3.1 The Problem Powers Solve

Here's a visual comparison of the traditional approach vs. Powers:

Traditional MCP (Everything Loaded at Once):

User starts task: "Add a database on Supabase"

Agent Context:
  ├── Figma MCP ........... 10+ tools loaded
  ├── Supabase MCP ........ 50+ tools loaded
  ├── Netlify MCP ......... 10+ tools loaded
  ├── Postman MCP ......... 80+ tools loaded
  └── Datadog MCP ......... 20+ tools loaded

  ⚠️ Context Overload: 180+ tools total
  → Slow responses, lower quality, irrelevant suggestions

With Kiro Powers (Dynamic Loading):

User starts task: "Add a database on Supabase"

Kiro analyzes task → Which powers are relevant?

  ✅ Supabase power → ACTIVATED (tools + best practices loaded)
  ⬜ Figma power → not loaded
  ⬜ Netlify power → not loaded
  ⬜ Postman power → not loaded
  ⬜ Datadog power → not loaded

  Agent Context: Only relevant tools
  → Fast responses, high quality, focused suggestions

Install five powers and your baseline context usage is near zero. Mention "design" and the Figma power activates. Switch to database work and Supabase activates while Figma deactivates. Your agent only loads tools relevant to the current task.

3.2 How Powers Work Under the Hood

When you start a task, Kiro:

Reads the task description from your prompt or conversation
Evaluates installed powers against the task using keyword matching from each power's frontmatter
Loads only relevant powers into context — their MCP tools, steering files, and best practices
Deactivates irrelevant powers as you switch contexts

This means you can have dozens of powers installed without any performance penalty. They activate only when the conversation touches their domain.

3.3 Anatomy of a Power

A power is a unified bundle that includes three components:

my-power/
├── POWER.md              # Entry point — onboarding manual for the agent
├── mcp.json              # MCP server configuration (tools + connection details)
└── steering/             # Workflow-specific guides (optional)
    ├── getting-started.md
    ├── best-practices.md
    └── advanced-patterns.md

Component	Purpose
POWER.md	The steering file that tells the agent what MCP tools it has, when to use them, best practices, common workflows, and troubleshooting guidance
mcp.json	Connection details for the MCP server — can be local (STDIO) or remote (HTTP/SSE)
Steering files	Workflow-specific guides that load on-demand. Working on RLS policies? The agent loads `rls-policies.md`. Writing Edge Functions? It loads `edge-functions.md`.

The POWER.md frontmatter defines activation keywords. For example, the Stripe power activates when you mention "payment," "checkout," "subscription," or "billing."

3.4 What Makes Powers Different

Feature	Traditional MCP	Kiro Powers
Tool Loading	All tools loaded upfront	On-demand, keyword-activated
Context Usage	50,000+ tokens for 5 servers	Near-zero baseline
Best Practices	Not included	Packaged in POWER.md and steering files
Installation	Manual JSON configuration	One-click from IDE or kiro.dev
Ecosystem	Find and configure individually	Curated partners + community + build your own
Cross-tool	Per-client configuration	Building toward cross-compatibility (Cursor, Claude Code, Kiro CLI)

Launch partners include Datadog, Dynatrace, Figma, Neon, Netlify, Postman, Supabase, Stripe, and Strands Agents — with more coming from both software vendors and the open-source community.

4. Kiro Powers Across the AI-DLC Phases

Powers aren't just a developer convenience — they map directly to the AI-DLC methodology. Here's how powers serve each phase:

AI-DLC Phase	Activity	Relevant Powers
Inception	Architecture diagrams, system design	AWS Draw.io, Figma
Inception	Requirements validation, API contracts	Postman (spec generation)
Construction	Payment integration	Stripe
Construction	Database setup	Supabase, Neon, Aurora
Construction	AI agent development	Amazon Bedrock AgentCore, Strands
Construction	API testing	Postman
Operations	Deployment	Netlify
Operations	Observability	Datadog, Dynatrace

Each power brings domain-specific expertise that would otherwise require hours of documentation reading. The agent doesn't just have tools — it has the knowledge of how to use them correctly.

5. Four Powers, Four Real-World Use Cases

Each power below is demonstrated through an independent, real-world scenario — the kind of task you'd actually face on a production team. For each, we walk through installation, activation, the step-by-step workflow, the best practices the power enforces, and what would go wrong without it.

5.1 Use Case 1 — AWS Draw.io: Designing a Multi-Region Disaster Recovery Architecture

AI-DLC Phase: Inception | Real-world scenario: Your team has been asked to design a multi-region active-passive disaster recovery (DR) strategy for a healthcare platform running on AWS. The CTO needs a professional architecture diagram for the board presentation by end of day. Normally this takes a solutions architect half a day with Lucidchart or draw.io — hunting for the right AWS icons, aligning subnets, color-coding regions.

What the power provides:

Draw.io native XML format generation (.drawio files)
Complete AWS, Azure, and GCP cloud icon libraries with correct mxgraph shape names
Architecture pattern templates: three-zone DR layouts, VPC/subnet nesting, hub-and-spoke topologies
Four steering files: architecture-patterns.md, cloud-icons.md, style-guide.md, branding.md

Step-by-step walkthrough:

Step 1 — Install (one-click):
Open the Kiro Powers panel → search "AWS Draw.io" → click Install. No API keys, no JSON config. The power is purely documentation-driven — it teaches the agent how to produce valid draw.io XML.

Step 2 — Describe your architecture in natural language:

"Design a multi-region active-passive DR architecture diagram. Primary region is us-east-1 with an ALB, ECS Fargate cluster, Aurora PostgreSQL, and S3. DR region is eu-west-1 with Aurora read replica, S3 cross-region replication, and a standby ECS cluster. Show Route 53 health-check failover at the top, a replication arrow between Aurora instances, and a failover section at the bottom."

The power activates on keywords like "architecture," "diagram," "flowchart," and "topology."

Step 3 — The agent generates a production-quality .drawio file:

The agent leverages the power's architecture-patterns.md steering to use the Three-Zone DR Layout pattern:

Every component uses the correct AWS icon from the cloud-icons.md reference:

<!-- Aurora Primary — uses the official AWS database icon -->
<mxCell id="aurora-primary" value="Aurora PostgreSQL"
  style="sketch=0;outlineConnect=0;fontColor=#232F3E;fillColor=#C925D1;
  strokeColor=#ffffff;verticalLabelPosition=bottom;verticalAlign=top;
  align=center;html=1;fontSize=12;aspect=fixed;
  shape=mxgraph.aws4.resourceIcon;resIcon=mxgraph.aws4.aurora;"
  vertex="1" parent="1">
  <mxGeometry x="250" y="300" width="78" height="78" as="geometry" />
</mxCell>

<!-- VPC container with proper subnet nesting -->
<mxCell id="vpc-primary" value="VPC 10.0.0.0/16"
  style="sketch=0;outlineConnect=0;gradientColor=none;html=1;whiteSpace=wrap;
  fontSize=12;fontStyle=0;shape=mxgraph.aws4.group;
  grIcon=mxgraph.aws4.group_vpc;strokeColor=#8C4FFF;fillColor=none;
  verticalAlign=top;align=left;spacingLeft=30;dashed=0;"
  vertex="1" parent="1">
  <mxGeometry x="40" y="100" width="450" height="350" as="geometry" />
</mxCell>

The diagram follows AWS's official color conventions: Compute in #ED7100, Database in #C925D1, Networking in #8C4FFF, Storage in #7AA116, Security in #DD344C.

Step 4 — Open, edit, and present:
Open the .drawio file in VS Code (Draw.io extension) or at app.diagrams.net. Drag components to fine-tune layout, export to PNG/SVG/PDF for the board deck.

Best practices the power enforces:

Unique IDs on every mxCell (prevents rendering bugs)
Consistent 10-20px grid alignment for professional appearance
Parent hierarchy for nested elements (subnets inside VPCs)
Color-coded legend explaining service categories
Dashed arrows for failover paths, solid flex arrows for replication
Status indicators (green circle = active, grey = standby)

What goes wrong without the power: The agent produces generic rectangles with text labels. No AWS icons, no VPC grouping, no color conventions, no DR-specific layout patterns. You'd spend more time fixing the diagram than it would take to draw it manually.

Customization tip: Edit steering/branding.md to set your company's brand colors. Every diagram the agent generates will use your palette instead of the defaults.

5.2 Use Case 2 — Stripe Payments: Building a SaaS Subscription Platform with Usage-Based Billing

AI-DLC Phase: Construction | Real-world scenario: You're building a developer tools platform — think a hosted CI/CD service like a smaller-scale Vercel or Railway. You need tiered subscription plans (Free, Pro, Enterprise) plus usage-based billing for compute minutes that exceed the plan's included quota. This is one of the most complex Stripe integration patterns, combining Subscriptions, metered billing, Checkout, and webhooks.

What the power provides:

Stripe MCP server connection (https://mcp.stripe.com) for live API operations
stripe-best-practices.md steering file with Stripe's official integration guidance
Knowledge of Checkout Sessions, Payment Intents, Billing APIs, Connect, and deprecated API warnings
Workflow templates for one-time payments, subscriptions, refunds, and saved payment methods

Step-by-step walkthrough:

Step 1 — Install and authenticate:
Powers panel → search "Stripe" → Install. Enter your Stripe secret key (sk_test_...) when prompted. The power configures the MCP connection automatically:

{
  "mcpServers": {
    "stripe": {
      "url": "https://mcp.stripe.com"
    }
  }
}

Step 2 — Describe the billing model:

"Build a subscription billing system with three tiers: Free (0/mo, 100 compute minutes), Pro ($49/mo, 2,000 compute minutes), and Enterprise ($199/mo, 10,000 compute minutes). Any usage beyond the included minutes should be billed at $0.02 per minute using metered billing. Use Stripe Checkout for the signup flow."

The power activates on "subscription," "billing," "payment," or "checkout."

Step 3 — The agent builds the product catalog:

The agent creates Products and Prices in Stripe following the power's guidance to use the Billing APIs for recurring revenue:

// Create the Pro plan with a base subscription price
const proProduct = await stripe.products.create({
  name: 'Pro Plan',
  description: '2,000 compute minutes included',
});

// Fixed monthly price
const proBasePrice = await stripe.prices.create({
  product: proProduct.id,
  unit_amount: 4900, // $49.00
  currency: 'usd',
  recurring: { interval: 'month' },
});

// Metered overage price — usage-based billing
const proOveragePrice = await stripe.prices.create({
  product: proProduct.id,
  currency: 'usd',
  recurring: {
    interval: 'month',
    usage_type: 'metered', // Key: enables usage-based billing
  },
  unit_amount: 2, // $0.02 per minute
  billing_scheme: 'per_unit',
});

Step 4 — Checkout Session with multiple line items:

const session = await stripe.checkout.sessions.create({
  mode: 'subscription',
  customer: customerId,
  line_items: [
    { price: proBasePrice.id, quantity: 1 },
    { price: proOveragePrice.id }, // No quantity — metered usage reported later
  ],
  success_url: 'https://app.example.com/welcome?session_id={CHECKOUT_SESSION_ID}',
  cancel_url: 'https://app.example.com/pricing',
});

Step 5 — Report usage for metered billing:

// At the end of each billing period (or in real-time), report compute usage
const usageRecord = await stripe.subscriptionItems.createUsageRecord(
  subscriptionItemId, // The metered line item's subscription item ID
  {
    quantity: 347, // 347 overage minutes this period
    timestamp: Math.floor(Date.now() / 1000),
    action: 'increment',
  }
);

Step 6 — Comprehensive webhook handler:

app.post('/webhook', express.raw({ type: 'application/json' }), (req, res) => {
  const sig = req.headers['stripe-signature'];
  let event;

  try {
    event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);
  } catch (err) {
    return res.status(400).send(`Webhook Error: ${err.message}`);
  }

  switch (event.type) {
    case 'customer.subscription.created':
      // Provision the customer's plan tier and compute quota
      break;
    case 'customer.subscription.updated':
      // Handle plan upgrades/downgrades — adjust quotas
      break;
    case 'customer.subscription.deleted':
      // Revoke access, downgrade to Free tier
      break;
    case 'invoice.payment_failed':
      // Notify customer, implement grace period logic
      break;
    case 'invoice.finalized':
      // Usage-based invoice ready — log for internal billing dashboard
      break;
  }

  res.json({ received: true });
});

Best practices the power enforces (from stripe-best-practices.md):

Practice	What the power does	What agents do without it
Use Checkout Sessions	Always generates Checkout-based flows	May use deprecated Charges API
Dynamic payment methods	Omits `payment_method_types`, lets Stripe optimize	Hardcodes `['card']`
Idempotency keys	Adds idempotency keys on create operations	Skips them, risking duplicate charges
Webhook signature verification	Always includes `constructEvent` with secret	Parses raw JSON without verification
No API version in code	Follows Stripe's versioning guidance	Pins to an old API version
Sandbox-first development	Uses `sk_test_` keys	May accidentally use live keys
Never expose secret keys	Server-side only, environment variables	May leak keys in client-side code

What the power prevents: The steering file explicitly blocks the agent from recommending the deprecated Charges API, the legacy Card Element, the Sources API for saving cards, or mixing Connect charge types. These are real-world mistakes that cost teams weeks of refactoring.

5.3 Use Case 3 — Postman: Contract-First API Development for a Microservices Migration

AI-DLC Phase: Construction + Operations | Real-world scenario: Your team is migrating a monolithic e-commerce backend into microservices. You have an existing OpenAPI 3.0 spec for the monolith, and you need to: (1) generate Postman collections from the spec, (2) create environment configurations for local, staging, and production, (3) add automated tests to every endpoint, and (4) set up continuous testing that runs whenever API code changes. This is a contract-first approach — the API spec is the source of truth.

What the power provides:

Postman MCP server (https://mcp.postman.com/minimal) with 40 tools in minimal mode (112 in full mode)
Tools spanning workspace management, collection CRUD, environment management, mock servers, API spec management, code generation, and test execution
steering.md with workflow patterns for collection generation, workspace creation, and test execution
Automatic hook setup for continuous testing on file changes

Step-by-step walkthrough:

Step 1 — Install and authenticate:
Powers panel → search "Postman" → Install. Set your Postman API key (generate at postman.com → Settings → API Keys). The power connects via SSE to Postman's hosted MCP server:

{
  "mcpServers": {
    "postman": {
      "url": "https://mcp.postman.com/minimal",
      "headers": {
        "Authorization": "Bearer ${POSTMAN_API_KEY}"
      }
    }
  }
}

Step 2 — Import the OpenAPI spec and generate collections:

"I have an OpenAPI spec at openapi.yaml for our e-commerce API. Create a Postman workspace called 'E-Commerce Microservices', import the spec, generate a collection from it, and set up local, staging, and production environments."

The power activates on "postman," "api," "testing," "collections," or "http."

Step 3 — The agent orchestrates the full setup:

// 1. Create a dedicated workspace
const { workspace } = await createWorkspace({
  workspace: { name: "E-Commerce Microservices", type: "team" }
});

// 2. Import the OpenAPI spec
const { spec } = await createSpec({
  workspaceId: workspace.id,
  name: "E-Commerce API v2",
  type: "OPENAPI:3.0",
  files: [{ path: "openapi.yaml", content: openApiContent }]
});

// 3. Generate a collection from the spec — contract-first!
const { collection } = await generateCollection({
  specId: spec.id,
  elementType: "collection",
  name: "E-Commerce API Tests"
});

// 4. Create environment configurations
const environments = {};
for (const [name, baseUrl] of [
  ["Local", "http://localhost:3000"],
  ["Staging", "https://staging-api.example.com"],
  ["Production", "https://api.example.com"]
]) {
  const { environment } = await createEnvironment({
    workspace: workspace.id,
    environment: {
      name,
      values: [
        { key: "base_url", value: baseUrl, enabled: true },
        { key: "api_key", value: `{{${name.toLowerCase()}_api_key}}`, enabled: true },
        { key: "auth_token", value: "", enabled: true }
      ]
    }
  });
  environments[name] = environment;
}

// 5. Save all IDs for future reference
// The power's steering mandates saving to .postman.json

Step 4 — Add test scripts to every request:

The agent adds post-request test scripts that validate:

HTTP status codes (200, 201, 400, 404, etc.)
Response schema matches the OpenAPI contract
Response time is under acceptable thresholds
Required headers are present (Content-Type, correlation IDs)
Business logic assertions (e.g., created resource has an ID)

Step 5 — Run the collection and get a detailed report:

const results = await runCollection({
  collectionId: collection.uid,
  environmentId: environments["Local"].id
});

// The agent displays:
// ✅ GET /products — 200 OK (45ms)
// ✅ POST /products — 201 Created (120ms)
// ❌ GET /products/{id} — 404 Not Found (32ms) — Product ID not seeded
// ✅ POST /orders — 201 Created (89ms)
// ❌ PUT /orders/{id}/status — 500 Internal Server Error (210ms)
//
// 3/5 passed | 2 failures detected
// → Agent offers to investigate and fix the failing endpoints

Step 6 — Set up continuous testing with a Kiro hook:

The power's onboarding creates a hook that triggers Postman test runs whenever API source code changes:

{
  "name": "API Postman Testing",
  "version": "1",
  "when": {
    "type": "fileEdited",
    "patterns": [
      "*.ts", "*.js", "*.py", "*.go",
      "openapi.yaml", "openapi.yml", "swagger.yaml"
    ]
  },
  "then": {
    "type": "askAgent",
    "prompt": "API source code or configuration has been modified. Retrieve the .postman.json file. If it exists, get the collection ID and run the collection, showing results and proposing fixes for any errors found."
  }
}

Now every time you save a file, Postman tests run automatically — a continuous contract validation loop.

Step 7 — Keep spec and collection in sync:

As the API evolves, use the sync tools to maintain the contract:

// Spec changed? Sync the collection to match
await syncCollectionWithSpec({
  collectionId: collection.uid,
  specId: spec.id
});

// Collection changed (new tests added)? Sync back to spec
await syncSpecWithCollection({
  specId: spec.id,
  collectionId: collection.uid
});

Best practices the power enforces:

Practice	How the power enforces it
Store IDs in `.postman.json`	Steering mandates saving workspace, collection, and environment IDs to a local file for reproducibility
Use environments, not hardcoded URLs	Agent always creates environment variables for `base_url`, `api_key`, etc.
No curl or external clients	Steering explicitly states: "You are not allowed to use curl or any other API clients except Postman"
Server must be running before tests	Agent verifies the API server is up before executing collection runs
Organized folder structure	Requests are grouped by resource (Products, Orders, Users) inside the collection
Post-request test scripts on every request	Agent adds validation scripts, not just request definitions

What goes wrong without the power: The agent might use curl for testing (no persistence, no environments), skip test scripts, forget to save IDs, or create a flat collection without folder organization. The power brings a complete, repeatable testing workflow that survives across sessions.

5.4 Use Case 4 — Amazon Bedrock AgentCore: Building an Internal Knowledge Assistant for Enterprise

AI-DLC Phase: Construction + Operations | Real-world scenario: Your enterprise wants to build an internal knowledge assistant — an AI agent that employees can ask about company policies, HR procedures, technical documentation, and onboarding guides. The agent needs to: (1) use a foundation model via Amazon Bedrock, (2) maintain conversation memory so follow-up questions work naturally, (3) expose the agent through a managed gateway with authentication, and (4) deploy to production with proper infrastructure. This is a common enterprise pattern that AgentCore was built for.

What the power provides:

MCP tools: search_agentcore_docs, fetch_agentcore_doc, manage_agentcore_runtime, manage_agentcore_memory, manage_agentcore_gateway
Three steering files: getting-started.md (full create→dev→test→deploy workflow), agentcore-memory-integration.md, agentcore-gateway-integration.md
Support for multiple agent SDKs (Strands, Claude, OpenAI) and model providers (Bedrock, OpenAI)
Infrastructure deployment guidance via CDK or Terraform

Step-by-step walkthrough:

Step 1 — Install the power:
Powers panel → search "Bedrock AgentCore" → Install. No API keys needed at install time — the power uses your existing AWS credentials.

Step 2 — Describe the agent:

"Create a new AI agent using Bedrock AgentCore with the Strands framework. It should be an internal knowledge assistant that can answer questions about company documentation. Use Bedrock as the model provider and include conversation memory."

The power activates on keywords like "agent," "bedrock," "agentcore," or "strands."

Step 3 — Scaffold the project:

The agent follows the getting-started.md steering file, which specifies using --non-interactive mode for AI-driven workflows:

# Install the AgentCore toolkit
pip install bedrock-agentcore-starter-toolkit

# Create the agent project with defaults (Strands + Bedrock)
agentcore create --non-interactive \
  --project-name KnowledgeAssistant \
  --template basic \
  --agent-framework Strands \
  --model-provider Bedrock

This generates:

KnowledgeAssistant/
├── src/
│   └── main.py              # Agent entrypoint with @app.entrypoint decorator
├── .bedrock_agentcore.yaml   # Runtime configuration
├── pyproject.toml            # Dependencies
└── .venv/                    # Virtual environment (auto-created)

Step 4 — Customize the agent logic:

The agent modifies src/main.py to add knowledge retrieval capabilities:

from bedrock_agentcore import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

@app.entrypoint
async def handle_request(prompt: str, session_id: str = None):
    """
    Internal knowledge assistant — answers questions about
    company policies, HR procedures, and technical documentation.
    """
    # The Strands framework handles model invocation,
    # tool orchestration, and response generation
    response = await agent.invoke(
        prompt=prompt,
        session_id=session_id,
        system_prompt="""You are an internal knowledge assistant for Acme Corp.
        Answer questions about company policies, HR procedures, benefits,
        technical documentation, and onboarding guides.
        Always cite the source document when answering.
        If you don't know the answer, say so clearly."""
    )
    return {"response": response}

Step 5 — Start the dev server and test locally:

# Terminal 1: Start dev server with hot reloading
agentcore dev

# Terminal 2: Test the agent
agentcore invoke --dev '{"prompt": "What is our PTO policy for new employees?"}'

# Expected response:
# ✓ Response from dev server:
# {
#   "response": "According to the Employee Handbook (Section 4.2),
#    new employees receive 15 days of PTO in their first year..."
# }

The power's steering emphasizes a critical development loop: make a change → save → dev server auto-reloads → test with agentcore invoke --dev → verify → repeat.

Step 6 — Add conversation memory:

The agent uses the manage_agentcore_memory MCP tool to understand memory configuration:

# .bedrock_agentcore.yaml — updated configuration
memory:
  mode: STM_ONLY  # Short-term memory for conversation continuity

The power's steering includes a critical deployment ordering rule:

Deploy with NO_MEMORY first. Memory integration should be added after the initial successful deployment. The agent code can include memory session manager logic — it simply won't persist when NO_MEMORY is configured. Once the agent is running, update to STM_ONLY or STM_AND_LTM and redeploy.

This prevents a common failure mode where developers try to deploy with memory enabled before the memory resources exist.

Step 7 — Configure the gateway for authenticated access:

The agent uses the manage_agentcore_gateway MCP tool to set up a managed API endpoint:

# The MCP tool provides the exact CLI commands needed
agentcore gateway create \
  --name knowledge-assistant-gateway \
  --auth-type IAM

# Add the agent as a target
agentcore gateway add-target \
  --gateway-name knowledge-assistant-gateway \
  --agent-name KnowledgeAssistant

This creates a managed HTTPS endpoint with IAM authentication — employees access the agent through your company's SSO.

Step 8 — Deploy to production:

# Configure the deployment entrypoint
agentcore configure --entrypoint src/main.py --non-interactive

# Deploy to AgentCore runtime (initially without memory)
agentcore launch

# Verify deployment
agentcore status

# Test the deployed agent
agentcore invoke '{"prompt": "How do I request a hardware upgrade?"}'

# Once confirmed working, enable memory and redeploy
# Update .bedrock_agentcore.yaml: memory.mode → STM_ONLY
agentcore launch

# When done testing, clean up
agentcore stop-session    # Free active session resources
agentcore destroy --dry-run  # Preview what will be deleted
agentcore destroy            # Remove all resources

Best practices the power enforces:

Practice	How the power enforces it
Non-interactive mode for AI workflows	Steering specifies `--non-interactive` flag — prevents the agent from hanging on interactive prompts
Memory deployment ordering	Steering mandates `NO_MEMORY` first, then upgrade after successful deployment
Test after every change	Steering marks this as "CRITICAL" — always run `agentcore invoke --dev` after code changes
*Use `manage_agentcore_` MCP tools first**	Steering says "DO NOT attempt to manually configure memory/gateway without first consulting this tool"
Existing agent protection	Steering warns: "`agentcore create` is ONLY for new projects — using it on an existing agent will overwrite your code"
Entrypoint auto-detection	Dev server reads `.bedrock_agentcore.yaml` for the entrypoint, falls back to `src.main:app`

What goes wrong without the power: Developers commonly try to deploy with memory enabled before resources exist (deployment fails), use agentcore create on an existing project (code overwritten), skip local testing (bugs discovered only in production), or manually configure gateways without understanding the required CLI sequence. The power's three steering files (getting-started.md, agentcore-memory-integration.md, agentcore-gateway-integration.md) prevent all of these pitfalls.

6. How Powers Fit Into Your Developer Workflow

Here's how to think about powers in your daily workflow — each power slots into the moment you need it, regardless of the project:

Architecture review → Inception phase:

"Design a multi-region DR architecture for our healthcare platform"
→ Draw.io power activates, produces a .drawio file with proper AWS icons and DR patterns

Feature development → Construction phase:

"Add usage-based subscription billing with Stripe"
→ Stripe power activates with best practices — Checkout Sessions, metered billing, webhook verification

"Build an internal knowledge assistant with Bedrock AgentCore"
→ AgentCore power activates with the full create→dev→test→deploy workflow

Quality assurance → Construction + Operations phase:

"Import our OpenAPI spec into Postman and generate test collections"
→ Postman power activates, creates workspace, generates collections, sets up environments

"Run all API tests before we merge"
→ Postman power runs collections, reports pass/fail by endpoint, offers to fix failures

Deployment → Operations phase:

"Deploy the knowledge assistant to AWS"
→ AgentCore power guides through agentcore launch with memory ordering best practices

The beauty is that you never manage context manually. You just describe what you need, and the right power activates with the right tools and the right knowledge. When you switch from payments to testing, Stripe deactivates and Postman activates. Your context window stays clean and focused.

Pro tips for power users:

Install powers proactively — even if you don't need them today. They cost zero context until activated.
Let keywords do the work — you don't need to explicitly say "use the Stripe power." Just mention "payment" or "checkout" and it activates.
Leverage steering files — powers often include multiple steering files for different workflows. The agent loads the right one based on your current task.
Use hooks — powers like Postman can set up hooks that automatically run tests when you edit code, creating a continuous testing loop.

7. Building and Sharing Your Own Powers

Powers aren't just for consuming — you can build your own. This is especially powerful for teams with internal tools, custom frameworks, or domain-specific knowledge.

A power is structured as:

my-custom-power/
├── POWER.md              # Agent instructions, workflows, best practices
├── mcp.json              # MCP server config (optional)
└── steering/             # Additional workflow guides (optional)
    └── my-workflow.md

The POWER.md is the heart of the power. It tells the agent:

What tools are available and when to use them
Best practices and anti-patterns to avoid
Common workflows with step-by-step instructions
Troubleshooting guidance for common errors

Sharing options:

GitHub — Import powers from any GitHub URL
Local directories — Point to a local folder for private team powers
Kiro marketplace — Publish for the community

Example use cases for custom powers:

Your company's design system and component library
Internal API standards and code review guidelines
Infrastructure-as-code patterns specific to your organization
Domain-specific knowledge (healthcare compliance, financial regulations, etc.)

8. Conclusion: The Future of Agent Capabilities

Kiro Powers represent a fundamental shift in how AI agents acquire and use knowledge. Instead of loading everything upfront and hoping for the best, powers enable continual, on-demand learning — the agent downloads exactly the expertise it needs, when it needs it.

This matters for three reasons:

For developers: You work faster in unfamiliar domains. Need to integrate Stripe? The agent already knows the best practices. Need to build an AI agent? The agent already knows the deployment workflow. You focus on business logic; the power handles the framework expertise.
For tool providers: You package your expertise once and it works everywhere. No more maintaining separate documentation for every AI tool. One POWER.md, one set of steering files, and your users get guided experiences across any compatible IDE.
For the AI-DLC methodology: Powers are the mechanism that makes AI a true collaborator across all phases — from inception (DR architecture diagrams with Draw.io) through construction (SaaS billing with Stripe, contract-first testing with Postman, enterprise agents with AgentCore) to operations (deployment, observability). Each power brings domain expertise that would otherwise require hours of documentation reading.

The vision is clear: AI agents that don't just have tools, but have the wisdom to use them correctly. Not by knowing everything upfront, but by learning what they need, when they need it, and continuously expanding their expertise as the tools around them evolve.

Get started today:

Browse and install powers at kiro.dev/powers
Read the official documentation at kiro.dev/docs/powers
Build your own power with the creation guide
Join the community on Discord

Kiro Powers are available today in Kiro IDE, with cross-compatibility for other AI development tools coming soon. Launch partners include Datadog, Dynatrace, Figma, Neon, Netlify, Postman, Supabase, Stripe, and Strands Agents.

References:

The AWS AI/ML Landscape in 2026 — Simplified

Ajaykumar k v — Thu, 01 Jan 2026 18:36:55 +0000

A practical deep-dive into Amazon's AI/ML ecosystem and how to leverage it for real-world problems

Remember when implementing machine learning meant assembling a team of PhDs, buying expensive GPU clusters, and spending months just to get a proof of concept running? Yeah, those days are gone. In 2025, AWS has transformed the AI/ML landscape into something that's actually accessible—whether you're a startup founder with a brilliant idea or an enterprise architect modernizing legacy systems.

But here's the thing: AWS now offers over 30 AI/ML services. That's not a typo. Thirty. And if you're feeling overwhelmed just reading that number, you're not alone. The good news? They're not randomly thrown together. There's a method to this madness, and once you understand the architecture, everything clicks into place.

The Three-Tier Architecture: How AWS Actually Thinks About AI/ML

AWS structures its AI/ML services like a pyramid, and understanding this structure is your secret weapon to picking the right tool for the job.

TIER 1: The Foundation Layer - Build Your Own ML Models

Amazon SageMaker AI: The Complete ML Platform

Amazon SageMaker AI is the heavyweight champion of custom machine learning. This isn't just a service—it's an entire ecosystem for building, training, and deploying machine learning models at scale.

Core Components & Features:

1. SageMaker Studio

Fully integrated development environment (IDE) for ML
Web-based interface with JupyterLab notebooks
Visual workflow builder for ML pipelines
Real-time collaboration with shared spaces across teams
Git integration for version control
One-click access to compute resources

2. SageMaker Autopilot (AutoML)

Automatically builds, trains, and tunes ML models
Supports classification and regression problems
Generates multiple model candidates and ranks them
Provides full visibility into model creation process
Exports Python code for customization
No ML expertise required to get started

3. SageMaker Feature Store

Centralized repository for ML features
Online store for low-latency real-time inference (sub-millisecond)
Offline store for training and batch inference
Feature versioning and lineage tracking
Automatic feature discovery across teams
Point-in-time correct queries for historical data

4. SageMaker Data Wrangler

Visual data preparation tool with 300+ built-in transformations
Import data from S3, Athena, Redshift, Snowflake
Interactive data quality insights and visualizations
Automatic data quality issue detection
Export workflows to SageMaker Pipelines
Generate Python code for custom transformations

5. SageMaker Training

Distributed training across multiple GPUs and instances
Supports TensorFlow, PyTorch, MXNet, scikit-learn, XGBoost
Managed spot training for up to 90% cost savings
Automatic model tuning (hyperparameter optimization)
SageMaker Training Compiler for 50% faster training
Checkpointing for fault tolerance

6. SageMaker Inference

Real-time endpoints with auto-scaling
Serverless inference (no infrastructure management)
Batch transform for large-scale predictions
Multi-model endpoints (host multiple models on one endpoint)
Multi-container endpoints for ML pipelines
Shadow testing for A/B testing new models

7. SageMaker Pipelines (MLOps)

CI/CD for machine learning workflows
Visual pipeline designer
Automated model retraining triggers
Integration with SageMaker Model Registry
Step caching to avoid redundant computations
Parallel execution of pipeline steps

8. SageMaker Clarify

Detect bias in training data and models
Explain model predictions with SHAP values
Feature importance analysis
Fairness metrics across demographic groups
Model explainability reports
Integration with SageMaker Model Monitor

9. SageMaker Model Monitor

Continuous monitoring of deployed models
Data quality monitoring (schema violations, missing values)
Model quality monitoring (accuracy drift)
Bias drift detection
Feature attribution drift
Automated alerts via CloudWatch and SNS

10. SageMaker Debugger

Real-time monitoring of training jobs
Automatic detection of training issues (vanishing gradients, overfitting)
Built-in rules for common problems
Tensor visualization and analysis
Profiling for system bottlenecks
Automatic termination of problematic jobs

11. SageMaker Ground Truth

Managed data labeling service
Human labeling workforce (Amazon Mechanical Turk, private, vendor)
Active learning to reduce labeling costs by 40%
Built-in workflows for images, text, video, 3D point clouds
Custom labeling workflows
Automatic data labeling using ML

12. SageMaker Neo

Compile models for edge devices
Optimize models for 2x faster inference
Support for ARM, Intel, NVIDIA processors
Deploy to AWS IoT Greengrass
Reduce model size by up to 10x
No accuracy loss during optimization

13. SageMaker JumpStart

600+ pre-trained models from popular model hubs
One-click deployment of foundation models
Fine-tuning capabilities for domain adaptation
Solution templates for common use cases
Example notebooks for learning
Models from Hugging Face, PyTorch Hub, TensorFlow Hub

Real-World Use Case: Healthcare Diagnostics

A healthcare startup building a diagnostic tool for rare diseases has proprietary medical imaging data. They need a custom computer vision model because off-the-shelf solutions won't work for their specialized use case.

Implementation with SageMaker:

Use Ground Truth to label medical images with expert radiologists
Data Wrangler to preprocess and augment imaging data
Feature Store to manage extracted image features
Train custom ResNet model with SageMaker Training on GPU instances
Clarify to detect bias in predictions across patient demographics
Model Monitor to track model performance in production
Deploy with HIPAA-compliant endpoints for real-time diagnosis
Pipelines to automate retraining when new labeled data arrives

Result: From concept to production in 6 weeks instead of 6 months, with 94% diagnostic accuracy and full compliance with healthcare regulations.

TIER 2: The GenAI Revolution - Amazon Bedrock

Amazon Bedrock: Your Gateway to Foundation Models

Amazon Bedrock is AWS's fully managed service for building generative AI applications. Instead of training foundation models from scratch (which costs millions), Bedrock gives you access to leading AI models through a single API.

Available Foundation Models:

1. Amazon Titan Models

Titan Text: Text generation, summarization, Q&A (up to 32K tokens)
Titan Embeddings: Convert text to numerical vectors for semantic search
Titan Image Generator: Create realistic images from text descriptions
Titan Multimodal Embeddings: Process text and images together

2. Anthropic Claude

Claude 4.5 Opus: Most capable, complex reasoning
Claude 4.5 Sonnet: Balanced performance and speed
Claude 4 Haiku: Fastest, most compact
200K token context window
Strong at analysis, coding, math, creative writing

3. Meta Llama Models

Llama 4
Open-source architecture
Multilingual support
Strong coding capabilities

4. AI21 Labs Jurassic

Jurassic-2 Ultra and Mid
Optimized for enterprise use cases
Multilingual text generation

5. Cohere Command

Command R and Command R+
Retrieval-augmented generation (RAG) optimized
Multilingual support (10+ languages)

6. Stability AI

Stable Diffusion XL for image generation
High-quality, customizable images
Style control and fine-tuning

Core Bedrock Features:

1. Knowledge Bases for Amazon Bedrock

Connect your proprietary data sources (S3, SharePoint, Confluence, Salesforce)
Automatic data chunking and embedding
Vector database integration (Amazon OpenSearch, Pinecone, Redis)
Retrieval-Augmented Generation (RAG) without code
Automatic citation of sources in responses
Metadata filtering for precise retrieval
Hybrid search (keyword + semantic)

2. Agents for Amazon Bedrock

Build autonomous AI agents that take actions
Define agent instructions in natural language
Connect to APIs and Lambda functions
Multi-step task orchestration
Memory and context management
Action groups for organizing capabilities
Automatic API schema parsing

3. Guardrails for Amazon Bedrock

Content filtering (hate speech, violence, sexual content)
PII detection and redaction (names, addresses, SSN, credit cards)
Topic-based restrictions (block specific subjects)
Word filters (denied terms and phrases)
Contextual grounding checks (prevent hallucinations)
Toxicity thresholds (configurable sensitivity)
Apply to both inputs and outputs

4. Model Customization

Fine-tuning: Adapt models with your labeled data
Continued Pre-training: Train on large unlabeled datasets
Private training (data never leaves your VPC)
Custom model versioning
A/B testing between base and custom models
Automatic hyperparameter tuning

5. Model Evaluation

Built-in evaluation metrics (accuracy, toxicity, relevance)
Human evaluation workflows
Automatic benchmarking against test datasets
Compare multiple models side-by-side
Custom evaluation criteria

6. Prompt Management

Save and version prompts
Prompt templates with variables
A/B test different prompts
Share prompts across teams
Prompt flow for multi-step workflows

Real-World Use Case: E-Commerce AI Shopping Assistant

A large e-commerce company wants to build an intelligent shopping assistant that understands customer queries, searches their product catalog, and provides personalized recommendations.

Implementation with Bedrock:

Step 1: Knowledge Base Setup

Upload product catalog (100K products) to S3
Create Bedrock Knowledge Base with product descriptions, specs, reviews
Enable hybrid search for both keyword and semantic matching

Step 2: Agent Configuration

Create Bedrock Agent with Claude 3 Sonnet
Define agent instructions: "You are a helpful shopping assistant. Help customers find products, answer questions, and provide recommendations."
Connect action groups:
- check_inventory: Lambda function to check real-time stock
- get_pricing: API to fetch current prices and discounts
- create_cart: Add items to shopping cart
- track_order: Check order status

Step 3: Guardrails

Block competitor mentions
Redact customer PII from logs
Prevent price promises ("I guarantee lowest price")
Filter inappropriate product searches
Contextual grounding to prevent hallucinated product features

Step 4: Deployment

Deploy agent with API Gateway
Integrate with website chat widget
Mobile app integration
Voice interface with Amazon Connect

Results:

70% reduction in customer service tickets
35% increase in conversion rate
Average response time: 2 seconds
Handles 50K concurrent conversations
92% customer satisfaction score
ROI achieved in 3 months

TIER 3: Ready-to-Use AI Services - No ML Expertise Required

These are fully managed, pre-trained services that you call via simple APIs. No model training, no infrastructure management—just add AI capabilities to your applications.

Amazon Rekognition: Computer Vision Made Simple

What it does: Analyzes images and videos to detect objects, faces, text, scenes, and activities.

Key Features:

Image Analysis:

Object and Scene Detection: Identify 10K+ objects (cars, furniture, animals) and scenes (beach, city, sunset)
Facial Analysis: Detect faces with attributes (age range, gender, emotions, glasses, beard, eyes open/closed)
Face Comparison: Compare two faces for similarity (useful for identity verification)
Celebrity Recognition: Identify 100K+ celebrities automatically
Text Detection (OCR): Extract text in multiple languages and orientations
Content Moderation: Detect explicit, suggestive, violent, or disturbing content with confidence scores
PPE Detection: Identify personal protective equipment (face covers, hand covers, head covers)
Custom Labels: Train custom models with as few as 10 images per category

Video Analysis:

Person Tracking: Track people across video frames with unique IDs
Activity Detection: Recognize activities (running, playing sports, dancing)
Object Tracking: Follow objects through video
Celebrity Recognition in Video: Identify when celebrities appear
Face Search in Video: Find specific people in video libraries
Content Moderation in Video: Detect inappropriate content with timestamps
Segment Detection: Identify black frames, color bars, end credits, shots
Technical Cue Detection: Find SMPTE color bars, black frames, opening/closing credits

Advanced Capabilities:

Custom Moderation: Train adapters for brand-specific content policies
Streaming Video Analysis: Real-time analysis with Kinesis Video Streams
Batch Processing: Analyze thousands of images in parallel

Real-World Use Case: Social Media Content Moderation

A social media platform receives 10 million image uploads daily and needs to moderate content before it goes live.

Implementation:

Images uploaded to S3 trigger Lambda function
Rekognition DetectModerationLabels API analyzes each image
Custom Labels model trained to detect platform-specific violations (logo misuse, banned symbols)
Images with confidence > 90% automatically rejected
Images with 50-90% confidence sent to human moderators
Facial recognition prevents banned users from creating new accounts
Text detection identifies phone numbers and URLs in images

Results:

95% of inappropriate content blocked automatically
Human moderation workload reduced by 80%
Average processing time: 300ms per image
Cost: $0.001 per image analyzed
False positive rate: < 2%

Amazon Textract: Document Intelligence Beyond OCR

What it does: Extracts text, handwriting, tables, forms, and structured data from scanned documents.

Key Features:

Text Extraction:

Printed Text Detection: Extract text with 99%+ accuracy
Handwriting Recognition: Read cursive and printed handwriting
Multi-language Support: 100+ languages including Arabic, Chinese, Japanese
Layout Understanding: Preserve document structure (paragraphs, columns, headers)
Confidence Scores: Per-word confidence levels

Form Extraction:

Key-Value Pair Detection: Automatically identify form fields and values
Checkbox Detection: Recognize selected/unselected checkboxes
Radio Button Detection: Identify selected options
Signature Detection: Locate signature fields
Relationship Mapping: Link keys to their corresponding values

Table Extraction:

Table Structure Recognition: Identify rows, columns, cells
Merged Cell Handling: Understand complex table layouts
Multi-page Tables: Track tables spanning multiple pages
Nested Tables: Extract tables within tables
Cell Relationships: Maintain row/column associations

Specialized Features:

Queries: Ask specific questions about documents ("What is the invoice total?")
AnalyzeExpense: Extract data from invoices and receipts (vendor, date, line items, tax, total)
AnalyzeID: Extract information from identity documents (passports, driver's licenses)
Custom Adapters: Train on your document types for improved accuracy
Layout Analysis: Understand document structure (titles, headers, footers, page numbers)

Real-World Use Case: Insurance Claims Processing

An insurance company processes 50K claim forms monthly—mix of printed forms, handwritten notes, and attached receipts.

Implementation:

Claims submitted via mobile app or email
Documents uploaded to S3
Textract AnalyzeDocument extracts:
- Policyholder information (name, policy number, date of birth)
- Claim details (incident date, description, amount claimed)
- Checkboxes (injury type, property damage)
- Handwritten notes from adjusters
Textract AnalyzeExpense processes receipts:
- Vendor names, dates, line items, totals
Extracted data validated and inserted into claims system
Queries feature asks: "What is the total claim amount?" "When did the incident occur?"

Results:

Processing time: 30 seconds (down from 10 minutes manual)
98% extraction accuracy
90% straight-through processing (no human intervention)
$2M annual savings in processing costs
Claims settled 5x faster

Amazon Comprehend: Natural Language Understanding

What it does: Analyzes text to extract insights, sentiment, entities, and relationships.

Key Features:

Sentiment Analysis:

Document-level Sentiment: Overall positive, negative, neutral, or mixed
Targeted Sentiment: Sentiment toward specific entities ("The food was great but service was slow")
Confidence Scores: Probability for each sentiment
Multi-language Support: 100+ languages

Entity Recognition:

Built-in Entity Types: Person, location, organization, date, quantity, title, event, brand, commercial item
Custom Entity Recognition: Train models for domain-specific entities (product codes, medical terms)
Entity Linking: Connect entities to knowledge bases
Confidence Scores: Per-entity confidence levels

Key Phrase Extraction:

Identify important phrases in text
Rank by relevance
Multi-language support

Language Detection:

Identify dominant language in text
Support for 100+ languages
Confidence scores for each detected language

Syntax Analysis:

Part-of-speech tagging (noun, verb, adjective)
Tokenization
Sentence boundary detection

Topic Modeling:

Discover topics in document collections
Unsupervised learning
Topic distribution per document

PII Detection and Redaction:

Identify personally identifiable information
Detect: names, addresses, SSN, credit cards, phone numbers, emails, IP addresses, passport numbers, driver's licenses
Redaction modes: mask, replace with entity type, or remove
Confidence scores

Custom Classification:

Train custom text classifiers
Multi-class and multi-label classification
As few as 50 training examples per class
Automatic model training and deployment

Comprehend Medical:

Extract medical entities (medications, conditions, procedures, anatomy, test results)
Detect protected health information (PHI)
Understand relationships (medication dosage, test results)
ICD-10-CM and RxNorm code linking
HIPAA eligible

Real-World Use Case: Customer Support Intelligence

A SaaS company receives 10K support tickets daily across email, chat, and phone transcripts.

Implementation:

All tickets ingested into S3
Comprehend analyzes each ticket:
- Sentiment Analysis: Identify angry customers (priority routing)
- Entity Recognition: Extract product names, feature requests, error codes
- Custom Classification: Categorize by issue type (billing, technical, feature request)
- PII Detection: Redact customer data before storing in analytics database
- Key Phrases: Identify trending issues
Results feed into:
- Automatic ticket routing
- Priority queues (negative sentiment = high priority)
- Product team dashboard (feature requests, bugs)
- Knowledge base article suggestions

Results:

60% faster ticket routing
40% reduction in response time
25% improvement in customer satisfaction
Identified 3 critical bugs within hours of first report
Automatic compliance with data privacy regulations

Amazon Polly: Text-to-Speech That Sounds Human

What it does: Converts text into lifelike speech in 60+ languages.

Key Features:

Voice Options:

Neural TTS Voices: Most natural-sounding, human-like quality
Generative Voices: Create unique brand voices
Long-form Voices: Optimized for long content (audiobooks, articles)
Standard Voices: Cost-effective option
Newscaster Style: Professional news anchor tone
Conversational Style: Casual, friendly tone
60+ Languages: Including English, Spanish, French, German, Japanese, Arabic, Hindi

Speech Customization:

SSML Support: Control pronunciation, emphasis, pauses, pitch, rate
Lexicons: Custom pronunciation for brand names, acronyms, technical terms
Speech Marks: Get metadata (phonemes, visemes, word timing) for lip-sync
Breathing Sounds: Add natural breathing for realism
Dynamic Range Compression: Optimize for different playback devices

Advanced Features:

Brand Voice: Create custom neural voice for your brand (requires voice talent recording)
Voice Cloning: Generate speech in specific person's voice (with consent)
Real-time Streaming: Stream audio as it's generated
Batch Synthesis: Generate hours of audio asynchronously
Multiple Output Formats: MP3, OGG, PCM

Real-World Use Case: E-Learning Platform

An online education platform offers 5K courses and wants to add audio narration in 20 languages without hiring voice actors.

Implementation:

Course content stored as text in database
Polly generates audio narration:
- Neural voices for premium courses
- Long-form voices for lengthy lectures
- Newscaster style for formal content
- Conversational style for casual tutorials
Custom lexicons for:
- Technical terms (API, SQL, Kubernetes)
- Brand names (AWS, SageMaker)
- Acronyms (HTML, CSS, REST)
SSML for:
- Pauses between sections
- Emphasis on key concepts
- Slower speech for complex topics
Audio cached in CloudFront CDN
Students can adjust playback speed

Results:

$500K annual savings (vs. voice actors)
Audio generated in minutes (vs. weeks)
20 languages supported (vs. 3 previously)
40% increase in course completion rates
Accessibility compliance achieved
Update course audio in hours when content changes

Amazon Transcribe: Speech-to-Text with Intelligence

What it does: Converts audio and video to accurate text transcripts with advanced features.

Key Features:

Core Transcription:

Automatic Speech Recognition (ASR): 99%+ accuracy for clear audio
Real-time Streaming: Transcribe live audio with sub-second latency
Batch Transcription: Process pre-recorded audio files
Multi-language Support: 100+ languages and dialects
Automatic Language Identification: Detect language automatically
Multi-language Audio: Transcribe audio with multiple languages

Speaker Features:

Speaker Diarization: Identify and separate different speakers (up to 10 speakers)
Speaker Labels: Tag each utterance with speaker ID
Channel Identification: Separate audio channels (useful for call center recordings)

Accuracy Enhancement:

Custom Vocabulary: Add domain-specific terms, brand names, acronyms
Vocabulary Filtering: Mask or remove profanity and sensitive words
Custom Language Models: Train on your domain-specific text for better accuracy
Automatic Punctuation: Add periods, commas, question marks
Number Formatting: Convert spoken numbers to digits

Advanced Features:

Partial Results: Get transcripts as speech is detected (streaming)
Confidence Scores: Per-word confidence levels
Timestamps: Word-level and sentence-level timing
Redaction: Automatically redact PII (SSN, credit cards, names)
Content Moderation: Flag profanity and inappropriate content
Subtitle Generation: Create WebVTT and SRT subtitle files
Call Analytics: Specialized features for call center recordings
- Sentiment analysis per speaker
- Call categorization
- Issue detection
- Interruption tracking
- Talk time analysis
- Non-talk time detection

Transcribe Medical:

Medical terminology recognition
Specialty-specific vocabularies (cardiology, neurology, oncology)
Medication names and dosages
HIPAA eligible
Automatic PHI identification

Real-World Use Case: Legal Firm Deposition Management

A law firm records 200+ client meetings, depositions, and court proceedings monthly and needs searchable transcripts.

Implementation:

Audio recordings uploaded to S3
Transcribe processes with:
- Speaker diarization (identify attorney, client, witnesses)
- Custom vocabulary (legal terms, case-specific names, technical jargon)
- PII redaction for sensitive information
- Timestamps for easy reference
Transcripts stored in searchable database
Integration with case management system
Lawyers can search: "Find all mentions of contract breach in Smith deposition"

Results:

Transcription time: 30 minutes (vs. 8 hours manual)
Cost: $0.024 per minute of audio
97% accuracy with custom vocabulary
Searchable archive of 10 years of recordings
Paralegals save 20 hours/week
Critical testimony found in seconds, not hours

Amazon Translate: Neural Machine Translation

What it does: Translates text between 75+ languages in real-time with high accuracy.

Key Features:

Translation Capabilities:

75+ Languages: Including major languages and regional dialects
Neural Machine Translation: Context-aware, fluent translations
Real-time Translation: Translate text instantly via API
Batch Translation: Translate large documents asynchronously
Automatic Language Detection: Identify source language automatically

Customization:

Custom Terminology: Define how specific terms should be translated
- Brand names (keep unchanged)
- Technical terms (consistent translation)
- Industry jargon
Parallel Data: Provide example translations to improve quality
Formality Control: Choose formal or informal tone (for supported languages)
Profanity Masking: Mask profane words in translations

Advanced Features:

Document Translation: Translate Word, PowerPoint, Excel files while preserving formatting
Active Custom Translation: Real-time custom model training
Translation Quality Estimation: Confidence scores for translations
Brevity Control: Adjust translation length
HTML Translation: Translate HTML content while preserving tags

Real-World Use Case: Global SaaS Platform

A B2B SaaS company serves customers in 50 countries and needs to localize their application, documentation, and support content.

Implementation:

Application UI:
- All UI strings stored in resource files
- Translate API called at build time
- Custom terminology for product features ("Dashboard" → consistent across languages)
- Formality set to "formal" for business context
Help Documentation:
- 500 articles in English
- Batch translation to 20 languages
- Document translation preserves formatting
- Technical terms (API endpoints, code samples) kept in English
Customer Support:
- Real-time translation of support tickets
- Support agents respond in English, automatically translated to customer's language
- Custom terminology for product-specific terms
Marketing Content:
- Website content translated with formality control
- Regional dialect support (Spanish for Spain vs. Latin America)

Results:

20 languages supported (vs. 3 manual translations)
Translation cost: $15 per million characters
Time to add new language: 1 day (vs. 3 months)
35% increase in international revenue
50% reduction in support response time for non-English customers
Consistent terminology across all touchpoints

Amazon Lex: Build Conversational Interfaces

What it does: Create chatbots and voice assistants with the same technology that powers Alexa.

Key Features:

Conversation Design:

Intents: Define what users want to accomplish
Slots: Extract specific information from user input (dates, names, numbers)
Slot Types: Built-in types (dates, numbers, cities) and custom types
Utterances: Example phrases users might say
Prompts: Questions bot asks to gather information
Confirmation: Ask users to confirm before taking action

Natural Language Understanding:

Intent Recognition: Understand user's goal from natural language
Entity Extraction: Pull out key information (dates, locations, products)
Context Management: Remember conversation history
Multi-turn Conversations: Handle complex, multi-step interactions
Sentiment Detection: Understand user's emotional state
Automatic Speech Recognition: Voice input support

Advanced Features:

Lambda Integration: Execute business logic and API calls
Session Attributes: Store conversation state
Conditional Branching: Different conversation flows based on context
Slot Validation: Ensure collected information is valid
Fallback Intents: Handle unrecognized input gracefully
AMAZON.KendraSearchIntent: Search knowledge bases for answers
Multi-language Support: 20+ languages
Voice and Text: Same bot works for both modalities

Deployment Options:

Amazon Connect: Integrate with contact center
Facebook Messenger: Deploy to social media
Slack: Enterprise chat integration
Twilio SMS: Text message interface
Custom Applications: Web, mobile, IoT devices

Real-World Use Case: Banking Customer Service Bot

A bank wants to automate routine customer inquiries to reduce call center volume.

Implementation:

Intents Created:

CheckBalance: "What's my account balance?"
TransferFunds: "Transfer $500 from checking to savings"
PayBill: "Pay my electric bill"
ReportCard: "I lost my credit card"
FindATM: "Where's the nearest ATM?"
GetHelp: "I need to speak to someone"

Conversation Flow Example (CheckBalance):

User: "What's my balance?"
Bot: "I can help with that. Which account? Checking or savings?"
User: "Checking"
Bot: [Lambda calls banking API]
Bot: "Your checking account balance is $2,450.32. Anything else I can help with?"

Features Used:

Slot validation (account type must be checking/savings)
Lambda integration for real-time balance lookup
Session attributes to remember user's account preferences
Sentiment detection to escalate frustrated customers to human agents
Multi-factor authentication via SMS before showing sensitive info
Voice interface for phone banking
Text interface for mobile app and website

Results:

70% of routine inquiries handled by bot
500K calls/month deflected from human agents
$3M annual cost savings
Average interaction time: 45 seconds
24/7 availability
Customer satisfaction: 4.2/5 stars
Escalation to human agent when needed: 15% of conversations

Amazon Personalize: Real-Time Recommendations

What it does: Provides personalized recommendations using the same technology as Amazon.com.

Key Features:

Recommendation Types:

User Personalization: Recommend items based on user's history and preferences
Similar Items: "Customers who viewed this also viewed..."
Personalized Ranking: Rerank items based on user's preferences
Trending Now: Popular items with momentum
Next Best Action: Recommend optimal action for user engagement

Data Inputs:

Interactions: User behavior (clicks, purchases, views, ratings)
User Metadata: Demographics, preferences, subscription tier
Item Metadata: Categories, price, description, attributes
Contextual Data: Device type, location, time of day

Advanced Features:

Real-time Events: Update recommendations as users interact
Cold Start: Recommendations for new users and items
Business Rules: Apply filters and promotions
- Boost certain items
- Filter out out-of-stock items
- Promote seasonal content
A/B Testing: Compare recommendation strategies
Batch Recommendations: Generate recommendations for all users offline
Exploration: Balance popular items with discovery

Recipes (Algorithms):

User-Personalization: General-purpose recommendations
Personalized-Ranking: Rerank search results
Similar-Items: Item-to-item similarity
Popularity-Count: Most popular items
Next-Best-Action: Optimize for specific goals

Real-World Use Case: Streaming Service

A video streaming platform with 10M users wants to increase watch time and reduce churn.

Implementation:

Data Collection:

User interactions: watch history, ratings, searches, pauses, skips
User metadata: age, location, subscription tier, device preferences
Content metadata: genre, actors, director, release year, duration, language

Recommendation Strategies:

Homepage: User-Personalization recipe for "Recommended for You"
Video Page: Similar-Items for "Because you watched..."
Search Results: Personalized-Ranking to reorder results
Trending Section: Popularity-Count with time decay
Email Campaigns: Batch recommendations for weekly digest

Business Rules Applied:

Boost new releases for first 7 days
Filter content not available in user's region
Promote content user's subscription tier has access to
Reduce recommendations for genres user consistently skips

Real-time Updates:

User watches 10 minutes of a show → immediately update recommendations
User rates a movie → adjust similar content recommendations
User searches for "comedy" → boost comedy recommendations

Results:

25% increase in average watch time
15% reduction in churn rate
40% of content discovered through recommendations
60% increase in email click-through rates
30% improvement in new content discovery
ROI: 8x within first year

Industry-Specific & Specialized AI Services

Amazon Forecast: Time-Series Forecasting

What it does: Predicts future values based on historical time-series data using machine learning.

Key Features:

Forecasting Capabilities:

Automatic Model Selection: Tests multiple algorithms and picks the best
Built-in Algorithms: CNN-QR, DeepAR+, Prophet, NPTS, ARIMA, ETS
Probabilistic Forecasts: P10, P50, P90 quantiles for uncertainty
Multiple Time Series: Forecast thousands of related time series together
Missing Data Handling: Automatically fills gaps in historical data

Data Types Supported:

Target Time Series: Historical values to forecast (sales, demand, traffic)
Related Time Series: Additional data that influences target (price, promotions, weather)
Item Metadata: Static attributes (product category, store location)

Domain-Specific Features:

Retail Domain: Demand forecasting with promotions, holidays, stockouts
Inventory Planning: Optimize stock levels across locations
Workforce Planning: Predict staffing needs
EC2 Capacity: Forecast compute resource requirements
Web Traffic: Predict website visitors
Metrics: Forecast custom business metrics

Advanced Features:

Holiday Calendars: Built-in holiday effects for 250+ countries
Weather Index: Incorporate weather data automatically
What-If Analysis: Simulate different scenarios
Explainability: Understand which factors drive forecasts
Automatic Retraining: Keep models fresh with new data

Real-World Use Case: Retail Chain Inventory Optimization

A retail chain with 500 stores needs to forecast demand for 50K products to optimize inventory.

Implementation:

Historical sales data (3 years) uploaded to S3
Related time series: promotions, holidays, local events, weather
Item metadata: category, price tier, seasonality
Forecast generates predictions for next 12 weeks
P10 forecast for safety stock
P50 forecast for base inventory
P90 forecast for peak demand scenarios
Automated retraining weekly with latest sales data

Results:

40% reduction in stockouts
35% reduction in overstock
$15M annual savings in inventory costs
25% improvement in forecast accuracy vs. previous statistical methods
Optimized distribution center allocation
Better promotional planning

Amazon Fraud Detector: ML-Powered Fraud Prevention

What it does: Identifies potentially fraudulent online activities using machine learning.

Key Features:

Fraud Types Detected:

Online Fraud: Fake account creation, payment fraud
Account Takeover: Unauthorized access to existing accounts
Transaction Fraud: Suspicious purchases and payments
Identity Verification: Validate user identity during onboarding

Built-in Models:

Online Fraud Insights: Pre-trained model for common fraud patterns
Transaction Fraud Insights: Detect suspicious transactions
Account Takeover Insights: Identify compromised accounts

Custom Models:

Train on your historical fraud data
Automatic feature engineering
Model versioning and A/B testing
Continuous learning from new fraud patterns

Features:

Real-time Scoring: Evaluate transactions in milliseconds
Risk Scores: 0-1000 scale indicating fraud likelihood
Rules Engine: Combine ML predictions with business rules
Explainability: Understand why transaction was flagged
SageMaker Integration: Use custom ML models
Event Tracking: Monitor outcomes to improve models

Real-World Use Case: Online Marketplace Fraud Prevention

An online marketplace processes 1M transactions daily and loses $5M annually to fraud.

Implementation:

Historical transaction data (2 years) with fraud labels
Features tracked:
- User behavior (account age, purchase history, login patterns)
- Transaction details (amount, payment method, shipping address)
- Device fingerprinting (IP address, browser, device ID)
- Velocity checks (transactions per hour, new addresses)
Custom model trained on marketplace-specific fraud patterns
Rules engine:
- Block transactions with score > 900
- Manual review for scores 700-900
- Approve scores < 700
Real-time scoring at checkout
Feedback loop: confirmed fraud updates model

Results:

60% reduction in fraud losses ($3M saved annually)
False positive rate reduced from 15% to 3%
Average scoring time: 50ms
Legitimate customers rarely impacted
Fraud detection rate: 95%
ROI: 15x in first year

Amazon HealthLake: Healthcare Data Management

What it does: Stores, transforms, and analyzes health data at scale with FHIR support.

Key Features:

Data Management:

FHIR Support: Fast Healthcare Interoperability Resources standard
Data Ingestion: Import from multiple EHR systems
Data Normalization: Standardize data from different sources
Medical NLP: Extract insights from clinical notes
Structured and Unstructured Data: Handle both types

Analytics:

Integrated Analytics: Query with Amazon Athena
Medical Entity Extraction: Medications, conditions, procedures
Temporal Queries: Track patient history over time
Population Health: Aggregate data for research
Cohort Identification: Find patients matching criteria

Compliance:

HIPAA Eligible: Meets healthcare privacy requirements
Encryption: At rest and in transit
Audit Logging: Track all data access
Access Controls: Fine-grained permissions

Real-World Use Case: Hospital Network Data Unification

A hospital network with 5 facilities uses different EHR systems and needs unified patient records.

Implementation:

Data from Epic, Cerner, Meditech ingested into HealthLake
FHIR transformation normalizes data structure
Medical NLP extracts entities from clinical notes
Unified patient view across all facilities
Doctors access complete medical history regardless of where patient was treated
Research team queries de-identified data for clinical studies
Population health analytics identify high-risk patients

Results:

Complete patient history available in seconds
50% reduction in duplicate tests
Improved care coordination
Faster diagnosis with complete information
Research insights from 500K patient records
Compliance with HIPAA maintained

The New Generation: 2025 GenAI Services

Amazon Q: The AI Assistant Family

Amazon Q is not a single product—it's a family of three specialized AI assistants, each designed for different use cases.

1. Amazon Q Developer

What it does: AI-powered coding assistant for software developers.

Key Features:

Code generation in 15+ languages (Python, Java, JavaScript, TypeScript, C#, Go, Rust, etc.)
Code explanation and documentation generation
Security vulnerability detection (SQL injection, XSS, CSRF)
Automated code transformations and refactoring
Unit test generation
AWS infrastructure code generation (CloudFormation, Terraform)
IDE integration (VS Code, JetBrains, Visual Studio, Cloud9)

Pricing:

Free Tier: Basic code completions
Professional ($19/user/month): Unlimited completions, security scanning, code transformations
Enterprise (Custom): Private deployment, custom training, SSO

Real-World Use Case:
Financial services company upgraded 500K lines of Java 8 code to Java 17 with Spring Boot 3 in 3 weeks (vs. 6 months manual), achieving 95% automated transformation with zero production bugs.

2. Amazon Q Business

What it does: Enterprise knowledge assistant that connects to your company's data sources.

Key Features:

Natural language search across 40+ data sources (Slack, Teams, Confluence, SharePoint, Salesforce, S3, databases)
Semantic search with automatic source citations
Role-based access control (respects source system permissions)
PII detection and redaction
Conversational AI with multi-turn context
Analytics dashboard for query tracking

Pricing:

Lite ($3/user/month): 10 data sources, 100 queries/month
Plus ($20/user/month): Unlimited sources and queries
Enterprise (Custom): VPC deployment, custom training

Real-World Use Case:
Global consulting firm with 15K employees connected 10 years of project documentation, achieving 70% reduction in search time, 5 hours/week saved per consultant, and $10M annual productivity savings.

3. Amazon Q in QuickSight

What it does: Natural language interface for business intelligence.

Key Features:

Ask questions in plain English ("What were top 5 products last quarter?")
Automatic visualization selection and dashboard creation
Executive summaries and data storytelling
Proactive anomaly detection and insights
Trend identification and forecasting explanations

Pricing:

$250/month for 10 users, $25/user/month additional
Unlimited queries

Real-World Use Case:
Retail chain with 200 stores enabled executives to get answers in seconds vs. days, achieving 80% reduction in ad-hoc report requests and 100% executive adoption.

Kiro: Agentic IDE for Spec-Driven Development

What it does: Agentic coding service that transforms prompts into detailed specifications, then into working code, documentation, and tests.

Key Features:

Spec-Driven Coding:

Converts natural language prompts into structured specifications
Breaks down features into logical implementation steps
Generates requirements, design documents, and data flow diagrams
Creates code, tests, and API integrations

Conversational Development:

Chat with Kiro about your codebase
Request explanations for complex logic
Generate new features through conversation
Debug issues with AI assistance

Agent Hooks:

Automated triggers for predefined actions
Execute tasks on file save, create, or delete events
Automate routine development tasks

Steering Files:

Persistent project knowledge through markdown files
Define coding conventions and standards
Ensure consistent patterns across codebase

Built on Amazon Bedrock:

Uses multiple foundation models
Automated abuse detection
Enterprise-grade security

Privacy & Security:

Free tier data may be used for service improvement
Enterprise users get customer-managed encryption keys
Granular access controls

Real-World Use Case:
Software teams use Kiro to go from prompt to feature with step-by-step guidance, reducing development time by automating documentation, test generation, and boilerplate code while maintaining code quality standards.

Amazon Nova Act: UI Automation Agent

What it does: Foundation model that can interact with user interfaces—clicking buttons, filling forms, navigating websites and applications.

Key Capabilities:

Visual Understanding:

Recognizes UI elements (buttons, forms, menus, links)
Understands screen layouts and context
Adapts to UI changes dynamically

Action Execution:

Click, type, scroll, navigate
Fill forms with data
Submit information
Handle pop-ups and dialogs

Multi-Step Workflows:

Complete complex tasks across multiple screens
Chain actions together
Maintain context throughout workflow

Error Handling:

Retry failed actions
Adapt when UI changes
Handle unexpected states
Provide detailed logs for audit

Cross-Platform:

Web applications
Desktop applications
Mobile apps (future)
Legacy systems without APIs

Use Cases:

Data entry automation across legacy systems
Automated testing of web applications
RPA (Robotic Process Automation) replacement
Integration with systems lacking APIs
Compliance and audit workflows

Real-World Use Case: Accounting Firm Automation

An accounting firm manually enters data into 5 different legacy systems without APIs.

Implementation:

Nova Act agent trained to:
- Log into each system
- Navigate to data entry forms
- Fill in client information
- Submit and verify entries
- Handle error messages
Agent runs on schedule
Processes 500 entries/day
Logs all actions for audit compliance

Results:

200 hours/month saved
99.5% accuracy
Runs 24/7
Eliminates manual data entry errors
Frees staff for higher-value work

Amazon Bedrock AgentCore

Amazon Bedrock AgentCore is a fully-managed agent platform built by AWS to help organizations build, deploy, operate, and scale AI agents in production, with enterprise-grade security, observability, and flexibility. Instead of just prototyping with a framework locally, AgentCore provides cloud-ready infrastructure and services so agents can run reliably at scale.

🚀 Core Features

📌 1. Universal Framework & Model Support

Works with any agent framework like LangChain, LangGraph, CrewAI, Strands Agents, etc.
Supports any foundation model, including Amazon Bedrock models (Claude, Nova, Titan) and external providers.

🛠️ 2. Managed Runtime

Purpose-built serverless environment to deploy and run agents and tools without managing servers.
Session isolation ensures each user’s context and data is protected.
Supports long-running tasks (up to hours), async jobs, streaming responses, and WebSocket interactions.

🧠 3. AgentCore Memory

Built-in memory system for context retention across sessions and users.
Enables both short-term interaction context and long-term knowledge for personalization and coherence.

🔐 4. Identity & Security

Identity management service to securely authenticate agents and sessions via OAuth, IAM, and external identity providers.
Protects credentials and supports secure access to third-party systems.

🔗 5. AgentCore Gateway

Acts as a bridge between AI agents and external APIs or Lambda functions, exposing them as tools that agents can call.
Features like debug messaging, custom encryption, semantic search for tools, and tagging for organization.

🧪 6. Observability & Quality Controls

Integrated observability for metrics, logs, tracing, and dashboards so teams can monitor agent behavior.
New policy enforcement and evaluation features help ensure agents obey compliance and quality standards.

🧩 7. Tooling & Execution Enhancements

Code Interpreter tool allows agents to execute safe sandboxed code.
Browser tool lets agents interact with live websites securely at scale.

✅ Enterprise Benefits

Capability	What It Enables
Security & Identity	Enterprise IAM + OAuth + secure credential storage
Scalability	Serverless scaling with session isolation
Observability	Traceable logs and performance metrics
Governance	Policy controls and quality evaluation
Tool Integrations	Easy API, Lambda, and external service integration

These features make AgentCore suitable for real-world deployment where reliability, governance, and auditability are critical.

📌 Solid Use Case: Enterprise IT Support Assistant

Overview

An enterprise wants an AI agent that can handle internal IT support tickets automatically — from reading tickets and troubleshooting to resolving common issues or handing over to human support when needed.

AgentCore Implementation

Runtime & Scaling

Deploy an IT agent using AgentCore Runtime that can respond at scale as ticket volume fluctuates.
Memory & Context
- Memory stores session context such as user history, common resolutions, and preferences.
Identity Integration
- Authenticate users via corporate OAuth/SAML for secure access to internal systems.
Tool Integrations
- Connect to internal APIs (e.g., helpdesk systems, knowledge base, asset inventory) using the Gateway.
- Agents can run diagnostic scripts via the Code Interpreter tool to gather logs or run fixes.
Observability & Quality
- Admins monitor agent effectiveness, ticket resolution rates, and anomalous behavior via observability dashboards.
- Built-in policy controls ensure agents don’t perform unsafe actions.

Results

Faster response times on common issues.
Reduced workload for human IT support.
Secure access to enterprise systems without exposing credentials.
Reliable audit trails for compliance.

Understanding the AWS AI/ML Stack vs. GenAI Stack

Now that we've explored all the services, let's create a clear distinction between the traditional ML stack and the GenAI stack—because choosing the right one matters.

The AWS Machine Learning (ML) Stack

Philosophy: Build custom models trained on your specific data for your unique use case.

When to Use:

You have proprietary data that gives you competitive advantage
Your problem is unique and pre-trained models won't work
You need complete control over model architecture and training
You want to optimize for specific metrics (accuracy, latency, cost)
You're solving prediction, classification, or regression problems
You need explainability and model governance

Core Services:

1. Amazon SageMaker AI (The Foundation)

End-to-end ML platform
Build, train, deploy custom models
Complete control over ML lifecycle
MLOps and governance built-in

2. Ready-to-Use ML Services (Pre-trained Models)

Amazon Rekognition: Computer vision (images, videos)
Amazon Textract: Document intelligence
Amazon Comprehend: Natural language processing
Amazon Transcribe: Speech-to-text
Amazon Polly: Text-to-speech
Amazon Translate: Language translation
Amazon Lex: Conversational AI
Amazon Personalize: Recommendations
Amazon Forecast: Time-series forecasting
Amazon Fraud Detector: Fraud detection

3. Supporting Services

Amazon Augmented AI (A2I): Human review workflows
Amazon Lookout for Equipment: Anomaly detection for industrial equipment
Amazon Monitron: Equipment monitoring
AWS Panorama: Computer vision at the edge
Amazon DevOps Guru: ML-powered operations
Amazon CodeGuru: Code quality and performance

Typical ML Stack Architecture:

Data Sources (S3, Databases, Streams)
         ↓
Data Preparation (SageMaker Data Wrangler, Glue)
         ↓
Feature Engineering (SageMaker Feature Store)
         ↓
Model Training (SageMaker Training, Autopilot)
         ↓
Model Evaluation (SageMaker Clarify, Debugger)
         ↓
Model Registry (SageMaker Model Registry)
         ↓
Deployment (SageMaker Endpoints, Batch Transform)
         ↓
Monitoring (SageMaker Model Monitor)
         ↓
Retraining (SageMaker Pipelines)

Real-World ML Stack Example: Predictive Maintenance

A manufacturing company wants to predict equipment failures before they happen.

Why ML Stack (not GenAI):

Unique sensor data from proprietary equipment
Need precise predictions (false positives are expensive)
Requires model explainability for maintenance teams
Must integrate with existing SCADA systems

Implementation:

Data Collection: IoT sensors → Kinesis → S3
Feature Engineering: SageMaker Feature Store (temperature trends, vibration patterns, usage hours)
Model Training: SageMaker with custom XGBoost model
Deployment: Real-time endpoint for critical equipment, batch for others
Monitoring: Model Monitor tracks prediction drift
Human Review: A2I for borderline predictions
Retraining: Automated pipeline when new failure data arrives

Results:

85% of failures predicted 48 hours in advance
60% reduction in unplanned downtime
$10M annual savings
Model explainability helps maintenance teams understand why

The AWS Generative AI (GenAI) Stack

Philosophy: Use pre-trained foundation models for content generation, reasoning, and understanding.

When to Use:

You need to generate content (text, images, code)
You want conversational AI and natural language understanding
You need to reason over documents and data
You want to build AI agents that take actions
You don't have millions of labeled training examples
Time-to-market is critical

Core Services:

1. Amazon Bedrock (The Foundation)

Access to leading foundation models (Claude, Llama, Titan, etc.)
Knowledge Bases for RAG
Agents for autonomous actions
Guardrails for safety
Fine-tuning for customization

2. Amazon Q (AI Assistant)

AWS expertise and troubleshooting
Code generation and explanation
Business intelligence and analytics
Document search and summarization

3. Amazon Nova Act (UI Automation)

AI agents that interact with UIs
Automate workflows across systems
RPA replacement with intelligence

4. Amazon Bedrock AgentCore (Agent Platform)

Deploy agents at scale
Multi-framework support
Model flexibility

5. Supporting GenAI Services

Amazon Kendra: Intelligent enterprise search (ML-powered, often used with GenAI)
Amazon Lex: Conversational interfaces (can integrate with Bedrock)
Amazon Comprehend: NLP for understanding (complements GenAI)

Typical GenAI Stack Architecture:

User Query
    ↓
Application Layer (Web/Mobile/API)
    ↓
Amazon Bedrock Agent
    ↓
├─→ Knowledge Base (RAG)
│   ├─→ Vector Database (OpenSearch)
│   └─→ Data Sources (S3, SharePoint, Confluence)
│
├─→ Foundation Model (Claude, Llama, Titan)
│
├─→ Guardrails (Safety, PII, Content Filtering)
│
└─→ Action Groups (Lambda Functions, APIs)
    ├─→ Database Queries
    ├─→ External APIs
    └─→ Business Logic

Real-World GenAI Stack Example: Enterprise Knowledge Assistant

A consulting firm with 10K employees wants an AI assistant that can answer questions using their 20 years of project documentation.

Why GenAI Stack (not ML):

Need natural language understanding and generation
Don't have labeled training data
Documents are unstructured (reports, presentations, emails)
Need conversational interface
Want to deploy quickly

Implementation:

Data Ingestion: 500K documents → S3
Knowledge Base: Bedrock Knowledge Base with OpenSearch vector store
Foundation Model: Claude 3 Sonnet for reasoning and generation
Agent Setup: Bedrock Agent with action groups:
- Search project database
- Check employee availability
- Create meeting invites
- Generate project proposals
Guardrails:
- Redact client PII
- Block competitor mentions
- Ensure professional tone
Deployment: Slack bot + web interface
Amazon Q Integration: Help employees with AWS infrastructure questions

Results:

Deployed in 4 weeks (vs. 6 months for custom ML)
80% of internal questions answered without human help
Average response time: 3 seconds
10K queries/day
90% user satisfaction
Consultants save 5 hours/week searching for information
New employees onboard 50% faster

ML Stack vs. GenAI Stack: Decision Matrix

Criteria	ML Stack	GenAI Stack
Use Case	Prediction, classification, regression, anomaly detection	Content generation, reasoning, conversation, summarization
Data Requirements	Large labeled datasets	Documents, unstructured text, minimal training data
Time to Deploy	Weeks to months	Days to weeks
Customization	Complete control	Prompt engineering, fine-tuning, RAG
Explainability	High (feature importance, SHAP)	Moderate (citations, reasoning traces)
Cost	Training costs, inference costs	Token-based pricing
Maintenance	Model retraining, drift monitoring	Prompt updates, knowledge base refresh
Best For	Unique problems, proprietary data	General reasoning, content creation

Hybrid Approach: Combining ML and GenAI

The most powerful solutions often combine both stacks:

Example: Intelligent Customer Service Platform

GenAI Components:

Bedrock Agent for conversational interface
Knowledge Base for product documentation
Claude for natural language understanding

ML Components:

SageMaker model for customer churn prediction
Personalize for product recommendations
Comprehend for sentiment analysis
Forecast for demand prediction

How They Work Together:

Customer asks question → Bedrock Agent (GenAI)
Agent retrieves answer from Knowledge Base (GenAI)
Agent checks customer sentiment → Comprehend (ML)
If negative sentiment → escalate to human
Agent suggests products → Personalize (ML)
Agent predicts churn risk → SageMaker (ML)
If high risk → offer retention discount

Result: Best of both worlds—natural conversation with data-driven insights.

The AWS Advantage: Why This Ecosystem Matters

1. Breadth of Choice

30+ AI/ML services covering every use case
Choose the right tool for the job
Start simple, scale to complex

2. Integration

Services work seamlessly together
Unified IAM, VPC, CloudWatch
Data flows easily between services

3. Infrastructure Abstraction

No server management
Auto-scaling built-in
High availability by default

4. Pay-as-You-Go

No upfront costs
Scale from prototype to production
Only pay for what you use

5. Security & Compliance

Encryption at rest and in transit
HIPAA, PCI-DSS, SOC 2, GDPR compliant
Your data stays in your account
Fine-grained access controls

6. Performance

Global infrastructure
Low-latency inference
Optimized for scale

7. Innovation Velocity

New features released constantly
Access to latest models (Claude 3, Llama 3, etc.)
Backward compatibility maintained

Getting Started: Your 4-Week Journey

Week 1: Explore Ready-to-Use Services

Goal: Get hands-on with pre-trained AI services

Tasks:

Sign up for AWS Free Tier
Try Amazon Rekognition: Upload images, detect objects
Try Amazon Comprehend: Analyze text sentiment
Try Amazon Polly: Generate speech from text
Build a simple demo combining 2-3 services

Time Investment: 5-10 hours
Cost: Free (within Free Tier limits)

Week 2: Experiment with GenAI

Goal: Understand foundation models and Bedrock

Tasks:

Access Amazon Bedrock console
Try different foundation models (Claude, Llama, Titan)
Create a simple Knowledge Base with your documents
Build a basic chatbot using Bedrock Agent
Experiment with Guardrails

Time Investment: 10-15 hours
Cost: ~$10-20 (token usage)

Week 3: Build a Custom ML Model

Goal: Experience the full ML lifecycle

Tasks:

Choose a dataset (Kaggle, UCI ML Repository)
Use SageMaker Autopilot for automated ML
Explore SageMaker Studio notebooks
Train a simple model (classification or regression)
Deploy to a real-time endpoint
Test predictions via API

Time Investment: 15-20 hours
Cost: ~$20-50 (compute and storage)

Week 4: Build a Real Project

Goal: Combine multiple services into a working application

Project Ideas:

Document Intelligence App: Upload PDFs → Textract extracts data → Comprehend analyzes sentiment → Store in database
Content Generation Platform: Bedrock generates blog posts → Polly creates audio version → Translate to multiple languages
Smart Customer Service: Lex chatbot → Bedrock for complex queries → Personalize for recommendations
Predictive Analytics Dashboard: SageMaker model predicts outcomes → Forecast for time-series → QuickSight for visualization

Time Investment: 20-30 hours
Cost: ~$50-100

Common Pitfalls to Avoid

1. Using GenAI When You Need ML

Mistake: Using Bedrock for precise numerical predictions
Solution: Use SageMaker for regression/classification tasks

2. Using ML When You Need GenAI

Mistake: Training a custom NLP model for document Q&A
Solution: Use Bedrock with Knowledge Bases (RAG)

3. Not Considering Costs

Mistake: Running expensive GPU instances 24/7
Solution: Use Spot instances, serverless inference, or batch processing

4. Ignoring Security

Mistake: Exposing API keys, not using VPC endpoints
Solution: Use IAM roles, VPC endpoints, encryption

5. Skipping Monitoring

Mistake: Deploy and forget
Solution: Use Model Monitor, CloudWatch, set up alerts

6. Not Planning for Scale

Mistake: Building for current load only
Solution: Design for 10x growth, use auto-scaling

The Future: What's Coming in AI/ML on AWS

Based on current trends and AWS's innovation velocity:

1. More Powerful Foundation Models

Larger context windows (1M+ tokens)
Multimodal models (text + image + video + audio)
Faster inference times
Lower costs

2. Autonomous Agents

Agents that can use any tool or API
Multi-agent collaboration
Long-running workflows
Better reasoning capabilities

3. Easier Customization

Fine-tuning with less data
Faster training times
Better transfer learning
Automated prompt optimization

4. Enhanced Privacy

On-premises foundation models
Federated learning
Differential privacy
Confidential computing

5. Industry-Specific Solutions

Healthcare AI assistants
Financial services compliance tools
Manufacturing optimization
Retail personalization

The Bottom Line

AWS has democratized AI/ML in a way that seemed impossible a decade ago. You don't need a PhD in machine learning to build intelligent applications anymore. You don't need millions in funding to train models. You don't need a team of infrastructure engineers to deploy at scale.

What you do need:

A clear understanding of your problem
Knowledge of which AWS service fits your use case
Willingness to experiment and iterate
Focus on delivering value, not building infrastructure

The Two Stacks:

Choose the ML Stack when:

You have unique data and unique problems
You need precise predictions
You want complete control
Explainability is critical

Choose the GenAI Stack when:

You need content generation and reasoning
You want natural language interfaces
Time-to-market is critical
You don't have labeled training data

Or combine both for the most powerful solutions.

The AI revolution isn't coming—it's here. And with AWS's comprehensive AI/ML stack, you're equipped to be part of it. The tools are ready. The infrastructure is waiting. The only question is: what will you build?

Resources to Continue Learning

Official AWS Resources:

Certifications:

AWS Certified Machine Learning - Specialty (Retired)
AWS Certified AI Practitioner
AWS Machine learning Associate
AWS Generative AI Developer Professional (Beta)

Community:

AWS re:Post (Q&A forum)
AWS Events (re:Invent, Summits, Webinars)

Free Tier:

AWS Free Tier - Try most AI/ML services free
Many services include generous monthly free usage

Ready to start building? Pick one service from this guide, spend an hour experimenting, and see where it takes you. The best way to learn is by doing.

Have questions or want to share your AWS AI/ML journey? The AWS community is incredibly helpful—don't hesitate to ask for help on re:Post or join local AWS user groups.

Remember: Every expert was once a beginner. Every production system started as an experiment. Your AI/ML journey starts with a single API call.

Now go build something amazing! 🚀

Shaping the Future with Agentic AI — Reflections from the UC Berkeley Agentic AI MOOC (Fall 2025)

Ajaykumar k v — Wed, 17 Dec 2025 17:51:35 +0000

This fall, I had the opportunity to complete the Agentic AI MOOC (Fall 2025) offered by the University of California, Berkeley — a thoughtfully curated 12-lecture series exploring the rapidly evolving frontier of LLM-powered agents.

This course builds directly on the foundations laid in the Fall 2024 LLM Agents MOOC and the Spring 2025 Advanced LLM Agents MOOC, moving decisively from what agents are to how agentic systems are designed, evaluated, deployed, and governed in real-world settings.

Agentic AI is quickly becoming a core paradigm in how intelligent systems are built — enabling autonomous reasoning, multi-step planning, tool use, collaboration, and personalization across domains such as software engineering, robotics, scientific discovery, and web automation.

🎓 Course Overview — Agentic AI MOOC (Fall 2025)

Over the span of the course, we explored Agentic AI from systems, modeling, evaluation, and safety perspectives, guided by experts from OpenAI, NVIDIA, Meta, Google DeepMind, Stanford, Microsoft, and more.

📚 Lecture Series Highlights

LLM Agents Overview — Yann Dubois (OpenAI)
Evolution of System Designs from an AI Engineer Perspective — Yangqing Jia (NVIDIA)
Post-Training Verifiable Agents — Jiantao Jiao (NVIDIA)
Agent Evaluation & Project Overview
Challenges and Lessons from Training Agentic Models — Weizhu Chen (Microsoft)
Multi-Agent AI — Noam Brown (OpenAI)
Predictable Noise in LLMs — Sida Wang (Meta)
AI Agents for Automating Scientific Discovery — James Zou (Stanford)
Practical Lessons from Deploying Real-World AI Agents — Clay Bavor (Sierra)
Multi-Agent Systems in the Era of LLMs — Oriol Vinyals (Google DeepMind)
Autonomous Agents: Embodiment, Interaction, and Learning — Peter Stone (UT Austin / Sony AI)
Agentic AI Safety & Security — Dawn Song (UC Berkeley)

Together, these lectures painted a full-stack view of agentic systems — from theoretical foundations and benchmarks to deployment challenges, embodied agents, and security considerations.

🧠 Key Takeaways from the Fall 2025 MOOC

Agentic AI is not just about better prompts — it’s about architecture, evaluation, and reliability.
Multi-agent systems introduce emergent behaviors that demand new reasoning and coordination strategies.
Evaluation remains one of the hardest problems — benchmarks like SWE-bench, BrowseComp, and τ²-Bench are critical steps forward.
Real-world deployment exposes challenges that don’t show up in lab settings: latency, robustness, safety, and user trust.
Agent safety and security are first-class concerns, not afterthoughts.

⭐ Lecture Spotlight: Practical Lessons from Deploying Real-World AI Agents

Clay Bavor (Co-Founder, Sierra)

One lecture that resonated deeply with me was “Practical Lessons from Deploying Real-World AI Agents” by Clay Bavor, because it moved beyond research demos and focused squarely on what it actually takes to ship reliable agents in production.

A core message of the talk is that LLMs are only the tip of the iceberg. In real-world deployments, the visible components—LLMs, RAG, and tool use—sit above a much larger, more complex foundation that determines whether an agent succeeds or fails. This Agent Iceberg includes observability, guardrails, testing frameworks, policy enforcement, access control, model upgrades, failover strategies, and compliance workflows—capabilities that are often underestimated but absolutely essential in production environments

Clay emphasized a key transition happening right now:
we are moving from “agents as technology” to “agents as product.”
This shift demands a product mindset—designing agents that are simple (but not simplistic), reliable at scale, and capable of building long-term user relationships rather than just resolving one-off tasks. The best agents don’t just complete transactions; they engage over time, remember past interactions, integrate enterprise data, and act proactively instead of reactively

A particularly impactful part of the lecture was the discussion on evaluation and testing, especially through τ-Bench / τ²-Bench. Unlike traditional benchmarks that focus on reasoning or single-turn success, τ-Bench evaluates agents in realistic, multi-turn, policy-constrained environments using:

LLM-based user simulators
Dual-control setups where both user and agent can act via tools
Objective success checks based on final system state

This approach reflects a crucial production truth: when agents handle millions of conversations, reliability matters more than occasional brilliance. Metrics like pass^k are designed to measure consistency under conversational variability, not just best-case performance

Another strong takeaway was around voice agents, where Clay highlighted how deceptively hard production readiness is. Challenges such as transcription quality, background noise, prosody, emotional tone, and pronunciation of real-world entities show that deploying voice-based agents requires deep system-level thinking—not just better models

Overall, this lecture reframed how I think about agentic AI:
the hardest problems are not prompting or reasoning—but reliability, testing, safety, and productization. It was a powerful reminder that we are still in the “1997 era” of building agents, and that the biggest breakthroughs ahead will come from engineering discipline as much as model innovation.

🔗 Explore the Agentic AI MOOC
👉 https://agenticai-learning.org/f25

Grateful to the instructors and the UC Berkeley team for designing a course that doesn’t just follow trends — but helps shape where Agentic AI is headed next.

🎮 From Prompt to Playable: Building Synaptic Weave with Amazon Q CLI

Ajaykumar k v — Wed, 11 Jun 2025 19:18:19 +0000

Can you build an innovative game with no manual coding, no images, and only prompts?

I said yes. Amazon Q CLI delivered.

🚀 The Challenge

As part of the Amazon Q CLI Game Build Challenge, I set out to create something bold:

Fully procedural
Purely prompt-engineered
Code-only visuals (no images or sprites)

The goal? Build a game that feels intelligent, abstract, and alive.

My Prompt:

You are Amazon Q CLI, an AI game-engineer assistant. I want to build an unprecedented, procedural-only, shape-and-text-driven PyGame project called “Synaptic Weave.” In this game, the player traverses a dynamically growing neural-network maze whose corridors and obstacles evolve in real-time based on the player’s own path history.

🧠 Game Concept: What is Synaptic Weave?

Synaptic Weave is a procedurally expanding neural maze game where:

The maze grows based on your movement

Your trails become permanent paths
Hazards (pulses) emerge from firing nodes
Logic puzzles test your path planning skills

Game Terms:

Depth:

Number of unique nodes you've visited

Branching Factor:

Average number of connections per node

Active Pulses:

Number of expanding hazard waves present on the screen

🏃‍♂️ Iteration 1: The Foundation

Amazon Q CLI gave me a complete, working PyGame project:

main.py, graph_maze.py, player.py, hazards.py, ui.py

Procedural maze built using NetworkX

Smooth player movement and fading trails

Initial hazard system and scoring logic

I ran python src/main.py and within seconds, I was navigating a neural web with glowing nodes and path-based evolution. No errors. Fully playable.

🔄 Iteration 2: Making It Understandable & Alive

I asked:

"Make the game more interactive. Explain game mechanics clearly. Add visual polish."

Q CLI responded with:

A tutorial system at the start
H key for help screen
ESC/P to pause
Animated milestone popups, fading trails, and pulsing glow effects
Interactive HUD with tooltips
Background particles and more visual feedback

Now the game felt alive — not just running logic, but immersive play.

🔥 Iteration 3: Cranking Up the Challenge

I told Q:

"Make it more competitive. I want to think, plan, and sweat!"

Q CLI leveled up the experience:

⚔️ Major Enhancements:

Hazards Every 4 Nodes: Fire pulses. Every 8 nodes? Logic gate puzzles.

Pulse Overhaul: Faster, variable-speed hazards that spawn immediately and randomly after 20 nodes.

Progressive Difficulty:

At 25, 50, 100 nodes, pulses get 30% faster

Pulse frequency and hazard rates scale aggressively

Visual Warnings: On hazard creation and difficulty jumps

Strategic Depth:

Risk vs. reward exploration

Trail hardening becomes key to survival

You must plan movement and solve timed hazards

**
I wanted strategy. I got it. Each run now feels like a tactical deep-dive through chaos.**

Some of the code snippets generated by Amazon Q cli (hazards.py)

import random
import math
import time
import pygame

# Constants
PULSE_COLOR = (255, 100, 100, 180)
PULSE_BORDER_COLOR = (255, 50, 50)
PULSE_SPEED = 80  # Pixels per second
PULSE_MAX_RADIUS = 150
FIRING_NODE_COLOR = (255, 100, 100)
LOGIC_GATE_COLOR = (100, 255, 100)
LOGIC_GATE_ACTIVE_COLOR = (200, 255, 200)


class Pulse:
    """Expanding circular pulse hazard."""

    def __init__(self, center, start_time):
        """Initialize a new pulse.

        Args:
            center (tuple): (x, y) center position of the pulse
            start_time (float): Time when the pulse started
        """
        self.center = center
        self.start_time = start_time
        self.radius = 0
        self.active = True
        self.speed = PULSE_SPEED * (0.8 + random.random() * 0.4)  # Randomize speed slightly

    def update(self, current_time):
        """Update the pulse radius based on elapsed time.

        Args:
            current_time (float): Current game time

        Returns:
            bool: True if the pulse is still active, False if it should be removed
        """
        elapsed = current_time - self.start_time
        self.radius = elapsed * self.speed

        # Deactivate if radius exceeds maximum
        if self.radius > PULSE_MAX_RADIUS:
            self.active = False

        return self.active

    def check_collision(self, player_pos, player_radius):
        """Check if the pulse collides with the player.

        Args:
            player_pos (tuple): (x, y) player position
            player_radius (float): Player collision radius

        Returns:
            bool: True if collision detected, False otherwise
        """
        # Calculate distance between pulse center and player
        dx = player_pos[0] - self.center[0]
        dy = player_pos[1] - self.center[1]
        distance = math.sqrt(dx*dx + dy*dy)

        # Check if player is within the pulse ring (with some thickness)
        pulse_thickness = 10
        min_distance = self.radius - pulse_thickness - player_radius
        max_distance = self.radius + pulse_thickness + player_radius

        return min_distance <= distance <= max_distance and self.active

    def draw(self, surface):
        """Draw the pulse on the given surface.

        Args:
            surface: Pygame surface to draw on
        """
        # Create a surface for the semi-transparent pulse
        pulse_surface = pygame.Surface((surface.get_width(), surface.get_height()), pygame.SRCALPHA)

        # Draw the pulse as a semi-transparent circle
        pygame.draw.circle(
            pulse_surface,
            PULSE_COLOR,
            (int(self.center[0]), int(self.center[1])),
            int(self.radius),
            10  # Width of the pulse ring
        )

        # Draw the border of the pulse
        pygame.draw.circle(
            surface,
            PULSE_BORDER_COLOR,
            (int(self.center[0]), int(self.center[1])),
            int(self.radius),
            2  # Width of the border
        )

        # Blit the pulse surface onto the main surface
        surface.blit(pulse_surface, (0, 0))


class FiringNode:
    """Node that periodically emits expanding pulses."""

    def __init__(self, node_id, position, maze):
        """Initialize a firing node.

        Args:
            node_id (int): ID of the node in the maze
            position (tuple): (x, y) position of the node
            maze: Reference to the GraphMaze instance
        """
        self.node_id = node_id
        self.position = position
        self.maze = maze
        self.pulses = []
        self.last_fire_time = time.time()
        self.fire_interval = random.uniform(2.0, 4.0)  # Faster firing rate (was 3.0-6.0)

        # Immediately fire a pulse when created
        self.pulses.append(Pulse(self.position, self.last_fire_time))

    def update(self, current_time):
        """Update the firing node and its pulses.

        Args:
            current_time (float): Current game time
        """
        # Check if it's time to fire a new pulse
        if current_time - self.last_fire_time > self.fire_interval:
            self.pulses.append(Pulse(self.position, current_time))
            self.last_fire_time = current_time
            self.fire_interval = random.uniform(3.0, 6.0)  # Randomize next interval

        # Update existing pulses and remove inactive ones
        self.pulses = [pulse for pulse in self.pulses if pulse.update(current_time)]

    def check_collision(self, player_pos, player_radius):
        """Check if any pulse from this node collides with the player.

        Args:
            player_pos (tuple): (x, y) player position
            player_radius (float): Player collision radius

        Returns:
            bool: True if collision detected, False otherwise
        """
        for pulse in self.pulses:
            if pulse.check_collision(player_pos, player_radius):
                return True
        return False

    def draw(self, surface):
        """Draw the firing node and its pulses.

        Args:
            surface: Pygame surface to draw on
        """
        # Draw each pulse
        for pulse in self.pulses:
            pulse.draw(surface)


class LogicGate:
    """Logic gate puzzle that requires a sequence to solve."""

    def __init__(self, node_id, position):
        """Initialize a logic gate puzzle.

        Args:
            node_id (int): ID of the node in the maze
            position (tuple): (x, y) position of the node
        """
        self.node_id = node_id
        self.position = position
        self.solved = False
        self.active = False
        self.sequence = self._generate_sequence()
        self.player_sequence = []
        self.interaction_radius = 50  # Distance at which player can interact

    def _generate_sequence(self):
        """Generate a random sequence for the puzzle.

        Returns:
            list: List of keys in the sequence
        """
        keys = [pygame.K_1, pygame.K_2, pygame.K_3, pygame.K_4]
        sequence_length = random.randint(3, 5)
        return [random.choice(keys) for _ in range(sequence_length)]

    def check_interaction(self, player_pos):
        """Check if the player is close enough to interact.

        Args:
            player_pos (tuple): (x, y) player position

        Returns:
            bool: True if player can interact, False otherwise
        """
        dx = player_pos[0] - self.position[0]
        dy = player_pos[1] - self.position[1]
        distance = math.sqrt(dx*dx + dy*dy)

        return distance <= self.interaction_radius

    def process_key_input(self, key):
        """Process key input for the puzzle sequence.

        Args:
            key (int): Pygame key constant

        Returns:
            bool: True if the puzzle is solved, False otherwise
        """
        if not self.active or self.solved:
            return False

        # Add key to player sequence
        self.player_sequence.append(key)

        # Check if the sequence matches so far
        sequence_length = len(self.player_sequence)
        if self.player_sequence != self.sequence[:sequence_length]:
            # Reset on mistake
            self.player_sequence = []
            return False

        # Check if complete sequence entered
        if len(self.player_sequence) == len(self.sequence):
            self.solved = True
            return True

        return False

    def draw(self, surface):
        """Draw the logic gate and its state.

        Args:
            surface: Pygame surface to draw on
        """
        # Draw the logic gate node
        color = LOGIC_GATE_ACTIVE_COLOR if self.active else LOGIC_GATE_COLOR
        pygame.draw.circle(
            surface,
            color,
            (int(self.position[0]), int(self.position[1])),
            20  # Slightly larger than regular nodes
        )

        # If active, draw the sequence UI
        if self.active and not self.solved:
            font = pygame.font.SysFont(None, 24)

            # Draw sequence prompt
            prompt = "Enter sequence: " + "".join([str(i+1) for i in range(len(self.sequence))])
            text = font.render(prompt, True, (255, 255, 255))
            surface.blit(text, (self.position[0] - text.get_width() // 2, self.position[1] - 50))

            # Draw player progress
            progress = "".join([str((key - pygame.K_0)) for key in self.player_sequence])
            progress_text = font.render(progress, True, (255, 255, 255))
            surface.blit(progress_text, (self.position[0] - progress_text.get_width() // 2, self.position[1] - 25))

        # If solved, show completion message
        if self.solved:
            font = pygame.font.SysFont(None, 24)
            text = font.render("Gate Unlocked!", True, (255, 255, 255))
            surface.blit(text, (self.position[0] - text.get_width() // 2, self.position[1] - 30))


class HazardManager:
    """Manages all hazards in the game."""

    def __init__(self, maze):
        """Initialize the hazard manager.

        Args:
            maze: Reference to the GraphMaze instance
        """
        self.maze = maze
        self.firing_nodes = {}  # Map of node_id to FiringNode
        self.logic_gates = {}   # Map of node_id to LogicGate
        self.nodes_visited = 0
        self.pulse_frequency = 0.1  # Probability of a new node becoming a firing node
        self.gate_frequency = 0.1   # Probability of a new node becoming a logic gate

    def update(self, dt):
        """Update all hazards.

        Args:
            dt (float): Time elapsed since last update

        Returns:
            bool: True if a new pulse was created
        """
        current_time = time.time()
        pulse_created = False

        # Update firing nodes
        for node in self.firing_nodes.values():
            old_pulse_count = len(node.pulses)
            node.update(current_time)
            if len(node.pulses) > old_pulse_count:
                pulse_created = True

        return pulse_created

    def check_player_collision(self, player):
        """Check if the player collides with any hazard.

        Args:
            player: Player instance

        Returns:
            bool: True if collision detected, False otherwise
        """
        player_pos = player.position
        player_radius = 10  # Player collision radius

        # Check collision with each firing node's pulses
        for node in self.firing_nodes.values():
            if node.check_collision(player_pos, player_radius):
                return True

        return False

    def check_logic_gate_interaction(self, player):
        """Check if the player can interact with a logic gate.

        Args:
            player: Player instance
        """
        # Deactivate all gates first
        for gate in self.logic_gates.values():
            gate.active = False

        # Check if player is near any gate
        for gate in self.logic_gates.values():
            if gate.check_interaction(player.position):
                gate.active = True
                break

    def process_key_input(self, key):
        """Process key input for active logic gates.

        Args:
            key (int): Pygame key constant
        """
        for gate in self.logic_gates.values():
            if gate.active:
                gate.process_key_input(key)

    def add_node(self, node_id, position):
        """Consider adding a hazard at the given node.

        Args:
            node_id (int): ID of the node in the maze
            position (tuple): (x, y) position of the node
        """
        self.nodes_visited += 1

        # Every 8 nodes, add a logic gate
        if self.nodes_visited % 8 == 0:
            self.logic_gates[node_id] = LogicGate(node_id, position)
        # Every 4 nodes, add a firing node (increased frequency)
        elif self.nodes_visited % 4 == 0:
            self.firing_nodes[node_id] = FiringNode(node_id, position, self.maze)

        # After reaching 20 nodes, occasionally add random firing nodes
        elif self.nodes_visited > 20 and random.random() < self.pulse_frequency:
            self.firing_nodes[node_id] = FiringNode(node_id, position, self.maze)

    def increase_difficulty(self, milestone):
        """Increase difficulty parameters based on milestone reached.

        Args:
            milestone (int): Current milestone level
        """
        self.pulse_frequency = 0.15 + milestone * 0.1  # Increased base frequency
        # Increase pulse speed based on milestone
        global PULSE_SPEED
        PULSE_SPEED = 100 + milestone * 30  # Faster pulses

        # Make existing firing nodes fire more frequently
        for node in self.firing_nodes.values():
            node.fire_interval = max(1.0, node.fire_interval * 0.7)  # Reduce interval by 30%

    def get_active_pulses_count(self):
        """Get the total number of active pulses.

        Returns:
            int: Count of active pulses
        """
        count = 0
        for node in self.firing_nodes.values():
            count += len(node.pulses)
        return count

    def draw(self, surface):
        """Draw all hazards.

        Args:
            surface: Pygame surface to draw on
        """
        # Draw firing nodes and their pulses
        for node in self.firing_nodes.values():
            node.draw(surface)

        # Draw logic gates
        for gate in self.logic_gates.values():
            gate.draw(surface)

📊 Tech Stack

Tool

Amazon Q CLI

Prompt-powered code generation

PyGame

Game rendering and interaction engine

NetworkX

Graph generation for maze logic

Python

Core game logic

🧵 Reflections: Building with Prompts

This project flipped traditional dev on its head:

🚀 Rapid ideation to playable game in minutes

🎨 Focus on gameplay, not boilerplate

🤖 AI as a coding co-pilot that explains, iterates, and surprises you

📲 Try It Yourself

Want to build your own game using Amazon Q CLI?

Sign up on community.aws
Follow this link
Explore how far pure prompts can go

🔗 Links

GitHub Repository - Synaptic Weave

Understanding AWS Networking Services: A Comprehensive Guide

Ajaykumar k v — Sun, 15 Dec 2024 18:12:24 +0000

In the vast landscape of cloud computing, Amazon Web Services (AWS) has constructed a robust network infrastructure that serves as the backbone for countless applications and services worldwide. Let's embark on a journey through the key components of AWS networking, exploring how they work together to create a seamless and secure digital environment.

Amazon VPC (Virtual Private Cloud)

Amazon VPC is the cornerstone of AWS networking, providing a logically isolated section of the AWS cloud. It allows you to create a private, secure environment for your resources.

Key Components:

Custom IP ranges (CIDR blocks)
Public and private subnets(part of VPC)
Route tables and network ACLs
Internet and NAT gateways and much more

Real-world Analogy:
VPCs enable you to create multi-tiered web applications with public-facing web servers and private backend systems, all within a secure, isolated network environment.

Multi-tier Application Architecture:
├── Public Subnet (10.0.1.0/24)
    └── Web Servers
├── Private Subnet (10.0.2.0/24)
    └── Application Servers
└── Database Subnet (10.0.3.0/24)
    └── RDS Instances

AWS Transit Gateway

AWS Transit Gateway acts as a cloud router, simplifying network architecture by serving as a hub for VPCs and on-premises networks.

Key benefits:

Centralized management
Reduced operational complexity
Scalable connectivity

Real-world Analogy:
Transit Gateway can significantly reduce the number of connections needed in complex network topologies, simplifying management and reducing costs.

Transit Gateway
├── VPC-1 (Production) - 172.16.0.0/16
├── VPC-2 (Development) - 172.17.0.0/16
├── VPC-3 (Testing) - 172.18.0.0/16
└── On-premises network (via Direct Connect)

AWS PrivateLink

PrivateLink provides private connectivity between VPCs, AWS services, and on-premises applications without exposing traffic to the public internet.

Use cases:

Secure access to SaaS applications
Private connectivity between VPCs
Secure on-premises to cloud connections

Real-world Analogy:
PrivateLink enhances security by keeping your network traffic within the AWS network, reducing exposure to potential threats.

Service Provider VPC (Banking API)
└── PrivateLink Endpoint
    ├── Consumer VPC-1 (Trading System)
    ├── Consumer VPC-2 (Risk Management)
    └── On-premises Data Center

Amazon CloudFront

CloudFront is a fast content delivery network (CDN) that securely delivers data, videos, applications, and APIs globally with low latency.

Key features:

Global edge network
Integration with AWS services
Advanced security features

Real-world Analogy:
CloudFront can significantly improve the performance of your web applications by caching content at edge locations close to your users.

CloudFront Distribution
├── Origin: S3 Bucket (static assets)
├── Origin: ALB (dynamic content)
└── Edge Locations
    ├── North America
    ├── Europe
    └── Asia Pacific

Amazon Route 53

Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service designed to give developers and businesses an extremely reliable and cost-effective way to route end users to Internet applications.

Routing policies:

Simple routing
Weighted routing
Latency-based routing
Geolocation routing
Failover routing

Real-world Analogy:
Route 53's advanced routing policies allow you to optimize your application's availability and performance on a global scale.

example.com
├── Simple Routing (web.example.com → EC2 instance)
├── Weighted Routing (api.example.com → Multiple regions)
└── Latency-based Routing (app.example.com → Nearest region)

AWS Global Accelerator

AWS Global Accelerator is a networking service that improves the availability and performance of applications for local and global users. It provides static IP addresses that act as a fixed entry point to your application endpoints in a single or multiple AWS Regions. Global Accelerator uses the AWS global network to optimize the path from your users to your applications, improving the performance of your TCP and UDP traffic.

Key benefits:

Static IP addresses
Fast regional failover
Improved availability

Real-world Analogy:
Global Accelerator can reduce latency for your global users by routing traffic through the AWS global network infrastructure.

Global Accelerator
├── Static IP: 192.0.2.1
├── Static IP: 192.0.2.2
└── Endpoints
    ├── ALB in us-east-1
    ├── ALB in eu-west-1
    └── EC2 instance in ap-southeast-2

AWS Direct Connect

Think of Direct Connect as a dedicated private highway between your data center and AWS.
Similar to how a private toll road provides faster, more reliable travel compared to public highways.

Real-world Analogy:
A major stock exchange using Direct Connect for ultra-low latency trading operations, ensuring consistent sub-millisecond connectivity.

Financial Institution Setup:
├── On-premises Trading System
    ├── Direct Connect (10 Gbps)
    ├── Primary Connection to us-east-1
    └── Secondary Connection to us-west-2

AWS Site-to-Site VPN

AWS Site-to-Site VPN creates an encrypted tunnel between your network and your Amazon VPCs or AWS Transit Gateway. It's a fully managed service that automatically provides high availability and auto-scaling capabilities. Site-to-Site VPN allows you to securely connect your on-premises network or branch office site to your Amazon VPC, enabling you to extend your on-premises network into the cloud as if it were part of your existing corporate network.Like a secure tunnel between two buildings, allowing safe passage of information.

Real-world Analogy:
A retail chain connecting hundreds of stores to their AWS-hosted inventory management system securely.

Retail Company Infrastructure:
├── Headquarters (On-premises)
├── Multiple Store Locations
    ├── Primary VPN Tunnel
    ├── Backup VPN Tunnel
    └── Encrypted Communications

AWS Client VPN

AWS Client VPN is a managed client-based VPN service that enables you to securely access your AWS resources and resources in your on-premises network. With Client VPN, you can access your resources from any location using an OpenVPN-based VPN client. It's an elastic, highly available service that automatically scales up or down based on demand.

AWS Cloud WAN

AWS Cloud WAN is a managed wide area networking (WAN) service that makes it easy to build, manage, and monitor a unified global network that connects resources running across your cloud and on-premises environments. It provides a central dashboard from which you can connect on-premises branch offices, data centers, and Amazon VPCs across the AWS global network. Cloud WAN automatically creates and manages a global network using Border Gateway Protocol (BGP) and VPN connections, eliminating the need to configure and manage individual connections.

AWS Shield

AWS Shield is a managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS. It provides always-on detection and automatic inline mitigations that minimize application downtime and latency, so there is no need to engage AWS Support to benefit from DDoS protection. There are two tiers of AWS Shield - Standard and Advanced. AWS Shield Standard is automatically included at no extra cost beyond what you already pay for AWS WAF and your other AWS services. For higher levels of protection against attacks targeting your applications running on Amazon EC2, Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator, and Route 53, you can subscribe to AWS Shield Advanced.

Real-world Analogy:
Similar to having a security team that protects a building from various types of attacks.

E-commerce Platform Protection:
├── Layer 3/4 Protection
    ├── Black Friday Traffic Surge
    └── DDoS Mitigation
├── Application Layer Protection
    └── Bot Prevention

AWS WAF

AWS WAF (Web Application Firewall) is a web application firewall that helps protect your web applications or APIs against common web exploits and bots that may affect availability, compromise security, or consume excessive resources. AWS WAF gives you control over how traffic reaches your applications by enabling you to create security rules that control bot traffic and block common attack patterns, such as SQL injection or cross-site scripting. You can also customize rules that filter out specific traffic patterns. You can deploy AWS WAF on Amazon CloudFront as part of your CDN solution, the Application Load Balancer that fronts your web servers or origin servers running on EC2, Amazon API Gateway for your REST APIs, or AWS AppSync for your GraphQL APIs.

Real-world Analogy:
Like a security checkpoint that inspects all visitors before entering a building. A healthcare provider using WAF to ensure HIPAA compliance and protect patient data.

Banking Application Security:
├── SQL Injection Prevention
├── Cross-site Scripting Protection
├── Geo-blocking Rules
└── Rate Limiting

AWS Network Firewall

AWS Network Firewall is a managed service that makes it easy to deploy essential network protections for all of your Amazon Virtual Private Clouds (VPCs). The service can be set up with just a few clicks and scales automatically with your network traffic, so you don't have to worry about deploying and managing any infrastructure. Network Firewall's flexible rules engine lets you define firewall rules that give you fine-grained control over network traffic, such as blocking outbound Server Message Block (SMB) requests to prevent the spread of malicious activity. You can use Suricata-compatible rules to perform deep packet inspection and to alert on or drop packets based on the content of packet payloads.

AWS App Mesh

AWS App Mesh is a service mesh that provides application-level networking to make it easy for your services to communicate with each other across multiple types of compute infrastructure. App Mesh standardizes how your services communicate, giving you end-to-end visibility and ensuring high availability for your applications. With App Mesh, you can easily monitor and control communications across microservices applications running on AWS Fargate, Amazon EC2, Amazon ECS, Amazon EKS, and Kubernetes on EC2.

Real-world Analogy:
Similar to an intelligent traffic control system for microservices.
A streaming service using App Mesh to manage communication between hundreds of microservices handling video delivery.

E-commerce Microservices:
├── Product Service
├── Cart Service
├── Payment Service
└── Shipping Service

Amazon API Gateway

Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. APIs act as the "front door" for applications to access data, business logic, or functionality from your backend services. API Gateway handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, CORS support, authorization and access control, throttling, monitoring, and API version management. API Gateway has no minimum fees or startup costs. You pay only for the API calls you receive and the amount of data transferred out and, with the API Gateway tiered pricing model, you can reduce your cost as your API usage scales.

Real-world Analogy:
Imagine you're building a ride-sharing application. Your app needs to handle various operations like user authentication, ride requests, driver location updates, and payment processing. Here's how API Gateway could be used:

User Authentication: API Gateway integrates with Amazon Cognito to handle user logins.
Ride Requests: When a user requests a ride, the API Gateway routes this request to an AWS Lambda function that finds the nearest available driver.
Location Updates: Drivers' location updates are sent through WebSocket connections managed by API Gateway, allowing real-time tracking.
Payment Processing: After the ride, payment requests are routed through API Gateway to a secure payment processing service.

AWS Cloud Map

AWS Cloud Map is a cloud resource discovery service that enables your applications to easily discover and connect to cloud resources such as databases, message queues, microservices, and other cloud applications with just a few lines of code. With Cloud Map, you can define custom names for your application resources, and it maintains the updated location of these dynamically changing resources. This increases your application availability because your web service always discovers the most up-to-date locations of its resources. Cloud Map natively integrates with other AWS services, including Amazon ECS, Amazon EKS, and AWS Lambda, to automatically register the location and health of containerized services and Lambda functions.

Real-world Analogy:
Like a dynamic business directory that always knows where every service is located.
A food delivery application using Cloud Map to maintain real-time service discovery for its distributed system.

Microservices Discovery:
├── Database Services
    ├── Primary DB (RDS)
    └── Cache (ElastiCache)
├── Application Services
    ├── Auth Service
    └── Payment Service

These services work together to create robust, secure, and scalable network architectures. For instance, a global enterprise might use:

VPC for network isolation
Transit Gateway for connectivity
Direct Connect for reliable access
Shield and WAF for security
App Mesh for service communication
Cloud Map for service discovery

Conclusion

AWS networking services provide a comprehensive suite of tools to build secure, scalable, and highly available applications. By understanding and properly implementing these services, you can create robust network architectures that meet your business needs while maintaining security and performance.
Remember that AWS networking is not just about connecting resources – it's about building a foundation that enables your applications to scale, remain secure, and provide the best possible experience for your users.

DEV Community: Ajaykumar k v

I Broke My Own Serverless App on Purpose, Then Asked AWS DevOps Agent What Happened

Table of contents

1. Why another DevOps Agent post

2. What AWS DevOps Agent actually is

How it differs from things you already have

3. The five nouns you need

4. Pricing you can predict before you switch it on

What this post actually cost, measured

5. The lab

Architecture

The whole trick, in two parameters

6. Onboarding in 20 minutes

The four things that bite

Confirm it's actually alive

7. Wiring alarms to the agent

The two paths, side by side

Path A, and the parts the samples leave to you

8. Breaking production on purpose

9. The evidence chain

10. Asking the agent

The moment it refused

11. The investigation, graded claim by claim

What it said

What checks out

What doesn't

The honest reading of this

12. The second root cause

13. Reading the agent's mind

14. Fixing it

What prevention should produce

15. Closing the loop

16. Making the agent yours

17. What this cost, and how to tear it down

18. Honest scorecard

19. Appendix: copy-paste checklist

Kiro Powers aren’t just about adding tools — they solidify developer workflows and remove the chaos of context overload. What makes them powerful is how they naturally align with the AI-Driven Development Lifecycle (AI-DLC)

Kiro Powers: Give Your AI Agent Superpowers — Not Context Overload

Kiro Powers: Give Your AI Agent Superpowers — Not Context Overload

Table of Contents

1. Introduction: The Context Problem in AI-Assisted Development

2. What Is the AI-Driven Development Lifecycle (AI-DLC)?

3. Enter Kiro Powers: On-Demand Expertise for AI Agents

3.1 The Problem Powers Solve

3.2 How Powers Work Under the Hood

3.3 Anatomy of a Power

3.4 What Makes Powers Different

4. Kiro Powers Across the AI-DLC Phases

5. Four Powers, Four Real-World Use Cases

5.1 Use Case 1 — AWS Draw.io: Designing a Multi-Region Disaster Recovery Architecture

5.2 Use Case 2 — Stripe Payments: Building a SaaS Subscription Platform with Usage-Based Billing

5.3 Use Case 3 — Postman: Contract-First API Development for a Microservices Migration

5.4 Use Case 4 — Amazon Bedrock AgentCore: Building an Internal Knowledge Assistant for Enterprise

6. How Powers Fit Into Your Developer Workflow

7. Building and Sharing Your Own Powers

8. Conclusion: The Future of Agent Capabilities

The AWS AI/ML Landscape in 2026 — Simplified

The Three-Tier Architecture: How AWS Actually Thinks About AI/ML

TIER 1: The Foundation Layer - Build Your Own ML Models

Amazon SageMaker AI: The Complete ML Platform

Core Components & Features:

TIER 2: The GenAI Revolution - Amazon Bedrock

Amazon Bedrock: Your Gateway to Foundation Models

Available Foundation Models:

Core Bedrock Features:

TIER 3: Ready-to-Use AI Services - No ML Expertise Required

Amazon Rekognition: Computer Vision Made Simple

Key Features:

Amazon Textract: Document Intelligence Beyond OCR

Key Features:

Amazon Comprehend: Natural Language Understanding

Key Features:

Amazon Polly: Text-to-Speech That Sounds Human

Key Features:

Amazon Transcribe: Speech-to-Text with Intelligence

Key Features:

Amazon Translate: Neural Machine Translation

Key Features:

Amazon Lex: Build Conversational Interfaces

Key Features: