Lambda production defaults

FsCDK bakes in the guidance from AWS Heroes Yan Cui, Heitor Lessa, and Alex Casalboni, along with the AWS Lambda Operator Guide, so every function starts production-ready without additional wiring.

Lambda Production Architecture

Why these defaults matter

Serverless workloads succeed when they: - Retain failed events – DLQs capture payloads for replay and debugging. - Control spend and contention – Reserved concurrency prevents noisy neighbours. - Emit rich telemetry – JSON logs, X-Ray tracing, and Powertools illuminate behaviour. - Fail predictably – Retry and event-age limits avoid infinite loops and stale updates.

FsCDK turns these best practices into defaults so you don’t have to wire them by hand.

Defaults applied to every function

Every Lambda function in FsCDK automatically gets these production-safe defaults:

Basic usage (defaults already applied)

#r "../src/bin/Release/net8.0/publish/Amazon.JSII.Runtime.dll"
#r "../src/bin/Release/net8.0/publish/Constructs.dll"
#r "../src/bin/Release/net8.0/publish/Amazon.CDK.Lib.dll"
#r "../src/bin/Release/net8.0/publish/FsCDK.dll"

#r "nuget: Amazon.CDK.Lib, 2.128.0"

open Amazon.CDK
open Amazon.CDK.AWS.Lambda
open FsCDK

let app = App()

stack "ProductionStack" {
    scope app

    lambda "OrderProcessor" {
        handler "index.handler"
        runtime Runtime.PYTHON_3_11
        code "./src"

        environment [ "TABLE_NAME", "orders-table"; "POWERTOOLS_SERVICE_NAME", "order-service" ] // Powertools auto-configured
    }
// Reserved concurrency = 10
// X-Ray tracing enabled
// JSON logging enabled
// DLQ auto-created: "OrderProcessor-dlq"
// Powertools layer added automatically
// Max event age = 6 hours
// Retry attempts = 2
}

Overriding defaults

When you understand traffic patterns and operational maturity, override the presets. Follow the decision points outlined in Production-Ready Serverless and validate changes through load tests before relaxing safeguards:

stack "CustomStack" {
    scope app

    // High-throughput function
    lambda "HighVolumeProcessor" {
        handler "index.handler"
        runtime Runtime.NODEJS_20_X
        code "./dist"

        // Override defaults
        reservedConcurrentExecutions 500 // Allow higher concurrency
        tracing Tracing.PASS_THROUGH // Disable X-Ray
        loggingFormat LoggingFormat.TEXT // Use plain text logs
        autoCreateDLQ false // Disable DLQ
        autoAddPowertools false // Skip Powertools layer
        maxEventAge (Duration.Hours(1.0)) // 1 hour instead of 6
        retryAttempts 0 // No retries
    }
}

Dead Letter Queue (DLQ) Auto-Creation

How it works

FsCDK provisions a standard SQS queue and wires it to the Lambda’s asynchronous failure destination—matching the blueprint from the AWS Lambda Operator Guide:

• Naming convention: {FunctionName}-dlq
• Retention: 14 days (enough to investigate issues and reprocess, per Yan Cui’s guidance)
• Queue type: Standard SQS
• Construct ID: {ConstructId}-DLQ

lambda "PaymentProcessor" {
    handler "process_payment"
    runtime Runtime.PYTHON_3_11
    code "./payment-service"
}
// Automatically creates SQS queue: "PaymentProcessor-dlq"
// Failed events stored for 14 days

Manual DLQ configuration

Large or regulated workloads may require custom encryption, retention, or monitoring. The pattern below mirrors the approach described in the AWS Compute Blog post “Designing resilient asynchronous workflows with DLQs.”

open Amazon.CDK.AWS.SQS

