Generate Production-Ready AWS CDK Infrastructure

This skill turns an assistant into an expert in AWS Cloud Development Kit (CDK), specializing in reusable patterns, L2 and L3 constructs, and production-grade infrastructure stacks. It covers building cloud infrastructure with TypeScript, Python, or Java, and centers on designing reusable CDK stacks and L3 constructs. One worked example is a serverless API pattern that combines a DynamoDB table, a Lambda function, and an API Gateway REST API.

The instructions the assistant follows:

1. Identify the infrastructure pattern needed, such as a serverless API, container service, or data pipeline.
2. Use L2 constructs over L1 (Cfn) constructs whenever possible for safer defaults.
3. Apply the principle of least privilege to all IAM roles and policies.
4. Use RemovalPolicy and Tags appropriately for production readiness.
5. Structure stacks for reusability by separating stateful resources (databases, buckets) from stateless ones (compute, APIs).
6. Enable monitoring by default, with CloudWatch alarms and X-Ray tracing.

Use it when you are building reusable CDK constructs or patterns, designing multi-stack CDK applications, implementing common infrastructure patterns (API plus Lambda plus DynamoDB, ECS services, static sites), or reviewing CDK code for best practices and anti-patterns.

Do not use it when you need raw CloudFormation templates without CDK, when the task is Terraform-specific, or when simple one-off CLI resource creation is enough. Also do not treat the output as a substitute for environment-specific validation, testing, or expert review, and stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing. The skill is marked critical risk in its metadata.

The input is a description of the infrastructure you need. The output is CDK code organized as reusable constructs and stacks. In the worked example, the table uses a string partition key, pay-per-request billing, and a retain removal policy. The Lambda function runs on Node.js 20 with active tracing and receives the table name through an environment variable. The table grants read and write access to the handler, and a Lambda REST API fronts it:

import { Construct } from "constructs";
import * as apigateway from "aws-cdk-lib/aws-apigateway";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as dynamodb from "aws-cdk-lib/aws-dynamodb";

export class ServerlessApiPattern extends Construct {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    const table = new dynamodb.Table(this, "Table", {
      partitionKey: { name: "pk", type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
      removalPolicy: cdk.RemovalPolicy.RETAIN,
    });

    const handler = new lambda.Function(this, "Handler", {
      runtime: lambda.Runtime.NODEJS_20_X,
      handler: "index.handler",
      code: lambda.Code.fromAsset("lambda"),
      environment: { TABLE_NAME: table.tableName },
      tracing: lambda.Tracing.ACTIVE,
    });

    table.grantReadWriteData(handler);
    new apigateway.LambdaRestApi(this, "Api", { handler });
  }
}

The skill works with AWS CDK and the AWS services named in its patterns: API Gateway, Lambda, DynamoDB, ECS, CloudWatch, X-Ray, and IAM. Its best practices are:

• Do use consistent tagging through Tags.of(this).add().
• Do separate stateful and stateless resources into different stacks.
• Do run cdk diff before every deploy.
• Do not use L1 constructs when L2 alternatives exist.
• Do not hardcode account IDs or regions; use cdk.Aws.ACCOUNT_ID instead.

For one common problem, a circular dependency between stacks, the fix is to extract shared resources into a dedicated base stack and pass references through constructor props.

It is for cloud and platform engineers who define AWS infrastructure in code and want consistent, production-ready CDK constructs, as well as reviewers who check CDK pull requests against these best practices.