cdk.json - Environment & Policy Configuration

mplementation follows four technical phases.

Phase 1: Workload Partitioning & Execution Model Mapping

Classify existing workloads by execution characteristics:

• Request-driven: User-facing APIs, webhooks, synchronous transactions
• Event-driven: Data ingestion, background processing, state transitions
• Batch/AI: ML inference, vector search, ETL pipelines, model training

Map each category to the appropriate runtime:

• Request-driven → API Gateway + Serverless Functions or Edge Compute
• Event-driven → Message Queue + Stateless Processors + Managed State
• Batch/AI → GPU Serverless or Dedicated AI Inference Endpoints + Object Storage

Phase 2: Event Mesh & State Management

Replace synchronous coupling with asynchronous event routing. Use managed message brokers to decouple producers and consumers. Implement idempotent processors with explicit retry policies and dead-letter queues. Store state in managed databases with partition keys aligned to access patterns. Avoid self-hosted state stores unless compliance or latency dictates otherwise.

Phase 3: Infrastructure as Code with Policy Enforcement

Define all resources declaratively. Enforce least-privilege IAM, network isolation, and cost guardrails at deployment time. Use policy-as-code to prevent drift and enforce compliance before resources provision.

Phase 4: Observability & Auto-Scaling Configuration

Instrument distributed traces, metrics, and logs at the service boundary. Configure auto-scaling based on queue depth, request latency, or CPU/memory thresholds rather than static capacity. Implement circuit breakers for downstream dependencies.

Code Example: Event-Driven Processor Stack (TypeScript + AWS CDK)

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

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

    // Managed state: Partitioned table with TTL for ephemeral data
    const stateTable = new dynamodb.Table(this, 'ExecutionState', {
      partitionKey: { name: 'eventId', type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
      timeToLiveAttribute: 'ttl',
      encryption: dynamodb.TableEncryption.AWS_MANAGED,
    });

    // Event broker: DLQ for failed executions, visibility timeout aligned to processor
    const dlq = new sqs.Queue(this, 'DeadLetterQueue', {
      retentionPeriod: cdk.Duration.days(14),
      encryption: sqs.QueueEncryption.KMS_MANAGED,
    });

    const eventQueue = new sqs.Queue(this, 'EventProcessorQueue', {
      visibilityTimeout: cdk.Duration.seconds(300),
      deadLetterQueue: { maxReceiveCount: 3, queue: dlq },
      encryption: sqs.QueueEncryption.KMS_MANAGED,
    });

    // Stateless compute: Provisioned concurrency for warm starts, environment-driven config
    const processor = new lambda.Function(this, 'EventProcessor', {
      runtime: lambda.Runtime.NODEJS_18_X,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('lambda'),
      environment: {
        STATE_TABLE: stateTable.tableName,
        QUEUE_URL: eventQueue.queueUrl,
        MAX_RETRIES: '3',
      },
      timeout: cdk.Duration.seconds(60),
      memorySize: 512,
      tracing: lambda.Tracing.ACTIVE,
      reservedConcurrentExecutions: 100,
    });

    // IAM: Least privilege, scoped to specific ARNs
    processor.addToRolePolicy(new iam.PolicyStatement({
      actions: ['dynamodb:PutItem', 'dynamodb:GetItem', 'dynamodb:UpdateItem'],
      resources: [stateTable.tableArn],
    }));

    processor.addToRolePolicy(new iam.PolicyStatement({
      actions: ['sqs:ReceiveMessage', 'sqs:DeleteMessage', 'sqs:GetQueueAttributes'],
      resources: [eventQueue.queueArn],
    }));

    // Event source mapping: Batch processing with configurable window
    processor.addEventSource(new lambda.SqsEventSource(eventQueue, {
      batchSize: 10,
      maxBatchingWindow: cdk.Duration.seconds(5),
      reportBatchItemFailures: true,
    }));

    new cdk.CfnOutput(this, 'QueueUrl', { value: eventQueue.queueUrl });
    new cdk.CfnOutput(this, 'ProcessorArn', { value: processor.functionArn });
  }
}

Architecture Decisions & Rationale

• Managed over self-hosted: Reduces operational overhead, eliminates patching, and provides deterministic scaling.
• Event-driven boundaries: Decouples producers from consumers, enables independent scaling, and isolates failures.
• Idempotent processors: Prevents duplicate state mutations during retries or scale-out events.
• Policy-enforced IAM: Prevents privilege escalation and aligns with zero-trust cloud security models.
• Observability-first: Active tracing and structured logging enable rapid root-cause analysis in distributed systems.

Pitfall Guide

1. Lift-and-Shift Without Runtime Refactoring Migrating VMs or monoliths to cloud infrastructure without redesigning execution boundaries preserves architectural debt. Cloud platforms optimize for stateless, event-driven workloads. Running synchronous, stateful services on elastic compute creates scaling mismatches and cost inflation. Refactor execution models before deployment.