stack "CustomDLQStack" {
    scope app

    // Create custom DLQ with specific settings
    let! customDlq =
        queue "critical-failures" {
            retentionPeriod (30.0 * 24.0 * 3600.0) // 30 days in seconds
            encryption QueueEncryption.KMS
        }

    lambda "CriticalFunction" {
        handler "index.handler"
        runtime Runtime.PYTHON_3_11
        code "./src"
        deadLetterQueue customDlq // Use custom DLQ
        autoCreateDLQ false // Disable auto-creation
    }
}

AWS Lambda Powertools integration

Created by AWS Principal Engineer Heitor Lessa, Lambda Powertools delivers the structured logging, metrics, and tracing helpers showcased in the Powertools Live Workshops (average rating 4.9★). FsCDK automatically layers these utilities so your handlers follow the same blueprint Heitor presents in re:Invent sessions.

Key capabilities

• Structured logging with correlation IDs
• Custom metrics without manual CloudWatch API calls
• X-Ray-compatible tracing helpers
• Input validation, idempotency utilities, and middleware patterns

Supported runtimes

For .NET, install the NuGet packages (Logging, Metrics, Tracing) as demonstrated in the official Powertools .NET docs.

Python Example

lambda "PythonFunction" {
    handler "app.handler"
    runtime Runtime.PYTHON_3_11
    code "./python-service"

    environment
        [ "POWERTOOLS_SERVICE_NAME", "user-service"
          "POWERTOOLS_METRICS_NAMESPACE", "MyApp"
          "LOG_LEVEL", "INFO" ]
}
// Powertools layer added automatically!

In your Python code:

from aws_lambda_powertools import Logger, Tracer, Metrics
from aws_lambda_powertools.utilities.typing import LambdaContext

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

@logger.inject_lambda_context
@tracer.capture_lambda_handler
@metrics.log_metrics(capture_cold_start_metric=True)
def handler(event: dict, context: LambdaContext) -> dict:
    logger.info("Processing user request", extra={"user_id": event.get("user_id")})
    metrics.add_metric(name="UserRequestProcessed", unit="Count", value=1)

    # Your business logic here

    return {"statusCode": 200, "body": "Success"}

Node.js/TypeScript Example

lambda "NodeFunction" {
    handler "index.handler"
    runtime Runtime.NODEJS_20_X
    code "./nodejs-service"

    environment
        [ "POWERTOOLS_SERVICE_NAME", "order-service"
          "POWERTOOLS_METRICS_NAMESPACE", "MyApp"
          "LOG_LEVEL", "INFO" ]
}

In your TypeScript code:

import { Logger } from '@aws-lambda-powertools/logger';
import { Tracer } from '@aws-lambda-powertools/tracer';
import { Metrics } from '@aws-lambda-powertools/metrics';

const logger = new Logger();
const tracer = new Tracer();
const metrics = new Metrics();

export const handler = async (event: any) => {
    logger.info('Processing order', { orderId: event.orderId });
    metrics.addMetric('OrderProcessed', 'Count', 1);

    // Your business logic here

    return { statusCode: 200, body: 'Success' };
};

Disabling Powertools

If you don't want Powertools (e.g., for .NET or custom logging):

lambda "CustomLoggingFunction" {
    handler "index.handler"
    runtime Runtime.DOTNET_8
    code "./dotnet-service"
    autoAddPowertools false // Skip Powertools layer
}

Reserved Concurrency

Why reserved concurrency?

By default, Lambda can consume the entire account concurrency pool (1,000 per Region). Without guard rails you risk surprise costs and throttling other services—a scenario highlighted in Yan Cui’s “All you need to know about Lambda concurrency”. FsCDK therefore caps concurrency at 10 by default.

When to override

Increase or remove the cap only after: - Load testing confirms throughput requirements - You’ve configured cost and error alarms - Other critical functions have explicit concurrency protections in place

// Development/staging - keep defaults
lambda "DevFunction" {
    handler "index.handler"
    runtime Runtime.PYTHON_3_11
    code "./src"
// Reserved concurrency = 10 (default)
}

