DEV Community: TOMOAKI ishihara

AWS CDK 100 Drill Exercises #007: SQS-Lambda-Firehose —— Building Event-Driven Data Pipelines

TOMOAKI ishihara — Mon, 26 Jan 2026 15:23:32 +0000

Introduction

This is the 8th installment of "AWS CDK 100 Drill Exercises". For the series overview, see here.

In this exercise, we'll build an event-driven data pipeline combining SQS, Lambda, and Firehose.

Why SQS-Lambda-Firehose?

Feature	Benefit
Event-Driven	Loosely coupled and scalable
Reliability	Robust error handling with DLQ and batch failure reporting
Cost Efficiency	Serverless with pay-per-use pricing
Reduced Ops	Minimize infrastructure management with managed services

What You'll Learn

SQS + Dead Letter Queue design
Lambda ReportBatchItemFailures for batch processing
Firehose → S3 streaming delivery
Production monitoring with CloudWatch Alarms

📁 Code Repository: GitHub

Architecture Overview

Data Flow

Producer → SQS Queue → Lambda → Firehose → S3
                ↓ (on failure)
           Dead Letter Queue

Key Components and Design Points

Component	Design Points
SQS Queue	Long Polling (20s), Visibility Timeout (30s), SSL enforcement
Dead Letter Queue	Move to DLQ after 3 failures, 14-day retention
Lambda	Batch size 5, ReportBatchItemFailures enabled, X-Ray enabled
SQS Queue (for Failure Lambda)	Long Polling (20s), Visibility Timeout (30s), SSL enforcement
Lambda (Failure)	Lambda without Firehose permissions for DLQ behavior validation
Firehose	1min/1MB buffering, partitioned prefix
S3	Lifecycle management (60d→IA, 90d→Glacier, 365d→Delete)
CloudWatch	8 alarms + SNS notifications

Implementation Highlights

1. SQS + Dead Letter Queue

DLQ configuration is critical for isolating failed messages and enabling investigation and reprocessing.

See: stacks/sqs-lambda-firehose-stack.ts#L35

// Dead Letter Queue
const deadLetterQueue = new sqs.Queue(this, 'DeadLetterQueue', {
  retentionPeriod: cdk.Duration.days(14),
  enforceSSL: true,
});

// Main Queue with DLQ
const queue = new sqs.Queue(this, 'MainQueue', {
  visibilityTimeout: cdk.Duration.seconds(30),
  receiveMessageWaitTime: cdk.Duration.seconds(20), // Long Polling
  deadLetterQueue: {
    maxReceiveCount: 3, // Move to DLQ after 3 failures
    queue: deadLetterQueue,
  },
  enforceSSL: true,
});

Best Practice: Set Visibility Timeout to at least 6 times the Lambda timeout (see documentation)

2. Lambda - ReportBatchItemFailures

When only some messages in a batch fail, you can reprocess only the failed ones.

lambdaFunction.addEventSource(
  new lambdaEventSources.SqsEventSource(queue, {
    batchSize: 5,
    reportBatchItemFailures: true, // Support partial failures
  })
);

Without Powertools vs With Powertools

❌ Without Powertools (Manual Implementation)

def lambda_handler(event, context):
    records = event.get("Records", [])
    batch_item_failures = []

    for record in records:
        message_id = record.get("messageId")
        message_body = record.get("body", "")

        try:
            process_message(message_body)
        except Exception as e:
            # Manually add failed record ID
            batch_item_failures.append({"itemIdentifier": message_id})

    # Manually construct response format
    return {"batchItemFailures": batch_item_failures}

Problems:

Need to manually add itemIdentifier to batch_item_failures
Must construct response format accurately
Lots of error handling boilerplate
Testing becomes complex

✅ With Powertools (Recommended)

from aws_lambda_powertools.utilities.batch import (
    BatchProcessor, EventType, process_partial_response
)

processor = BatchProcessor(event_type=EventType.SQS)

def record_handler(record):
    """Process each record - just raise exception on failure"""
    payload = record.json_body
    send_to_firehose(payload)

def lambda_handler(event, context):
    return process_partial_response(
        event=event,
        record_handler=record_handler,
        processor=processor,
        context=context
    )

Benefits:

itemIdentifier extraction and setting are automated
No need to worry about response format
record_handler can focus solely on processing logic
Just raise an exception on failure

Item	Manual Implementation	Powertools
Code Volume	Large	Small
Bug Risk	High (itemIdentifier mistakes, etc.)	Low
Test Ease	Complex	Simple
Metrics	Manual addition	Auto-collection available

📝 Complete Lambda Function Code (Python)

See: sqs-firehose-powertools/index.py

import json
import os
import boto3
from aws_lambda_powertools import Logger, Tracer, Metrics
from aws_lambda_powertools.utilities.batch import (
    BatchProcessor, EventType, process_partial_response
)
from aws_lambda_powertools.utilities.data_classes.sqs_event import SQSRecord

logger = Logger()
tracer = Tracer()
metrics = Metrics()

processor = BatchProcessor(event_type=EventType.SQS)
firehose_client = boto3.client('firehose')
delivery_stream_name = os.environ['FIREHOSE_DELIVERY_STREAM_NAME']

@tracer.capture_method
def record_handler(record: SQSRecord):
    """Process individual record"""
    payload = record.json_body
    logger.info("Processing message", extra={"message_id": record.message_id})

    response = firehose_client.put_record(
        DeliveryStreamName=delivery_stream_name,
        Record={'Data': json.dumps(payload) + '\n'}
    )

    logger.info("Sent to Firehose", extra={"record_id": response['RecordId']})
    metrics.add_metric(name="ProcessedMessages", unit="Count", value=1)

@logger.inject_lambda_context
@tracer.capture_lambda_handler
@metrics.log_metrics(capture_cold_start_metric=True)
def lambda_handler(event, context):
    return process_partial_response(
        event=event,
        record_handler=record_handler,
        processor=processor,
        context=context
    )

3. Firehose - Partitioned Delivery

Improves S3 query performance and analysis efficiency with Athena and similar tools.

See: stacks/sqs-lambda-firehose-stack.ts#L168

See: dev-params.ts#L69

const deliveryStream = new firehose.DeliveryStream(this, 'DeliveryStream', {
  destination: new firehose.S3Bucket(bucket, {
    dataOutputPrefix: '!{timestamp:yyyy/MM/dd}/',      // Partition by date
    errorOutputPrefix: '!{firehose:error-output-type}/!{timestamp:yyyy/MM/dd}/',
    bufferingInterval: cdk.Duration.minutes(1),
    bufferingSize: cdk.Size.mebibytes(1),
  }),
});

4. S3 Lifecycle Management

See: stacks/sqs-lambda-firehose-stack.ts#L88

bucket.addLifecycleRule({
  transitions: [
    { storageClass: s3.StorageClass.INFREQUENT_ACCESS, transitionAfter: cdk.Duration.days(60) },
    { storageClass: s3.StorageClass.GLACIER, transitionAfter: cdk.Duration.days(90) },
  ],
  expiration: cdk.Duration.days(365),
});

📝 Complete Stack Implementation Code

import * as cdk from 'aws-cdk-lib/core';
import { Construct } from 'constructs';
import * as sqs from 'aws-cdk-lib/aws-sqs';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as pythonLambda from '@aws-cdk/aws-lambda-python-alpha';
import * as lambdaEventSources from 'aws-cdk-lib/aws-lambda-event-sources';
import * as firehose from 'aws-cdk-lib/aws-kinesisfirehose';
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as logs from 'aws-cdk-lib/aws-logs';

export class SqsLambdaFirehoseStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props: SqsLambdaFirehoseStackProps) {
    super(scope, id, props);

    // 1. Dead Letter Queue
    const deadLetterQueue = new sqs.Queue(this, 'DeadLetterQueue', {
      retentionPeriod: cdk.Duration.days(14),
      enforceSSL: true,
      encryption: sqs.QueueEncryption.SQS_MANAGED,
    });

    // 2. Main Queue
    const queue = new sqs.Queue(this, 'MainQueue', {
      visibilityTimeout: cdk.Duration.seconds(30),
      retentionPeriod: cdk.Duration.days(4),
      receiveMessageWaitTime: cdk.Duration.seconds(20),
      deadLetterQueue: { maxReceiveCount: 3, queue: deadLetterQueue },
      enforceSSL: true,
    });

    // 3. S3 Bucket
    const bucket = new s3.Bucket(this, 'DataBucket', {
      removalPolicy: cdk.RemovalPolicy.DESTROY,
      autoDeleteObjects: true,
      enforceSSL: true,
      versioned: true,
      encryption: s3.BucketEncryption.S3_MANAGED,
    });

    bucket.addLifecycleRule({
      transitions: [
        { storageClass: s3.StorageClass.INFREQUENT_ACCESS, transitionAfter: cdk.Duration.days(60) },
        { storageClass: s3.StorageClass.GLACIER, transitionAfter: cdk.Duration.days(90) },
      ],
      expiration: cdk.Duration.days(365),
    });

    // 4. Firehose
    const deliveryStream = new firehose.DeliveryStream(this, 'DeliveryStream', {
      destination: new firehose.S3Bucket(bucket, {
        dataOutputPrefix: '!{timestamp:yyyy/MM/dd}/',
        errorOutputPrefix: '!{firehose:error-output-type}/!{timestamp:yyyy/MM/dd}/',
        bufferingInterval: cdk.Duration.minutes(1),
        bufferingSize: cdk.Size.mebibytes(1),
      }),
    });

    // 5. Lambda Function
    const lambdaFunction = new pythonLambda.PythonFunction(this, 'ProcessorFunction', {
      runtime: lambda.Runtime.PYTHON_3_14,
      handler: 'lambda_handler',
      entry: '../../common/src/python-lambda/sqs-firehose',
      timeout: cdk.Duration.seconds(5),
      memorySize: 256,
      environment: {
        FIREHOSE_DELIVERY_STREAM_NAME: deliveryStream.deliveryStreamName,
      },
      tracing: lambda.Tracing.ACTIVE,
      loggingFormat: lambda.LoggingFormat.JSON,
    });

    // 6. Permissions &amp; Event Source
    queue.grantConsumeMessages(lambdaFunction);
    deliveryStream.grantPutRecords(lambdaFunction);

    lambdaFunction.addEventSource(
      new lambdaEventSources.SqsEventSource(queue, {
        batchSize: 5,
        reportBatchItemFailures: true,
      })
    );
  }
}

CloudWatch Monitoring

In production, we configure 8 alarms with SNS notifications.

Alarm List

Category	Alarm	Threshold	Purpose
SQS	ApproximateAgeOfOldestMessage	300s	Detect message backlog
SQS	NumberOfEmptyReceives	100	Detect Long Polling issues
DLQ	ApproximateNumberOfMessagesVisible	1	Immediate failure detection
Firehose	DeliveryToS3.DataFreshness	900s	Detect delivery delays
Firehose	ThrottledRecords	1	Detect throttling
Firehose	IncomingBytes Rate	80%	Quota utilization
Firehose	IncomingRecords Rate	80%	Quota utilization
Firehose	IncomingPutRequests Rate	80%	Quota utilization

DLQ Alarm (Most Critical)

See: stacks/sqs-lambda-firehose-stack.ts#L369

const dlqAlarm = deadLetterQueue
  .metricApproximateNumberOfMessagesVisible()
  .createAlarm(this, 'DlqAlarm', {
    threshold: 1,  // Alert even with 1 message
    evaluationPeriods: 1,
  });

Firehose Quota Monitoring (Math Expression)

See: stacks/sqs-lambda-firehose-stack.ts#L390

const incomingBytesRateAlarm = new cw.Alarm(this, 'IncomingBytesRateAlarm', {
  threshold: 80, // Alert at 80% usage
  metric: new cw.MathExpression({
    expression: '100*(m1/300/m2)',  // Calculate usage as %
    usingMetrics: {
      m1: firehose.metric('IncomingBytes', { statistic: 'Sum' }),
      m2: firehose.metric('BytesPerSecondLimit', { statistic: 'Minimum' }),
    },
  }),
});

📝 SNS Notification Integration Code

const topic = new sns.Topic(this, 'AlertTopic', {
  displayName: 'SQS-Firehose Alerts',
});

[dlqAlarm, sqsAgeAlarm, firehoseFreshnessAlarm, ...otherAlarms].forEach(alarm =&gt; {
  alarm.addAlarmAction(new cw_actions.SnsAction(topic));
});

Deployment & Verification

npm run stage:deploy:all -w workspaces/sqs-lambda-firehose --project=myproject --env=dev

See: test-scripts/send-messages.sh

# Send test messages
./test-scripts/send-messages.sh --env dev --project myproject

# Verify data is saved in S3
./test-scripts/check-s3.sh --env dev --project myproject

Best Practices Summary

Component	Recommended	Avoid
SQS	Long Polling, DLQ configuration, SSL enforcement	Short Polling, no DLQ
Lambda	ReportBatchItemFailures, appropriate batch size (5-10)	Too large batches, no error handling
Firehose	Partitioning, 1-5MB buffer	No partitioning, excessively long buffer time
S3	Lifecycle management, encryption	No lifecycle, public access

Cost Estimation

💰 Monthly Estimate (Tokyo Region, Low-to-Medium Usage)

Service	Usage	Monthly Cost
SQS	1M requests	$0.40
Lambda	1M requests, 256MB	$0.83
Firehose	1GB delivery	$0.03
S3	10GB~60GB	$0.50~1.00
CloudWatch	5GB Logs	$0.27

Total: ~$7-10/month

Summary

What we learned from this pattern:

SQS + DLQ: Reliable message processing
ReportBatchItemFailures: Efficient handling of partial failures
Firehose Partitioning: Analytics-friendly data storage
CloudWatch Alarms: Essential monitoring for production

References

Let's continue learning practical AWS CDK patterns through the 100 drill exercises!
If you found this helpful, please ⭐ the repository!

📌 You can see the entire code in My GitHub Repository.

AWS CDK 100 Drill Exercises #006: VPC Peering - Cross-Account Network Integration and DNS Resolution Automation

TOMOAKI ishihara — Wed, 31 Dec 2025 11:23:15 +0000

Introduction

This is the 6th installment of "AWS CDK 100 Drill Exercises."

For more information about AWS CDK 100 Drill Exercises, please refer to this article.

In this article, we will explore cross-account network integration using VPC Peering, a key feature that enables private communication between multiple VPCs and is a core technology in a multi-account strategy.

Why VPC Peering?

Multi-account strategy: Organizations are recommended to manage development, staging, and production environments in separate accounts
Secure communication: Private communication between VPCs without going through the internet
Cost efficiency: Simpler network configuration at lower cost compared to Transit Gateway
CDK complexity: Learn CDK limitations and workarounds for cross-account resource references
Practical necessity: Essential network configuration pattern in enterprise environments

What You'll Learn

VPC Peering connection implementation (same account & cross-account)
CDK cross-account stack reference limitations and solutions
Value sharing using AWS Systems Manager Parameter Store
Cross-account parameter reading via Custom Resources
IAM Cross-Account Role design and implementation
Automatic VPC Peering connection acceptance and route configuration
Cross-account deployment best practices

📁 Code Repository: All code examples for this exercise are available on GitHub.

Architecture Overview

What we will build:

Configuration Pattern

Account A (111111111111):
├─ VPC A (10.0.0.0/16)
│  └─ Test Instance (Private Subnet)
├─ VPC B (10.1.0.0/16)
│  └─ Test Instance (Private Subnet)
└─ VPC A ↔ VPC B Peering (same account)

Account B (222222222222):
└─ VPC C (10.2.0.0/16)
   └─ Test Instance (Private Isolated Subnet)

Cross-account Peering:
VPC B (Account A) ↔ VPC C (Account B)

Key Components

VpcAStack (Account A)
- Create VPC A and VPC B
- VPC Peering connection within same account
- Save VPC B information to Parameter Store (readable by Account B)
VpcCStack (Account B)
- Create VPC C
- Save VPC C information to Parameter Store (readable by Account A)
- Create ParameterStoreReadRole (for reading from Account A)
CrossAccountPeeringStack (Account A)
- Retrieve VPC C information via Custom Resource
- Create Peering connection between VPC B and VPC C
- Save Peering connection ID to Parameter Store
- Create PeeringIdReadRole (for reading from Account B)
VpcCRoutesStack (Account B)
- Retrieve Peering connection ID via Custom Resource
- Add routes to VPC B in VPC C's route tables

Prerequisites

AWS CLI v2 installed and configured
Node.js 20+
AWS CDK CLI (npm install -g aws-cdk)
Basic TypeScript knowledge
Two AWS accounts (for development, production, etc.)
AWS CLI profile configuration for each account
Understanding of VPC basic concepts (refer to VPC Basics)

Project Directory Structure

vpc-peering/
├── bin/
│   └── vpc-peering.ts                     # Application entry point
├── lib/
│   ├── stacks/
│   │   ├── vpc-a-stack.ts                 # Step1. VPC A/B + same account peering
│   │   ├── vpc-c-stack.ts                 # Step2. VPC C (Account B)
│   │   ├── cross-account-peering-stack.ts # Step3. Cross-account peering
│   │   └── vpc-c-routes-stack.ts          # Step4. VPC C route configuration
│   ├── stages/
│   │   └── vpc-peering-stage.ts           # Deployment orchestration
│   └── types/
│       └── vpc-peering-params.ts          # Parameter type definitions
├── parameters/
│   └── environments.ts                   # Environment-specific parameters
└── test/
    ├── compliance/
    │   └── cdk-nag.test.ts               # CDK Nag compliance test
    ├── snapshot/
    │   └── snapshot.test.ts              # Snapshot test
    └── unit/
        ├── vpc-a.test.ts                 # VPC Peering stack test
        ├── vpc-c.test.ts                 # VPC C stack test
        ├── vpc-c-routes-stack.test.ts    # VPC C route configuration stack test
        └── cross-account-peering.test.ts # Cross-account peering test

Cross-Account Reference Challenges in CDK

This implementation requires cross-account value references. In this case, there are the following issues:

Problem: CloudFormation Runtime Limitations

When referencing cross-account resources in CDK, it cannot execute due to the following limitations:

// ❌ This does not work
const vpcCStack = new VpcCStack(this, 'VpcC', {
  env: { account: accountB }
});

const peeringStack = new CrossAccountPeeringStack(this, 'Peering', {
  env: { account: accountA },
  peerVpc: vpcCStack.vpc  // ❌ Cross-account reference not allowed
});

Error message:

Stack "CrossAccountPeering" cannot consume a cross reference from stack "VpcC".
Cross stack references are only supported for stacks deployed to the same environment

Why doesn't it work?

CloudFormation Export/Import limitations
- CloudFormation Export/Import only works within the same account and same region
- Cannot directly reference stack outputs between different accounts
How CDK stack references work
- CDK internally uses CloudFormation Export/Import
- This mechanism cannot be used for cross-account
Evaluation timing during deployment
- vpcCStack.vpc.vpcId is evaluated at deployment time
- Cannot retrieve values from resources deployed in Account B during Account A deployment

Solutions

To solve cross-account references, the following methods can be considered.
Ultimately, we adopted the second method.

1. Static parameter passing via CDK Context or environment variable files
2. Passing via Parameter Store and AWS Custom Resources

1. Manual Parameter Passing via CDK Context or Environment Variable Files

Implementation:

// Get parameter for VPC C ID created in Account B
const vpcCId = this.node.tryGetContext('vpcCId');

if (!vpcCId) {
  console.warn('vpcCId not provided. Run: cdk deploy --context vpcCId=vpc-xxx');
  return;
}

// Create VPC Peering
const peering = new ec2.CfnVPCPeeringConnection(this, 'Peering', {
  vpcId: localVpc.vpcId,
  peerVpcId: vpcCId,  // ✅ Works
  peerOwnerId: accountB,
});

Deployment procedure:

# 1. Create VPC C in Account B
cdk deploy --profile account-b VpcC

# 2. Manually retrieve VPC C ID
VPC_C_ID=$(aws ec2 describe-vpcs --profile account-b \
  --filters "Name=tag:Name,Values=VpcC" \
  --query 'Vpcs[0].VpcId' --output text)

# 3. Create Peering in Account A (pass VPC ID)
cdk deploy --profile account-a --context vpcCId=$VPC_C_ID CrossAccountPeering

Issues:

⚠️ Manual parameter retrieval required
Difficult to automate in CI/CD pipelines
Human error risk (copy & paste mistakes, etc.)
Lack of scalability (management becomes complex as parameters increase)

2. Parameter Store and AWS Custom Resources

Architecture:

Account B:
├─ VPC C
├─ SSM Parameter (/project/env/vpc-c/id)
└─ ParameterStoreReadRole <- Can be assumed by Account A

Account A:
├─ Custom Resource
│  ├─ assumeRole -> Account B's ParameterStoreReadRole
│  └─ getParameter -> Retrieve VPC C ID
└─ VPC Peering Connection (using retrieved VPC C ID)

Implementation:

Account B: Create Parameter Store + Read Role

// VpcCStack (Account B)
const vpcCIdParam = new ssm.StringParameter(this, 'VpcIdParam', {
  stringValue: this.vpcC.vpc.vpcId,
  parameterName: `/project/env/vpc-c/id`,
});

// IAM role for reading from Account A
const readRole = new iam.Role(this, 'ParameterStoreReadRole', {
  assumedBy: new iam.AccountPrincipal(accountA),
  roleName: 'project-env-ParameterStoreReadRole',
});

vpcCIdParam.grantRead(readRole);

Account A: Read parameter with Custom Resource

// CrossAccountPeeringStack (Account A)
import * as cr from 'aws-cdk-lib/custom-resources';

const readRoleArn = `arn:aws:iam::${accountB}:role/project-env-ParameterStoreReadRole`;

// Read Parameter Store from other account with Custom Resource
const getVpcCId = new cr.AwsCustomResource(this, 'GetVpcCId', {
  onUpdate: {
    service: 'SSM',
    action: 'getParameter',
    parameters: {
      Name: '/project/env/vpc-c/id',
    },
    region: 'ap-northeast-1',
    physicalResourceId: cr.PhysicalResourceId.of('VpcCIdLookup'),
    assumedRoleArn: readRoleArn,  // ✅ Assume Account B's Role
  },
  policy: cr.AwsCustomResourcePolicy.fromStatements([
    new iam.PolicyStatement({
      actions: ['sts:AssumeRole'],
      resources: [readRoleArn],
    }),
  ]),
});

const vpcCId = getVpcCId.getResponseField('Parameter.Value');

// Create VPC Peering
const peering = new ec2.CfnVPCPeeringConnection(this, 'Peering', {
  vpcId: localVpc.vpcId,
  peerVpcId: vpcCId,  // ✅ Use automatically retrieved value
  peerOwnerId: accountB,
});

Benefits:

Fully automated: No manual parameter retrieval required
CI/CD ready: Can be integrated into pipelines
Secure: Strict access control with IAM roles
Scalable: Supports multiple parameters
Error detection: Errors are automatically detected at deployment time

Drawbacks:

Lambda function is automatically created (slight cost increase)
Implementation is somewhat complex
Custom Resource lifecycle management required

VPC Peering Within Same Account

The implementation of VPC Peering within the same account is as follows.

VpcAStack Implementation

// lib/stacks/vpc-peering-stack.ts

export class VpcAStack extends cdk.Stack {
  public readonly vpcA: VpcConstruct;
  public readonly vpcB: VpcConstruct;

  constructor(scope: Construct, id: string, props: VpcAStackProps) {
    super(scope, id, props);

    // Create VPC A
    this.vpcA = new VpcConstruct(this, 'VpcA', {
        // Specify parameters
    });

    // Create VPC B
    this.vpcB = new VpcConstruct(this, 'VpcB', {
        // Specify parameters
    });

    // VPC Peering connection
    const peering = new VpcPeering(this, 'VpcABPeering', {
      vpc: this.vpcA.vpc,
      peerVpc: this.vpcB.vpc,
    });
  }
}

VPC Peering Construct

// common/constructs/vpc/vpc-peering.ts
export class VpcPeering extends Construct {
  public readonly vpcPeeringConnection: ec2.CfnVPCPeeringConnection;
  public readonly localSecurityGroup: ec2.ISecurityGroup;
  public readonly peeringSecurityGroup: ec2.ISecurityGroup;

