Agent Plugins for AWS Bring Structured Serverless, Deployment, and SageMaker Skills to Claude Code
Agent Plugins for AWS add serverless, deployment, and SageMaker skills to Claude Code; this guide covers local setup with kiro-gateway and practical troubleshooting.
What Agent Plugins for AWS Are and Why They Matter
AWS released Agent Plugins for AWS, a packaged set of structured skill packs that connect directly into Claude Code to guide complex cloud tasks. The release bundles multiple artifact types — skills, MCP servers, hooks, and references — designed to let the model run multi-step workflows for serverless apps, deployment, cost estimation, and SageMaker operations. For teams and developers who prototype with local tools or prefer a hands-on environment, the plugins offer a way to have a model-driven assistant generate, validate, and even deploy infrastructure code with live data backing certain decisions.
This article explains how the plugins work with Claude Code when routed through a local kiro-gateway instance, step-by-step setup details used in testing, sample interactions (including a live cost estimate), the runtime behaviors you’ll see, and two concrete troubleshooting items encountered during experimentation.
How the Plugins Are Packaged
Agent Plugins for AWS deliver four distinct artifact classes:
- Skills: structured workflows that guide Claude Code through multi-step tasks (this is the core of the package).
- MCP servers: connectors that provide live data such as pricing, documentation, and IaC validators.
- Hooks: automatic actions that run on developer activity (for example, validating a SAM template after edits).
- References: documentation and configuration defaults the skills consult during execution.
Installed inside Claude Code, these pieces let the assistant not only reason about architecture but also call live services (via MCP servers) for data like current pricing or IaC validation.
Local routing with kiro-gateway: why and how
The test setup routed Claude Code through a local kiro-gateway so the author could exercise the plugins without changing an Anthropic API subscription. Claude Code accepts an ANTHROPIC_BASE_URL environment variable; pointing that to a local kiro-gateway instance causes Claude Code to send standard Anthropic API requests to the gateway, which translates them into calls under a Kiro Pro subscription. The result is a local development workflow where the gateway handles proxying and authentication for the user’s existing Kiro account.
The approach enabled the tester to run the Agent Plugins in a personal environment with no additional paid access beyond an existing Kiro Pro subscription.
Install steps used in testing
The test used a specific Claude Code requirement and a sequence of local commands to set up the gateway and point Claude Code at it. The key, explicitly supported steps:
- Install Claude Code (requires version 2.1.29 or later): npm install -g @anthropic-ai/claude-code.
- Clone and prepare the kiro-gateway repository, create a Python virtual environment, and install its requirements. The repository used was jwadow/kiro-gateway.
- Create a .env file for kiro-gateway that includes a local proxy API key, the path to the kiro-cli auth DB, and the gateway host and port. On macOS that database path is under ~/Library/Application Support/kiro-cli/data.sqlite3.
- Start the kiro-gateway process on the configured port.
- Create ~/.claude/settings.json to set ANTHROPIC_BASE_URL to the gateway address and supply the gateway proxy key via ANTHROPIC_API_KEY; set ANTHROPIC_MODEL to the configured Claude model. On first run Claude Code will prompt to accept the API key; select Yes so it uses the gateway proxy key locally.
- Run claude to start the Claude Code client and confirm the gateway proxying is active.
These steps reflect the exact configuration approach used during the test and are the practical minimal path to let Claude Code try the Agent Plugins through a local proxy.
Installing the Agent Plugins inside Claude Code
Inside Claude Code the Agent Plugins were installed via the plugin marketplace and then individual plugin installs. In the test the author added the upstream package and installed specific plugins with commands inside Claude Code, such as:
/plugin marketplace add awslabs/agent-plugins
/plugin install deploy-on-aws@agent-plugins-for-aws
/plugin install aws-serverless@agent-plugins-for-aws
After installation, the author restarted Claude Code. The marketplace contained seven available plugins in the tested environment: deploy-on-aws, aws-serverless, aws-amplify, databases-on-aws, amazon-location-service, migration-to-aws, and sagemaker-ai.
What each plugin provides (exact behaviors observed)
The aws-serverless plugin supplies three skills focused on serverless application development and orchestration:
- aws-lambda: covers Lambda functions, event sources, API Gateway, EventBridge, and Step Functions.
- aws-serverless-deployment: contains workflows for SAM and CDK deployment.
- aws-lambda-durable-functions: focuses on workflow orchestration patterns such as sagas and human-in-the-loop steps.
The deploy-on-aws plugin provides a single deploy skill that follows a five-step workflow: Analyze, Recommend, Estimate, Generate, Deploy. That skill is backed by three MCP servers:
- awsknowledge: used for architecture decision support.
- awspricing: used to fetch live cost data.
- aws-iac-mcp: used for CDK and CloudFormation validation.
Generate produces either CDK or CloudFormation code and applies security defaults at generation time. Deploy performs an IaC security scan and requests user confirmation before executing any changes.
The sagemaker-ai plugin (the newest in the tested package) includes twelve skills covering model customization workflows such as use-case definition, dataset evaluation, fine-tuning, model evaluation, and deployment to Amazon SageMaker AI. It also includes skills for managing SageMaker HyperPod clusters, remote diagnostics via AWS Systems Manager, and generating issue reports. The sagemaker-ai plugin is installed from inside Claude Code using the plugin install command.
A live example: cost estimation for a serverless TODO API
One of the clearest demonstrations in the test was the cost estimation capability. The author fed Claude Code a prompt to deploy a serverless TODO API with DynamoDB and to estimate monthly costs at 10,000 requests/day. The deploy-on-aws skill executed Analyze and Estimate steps and called get_pricing against the AWS Price List API for Lambda, API Gateway, and DynamoDB. The plugin used live pricing values at query time to populate the estimate.
The resulting breakdown for 10,000 requests/day (approximately 300,000 requests/month) was presented as:
- Lambda requests: 300K (free tier: 1M) — $0.00
- Lambda duration: 7,680 GB-sec (free tier: 400K) — $0.00
- API Gateway (HTTP): 300K @ $1.00/million — $0.30
- DynamoDB reads: 180K RRUs @ $0.125/million — $0.02
- DynamoDB writes: 120K WRUs @ $0.625/million — $0.08
- DynamoDB storage: ~1 MB — $0.00
Total: approximately $0.40 per month.
This cost table was generated by the skill calling the live AWS pricing APIs during the Estimate step.
Full plugin-driven deployment flows observed
Beyond estimates, the plugins can drive end-to-end code generation and deployment. After Estimate, the Generate step writes CDK or CloudFormation code with security defaults applied. The plugin then runs an IaC security scan and prompts for confirmation before proceeding to Deploy.
For SAM-based deployments, Claude Code calls the aws-serverless plugin’s deployment skill which invokes sam_init to scaffold, sam_build to compile, and sam_deploy to push to the target region. The plugin guides each of those steps and surfaces validation or errors from the underlying tools. Both CDK and SAM paths rely on the plugin suite end-to-end; the difference is which named skill orchestrates the process.
Troubleshooting observed during testing
The kiro-gateway approach enabled testing but surfaced two specific issues the author experienced while running the Agent Plugins locally. Both are implementation or environment constraints rather than behavior of the AWS plugins themselves.
-
Long tool names trigger a 400 error: MCP servers produced very verbose tool names (for example, names like mcpGitHubcheck_if_a_repository_is_starred_by_the_authenticated_user reached 71 characters). The Kiro API enforces a hard 64-character tool-name limit. The original kiro-gateway code rejected names over that limit, causing the MCP servers to fail with an “Improperly formed request” 400 response. The author patched kiro-gateway locally to shorten names when sending to Kiro and restore the original names in responses so that Claude Code and MCP servers still see full names while Kiro’s limit is satisfied. That patch was built locally with Claude Code’s help and had not been submitted upstream at the time of testing. If you encounter the same error, the remedy described is to apply a similar transparent renaming patch in your local gateway until an upstream fix is available.
- aws-iac-mcp build failure on Apple Silicon: The aws-iac-mcp server depends on guardpycfn, a Rust-based Python package. On Apple Silicon the build attempted to cross-compile for x86_64 but the x86_64-apple-darwin Rust target was not installed. The explicit fix used in testing was to add the missing Rust target with rustup target add x86_64-apple-darwin and then restart Claude Code. After that step, the aws-iac-mcp server started successfully in the tester’s environment.
The test notes that kiro-gateway is an actively developed open-source project and has some rough edges; routing through it produced slightly slower responses than direct Anthropic API calls because of the extra local hop, but the latency was acceptable for experimentation.
Operational notes and verification steps
After applying the fixes, the usage flow used in testing was:
- Start the gateway process on the chosen port.
- Run claude and allow it to accept the gateway API key on first run.
- Check gateway health with a simple curl http://127.0.0.1:9000/health to confirm the gateway is reachable.
Cost for using this local pattern was reported as $0 extra beyond an existing Kiro Pro subscription; the gateway simply translated Claude Code’s Anthropic-style requests into Kiro-managed API calls.
Industry and developer implications
Agent Plugins for AWS demonstrate how structured model-driven workflows can be combined with live connectors (MCP servers) to reduce the friction between design intent and deployable infrastructure. For developers and platform engineers, the most concrete implications are:
- Faster prototyping: skills that scaffold projects (sam_init, CDK generation) and run validation checks can shorten the loop from idea to runnable code. The deploy and serverless skills convert high-level prompts into actionable IaC artifacts with security defaults applied.
- Data-driven decisions: by wiring in live pricing and documentation via MCP servers, a model can make recommendations grounded in current service data (for example, cost estimates), which is useful for planning and cost optimization discussions.
- Tooling surface area: the plugin approach surfaces new operational concerns — such as tool-name length limits, local build dependencies, and cross-compilation issues — that teams must handle when bridging model tooling and real-world developer infrastructure. The observed Apple Silicon build issue and required rustup step highlight how modern development environments can introduce platform-specific build friction.
- Continuous feedback: hooks that run validations on file save (sam validate after template edits) push IaC validation earlier into the developer workflow, aligning with existing IaC security and developer tooling trends.
For businesses, the ability to generate code with security defaults and estimate costs using live pricing could streamline proofs of concept and reduce time-to-initial-deployment. It also raises operational questions: how teams manage model-initiated deployments, approvals, and audit trails when an assistant can generate and push changes (the deploy skill requests confirmation before executing, per the tested behavior).
Who can make use of this setup and when it fits
The approach documented in testing fits developers and platform engineers who want a local, experimental environment to try Claude Code-driven workflows with AWS-oriented skills, especially when they already have a Kiro Pro subscription and want to route traffic through a local proxy. It’s suitable for proof-of-concept work, learning workflows, and small-scale experimentation.
It is not presented as a production turnkey path in the tested write-up: kiro-gateway is open-source and under active development, and the author encountered issues that required local fixes. If you expect production-level reliability or enterprise-grade deployment automation, treat this pattern as an integration prototype that surfaces integration points to harden before relying on it in production.
Security and validation behaviors noted
The plugins incorporate validation steps: generated IaC is produced with security defaults, and Deploy runs an IaC security scan prior to asking for human confirmation. The aws-serverless plugin also ships a non-configurable hook that runs sam validate automatically after edits to template.yaml, surfacing errors immediately on save. Those behaviors integrate validation early in the workflow and help prevent common IaC mistakes before deploying.
Practical reader questions addressed (what it does, how it works, who can use it, when it’s available)
- What does it do? Agent Plugins for AWS provide Claude Code with structured skills and live MCP servers to build, estimate, validate, and deploy serverless and machine learning workloads on AWS.
- How does it work? Skills drive multi-step workflows inside Claude Code; MCP servers supply live data (like pricing), hooks run automated validations on developer actions, and the suite can generate IaC (CDK or CloudFormation) and perform deployments after user confirmation.
- Who can use it? The tested setup targeted developers who can run Claude Code locally, have an existing Kiro Pro subscription, and are comfortable running a local gateway and applying minor fixes if needed.
- When is it available? The article describes the package as released by AWS and available in the Claude Code plugin marketplace in the tested environment; the sagemaker-ai plugin is included among the available installs and contains a dozen-plus skills for SageMaker workflows.
All of the above points are drawn from the test run and the configuration and behavior the author documented.
Limitations and cautionary points
- The kiro-gateway route adds an extra network hop; responses observed were somewhat slower than direct API calls.
- Local environment constraints matter: long tool names triggered a 400 error against the Kiro backend until patched locally; guardpycfn’s Rust build required adding a cross-compilation target on Apple Silicon.
- The author’s renaming patch for tool names had not been submitted upstream at the time of testing, so users relying on a vanilla kiro-gateway may hit the same 64-character limit unless an upstream fix is published.
Usage checklist for someone replicating the test
- Ensure Claude Code is at least v2.1.29.
- Clone the jwadow/kiro-gateway repository and install Python dependencies in a virtual environment.
- Create a .env for the gateway containing PROXY_API_KEY, KIRO_CLI_DB_FILE pointing at your kiro-cli DB, SERVER_HOST, and SERVER_PORT.
- Start the gateway process on the chosen port and verify health via /health.
- Point Claude Code to the gateway via ~/.claude/settings.json setting ANTHROPIC_BASE_URL and ANTHROPIC_API_KEY, and accept the key on first run.
- Inside Claude Code, add the awslabs/agent-plugins marketplace package and install the plugins you need (for the test, deploy-on-aws, aws-serverless, and sagemaker-ai were installed).
- If you encounter a 400 Improperly formed request due to long tool names, consider applying a name-shortening patch to kiro-gateway as described in the test notes.
- On Apple Silicon, if aws-iac-mcp fails with a missing x86_64-apple-darwin target, run rustup target add x86_64-apple-darwin, then restart Claude Code and the gateway.
Credits and cost
The local test used an existing Kiro Pro subscription to route requests and reported no additional cost for the gateway wiring itself. The example cost estimate generated by a plugin for a simple serverless TODO API at 10,000 requests/day calculated to about $0.40/month using live AWS pricing at query time.
Looking ahead, structured skill packs like Agent Plugins for AWS combined with model-driven deployment workflows and live connectors show a clear trajectory toward tighter developer workflows that blend natural-language intent, automated IaC generation, and real-time validation; teams evaluating these tools should plan for integration work (proxying, build targets, validation gates) and consider how to incorporate human approval steps and audit controls into any deployment pipeline that a model can initiate.
