Generate Production-Ready AWS CDK Infrastructure

This is an AWS Cloud Development Kit (CDK) skill for reusable patterns, L2/L3 constructs, and production-grade infrastructure stacks, favoring L2 constructs over raw L1 (Cfn*) constructs for safer defaults, least-privilege IAM, appropriate RemovalPolicy and Tags usage, stacks separated into stateful (databases, buckets) and stateless (compute, APIs) resources, and monitoring enabled by default (CloudWatch alarms, X-Ray tracing). Its serverless-API example wires a DynamoDB table, a traced Lambda handler, and an API Gateway REST API together as one reusable construct:

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 });
  }
}

Use this skill when building reusable CDK constructs or patterns, designing multi-stack CDK applications, implementing common infrastructure patterns (an API plus Lambda plus DynamoDB, ECS services, static sites), or reviewing CDK code for best practices and anti-patterns. Don't use it if the user needs raw CloudFormation templates without CDK, if the task is Terraform-specific, or if simple one-off CLI resource creation is sufficient. Named best practices: use cdk.Tags.of(this).add() for consistent tagging, separate stateful and stateless resources into different stacks, run cdk diff before every deploy, avoid L1 constructs when L2 alternatives exist, and avoid hardcoding account IDs or regions in favor of cdk.Aws.ACCOUNT_ID. For circular dependencies between stacks, the fix is to extract shared resources into a dedicated base stack and pass references via constructor props.

Input is an infrastructure requirement (serverless API, container service, data pipeline); output is CDK construct code using L2 constructs, least-privilege IAM roles, appropriate removal policies and tags, stacks split by statefulness, and monitoring (CloudWatch alarms, X-Ray tracing) enabled by default.

Cloud and platform engineers building or reviewing AWS CDK infrastructure who want reusable, production-grade construct patterns with least-privilege IAM and built-in monitoring, rather than hand-writing CloudFormation or ad hoc CDK stacks.