  constructor(scope: Construct, id: string, props: VpcPeeringProps) {
    super(scope, id);

    // CIDR overlap check
    if (props.vpc.vpcCidrBlock === props.peerVpc.vpcCidrBlock) {
      throw new Error(`VPC CIDR blocks overlap`);
    }

    // Create VPC Peering connection
    this.vpcPeeringConnection = new ec2.CfnVPCPeeringConnection(this, 'Connection', {
      vpcId: props.vpc.vpcId,
      peerVpcId: props.peerVpc.vpcId,
    });

    // Add routes (Local VPC -> Peer VPC)
    props.vpc.privateSubnets.forEach((subnet, index) => {
      new ec2.CfnRoute(this, `RouteToPeer${index}`, {
        routeTableId: subnet.routeTable.routeTableId,
        destinationCidrBlock: props.peerVpc.vpcCidrBlock,
        vpcPeeringConnectionId: this.vpcPeeringConnection.ref,
      });
    });

    // Add routes (Peer VPC -> Local VPC)
    props.peerVpc.privateSubnets.forEach((subnet, index) => {
      new ec2.CfnRoute(this, `RouteToLocal${index}`, {
        routeTableId: subnet.routeTable.routeTableId,
        destinationCidrBlock: props.vpc.vpcCidrBlock,
        vpcPeeringConnectionId: this.vpcPeeringConnection.ref,
      });
    });

    // Security groups (allow mutual communication)
    :

  }
}

Cross-Account VPC Peering

Implementation

Step 3. Deploy to Account A: CrossAccountPeeringStack
   ├─ Retrieve VPC C information via Custom Resource
   ├─ Create VPC B <-> VPC C Peering
   ├─ Save Peering ID to Parameter Store
   └─ Create PeeringIdReadRole

Step 4. Deploy to Account B: VpcCRoutesStack
   ├─ Retrieve Peering ID via Custom Resource
   └─ Update VPC C route tables

VpcCStack (Account B)

// lib/stacks/vpc-c-stack.ts

export class VpcCStack extends cdk.Stack {
  public readonly vpcC: VpcConstruct;

  constructor(scope: Construct, id: string, props: VpcCStackProps) {
    super(scope, id, props);

    // Create VPC C
    this.vpcC = new VpcConstruct(this, 'VpcC', {
        // Specify parameters
    });

    if (props.params.accountAId) {
      // Save VPC C information to Parameter Store
      const vpcCIdParam = new ssm.StringParameter(this, 'VpcIdParam', {
        stringValue: this.vpcC.vpc.vpcId,
        description: 'VPC C ID in Account B',
        parameterName: `/${props.project}/${props.environment}/vpc-c/id`,
      });

      const parameterReadRole = new iam.Role(this, 'ParameterStoreReadRole', {
        assumedBy: new iam.AccountPrincipal(props.params.accountAId),
        roleName: `${props.project}-${props.environment}-ParameterStoreReadRole`,
        description: `Role to allow Account ${props.params.accountAId} to read VPC C parameters from Parameter Store`,
      });
      // Grant read access to VPC C parameters
      vpcCIdParam.grantRead(parameterReadRole);

      // Peering acceptance role
      const peeringRole = new iam.Role(this, 'VpcPeeringRole', {
        assumedBy: new iam.AccountPrincipal(props.params.accountAId),
        roleName: props.peeringRoleName,
      });

      peeringRole.addToPolicy(new iam.PolicyStatement({
        actions: ['ec2:AcceptVpcPeeringConnection'],
        resources: ['*'],
      }));
    }
  }
}

CrossAccountPeeringStack (Account A)

// lib/stacks/cross-account-peering-stack.ts

export class CrossAccountPeeringStack extends cdk.Stack {
  public readonly peeringConnection: ec2.CfnVPCPeeringConnection;

  constructor(scope: Construct, id: string, props: CrossAccountPeeringStackProps) {
    super(scope, id, props);

    // Retrieve VPC C ID via Custom Resource
    const getVpcCId = new cr.AwsCustomResource(this, 'GetVpcCId', {
      onUpdate: {
        service: 'SSM',
        action: 'getParameter',
        parameters: {
          Name: parameterName,
        },
        region: region,
        physicalResourceId: cr.PhysicalResourceId.of('VpcCIdLookup'),
        assumedRoleArn: parameterReadRoleArn,
      },
      policy: cr.AwsCustomResourcePolicy.fromStatements([
        new iam.PolicyStatement({
          actions: ['sts:AssumeRole'],
          resources: [parameterReadRoleArn],
        }),
      ]),
    });
    const vpcCId = getVpcCId.getResponseField('Parameter.Value');

    // Create VPC Peering
    this.peeringConnection = new ec2.CfnVPCPeeringConnection(this, 'VpcBCPeering', {
      vpcId: props.requestorVpc.vpcId,
      peerVpcId: vpcCId,
      peerOwnerId: props.params.accountBId,
      peerRegion: props.params.regionB,
      peerRoleArn: `arn:aws:iam::${props.params.accountBId}:role/${props.peeringRoleName}`,
    });

    // Save Peering ID to Parameter Store
    const peeringIdParam = new ssm.StringParameter(this, 'PeeringConnectionIdParam', {
      stringValue: this.peeringConnectionId,
      description: 'VPC Peering Connection ID for VPC B <-> VPC C',
      parameterName: `/${props.project}/${props.environment}/peering/vpc-b-vpc-c/id`,
    });
    const peeringIdReadRole = new iam.Role(this, 'PeeringIdReadRole', {
      assumedBy: new iam.AccountPrincipal(props.params.accountBId),
      roleName: `${props.project}-${props.environment}-PeeringIdReadRole`,
      description: `Role to allow Account ${props.params.accountBId} to read Peering Connection ID from Parameter Store`,
    });
    peeringIdParam.grantRead(peeringIdReadRole);
  }
}

VpcCRoutesStack (Account B)

// lib/stacks/vpc-c-routes-stack.ts

export class VpcCRoutesStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props: VpcCRoutesStackProps) {
    super(scope, id, props);

    // Account A role
    const parameterReadRoleArn = `arn:aws:iam::${props.params.accountAId}:role/${props.project}-${props.environment}-PeeringIdReadRole`;

    // Retrieve Peering ID via Custom Resource
    const getPeeringConnectionId = new cr.AwsCustomResource(this, 'GetPeeringConnectionId', {
      onUpdate: {
        service: 'SSM',
        action: 'getParameter',
        parameters: {
          Name: props.peeringIdParamName, // /${props.project}/${props.environment}/peering/vpc-b-vpc-c/id,
        },
        region: regionA,
        physicalResourceId: cr.PhysicalResourceId.of('PeeringConnectionIdLookup'),
        assumedRoleArn: parameterReadRoleArn,
      },
      policy: cr.AwsCustomResourcePolicy.fromStatements([
        new iam.PolicyStatement({
          actions: ['sts:AssumeRole'],
          resources: [parameterReadRoleArn],
        }),
      ]),
    });
    const peeringConnectionId = getPeeringConnectionId.getResponseField('Parameter.Value');

    // target Subnet
    // private or isolated subnets
    const targetSubnets =
      (props.vpc.privateSubnets && props.vpc.privateSubnets.length > 0)
        ? props.vpc.privateSubnets
        : props.vpc.isolatedSubnets;
    // Add routes to VPC C private subnets pointing to VPC B
    targetSubnets.forEach((subnet, index) => {
      new ec2.CfnRoute(this, `VpcCToVpcBRoute${index + 1}`, {
        routeTableId: subnet.routeTable.routeTableId,
        destinationCidrBlock: props.vpcBCidr,
        vpcPeeringConnectionId: peeringConnectionId,
      });
    });
  }
}

VPC Peering DNS Resolution Options Automation (Custom Resource Implementation Example)

Why DNS Resolution Options are Needed

Just creating a VPC Peering connection doesn't enable resolution of private DNS names in the peer VPC. For example, if you want to access an EC2 instance in VPC B from VPC A using a private DNS name like ip-10-1-0-10.ap-northeast-1.compute.internal, you need to enable DNS resolution options.

Normally, this option is configured manually from the console or set using AWS CLI as follows (documentation is here):

aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id pcx-xxxxx \
  --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true \
  --accepter-peering-connection-options AllowDnsResolutionFromRemoteVpc=true

In this implementation, we automate this configuration using AWS CDK's AwsCustomResource.

For Same Account

For same account, specify both RequesterPeeringConnectionOptions and AccepterPeeringConnectionOptions.

    // Enable DNS resolution over VPC Peering
    const onCreate: cr.AwsSdkCall = {
        service: 'EC2',
        action: 'modifyVpcPeeringConnectionOptions',
        parameters: {
            VpcPeeringConnectionId: this.peeringConnection.ref,
                RequesterPeeringConnectionOptions: {
                    AllowDnsResolutionFromRemoteVpc: true
                },
                AccepterPeeringConnectionOptions: {
                    AllowDnsResolutionFromRemoteVpc: true,
                }
        },
        region: props.env?.region,
        physicalResourceId: cr.PhysicalResourceId.of(`EnableVpcPeeringDnsResolution:${this.peeringConnection.ref}`),
    }
    const onUpdate = onCreate;
    const onDelete: cr.AwsSdkCall = {
        service: "EC2",
        action: "modifyVpcPeeringConnectionOptions",
        parameters: {
            VpcPeeringConnectionId: this.peeringConnection.ref,
            RequesterPeeringConnectionOptions: {
                AllowDnsResolutionFromRemoteVpc: false
            },
            AccepterPeeringConnectionOptions: {
                AllowDnsResolutionFromRemoteVpc: false,
            }
        },
    }
    new cr.AwsCustomResource(this, 'EnableVpcPeeringDnsResolution', {
        onUpdate,
        onCreate,
        onDelete,
        policy: cr.AwsCustomResourcePolicy.fromSdkCalls({resources: cr.AwsCustomResourcePolicy.ANY_RESOURCE}),
    });

For Cross-Account

For cross-account VPC Peering, configure separately from Requester and Accepter side stacks.

※Duplicate parts from the same account case are omitted.

Requester side (Account A): CrossAccountPeeringStack

        parameters: {
            VpcPeeringConnectionId: this.peeringConnection.ref,
            RequesterPeeringConnectionOptions: {
                AllowDnsResolutionFromRemoteVpc: true
            },
        },

Accepter side (Account B): VpcCRoutesStack

        parameters: {
            VpcPeeringConnectionId: peeringConnectionId,
            AccepterPeeringConnectionOptions: {
                AllowDnsResolutionFromRemoteVpc: true,
            }
        },

Deployment and Cleanup

1. Environment Parameter Configuration

// parameters/environments.ts

export const params: Record<Environment, EnvParams> = {
  [Environment.DEVELOPMENT]: {
    accountAId: '111111111111',  // Account A
    accountBId: '222222222222',  // Account B
    regionA: 'ap-northeast-1',
    regionB: 'ap-northeast-1',
    vpcAConfig: {
      createConfig: {
        cidr: '10.0.0.0/16',
        maxAzs: 2,
        natGateways: 1,
      },
    },
    vpcBConfig: {
      createConfig: {
        cidr: '10.1.0.0/16',
        maxAzs: 2,
        natGateways: 1,
      },
    },
    vpcCConfig: {
      createConfig: {
        cidr: '10.2.0.0/16',
        maxAzs: 2,
        natGateways: 0,
      },
    },
  },
};

2. Bootstrap

1. Bootstrap Account A (pipeline account)

# Basic bootstrap to host pipeline in Account A
npx cdk bootstrap \
    --profile account-a-admin \
    --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess \
    aws://111111111111/ap-northeast-1

2. Bootstrap Account B (target account)

# Bootstrap Account B and trust Account A
npx cdk bootstrap \
    --profile account-b-admin \
    --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess \
    --trust 111111111111 \
    aws://222222222222/ap-northeast-1

Important points:

--trust 111111111111: Allows Account A to deploy to Account B
This configuration allows Account A's bootstrap role to AssumeRole to Account B's resources

How `--trust` option works

1. IAM Role Creation

When you bootstrap with the --trust option, the following IAM roles are created:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

This trust policy allows Account A's principals to:

CDKDeployRole: Deploy CloudFormation stacks
CDKFilePublishingRole: Upload file assets to S3
CDKImagePublishingRole: Push Docker images to ECR

3. Deployment

CDK_CROSS_ACCOUNT_ID=222222222222 npm run stage:deploy:all -w workspaces/vpc-peering --project=myproject --env=dev

4. Connection Verification

Example connection verification from VPC A. In the example below, we connect to EC2, but you can also use CloudShell.

# Ping from VPC A instance to VPC B instance
aws ssm start-session --profile account-a \
  --target i-0xxxxxxxxxxxxx  # VPC A Instance ID

# Connectivity check to VPC B
ping 10.1.x.x  # VPC B Private IP

# Ping to VPC C (cross-account) -> Cannot connect from VPC A
ping 10.2.x.x  # VPC C Private IP

5. Cleanup

If you connected to VPC using CloudShell for connection verification, delete the CloudShell environment before cleanup. Stack deletion will fail.

# Delete all resources
CDK_CROSS_ACCOUNT_ID=222222222222 npm run stage:destroy:all -w workspaces/vpc-peering --project=myproject --env=dev

Summary

This article explained the implementation of VPC Peering using AWS CDK, focusing on cross-account challenges and solutions.

What We Learned

CDK cross-account limitations
- CloudFormation Export/Import only works within the same account
- Stack references do not work cross-account
Implementation patterns
- Parameter Store: Store and share values
- IAM Cross-Account Role: Secure access control
- Custom Resource: Dynamic value retrieval at deployment time

References

Let's continue learning practical AWS CDK patterns through the 100 drill exercises!
If you found this helpful, please ⭐ the repository!

📌 You can see the entire code in My GitHub Repository.

AWS CDK 100 Drill Exercises #005: CDK Parameters —— Managing Parameters with TypeScript vs cdk.json

TOMOAKI ishihara — Fri, 26 Dec 2025 14:21:53 +0000

Introduction

This is the fifth installment of "AWS CDK 100 Drill Exercises."

For more information about AWS CDK 100 Drill Exercises, please refer to this article.

When developing CDK applications, you'll face the challenge of how to manage different configuration values for each environment. Small instances for development, large instances for production. One NAT Gateway for development, multiple across AZs for production. How should you manage these environment-specific configurations?

In this exercise, we'll implement two main approaches for managing parameters in CDK and understand the pros and cons of each.

Why is Parameter Management Important?

Environment Isolation: Use different configurations for development, staging, and production
Code Reusability: Reuse the same code with different configurations
Configuration Visibility: Make it clear what values are being used
Ease of Change: Change configurations without modifying code
Type Safety: Leverage TypeScript's type system for safe configuration management

What You'll Learn

How to define parameters in TypeScript files (type-safety focused)
How to define parameters in cdk.json (flexibility focused)
Environment-specific parameter management and best practices
Parameter validation at deployment time
Pros and cons of each approach
When to use which approach in production

📁 Code Repository: All code examples for this exercise are available on GitHub.

Architecture Overview

Here's what we'll build:

We'll implement two parameter management approaches.

1. TypeScript Parameters (CdkTSParametersStack)

Define parameters in TypeScript files
Type safety and IDE support
Separate parameter files for each environment
Compile-time validation

2. cdk.json Parameters (CdkJsonParametersStack)

Define parameters in the context section of cdk.json
JSON-based flexible configuration
Standard CDK approach
Easy dynamic value retrieval

Both approaches create the same VPC resources, but differ in how parameters are defined and type safety is ensured.

Prerequisites

To proceed with this exercise, you'll need:

AWS CLI v2 installed and configured
Node.js 20+
AWS CDK CLI (npm install -g aws-cdk)
Basic knowledge of TypeScript
AWS Account (can be done within free tier)
Basic understanding of VPC concepts (refer to Episode 3: VPC Basics)

Project Directory Structure

cdk-parameters/
├── bin/
│   └── cdk-parameters.ts                # Application entry point
├── lib/
│   ├── stacks/
│   │   ├── cdk-ts-parameters-stack.ts   # TypeScript parameters stack
│   │   └── cdk-json-parameters-stack.ts # cdk.json parameters stack
│   └── types/
│       ├── common.ts                     # Common type definitions
│       ├── vpc.ts                        # VPC type definitions
│       └── index.ts                      # Type definitions export
├── parameters/
│   ├── environments.ts                   # Environment definitions and parameter interfaces
│   ├── dev-params.ts                     # Development environment parameters
│   ├── stg-params.ts                     # Staging environment parameters
│   ├── prd-params.ts                     # Production environment parameters
│   └── index.ts                          # Parameter exports
├── test/
│   ├── compliance/
│   │   └── cdk-nag.test.ts              # Compliance tests
│   ├── snapshot/
│   │   └── snapshot.test.ts             # Snapshot tests
│   └── unit/
│       ├── cdk-ts-parameters-stack.test.ts # Unit tests
│       └── cdk-json-parameters-stack.test.ts
├── cdk.json                              # CDK configuration and JSON parameters
├── package.json
└── tsconfig.json

Pattern 1: Defining Parameters in TypeScript Files

Creating Type Definitions

First, define the types for parameters. This enables IDE autocomplete and compile-time type checking.

// lib/types/index.ts
import * as ec2 from 'aws-cdk-lib/aws-ec2';

export enum Environment {
  DEVELOPMENT = 'dev',
  STAGING = 'stg',
  PRODUCTION = 'prd',
  TEST = 'test',
}

export interface SubnetConfig {
  subnetType: ec2.SubnetType;
  name: string;
  cidrMask: number;
}

export interface VpcCreateConfig {
  vpcName?: string;
  cidr: string;
  maxAzs?: number;
  natCount?: number;
  enableDnsHostnames?: boolean;
  enableDnsSupport?: boolean;
  subnets?: SubnetConfig[];
}

export interface VpcConfig {
  existingVpcId?: string;
  createConfig?: VpcCreateConfig;
}

Key Points:

Detailed type definitions like SubnetConfig and VpcCreateConfig prevent configuration mistakes
Using enum for environment names prevents typos
Optional properties (?) allow for default value usage

Environment-Specific Parameter Files

Create parameter files for each environment.

// parameters/environments.ts
export interface EnvParams {
    accountId?: string;
    vpcConfig: VpcConfig;
}

export const params: Partial<Record<Environment, EnvParams>> = {};

// parameters/dev-params.ts
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as types from 'lib/types';
import { params, EnvParams } from 'parameters/environments';

const devParams: EnvParams = {
    accountId: '111122223333',  // Development environment AWS Account ID
    vpcConfig: {
        createConfig: {
            vpcName: 'DevVPC',
            cidr: '10.10.0.0/16',
            maxAzs: 2,              // Only 2 AZs for development
            natCount: 1,            // Only 1 NAT for cost savings
            enableDnsHostnames: true,
            enableDnsSupport: true,
            subnets: [
                {
                    subnetType: ec2.SubnetType.PUBLIC,
                    name: 'Public',
                    cidrMask: 24,
                },
                {
                    subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
                    name: 'Private',
                    cidrMask: 24,
                },
            ],
        },
    },
};

// Register in global params object
params[types.Environment.DEVELOPMENT] = devParams;

// parameters/prd-params.ts
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as types from 'lib/types';
import { params, EnvParams } from 'parameters/environments';

const prdParams: EnvParams = {
    accountId: '999988887777',  // Production environment AWS Account ID
    vpcConfig: {
        createConfig: {
            vpcName: 'PrdVPC',
            cidr: '10.0.0.0/16',
            maxAzs: 3,              // 3 AZs for redundancy in production
            natCount: 3,            // NAT Gateway in each AZ
            enableDnsHostnames: true,
            enableDnsSupport: true,
            subnets: [
                {
                    subnetType: ec2.SubnetType.PUBLIC,
                    name: 'Public',
                    cidrMask: 24,
                },
                {
                    subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
                    name: 'Private',
                    cidrMask: 24,
                },
            ],
        },
    },
};

params[types.Environment.PRODUCTION] = prdParams;

Key Points:

Different configurations for development and production (number of AZs, NAT Gateways)
Including account ID prevents deployment to wrong accounts
Type safety detects configuration errors at compile time

Stack Using Parameters

// lib/stacks/cdk-parameters-stack.ts
import * as cdk from 'aws-cdk-lib/core';
import { Construct } from 'constructs';
import { VpcConfig, Environment } from 'lib/types';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import { pascalCase } from 'change-case-commonjs';

export interface StackProps extends cdk.StackProps {
  project: string;
  environment: Environment;
  isAutoDeleteObject: boolean;
  vpcConfig: VpcConfig;
}

export class CdkTSParametersStack extends cdk.Stack {
  public readonly vpc: ec2.IVpc;

  constructor(scope: Construct, id: string, props: StackProps) {
    super(scope, id, props);

    // Reference existing VPC
    if (props.vpcConfig.existingVpcId) {
      this.vpc = ec2.Vpc.fromLookup(this, 'VPC', {
        vpcId: props.vpcConfig.existingVpcId,
      });
      return;
    }

    // Create new VPC
    if (props.vpcConfig.createConfig) {
      const createConfig = props.vpcConfig.createConfig;
      const vpcNameSuffix = createConfig.vpcName ?? 'vpc';

      this.vpc = new ec2.Vpc(this, 'VPC', {
        vpcName: `${pascalCase(props.project)}/${pascalCase(props.environment)}/${pascalCase(vpcNameSuffix)}`,
        ipAddresses: ec2.IpAddresses.cidr(createConfig.cidr),
        maxAzs: createConfig.maxAzs || cdk.Stack.of(this).availabilityZones.length,
        natGateways: createConfig.natCount || 1,
        subnetConfiguration: createConfig.subnets || [
          // Default subnet configuration
          {
            subnetType: ec2.SubnetType.PUBLIC,
            name: 'Public',
            cidrMask: 24,
          },
          {
            subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
            name: 'Private',
            cidrMask: 24,
          },
        ],
        enableDnsHostnames: createConfig.enableDnsHostnames ?? true,
        enableDnsSupport: createConfig.enableDnsSupport ?? true,
      });
    } else {
      throw new Error('VPC configuration is required to create the VPC.');
    }
  }
}

Key Points:

Type-safe parameter passing through VpcConfig interface
Supports both existing VPC reference and new creation
Default values allow operation with minimal parameters

Entry Point and Deployment Validation

// bin/cdk-parameters.ts
#!/usr/bin/env node
import * as cdk from 'aws-cdk-lib/core';
import { pascalCase } from "change-case-commonjs";
import { params } from "parameters/environments";
import { CdkParametersStage } from 'lib/stages/cdk-parameters-stage';
import { Environment } from 'lib/types/common';
import { validateDeployment } from '@common/helpers/validate-deployment';
import 'parameters';

const app = new cdk.App();

const pjName: string = app.node.tryGetContext("project");
const envName: Environment = 
app.node.tryGetContext("env") || Environment.DEVELOPMENT;

const defaultEnv = {
    account: process.env.CDK_DEFAULT_ACCOUNT,
    region: process.env.CDK_DEFAULT_REGION,
};

// Check for parameter existence
if (!params[envName]) {
throw new Error(`No parameters found for environment: ${envName}`);
}

// Pre-deployment validation
validateDeployment(pjName, envName, params[envName].accountId);

const isAutoDeleteObject = true;
const isTerminationProtection = false;

new CdkParametersStage(app, `${pascalCase(envName)}`, {
    project: pjName,
    environment: envName,
    env: defaultEnv,
    terminationProtection: isTerminationProtection,
    isAutoDeleteObject: isAutoDeleteObject,
    params: params[envName],
});

cdk.Tags.of(app).add("Project", pjName);
cdk.Tags.of(app).add("Environment", envName);

Deployment Validation Implementation:

// common/helpers/validate-deployment.ts
export function validateDeployment(
  pjName: string, 
  envName: string, 
  accountId?: string
): void {
  console.log(`Project Name: ${pjName}`);
  console.log(`Environment Name: ${envName}`);

  // Account ID validation
  if (accountId) {
    const isSameAccount = accountId === process.env.CDK_DEFAULT_ACCOUNT;
    if (!isSameAccount) {
      const warningBox = [
        '',
        '╭────────────────────────────────────────────────────────────╮',
        '│ ❌ ACCOUNT MISMATCH WARNING                                │',
        '│                                                            │',
        '│  The provided account ID does not match the current        │',
        '│  CDK account.                                              │',
        '│                                                            │',
        `│  Expected: ${accountId}                                    │`,
        `│  Current:  ${process.env.CDK_DEFAULT_ACCOUNT}              │`,
        '│                                                            │',
        '╰────────────────────────────────────────────────────────────╯',
        '',
      ].join('\n');
      console.log(warningBox);
      throw new Error('Account ID mismatch. Deployment aborted.');
    }
  }

  // Production environment deployment confirmation
  if (envName === 'prd') {
    const cautionBox = [
      '',
      '╭────────────────────────────────────────────────────────────╮',
      '│ 🚨 PRODUCTION DEPLOYMENT                                   │',
      '│                                                            │',
      '│  This is a production release.                             │',
      '│  Please review carefully before proceeding.                │',
      '│                                                            │',
      '╰────────────────────────────────────────────────────────────╯',
      '',
    ].join('\n');
    console.log(cautionBox);

    const readlineSync = require('readline-sync');
    const answer = readlineSync.question(
      'Are you sure you want to proceed? (yes/no): '
    );

    if (answer.toLowerCase() !== 'yes') {
      throw new Error('Deployment aborted by user.');
    }
    console.log('✓ Proceeding with deployment...');
  }
}