// Production - increase based on load testing
lambda "ProdFunction" {
    handler "index.handler"
    runtime Runtime.PYTHON_3_11
    code "./src"
    reservedConcurrentExecutions 500 // Tested capacity
}

// Unlimited (use with caution!)
lambda "UnlimitedFunction" {
    handler "index.handler"
    runtime Runtime.PYTHON_3_11
    code "./src"
    reservedConcurrentExecutions -1 // Remove limit (not recommended!)
}

X-Ray Tracing

Default: ACTIVE

Active tracing mirrors the workflow taught in AWS Powertools workshops—capturing every invocation for dependency mapping, latency analysis, and incident response. Keep it enabled unless regulatory requirements dictate otherwise.

Tracing modes

// Active tracing (default) - traces all requests
lambda "ActiveTracing" {
    handler "index.handler"
    runtime Runtime.PYTHON_3_11
    code "./src"
    tracing Tracing.ACTIVE // Default
}

// Pass-through - only traces if upstream sent trace header
lambda "PassThroughTracing" {
    handler "index.handler"
    runtime Runtime.PYTHON_3_11
    code "./src"
    tracing Tracing.PASS_THROUGH
}

// Disabled - no tracing
lambda "NoTracing" {
    handler "index.handler"
    runtime Runtime.PYTHON_3_11
    code "./src"
    tracing Tracing.DISABLED
}

X-Ray with Powertools

When using Lambda Powertools, X-Ray tracing is automatically integrated:

from aws_lambda_powertools import Tracer

tracer = Tracer()

@tracer.capture_lambda_handler
def handler(event, context):
    # Automatically creates X-Ray segments
    process_order()

@tracer.capture_method
def process_order():
    # Creates subsegments for detailed tracing
    validate_order()
    save_to_database()

Structured Logging (JSON)

Default: JSON format

Structured JSON logs are the backbone of Yan Cui’s observability playbook and the AWS Lambda Operator Guide. They unlock CloudWatch Logs Insights, make Datadog/Splunk ingestion straightforward, and enforce consistent fields for downstream analytics.

lambda "JsonLoggingFunction" {
    handler "index.handler"
    runtime Runtime.PYTHON_3_11
    code "./src"
    loggingFormat LoggingFormat.JSON // Default
}

// Override to text format if needed
lambda "TextLoggingFunction" {
    handler "index.handler"
    runtime Runtime.PYTHON_3_11
    code "./src"
    loggingFormat LoggingFormat.TEXT
}

CloudWatch Logs Insights Example

With JSON logging, you can query logs efficiently:

fields @timestamp, level, message, userId
| filter level = "ERROR"
| filter userId = "user-123"
| sort @timestamp desc
| limit 20

Async Invocation Configuration

Default event handling

Async invocations inherit a 6-hour max age and two retry attempts, echoing the configuration recommended in the AWS Lambda Operator Guide to balance resiliency with timely processing.

When to override

Use configureAsyncInvoke when business SLAs require tighter delivery windows or fewer retries—after validating downstream systems can cope.

lambda "CustomAsyncFunction" {
    handler "index.handler"
    runtime Runtime.PYTHON_3_11
    code "./src"

    // Custom async configuration

    asyncInvokeOption (
        eventInvokeConfigOptions {
            maxEventAge (Duration.Minutes(30.0)) // Process within 30 min
            retryAttempts 1 // Only retry once
        }
    )
}
// Note: When using configureAsyncInvoke, MaxEventAge/RetryAttempts
// are NOT set on the function props to avoid conflicts

Why limit event age?

Stale events lead to incorrect business logic, wasted compute, and confusing audit trails—an issue repeatedly called out in the AWS Compute Blog. FsCDK therefore drops payloads older than six hours by default.

Complete Production Example

Here's a complete example showing all production features:

let productionApp = App()

