RFC: aws-dev-toolkit — Comprehensive AWS development toolkit plugin (v0.12.0, 34 skills)

[rsmets]

Updated 2026-04-06: Updated to reflect v0.12.0 — 34 skills (was 30), 33 reference files, renamed bedrock-cost → bedrock, added rds-aurora, agentcore, iot, mlops skills, concrete justifications on all opinionated recommendations. See detailed comparison comment for the full argument.

Is this related to an existing feature request or issue?

Yes, PR #107 already exists with an initial submission of this plugin. This RFC formalizes the proposal per the contributing guidelines so that maintainers can evaluate and discuss the plugin before merge. Also relevant: #56 (Plugin Granularity), #101 (Work With AWS), #110 (Remove migration-to-aws).

Summary

aws-dev-toolkit is a comprehensive AWS development toolkit plugin for Claude Code, packaging 34 skills, 11 specialized agents, and 3 MCP servers into a single plugin that helps developers build, migrate, and review well-architected applications on AWS.

The plugin targets the full AWS development lifecycle: architecture design, infrastructure-as-code scaffolding, service-specific deep-dives, cost optimization, security review, observability, cloud migrations (GCP→AWS, Azure→AWS), and formal Well-Architected Framework reviews — with mandatory security enforcement on every IaC change and progressive discovery (30+ questions across 5 categories).

Use case

Target users: Developers and solutions architects building on AWS who use Claude Code as their AI coding assistant.

Key use cases:

• Designing AWS architectures following Well-Architected Framework best practices
• Scaffolding IaC projects (CDK, Terraform, SAM, CloudFormation)
• Deep-diving into specific AWS services (Lambda, DynamoDB, ECS, EKS, RDS/Aurora, IoT, SageMaker, etc.)
• Reviewing infrastructure code for security issues and best practices
• Estimating and optimizing AWS costs, including Bedrock token economics
• Planning and executing cloud migrations from GCP or Azure to AWS
• Building AI agents with Strands Agents SDK and Bedrock AgentCore
• Running formal Well-Architected reviews against workloads
• End-to-end SA workflows (discovery → design → security review → cost estimate)
• Side-by-side architecture comparison across cost, complexity, performance, and team fit
• Quick account health checks scanning for top security/cost/reliability issues
• MLOps pipelines — SageMaker training/inference/monitoring, MLflow experiment tracking
• IoT architectures — IoT Core, Greengrass v2 edge compute, fleet provisioning, device security

Before: Developers must manually consult AWS documentation, Well-Architected whitepapers, and pricing pages, then translate guidance into code — context-switching between Claude Code and multiple browser tabs.

After: Developers invoke a skill (e.g., /dynamodb, /security-review, /gcp-to-aws) or let an agent (e.g., cost-optimizer, migration-advisor) handle the research and recommendations inline, with MCP servers providing live AWS context from their account.

Proposal

Plugin structure

plugins/aws-dev-toolkit/
├── .claude-plugin/plugin.json   # Plugin manifest (v0.12.0)
├── .mcp.json                    # 3 MCP server configurations
├── skills/                      # 34 skills (each with SKILL.md + references/)
│   ├── Service-specific (19):
│   │   ├── agentcore/           # NEW in v0.12.0
│   │   ├── api-gateway/
│   │   ├── bedrock/             # Renamed from bedrock-cost
│   │   ├── cloudfront/
│   │   ├── dynamodb/
│   │   ├── ec2/
│   │   ├── ecs/
│   │   ├── eks/
│   │   ├── iam/
│   │   ├── iot/                 # NEW in v0.12.0
│   │   ├── lambda/
│   │   ├── messaging/
│   │   ├── mlops/               # NEW in v0.12.0
│   │   ├── networking/
│   │   ├── observability/
│   │   ├── rds-aurora/          # NEW in v0.12.0
│   │   ├── s3/
│   │   ├── security-review/
│   │   └── step-functions/
│   └── Workflow & cross-cutting (15):
│       ├── aws-architect/
│       ├── aws-compare/
│       ├── aws-debug/
│       ├── aws-diagram/
│       ├── aws-health-check/
│       ├── aws-migrate/
│       ├── aws-plan/
│       ├── azure-to-aws/
│       ├── challenger/
│       ├── cost-check/
│       ├── customer-ideation/
│       ├── gcp-to-aws/
│       ├── iac-scaffold/
│       ├── strands-agent/
│       └── well-architected/
├── agents/                      # 11 specialized agents
│   ├── agentcore-sme.md
│   ├── aws-explorer.md
│   ├── bedrock-sme.md
│   ├── container-sme.md
│   ├── cost-optimizer.md
│   ├── iac-reviewer.md
│   ├── migration-advisor.md
│   ├── networking-sme.md
│   ├── observability-sme.md
│   ├── serverless-sme.md
│   └── well-architected-reviewer.md
└── hooks/hooks.json             # Hook definitions