Key Points:

Account ID validation prevents deployment to wrong accounts
Requires user confirmation before production deployment
Visually clear box display
In the actual implementation, ANSI color codes are used to customize the display (red for errors, yellow for warnings, green for success messages) for better visibility in the terminal

Deployment Method

# Deploy to development environment
npm run stage:deploy:all --project=myproject --env=dev

# Deploy to production environment (with confirmation prompt)
npm run stage:deploy:all --project=myproject --env=prd

Pros and Cons of TypeScript Approach

Pros:

Type Safety: Detect configuration errors at compile time
IDE Support: Autocomplete and refactoring
Complex Logic: Easy parameter calculation and conditional branching
Reusability: Share common type definitions across multiple stacks
Version Control: Track parameter changes with Git

Cons:

Recompilation on Changes: Build required every time parameters change
Initial Setup: Type definitions and file structure preparation needed
Learning Cost: TypeScript knowledge required

Pattern 2: Defining Parameters in cdk.json

Parameter Definition in cdk.json

// cdk.json
{
  "app": "npx ts-node --prefer-ts-exts bin/cdk-parameters.ts",
  "context": {
    "dev": {
      "vpcConfig": {
        "createConfig": {
          "vpcName": "DevVPC",
          "cidr": "10.100.0.0/16",
          "maxAzs": 2,
          "natCount": 1,
          "enableDnsHostnames": true,
          "enableDnsSupport": true,
          "subnets": [
            {
              "subnetType": "PUBLIC",
              "name": "Public",
              "cidrMask": 24
            },
            {
              "subnetType": "PRIVATE_WITH_NAT",
              "name": "Private",
              "cidrMask": 24
            }
          ]
        }
      }
    },
    "stg": {
      "vpcConfig": {
        "createConfig": {
          "vpcName": "StgVPC",
          "cidr": "10.101.0.0/16",
          "maxAzs": 2,
          "natCount": 2
        }
      }
    },
    "prd": {
      "vpcConfig": {
        "createConfig": {
          "vpcName": "PrdVPC",
          "cidr": "10.0.0.0/16",
          "maxAzs": 3,
          "natCount": 3
        }
      }
    }
  }
}

Key Points:

Define environment-specific parameters in JSON
Use CDK's standard context section
Configuration changes possible without recompilation

Stack Using cdk.json Parameters

// lib/stacks/cdk-json-parameters-stack.ts
import * as cdk from 'aws-cdk-lib/core';
import { Construct } from 'constructs';
import { Environment } from 'lib/types';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import { pascalCase } from 'change-case-commonjs';

export interface StackProps extends cdk.StackProps {
  project: string;
  environment: Environment;
  isAutoDeleteObject: boolean;
}

export class CdkJsonParametersStack extends cdk.Stack {
  public readonly vpc: ec2.IVpc;

  constructor(scope: Construct, id: string, props: StackProps) {
    super(scope, id, props);

    // Get parameters from cdk.json
    const params = this.node.tryGetContext(props.environment) || {};
    const vpcConfig = params['vpcConfig'] || {};

    // Reference existing VPC
    if (vpcConfig['existingVpcId']) {
      this.vpc = ec2.Vpc.fromLookup(this, "VPC", {
        vpcId: vpcConfig['existingVpcId'],
      });
      return;
    }

    // Check for createConfig existence
    if (!vpcConfig['createConfig']) {
      throw new Error(
        'VPC createConfig is required in JSON parameters to create the VPC.'
      );
    }

    const createConfig = vpcConfig['createConfig'];

    // Subnet configuration mapping
    const subnets = createConfig['subnets'] || [
      {
        subnetType: 'PUBLIC',
        name: 'Public',
        cidrMask: 24,
      },
      {
        subnetType: 'PRIVATE_WITH_NAT',
        name: 'Private',
        cidrMask: 24,
      }
    ];

    // Create VPC
    const vpcNameSuffix = createConfig['vpcName'] ?? 'vpc';
    this.vpc = new ec2.Vpc(this, "VPC", {
      vpcName: `${pascalCase(props.project)}/${pascalCase(props.environment)}/${pascalCase(vpcNameSuffix)}`,
      ipAddresses: ec2.IpAddresses.cidr(
        createConfig['cidr'] || '10.1.0.0/16'
      ),
      maxAzs: createConfig['maxAzs'] || 3,
      natGateways: createConfig['natCount'] || 1,
      subnetConfiguration: subnets.map((subnet: any) => {
        // Convert string subnetType to ec2.SubnetType
        if (subnet['subnetType'] === 'PUBLIC') {
          return {
            subnetType: ec2.SubnetType.PUBLIC,
            name: subnet['name'] || 'Public',
            cidrMask: subnet['cidrMask'] || 24,
          };
        } else if (subnet['subnetType'] === 'PRIVATE_WITH_NAT') {
          return {
            subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
            name: subnet['name'] || 'Private',
            cidrMask: subnet['cidrMask'] || 24,
          };
        }
        return null;
      }).filter((config: any) => config !== null),
    });
  }
}

Key Points:

Retrieve values from cdk.json using this.node.tryGetContext()
Convert string-type parameters to TypeScript types
Default values allow operation with minimal parameters
Type checking performed at runtime

Pros and Cons of cdk.json Approach

Pros:

No Recompilation: Deploy immediately after parameter changes
CDK Standard: Standard CDK approach
External Tool Integration: Easy to read with JSON parsers
Low Learning Cost: Only JSON knowledge required
Dynamic Values: Retrieve and calculate values at runtime

Cons:

No Type Safety: Cannot detect configuration errors until runtime
Limited IDE Support: No autocomplete or refactoring
Complex Logic: Difficult to perform calculations or conditional branching
Error Handling: Runtime error handling required

Which Approach Should You Choose?

Approach Comparison Table

Aspect	TypeScript Approach	cdk.json Approach
Type Safety	✅ Compile-time type checking	❌ Cannot detect until runtime
IDE Support	✅ Autocomplete and refactoring	⚠️ Limited
Ease of Change	⚠️ Recompilation required	✅ No recompilation needed
Complex Logic	✅ Easy calculation and conditional branching	❌ Difficult
External Tool Integration	⚠️ Build required	✅ Easy with JSON parser
Learning Cost	⚠️ TypeScript knowledge required	✅ JSON only
Initial Setup	⚠️ Type definitions and file structure needed	✅ Simple
Version Control	Change history is clear	Change history is clear
Error Detection	✅ Compile-time	❌ Runtime
CDK Standard	⚠️ Custom approach	✅ CDK standard

Recommended Use Cases

TypeScript Approach Recommended

Large projects (many parameters and complex configurations)
When type safety is important
Team development (IDE support improves development efficiency)
Complex logic (parameter calculations and conditional branching)
Long-term operation (maintainability and readability focused)

cdk.json Approach Recommended

Small projects (simple configurations)
When rapid changes are needed
CDK beginners (limited TypeScript knowledge)
CI/CD integration (configuration changes from external tools)
Prototyping (rapid experimentation and validation)

Hybrid Approach

In production, combining both approaches can be effective.

Basic Configuration: Managed in cdk.json (environment name, region, etc.)
Complex Configuration: Managed in TypeScript (VPC configuration, security groups, etc.)
Sensitive Information: Retrieved from AWS Secrets Manager

Test Implementation

The same test patterns can be applied to both approaches.

Unit Tests

// test/unit/cdk-parameters-stack.test.ts
describe("CdkTSParametersStack Fine-grained Assertions", () => {
  let stackTemplate: Template;

  beforeAll(() => {
    const app = new cdk.App();
    const stack = new CdkTSParametersStack(app, "CdkParameters", {
      project: "TestProject",
      environment: Environment.TEST,
      env: { account: '123456789012', region: 'ap-northeast-1' },
      isAutoDeleteObject: true,
      terminationProtection: false,
      vpcConfig: {
        createConfig: {
          vpcName: "TestVPC",
          cidr: "10.1.0.0/16",
          maxAzs: 2,
          natCount: 1,
          subnets: [
            { subnetType: ec2.SubnetType.PUBLIC, name: 'Public', cidrMask: 24 },
            { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS, name: 'Private', cidrMask: 24 },
          ],
        },
      },
    });
    stackTemplate = Template.fromStack(stack);
  });

  test("should create 1 VPC", () => {
    stackTemplate.resourceCountIs("AWS::EC2::VPC", 1);
  });

  test("VPC should have correct CIDR block", () => {
    stackTemplate.hasResourceProperties("AWS::EC2::VPC", {
      CidrBlock: "10.1.0.0/16",
    });
  });
});

Snapshot Tests

// test/snapshot/snapshot.test.ts
describe("Stack Snapshot Tests", () => {
  const app = new cdk.App({ context: testContext });

  // Create all stacks first
  const stack = new CdkTSParametersStack(app, "CdkParameters", {
    project: projectName,
    environment: envName,
    env: defaultEnv,
    isAutoDeleteObject: true,
    terminationProtection: false,
    vpcConfig: envParams.vpcConfig,
  });

  const jsonParameterStack = new CdkJsonParametersStack(
    app, "CdkJsonParameters", {
    project: projectName,
    environment: envName,
    env: defaultEnv,
    isAutoDeleteObject: true,
    terminationProtection: false,
  });

  // Get templates after all stacks are created
  const stackTemplate = Template.fromStack(stack);
  const jsonParameterStackTemplate = Template.fromStack(jsonParameterStack);

  test("Complete CloudFormation template snapshot", () => {
    expect(stackTemplate.toJSON()).toMatchSnapshot();
    expect(jsonParameterStackTemplate.toJSON()).toMatchSnapshot();
  });
});

Key Points:

Create all stacks before calling Template.fromStack()
Use same test patterns for both approaches
Snapshot tests detect unintended changes

Deployment and Cleanup

Deployment

# Deploy TypeScript parameters version
npm run stage:deploy:all --project=myproject --env=dev

# Deploy cdk.json parameters version
npm run stage:deploy:all --project=myproject --env=dev

Cleanup

# Delete all resources
npm run stage:destroy:all --project=myproject --env=dev

Summary

In this exercise, we learned two major approaches for managing parameters in CDK.

What We Learned

TypeScript Approach: Development efficiency through type safety and IDE support
cdk.json Approach: Flexibility and rapid changes
Deployment Validation: Account ID checking and production environment confirmation
Test Strategy: Test patterns applicable to both approaches
Best Practices: Choosing based on project size

Best Practices

Leverage Type Definitions: Make full use of TypeScript's type system
Default Values: Set default values for non-required parameters
Implement Validation: Implement parameter validation before deployment
Documentation: Clearly document parameter meanings and constraints
Testing: Implement tests for parameter changes

Reference Resources

Let's continue learning practical AWS CDK patterns through the 100 drill exercises!
If you found this helpful, please ⭐ the repository!

📌 You can see the entire code in My GitHub Repository.

AWS CDK 100 Drill Exercises #004: NAT Instance V2 — Cost-Effective NAT with Automated Scheduling and Patch Management

TOMOAKI ishihara — Wed, 24 Dec 2025 15:24:21 +0000

Introduction

This is the fourth installment of "AWS CDK 100 Drill Exercises."

For more information about AWS CDK 100 Drill Exercises, please refer to this article.

In the previous article, we learned VPC basics and introduced a method to reduce NAT Gateways to a single instance for cost optimization in development environments. This time, we'll explain how to replace NAT Gateway with an EC2-based NAT instance for even greater cost savings.

Why NAT Instance?

Development and test environments often don't need to run 24/7. However, NAT Gateway uses a pay-as-you-go pricing model, incurring charges even during idle hours.

Cost Comparison (Tokyo Region):

Resource	Monthly Cost	Annual Cost	Features
NAT Gateway (1 instance)	~$44.64	~$535.68	24/7 operation, data transfer charges separate
NAT Instance (t4g.nano)	~$4.66	~$55.92	Schedulable start/stop
Savings Rate	90.8% reduction	90.8% reduction	-

Furthermore, when operating only during business hours (weekdays 9:00-18:00):

Resource	Monthly Cost	Annual Cost	Features
NAT Instance (business hours only)	~$1.84	~$22.08	9 hours on weekdays only
Savings Rate	96.4% reduction	96.4% reduction	-

💡 In development environments, you can save over $587.97 annually!

What You'll Learn

NAT Instance v2 implementation method
Automated start/stop scheduling with EventBridge
Static Elastic IP assignment to NAT Instance
Monitoring NAT Instance state changes and SNS notifications
Automated patch application using Systems Manager Patch Manager
Maintenance window configuration and operations
Trade-offs between NAT Gateway and NAT Instance

📁 Code Repository: All code examples for this exercise are available on GitHub.

Architecture Overview

The basic VPC configuration is the same as vpc-basics, with the following differences.

Key Changes

NAT Gateway → NAT Instance: Changed from managed NAT service to EC2-based NAT instance
EventBridge Schedule: Automated start/stop schedule configuration
Elastic IP Assignment: Assigned static IP address to NAT Instance
SNS Notification: Monitoring NAT Instance state changes
Patch Manager: Automated patch application via Systems Manager

Prerequisites

In addition to the prerequisites of vpc-basics, the following are required:

Basic understanding of EventBridge and SNS
Knowledge of EC2 instance types

NAT Instance v2 Implementation

1. Creating NAT Provider

In CDK v2, you can easily create a NAT instance using NatProvider.instanceV2().

import * as ec2 from 'aws-cdk-lib/aws-ec2';

// Creating NAT Instance Provider
const natProvider = ec2.NatProvider.instanceV2({
  instanceType: ec2.InstanceType.of(
    ec2.InstanceClass.T4G,  // ARM-based Graviton2
    ec2.InstanceSize.NANO   // Smallest size for cost optimization
  ),
  machineImage: ec2.MachineImage.latestAmazonLinux2023({
    edition: ec2.AmazonLinuxEdition.STANDARD,
    cpuType: ec2.AmazonLinuxCpuType.ARM_64,  // For Graviton2
  }),
  defaultAllowedTraffic: ec2.NatTrafficDirection.OUTBOUND_ONLY,
});

// Applying NAT Provider to VPC
const vpc = new ec2.Vpc(this, 'VpcNatInstanceV2', {
  vpcName,
  ipAddresses: ec2.IpAddresses.cidr('10.1.0.0/16'),
  maxAzs: 3,
  natGateways: 3,  // One per AZ
  natGatewayProvider: natProvider,  // Using NAT Instance
  subnetConfiguration: [
    // Subnet configuration same as before
    // ...
  ],
});

Why t4g.nano?

※ Tokyo Region pricing

Instance Type	vCPU	Memory	Price/hour (Tokyo)	Monthly	Use Case
t4g.nano	2	0.5 GB	$0.0054	~$3.94	Small traffic for development environments
t4g.micro	2	1 GB	$0.0108	~$7.88	Medium traffic
t3.nano	2	0.5 GB	$0.0068	~$4.96	When x86 is required

💡 Benefits of Graviton2 (ARM):

Approximately 20% cheaper than equivalent x86 instances
Superior cost-performance ratio
Fully supported by Amazon Linux 2023

2. Allowing Traffic from VPC to NAT Instance

NAT Instance needs to accept all traffic from within the VPC.

// Allow all traffic from VPC CIDR
(natProvider as ec2.NatInstanceProviderV2).connections.allowFrom(
  ec2.Peer.ipv4(vpc.vpcCidrBlock),
  ec2.Port.allTraffic(),
  'Allow all traffic from VPC',
);

This allows resources in private subnets to access the internet via NAT Instance.

Automated Start/Stop with EventBridge

You can further reduce costs by stopping NAT Instance outside business hours.

1. Creating IAM Role

import * as iam from 'aws-cdk-lib/aws-iam';

const natInstanceScheduleRole = new iam.Role(this, 'NatInstanceScheduleRole', {
  roleName: [props.project, props.environment, 'NatInstanceSchedule'].join('-'),
  assumedBy: new iam.ServicePrincipal('events.amazonaws.com'),
  managedPolicies: [
    iam.ManagedPolicy.fromAwsManagedPolicyName(
      'service-role/AmazonSSMAutomationRole'
    ),
  ],
});

2. Creating Schedule Rules

import * as events from 'aws-cdk-lib/aws-events';

const region = cdk.Stack.of(this).region;

// Schedule configuration (UTC time)
const startCronSchedule = 'cron(0 0 ? * * *)'; // 00:00 UTC (JST 09:00)
const stopCronSchedule = 'cron(0 9 ? * * *)';  // 09:00 UTC (JST 18:00)

const natInstanceIds: string[] = [];

natProvider.configuredGateways.forEach((nat, index) => {
  natInstanceIds.push(nat.gatewayId);

  // Start schedule
  new events.CfnRule(this, `EC2StartRule${index + 1}`, {
    name: [props.project, props.environment, 'NATStartRule', nat.gatewayId].join('-'),
    description: `${nat.gatewayId} ${startCronSchedule} Start`,
    scheduleExpression: startCronSchedule,
    targets: [{
      arn: `arn:aws:ssm:${region}::automation-definition/AWS-StartEC2Instance:$DEFAULT`,
      id: 'TargetEC2Instance1',
      input: `{"InstanceId": ["${nat.gatewayId}"]}`,
      roleArn: natInstanceScheduleRole.roleArn,
    }],
  });

  // Stop schedule
  new events.CfnRule(this, `EC2StopRule${index + 1}`, {
    name: [props.project, props.environment, 'NATStopRule', nat.gatewayId].join('-'),
    description: `${nat.gatewayId} ${stopCronSchedule} Stop`,
    scheduleExpression: stopCronSchedule,
    targets: [{
      arn: `arn:aws:ssm:${region}::automation-definition/AWS-StopEC2Instance:$DEFAULT`,
      id: 'TargetEC2Instance1',
      input: `{"InstanceId": ["${nat.gatewayId}"]}`,
      roleArn: natInstanceScheduleRole.roleArn,
    }],
  });
});

Understanding Cron Expressions

cron(minute hour day month day-of-week year)

Examples:
cron(0 0 ? * * *)     # Every day at 00:00 UTC
cron(0 9 ? * * *)     # Every day at 09:00 UTC
cron(0 0 ? * MON-FRI *) # Weekdays only at 00:00 UTC
cron(0 0 1 * ? *)     # 1st day of every month at 00:00 UTC

💡 Time Zone Notes:

EventBridge cron uses UTC time
JST = UTC + 9 hours
JST 09:00 = UTC 00:00
JST 18:00 = UTC 09:00

Schedule examples by environment:

Environment	Operating Hours (JST)	Start (UTC)	Stop (UTC)	Monthly Cost
Development	Weekdays 9:00-18:00	`cron(0 0 ? * MON-FRI *)`	`cron(0 9 ? * MON-FRI *)`	~$1.07 (t4g.nano)
Test	Daily 9:00-18:00	`cron(0 0 ? * * *)`	`cron(0 9 ? * * *)`	~$3.89 (t4g.nano)
Staging	24/7	Recommend NAT Gateway same as production	Recommend NAT Gateway same as production	~$44.64
Production	24/7	Recommend NAT Gateway	Recommend NAT Gateway	~$44.64

Static Elastic IP Assignment

By assigning a static Elastic IP to NAT Instance, you can fix the source IP address for outbound communications.

const outboundEips: ec2.CfnEIP[] = [];

natProvider.configuredGateways.forEach((nat, index) => {
  // Creating Elastic IP
  const eip = new ec2.CfnEIP(this, `NatEip${index + 1}`, {
    tags: [{
      key: "Name",
      value: `${props.project}/${props.environment}/NatEIP${index + 1}`
    }],
  });
  eip.applyRemovalPolicy(cdk.RemovalPolicy.DESTROY);

  // Associate Elastic IP with NAT Instance
  new ec2.CfnEIPAssociation(this, `NatEipAssociation${index + 1}`, {
    allocationId: eip.attrAllocationId,
    instanceId: nat.gatewayId,
  });

  // Output as CloudFormation Output
  new cdk.CfnOutput(this, `NatInstance${index + 1}PublicIP`, {
    value: eip.ref,
    description: `Public IP address of NAT Instance ${index + 1}`,
  });

  outboundEips.push(eip);
});

Why Static IP is Needed?

External Service Whitelisting
- Many third-party APIs require IP whitelisting
- Database access control via security groups
- VPN connection configurations
Log Analysis and Troubleshooting
- Tracking outbound traffic with fixed source IP
- Easier identification of access source
Compliance Requirements
- Some industries require tracking of outbound communication sources
- Auditing and logging requirements

Monitoring NAT Instance State Changes

Set up SNS notifications to receive alerts when NAT Instance state changes.

1. Creating SNS Topic

import * as sns from 'aws-cdk-lib/aws-sns';
import * as subscriptions from 'aws-cdk-lib/aws-sns-subscriptions';

// Create SNS Topic
const natInstanceTopic = new sns.Topic(this, 'NatInstanceTopic', {
  topicName: [props.project, props.environment, 'NatInstance'].join('-'),
  displayName: 'NAT Instance State Change Notifications',
});

// Email subscription (optional)
if (props.notificationEmail) {
  natInstanceTopic.addSubscription(
    new subscriptions.EmailSubscription(props.notificationEmail)
  );
}

2. Creating EventBridge Rule

import * as events from 'aws-cdk-lib/aws-events';
import * as targets from 'aws-cdk-lib/aws-events-targets';

// Rule for NAT Instance state change
const natInstanceStateRule = new events.Rule(this, 'NatInstanceStateRule', {
  ruleName: [props.project, props.environment, 'NatInstanceState'].join('-'),
  description: 'Notify when NAT Instance state changes',
  eventPattern: {
    source: ['aws.ec2'],
    detailType: ['EC2 Instance State-change Notification'],
    detail: {
      'instance-id': natInstanceIds,
      'state': ['pending', 'running', 'stopping', 'stopped', 'terminated'],
    },
  },
});

// Add SNS topic as target
natInstanceStateRule.addTarget(new targets.SnsTopic(natInstanceTopic, {
  message: events.RuleTargetInput.fromObject({
    subject: `[${props.project.toUpperCase()}-${props.environment.toUpperCase()}] NAT Instance State Change`,
    instanceId: events.EventField.fromPath('$.detail.instance-id'),
    state: events.EventField.fromPath('$.detail.state'),
    time: events.EventField.fromPath('$.time'),
  }),
}));

3. Setting Up Email Notifications (Optional)

When an email address is provided, you'll receive notifications like:

{
  "subject": "[YOURPROJECT-DEV] NAT Instance State Change",
  "instanceId": "i-0123456789abcdef0",
  "state": "running",
  "time": "2024-01-15T12:00:00Z"
}

Notified Events

pending: Instance is starting
running: Instance is running
stopping: Instance is stopping
stopped: Instance is stopped
terminated: Instance is terminated

💡 Tips:

Set up Slack/Teams integration via SNS for team notifications
Log important events to CloudWatch Logs
Create dashboards combining CloudWatch metrics

NAT Gateway vs NAT Instance: Trade-offs

Feature Comparison Table

Feature	NAT Gateway	NAT Instance
Availability	✅ Managed by AWS	Depends on instance type
Performance	✅ Up to 100 Gbps	Depends on instance type
Cost (24/7)	~$44.64/month	✅ ~$3.94/month (t4g.nano)
Scheduled Control	❌ Not available	✅ EventBridge schedule
Patch Management	✅ Not required (Managed)	Required (SSM Patch Manager)
Scalability	✅ Automatic	Manual (instance type change)
Monitoring	CloudWatch metrics	CloudWatch + OS metrics
Single Point of Failure	✅ No	Yes (single instance)

Recommended Use Cases

Use Cases for NAT Gateway

Production Environments
- 24/7 operation required
- High availability is critical
- Handling large traffic volume
High Performance Requirements
- Burst traffic handling needed
- Bandwidth requirements over 5 Gbps
- Multiple concurrent connections
Zero Operational Overhead
- No infrastructure management desired
- Fully managed service preferred
- No patching management needed