stack "ProductionOrderService" {
    scope productionApp

    // DynamoDB table for orders
    let ordersTable =
        table "production-orders" {
            partitionKey "orderId" AWS.DynamoDB.AttributeType.STRING
            billingMode AWS.DynamoDB.BillingMode.PAY_PER_REQUEST
            pointInTimeRecovery true
        // Note: Encryption is managed by AWS by default
        }

    // Order processor with all production defaults
    lambda "OrderProcessor" {
        handler "process_order.handler"
        runtime Runtime.PYTHON_3_11
        code "./services/order-processor"
        memorySize 512
        timeout 30.0

        // Environment variables for Powertools
        environment
            [ "TABLE_NAME", ordersTable.TableName
              "POWERTOOLS_SERVICE_NAME", "order-processor"
              "POWERTOOLS_METRICS_NAMESPACE", "OrderService"
              "LOG_LEVEL", "INFO" ]

        // Production-safe defaults applied automatically:
        // Reserved concurrency = 10
        // X-Ray tracing = ACTIVE
        // JSON logging
        // DLQ = "OrderProcessor-dlq" (14-day retention)
        // Powertools layer added
        // Max event age = 6 hours
        // Retry attempts = 2

        // Grant DynamoDB permissions
        addRolePolicyStatement (
            policyStatement {
                actions [ "dynamodb:PutItem"; "dynamodb:UpdateItem" ]
                resources [ ordersTable.Table.Value.TableArn ]
            }
        )
    }

    // High-volume notification sender (custom concurrency)
    lambda "NotificationSender" {
        handler "send_notification.handler"
        runtime Runtime.NODEJS_20_X
        code "./services/notification-sender"
        memorySize 256
        timeout 10.0

        // Override concurrency for high volume
        reservedConcurrentExecutions 200 // Validated through load testing

        environment
            [ "POWERTOOLS_SERVICE_NAME", "notification-sender"
              "POWERTOOLS_METRICS_NAMESPACE", "OrderService" ]

    // Other defaults still applied:
    // X-Ray tracing = ACTIVE
    // JSON logging
    // DLQ auto-created
    // Powertools layer
    }

    // Legacy function (custom configuration)
    lambda "LegacyProcessor" {
        handler "legacy.handler"
        runtime Runtime.JAVA_17
        code "./legacy-service"

        // Disable new features for legacy compatibility
        autoCreateDLQ false // Custom error handling
        autoAddPowertools false // Custom logging library
        loggingFormat LoggingFormat.TEXT // Legacy log parser

    // Still protected:
    // Reserved concurrency = 10
    // X-Ray tracing = ACTIVE (can disable if needed)
    }
}

productionApp.Synth() |> ignore

Best practices (from AWS Heroes)

DO

• Keep the defaults for new workloads—Yan Cui calls them "sane guard rails" for any greenfield project.
• Embrace Lambda Powertools to standardise logging, metrics, and tracing without reinventing tooling.
• Monitor DLQs with CloudWatch alarms and establish a replay runbook.
• Load test before raising reserved concurrency or removing limits.
• Retain JSON logging to unlock Logs Insights, OpenSearch, and external observability platforms.

DON’T

• Remove concurrency limits without validated traffic modelling; it’s the fastest path to bill shock.
• Disable DLQs or you’ll lose the audit trail needed during incidents.
• Turn off X-Ray in production unless compliance requires it—the overhead is minimal.
• Set overly tight MaxEventAge; you’ll drop legitimate events unnecessarily.
• Revert to plaintext logging; structured logs are the foundation for analytics.

Related Documentation

• Lambda Quickstart - Basic Lambda usage
• Getting Started - FsCDK fundamentals
• IAM Best Practices - Securing Lambda permissions

📚 Learning Resources from AWS Heroes

Yan Cui (The Burning Monk) - AWS Serverless Hero

Essential Reading:

• Production-Ready Serverless Course - Yan Cui's comprehensive 10-module course covering everything from Lambda basics to production observability
• The Burning Monk Blog - Yan Cui's comprehensive serverless best practices, including articles on concurrency, cold starts, and production patterns
• AWS Lambda Operator Guide - Official production best practices