Skills inventory (34 skills)

Service-specific skills (19):

Skill	Description
agentcore	Bedrock AgentCore platform — Runtime, Memory, Gateway, Identity, Policy, multi-agent architectures
api-gateway	Design and configure Amazon API Gateway (REST, HTTP, WebSocket APIs)
bedrock	Bedrock model selection, agents, guardrails, fine-tuning, cost modeling
cloudfront	Design and configure CloudFront distributions, cache behaviors, and edge functions
dynamodb	DynamoDB table design, access patterns, GSI/LSI strategies, single-table design
ec2	EC2 instance selection, auto-scaling, Spot instances, and storage optimization
ecs	ECS workloads — Fargate vs EC2 launch types, task definitions, deployment strategies
eks	EKS clusters — managed node groups, Fargate profiles, IRSA, Karpenter autoscaling
iam	IAM policies, roles, permission boundaries, SCPs, Identity Center, Access Analyzer
iot	IoT Core MQTT/shadows/rules, Greengrass v2, SiteWise, fleet provisioning, device security
lambda	Lambda function design, cold start optimization, concurrency, and deployment
messaging	SQS, SNS, EventBridge — event-driven architectures, fan-out, DLQ patterns
mlops	SageMaker training/inference/pipelines, MLflow, model monitoring, cost optimization
networking	VPC architecture, subnets, security groups, Transit Gateway, Route53
observability	CloudWatch metrics, logs, alarms, dashboards, X-Ray tracing
rds-aurora	Engine selection, Aurora vs RDS, Serverless v2, HA topology, RDS Proxy, blue/green
s3	S3 storage strategies, bucket policies, lifecycle policies, performance optimization
security-review	Review AWS infrastructure code and configurations for security issues
step-functions	Step Functions workflows — saga patterns, parallel tasks, error recovery

Workflow & cross-cutting skills (15):

Skill	Description
aws-architect	Design and review AWS architectures following Well-Architected Framework principles
aws-compare	Side-by-side architecture comparison across cost, complexity, performance, and team fit
aws-debug	Debug AWS infrastructure issues, deployment failures, and runtime errors
aws-diagram	Mermaid + ASCII architecture diagrams from descriptions or reverse-engineered from IaC
aws-health-check	5-minute account scan catching top security/cost/reliability issues
aws-migrate	Orchestrated migration assessment chaining discovery, service mapping, wave planning, and cost estimation
aws-plan	End-to-end discovery → design → security review → cost estimate in one flow
azure-to-aws	Azure to AWS migration guidance with service mappings, gotchas, and assessment
challenger	Adversarial reviewer that stress-tests other agents' outputs for reasoning gaps
cost-check	Analyze and optimize AWS costs, investigate unexpected charges
customer-ideation	Guide customers from idea to AWS architecture with structured discovery
gcp-to-aws	GCP to AWS migration guidance with service mappings, gotchas, and assessment
iac-scaffold	Scaffold new IaC projects using CDK, Terraform, SAM, or CloudFormation
strands-agent	Scaffold AI agents using Strands Agents SDK with Bedrock AgentCore (TS & Python)
well-architected	Formal Well-Architected Framework reviews against the six pillars

Agents inventory (11 agents)

Agent	Description
agentcore-sme	Bedrock AgentCore expert for production-ready AI agents and multi-agent systems
aws-explorer	Read-only AWS environment explorer for understanding deployed resource state
bedrock-sme	Bedrock expert emphasizing cost-efficient model selection and agent workflows
container-sme	Container expert for ECS, EKS, Fargate orchestration and CI/CD
cost-optimizer	Deep cost optimization — rightsizing, Reserved Instances, Savings Plans, data transfer
iac-reviewer	Reviews IaC changes for correctness, security, and best practices before deployment
migration-advisor	Migration planning — workload assessment, wave planning, dependency mapping
networking-sme	VPC design, hybrid connectivity, DNS, CDN, load balancing, and service connectivity
observability-sme	CloudWatch, X-Ray, OpenTelemetry monitoring strategies and dashboards
serverless-sme	Serverless architecture for Lambda, API Gateway, Step Functions, EventBridge, DynamoDB
well-architected-reviewer	Formal WA reviews with evidence-gathering assessment commands