Use Cases for NAT Instance

Development/Test Environments
- Traffic only during business hours
- Cost optimization prioritized
- Downtime acceptable
Cost Reduction Priority
- Small-scale traffic
- Scheduled operation possible
- Operational overhead acceptable
Custom Network Control
- Custom security groups needed
- Traffic filtering required
- Specific logging requirements

Performance Comparison

Metric	NAT Gateway	NAT Instance (t4g.nano)	NAT Instance (t4g.micro)
Bandwidth	Up to 100 Gbps	Up to 5 Gbps	Up to 5 Gbps
Max Connections	55,000~440,000	~55,000	~55,000
Bandwidth	10 Gbps	~ 5 Gbps	~ 5 Gbps
Latency	Low	Low	Low

💡 Tips: For development environments with low traffic, t4g.nano is sufficient. For production use, consider t4g.medium or larger.

Cost Analysis

Detailed Cost Comparison (Tokyo Region)

1. NAT Gateway (Traditional)

Base Charge:
- $0.062/hour × 730 hours = $45.26/month

Data Processing:
- $0.062/GB
- Example: 100 GB/month = $6.20

Total: ~$51.46/month per AZ
3 AZs: ~$154.38/month

2. NAT Instance (t4g.nano) - 24/7 Operation

Instance Charge:
- $0.0054/hour × 730 hours = $3.94/month

Elastic IP:
- While stopped: $0.005/hour × 730 hours = $3.65/month

Data Transfer:
- Same as NAT Gateway ($0.062/GB)
- Example: 100 GB/month = $6.20

Total: ~$13.79/month per instance
3 instances: ~$41.37/month

Savings: $154.38 - $41.37 = $113.01/month (73% reduction)
Annual savings: ~$1,356

3. NAT Instance - Business Hours Only (Weekdays 9 hours)

Instance Charge:
- Operating hours: 9 hours × 5 days × 4.33 weeks = ~195 hours/month
- $0.0054/hour × 195 hours = $1.05/month

Elastic IP:
- While stopped: $0.005/hour × 730 hours = $3.65/month

Data Transfer:
- Same as NAT Gateway ($0.062/GB)
- Example: 100 GB/month = $6.20

Total: ~$10.9/month per instance
3 instances: ~$32.7/month
Savings: $154.38 - $32.7 = $121.68/month (79% reduction)
Annual savings: ~$1,460

💡 Important Note: For scheduled operation, also calculate Elastic IP charges during stop periods. In many cases, 24/7 operation may be more cost-effective.

Recommended Configuration and Costs by Environment

Environment	Configuration	Monthly Cost	Reasoning
Development	NAT Instance × 1 (t4g.nano, 9/7)	~$1.84	Cost priority, downtime acceptable
Test	NAT Instance × 1 (t4g.micro, 9/7)	~$1.84	Cost and performance balance
Staging	NAT Gateway × 1	~$44.64	Production equivalent
Production	NAT Gateway × 3	~$154	High availability critical

Automating Patch Application

Use Systems Manager Patch Manager to automatically apply security patches to NAT Instance.

1. Granting SSM Permissions to NAT Instance

NAT Instance requires permissions to use Systems Manager.

import * as iam from 'aws-cdk-lib/aws-iam';

// Add SSM managed policy to NAT Instance role
(natProvider as ec2.NatInstanceProviderV2).connections.allowFrom(
  ec2.Peer.ipv4(vpc.vpcCidrBlock),
  ec2.Port.allTraffic(),
  'Allow all traffic from VPC',
);

// Get NAT Instance role
const natInstanceRole = (natProvider as ec2.NatInstanceProviderV2).securityGroup.node.tryFindChild('InstanceRole') as iam.Role;

// Add SSM managed policy
natInstanceRole.addManagedPolicy(
  iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore')
);

This allows NAT Instance to:

Report to Systems Manager Fleet Manager
Execute commands via Session Manager
Execute Patch Manager tasks

2. Creating Patch Baseline

import * as ssm from 'aws-cdk-lib/aws-ssm';

// Create patch baseline for Amazon Linux 2023
const patchBaseline = new ssm.CfnPatchBaseline(this, 'NatInstancePatchBaseline', {
  name: `${props.project}-${props.environment}-AL2023-PatchBaseline`,
  description: 'Patch baseline for NAT Instance (Amazon Linux 2023)',
  operatingSystem: 'AMAZON_LINUX_2023',
  approvalRules: {
    patchRules: [
      {
        // Security patches
        patchFilterGroup: {
          patchFilters: [
            {
              key: 'CLASSIFICATION',
              values: ['Security', 'Bugfix'],
            },
            {
              key: 'SEVERITY',
              values: ['Critical', 'Important'],
            },
          ],
        },
        approveAfterDays: 7,  // Apply 7 days after release
        complianceLevel: 'HIGH',
        enableNonSecurity: false,
      },
    ],
  },
  // Tag-based target specification
  patchGroups: [`/NatInstance/${props.project}/${props.environment}`],
});

💡 Key Points:

approveAfterDays: 7: Apply only tested patches
SEVERITY: Critical, Important: Apply high-priority patches first

3. Configuring Maintenance Window

3.1. IAM Role for Maintenance Window

const maintenanceWindowRole = new iam.Role(this, 'MaintenanceWindowRole', {
  roleName: `${props.project}-${props.environment}-MaintenanceWindowRole`,
  assumedBy: new iam.CompositePrincipal(
    new iam.ServicePrincipal('ssm.amazonaws.com'),
    new iam.ServicePrincipal('ec2.amazonaws.com'),
  ),
  managedPolicies: [
    iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AmazonSSMMaintenanceWindowRole'),
    iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),
  ],
});

// Add PassRole permission
maintenanceWindowRole.addToPolicy(new iam.PolicyStatement({
  effect: iam.Effect.ALLOW,
  actions: ['iam:PassRole'],
  resources: [natInstanceRole.roleArn],
  conditions: {
    StringEquals: {
      'iam:PassedToService': 'ssm.amazonaws.com',
    },
  },
}));

3.2. Creating Maintenance Window

// Maintenance window: Every Sunday 12:00 JST (03:00 UTC)
const maintenanceWindow = new ssm.CfnMaintenanceWindow(this, 'NatInstanceMaintenanceWindow', {
  name: `${props.project}-${props.environment}-NatInstance-PatchWindow`,
  description: 'Weekly maintenance window for NAT Instance patches',
  schedule: 'cron(0 3 ? * SUN *)',  // Every Sunday 03:00 UTC (12:00 JST)
  duration: 4,  // 4 hours
  cutoff: 1,    // Stop 1 hour before end
  allowUnassociatedTargets: false,
  scheduleTimezone: 'UTC',
});

3.3. Configuring Patch Task

// Maintenance window target
const maintenanceWindowTarget = new ssm.CfnMaintenanceWindowTarget(this, 'NatInstanceTarget', {
  windowId: maintenanceWindow.ref,
  resourceType: 'INSTANCE',
  targets: [
    {
      key: 'tag:Patch Group',
      values: [`/NatInstance/${props.project}/${props.environment}`],
    },
  ],
});

// Patch task
new ssm.CfnMaintenanceWindowTask(this, 'PatchTask', {
  windowId: maintenanceWindow.ref,
  taskType: 'RUN_COMMAND',
  taskArn: 'AWS-RunPatchBaseline',
  targets: [
    {
      key: 'WindowTargetIds',
      values: [maintenanceWindowTarget.ref],
    },
  ],
  serviceRoleArn: maintenanceWindowRole.roleArn,
  priority: 1,
  maxConcurrency: '1',  // Sequential execution one at a time
  maxErrors: '1',
  taskInvocationParameters: {
    maintenanceWindowRunCommandParameters: {
      parameters: {
        Operation: ['Install'],
        RebootOption: ['RebootIfNeeded'],
      },
      timeoutSeconds: 3600,  // 1 hour timeout
      cloudWatchOutputConfig: {
        cloudWatchLogGroupName: `/aws/ssm/${props.project}/${props.environment}/patch`,
        cloudWatchOutputEnabled: true,
      },
    },
  },
});

💡 Important Parameters:

maxConcurrency: '1': Apply sequentially one instance at a time (maintain availability)
RebootOption: 'RebootIfNeeded': Auto-reboot when kernel patch requires it
timeoutSeconds: 3600: Allow sufficient time for patch application

5. Monitoring Patch Application Status

import * as cloudwatch from 'aws-cdk-lib/aws-cloudwatch';
import * as cloudwatchActions from 'aws-cdk-lib/aws-cloudwatch-actions';

// SNS topic for patch notifications
const patchNotificationTopic = new sns.Topic(this, 'PatchNotificationTopic', {
  topicName: `${props.project}-${props.environment}-PatchNotification`,
  displayName: 'NAT Instance Patch Status Notifications',
});

// Email subscription (optional)
if (props.notificationEmail) {
  patchNotificationTopic.addSubscription(
    new subscriptions.EmailSubscription(props.notificationEmail)
  );
}

// EventBridge rule for patch completion
const patchCompletionRule = new events.Rule(this, 'PatchCompletionRule', {
  ruleName: `${props.project}-${props.environment}-NatInstancePatchCompletion`,
  description: 'Notify when NAT Instance patch completes',
  eventPattern: {
    source: ['aws.ssm'],
    detailType: ['EC2 Command Status-change Notification'],
    detail: {
      'status': ['Success', 'Failed', 'TimedOut'],
      'document-name': ['AWS-RunPatchBaseline'],
    },
  },
});

patchCompletionRule.addTarget(new targets.SnsTopic(patchNotificationTopic, {
  message: events.RuleTargetInput.fromObject({
    default: events.EventField.fromPath('$.detail'),
    subject: `[${props.project.toUpperCase()}-${props.environment.toUpperCase()}] NAT Instance Patch Status`,
    message: {
      summary: `Patch operation ${events.EventField.fromPath('$.detail.status')}`,
      details: {
        commandId: events.EventField.fromPath('$.detail.command-id'),
        instanceId: events.EventField.fromPath('$.detail.instance-id'),
        status: events.EventField.fromPath('$.detail.status'),
        documentName: events.EventField.fromPath('$.detail.document-name'),
      },
    },
  }),
}));

// Compliance violation alarm
const complianceMetric = new cloudwatch.Metric({
  namespace: 'AWS/SSM',
  metricName: 'PatchComplianceNonCompliantCount',
  dimensionsMap: {
    PatchGroup: `/NatInstance/${props.project}/${props.environment}`,
  },
  statistic: 'Average',
  period: cdk.Duration.hours(1),
});

new cloudwatch.Alarm(this, 'PatchComplianceAlarm', {
  alarmName: `${props.project}-${props.environment}-NatInstancePatchNonCompliant`,
  metric: complianceMetric,
  threshold: 0,
  evaluationPeriods: 2,
  comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_THRESHOLD,
  treatMissingData: cloudwatch.TreatMissingData.NOT_BREACHING,
}).addAlarmAction(new cloudwatchActions.SnsAction(patchNotificationTopic));

Key Points for Patch Management

Item	Setting	Reason
Execution Timing	Every Sunday 3:00 UTC (12:00 JST)	Low traffic period
Window Duration	4 hours	Accommodate sequential application to multiple instances
Concurrency	1 instance	Sequential execution to maintain availability
Reboot	As needed	For kernel patches etc.
Approval Period	7 days	Apply only tested patches
Target Patches	Critical/Important security patches	Prioritize high-severity

Patch Application Flow

1. Every Sunday 12:00 JST
   ↓
2. Maintenance window starts
   ↓
3. Apply patches to NAT Instance #1
   ↓ (Reboot if needed)
   ↓
4. Apply patches to NAT Instance #2
   ↓ (Reboot if needed)
   ↓
5. Apply patches to NAT Instance #3
   ↓ (Reboot if needed)
   ↓
6. Completion notification (via SNS)

💡 For development environments: With single NAT Instance configuration, internet connection is temporarily lost during patch application (especially during reboot). Recommend setting maintenance window outside business hours.

Best Practices

1. Security

// ✅ Disable source/destination check for NAT Instance
// (Automatically set by NatProvider.instanceV2())

// ✅ Restrict traffic with security groups
(natProvider as ec2.NatInstanceProviderV2).connections.allowFrom(
  ec2.Peer.ipv4(vpc.vpcCidrBlock),
  ec2.Port.allTraffic(),
  'Allow all traffic from VPC',
);

// ✅ Access via Systems Manager Session Manager
// (Disable public SSH access)

2. Monitoring and Alerts

// CloudWatch alarm configuration example
import * as cloudwatch from 'aws-cdk-lib/aws-cloudwatch';
import * as actions from 'aws-cdk-lib/aws-cloudwatch-actions';

const cpuAlarm = new cloudwatch.Alarm(this, 'NatInstanceCpuAlarm', {
  metric: new cloudwatch.Metric({
    namespace: 'AWS/EC2',
    metricName: 'CPUUtilization',
    dimensionsMap: {
      InstanceId: natInstanceId,
    },
    statistic: 'Average',
    period: cdk.Duration.minutes(5),
  }),
  threshold: 80,
  evaluationPeriods: 2,
  alarmDescription: 'NAT Instance CPU utilization is too high',
});

cpuAlarm.addAlarmAction(new actions.SnsAction(snsTopic));

// Patch compliance alarm
const complianceAlarm = new cloudwatch.Alarm(this, 'PatchComplianceAlarm', {
  metric: complianceMetric,
  threshold: 0,
  evaluationPeriods: 2,
  comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_THRESHOLD,
  alarmDescription: 'NAT Instance has missing security patches',
});

complianceAlarm.addAlarmAction(new actions.SnsAction(patchNotificationTopic));

3. Optimal Availability for Development Environments

In this architecture, we configured 3 NAT instances as a high-availability example, but for development environments, a single NAT instance is often sufficient. In that case, adjust the natGateways count.

// Deploy NAT Instance to multiple AZs
const vpc = new ec2.Vpc(this, 'VpcNatInstanceV2', {
  natGateways: 1,  // Only 1 instance
  natGatewayProvider: natProvider,
});

Cost becomes:

3 instances: $9.30/month
1 instance: $3.10/month

Troubleshooting

Common Issues and Solutions

1. Cannot Access Internet from Private Subnet After NAT Instance Stops

Cause: Stopped by schedule or manually stopped

Solution:

# Manually start NAT Instance
aws ec2 start-instances --instance-ids i-xxxxx

# Or temporarily disable schedule
aws events disable-rule --name YourProject-dev-NATStopRule-i-xxxxx

2. Instance Not Showing in Systems Manager

Cause: IAM role missing AmazonSSMManagedInstanceCore policy

Solution:

# Check in Fleet Manager
aws ssm describe-instance-information \
  --query 'InstanceInformationList[].[InstanceId,PingStatus,PlatformName]' \
  --output table

# If instance not shown, check IAM role
aws iam list-attached-role-policies --role-name <NAT-Instance-Role-Name>

💡 NAT Instance IAM role requires the following policies:

AmazonSSMManagedInstanceCore (For Systems Manager management)

3. Patch Application Fails

Cause: Maintenance window IAM role missing iam:PassRole permission

Solution:

Check error in CloudTrail logs.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=SendCommand \
  --max-results 5

If error is InvalidDocument: document hash and hash type must both be present or none, remove documentHashType parameter (not needed for AWS managed documents).

4. Poor Performance

Cause: Instance type is too small

Solution: Change to larger instance type

instanceType: ec2.InstanceType.of(
  ec2.InstanceClass.T4G,
  ec2.InstanceSize.MICRO,  // nano → micro
),

5. Unexpected Shutdown

Cause: Need to check CloudWatch Logs

Solution:

# Check logs in Systems Manager
aws logs filter-log-events \
  --log-group-name /aws/ssm/automation \
  --filter-pattern "i-xxxxx"

# Check EC2 instance status history
aws ec2 describe-instance-status \
  --instance-ids i-xxxxx \
  --include-all-instances

Troubleshooting Tips

Utilize CloudTrail: Analyze API call failure reasons in detail
Validate IAM permissions: Correctly configure conditional policies for iam:PassRole
Systems Manager logs: Check detailed execution logs for patch application
EventBridge metrics: Monitor schedule rule execution status

Deployment and Cleanup

Deployment

# Install dependencies
cd infrastructure/cdk-workspaces/workspaces/vpc-natinstance-v2
npm install

# Bootstrap CDK (first time only)
cdk bootstrap

# Deploy
cdk deploy "**" --project=YourProject --env=dev

Cleanup

# Delete stack
cdk destroy "**" --project=YourProject --env=dev

# Skip confirmation prompt
cdk destroy "**" --project=YourProject --env=dev --force

⚠️ Notes:

Elastic IPs are automatically released
Flow logs in S3 bucket are auto-deleted due to autoDeleteObjects: true
For production environments, use removalPolicy: cdk.RemovalPolicy.RETAIN

Summary

NAT Instance is an excellent alternative to NAT Gateway. Especially for development environments, it offers the following benefits:

Benefits:

Significant cost savings: Save over $400 annually
Schedule management: Auto-stop outside business hours
Flexible control: Security groups and Network ACLs
Monitoring and alerts: CloudWatch and EventBridge integration

Drawbacks (Considerations):

Single point of failure (for single instance)
Performance limitations (depends on instance type)
Operational management required (patching, monitoring)
Additional cost for high availability configuration

Recommendations

Development/Test environments: Use NAT Instance for cost optimization
Production environments: Use NAT Gateway for availability
Hybrid configuration: Choose optimal configuration per environment

References

Let's continue learning practical AWS CDK patterns through the 100 drill exercises!
If you found this helpful, please ⭐ the repository!

📌 You can see the entire code in My GitHub Repository.

AWS CDK 100 Drill Exercises #003: VPC Basics — From Network Configuration to Security

TOMOAKI ishihara — Sun, 21 Dec 2025 08:15:58 +0000

Introduction

This is the third installment of the "AWS CDK 100 Drill Exercises" series.

For an overview of the AWS CDK 100 Drill Exercises, please refer to this article.

Following S3 Fundamentals in Exercise #001 and IAM Basics in Exercise #002, we'll tackle Amazon Virtual Private Cloud (VPC). VPC is the foundation of AWS networking and is essential for securely isolating resources and controlling communication.

Why VPC?

Networking Foundation: Many AWS resources are deployed within a VPC
Security Layer: Implements security controls at the network level
Production Necessity: Almost all production environments require VPC
CDK Integration: Understanding how CDK abstracts VPC resources
Best Practices: Learning proper network design from the start

What You'll Learn

Two approaches to creating VPCs with CDK (default and custom)
Subnet design and CIDR block calculations
Differences between public/private subnets
Roles of NAT Gateway and Internet Gateway
Traffic monitoring with VPC Flow Logs
VPC Endpoint implementation (Gateway/Interface)
Secure SSH access via EC2 Instance Connect Endpoint
Security group cross-referencing and avoiding circular dependencies

📁 Code Repository: All code examples for this exercise are available on GitHub.

Architecture Overview

Here's what we'll build in this exercise:

We'll implement two patterns:

Default VPC: Created with CDK default settings
Custom VPC: Created with custom configurations

1. Default VPC (CDKDefault)

VPC created with CDK's default settings
Fully functional VPC with minimal code

2. Custom VPC (CustomVPC)

VPC with custom configuration
- Up to 3 Availability Zones (varies by region)
- 6 types of subnets (External, Management, Internal, Application, Isolated, TransitGateway)
- Custom CIDR blocks
- Single NAT Gateway (cost optimization)
VPC Flow Logs implementation
- All traffic logged to S3
- Rejected traffic logged to CloudWatch Logs
VPC Endpoints
- Gateway Endpoints (S3, DynamoDB)
- Interface Endpoints (Systems Manager)
EC2 Instance Connect Endpoint
- Secure SSH access without going through the internet
- Security group cross-referencing

Prerequisites

To proceed with this exercise, you'll need:

AWS CLI v2 installed and configured
Node.js 20+
AWS CDK CLI (npm install -g aws-cdk)
Basic knowledge of TypeScript
AWS Account (can be done with Free Tier)
Basic understanding of VPC concepts (CIDR, subnets, routing)

Project Directory Structure

vpc-basics/
├── bin/
│   └── vpc-basics.ts                    # Application entry point
├── lib/
│   └── stacks/
│       ├── vpc-cdkdefault-stack.ts      # CDK Default VPC Creation Stack
│       └── vpc-basics-stack.ts          # Custom VPC stack definition
├── test/
│   ├── compliance/
│   │   └── cdk-nag.test.ts              # CDK Nag compliance tests
│   ├── snapshot/
│   │   └── snapshot.test.ts             # Snapshot tests
│   └── unit/
│       ├── vpc-cdkdefault.test.ts       # Unit tests
│       └── vpc-basics.test.ts           # Unit tests
├── cdk.json
├── package.json
└── tsconfig.json

Pattern 1: Understanding CDK Default VPC

This is the simplest VPC creation. CDK automatically handles all configurations.

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

export class VpcCDKDefaultStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Create VPC with CDK default settings
    new ec2.Vpc(this, 'CDKDefault', {});
  }
}

Default Configuration Details

What CDK automatically configures:

CIDR Block: 10.0.0.0/16 (65,536 IP addresses)
Availability Zones: Available AZs in the region (up to 3)
Subnet Configuration:
- Public Subnet: One per AZ
- Private Subnet: One per AZ
NAT Gateway: One per AZ (high availability configuration)
Internet Gateway: One
Route Tables: Automatically configured

Generated resources:

CDKDefault VPC (10.0.0.0/16)
├── AZ-1
│   ├── Public Subnet (10.0.0.0/19)    - 8,192 IPs
│   ├── Private Subnet (10.0.96.0/19)  - 8,192 IPs
│   └── NAT Gateway
├── AZ-2
│   ├── Public Subnet (10.0.32.0/19)   - 8,192 IPs
│   ├── Private Subnet (10.0.128.0/19) - 8,192 IPs
│   └── NAT Gateway
├── AZ-3
│   ├── Public Subnet (10.0.64.0/19)   - 8,192 IPs
│   ├── Private Subnet (10.0.160.0/19) - 8,192 IPs
│   └── NAT Gateway
└── Internet Gateway

Pros and Cons of Default VPC

Pros:

Minimal code
Production-ready configuration
High availability (multiple AZs, multiple NAT Gateways)
Follows best practices

Cons:

High cost (multiple NAT Gateways)
No CIDR range customization
Fixed number of subnets

💡 For development environments, we recommend using a custom VPC for cost reduction.

Pattern 2: Creating a Custom VPC

In real projects, you'll create VPCs tailored to requirements.

import { pascalCase } from "change-case-commonjs";

const vpcName = [
  pascalCase(props.project),         // Project name
  pascalCase(props.environment),     // Environment identifier (dev/test/prod)
  'CustomVPC',                 // Purpose
]
  .join('/');

const customVpc = new ec2.Vpc(this, 'CustomVPC', {
  vpcName,
  ipAddresses: ec2.IpAddresses.cidr('10.1.0.0/16'),
  maxAzs: 3,              // Use up to 3 AZs
  natGateways: 1,         // Only 1 NAT Gateway (cost optimization)
  subnetConfiguration: [
    {
      cidrMask: 26,       // 64 IPs per AZ (/26 = 2^(32-26) = 64)
      name: 'External',
      subnetType: ec2.SubnetType.PUBLIC,
    },
    {
      cidrMask: 27,       // 32 IPs per AZ (/27 = 2^(32-27) = 32)
      name: 'Management',
      subnetType: ec2.SubnetType.PUBLIC,
    },
    {
      cidrMask: 22,       // 1024 IPs per AZ (/22 = 2^(32-22) = 1024)
      name: 'Internal',
      subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
    },
    {
      cidrMask: 22,       // 1024 IPs per AZ
      name: 'Application',
      subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
    },
    {
      cidrMask: 24,       // 256 IPs per AZ (/24 = 2^(32-24) = 256)
      name: 'Isolated',
      subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
    },
    {
      cidrMask: 28,       // 16 IPs per AZ (/28 = 2^(32-28) = 16)
      name: 'TransitGateway',
      subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
    }
  ],
});

Understanding CIDR Calculations

CIDR (Classless Inter-Domain Routing) defines IP address ranges.

The basic calculation formula:

Available IP Addresses = 2^(32 - CIDR mask)

