createdAt: { S: timestamp },
  payload: { S: JSON.stringify(order) },
},

});

await dynamo.send(command);

return { statusCode: 202, body: JSON.stringify({ orderId, status: "accepted" }), }; };

### Step 4: Adopt Managed Data Stores with Consistency Models
Replace self-managed databases with managed services that align with your consistency requirements. Use DynamoDB or Cosmos DB for eventual consistency and high throughput. Reserve PostgreSQL/MySQL for transactional boundaries that require ACID guarantees. Partition data by access patterns, not by entity relationships.

### Step 5: Infrastructure as Code and Observability from Day One
Define all resources declaratively. Implement structured logging, distributed tracing, and metric emission at the function boundary. Cloud evolution fails when observability is retrofitted.

**Architecture Decisions and Rationale:**
- **Event-driven over synchronous:** Reduces coupling, enables replay, and isolates failures. Synchronous chains create cascading latency and tight scaling dependencies.
- **Stateless compute over embedded state:** Functions scale horizontally without session affinity. State is externalized to managed stores, eliminating warm-up penalties and enabling zero-downtime deployments.
- **Managed services over self-hosted:** Reduces operational toil, provides automatic patching, and aligns cost with actual usage. The trade-off is vendor lock-in, which is mitigated by abstracting data access layers and avoiding proprietary query languages.
- **TypeScript across infrastructure and runtime:** Provides type safety for IAM policies, event schemas, and runtime contracts. Shared interfaces prevent schema drift between publishers and consumers.

## Pitfall Guide

### 1. Lift-and-Shift Without State Decoupling
Migrating stateful workloads without extracting session data, file attachments, or cache layers creates hidden bottlenecks. Stateless compute cannot scale if state remains embedded.
**Best Practice:** Audit all stateful dependencies before migration. Externalize sessions to Redis/Memcached, files to object storage, and caches to managed layers. Validate statelessness through load testing.

### 2. Ignoring Cold Start Latency in Serverless
Function initialization delays impact user experience and SLA compliance. Teams often assume serverless is instantly responsive.
**Best Practice:** Use provisioned concurrency for latency-sensitive paths. Implement warm-up strategies for background workers. Optimize bundle size and dependency tree to reduce initialization time.

### 3. Premature Microservice Fragmentation
Splitting a monolith into dozens of services before establishing clear bounded contexts creates distributed monoliths. Network latency, transaction management, and deployment coordination become unmanageable.
**Best Practice:** Start with a modular monolith. Decompose only when scaling, team ownership, or failure isolation requires it. Use event contracts to define boundaries before code separation.

### 4. Over-Provisioned IAM Roles
Granting broad permissions during migration creates security debt and violates least privilege. Cloud providers enforce strict IAM boundaries; legacy applications often assume root or admin access.
**Best Practice:** Use policy generators and runtime permission audits. Scope roles to specific resource ARNs and actions. Implement IAM Access Analyzer to detect unused permissions.

### 5. Data Gravity and Egress Cost Blindness
Moving compute to the cloud while leaving data on-premises or in incompatible regions creates latency spikes and unpredictable egress bills. Cloud economics assume data locality.
**Best Practice:** Colocate compute and data. Use regional data replication only when compliance requires it. Implement caching layers and CDN offloading to reduce origin fetches.

### 6. Treating Cloud as Static Infrastructure
Provisioning fixed capacity and expecting cloud elasticity is contradictory. Cloud platforms reward dynamic scaling and penalize over-provisioning with wasted spend.
**Best Practice:** Implement auto-scaling policies based on queue depth, CPU, or custom metrics. Use spot/preemptible instances for fault-tolerant workloads. Design for graceful degradation during capacity constraints.

### 7. Skipping Chaos and Resilience Testing
Cloud-native architectures assume component failure. Applications migrated without resilience patterns fail catastrophically during partial outages.
**Best Practice:** Implement circuit breakers, exponential backoff, and idempotent operations. Run chaos experiments targeting message queues, database connections, and downstream APIs. Validate recovery paths before production deployment.