MCP servers (3 servers)

Server	Type	Package / URL	Purpose
awsiac	stdio (uvx)	awslabs.aws-iac-mcp-server	Infrastructure-as-code best practices
awsknowledge	HTTP	https://knowledge-mcp.global.api.aws	AWS architecture decisions and documentation
awspricing	stdio (uvx)	awslabs.aws-pricing-mcp-server	Cost estimation and pricing data

Additional context

• License: MIT
• No runtime dependencies beyond the 3 MCP servers (which are official AWS Labs packages/endpoints)
• All skill and agent definitions are pure Markdown — no executable code in the plugin itself
• The plugin follows Claude Code's plugin conventions: kebab-case naming, YAML frontmatter on all skills/agents, standard plugin.json manifest
• 33 reference files offload detailed code examples, CLI commands, and policy templates from SKILL.md while keeping guidance self-contained
• Every opinionated recommendation includes concrete justification — cost numbers, failure modes, or operational tradeoffs
• Security enforcement: Every IaC change requires a mandatory security review pass via the iac-reviewer agent
• SCP guardrails: The architect skill recommends 6 baseline SCPs (no public SGs on private resources, no unencrypted storage, no public RDS, require IMDSv2, no root access keys, no S3 public access)
• Source repo: https://github.com/rsmets/aws-dev-toolkit (MIT)

[rsmets]

Updated Proposal: The Case for a Unified AWS Plugin

Since filing this RFC, the plugin has grown to v0.6.0 with 30 skills, 11 agents, and 5 MCP servers. I want to make a more substantive argument for why this consolidated approach is superior to the current fragmented plugin model — grounded in data, industry precedent, and Anthropic's own guidance on agent harness design.

---

The Current State: 7 Plugins, Narrow Scope, No Shared Context

The repo currently ships 7 independent plugins. Here's what they actually contain:

Plugin	Skills	References	Agents	MCP Servers	AWS Services Covered
amazon-location-service	1	6	0	1	Location Service only
aws-amplify	1	3	0	1	Amplify Gen 2 only
aws-serverless	4	29	0	1	Lambda, API GW, Step Functions
databases-on-aws	1	23	0	2	Aurora DSQL only (despite the name)
deploy-on-aws	1	3	0	3	Generic deployment
migration-to-aws	1	15	0	2	GCP only (being removed via #110)
sagemaker-ai	11	17	0	1	SageMaker only
Totals	21	~96	0	5 unique	~8 services

Compare with aws-dev-toolkit (single plugin):

Metric	7 Fragmented Plugins	aws-dev-toolkit (1 plugin)
Skills	21	30
Agents	0	11
MCP Servers (unique)	5	5
AWS services with dedicated skills	~8	15 (Lambda, DynamoDB, EC2, ECS, EKS, S3, CloudFront, IAM, API GW, Step Functions, Bedrock, networking, messaging, observability, plus cross-cutting)
Workflow orchestration skills	0	5 (aws-plan, aws-compare, aws-health-check, aws-diagram, aws-migrate)
Security enforcement	None	Mandatory IaC security review
Well-Architected reviews	None	Full 6-pillar WAF skill + agent
Migration coverage	GCP only (being removed)	GCP + Azure
Plugins user must install	1-7	1

5 Concrete Problems with Fragmentation

1. Zero agents across all 7 plugins. Claude Code's agent system (docs) is one of its most powerful features — specialized sub-agents can be spawned for focused tasks while preserving the parent context. None of the current plugins define a single agent. aws-dev-toolkit defines 11 specialized SMEs (container, networking, serverless, cost optimization, etc.) that can be composed into agent teams.

2. MCP server duplication creates conflicts. awsknowledge appears in 3 separate plugins (databases-on-aws, deploy-on-aws, migration-to-aws). awspricing appears in 2. When users install multiple plugins, they get duplicate MCP server configurations. A unified plugin deduplicates this entirely.

3. No cross-cutting concerns. Security review, cost estimation, and Well-Architected alignment aren't features of individual services — they cut across every AWS workload. The fragmented model has no natural home for these. In aws-dev-toolkit, the security-review skill and iac-reviewer agent are mandatory gates on every architecture proposal and IaC change.

4. Coverage gaps are enormous. No plugin covers EC2, ECS, EKS, S3, CloudFront, IAM, VPC/networking, DynamoDB, observability, or messaging (SQS/SNS/EventBridge). These are arguably the most commonly-used AWS services. The databases-on-aws plugin covers only Aurora DSQL despite its broad name — no RDS, no DynamoDB, no ElastiCache, no Neptune.

5. No workflow composition. Real SA engagements chain discovery → design → security review → cost estimate → IaC generation. The fragmented plugins can't orchestrate this. aws-dev-toolkit's aws-plan skill chains the full lifecycle in a single invocation; aws-compare does side-by-side architecture comparison; aws-health-check runs a 5-minute account scan.

Industry Precedent: Consolidated Toolkits Win

Microsoft's Python VSCode extension bundles IntelliSense, debugging, linting, formatting, testing, Jupyter, and environment management into one extension — 211M+ installs. Microsoft explicitly recommends consolidated extensions: "it is often more convenient to have a single extension which combines multiple contributions" (VS Code Extension Manifest).

HashiCorp's Terraform provider split is the cautionary counterexample — they moved FROM monolithic TO distributed providers, but their motivation was independent release cadences and independent contributor communities (blog post). AWS plugins don't have this property — they share the same AWS documentation, the same MCP servers, the same security model, and the same target user (developers building on AWS).

JetBrains' plugin architecture favors consolidated plugins with optional feature degradation via optional dependencies — modular internally, monolithic externally.

The pattern is clear: split when components have genuinely independent lifecycles and contributor bases; consolidate when capabilities are synergistic and share context. AWS services are deeply synergistic.

Anthropic's Own Guidance Supports This

Anthropic's research on harness design for long-running apps demonstrates that integrated multi-agent systems with rich tool access dramatically outperform narrow single-purpose tools:

"The harness was over 20x more expensive, but the difference in output quality was immediately apparent" — the solo agent's output was non-functional while the multi-agent harness produced fully working code.

Their three-agent architecture (Planner → Generator → Evaluator) maps directly to what aws-dev-toolkit provides: aws-architect (planning), service-specific skills (generation), and security-review + well-architected + challenger (evaluation). This is impossible to achieve across isolated plugins.

Anthropic's building effective agents research reinforces: "Tool definitions and specifications should be given just as much prompt engineering attention as your overall prompts." Well-documented, deep tools outperform many shallow ones — but having rich, composable tools in a shared context outperforms both.

Addressing the "Waffle House" Argument (RFC #56)

In #56, @mojodna makes an elegant argument for "station knowledge" — service-specific plugins composed at runtime by the LLM. I respect this framing, but the maintainer's own response highlights the fatal flaw:

"a workflow plugin cannot import or include content from a service plugin at the filesystem level"

This means cross-plugin composition relies entirely on the LLM's non-deterministic ability to find and combine knowledge across plugin boundaries. For security-critical AWS decisions, this is insufficient. aws-dev-toolkit makes the composition explicit and deterministic: the aws-plan workflow skill calls the architect, invokes security review, estimates costs, and generates IaC — all within a single plugin's context.

Additionally, the maintainer acknowledges the duplication problem "is real and will only get worse over time." A unified plugin eliminates this class of problem entirely.

Relationship to Other RFCs

• RFC: Plugin Granularity and Organization for awslabs/agent-plugins #56 (Plugin Granularity) — This proposal is a concrete answer to the granularity question: for AWS development, unified beats fragmented.
• RFC: Work With AWS plugin #101 (Work With AWS) — Shares the same motivation ("None of the existing plugins provide general-purpose access to AWS"). aws-dev-toolkit goes further with 30 skills and 11 agents vs. a general-purpose wrapper.
• chore: remove migration-to-aws plugin #110 (Remove migration-to-aws) — The migration plugin's removal further consolidates the argument: its GCP migration capability already exists (with more depth) in aws-dev-toolkit's gcp-to-aws and azure-to-aws skills.

Updated Numbers (v0.6.0)

30 skills | 11 agents | 5 MCP servers | 12 reference docs
15 service-specific skills | 15 workflow/cross-cutting skills
7 security enforcement rules | 6 SCP baseline guardrails
30+ progressive discovery questions across 5 categories
GCP + Azure migration | Full Well-Architected 6-pillar review

Path Forward

PR #107 contains the full plugin. I'm happy to:

1. Adapt the plugin structure to match any conventions the maintainers prefer
2. Split into sub-directories if there's a technical reason (while keeping it a single installable plugin)
3. Collaborate on which MCP servers to include vs. reference
4. Add any additional skills/agents the community needs

The source repo is MIT-licensed: https://github.com/rsmets/sup-virtual-sa

---

This comment supplements the original RFC with quantitative analysis of the current plugin landscape and evidence-based arguments for the consolidated approach.

[rsmets]

v0.12.0 — 34 Skills, 33 Reference Files

Updated the PR with the current state of the plugin. Here's what it includes.

Service-specific skills (19)

Skill	Coverage
agentcore	Full Bedrock AgentCore platform — Runtime (microVM session isolation), Memory, Gateway, Identity, Policy, Code Interpreter, Browser, Observability, Evaluations, multi-agent architecture patterns
api-gateway	REST, HTTP, WebSocket APIs — authorizers, CORS, throttling, Lambda integration
bedrock	Model selection, agents, guardrails, fine-tuning, cost modeling
cloudfront	Distributions, cache behaviors, edge functions, OAC, WAF integration
dynamodb	Table design, access patterns, GSI/LSI strategies, single-table design
ec2	Instance selection, auto-scaling, Spot instances, Graviton, storage optimization
ecs	Fargate vs EC2, task definitions, deployment strategies, Service Connect
eks	Managed node groups, Fargate profiles, IRSA, Karpenter autoscaling
iam	Policies, roles, permission boundaries, SCPs, Identity Center, Access Analyzer
iot	IoT Core (MQTT/HTTPS/WebSocket, Device Shadow, Rules Engine), Greengrass v2, SiteWise, IoT Events, fleet provisioning, device security (X.509, Device Defender)
lambda	Function design, cold starts, Powertools, concurrency, event sources, SnapStart
messaging	SQS, SNS, EventBridge — event-driven architectures, fan-out, DLQ patterns
mlops	SageMaker training/inference/pipelines, MLflow on AWS, model monitoring, distributed training, Spot/Inferentia/Trainium cost optimization
networking	VPC, subnets, security groups, Transit Gateway, Route53, VPC endpoints
observability	CloudWatch metrics/logs/alarms, dashboards, X-Ray tracing, Container Insights
rds-aurora	Engine selection (RDS vs Aurora vs Serverless v2), HA topology, RDS Proxy, blue/green deployments, migration paths, parameter tuning
s3	Storage strategies, bucket policies, lifecycle policies, performance
security-review	Review infrastructure code and configurations for security issues
step-functions	Workflows — saga patterns, parallel tasks, error recovery, 200+ direct service integrations

33 reference files

Skills are supplemented by references/*.md files that offload detailed CLI commands, code examples, policy templates, and pipeline recipes from SKILL.md. This keeps the main skill focused on guidance while providing deep-dive examples when needed. Examples:

• lambda/references/powertools-patterns.md — Python/TypeScript Powertools code
• iam/references/role-templates.md — 5 persona-based IAM role templates
• mlops/references/pipeline-recipes.md — Full SageMaker Pipeline definitions + CI/CD
• iot/references/security-provisioning.md — Fleet provisioning templates + Device Defender
• step-functions/references/patterns.md — Saga, callback, and Distributed Map ASL examples
• networking/references/vpc-endpoint-catalog.md — VPC endpoint catalog by priority with cost analysis

Quality standards

• Every opinionated recommendation includes a concrete justification — cost numbers, failure modes, operational tradeoffs. No "always use X" without explaining why.
• Related Skills cross-references across 14+ skills for discovery
• Anti-patterns with consequences on every service skill
• Output format tables standardized across skills for consistent recommendation structure

Updated comparison

Metric	7 Fragmented Plugins	aws-dev-toolkit v0.12.0
Skills	21	34
Reference files	~96	33 (supplementing skills, not replacing them)
Agents	0	11
MCP Servers (unique)	5	3 (deduplicated)
AWS services with dedicated skills	~8	19
Workflow orchestration skills	0	5
Security enforcement	None	Mandatory IaC security review

34 skills | 11 agents | 3 MCP servers | 33 reference files
19 service-specific skills | 15 workflow/cross-cutting skills

PR #107 has been updated with the full v0.12.0 content. Source repo: https://github.com/rsmets/aws-dev-toolkit (MIT)