/16 = 2^(32-16) = 2^16 = 65,536 IPs
/22 = 2^(32-22) = 2^10 = 1,024 IPs
/24 = 2^(32-24) = 2^8  = 256 IPs
/26 = 2^(32-26) = 2^6  = 64 IPs
/27 = 2^(32-27) = 2^5  = 32 IPs
/28 = 2^(32-28) = 2^4  = 16 IPs

For each subnet, AWS reserves 5 IPv4 addresses. (Documentation here)

.0: Network address
.1: VPC router
.2: DNS
.3: Reserved for future use
.255: Broadcast (not used in VPC but reserved)

The actual usable IPs are calculated value - 5.

Understanding Subnet Types

Type	Description	Routing	Use Cases
`PUBLIC`	Route to Internet Gateway	Internet via IGW	Load balancers, NAT Gateway, Bastion
`PRIVATE_WITH_EGRESS`	Route to NAT Gateway	Outbound only via NAT	Application servers, VPC Endpoints
`PRIVATE_ISOLATED`	No route to internet	VPC only	Databases, Transit Gateway attachments

Subnet Configuration Design

CustomVPC (10.1.0.0/16) - 65,536 IPs
├── AZ-1 (ap-northeast-1a)
│   ├── ExternalSubnet-1 (10.1.0.0/26)           - 64 IPs (59 usable)
│   ├── ManagementSubnet-1 (10.1.0.64/27)        - 32 IPs (27 usable)
│   ├── InternalSubnet-1 (10.1.0.128/22)         - 1,024 IPs (1,019 usable)
│   ├── ApplicationSubnet-1 (10.1.4.128/22)      - 1,024 IPs (1,019 usable)
│   ├── IsolatedSubnet-1 (10.1.8.128/24)         - 256 IPs (251 usable)
│   └── TransitGatewaySubnet-1 (10.1.9.0/28)     - 16 IPs (11 usable)
├── AZ-2 (ap-northeast-1c)
│   ├── ExternalSubnet-2 (10.1.0.96/26)          - 64 IPs (59 usable)
│   ├── ManagementSubnet-2 (10.1.0.160/27)       - 32 IPs (27 usable)
│   ├── InternalSubnet-2 (10.1.9.16/22)          - 1,024 IPs (1,019 usable)
│   ├── ApplicationSubnet-2 (10.1.13.16/22)      - 1,024 IPs (1,019 usable)
│   ├── IsolatedSubnet-2 (10.1.17.16/24)         - 256 IPs (251 usable)
│   └── TransitGatewaySubnet-2 (10.1.18.0/28)    - 16 IPs (11 usable)
├── AZ-3 (ap-northeast-1d)
│   ├── ExternalSubnet-3 (10.1.0.192/26)         - 64 IPs (59 usable)
│   ├── ManagementSubnet-3 (10.1.0.224/27)       - 32 IPs (27 usable)
│   ├── InternalSubnet-3 (10.1.17.32/22)         - 1,024 IPs (1,019 usable)
│   ├── ApplicationSubnet-3 (10.1.21.32/22)      - 1,024 IPs (1,019 usable)
│   ├── IsolatedSubnet-3 (10.1.25.32/24)         - 256 IPs (251 usable)
│   └── TransitGatewaySubnet-3 (10.1.26.32/28)   - 16 IPs (11 usable)
├── NAT Gateway (AZ-1 only)
└── Internet Gateway

Why 6 Types of Subnets?

This doesn't mean you should always create many subnets, but we've created 6 as examples of subnet segmentation. Dividing subnets too finely wastes reserved IPs per subnet, so adjust the subnet configuration according to your actual project requirements. For basic projects, two types—Public and Private Subnets—are often sufficient.

ExternalSubnet (Public): For internet-facing load balancers, NAT Gateway placement
ManagementSubnet (Public): For Bastion Hosts and operational management
InternalSubnet (Private with Egress): For VPC Endpoints, internal load balancers
ApplicationSubnet (Private with Egress): For application servers, ECS tasks, Lambda functions
IsolatedSubnet (Private Isolated): For database layers like RDS, ElastiCache
TransitGatewaySubnet (Private Isolated): For Transit Gateway attachments

VPC Flow Logs Implementation

VPC Flow Logs capture information about IP traffic flowing to and from network interfaces in your VPC.

Flow Logs to S3

import * as s3 from 'aws-cdk-lib/aws-s3';

// Create secure S3 bucket
const flowLogBucket = new s3.Bucket(this, 'FlowLogBucket', {
  encryption: s3.BucketEncryption.S3_MANAGED,
  blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
  enforceSSL: true,  // Require HTTPS
  removalPolicy: cdk.RemovalPolicy.DESTROY,  // ⚠️ For dev (use RETAIN for prod)
  autoDeleteObjects: true,  // ⚠️ For dev (use RETAIN removalPolicy for prod)
});

// Log all traffic to S3
customVpc.addFlowLog('FlowLogToS3', {
  destination: ec2.FlowLogDestination.toS3(
    flowLogBucket,
    'vpcFlowLog/',
    {
      fileFormat: ec2.FlowLogFileFormat.PLAIN_TEXT,
      hiveCompatiblePartitions: true,  // For Athena queries
      perHourPartition: true,
    }
  ),
  trafficType: ec2.FlowLogTrafficType.ALL,
});

Generated log file structure:

s3://bucket-name/vpcFlowLog/
└── AWSLogs/
    └── aws-account-id=123456789012/
        └── aws-service=vpcflowlogs/
            └── aws-region=ap-northeast-1/
                └── year=2024/
                    └── month=12/
                        └── day=20/
                            └── hour=12/
                                └── <AWSAccountID>_vpcflowlogs_<region>_xxxxx.log.gz

Flow Logs to CloudWatch Logs

import * as logs from 'aws-cdk-lib/aws-logs';

// Log rejected traffic only to CloudWatch Logs
customVpc.addFlowLog('FlowLog', {
  destination: ec2.FlowLogDestination.toCloudWatchLogs(
    new logs.LogGroup(this, 'FlowLogGroup', {
      retention: logs.RetentionDays.ONE_WEEK,
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    })
  ),
  trafficType: ec2.FlowLogTrafficType.REJECT,  // Rejected only
});

Flow Logs Comparison

Destination	Pros	Cons	Use Cases
S3	- Ideal for long-term storage - Queryable with Athena - Cost effective	- No real-time analysis	Auditing, compliance, long-term analysis
CloudWatch Logs	- Real-time monitoring - Metric filters - Alerting	- Higher storage costs	Security monitoring, immediate threat detection

Flow Log Format

version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 123456789012 eni-1234abcd 10.0.1.5 203.0.113.5 49152 80 6 10 5000 1670000000 1670000060 ACCEPT OK

Key fields (documentation):

srcaddr/dstaddr: Source/destination IP addresses
srcport/dstport: Source/destination ports
protocol: IP protocol number (6=TCP, 17=UDP)
action: ACCEPT or REJECT

VPC Endpoints Implementation

VPC Endpoints enable private connections between your VPC and AWS services.

Gateway Endpoints (S3, DynamoDB)

const endpointSubnets = customVpc.selectSubnets({
    subnetGroupName: 'Internal',
});
// S3 Gateway Endpoint
customVpc.addGatewayEndpoint('S3Endpoint', {
  service: ec2.GatewayVpcEndpointAwsService.S3,
  subnets: [{ subnets: endpointSubnets.subnets }],
});

// DynamoDB Gateway Endpoint
customVpc.addGatewayEndpoint('DynamoDBEndpoint', {
  service: ec2.GatewayVpcEndpointAwsService.DYNAMODB,
  subnets: [{ subnets: endpointSubnets.subnets }],
});

Interface Endpoints (Systems Manager)

// SSM Interface Endpoint
customVpc.addInterfaceEndpoint('SSMEndpoint', {
  service: ec2.InterfaceVpcEndpointAwsService.SSM,
  subnets: {
    subnets: endpointSubnets.subnets,
  },
});

// SSM Messages Interface Endpoint
customVpc.addInterfaceEndpoint('SSMMessagesEndpoint', {
  service: ec2.InterfaceVpcEndpointAwsService.SSM_MESSAGES,
  subnets: {
    subnets: endpointSubnets.subnets,
  },
});

Comparison: Gateway vs Interface Endpoints

Feature	Gateway Endpoint	Interface Endpoint
Supported Services	S3, DynamoDB	Most AWS services
Pricing	Free	Hourly + data transfer
Implementation	Route table entry	ENI in subnet
DNS	Service endpoint	Private DNS
High Availability	Managed by AWS	Per AZ

Why Use VPC Endpoints?

Security: Traffic doesn't traverse the internet
Performance: Lower latency
Cost savings: Reduce NAT Gateway data transfer charges
Compliance: Keep data within AWS network

EC2 Instance Connect Endpoint

EC2 Instance Connect Endpoint allows SSH connections to EC2 instances in private subnets without public IPs or Bastion hosts.

Please note that the Instance Connect Endpoint has the following restrictions. For details, please refer to the documentation here.

Maximum number of EC2 Instance Connect Endpoints per AWS account per AWS Region: 5
Maximum number of EC2 Instance Connect Endpoints per VPC: 1
Maximum number of EC2 Instance Connect Endpoints per subnet: 1
Maximum number of concurrent connections per EC2 Instance Connect Endpoint: 20

// Security group for Instance Connect
const ec2InstanceConnectsg = new ec2.SecurityGroup(this, 'EC2InstanceConnectSG', {
  vpc: customVpc,
  description: 'Security group for EC2 Instance Connect Endpoint',
  allowAllOutbound: false,  // Deny default outbound
});

// Select first subnet in InternalSubnet
const iceSubnet = endpointSubnets.subnets[0];

// Create Instance Connect Endpoint
new ec2.CfnInstanceConnectEndpoint(this, 'EC2InstanceConnectEndpoint', {
  subnetId: iceSubnet.subnetId,
  preserveClientIp: false,
  securityGroupIds: [ec2InstanceConnectsg.securityGroupId],
});

// Security group for EC2 instances
const ec2sg = new ec2.SecurityGroup(this, 'EC2SG', {
  vpc: customVpc,
  description: 'Security group for EC2 instances',
  allowAllOutbound: true,
});

Avoiding Circular Dependencies with Security Groups

⚠️ Important: Using addIngressRule or addEgressRule creates circular dependencies between two security groups. While cdk synth succeeds, cdk deploy will fail.

Wrong approach (causes circular dependency):

// ❌ This will cause an error
ec2sg.addIngressRule(
  ec2InstanceConnectsg,
  ec2.Port.tcp(22),
  'Allow SSH from Instance Connect'
);

ec2InstanceConnectsg.addEgressRule(
  ec2sg,
  ec2.Port.tcp(22),
  'Allow SSH to EC2 instances'
);
// ❌ Dev-DrillexercisesVpcBasics failed: ValidationError: 
Circular dependency between resources: 
[EC2InstanceConnectSG697BC6D2, EC2InstanceConnectEndpoint, EC2SG244E8056]

Correct approach (using CloudFormation resources directly):

// ✅ Use CfnSecurityGroupIngress/Egress
// Ingress: Instance Connect SG -> EC2 SG
new ec2.CfnSecurityGroupIngress(this, 'AllowSSHFromInstanceConnect', {
  ipProtocol: 'tcp',
  fromPort: 22,
  toPort: 22,
  groupId: ec2sg.securityGroupId,
  sourceSecurityGroupId: ec2InstanceConnectsg.securityGroupId,
  description: 'Allow SSH from Instance Connect SG',
});

// Egress: Instance Connect SG -> EC2 SG
new ec2.CfnSecurityGroupEgress(this, 'AllowSSHToEC2SG', {
  ipProtocol: 'tcp',
  fromPort: 22,
  toPort: 22,
  groupId: ec2InstanceConnectsg.securityGroupId,
  destinationSecurityGroupId: ec2sg.securityGroupId,
  description: 'Allow SSH to EC2 SG',
});

Using Instance Connect Endpoint

To connect to an EC2 instance via Instance Connect Endpoint using AWS CLI, use the following command. Refer to the documentation for details.

# SSH connection via Instance Connect Endpoint
aws ec2-instance-connect ssh \
  --instance-id i-1234567890abcdef0 \
  --connection-type eice

Why Use Instance Connect Endpoint?

Comparison with traditional methods:

Method	Public IP	Bastion Host	SSH Key Management	Additional Cost
EC2 with Public IP	Required	✅Not needed	Required	✅None
Bastion Host	Required for Bastion	Required	Required	EC2 charges
Instance Connect Endpoint	✅Not needed	✅Not needed	✅Not needed	Yes

Benefits:

No internet exposure
No SSH key management (IAM authentication)
No Bastion host needed (cost reduction)
All connections logged in CloudTrail

CloudFormation Output Example

Key parts of the CloudFormation template generated after deployment:

{
  "Resources": {
    "CustomVPC616E3387": {
      "Type": "AWS::EC2::VPC",
      "Properties": {
        "CidrBlock": "10.1.0.0/16",
        "EnableDnsHostnames": true,
        "EnableDnsSupport": true,
        "Tags": [
          {
            "Key": "Name",
            "Value": "Myproject/Dev/CustomVPC"
          }
        ]
      }
    },
    "CustomVPCS3Endpoint": {
      "Type": "AWS::EC2::VPCEndpoint",
      "Properties": {
        "ServiceName": "com.amazonaws.ap-northeast-1.s3",
        "VpcEndpointType": "Gateway",
        "RouteTableIds": [...]
      }
    },
    "CustomVPCSSMEndpoint": {
      "Type": "AWS::EC2::VPCEndpoint",
      "Properties": {
        "ServiceName": "com.amazonaws.ap-northeast-1.ssm",
        "VpcEndpointType": "Interface",
        "PrivateDnsEnabled": true,
        "SecurityGroupIds": [...],
        "SubnetIds": [...]
      }
    }
  }
}

Deployment and Validation

Deployment

# Check differences
cdk diff --project=myproject --env=dev

# Deploy
cdk deploy "**" --project=myproject --env=dev

Validation

Verify VPC

   # List VPCs
   aws ec2 describe-vpcs \
     --filters "Name=tag:Name,Values=*Myproject/Dev/CustomVPC*"

   # Check subnets
   aws ec2 describe-subnets \
     --filters "Name=vpc-id,Values=<vpc-id>"

Verify VPC Endpoints

   # List VPC Endpoints
   aws ec2 describe-vpc-endpoints \
     --filters "Name=vpc-id,Values=<vpc-id>"

Verify Flow Logs

   # Check logs in S3 bucket
   aws s3 ls s3://<bucket-name>/vpcFlowLog/ --recursive

   # Check CloudWatch Logs
   aws logs describe-log-streams \
     --log-group-name <log-group-name>

Verify Security Groups

   # List security groups
   aws ec2 describe-security-groups \
     --filters "Name=vpc-id,Values=<vpc-id>"

Cleanup

# Delete stacks
cdk destroy "**" --project=myproject --env=dev

# Force delete without confirmation
cdk destroy "**" --force --project=myproject --env=dev

💡 Note

This example sets autoDeleteObjects: true for development environments, so S3 buckets are automatically deleted when the stack is deleted
For production, consider using removalPolicy: cdk.RemovalPolicy.RETAIN to protect data

Best Practices

Network Design

CIDR Planning: Design CIDR blocks considering future expansion
Multiple AZs: Use at least 2 AZs for high availability
- Specify maximum with maxAzs, but actual number depends on the region
- Tokyo region (ap-northeast-1) has a maximum of 3 AZs available
Subnet Isolation: Use different subnets for different tiers (Web, App, DB)
Reserved IPs: Account for the 5 IPs AWS reserves in each subnet

Security

Least Privilege: Open only necessary ports in security groups
Flow Logs: Enable flow logs for all VPCs
VPC Endpoints: Use to avoid going through the internet
Private Subnets: Place databases in completely isolated subnets
NACLs: Provide additional layers with Network ACLs when needed

Cost Optimization

NAT Gateway Count: One NAT Gateway is sufficient for development
VPC Endpoints: Choose based on usage frequency
- High frequency: Interface Endpoint (worth the hourly rate)
- Low frequency: Via NAT Gateway (pay-as-you-go)
Flow Logs: Use S3 for reduced long-term storage costs
Resource Tags: Tag all resources for cost tracking

Operations

Naming Conventions: Use consistent naming patterns

   Example: {project}-{environment}-{resource}-{account}-{region}

Tagging Strategy: Use Environment, Project, Owner, CostCenter tags
Monitoring: Monitor VPC metrics in CloudWatch
Documentation: Document network diagrams and CIDR allocations

Testing

Snapshot Tests: Clarify change differences
Unit Tests: Validate resource existence and configuration
Compliance Tests: Check security best practices with CDK Nag

Cost Estimation

Example Pricing for Key Components (Tokyo Region)

For CDK Default VPC:

Resource	Quantity	Estimated Monthly Cost
VPC	1	$0 (Free)
NAT Gateway	3	$133.92 ($0.062/hour × 24 × 30 × 3)
NAT Gateway Data Processing	100GB	$18.6 ($0.062/GB × 3)
VPC Gateway Endpoint	-	$0
VPC Interface Endpoint	-	$0
Endpoint Data Processing	-	$0
Total	-	~$152.52/month

For Custom VPC:

Resource	Quantity	Estimated Monthly Cost
VPC	1	$0 (Free)
NAT Gateway	1	$39.42 ($0.062/hour × 24 × 30)
NAT Gateway Data Processing	100GB	$6.20 ($0.062/GB)
VPC Gateway Endpoint	2	$0
VPC Interface Endpoint	2	$15.12 ($0.012/hour × 2 × 24 × 30)
Endpoint Data Processing	10GB	$0.12 ($0.012/GB)
S3 Storage (Flow Logs)	50GB	$1.15 ($0.023/GB)
CloudWatch Logs (7-day retention)	5GB	$0.35 ($0.033/GB)
Total	-	~$62.36/month

💡 Cost Reduction Tips

Development: One NAT Gateway is sufficient (multiple recommended for production) or use NAT instances with EC2
Flow Logs: Can be temporarily disabled in development
VPC Endpoints: Choose based on usage frequency

Summary

In this exercise, we learned VPC fundamentals through AWS CDK.

What We Learned

VPC Basics: Differences between CDK default and custom VPC
Subnet Design: CIDR calculations and 3-tier subnet configuration
Traffic Management: NAT Gateway, Internet Gateway, routing
Visibility: Network monitoring with VPC Flow Logs
VPC Endpoints: When to use Gateway vs Interface Endpoints
Secure Access: Implementing Instance Connect Endpoint
Security Groups: Cross-referencing and avoiding circular dependencies
Best Practices: Security, cost, and operations perspectives

Key Takeaways

Network Design: Proper CIDR planning is crucial for future expansion
Security Layers: Network-level isolation and control
Visibility: Flow log monitoring is essential
Cost Optimization: Choose NAT Gateway count and VPC Endpoints wisely
High Availability: Multi-AZ and failover design

References

Let's continue learning practical AWS CDK patterns through the 100 drill exercises!
If you found this helpful, please ⭐ the repository!

📌 You can see the entire code in My GitHub Repository.

AWS CDK 100 Drill Exercises #002: IAM Basics —— Users, Roles, and Secure Password Management

TOMOAKI ishihara — Tue, 09 Dec 2025 16:00:39 +0000

Introduction

This is the second exercise in the "AWS CDK 100 Drill Exercises" series.

For more about AWS CDK 100 Drill Exercises, see this introduction article.

After learning S3 fundamentals in the first exercise, we now dive into AWS Identity and Access Management (IAM). IAM is the foundation of AWS security, controlling who can access your resources and what they can do with them.

Why IAM After S3?

Security Foundation: IAM is essential for securing all AWS resources
Real-World Necessity: Every AWS deployment requires proper access management
CDK Integration: Understanding how CDK generates IAM policies and roles
Best Practices: Learning secure patterns from the start prevents future vulnerabilities

What You'll Learn

How CDK creates IAM users, groups, and roles
Secure password management with AWS Secrets Manager
The difference between managed policies and inline policies
Switch role implementation with MFA requirements
CloudFormation's dynamic secret resolution
IAM security best practices

📁 Code Repository: All code examples for this exercise are available on GitHub.

Architecture Overview

Here's what we'll build in this exercise:

We'll implement five different patterns across four constructs:

Construct 1: Basic User (CDKDefaultUser)

Pattern 1: Minimal IAM user configuration

Construct 2: Password Management User (IAMUserWithPassword)

Pattern 2A: Hardcoded password (⚠️ Not recommended)
Pattern 2B: Secure password management with Secrets Manager (✅ Recommended)
Pattern 3A: AWS managed policy attachment
Pattern 3B: Inline policy attachment

Construct 3: Group Management User (IamUserGroup)

Pattern 4: Group-based permission management

Construct 4: Switch Role User (SwitchRoleUser)

Pattern 5: MFA-required role assumption

Prerequisites

To follow along, you'll need:

AWS CLI v2 installed and configured
Node.js 20+
AWS CDK CLI (npm install -g aws-cdk)
Basic TypeScript knowledge
AWS Account (Free Tier works for this exercise)
Understanding of IAM concepts (users, roles, policies)

Project Directory Structure

iam-basics/
├── bin/
│   └── iam-basics.ts                      # Application entry point
├── lib/
│   ├── stacks/
│   │   └── iam-basics-stack.ts            # Main stack definition
│   └── constructs/
│       ├── iam-user-with-password.ts      # Patterns 2-3
│       ├── iam-user-with-group.ts         # Pattern 4
│       └── iam-user-with-switch-role.ts   # Pattern 5
├── test/
│   ├── compliance/
│   │   └── cdk-nag.test.ts                # Testing (explained in later exercises)
│   ├── snapshot/
│   │   └── snapshot.test.ts               # Testing (explained in later exercises)
│   └── unit/
│       └── iam-basics.test.ts             # Testing (explained in later exercises)
├── cdk.json
├── package.json
└── tsconfig.json

Pattern 1: Understanding CDK Default User

Let's start with the simplest IAM user creation. This is all you need to create an IAM user.

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as iam from 'aws-cdk-lib/aws-iam';

export class IamBasicsStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Minimal IAM user configuration
    const cdkDefaultUser = new iam.User(this, 'CDKDefaultUser', {});
  }
}

Generated CloudFormation:

{
  "Resources": {
    "CDKDefaultUserF7AAA71A": {
      "Type": "AWS::IAM::User",
      "Metadata": {
        "aws:cdk:path": "Dev/DrillexercisesIamBasics/CDKDefaultUser/Resource"
      }
    }
  }
}

Default Configuration Details

Let's examine what CDK automatically configures:

User Name: Auto-generated by AWS
No Password: Console access disabled by default
No Policies: Zero permissions (principle of least privilege)
No Access Keys: Programmatic access disabled

Until you explicitly grant permissions, this user cannot access anything.

Pattern 2A: User with Hardcoded Password (⚠️ Not Recommended)

⚠️ This pattern demonstrates what happens when you use it in production environments.
Note that "PasswordResetRequired": true is set, but the user cannot change the password because they lack permissions.
To allow password changes, you need the IAMUserChangePassword policy shown in [Pattern 2B].
Alternatively, you can configure your AWS account to allow all IAM users to change their own passwords. (See AWS Documentation)

const userWithPassword = new iam.User(this, 'PasswordUser', {
  password: cdk.SecretValue.unsafePlainText('InitialPassword123!'),
  passwordResetRequired: true,
});

Generated CloudFormation:

{
  "UserWithPasswordPasswordUserA5E8EDB8": {
    "Type": "AWS::IAM::User",
    "Properties": {
      "LoginProfile": {
        "Password": "InitialPassword123!",
        "PasswordResetRequired": true
      }
    }
  }
}

Why This Is Dangerous

Password in source code: Visible in version control. Even if passed via environment variables, it will be exposed for the following reasons.
CloudFormation template: Password exposed in console and logs
No encryption: Stored in plain text
Audit trail: Difficult to track password changes

Never use this pattern in production.

Pattern 2B: User with Secrets Manager (✅ Recommended)

This is the secure way to manage IAM user passwords.

import * as secretsmanager from 'aws-cdk-lib/aws-secretsmanager';

const userName = 'SecretsPasswordUser';

// Create the secret with auto-generated password
const userSecret = new secretsmanager.Secret(this, 'UserSecret', {
  generateSecretString: {
    secretStringTemplate: JSON.stringify({ username: userName }),
    generateStringKey: 'password',
    excludePunctuation: true,
    passwordLength: 16,
    requireEachIncludedType: true,
  },
});

