AWS Serverless Deployment

AWS Serverless Deployment

Deploy serverless applications to AWS using SAM or CDK. This skill covers project scaffolding, IaC templates, CDK constructs and patterns, deployment workflows, CI/CD pipelines, and SAM/CDK coexistence.

For Lambda runtime behavior, event sources, orchestration, observability, and optimization, see the aws-lambda skill.

When to Load Reference Files

Load the appropriate reference file based on what the user is working on:

• SAM project setup, templates, deployment workflow, local testing, or container images -> see references/sam-project-setup.md
• CDK project setup, constructs, CDK testing, or CDK pipelines -> see references/cdk-project-setup.md
• CDK Lambda constructs, NodejsFunction, PythonFunction, or CDK Function -> see references/cdk-lambda-constructs.md
• CDK serverless patterns, API Gateway CDK, Function URL CDK, EventBridge CDK, DynamoDB CDK, or SQS CDK -> see references/cdk-serverless-patterns.md
• SAM and CDK coexistence, migrating from SAM to CDK, or using sam build with CDK -> see references/sam-cdk-coexistence.md

Best Practices

SAM

• Do: Use sam_init with an appropriate template for your use case
• Do: Set global defaults for timeout, memory, runtime, and tracing in the Globals section
• Do: Use samconfig.toml environment-specific sections for multi-environment deployments
• Do: Use sam build --use-container when native dependencies are involved
• Don't: Copy-paste templates from the internet without understanding the resource configuration
• Don't: Hardcode resource ARNs or account IDs in templates — use !Ref, !GetAtt, and !Sub

CDK

• Do: Use TypeScript — type checking catches errors at synthesis time, before any AWS API calls
• Do: Prefer L2 constructs and grant* methods over L1 and raw IAM statements
• Do: Separate stateful and stateless resources into different stacks; enable termination protection on stateful stacks
• Do: Commit cdk.context.json to version control — it caches VPC/AZ lookups for deterministic synthesis
• Do: Write unit tests with aws-cdk-lib/assertions; assert logical IDs of stateful resources to detect accidental replacements
• Do: Use cdk diff in CI before every deployment to review changes
• Don't: Hardcode account IDs or region strings — use this.account and this.region
• Don't: Use cdk deploy directly in production without a pipeline
• Don't: Skip cdk bootstrap — deployments will fail without the CDK toolkit stack

Configuration