AWS Cloud Development Kit (CDK) expert for building cloud infrastructure with TypeScript/Python. Use when creating CDK stacks, defining CDK constructs, implementing infrastructure as code, or when the user mentions CDK, CloudFormation, IaC, cdk synth, cdk deploy, or wants to define AWS...
AWS Cloud Development Kit (CDK) expert for building cloud infrastructure with TypeScript/Python. Use when creating CDK stacks, defining CDK constructs, implementing infrastructure as code, or when the user mentions CDK, CloudFormation, IaC, cdk synth, cdk deploy, or wants to define AWS...
This skill provides comprehensive guidance for developing AWS infrastructure using the Cloud Development Kit (CDK), with integrated MCP servers for accessing latest AWS knowledge and CDK utilities.
AWS Documentation Requirement
Always verify AWS facts using MCP tools (mcp__aws-mcp__* or mcp__*awsdocs*__*) before answering. The aws-mcp-setup dependency is auto-loaded — if MCP tools are unavailable, guide the user through that skill's setup flow.
CDK-Specific MCP Guidance
AWS Labs replaced the dedicated CDK MCP server (awslabs.cdk-mcp-server) with the broader awslabs.aws-iac-mcp-server, which covers CDK alongside CloudFormation and other AWS infrastructure-as-code workflows.
For CDK construct lookups, best-practice recommendations, and pattern guidance, install awslabs.aws-iac-mcp-server. It ships in the deploy-on-aws plugin from awslabs/agent-plugins, or can be registered directly with claude mcp add aws-iac uvx awslabs.aws-iac-mcp-server@latest.
When to reach for it:
CDK construct recommendations and API lookups
CDK and CloudFormation best-practice patterns
Validation of synthesized templates
Cross-resource configuration guidance
When to Use This Skill
Use this skill when:
Creating new CDK stacks or constructs
Refactoring existing CDK infrastructure
Implementing Lambda functions within CDK
Following AWS CDK best practices
Validating CDK stack configurations before deployment
Verifying AWS service capabilities and regional availability
Core CDK Principles
Resource Naming
CRITICAL: Do NOT explicitly specify resource names when they are optional in CDK constructs.
Why: CDK-generated names enable:
Reusable patterns: Deploy the same construct/pattern multiple times without conflicts
Parallel deployments: Multiple stacks can deploy simultaneously in the same region
Cleaner shared logic: Patterns and shared code can be initialized multiple times without name collision
Stack isolation: Each stack gets uniquely identified resources automatically
Pattern: Let CDK generate unique names automatically using CloudFormation's naming mechanism.
// ❌ BAD - Explicit naming prevents reusability and parallel deploymentsnew lambda.Function(this, 'MyFunction', {
functionName: 'my-lambda', // Avoid this// ...
});
// ✅ GOOD - Let CDK generate unique namesnew lambda.Function(this, 'MyFunction', {
// No functionName specified - CDK generates: StackName-MyFunctionXXXXXX// ...
});
Security Note: For different environments (dev, staging, prod), follow AWS Security Pillar best practices by using separate AWS accounts rather than relying on resource naming within a single account. Account-level isolation provides stronger security boundaries.
Lambda Function Development
Use the appropriate Lambda construct based on runtime:
TypeScript/JavaScript: Use @aws-cdk/aws-lambda-nodejs
AWS Documentation MCP: Integrated for latest AWS information
CDK MCP Server: Integrated for CDK-specific guidance
GitHub Actions Integration
When GitHub Actions workflow files exist in the repository, ensure all checks defined in .github/workflows/ pass before committing. This prevents CI/CD failures and maintains code quality standards.
Limitations
Use this skill only when the task clearly matches its upstream source and local project context.
Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
