Infrastructure as Code (AWS CDK)

// infrastructure/lambda-stack.ts
import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';

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

    // DynamoDB table with on-demand billing
    const table = new dynamodb.Table(this, 'UsersTable', {
      partitionKey: { name: 'userId', type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
      pointInTimeRecovery: true,
      encryption: dynamodb.TableEncryption.AWS_MANAGED,
      removalPolicy: cdk.RemovalPolicy.RETAIN,
    });

    // Lambda function with 2026 best practices
    const userProcessor = new NodejsFunction(this, 'UserProcessor', {
      runtime: lambda.Runtime.NODEJS_20_X,
      architecture: lambda.Architecture.ARM_64, // Graviton2
      handler: 'handler',
      entry: 'src/handlers/processUser.ts',
      timeout: cdk.Duration.seconds(10),
      memorySize: 1769, // Price-performance sweet spot
      environment: {
        TABLE_NAME: table.tableName,
        POWERTOOLS_SERVICE_NAME: 'user-processor',
        POWERTOOLS_METRICS_NAMESPACE: 'UserService',
        LOG_LEVEL: 'INFO',
      },
      bundling: {
        minify: true,
        sourceMap: true,
        target: 'es2022',
        format: lambda.OutputFormat.ESM,
      },
      tracing: lambda.Tracing.ACTIVE,
      insightsVersion: lambda.LambdaInsightsVersion.VERSION_1_0_229_0,
      reservedConcurrentExecutions: 100, // Prevent runaway costs
    });

    table.grantWriteData(userProcessor);
  }
}

Common Pitfalls and How to Avoid Them

1. Ignoring Cold Start Impact

Problem: Default configurations lead to 2-5 second cold starts. Solution: Use ARM64, optimize bundle size with tree-shaking, implement provisioned concurrency for critical paths, and leverage Lambda SnapStart where applicable.

2. Over-Provisioning Memory

Problem: Setting 3GB memory when 512MB suffices wastes 83% of costs. Solution: Use AWS Lambda Power Tuning to find the optimal memory configuration. The sweet spot is often 1769MB (1 full vCPU).

3. Missing Observability

Problem: No structured logging or distributed tracing makes debugging impossible. Solution: Implement AWS Powertools from day one. Add correlation IDs, structured logs, and custom metrics.

4. Synchronous Processing Anti-Pattern

Problem: Lambda waiting for long-running operations blocks execution time. Solution: Use Step Functions for orchestration, SQS for async processing, and EventBridge for event-driven workflows.

5. Inadequate Error Handling

Problem: Unhandled exceptions cause silent failures and data loss. Solution: Implement dead-letter queues, exponential backoff with jitter, and circuit breakers for external dependencies.

6. Security Misconfigurations

Problem: Overly permissive IAM roles violate least privilege. Solution: Use IAM policy conditions, resource-based policies, and AWS IAM Access Analyzer to validate permissions.

Best Practices Checklist

• [ ] Architecture: ARM64 Graviton processors for cost-performance optimization
• [ ] Memory: Profiled and optimized using Lambda Power Tuning
• [ ] Timeout: Set to realistic values (avoid default 3 seconds or maximum 15 minutes)
• [ ] Concurrency: Reserved concurrency configured to prevent cost overruns
• [ ] Bundling: Minified, tree-shaken bundles under 5MB compressed
• [ ] Dependencies: AWS SDK v3 with modular imports, minimal external packages
• [ ] Logging: Structured JSON logs with correlation IDs via Powertools
• [ ] Metrics: Custom CloudWatch metrics for business KPIs
• [ ] Tracing: X-Ray active tracing with annotated segments
• [ ] Error Handling: Dead-letter queues and retry policies configured
• [ ] Security: Least-privilege IAM roles, secrets in Secrets Manager
• [ ] Networking: VPC configuration only when required, use PrivateLink
• [ ] Deployment: Blue-green deployments with automated rollback
• [ ] Testing: Unit tests for business logic, integration tests for AWS services
• [ ] Cost Monitoring: CloudWatch alarms on invocation count and duration

Frequently Asked Questions

What is the optimal memory configuration for AWS Lambda in 2026?

The optimal memory depends on your workload, but 1769MB is often the sweet spot because it provides a full vCPU. Use AWS Lambda Power Tuning to profile your function across memory configurations. ARM64 Graviton processors offer 34% better price-performance, making them the default choice for new functions.

How do I reduce Lambda cold start times to under 500ms?

Implement these strategies: (1) Use ARM64 architecture, (2) minimize bundle size through tree-shaking and code splitting, (3) initialize SDK clients outside the handler, (4) leverage Lambda SnapStart for Java/.NET, (5) implement provisioned concurrency for latency-critical functions, and (6) use Lambda function URLs to reduce API Gateway overhead.

Should I use provisioned concurrency or on-demand scaling?

Use provisioned concurrency only for latency-critical functions with predictable traffic patterns (e.g., user-facing APIs). For background processing, scheduled tasks, or bursty workloads, on-demand scaling is more cost-effective. Monitor P99 latency—if cold starts affect user experience, provision 10-20% of peak concurrency.

How do I implement proper observability for Lambda functions?

Use AWS Lambda Powertools for structured logging, custom metrics, and distributed tracing. Enable X-Ray active tracing, CloudWatch Lambda Insights for runtime metrics, and implement correlation IDs across service boundaries. Create CloudWatch dashboards for key metrics: invocation count, error rate, duration, and throttles.

What's the best way to manage secrets in Lambda functions?

Store secrets in AWS Secrets Manager or Parameter Store (encrypted). Use Lambda environment variables only for non-sensitive configuration. Implement secret caching with TTL to reduce API calls. For database credentials, use IAM database authentication when possible. Never hardcode secrets or commit them to version control.

How can I prevent Lambda cost overruns in production?

Set reserved concurrent executions to cap maximum invocations, implement CloudWatch billing alarms, use AWS Budgets for cost tracking, optimize memory allocation, reduce execution time through code optimization, implement request throttling at API Gateway, and use SQS for rate limiting. Monitor cost per invocation and set alerts for anomalies.

What deployment strategy should I use for Lambda functions?

Implement blue-green deployments using Lambda aliases and weighted traffic shifting. Start with 10% traffic to the new version, monitor error rates and latency for 5-10 minutes, then gradually shift to 50% and 100%. Configure automatic rollback on CloudWatch alarms. Use AWS SAM or CDK for infrastructure as code and consistent deployments across environments.

Actionable Conclusion

Building production-grade serverless applications in 2026 requires more than just deploying Lambda functions—it demands a holistic approach to performance, cost, security, and observability.

Start here: Implement the TypeScript example above as your baseline template. It incorporates AWS Powertools for observability, proper error handling, input validation, and follows 2026 architectural patterns.

Next steps:

1. Profile your functions with Lambda Power Tuning this week
2. Migrate to ARM64 Graviton processors for immediate cost savings
3. Implement structured logging and distributed tracing across all functions
4. Set up CloudWatch alarms for cost anomalies and error rates
5. Review IAM policies with Access Analyzer to enforce least privilege

The serverless paradigm has matured from experimental to enterprise-ready. By following these 2026 best practices, you'll build Lambda functions that scale efficiently, remain cost-effective, and deliver the performance your users expect. The key is treating serverless as a production architecture from day one—not as a prototype that "we'll optimize later."

Your serverless journey doesn't end with deployment. Continuously monitor, optimize, and iterate based on real-world metrics. The practices outlined here provide a foundation, but your specific workload will reveal unique optimization opportunities. Start implementing today, and you'll avoid the costly mistakes that plague poorly architected serverless applications.