// Create user with password from Secrets Manager
const user = new iam.User(this, 'SecretsPasswordUser', {
  userName: userName,
  password: userSecret.secretValueFromJson('password'),
  passwordResetRequired: true,
});
// change password policy
userWithSecretsManager.addManagedPolicy(
  iam.ManagedPolicy.fromAwsManagedPolicyName('IAMUserChangePassword')
);

// Grant the user permission to read their own password
userSecret.grantRead(user);

// Output the secret ARN for retrieval
new cdk.CfnOutput(this, 'SecretArn', {
  value: userSecret.secretArn,
  description: 'Retrieve password: aws secretsmanager get-secret-value --secret-id <this-arn>',
});

Generated CloudFormation:

{
  "UserWithPasswordSecretsPasswordUserSecret32219BC7": {
    "Type": "AWS::SecretsManager::Secret",
    "Properties": {
      "GenerateSecretString": {
        "ExcludePunctuation": true,
        "GenerateStringKey": "password",
        "SecretStringTemplate": "{\"username\":\"SecretsPasswordUser\"}"
      }
    }
  },
  "UserWithPasswordSecretsPasswordUserCFEF7855": {
    "Type": "AWS::IAM::User",
    "Properties": {
      "LoginProfile": {
        "Password": {
          "Fn::Join": [
            "",
            [
              "{{resolve:secretsmanager:",
              {"Ref": "UserWithPasswordSecretsPasswordUserSecret32219BC7"},
              ":SecretString:password::}}"
            ]
          ]
        },
        "PasswordResetRequired": true
      },
      "ManagedPolicyArns": [
        {
          "Fn::Join": [
            "",
            [
              "arn:",
              {
                "Ref": "AWS::Partition"
              },
              ":iam::aws:policy/IAMUserChangePassword"
            ]
          ]
        }
      ],
      "UserName": "SecretsPasswordUser"
    }
  },
  "UserWithPasswordSecretsPasswordUserDefaultPolicy6A5FC9BF": {
    "Type": "AWS::IAM::Policy",
    "Properties": {
      "PolicyDocument": {
        "Statement": [
          {
            "Action": [
              "secretsmanager:DescribeSecret",
              "secretsmanager:GetSecretValue"
            ],
            "Effect": "Allow",
            "Resource": {
              "Ref": "UserWithPasswordSecretsPasswordUserSecret32219BC7"
            }
          }
        ]
      },
      "Users": [
        {"Ref": "UserWithPasswordSecretsPasswordUserCFEF7855"}
      ]
    }
  }
}

Key Features of This Pattern

1. CloudFormation Dynamic Reference

The most important part is this:

"Password": {
  "Fn::Join": [
    "",
    [
      "{{resolve:secretsmanager:",
      {"Ref": "SecretId"},
      ":SecretString:password::}}"
    ]
  ]
}

CloudFormation uses {{resolve:secretsmanager:...}} to dynamically retrieve the password during stack deployment. The actual password never appears in the CloudFormation template.

2. Auto-Generated Secure Password

generateSecretString: {
  secretStringTemplate: JSON.stringify({ username: userName }),
  generateStringKey: 'password',
  excludePunctuation: true,        // Avoid special characters that might cause issues
  passwordLength: 16,               // Strong password length
  requireEachIncludedType: true,    // Include uppercase, lowercase, numbers
}

3. Principle of Least Privilege

userSecret.grantRead(user);

This grants only this specific user permission to read their own password secret. The generated policy includes:

secretsmanager:DescribeSecret
secretsmanager:GetSecretValue

Retrieving the Password

After deployment:

# Get the secret ARN from stack outputs
SECRET_ARN=$(aws cloudformation describe-stacks \
  --stack-name YourStackName \
  --query 'Stacks[0].Outputs[?OutputKey==`SecretArn`].OutputValue' \
  --output text)

# Retrieve the password
aws secretsmanager get-secret-value --secret-id $SECRET_ARN \
  --query SecretString --output text | jq -r '.password'

Pattern 3: Managed Policies vs Inline Policies

This pattern is implemented within the IAMUserWithPassword construct.
Two types of policies apply to users whose passwords are generated by Secrets Manager.

AWS Managed Policy

userWithPassword.addManagedPolicy(
  iam.ManagedPolicy.fromAwsManagedPolicyName('ReadOnlyAccess')
);

Generated CloudFormation:

{
  "ManagedPolicyArns": [
    {
      "Fn::Join": [
        "",
        [
          "arn:",
          {"Ref": "AWS::Partition"},
          ":iam::aws:policy/ReadOnlyAccess"
        ]
      ]
    }
  ]
}

Characteristics:

Maintained by AWS
Automatically updated with new services
Can be attached to multiple users/roles/groups
Reference by ARN

Inline Policy

userWithPassword.addToPolicy(
  new iam.PolicyStatement({
    actions: ['s3:ListAllMyBuckets'],
    resources: ['arn:aws:s3:::*'],
  })
);

Generated CloudFormation:

{
  "UserDefaultPolicy": {
    "Type": "AWS::IAM::Policy",
    "Properties": {
      "PolicyDocument": {
        "Statement": [
          {
            "Action": "s3:ListAllMyBuckets",
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::*"
          }
        ]
      },
      "Users": [
        {"Ref": "User"}
      ]
    }
  }
}

Characteristics:

Custom permissions
Tightly coupled to the user/role
Deleted when the user/role is deleted
Defined directly in the template

When to Use Each

Use Case	Managed Policy	Inline Policy
Common AWS permissions	✅	❌
Custom application-specific permissions	❌	✅
Shared across multiple entities	✅	❌
One-time, specific permissions	❌	✅
Frequently changing permissions	❌	✅

Pattern 4: Group-Based Permission Management

Groups allow you to grant consistent permissions to multiple users.
This pattern is implemented in iam-user-with-group.ts.

// Create a group
const group = new iam.Group(this, 'IamGroup', {});

// Attach policy to group
group.addManagedPolicy(iam.ManagedPolicy.fromAwsManagedPolicyName('ReadOnlyAccess'));

// Add user to group
user.addToGroup(group);

Generated CloudFormation:

{
  "UserGroupIamGroupAB148728": {
   "Type": "AWS::IAM::Group",
   "Properties": {
    "ManagedPolicyArns": [
     {
      "Fn::Join": [
       "",
       [
        "arn:",
        {
         "Ref": "AWS::Partition"
        },
        ":iam::aws:policy/ReadOnlyAccess"
       ]
      ]
     }
    ]
   },
  "UserGroupUser5985318E": {
   "Type": "AWS::IAM::User",
   "Properties": {
    "Groups": [
     {
      "Ref": "UserGroupIamGroupAB148728"
     }
    ],
   }
}

Benefits of Group-Based Management

Centralized Management: Update permissions for all users at once
Consistency: Ensure all users in a role have identical permissions
Scalability: Easy to onboard new team members
Auditability: Clear permission structure

Pattern 5: Switch Role with MFA (Advanced)

💡 Note: Advanced Pattern for Level 100

This pattern is implemented in iam-user-with-switch-role.ts.
This switch role pattern is slightly advanced for Level 100, but we include it here because:

It's a fundamental IAM best practice
You'll encounter it frequently in real-world AWS environments
CDK makes implementation straightforward

This pattern implements a security best practice: requiring MFA for elevated permissions.

const accountId = cdk.Stack.of(this).account;

// Create IAM user
const switchRoleUser = new iam.User(this, 'SwitchRoleUser', {
  userName: 'SwitchRoleUser',
  password: userSecret.secretValueFromJson('password'),
  passwordResetRequired: true,
});

// Create role with MFA requirement
const readOnlyRole = new iam.Role(this, 'ReadOnlyRole', {
  assumedBy: new iam.PrincipalWithConditions(
    new iam.AccountPrincipal(accountId),
    {
      Bool: { 'aws:MultiFactorAuthPresent': 'true' },
    }
  ),
  maxSessionDuration: cdk.Duration.hours(4),
  managedPolicies: [
    iam.ManagedPolicy.fromAwsManagedPolicyName('ReadOnlyAccess'),
  ],
});

// Create policy to allow assuming the role
const assumeRolePolicy = new iam.Policy(this, 'AssumeRolePolicy', {
  statements: [
    new iam.PolicyStatement({
      actions: ['sts:AssumeRole'],
      resources: [readOnlyRole.roleArn],
    }),
  ],
});

// Create group and attach policy
const switchRoleGroup = new iam.Group(this, 'SwitchRoleGroup', {});
assumeRolePolicy.attachToGroup(switchRoleGroup);

// Add user to group
switchRoleUser.addToGroup(switchRoleGroup);

Generated CloudFormation:

{
  "SwitchRoleUserReadOnlyRole660C7C3B": {
    "Type": "AWS::IAM::Role",
    "Properties": {
      "AssumeRolePolicyDocument": {
        "Statement": [
          {
            "Action": "sts:AssumeRole",
            "Condition": {
              "Bool": {
                "aws:MultiFactorAuthPresent": "true"
              }
            },
            "Effect": "Allow",
            "Principal": {
              "AWS": "arn:aws:iam::123456789012:root"
            }
          }
        ]
      },
      "ManagedPolicyArns": [
        {
          "Fn::Join": [
            "",
            [
              "arn:",
              {"Ref": "AWS::Partition"},
              ":iam::aws:policy/ReadOnlyAccess"
            ]
          ]
        }
      ],
      "MaxSessionDuration": 14400
    }
  }
}

Understanding the MFA Requirement

The key part is the condition:

"Condition": {
  "Bool": {
    "aws:MultiFactorAuthPresent": "true"
  }
}

This means:

Users must authenticate with MFA before assuming the role
Without MFA, the AssumeRole API call will fail
Even if the user has the sts:AssumeRole permission

How to Use Switch Role

Enable MFA for the user:

   aws iam create-virtual-mfa-device \
     --virtual-mfa-device-name SwitchRoleUser-MFA \
     --outfile QRCode.png \
     --bootstrap-method QRCodePNG

   aws iam enable-mfa-device \
     --user-name SwitchRoleUser \
     --serial-number arn:aws:iam::123456789012:mfa/SwitchRoleUser-MFA \
     --authentication-code1 123456 \
     --authentication-code2 789012

Assume the role:

   aws sts assume-role \
     --role-arn arn:aws:iam::123456789012:role/ReadOnlyRole \
     --role-session-name ReadOnlySession \
     --serial-number arn:aws:iam::123456789012:mfa/SwitchRoleUser-MFA \
     --token-code 123456

Use in AWS Console:

Log in as SwitchRoleUser
Click on account name → Switch Role
Enter Account ID and Role Name
You'll be prompted for MFA code

Benefits of Switch Role Pattern

Separation of Duties: Regular permissions vs elevated permissions
Audit Trail: Clear logs of when elevated permissions were used
Time-Limited: maxSessionDuration enforces automatic expiration
MFA Protection: Extra security layer for sensitive operations

Deploy and Verify

Deployment

# Check differences
cdk diff --project=sample --env=dev

# Deploy
cdk deploy "**" --project=sample --env=dev

Verification

Check IAM Users:

   # List all users
   aws iam list-users

   # Get specific user details
   aws iam get-user --user-name SecretsPasswordUser

Check Attached Policies:

   # List user policies
   aws iam list-attached-user-policies --user-name PasswordUser

   # List inline policies
   aws iam list-user-policies --user-name PasswordUser

Verify Secrets Manager:

   # Get secret value
   aws secretsmanager get-secret-value \
     --secret-id <secret-arn> \
     --query SecretString \
     --output text

Test Switch Role:

   # Assume role with MFA
   aws sts assume-role \
     --role-arn <role-arn> \
     --role-session-name TestSession \
     --serial-number <mfa-device-arn> \
     --token-code <mfa-code>

Cleanup

# Delete stack
cdk destroy "**" --project=sample --env=dev

# Force deletion without confirmation
cdk destroy "**" --force --project=sample --env=dev

Important: IAM users and roles are retained by default. If you want to delete them, you need to manually remove them or set appropriate deletion policies.

Best Practices

Security

Never Hardcode Passwords: Always use Secrets Manager or Parameter Store
Enable MFA: Especially for privileged accounts
Use Switch Roles: Separate regular and elevated permissions
Principle of Least Privilege: Grant only necessary permissions
Regular Audits: Review IAM policies and access patterns
Password Policies: Enforce strong password requirements
Access Key Rotation: Rotate access keys regularly (or avoid them entirely)

Password Management

Use Secrets Manager: For all password storage
Auto-Generate: Let AWS create strong passwords
Require Reset: Force password change on first login

Policy Management

Prefer Managed Policies: For common permissions
Use Inline Policies: For specific, one-off permissions
Group-Based Management: Manage permissions by role, not individual users

Operations

CloudTrail Logging: Monitor all IAM activities
Naming Conventions: Use clear, consistent names
Separate Environments: Different IAM configurations for dev/test/prod

Summary

In this exercise, we learned IAM fundamentals through AWS CDK.

What We Learned

IAM Basics: Users, groups, roles, and policies
Secure Passwords: Using Secrets Manager instead of hardcoded values
CloudFormation Integration: Dynamic secret resolution with {{resolve:secretsmanager:...}}
Policy Types: Managed vs inline policies and when to use each
Switch Roles: Implementing role assumption with MFA requirements
Best Practices: Least privilege, MFA, and group-based management

Key Takeaways

Security First: IAM is the foundation of AWS security
Secrets Manager: Essential for password management
MFA: Critical for elevated permissions
Groups: Simplify permission management
Audit: CloudTrail and regular reviews are essential

References

Let's continue learning practical AWS CDK patterns through the 100 drill exercises!
If you found this helpful, please ⭐ the repository!

📌 You can see the entire code in My GitHub Repository.

AWS CDK 100 Drill Exercises: Index & Progress (#001-#010)

TOMOAKI ishihara — Sun, 07 Dec 2025 15:53:46 +0000

AWS CDK 100 Drill Exercises: #001-#010

📊 Progress Overview

Exercises in this set: 10 | Completed: 7 / 10

██████████████□□□□□□ 70%

Level Distribution:

Level 100: 2 exercises
Level 200: 2 exercises
Level 300: 2 exercises
Level 400: 0 exercise

📈 Next Steps

Continue your journey with [Index #011-#020] →

💬 Questions or suggestions? Join the discussion on GitHub

AWS CDK 100 Drill Exercises #001: S3 Bucket Fundamentals —— From Default Settings to Practical Customization

TOMOAKI ishihara — Sun, 07 Dec 2025 15:48:48 +0000

Introduction

This is the first exercise in the "AWS CDK 100 Drill Exercises" series.

For more about AWS CDK 100 Drill Exercises, see this introduction article.

Through these 100 exercises, we'll progressively learn practical AWS CDK patterns. For this first exercise, I've chosen S3 buckets because they're an ideal starting point for learning AWS CDK fundamentals.

Why Start with S3?

Simple Structure: No complex dependencies like networking or security groups
Rich Configuration Options: Practical features including encryption, lifecycle rules, and versioning
CloudFormation Comparison: Easy to understand how CDK's defaults translate to CloudFormation
Cost Effective: Low-cost experimentation for learning purposes

What You'll Learn

How minimal CDK code translates to CloudFormation templates
Default behavior and customization of L2 Constructs
S3 bucket security best practices
Cost optimization through lifecycle rules
Versioning and noncurrent version management

📁 Code Repository: All code examples for this exercise are available on GitHub.

Architecture Overview

Here's what we'll build in this exercise:

We'll implement eight different patterns:

CDKDefault: Completely default settings
Named: Explicitly specify bucket name
AutoDeleteObjects: Auto-delete objects on bucket removal
BlockPublicAccessOff: Partial public access configuration
EncryptionSSEKMSManaged: AWS-managed KMS encryption
EncryptionSSEKMSCustomer: Customer-managed KMS encryption
LifecycleRules: Cost optimization through lifecycle transitions
VersioningEnabled: Versioning with lifecycle management

Prerequisites

To follow along, you'll need:

AWS CLI v2 installed and configured
Node.js 20+
AWS CDK CLI (npm install -g aws-cdk)
Basic TypeScript knowledge
AWS Account (Free Tier works for most exercises)

Project Directory Structure

s3-basics/
├── bin/
│   └── s3-basics.ts               # Application entry point
├── lib/
│   ├── stacks/
│   │      └── s3-basics-stack.ts         # Stack definition
│   └── stages/
│          └── s3-basics-stage.ts         # Stage definition
├── test/
│   ├── compliance
│   │      └── cdk-nag.test.ts     # Test code (covered in later exercises)
│   ├── snapshot
│   │      └── snapshot.test.ts    # Test code (covered in later exercises)
│   └── unit
│          └── s3-basics.test.ts   # Test code (covered in later exercises)
├── cdk.json
├── package.json
└── tsconfig.json

Pattern 1: Understanding CDK Defaults

Let's start with the simplest implementation.

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as s3 from 'aws-cdk-lib/aws-s3';

export class S3BasicStack extends cdk.Stack {
  public readonly bucket: s3.IBucket;

  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // S3 bucket with completely default settings
    this.bucket = new s3.Bucket(this, 'CDKDefault', {});
  }
}

This minimal code creates an S3 bucket. Let's examine what CloudFormation template this generates.

Generated CloudFormation:

Running cdk synth produces the following CloudFormation template:

{
  "Resources": {
    "CDKDefaultE8B73DAC": {
      "Type": "AWS::S3::Bucket",
      "UpdateReplacePolicy": "Retain",
      "DeletionPolicy": "Retain",
      "Metadata": {
        "aws:cdk:path": "Dev/DrillexercisesS3Basic/CDKDefault/Resource"
      }
    }
  }
}

Default Configuration Details

Let's examine what CDK automatically configures.

1. Logical ID Generation

The Construct ID CDKDefault gets a hash suffix E8B73DAC, resulting in the logical ID CDKDefaultE8B73DAC. This hash ensures uniqueness within the stack.

2. UpdateReplacePolicy and DeletionPolicy

Both are set to Retain, meaning the S3 bucket persists even after stack deletion - a safe default.

AWS Documentation: UpdateReplacePolicy and DeletionPolicy

⚠️ Note: If you deploy this code and destroy the stack, you'll need to manually delete the CDKDefault bucket.

3. Implicit Settings

While not explicitly shown in the CloudFormation template, these settings apply:

Encryption: SSE-S3 (Amazon S3-managed encryption keys)
Public Access: Completely blocked (recommended)
Versioning: Disabled
Bucket Name: Auto-generated by AWS

These are AWS default values. CDK prioritizes secure defaults, so even without explicit configuration, you get a safe setup.

Pattern 2: Specifying Bucket Name

This example explicitly specifies a bucket name.
However, for real projects, we recommend NOT specifying bucket names. The AWS documentation also recommends CloudFormation auto-generation.

Reasons for auto-generation:

New buckets can't be created during resource replacement
- During replacement, new resources are created before old ones are deleted, causing name conflicts
CDK-generated names are sufficiently unique
Improves deployment flexibility

Only specify bucket names when absolutely necessary.

const accountId = cdk.Stack.of(this).account;
const region = cdk.Stack.of(this).region;
const regionNoHyphens = region.replace(/-/g, '');

const bucketName = [
  props.project,       // Project name
  props.environment,   // Environment identifier
  'namedbucket',       // Purpose
  accountId,           // AWS Account ID
  regionNoHyphens      // Region (hyphens removed)
].join('-').toLowerCase();

new s3.Bucket(this, 'NamedBucket', {
  bucketName,
  autoDeleteObjects: props.isAutoDeleteObject,
  removalPolicy: cdk.RemovalPolicy.DESTROY,
});
// Result example: myproject-dev-logs-123456789012-apnortheast1

Key Bucket Name Rules:

Must be globally unique
Only lowercase letters, numbers, periods (.), and hyphens (-) allowed
3-63 characters in length

For detailed naming rules, refer to the official documentation.

Pattern 3: Deletion Behavior Control

In development environments, you often want to delete buckets and their objects together when removing the stack.

new s3.Bucket(this, 'AutoDeleteObjects', {
  autoDeleteObjects: true,
  removalPolicy: cdk.RemovalPolicy.DESTROY,
});

Generated CloudFormation:

This configuration adds the following to the CloudFormation template:

S3 Bucket: DeletionPolicy changed to Delete
Bucket Policy: Permissions for custom resource
Custom Resource: Lambda function to delete objects
IAM Role: Lambda execution role

{
  "AutoDeleteObjects9931B84E": {
    "Type": "AWS::S3::Bucket",
    "Properties": {
      "Tags": [
        {
          "Key": "aws-cdk:auto-delete-objects",
          "Value": "true"
        }
      ]
    },
    "UpdateReplacePolicy": "Delete",
    "DeletionPolicy": "Delete"
  },
  "AutoDeleteObjectsPolicy6BD2BF78": {
    "Type": "AWS::S3::BucketPolicy"
    // ... bucket policy details
  },
  "AutoDeleteObjectsAutoDeleteObjectsCustomResourceF9A68CC5": {
    "Type": "Custom::S3AutoDeleteObjects"
    // ... custom resource details
  },
  "CustomS3AutoDeleteObjectsCustomResourceProviderRole3B1BD092": {
    "Type": "AWS::IAM::Role"
    // ... IAM role details
  },
  "CustomS3AutoDeleteObjectsCustomResourceProviderHandler9D90184F": {
    "Type": "AWS::Lambda::Function",
    "Properties": {
      "Runtime": "nodejs22.x",
      "Timeout": 900
      // ... Lambda function details
    }
  }
}

Critical Warning

Consider carefully before using autoDeleteObjects: true in production environments.

Increases risk of accidental data deletion
Audit logs and retention-required data may be lost

Use only in development/test environments. For production, explicitly set removalPolicy: cdk.RemovalPolicy.RETAIN to prioritize data protection.

Pattern 4: Public Access Control

S3 bucket public access settings are crucial for security. By default, public access blocking is enabled, but this configuration disables it partially.

CDK Code:

// Allow public policy only (block everything else)
new s3.Bucket(this, 'BlockPublicAccessOff', {
  blockPublicAccess: new s3.BlockPublicAccess({ 
    blockPublicPolicy: false 
  }),
  autoDeleteObjects: true,
  removalPolicy: cdk.RemovalPolicy.DESTROY,
});

Generated CloudFormation:

{
  "BlockPublicAccessOff9C2A29A0": {
    "Type": "AWS::S3::Bucket",
    "Properties": {
      "PublicAccessBlockConfiguration": {
        "BlockPublicAcls": true,
        "BlockPublicPolicy": false,
        "IgnorePublicAcls": true,
        "RestrictPublicBuckets": true
      }
    }
  }
}

Four Public Access Block Settings

Setting	Default	Description
BlockPublicAcls	true	Deny public ACL settings
BlockPublicPolicy	true	Deny public bucket policies
IgnorePublicAcls	true	Ignore public ACLs
RestrictPublicBuckets	true	Restrict public access

Best Practices

Normally, keep all settings true (complete blocking). If public access is needed, consider:

Use CloudFront: Keep S3 private, deliver via CloudFront
Signed URLs: Grant temporary access permissions
Strict Bucket Policies: IP address restrictions, etc.

Pattern 5: Encryption Configuration

S3 offers three encryption methods.

1. SSE-S3 (Default)

// Explicit specification
new s3.Bucket(this, 'EncryptionSSES3', {
  encryption: s3.BucketEncryption.S3_MANAGED,
});

AWS-managed encryption keys
No additional cost
AWS handles key rotation automatically

2. SSE-KMS (AWS-Managed Key)

new s3.Bucket(this, 'EncryptionSSEKMSManaged', {
  encryption: s3.BucketEncryption.KMS_MANAGED,
  autoDeleteObjects: true,
  removalPolicy: cdk.RemovalPolicy.DESTROY,
});

Generated CloudFormation:

{
  "EncryptionSSEKMSManagedBEDBF190": {
    "Type": "AWS::S3::Bucket",
    "Properties": {
      "BucketEncryption": {
        "ServerSideEncryptionConfiguration": [
          {
            "ServerSideEncryptionByDefault": {
              "SSEAlgorithm": "aws:kms"
            }
          }
        ]
      }
    }
  }
}

Uses AWS-managed KMS keys
Auditable via CloudTrail
Charged for KMS API calls

3. SSE-KMS (Customer-Managed Key)

new s3.Bucket(this, 'EncryptionSSEKMSCustomer', {
  encryption: s3.BucketEncryption.KMS,
  encryptionKey: new cdk.aws_kms.Key(this, 'CustomKmsKey', {
    enableKeyRotation: true,
  }),
  autoDeleteObjects: true,
  removalPolicy: cdk.RemovalPolicy.DESTROY,
});

Full key management control
Configurable key rotation
Granular access control

Pattern 6: Lifecycle Rules

Lifecycle rules are essential for cost optimization.

CDK Code:

const lifecycleBucket = new s3.Bucket(this, 'LifecycleRules', {
  lifecycleRules: [
    {
      id: 'MoveToIAAfter30Days',
      enabled: true,
      transitions: [
        {
          storageClass: s3.StorageClass.INFREQUENT_ACCESS,
          transitionAfter: cdk.Duration.days(30),
        },
      ],
    },
  ],
  autoDeleteObjects: true,
  removalPolicy: cdk.RemovalPolicy.DESTROY,
});

// Adding rules later
lifecycleBucket.addLifecycleRule({
  id: 'MoveToGlacierAfter90Days',
  enabled: true,
  transitions: [
    {
      storageClass: s3.StorageClass.GLACIER,
      transitionAfter: cdk.Duration.days(90),
    },
  ],
});

lifecycleBucket.addLifecycleRule({
  id: 'ExpireAfter365Days',
  enabled: true,
  expiration: cdk.Duration.days(365),
});

Generated CloudFormation:

{
  "LifecycleRules2799D541": {
    "Type": "AWS::S3::Bucket",
    "Properties": {
      "LifecycleConfiguration": {
        "Rules": [
          {
            "Id": "MoveToIAAfter30Days",
            "Status": "Enabled",
            "Transitions": [
              {
                "StorageClass": "STANDARD_IA",
                "TransitionInDays": 30
              }
            ]
          },
          {
            "Id": "MoveToGlacierAfter90Days",
            "Status": "Enabled",
            "Transitions": [
              {
                "StorageClass": "GLACIER",
                "TransitionInDays": 90
              }
            ]
          },
          {
            "ExpirationInDays": 365,
            "Id": "ExpireAfter365Days",
            "Status": "Enabled"
          }
        ]
      }
    }
  }
}

Storage Class Selection

Storage Class	Use Case	Cost
Standard	Frequent access	High
Standard IA	30 days+ (monthly access)	Medium
Glacier Instant Retrieval	90 days+ (annual access)	Low
Glacier Flexible Retrieval	Archive (After 90 days (annual access) )	Low
Glacier Deep Archive	Archive (rare access)	Lowest

Cost Optimization Tips

Analyze Access Patterns: Use S3 Storage Lens and access logs
Gradual Transitions: STANDARD → STANDARD_IA → GLACIER INSTANT RETRIEVAL
Set Expiration: Auto-delete unnecessary data

Pattern 7: Versioning with Lifecycle Management

Finally, let's examine a configuration with versioning enabled.

CDK Code:

new s3.Bucket(this, 'VersioningEnabled', {
  versioned: true,
  autoDeleteObjects: true,
  removalPolicy: cdk.RemovalPolicy.DESTROY,
  lifecycleRules: [
    {
      id: 'ExpireNonCurrentVersionsAfter90Days',
      enabled: true,
      noncurrentVersionExpiration: cdk.Duration.days(90),
      noncurrentVersionsToRetain: 3,
    },
    {
      id: 'NonCurrentVersionTransitionToIAAfter30Days',
      enabled: true,
      noncurrentVersionTransitions: [
        {
          storageClass: s3.StorageClass.INFREQUENT_ACCESS,
          transitionAfter: cdk.Duration.days(30),
        },
      ],
    },
    {
      id: 'CurrentVersionTransitionToIAAfter60Days',
      enabled: true,
      transitions: [
        {
          storageClass: s3.StorageClass.INFREQUENT_ACCESS,
          transitionAfter: cdk.Duration.days(60),
        },
      ],
    },
    {
      id: 'CurrentVersionTransitionToGlacierAfter90Days',
      enabled: true,
      transitions: [
        {
          storageClass: s3.StorageClass.GLACIER,
          transitionAfter: cdk.Duration.days(90),
        },
      ],
    },
    {
      id: 'ExpireCurrentVersionsAfter365Days',
      enabled: true,
      expiration: cdk.Duration.days(365),
    },
    {
      id: 'AbortIncompleteMultipartUploadsAfter7Days',
      enabled: true,
      abortIncompleteMultipartUploadAfter: cdk.Duration.days(7),
    }
  ],
});

What is Versioning?

With versioning enabled, all changes to objects are preserved.

Current Version: Latest state
Noncurrent Versions: Previous states

Generated CloudFormation:

{
  "VersioningEnabledC271D012": {
    "Type": "AWS::S3::Bucket",
    "Properties": {
      "VersioningConfiguration": {
        "Status": "Enabled"
      },
      "LifecycleConfiguration": {
        "Rules": [
          {
            "Id": "ExpireNonCurrentVersionsAfter90Days",
            "NoncurrentVersionExpiration": {
              "NewerNoncurrentVersions": 3,
              "NoncurrentDays": 90
            },
            "Status": "Enabled"
          }
          // ... other rules
        ]
      }
    }
  }
}

Lifecycle Rule Details

1. Noncurrent Version Expiration

noncurrentVersionExpiration: cdk.Duration.days(90),
noncurrentVersionsToRetain: 3,

Delete noncurrent versions after 90 days
But retain the newest 3 versions

2. Noncurrent Version Transitions

noncurrentVersionTransitions: [
  {
    storageClass: s3.StorageClass.INFREQUENT_ACCESS,
    transitionAfter: cdk.Duration.days(30),
  },
]

Transition noncurrent versions to STANDARD_IA after 30 days

3. Current Version Transitions

transitions: [
  {
    storageClass: s3.StorageClass.INFREQUENT_ACCESS,
    transitionAfter: cdk.Duration.days(60),
  },
  {
    storageClass: s3.StorageClass.GLACIER,
    transitionAfter: cdk.Duration.days(90),
  },
]

Transition to STANDARD_IA after 60 days
Transition to GLACIER after 90 days

4. Abort Incomplete Multipart Uploads

abortIncompleteMultipartUploadAfter: cdk.Duration.days(7),

Auto-delete interrupted multipart uploads after 7 days, reducing unnecessary storage costs.

Deploy and Verify

Deployment

# Check differences
cdk diff --project=sample --env=dev

# Deploy
cdk deploy "**" --project=sample --env=dev

Verification

AWS Management Console
- Check created buckets in S3 Console
- Verify encryption settings in Properties tab
- Check lifecycle rules in Management tab
AWS CLI

# List buckets
aws s3 ls

# Check versioning configuration
aws s3api get-bucket-versioning --bucket <bucket-name>

# Check lifecycle configuration
aws s3api get-bucket-lifecycle-configuration --bucket <bucket-name>

# Check encryption configuration
aws s3api get-bucket-encryption --bucket <bucket-name>

Cleanup

# Delete stack
cdk destroy "**" --project=sample --env=dev

# Skip confirmation prompt
cdk destroy "**" --force --project=sample --env=dev

Best Practices

Security

Block All Public Access: Keep defaults unless specifically needed
Encryption is Mandatory: Minimum SSE-S3, recommended SSE-KMS
Enable Versioning: For data protection and compliance
Enable Access Logging: For security audits and troubleshooting

Cost Optimization

Configure Lifecycle Rules: Choose storage classes based on access patterns
Delete Incomplete Uploads: Auto-delete after ~7 days
Manage Noncurrent Versions: Retain only necessary generations
Consider S3 Intelligent-Tiering: When access patterns are unclear

Operations

Naming Conventions: Include project name, environment, and purpose
Tagging: Essential for cost allocation and resource management
CloudTrail Integration: Audit API calls
CloudWatch Metrics: Monitor bucket size and request counts

Summary

In this exercise, we learned AWS CDK fundamentals through S3 buckets.

What We Learned

CDK Defaults: Secure configurations with minimal code
CloudFormation Translation: How CDK code converts
Deletion Control: Using autoDeleteObjects and removalPolicy
Three Encryption Methods: SSE-S3, SSE-KMS (AWS-managed), SSE-KMS (Customer-managed)
Lifecycle Rules: Gradual transitions for cost optimization
Versioning: Comprehensive management of current and noncurrent versions

References

Let's continue learning practical AWS CDK patterns through the 100 drill exercises!
If you found this helpful, please ⭐ the repository!

📌 You can see the entire code in My GitHub Repository.

Introducing: AWS CDK 100 Drill Exercises - Learn by Building

TOMOAKI ishihara — Tue, 02 Dec 2025 15:34:06 +0000

What is AWS CDK 100 Drill Exercises?

AWS CDK 100 Drill Exercises is a comprehensive, hands-on learning series where I'll create and share 100 practical AWS infrastructure implementations using the AWS Cloud Development Kit (CDK). Each exercise focuses on real-world scenarios, from basic networking setups to advanced multi-region architectures.

Goal: Master AWS CDK through deliberate practice while building a valuable reference library for the community.

🏷️ Tags for This Series

I'm using #100drillexercises as a dedicated tag for this learning series. Follow this tag to track all exercises as they're published!

Additional tags to stay updated:
#aws #cdk #devtools #100drillexercises

💡 The Inspiration Behind This Project

The idea came from an article (or book—my memory is a bit fuzzy!) about design practice. The author recommended a "100 design challenge" where you recreate existing designs, then analyze and reflect on each one. Through this repetitive, deliberate practice, designers expand their creative vocabulary and develop a deeper understanding of design principles.

When I read that, a question struck me:

Could this approach work for AWS CDK?

Why AWS CDK Needs This

The Problem: Limited Real-World Experience

In our day-to-day work, we typically encounter a limited set of infrastructure patterns.

Project constraints: Most engineers work on 1-3 projects per year
Pattern repetition: Similar architectures across projects
Limited exposure: Rarely get hands-on with cutting-edge patterns
Passive learning: Attending AWS Summit sessions and reading case studies is valuable, but without actually building, the knowledge doesn't stick

The Reality Check

I've experienced this countless times:

Watching AWS Summit technical sessions and thinking "I totally get this"
Reading company tech blogs about innovative architectures
Seeing lightning talks showcasing clever solutions
Admiring architecture diagrams in presentations

But here's the truth: Seeing ≠ Understanding

When you see an architecture diagram at a conference, you might think "That's clever!"

But when you actually sit down to implement it? Different story:

"Wait, how do they handle cross-account permissions?"
"What's the actual security group configuration?"
"How do they manage the deployment order?"
"Why is my Lambda timing out when theirs works perfectly?"

These questions only surface when you're hands-on-keyboard, building it yourself.

Learning by Doing

This project is built on a simple principle.

You don't truly understand something until you've built it yourself.

By implementing 100 different infrastructure patterns with AWS CDK, I'll..

Deepen my understanding of AWS services and CDK patterns
Discover edge cases that documentation doesn't cover
Build practical experience with architectures I'd never encounter in my day job
Create reusable patterns for future projects
Document learnings to help others avoid common pitfalls

Will I make mistakes along the way? Absolutely. That's kind of the point.

Community Contribution

But this isn't just about my personal growth. I'm sharing this journey because..

For Learners

Progressive difficulty: From Level 100 (Foundational) to Level 400 (Expert)
Complete code examples: Every exercise includes working, tested code
Real-world focus: Patterns you'll actually use in production
Best practices: Following AWS Well-Architected Framework principles

For the Community

Reference library: Searchable collection of CDK patterns
Open source: All code available on GitHub
Collaborative learning: Feedback and improvements welcome
Bridge the gap: From concept to implementation

What to Expect

Exercise Structure

Every exercise provides these components.

Clear objectives: What you'll build and why
Architecture diagram: Visual overview of the infrastructure
Level indicator: 100/200/300/400 complexity rating
Step-by-step implementation: Annotated CDK code
Best practices: Security, cost optimization, operations tips
Verification steps: How to test your deployment
Common pitfalls: Issues I encountered and how to solve them

Coverage Areas

The 100 exercises cover these key areas.

Foundation & Networking: VPC, security groups, routing
Storage & Data: S3, RDS, DynamoDB, EFS
Compute & Serverless: Lambda, ECS, EC2, Auto Scaling
Distribution & CDN: CloudFront, Global Accelerator
Security & Compliance: IAM, Secrets Manager, KMS, Config
Monitoring & Observability: CloudWatch, X-Ray
DevOps & Automation: CI/CD pipelines, multi-region deployments

Release Schedule

Initial release: Building a Basic VPC
Regular updates: 1-2 new exercises per week
Community-driven: Taking requests and feedback

Exercise Levels & Focus Areas

The 100 exercises are organized by AWS's technical content complexity levels. Each level builds on previous knowledge while introducing new concepts and patterns.

Foundational (Level 100)

Overview: Introduction to AWS CDK basics and fundamental AWS service configurations.

Target Audience:

AWS CDK beginners
Those learning Infrastructure as Code for the first time
Developers familiar with AWS Console wanting to learn CDK

Example Patterns:

Basic VPC with public/private subnets
S3 bucket with versioning and encryption
Single Lambda function with CloudWatch Logs
Security groups with simple ingress/egress rules

Intermediate (Level 200)

Overview: Implementing best practices and service features with proper configurations.

Target Audience:

Developers comfortable with Level 100 concepts
Those implementing production-ready infrastructure
Engineers seeking to apply AWS best practices

Example Patterns:

VPC with NAT Gateways and proper routing
Static website hosting with S3 + CloudFront
Lambda with API Gateway integration
RDS with Multi-AZ configuration
Application Load Balancer setups

Advanced (Level 300)

Overview: Detailed implementations of complex architectures and service integrations.

Target Audience:

Experienced CDK users
Solution architects designing scalable systems
Engineers handling complex production workloads

Example Patterns:

Multi-tier web applications with ECS/EKS
Event-driven architectures with EventBridge
Aurora Global Database configurations
Step Functions orchestration patterns
Custom CDK Constructs (L3) development

Expert (Level 400)

Overview: Enterprise-level implementations involving multiple services, accounts, and advanced architectural patterns.

Target Audience:

Senior engineers and architects
Those managing large-scale AWS environments
Engineers implementing enterprise governance

Example Patterns:

Multi-account deployment strategies with CDK Pipelines
Cross-region disaster recovery architectures
Advanced security implementations (WAF, Shield, GuardDuty integration)
Cost optimization automation patterns
Hybrid cloud integration with Direct Connect

Who Is This For?

Is this guide right for you?

You're learning AWS CDK and want hands-on practice
You have basic AWS knowledge (or are working through it!)
You understand TypeScript/JavaScript fundamentals
You understand CloudFormation but want to level up to CDK
You're preparing for AWS certifications
You want to learn by building, not just reading
You appreciate well-documented, real-world examples

Getting Started

Prerequisites

AWS Account (Free Tier works for most exercises)
AWS CLI v2
Node.js 20+
AWS CDK CLI
Basic TypeScript knowledge

Follow Along

GitHub: All code available at aws-cdk-reference-architectures
Dev.to: Follow for new exercise announcements
Discussion: GitHub Discussions for questions and feedback

Join the Journey

This is a learning journey, not a finished course. I'm actively documenting my discoveries, incorporating community feedback, exploring new patterns, and developing my AWS skills in real-time.

Documenting my discoveries and mistakes
Incorporating community feedback
Exploring new patterns and architectures
Developing my AWS skills in real-time

How to Contribute

⭐ Star the repository
💬 Share your own implementations
🐛 Report bugs or suggest improvements
📢 Tell others if you find this useful
🤔 Request patterns you need

💭 What patterns or architectures would you like to see covered in this series? Drop a comment below!

🔔 Follow me to get notified when new exercises are published!

This project is part of my journey as an AWS Community Builder in the Dev Tools category, focusing on helping developers build better with AWS CDK.

Mastering AWS CDK #3 - AWS CDK Development: Best Practices and Workflow

TOMOAKI ishihara — Tue, 25 Nov 2025 02:27:27 +0000

AWS CDK Development: Best Practices and Workflow

In the previous parts of this series, we covered Part1: AWS CDK fundamentals and Part2: components and commands. Now, let's explore how to structure your CDK projects effectively and implement best practices that will help you build maintainable infrastructure code.

AWS CDK Development Workflow

The typical AWS CDK development workflow follows these steps:

Initialize a project with cdk init
Edit the App definition to define your stacks
Create stack definitions with the resources you need
Write tests for your infrastructure code
For the first deployment:
- Run cdk bootstrap to prepare your AWS environment
- Execute cdk deploy to deploy your resources
For subsequent deployments:
- (Optional) Run cdk diff to check for changes
- Execute cdk deploy to update your resources

Let's explore what you need to get started and how to organize your projects for maximum efficiency.

Prerequisites for AWS CDK Development

Knowledge Requirements

Before diving into AWS CDK, it helps to have:

A solid understanding of AWS services and concepts (AWS Solutions Architect Associate level is ideal)
Experience with CloudFormation templates
Programming experience in at least one of the supported languages

Technical Requirements

At minimum, you'll need:

AWS CLI v2 installed and configured
Node.js (even if you're using Python, Java, or another language for your CDK code)
A text editor or IDE

For a more productive development experience, consider:

Git for version control
An IDE like VS Code with AWS CDK extensions
Docker for local testing
A CI/CD pipeline for automated deployments

Recommended Project Structure

When I first started with CDK, I used the default structure from cdk init.
After managing several production deployments, I evolved to this more organized
approach that has served me well across multiple projects:

project-root/
├─ bin/                    # App definition (entry point)
├─ lib/
│  ├─ stages/              # Stage definitions
│  ├─ stacks/              # Stack definitions
│  ├─ aspects/             # Apply policies consistently across resources
│  ├─ constructs/          # Build reusable, standardized infrastructure components
│  ├─ types/               # Ensure type safety and clear contracts between components
│  ├─ utils/               # Shared utility functions
├─ parameters/             # Environment-specific configuration files
├─ src/                    # Lambda functions, HTML, and other source files
├─ test/                   # Test files
│  ├─ snapshot/            # Snapshot tests
│  ├─ compliance/          # Security and compliance tests
|  ├─ validation/          # validation tests 
│  ├─ unit/                # Unit tests
│  ├─ integration/         # integration tests
├─ node_modules/
├─ cdk.context.json        # Context values used by CDK
├─ cdk.json                # CDK configuration
├─ jest.config.js          # Test configuration
├─ package.json
├─ tsconfig.json
├─ README.md

The key advantages of this structure:

Clear separation of concerns: Each directory has a specific purpose
Dynamic configuration: Environment-specific settings in the parameters directory
Reusable components: Common resources in dedicated directories
Organized asset management: Application code separate from infrastructure code

Stack Organization Strategies

One critical decision in CDK development is how to organize your resources into stacks. While CloudFormation has a limit of 500 resources per stack(see CloudFormation quotas), the decision to split or combine stacks shouldn't be driven by technical limits alone.

When to Keep Resources in a Single Stack

As a general rule, you should prefer single, cohesive stacks unless you have a specific reason to split them. Resources that share the same lifecycle are good candidates to keep together.

Benefits of single stacks:

Simpler deployment and rollback
Atomic updates (all or nothing)
No cross-stack reference complications
Easier to understand resource relationships

When to Split Resources into Multiple Stacks

Consider splitting stacks when:

Resource lifecycles differ significantly
- Example: You want to preserve storage resources even if you delete application resources
You approach CloudFormation limits
- CloudFormation quotas include limits on template size, number of resources, etc.
You need different deployment frequencies
- Example: Network infrastructure rarely changes, while application resources change frequently
You need to apply different security or compliance controls
- Example: Production database stack requires stricter approval processes than development stacks

The Challenge of Cross-Stack References

One major consideration when splitting stacks is managing cross-stack references. While AWS CDK makes these references easier to work with, they still create dependencies that can complicate stack updates and deletions.

For example, if Stack B references a resource in Stack A, you can't delete Stack A while Stack B is still using that resource—leading to a potential "deadlock" situation.

To resolve cross-stack reference issues:

Use exports and imports sparingly
Consider using parameters for values that might be shared
Design for independence where possible
Document dependencies between stacks clearly

Construct ID Naming Conventions

The Construct ID is the second parameter when creating a construct:

const bucket = new s3.Bucket(this, "MyBucket", {});

Following consistent naming conventions for Construct IDs improves readability and maintenance:

Rule 1: Use PascalCase

Prefer PascalCase (e.g., DatabaseCluster, ApiGateway) for Construct IDs. This aligns with CloudFormation's conventions for logical IDs.

// Good
const userTable = new dynamodb.Table(this, "UserTable", {...});

// Less ideal
const userTable = new dynamodb.Table(this, "user_table", {...});

Tip: When generating Construct IDs dynamically from configuration files or external sources, use the change-case-commonjs library to ensure consistent naming:

import { pascalCase } from 'change-case-commonjs';

// Convert from various formats to PascalCase
const resourceName = pascalCase('user_profile_table'); // "UserProfileTable"
const bucket = new s3.Bucket(this, resourceName, {...});

Rule 2: Keep Names Simple and Descriptive

Avoid overly long or complex names. CDK truncates IDs at 240 characters when generating CloudFormation logical IDs.

// Good
const prodDatabase = new rds.DatabaseInstance(this, "ProductionDatabase", {...});

// Too verbose
const prodDatabase = new rds.DatabaseInstance(this, "ProductionMySQLDatabaseInstanceForUserManagementSystem", {...});

Rule 3: Avoid Redundancy in Nested Constructs

This one trips up a lot of developers (including me when I was starting out!).
When creating custom constructs that will be nested, avoid repeating the same
information in IDs.

// Avoid redundancy like this:
export class DatabaseConstruct extends Construct {
  constructor(scope: Construct, id: string) {
    super(scope, id);
    // "DatabaseDatabase" becomes redundant in the generated logical ID
    this.database = new rds.DatabaseInstance(this, 'Database', {...});
  }
}

// Usage:
const db = new DatabaseConstruct(this, 'Database');

From Construct ID to Logical ID

It's helpful to understand how CDK transforms your Construct IDs into CloudFormation logical IDs:

const logBucket = new s3.Bucket(this, 'LogsBucket', {});

In the generated CloudFormation template:

"Resources": {
  "LogsBucket9C4D8843": {
   "Type": "AWS::S3::Bucket",
   "Properties": {
     // ...
   }
  }
}

The logical ID LogsBucket9C4D8843 is created by combining your Construct ID with a hash suffix that ensures uniqueness within the CloudFormation template.

Dynamic Parameters and Environment Management

When working with multiple environments (development, testing, production), you need a way to parameterize your infrastructure code.

Passing Parameters to CDK Commands

You can pass context values to CDK commands using the -c flag:

cdk deploy -c env=prod -c region=us-east-1

And access these values in your code:

const environment = scope.node.tryGetContext('env') || 'dev';
const region = scope.node.tryGetContext('region') || process.env.CDK_DEFAULT_REGION;

Environment-Specific Validations

You can implement safety checks to prevent accidental deployments:

// Environment validation
const envName = app.node.tryGetContext('env');
const validEnvs = ['dev', 'test', 'stage', 'prod'];

if (!validEnvs.includes(envName)) {
  console.error(`Invalid environment specified. Please use: ${validEnvs.join(', ')}`);
  process.exit(1);
}

// Visual warning for production deployments
const isProduction = envName === 'prod';
if (isProduction) {
  console.log('\x1b[31m'); // Red text
  console.log('!!!!!!!!!! CAUTION !!!!!!!!!!');
  console.log('   DEPLOYING TO PRODUCTION   ');
  console.log('!!!!!!!!!! CAUTION !!!!!!!!!!');
  console.log('\x1b[0m'); // Reset color
}

Preventing Stack Deletion

For critical infrastructure stacks, you can enable termination protection:

const databaseStack = new DatabaseStack(app, 'ProductionDatabase', {
  terminationProtection: true, // Prevents accidental deletion
  // ...other properties
});

To delete this stack, you'll need to first disable termination protection using the AWS Console or AWS CLI.

# Enabled
aws cloudformation update-termination-protection --stack-name your-stackname --enable-termination-protection

# Disabled
aws cloudformation update-termination-protection --stack-name your-stackname --no-enable-termination-protection

Tagging Resources

Consistent tagging is essential for resource management, cost allocation, and security compliance. AWS CDK makes it easy to apply tags to all resources in your application or specific stacks:

// Tag all resources in the application
cdk.Tags.of(app).add('Project', 'MyProject');
cdk.Tags.of(app).add('Environment', envName);

// Tag all resources in a specific stack
cdk.Tags.of(myStack).add('Component', 'API');

// Apply additional tags
const tags: Record<string, string> = {
  'Owner': 'DevTeam',
  'CostCenter': 'CC1234',
  'Compliance': 'SOC2'
};
Object.entries(tags).forEach(([key, value]) => {
  cdk.Tags.of(app).add(key, value);
});

Linking AWS CLI Profiles to Environments

To reduce the risk of deploying to the wrong environment, you can create a convention that links your AWS CLI profiles to your environment names:

// package.json
{
  "scripts": {
    "deploy:all": "cdk deploy --all -c project=${npm_config_project} -c env=${npm_config_env} --profile ${npm_config_project}-${npm_config_env}",
    "destroy:all": "cdk destroy --all -c project=${npm_config_project} -c env=${npm_config_env} --profile ${npm_config_project}-${npm_config_env}"
  }
}

Usage:

npm run deploy:all --project=myapp --env=dev

This command uses the AWS CLI profile named myapp-dev for deployments to the development environment.

[profile myapp-dev]
region = us-west-2
[profile myapp-prod]
region = us-east-1

This approach ensures the AWS CLI profile matches the environment you're targeting, reducing the risk of deployment mistakes.

CDK Metadata: What It Is and When to Disable It

By default, CDK adds metadata to the generated CloudFormation templates for telemetry purposes. If you prefer not to include this metadata, you can disable it:

Version Reporting

see Configure AWS CDK Library usage data reporting

This information is used to improve the AWS CDK.
The AWS team collects and analyzes this information to understand how AWS CDK is being used.

CDKMetadata:
  CDKMetadata:
    Type: AWS::CDK::Metadata
    Properties:
      Analytics: v2:deflate64:H4sIAAAAAAAA/zPSszDXM1BMLC/WTU7J1s3JTNKrDi5JTM7WAQrFpyYb6Tmn5YUFOOsAqaDU4vzSouRUENs5Py8lsyQzP69WJy8/JVUvq1i/zMhAz1TPUDGrODNTt6g0ryQzN1UvCEIDANEI+cVnAAAA
    Metadata:
      aws:cdk:path: Dev/SandboxVPCBasic/CDKMetadata/Default

When to disable:

You have privacy or security concerns about sharing usage data
Your organization's policies prohibit telemetry
You want to minimize template size

How to disable:

cdk synth --version-reporting false
#or
cdk synth --no-version-reporting

Path Metadata

Path metadata provides a hierarchical view of your CDK constructs in the CloudFormation console, making it easier to understand the relationship between resources and their construct definitions.

With path metadata enabled (default):

The CloudFormation console displays a tree structure showing how constructs are organized in your CDK code. Each resource includes metadata like:

Resources:
  Vpc:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
    Metadata:
      aws:cdk:path: Dev/SandboxVPCBasic/Vpc/Resource

This path (Dev/SandboxVPCBasic/Vpc/Resource) shows exactly where this VPC is defined in your CDK construct hierarchy.

With path metadata disabled:

cdk synth --path-metadata false
#or
cdk synth --no-path-metadata

Without path metadata, the CloudFormation console shows a flat list of resources without the construct hierarchy.

Recommendation: Keep path metadata enabled (the default setting).

I know some teams disable this to reduce template size, and I respect that
decision, but in my view, the debugging benefits far outweigh the minimal size
savings. I've spent hours debugging CloudFormation stacks, and having the
construct hierarchy visible has saved me countless times.

Only consider disabling path metadata if you're hitting CloudFormation template size limits and have exhausted other optimization options.

Configuring Metadata in cdk.json

To permanently disable metadata in your project, add these settings to your cdk.json:

{
  "app": "npx ts-node bin/my-app.ts",
  "versionReporting": false,   // Disable version reporting
  "pathMetadata": false        // Not recommended - see above
}

Best practice: Consider disabling only versionReporting while keeping pathMetadata enabled for better operational visibility.

Conclusion

Adopting these AWS CDK development best practices will help you create infrastructure that is maintainable, scalable, and secure. The structure and patterns you establish early in your CDK journey will pay dividends as your infrastructure grows in complexity.

Organize your project with a clear directory structure that separates concerns
Think carefully about stack boundaries and the implications of cross-stack references
Follow consistent naming conventions for Construct IDs
Implement safety measures for production deployments
Use tags consistently across all resources
Align AWS CLI profiles with your environment names

In the next article, we'll explore how to test your AWS CDK applications effectively using snapshot tests, unit tests, and other validation techniques.

What project structure do you use for your CDK applications? Have you found other techniques that help manage multi-environment deployments? Share your experiences in the comments!

This article is part of the "Mastering AWS CDK" series, where we explore all aspects of using the AWS Cloud Development Kit for infrastructure as code.

AI-Powered Code Reviews with OpenRouter - Complete PR-Agent Setup Guide

TOMOAKI ishihara — Wed, 10 Sep 2025 23:58:20 +0000

👋 Introduction

Code reviews take time, and large teams often struggle with PR . PR-Agent (now Qodo Merge) uses AI to automatically review pull requests, generate descriptions, and suggest improvements.

This guide shows you how to set up PR-Agent with OpenRouter, giving you cost-effective access to multiple AI models (GPT-4o, Claude, Gemini, etc.) through a unified API.

📌 Why OpenRouter?

Challenges with Direct OpenAI API

Single provider dependency (OpenAI models only)
Complex management of multiple provider APIs
Difficult to compare pricing across different model

OpenRouter Benefits

Unified Multi-Model API - Access GPT-4o, Claude, Gemini, Llama, etc. through one interface
Flexible Model Selection - Choose the right model for each task, optimizing cost-effectiveness
Early Access to Latest Models - Quick access to new models like GPT-5
Transparent Pricing - Clear pricing for each model (5.5% fee on credit purchases)

Prerequisites

GitHub repository (private or public)
OpenRouter account (free to create)
GitHub Actions permissions

Step 1: OpenRouter Setup

1.1 Account Creation and API Key

Visit OpenRouter and create an account
Purchase Credits (Important)
- Go to the "Credits" page in your dashboard
- Minimum purchase is $5 (5.5% fee applies to credit purchases)
- Auto-recharge option available for convenience
- ⚠️ Free Tier: New accounts receive a small free credit allowance, but additional purchases are needed for production use(FAQ: What free tier options exist?)
In the dashboard, go to "API Keys" and generate a new key
Copy and securely store the key

1.2 Available Models

OpenRouter provides access to models like:

openai/gpt-5           # Latest model (2025 release)
openai/gpt-4o          # Balanced performance
anthropic/claude-3-opus-20240229  # High-quality analysis
google/gemini-pro      # Google's model
meta-llama/llama-2-70b-chat  # Open source

Check pricing at OpenRouter Models.

Step 2: GitHub Actions Workflow Setup

2.1 Configure Secrets

In your GitHub repository:

Go to Settings → Secrets and variables → Actions
Click "New repository secret"
Add the following secret:

Name: OPENROUTER_API_KEY
Value: or-xxxxxxxx (your OpenRouter API key)

2.2 Create Workflow File

Create .github/workflows/pr_agent.yml

name: Code Review(OpenRouter)

on:
  pull_request:
  pull_request_review_comment:
    types: [created]

# Concurrency control
concurrency:
  group: ${{ github.repository }}-${{ github.event.number || github.head_ref || github.sha }}-${{ github.workflow }}-${{ github.event_name == 'pull_request_review_comment' && 'pr_comment' || 'pr' }}
  cancel-in-progress: ${{ github.event_name != 'pull_request_review_comment' }}

jobs:
  pr_agent_job:
    if: |
      github.event.sender.type != 'Bot' &&
      github.event_name == 'pull_request' &&
      github.event.pull_request.changed_files < 50
    runs-on: ubuntu-latest
    permissions:
      issues: write
      pull-requests: write
      contents: write
      id-token: write
    name: Run pr agent on every pull request
    steps:
      - name: PR Agent action step with OpenRouter
        id: pragent
        uses: qodo-ai/pr-agent@main
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          OPENROUTER.KEY: ${{ secrets.OPENROUTER_API_KEY }} # OpenRouter API認証
          github_action_config.auto_review: "true" # enable\disable auto review
          github_action_config.auto_describe: "true" # enable\disable auto describe
          github_action_config.auto_improve: "true" # enable\disable auto improve

Step 3: Configuration File

Create .pr_agent.toml in your repository root.

[config]
model = "openai/gpt-5" # I specified gpt-5, but an error occurred. The correct setting is "openai/gpt-5".
fallback_models = ["openai/gpt-4o", "anthropic/claude-opus-4.1"]
ai_timeout = 300
custom_model_max_tokens = 200000 # Critical! Errors without this
response_language = "en-US"
ignore_pr_title = ["^\\[Auto\\]", "^Auto"]
ignore_pr_labels = ['invalid']

[ignore]
glob = ['dist/**']

[github_action_config]
# set as env var in .github/workflows/pr-agent.yaml
#auto_review = true
#auto_improve = true
#auto_describe = true

[pr_reviewer]
extra_instructions = """\
(1) Act as a highly experienced software engineer
(2) Provide thorough review of code, documents, and articles
(3) Suggest concrete code snippets for improvement

(4) **Never** comment on indentation, whitespace, blank lines, or other purely stylistic issues unless they change program semantics.

(5) **Priority Review Areas - Check systematically:**
- **Security**: Plaintext passwords, SQL injection, input validation, exception leaks
- **Error Handling**: Bare except clauses, missing try-catch, silent error suppression  
- **Resource Management**: Missing context managers (with statements), unclosed connections/files
- **Type Safety**: Missing type hints, incorrect type usage, unjustified Any types
- **Performance**: Inefficient algorithms (O(n²) or worse), unnecessary loops, memory leaks
- **Code Quality**: Magic numbers, unclear variable names, unused imports/variables
- **API Design**: Missing input validation, no error responses, required field checks
- **Architecture**: Single responsibility violations, tight coupling, global state usage

(6) Focus on concrete, actionable issues with specific code examples and fix recommendations.
"""
num_code_suggestions = 5
inline_code_comments = true
ask_and_reflect = true

[pr_description]
extra_instructions = "Generate clear and comprehensive descriptions"
generate_ai_title = true
add_original_user_description = false 
publish_description_as_comment = true

[pr_code_suggestions]
extra_instructions = "Provide actionable code suggestions with examples"
commitable_code_suggestions = true
demand_code_suggestions_self_review=true

Step 4: Testing the Setup

4.1 Create Test PR

Create a PR with intentionally problematic code.

# Missing type hints
def fizz_buzz(n):
    for i in range(1, n):
        if i % 15 == 0:
            print("FizzBuzz")
        elif i % 3 == 0:
            print("Fizz") 
        elif i % 5 == 0:
            print("Buzz")
        else:
            printo(i)  # Intentional bug

# Security issue
def add_user(name, password):
    users = []
    user = {"name": name, "password": password}  # Plaintext password
    users.append(user)

4.2 Expected Output

PR-Agent will provide.

Auto-generated PR Description:

Summary of changes
File-by-file change details
Impact analysis

Code Review Comments:

Fix for printo(i) → print(i)
Type hint suggestions
Security warning about plaintext passwords
Performance improvement suggestions

Step 5: Advanced Configuration

5.1 Cost Optimization

Use different models for different tasks.

[config]
model = "openai/gpt-4o-mini"  # For lightweight tasks
model_turbo = "openai/gpt-5"  # For complex analysis
fallback_models = ["anthropic/claude-3.7-sonnet", "google/gemini-2.5-pro"]

5.2 Team-Specific Rules

[pr_reviewer]
extra_instructions = """\
(1) Company-specific checks:
- Use structured logging for all log outputs
- External API calls must have timeout settings
- Database access must use transactions
- Never hardcode secrets (API keys, passwords, etc.)
"""

5.3 File Exclusions

[ignore]
glob = ['dist/**', '*.min.js', 'node_modules/**', '__pycache__/**']

[config]
ignore_pr_title = ["^\\[Auto\\]", "^WIP:", "^Draft:"]
ignore_pr_labels = ['work-in-progress', 'do-not-review']

Troubleshooting

Common Issues and Solutions

1. Model not recognized

Error: Model openai/gpt-5 is not defined in MAX_TOKENS
Solution: Add custom_model_max_tokens = 200000 to config

This error occurs when using a model that PR-Agent doesn't recognize. The models supported by PR-Agent are listed in this file. If your chosen model isn't in this list, you need to set the custom_model_max_tokens configuration.

2. Inconsistent language responses

[config]
response_language = "en-US"  # Be specific

[pr_reviewer]
extra_instructions = "Always respond in English and explain technical terms clearly"

3. GitHub Actions permission errors

permissions:
  issues: write
  pull-requests: write
  contents: write  # Add this line
  id-token: write

4. Timeouts on large PRs

[config]
ai_timeout = 600  # Extend to 10 minutes
large_patch_policy = "clip"  # Split large PRs

Cost Management Best Practices

1. Appropriate Model Selection

Task	Recommended Model	Pricing (approx.)
Simple reviews	gpt-4o-mini	$0.15/1M tokens
Detailed analysis	gpt-4o	$2.5/1M tokens
Highest quality	openai/gpt-5	$1.25/1M tokens

2. PR Size Limits

if: github.event.pull_request.changed_files < 50  # Limit file count

3. Control Automatic Execution

[config]
ignore_pr_labels = ['draft', 'wip', 'skip-ai-review']
ignore_pr_title = ["^\\[WIP\\]", "^Draft:", "^Auto"]

Impact Measurement

Before/After Comparison Metrics

Quantitative Metrics:

Reduced code review time
Increased bug detection
Earlier security issue identification
Faster PR merge times

Qualitative Metrics:

Reduced reviewer burden
Improved code quality
Learning effect (developer skill improvement)

Real-World Results Example

Before: Average review time 2 hours/PR
After: Average review time 45 minutes/PR (62% reduction)

Security issue detection:
- Before: 2 issues/month average
- After: 8 issues/month average (4x increase)

📝 Conclusion

Setting up PR-Agent with OpenRouter provides these benefits.

✅ Cost Performance - Use multiple models through OpenRouter for cost optimization

✅ Quality Improvement - Consistent review standards reduce oversights

✅ Efficiency - Significant reduction in review time

✅ Learning Effect - Developers learn best practices from AI feedback

✅ Flexibility - Customizable for team-specific requirements

We recommend starting with a small project for testing and gradually expanding. The configuration file allows extensive customization to match your team's needs.

📚 References

Hope this guide helps improve your code review process! Feel free to share questions or suggestions in the comments.

CloudFront ECDSA Signed URLs: 91% Faster Generation, 55% Shorter URLs

TOMOAKI ishihara — Wed, 10 Sep 2025 16:04:48 +0000

👋 Introduction

On September 9, 2025, Amazon CloudFront added support for ECDSA (Elliptic Curve Digital Signature Algorithm) keys in signed URLs. Previously limited to RSA-2048, CloudFront now supports ECDSA P-256 (prime256v1), enabling significantly faster signature generation and shorter URLs.

This article demonstrates implementing ECDSA signed URLs and compares performance with traditional RSA keys.

https://aws.amazon.com/about-aws/whats-new/2025/09/amazon-cloudfront-ecdsa-signed-urls/

📌 What's New

Key Changes

CloudFront signed URLs now support ECDSA (P-256) alongside RSA
Faster signature generation with lower CPU usage
Smaller signature size resulting in shorter URLs
Same security level as RSA with better performance

Expected Benefits

Performance: Faster signature generation for high-volume scenarios
Efficiency: Reduced CPU usage, ideal for resource-constrained environments
URL Length: Shorter URLs for SMS, QR codes, and other length-sensitive use cases

Implementation Guide

1. Generate Key Pairs

# Generate ECDSA P-256 private key
openssl ecparam -name prime256v1 -genkey -noout -out ecdsa-private.pem

# Generate public key
openssl ec -in ecdsa-private.pem -pubout -out ecdsa-public.pem

# For comparison, generate RSA keys
openssl genrsa -out rsa-private.pem 2048
openssl rsa -pubout -in rsa-private.pem -out rsa-public.pem

2. Register Public Keys with CloudFront

# Register ECDSA public key
ECDSA_KEY_CONTENT=$(cat ecdsa-public.pem)
ECDSA_KEY_RESPONSE=$(aws cloudfront create-public-key \
    --public-key-config \
    Name="ecdsa-signing-key",CallerReference="$(date +%s)",EncodedKey="$ECDSA_KEY_CONTENT",Comment="ECDSA P-256 key for signed URLs")

ECDSA_KEY_ID=$(echo $ECDSA_KEY_RESPONSE | jq -r '.PublicKey.Id')
echo "ECDSA Key ID: $ECDSA_KEY_ID"

3. Create Key Groups

# Create ECDSA key group
ECDSA_KEY_GROUP_RESPONSE=$(aws cloudfront create-key-group \
    --key-group-config \
    Name="ecdsa-key-group",Items="$ECDSA_KEY_ID",Comment="ECDSA key group")

ECDSA_KEY_GROUP_ID=$(echo $ECDSA_KEY_GROUP_RESPONSE | jq -r '.KeyGroup.Id')

4. Configure CloudFront Distribution

⚠️ Important: Update your CloudFront distribution behavior settings.

Go to your distribution's "Behaviors" tab
Edit the relevant behavior
Set "Restrict viewer access" to "Yes"
Set "Trusted authorization type" to "Trusted key groups"
Select your created key group

5. Generate Signed URLs

AWS CLI Limitation

⚠️ Important: As of September 9, 2025, the AWS CLI's cloudfront sign command doesn't support ECDSA keys and throws an error saying it's not an RSA key.

# aws --version
# aws-cli/2.29.0 
# This will fail with ECDSA keys
aws cloudfront sign --url https://example.com/file.jpg \
    --key-pair-id $ECDSA_KEY_ID \
    --private-key file://ecdsa-private.pem \
    --date-less-than "2025-09-10T12:09:03Z"
# Error: RSA private key not found in PEM.

Python Implementation

Here's a working Python implementation for ECDSA signed URLs.

# ecdsa_signer.py
import sys
import time
from botocore.signers import CloudFrontSigner
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives.serialization import load_pem_private_key
from cryptography.hazmat.backends import default_backend
import os
from datetime import datetime

def ecdsa_signer(message):
    with open("ecdsa-private.pem", "rb") as key_file:
        private_key = load_pem_private_key(
            key_file.read(), password=None, backend=default_backend()
        )
    return private_key.sign(message, ec.ECDSA(hashes.SHA1()))

def generate_signed_url(url, key_pair_id, date_less_than):
    start_time = time.time()

    cf_signer = CloudFrontSigner(key_pair_id, ecdsa_signer)
    signed_url = cf_signer.generate_presigned_url(
        url,
        date_less_than=datetime.fromisoformat(date_less_than.replace("Z", "+00:00")),
    )

    processing_time_ms = (time.time() - start_time) * 1000
    print(f"ECDSA processing time: {processing_time_ms:.2f}ms", file=sys.stderr)

    return signed_url

if __name__ == "__main__":
    url = sys.argv[1] if len(sys.argv) > 1 else "https://example.com/file.jpg"
    expiry_time = sys.argv[2] if len(sys.argv) > 2 else "2025-09-10T12:09:03Z"
    key_pair_id = os.environ.get("ECDSA_KEY_ID")

    signed_url = generate_signed_url(url, key_pair_id, expiry_time)
    print(signed_url)

Performance Comparison

I ran performance tests comparing RSA and ECDSA signature generation.

Results Summary

Test Runs	RSA Average	ECDSA Average	Improvement	RSA StdDev	ECDSA StdDev
1	36.47ms	3.04ms	91.7%	0.00ms	0.00ms
10	35.93ms	3.00ms	91.6%	2.54ms	0.31ms
20	33.54ms	2.60ms	92.2%	0.98ms	0.21ms
100	34.39ms	2.91ms	91.5%	1.33ms	0.58ms

Key Findings

Performance: ECDSA is ~12x faster than RSA (91% improvement)
URL Length: 55.1% shorter URLs (RSA: 448 chars → ECDSA: 201 chars)
Consistency: Lower standard deviation shows more stable performance

Real URL Examples

RSA Signed URL (448 characters):

https://example.com/private-files/uploadtest.jpg?Expires=1757511063&Signature=TNGmM2jrc5GRTalKgYhdZla1uaR~gOiX4HevKDMBbe5JkecwxGe0VoCqXB5KnCPgetRbbBE6JCtOdCYiTwGYxKpByOBJTMaS5Z3H9rqhln~wqQ0KZ-q5-lqvEPsxXlbBXbzJ0MDwNgzcCcu3GavsYGiceFr0veGw5RuYNLSs49HdFUKtdk~7wpI~bjdHzLDSaxoTKtIz0HDgii~VTPP769X~aOmG7~W0hm23nBP4WcTDe6Z8YvDRr61TqjixkNYrh4FiuUFFVuA2Tn0FUuaxcU5qVhtcl0ng8QqoyHUwWFju65h6g0TUM2iueJudQtV-CcoYf-UHlVOGQ39pnG9HxQ__&Key-Pair-Id=ZZZZZZZZZZZZZ

ECDSA Signed URL (201 characters):

https://example.com/private-files/uploadtest.jpg?Expires=1757511063&Signature=MEQCIBO~LD6qEaVjiwGFFF233dOB~XJvi7SPhubaN0FjFsigAiBlLZAYz9sCp6aY93bE9z0SuZDhEH3Pw8uL-9rPODVbQw__&Key-Pair-Id=WWWWWWWWWWWWWW

When to Use ECDSA

ECDSA is particularly beneficial for:

High-volume URL generation: APIs generating many signed URLs
Mobile/IoT devices: Resource-constrained environments
URL length constraints: SMS, QR codes, social media
Real-time applications: Where response time is critical

Conclusion

CloudFront's ECDSA support delivers significant performance improvements and URL size reductions. For high-load systems or resource-constrained environments, ECDSA provides substantial benefits while maintaining the same security level as RSA.

The 91% performance improvement and 53% URL size reduction make ECDSA a compelling choice for modern applications requiring efficient signed URL generation.

Resources

Have you tried ECDSA signed URLs in your CloudFront setup? Share your experience in the comments!

DEV Community: TOMOAKI ishihara

AWS CDK 100 Drill Exercises #007: SQS-Lambda-Firehose —— Building Event-Driven Data Pipelines

Introduction

Why SQS-Lambda-Firehose?

What You'll Learn

Architecture Overview

Data Flow

Key Components and Design Points

Implementation Highlights

1. SQS + Dead Letter Queue

2. Lambda - ReportBatchItemFailures

Without Powertools vs With Powertools

3. Firehose - Partitioned Delivery

4. S3 Lifecycle Management

CloudWatch Monitoring

Alarm List

DLQ Alarm (Most Critical)

Firehose Quota Monitoring (Math Expression)

Deployment & Verification

Best Practices Summary

Cost Estimation

Summary

References

AWS CDK 100 Drill Exercises #006: VPC Peering - Cross-Account Network Integration and DNS Resolution Automation

Introduction

Why VPC Peering?

What You'll Learn

Architecture Overview

Configuration Pattern

Key Components

Prerequisites

Project Directory Structure

Cross-Account Reference Challenges in CDK

Problem: CloudFormation Runtime Limitations

Why doesn't it work?

Solutions

1. Manual Parameter Passing via CDK Context or Environment Variable Files

2. Parameter Store and AWS Custom Resources

VPC Peering Within Same Account

VpcAStack Implementation

VPC Peering Construct

Cross-Account VPC Peering

Implementation

VpcCStack (Account B)

CrossAccountPeeringStack (Account A)

VpcCRoutesStack (Account B)

VPC Peering DNS Resolution Options Automation (Custom Resource Implementation Example)

Why DNS Resolution Options are Needed

For Same Account

For Cross-Account

Deployment and Cleanup

1. Environment Parameter Configuration

2. Bootstrap

1. Bootstrap Account A (pipeline account)

2. Bootstrap Account B (target account)

How --trust option works

1. IAM Role Creation

3. Deployment

4. Connection Verification

5. Cleanup

Summary

What We Learned

References

AWS CDK 100 Drill Exercises #005: CDK Parameters —— Managing Parameters with TypeScript vs cdk.json

Introduction

Why is Parameter Management Important?

What You'll Learn

Architecture Overview

1. TypeScript Parameters (CdkTSParametersStack)

2. cdk.json Parameters (CdkJsonParametersStack)

Prerequisites

Project Directory Structure

Pattern 1: Defining Parameters in TypeScript Files

Creating Type Definitions

Environment-Specific Parameter Files

Stack Using Parameters

Entry Point and Deployment Validation

Deployment Method

Pros and Cons of TypeScript Approach

Pattern 2: Defining Parameters in cdk.json

How `--trust` option works