Cost Optimization:

• Lambda Cost Optimization - AWS official strategies for memory optimization and reserved concurrency
• Lambda Power Tuning - Data-driven tool to optimize Lambda memory/cost (created by AWS SA)
• Serverless Cost Calculator - Estimate Lambda costs vs traditional infrastructure

Observability & Debugging:

• AWS Lambda Powertools - Built-in observability with structured logging, tracing, and metrics
• X-Ray Tracing Guide - Official AWS X-Ray integration documentation
• CloudWatch Logs Insights - Query and analyze Lambda logs

Video Content:

• AWS re:Invent 2023 - Production-Ready Serverless - Latest Lambda best practices from AWS
• Yan Cui - Serverless Observability - How to achieve observability in serverless apps
• Lambda Performance Optimization - Practical tips from AWS experts

AWS Lambda Powertools

Official Documentation:

• Lambda Powertools Python - Structured logging, metrics, and tracing for Python
• Lambda Powertools TypeScript - Enterprise-grade utilities for Node.js/TypeScript
• Lambda Powertools Java - Production-ready utilities for Java Lambda functions
• Lambda Powertools .NET - Observability utilities for .NET Lambda functions

Key Features Explained:

• Structured Logging - Automatically log correlation IDs and context
• Custom Metrics - Emit CloudWatch metrics without API calls
• Distributed Tracing - X-Ray integration with minimal code
• Validation - JSON Schema validation for Lambda events

AWS Official Resources

Lambda Best Practices:

• Lambda Operator Guide - Comprehensive guide for operating Lambda at scale
• Lambda Security Best Practices - IAM, VPC, and encryption guidance
• Lambda Performance Optimization - Memory, timeout, and concurrency tuning

Async Invocation & Error Handling:

• Asynchronous Invocation - How Lambda processes async events
• Dead Letter Queues (DLQ) - Capturing failed events
• Event Source Mapping - Stream processing with Lambda

X-Ray Tracing:

• Using X-Ray with Lambda - Enable distributed tracing
• X-Ray SDK for Lambda - Instrument your Lambda code
• X-Ray Service Map - Visualize your architecture

Community Tools

Lambda Development:

• Serverless Framework - Popular IaC framework for serverless
• SAM (Serverless Application Model) - AWS-native serverless framework
• LocalStack - Local AWS cloud emulator for testing
• Lumigo - Serverless observability platform (commercial)

Monitoring & Alerting:

• CloudWatch Logs Insights - Query structured logs
• CloudWatch Lambda Insights - Enhanced Lambda monitoring
• AWS Distro for OpenTelemetry - Open-source observability

Recommended Reading Order

Beginner → Intermediate:

1. Start with AWS Lambda Operator Guide
2. Read AWS Lambda Cold Start Best Practices
3. Implement Lambda Powertools in your functions
4. Learn X-Ray Tracing

Intermediate → Advanced:

1. Deep dive into Lambda Concurrency
2. Take Production-Ready Serverless Course
3. Implement Cost Optimization Strategies
4. Master Serverless Observability

Why FsCDK Uses These Defaults

FsCDK's production defaults are based on lessons learned by AWS Heroes and the broader serverless community:

1. Reserved Concurrency (10) - Prevents runaway costs and protects downstream systems (AWS docs)
2. Auto-create DLQ - Never lose events, always have audit trail (AWS DLQ docs)
3. X-Ray Tracing - Essential for debugging distributed systems (AWS X-Ray)
4. Structured JSON Logging - Enables CloudWatch Logs Insights queries (Lambda Powertools)
5. Lambda Powertools - Battle-tested utilities from AWS (official docs)

FsCDK Implementation Details

These defaults are implemented in src/Function.fs and src/LambdaPowertools.fs. See AGENTS.md for architectural details.

Summary

FsCDK's production defaults ensure your Lambda functions are:

These defaults can all be overridden, but they provide a safe starting point for production workloads.

()