2. Ignoring Cold Start & State Boundaries Serverless functions experience cold starts when provisioned capacity is exhausted or after idle periods. Assuming zero-latency startup leads to SLA violations. Pre-warm critical paths, use provisioned concurrency for latency-sensitive endpoints, and externalize state to managed databases or caches.

3. Over-Provisioning with "Just-in-Case" Scaling Static auto-scaling rules based on CPU or memory thresholds ignore workload characteristics. Event-driven systems should scale on queue depth, request latency, or custom metrics. Over-provisioning wastes spend and increases blast radius during failures.

4. Neglecting Data Egress & Cross-Region Latency Cloud providers charge for data leaving their network. Architectures that replicate data across regions or pull external datasets into compute layers incur hidden costs. Co-locate compute and data, use CDN edge caching, and compress payloads before transmission.

5. Treating Serverless as Stateless Monoliths Packing multiple responsibilities into a single function violates single-responsibility principles and complicates scaling, testing, and observability. Decompose by domain boundary. Each function should handle one execution type with explicit input/output contracts.

6. Skipping Policy-as-Code Early Manual resource configuration drifts over time, creating security gaps and compliance violations. Enforce IAM, network, and encryption policies at deployment time. Use tools like AWS CDK, Terraform with OPA, or platform-native policy engines to prevent non-compliant resources.

7. Misaligning Observability with Business Metrics Tracking only infrastructure metrics (CPU, memory, disk) misses application-level failures. Instrument distributed traces, error rates, latency percentiles, and business KPIs. Correlate technical metrics with user impact to prioritize incident response.

Best Practices from Production:

• Start with domain boundaries, not infrastructure templates.
• Use managed services aggressively; self-host only when compliance or latency dictates.
• Implement cost anomaly detection and budget alerts at the account level.
• Design idempotent processors with explicit retry and dead-letter handling.
• Leverage AI-native services (vector DBs, inference endpoints) instead of building custom ML pipelines.
• Enforce circuit breakers and fallbacks for all external dependencies.
• Version infrastructure code alongside application code; treat deployments as immutable.

Production Bundle

Action Checklist

• Audit existing workloads: Classify each service by execution model (request-driven, event-driven, batch/AI) and map to appropriate runtime.
• Implement event-driven boundaries: Replace synchronous calls with managed message brokers and idempotent processors.
• Deploy infrastructure as code: Define all resources declaratively with IAM, network, and encryption policies enforced at synthesis.
• Configure observability: Instrument distributed traces, structured logs, and business-aligned metrics before production deployment.
• Enable cost guardrails: Set budget alerts, enable idle resource detection, and enforce auto-scaling on queue depth or latency thresholds.
• Validate idempotency: Test processors with duplicate events, network timeouts, and scale-out scenarios to prevent state corruption.
• Implement fallback mechanisms: Add circuit breakers, dead-letter queues, and graceful degradation for all external dependencies.
• Document runbooks: Create incident response procedures aligned with new execution models, scaling behaviors, and observability dashboards.

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
Real-time user-facing API (<100ms target)	Edge compute + serverless functions	Minimizes latency, scales on demand, eliminates idle capacity	Low (pay-per-request, no baseline VM cost)
High-volume background processing	Event queue + stateless processors + managed DB	Decouples producers, enables batch processing, isolates failures	Medium (queue + compute + storage, but scales linearly)
AI inference with vector search	Managed AI endpoint + vector database	Native optimization, GPU provisioning handled by platform, reduces ML ops overhead	High initial, but drops 40-60% vs self-hosted GPU clusters
Compliance-bound data pipeline	Private VPC + dedicated compute + encrypted managed storage	Meets regulatory requirements while retaining cloud scalability	Medium-High (dedicated resources, but eliminates on-prem maintenance)

Configuration Template

# cdk.json - Environment & Policy Configuration
{
  "app": "npx ts-node --prefer-ts-exts bin/modern-cloud.ts",
  "context": {
    "environment": "production",
    "region": "us-east-1",
    "costGuardrails": {
      "budgetThreshold": 1500,
      "alertEmail": "ops@company.com",
      "idleResourceScan": true
    },
    "policyEnforcement": {
      "iamLeastPrivilege": true,
      "encryptionAtRest": true,
      "vpcFlowLogs": true,
      "wafEnabled": true
    },
    "observability": {
      "tracingEnabled": true,
      "logRetentionDays": 30,
      "metricsExport": "cloudwatch"
    }
  }
}

Quick Start Guide

1. Install AWS CDK v2 and initialize a TypeScript project: npm init -y && npm install aws-cdk-lib constructs && cdk init app --language typescript
2. Replace bin/ and lib/ files with the provided stack code and configuration template.
3. Synthesize and validate: cdk synth && cdk diff to review IAM, network, and cost implications before deployment.
4. Deploy to target environment: cdk deploy --require-approval never and verify queue URL and processor ARN in outputs.
5. Test end-to-end: Send a sample event to the SQS queue, monitor CloudWatch metrics, and validate state persistence in DynamoDB. Full deployment under 5 minutes.