Agent Toolkit for AWS: What Changed When We Installed It

In February we wrote about AI agents in DevOps workflows and argued that the operational patterns matter more than the model: bounded tool surfaces, output review, audit logs of agent actions. AWS shipped something on May 6 that addresses those points directly.

This post is a practical walkthrough of the Agent Toolkit for AWS: what it is, how the pieces fit together, the setup step that determines whether it works at all, and where we think it still falls short.

The problem it solves

If you have used a coding agent to build on AWS, you have seen both failure modes.

The first is stale knowledge. Models are trained on a snapshot, AWS ships hundreds of changes a quarter, and the agent confidently recommends a service configuration that was correct eighteen months ago. The second is trial and error: the agent does not know the right API shape, so it guesses, fails, reads the error, and guesses again. Every iteration costs tokens and wall-clock time.

Both are context problems, not intelligence problems. The Agent Toolkit is AWS’s attempt to fix the context.

The three layers

MCP server. A fully managed remote server that gives agents access to 300+ AWS services and roughly 15,000 API actions, plus real-time documentation search. It also provides sandboxed Python execution for multi-step operations, isolated from your local filesystem and network. Available in US East (N. Virginia) and Europe (Frankfurt).

Agent skills. Over 40 validated procedures across infrastructure as code, storage, analytics, serverless, containers, and AI services. These are not documentation dumps. They are opinionated: service decision tables, step-by-step deployment procedures, troubleshooting guides with root cause analysis. AWS says skills for databases, networking, and IAM are coming.

Plugins. Bundles of the above, scoped to a job. Three at launch: AWS Core for full-stack application development, AWS Data Analytics for pipelines and BI work, and AWS Agents for building on Bedrock AgentCore.

Cost. Free. You pay only for the AWS resources your agent actually provisions.

Installation is a two-minute job. As of the June 5 CLI release, aws configure agent-toolkit runs an interactive wizard that detects installed agents (Kiro, Claude Code, Codex, Cursor) and lets you pick which skills go to each.

The step almost everyone misses

Here is the part worth the price of admission: installing the toolkit does not mean your agent will use it.

The skills ship as on-demand instruction packages. An agent that does not know to look for them will answer from training data exactly as before, with the toolkit sitting there unused. The fix is a small rules file (aws-agent-rules.md in the toolkit repo) that tells the agent to prefer the MCP server for AWS interactions, check for a relevant skill before starting a task, load it via retrieve_skill, and verify against live documentation rather than recall when uncertain.

Seventeen lines. Without it, you get a slightly better search tool. With it, you get an agent that pulls up an architecture decision table before writing anything.

The behavioral difference is easy to see. Ask an unequipped agent to build an API and it produces a reasonable-looking API. Ask an equipped one and it comes back with a specific variant recommendation and the constraints attached: HTTP API rather than REST API for this shape of workload, 30-second hard timeout, 10 MB payload ceiling. That second answer is the one you want before the code gets written, not after.

This generalizes past the Agent Toolkit. Tool availability and tool usage are different problems, and the second one is solved with instructions, not integrations.

The governance story

This is the part that separates the Agent Toolkit from the awslabs MCP servers that preceded it, and it is why we expect this to clear internal review at clients where the earlier ones did not.

IAM condition keys that distinguish agent actions from human actions. You can write a policy that permits an operation when a person performs it and denies it when an agent does. That is the control most security teams have been asking for and could not previously express.

CloudTrail and CloudWatch coverage. Every agent API call is logged and attributable. When something goes wrong, you can reconstruct what happened.

Sandboxed execution. Multi-step Python runs in an isolated environment rather than against your workstation.

Read together, this is roughly the control set we described in February as a precondition for putting agents anywhere near production. It is now available without building it yourself.

Where it falls short

Honest limits, in the order they will bite you:

• Two regions. US East (N. Virginia) and Europe (Frankfurt) only. If your data residency requirements exclude both, you are waiting.
• Skill depth is uneven. The serverless and IaC skills are genuinely good. Others read like a first pass. Expect the quality to vary by service and to improve over the next few quarters.
• It does not make the output correct. The toolkit narrows the search space and grounds the agent in current documentation. It does not review the CloudFormation your agent wrote. Everything we said in February about human review gates still applies, unchanged.
• Knowing the best practice is not the same as knowing your environment. Skills encode AWS’s general guidance. They do not know your account structure, your tagging standard, or the reason you made an unusual choice three years ago. That context is still yours to supply.

What to do now

Install it on one project. Add the rules file, or the whole exercise is theater. Pick a task where you already know what good looks like, run it with and without, and see whether the difference is real for your workload.

If you are further along and running agents against client or production accounts, the IAM condition keys are worth a session on their own. Being able to write “agents may not do this” as an actual policy rather than a convention is a meaningful upgrade to how these systems get governed.

Closing

The Agent Toolkit is not a new capability so much as the removal of a lot of tedious setup that competent teams were doing by hand. That is the useful kind of AWS launch: less novel, more load-bearing.

If you are working out how coding agents fit into your AWS practice, or how to govern them once they are there, we’re glad to talk it through.