## Production Bundle

### Action Checklist
- [ ] Map bounded contexts: Identify domain boundaries and state dependencies before architectural changes.
- [ ] Externalize state: Migrate sessions, caches, and file storage to managed services.
- [ ] Implement event contracts: Define schema versions and backward compatibility rules for all publishers/consumers.
- [ ] Deploy infrastructure as code: Provision all resources through TypeScript/CDK or Terraform with state locking.
- [ ] Enable observability: Instrument distributed tracing, structured logging, and custom metrics at function boundaries.
- [ ] Configure auto-scaling: Set scaling policies based on queue depth or throughput, not fixed CPU thresholds.
- [ ] Run resilience tests: Validate circuit breakers, retries, and idempotency under simulated partial failures.

### Decision Matrix

| Scenario | Recommended Approach | Why | Cost Impact |
|----------|---------------------|-----|-------------|
| Legacy monolith with tight coupling | Modular monolith → Event decomposition | Reduces risk while establishing async boundaries | Low initial, scales with decomposition |
| High-traffic burst workload | Serverless functions + CDN + queue buffering | Matches compute to demand, absorbs spikes | Pay-per-use, avoids over-provisioning |
| Multi-region compliance requirement | Active-passive replication with regional data stores | Meets data residency without cross-region latency | Moderate (replication + regional infra) |
| Data-intensive batch processing | Managed Spark/Fargate + object storage | Scales compute independently of storage | High compute cost, low storage cost |

### Configuration Template

```typescript
// cdk-stack.ts
import * as cdk from "aws-cdk-lib";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as events from "aws-cdk-lib/aws-events";
import * as targets from "aws-cdk-lib/aws-events-targets";
import * as dynamodb from "aws-cdk-lib/aws-dynamodb";
import { Construct } from "constructs";

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

    const table = new dynamodb.Table(this, "OrdersTable", {
      partitionKey: { name: "orderId", type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
      encryption: dynamodb.TableEncryption.AWS_MANAGED,
    });

    const processor = new lambda.Function(this, "OrderProcessor", {
      runtime: lambda.Runtime.NODEJS_20_X,
      handler: "order-processor.handler",
      code: lambda.Code.fromAsset("dist"),
      environment: {
        ORDERS_TABLE: table.tableName,
        AWS_NODEJS_CONNECTION_REUSE_ENABLED: "1",
      },
      timeout: cdk.Duration.seconds(10),
      memorySize: 256,
    });

    table.grantReadWriteData(processor);

    const bus = new events.EventBus(this, "OrderEventBus");

    const rule = new events.Rule(this, "OrderEventRule", {
      eventBus: bus,
      eventPattern: {
        source: ["com.order.system"],
        detailType: ["OrderCreated"],
      },
    });

    rule.addTarget(new targets.LambdaFunction(processor));

    new cdk.CfnOutput(this, "EventBusArn", { value: bus.eventBusArn });
    new cdk.CfnOutput(this, "ProcessorFunctionArn", { value: processor.functionArn });
  }
}

Quick Start Guide

1. Initialize project: Run npm init -y && npm install aws-cdk-lib constructs @aws-sdk/client-* and configure AWS credentials via aws configure.
2. Define stack: Copy the configuration template into lib/cdk-stack.ts. Adjust region and environment variables to match your account.
3. Synthesize and deploy: Execute cdk bootstrap followed by cdk deploy. Verify resource creation in the AWS console and note the EventBus and Lambda ARNs.
4. Test event flow: Publish a test event using the AWS CLI or SDK. Confirm the Lambda function processes the payload and writes to DynamoDB. Validate tracing and logs in CloudWatch.
5. Iterate architecture: Add consumer functions, implement schema validation, and configure auto-scaling policies. Decompose additional bounded contexts using the same event-driven pattern.