Overview
Agent Toolkit for AWS (github.com/aws/agent-toolkit-for-aws) is an open-source TypeScript package under Apache 2.0. Its premise is counterintuitive: while most cloud vendors are shipping their own AI agents (Google's Gemini CLI, Microsoft Copilot, Alibaba's Tongyi Lingma), AWS builds plugins for everyone else's agents.
The toolkit is not "AWS's Claude Code." It is a plugin package that lets Claude Code, Codex, Cursor, Devin, and Kiro safely operate AWS.
Why plugins instead of an agent?
The apparent logic of cloud lock-in says vendors should own the agent. But agents have short lifecycles—whoever leads today may lose tomorrow. Making a plugin bets on a different outcome: whichever agent wins still needs to operate AWS. As the author puts it, that is the safe bet.
Five layered plugins
1. aws-core — service selection, CDK/CloudFormation, serverless, containers, storage, observability, billing, SDK usage, deployment 2. aws-agents — building AI agents on AWS (Bedrock + AgentCore) 3. aws-data-analytics — data lakes, analytics, ETL (S3 Tables, Glue, Athena) 4. aws-agents-for-devsecops — security investigation, code review, UAT, vulnerability scanning, penetration testing 5. aws-startup-advisor — startup architecture, cost, security, AWS Activate guidance, plus migration from Azure/GCP/Heroku/OpenAI/Gemini to AWS
The layering logic: plugins are organized by user scenario, not by AWS service. Traditional docs answer "how do I use S3"; the plugin answers "I want to deploy a serverless API" and helps the agent pick services.
Guardrails, not freedom
The README repeatedly emphasizes guardrails: boundaries rather than open-ended freedom, aligned with enterprise needs. Concretely:
- Restricting which services agents can operate on
- Restricting operation levels (read-only vs. write)
- Providing best-practice knowledge so agents don't have to guess
- Cloud vendors are shifting from "building agents" to "being the knowledge source for agents." The competition is over supply-side share (plugin installs), not agent capability.
- Developers gain a new skill: auditing plugin neutrality. Is your agent's recommendation the true optimum, or whatever a vendor's plugin says?
- Agent Toolkit for AWS—11 stars, 5 plugins—is an early sample defining how cloud vendors play in the agent era.
This complements agent-configuration-layer security approaches (e.g., ECC AgentShield): the toolkit provides secure configurations at the source.
Migration guidance as a customer-acquisition channel
The aws-startup-advisor plugin includes migration guidance—not just "how to use AWS" but "how to move your Azure/GCP/Heroku/OpenAI/Gemini stack to AWS." This reveals the toolkit's real positioning: it is an acquisition channel, steering agent-assisted decisions toward AWS.
Plugins as distribution channels
Traditional distribution: docs, SDKs, consoles. Agent-era distribution: plugins. The decision-maker shifts—agents read plugins and choose services while developers become approvers. The README itself reads like instructions for agents: "install this plugin, then you can do X, Y, Z"—a capability list, not a human tutorial.
What 11 stars means
The project has only 11 GitHub stars (vs. peers like impeccable at 733). But stars are the wrong metric: the value lies in how many agents have it installed. aws-core is a default recommendation in Claude Code's official marketplace. Marketplace install counts, not GitHub stars, measure agent-era traction.
The deeper question: plugin neutrality
When cloud vendors shape agent decisions through plugins, who audits their neutrality? If AWS ships a "migrate from Azure to AWS" plugin, will Azure ship the reverse? If both are installed, whose does the agent follow? The situation resembles the SEO wars of the search era—except search algorithms are black boxes while agent decisions are at least theoretically auditable, if plugin provenance remains visible. If plugin knowledge is internalized into agent context, users may not see that a recommendation came from AWS's plugin.