AWS Lambda Cost Optimization: VPC, Layers, and Advanced Patterns

Serverless bills rarely surprise anyone in the first month. They surprise people at scale. Over-provisioned memory, idle provisioned concurrency, and a monolithic handler each multiply the same invocation count month after month, and Lambda’s per-invocation pricing makes all three cheap to make and expensive to keep.

Past a few dozen functions the questions change. How do you share dependencies without wrecking cold starts, when is VPC attachment worth its cost, how do you reach across accounts safely, and where does the bill actually go? The answer to the last one is unglamorous: audit memory and concurrency against CloudWatch data before touching anything else, because configuration drift usually costs more than code-level optimization recovers.

Lambda Layers: Beyond Simple Code Sharing

When Layers Actually Make Sense

Most Lambda Layer tutorials frame Layers as a way to share code between functions, and that is usually the weakest reason to reach for one. Layers pay off when they pin heavy, slow-moving dependencies in one place: a monitoring SDK, a database driver, a custom runtime. Business logic belongs in the function package, where it is versioned and rolled back with the handler that uses it.

Splitting by change frequency:

// Layer 1: Heavy, rarely-changing dependencies
// /opt/nodejs/package.json in layer
{
  "dependencies": {
    "@aws-sdk/client-dynamodb": "^3.400.0",
    "datadog-lambda-js": "^8.67.0",
    "pino": "^8.15.0"
  }
}

// Function code uses layer dependencies
import { DynamoDBClient } from '@aws-sdk/client-dynamodb'; // From layer
import { datadogLambda } from 'datadog-lambda-js';  // From layer
import pino from 'pino';  // From layer

// Function-specific code (not in layer)
import { validateUserInput } from './validation';  // Function-specific
import { processPayment } from './payment';  // Function-specific

Layer versioning:

// CDK stack for layer management
export class SharedLayerStack extends Stack {
  constructor(scope: Construct, id: string, props: StackProps) {
    super(scope, id, props);

    // Semantic versioning for layers
    const monitoringLayer = new LayerVersion(this, 'MonitoringLayer', {
      code: Code.fromAsset('layers/monitoring'),
      compatibleRuntimes: [Runtime.NODEJS_20_X],
      description: `Monitoring Layer v2.1.0 - ${new Date().toISOString()}`,
      layerVersionName: 'monitoring-layer-v2-1-0'
    });

    // Export ARN for cross-stack usage
    new CfnOutput(this, 'MonitoringLayerArn', {
      value: monitoringLayer.layerVersionArn,
      exportName: 'MonitoringLayerV2-1-0'
    });
  }
}

What Layers Cost at Init

Layers are not free at runtime. AWS documents that Lambda extracts layers containing extensions into the /opt directory during the Init phase, and that “the total unzipped size of the function and all extensions cannot exceed the unzipped deployment package size limit of 250 MB”. The phase itself is capped: AWS limits Init to 10 seconds across extension init, runtime init, and function init together. Miss that budget and Lambda retries the phase at the first invocation, this time under the configured function timeout. That 10-second cap applies to on-demand concurrency. Functions on provisioned concurrency or SnapStart initialize under a longer budget: 130 seconds or the configured function timeout, whichever is higher.

What a megabyte costs inside that budget is not a number AWS publishes. Adrian Tanasa measured one version of it in 2023 and published the method: a Node.js 18 function at 256 MB on x86, its package doubled from 128 KB up to 64 MB, 100 invocations spaced ten minutes apart so each one stayed cold, @initDuration aggregated from CloudWatch Logs Insights. Average cold start ran from 171 ms at 1 KB to 3.1 seconds at 64 MB. The duration-per-megabyte ratio traced an inverted bell curve, bottoming near 26 ms/MB around 1 MB and reaching roughly 45 ms/MB at the margins. One engineer’s benchmark is not a vendor guarantee, so the shape of that curve is the finding and the digits are indicative.

The same benchmark blocks the easy conclusion. Moving identical bytes out of the function package and into a layer made cold starts shorter, measurably so from about 2 MB upward and by roughly two seconds at 64 MB. AWS documentation runs the other way for particular runtimes. Its Rust guidance recommends against layers because they lead “to increased cold start times because your functions need to manually load extra assemblies into memory during the init phase”. Whether a layer helps or hurts depends on the runtime and on what the layer carries. What holds either way is that layer bytes sit on the init path and have to be budgeted there.

Those bytes are measurable, and AWS publishes them for its own monitoring layer. Version 1.0.404.0 of the Lambda Insights extension cut the extension binary from about 9 MB to about 5 MB, the layer zip from about 3.7 MB to about 2.5 MB, and agent memory from about 11 MB to about 7 MB. Extensions share the function’s CPU, memory, and storage, so a monitoring layer shows up in the memory setting as well as on the init path.

Keep the stakes in proportion while you budget. AWS puts cold starts at under 1% of invocations, with a duration that varies from under 100 ms to over 1 second, and notes they are more common in development and test functions than in production ones. The 3.1 seconds above came from a deliberately extreme 64 MB package.

Four guidelines follow:

• Attach a layer only when more than one function needs it. The hard ceiling is five per function, but reaching for a fourth usually signals a dependency graph that needs pruning.
• Split layers by change frequency rather than by topic. A layer that changes weekly defeats the point of pinning dependencies.
• Reference layers by version ARN, so redeploying one layer cannot silently shift another function’s dependency tree.
• Keep function-specific logic out of layers, so rolling back a handler rolls back its behavior too.

VPC Configuration and Its Cost Footprint

VPC Attachment: What It Still Costs

The old advice that a VPC-attached function pays ten extra seconds of ENI setup on every cold start is out of date. Lambda now uses Hyperplane ENIs. One is created per unique combination of subnet and security group, then shared across every execution environment that uses that combination, so the setup cost is paid once for the combination rather than once per cold start. Warm invocations were never affected either way.

What VPC attachment still costs is money and reachability. A function inside a VPC has no route to the public internet unless you add one. Every AWS API call it makes then needs either a NAT Gateway or a VPC endpoint, and that is where a “make it private” decision turns into a recurring line item.

Attach a function to a VPC when it needs a private resource: an RDS cluster, an ElastiCache node, an internal service behind a private load balancer. Do not attach it for the feeling of safety, because a function outside a VPC already reaches AWS APIs over authenticated TLS endpoints.

A minimal Lambda VPC configuration:

# CDK VPC setup optimized for Lambda
VpcConfig:
  SecurityGroupIds:
    - !Ref LambdaSecurityGroup
  SubnetIds:
    - !Ref PrivateSubnet1
    - !Ref PrivateSubnet2
    # Key: Use multiple subnets in different AZs

# Security group with minimal required access
LambdaSecurityGroup:
  Type: AWS::EC2::SecurityGroup
  Properties:
    GroupDescription: Lambda function security group
    VpcId: !Ref Vpc
    SecurityGroupEgress:
      # Only what's absolutely necessary
      - IpProtocol: tcp
        FromPort: 5432
        ToPort: 5432
        CidrIp: 10.0.0.0/16  # Database subnet only
      - IpProtocol: tcp
        FromPort: 443
        ToPort: 443
        CidrIp: 0.0.0.0/0  # HTTPS for AWS API calls

Keep-Warm Schedules and Their Limits

Scheduled pings were the standard workaround for VPC cold starts before Hyperplane, and the pattern is still everywhere in production code:

// Scheduled ping that holds one execution environment open
const keepWarmSchedule = new Rule(this, 'KeepVpcLambdaWarm', {
  schedule: Schedule.rate(Duration.minutes(5)),
  targets: [new LambdaFunction(vpcLambdaFunction, {
    event: RuleTargetInput.fromObject({ 
      source: 'keep-warm',
      warmup: true 
    })
  })]
});

// Handler optimization for VPC functions
export const handler = async (event: any) => {
  // Handle warmup events
  if (event.source === 'keep-warm') {
    return { statusCode: 200, body: 'Staying warm' };
  }
  
  // Your actual logic
  return processBusinessLogic(event);
};

It holds one execution environment open per scheduled invocation, which is exactly its weakness. A single ping cannot warm the hundredth concurrent environment that a traffic spike creates, and the warmup branch has to be maintained in every handler. Provisioned concurrency does the same job with a documented guarantee and a bill you can read, so keep the schedule only for a predictable, single-digit-concurrency trickle.

What the private path adds to the bill:

• Gateway endpoints for S3 and DynamoDB: no hourly charge and no data processing charge.
• Interface endpoints (PrivateLink): an hourly charge per endpoint per availability zone, plus a per-gigabyte processing charge. Extra AZs multiply it.
• NAT Gateway: an hourly charge plus a per-gigabyte processing charge, billed on every byte including traffic to AWS APIs.
• Hyperplane ENIs are not billed, but they consume subnet IP addresses, which is a capacity constraint rather than a cost one.

Two interface endpoints across two availability zones plus one NAT Gateway is the common shape. At the rates AWS publishes for VPC ($0.01 per interface endpoint per availability zone per hour, $0.045 per NAT Gateway hour), that shape bills 4 × $0.01 + $0.045 = $0.085 an hour, about $62 a month across 730 hours, before a single gigabyte moves through either. That floor exists whether the functions run or not, and it is what makes VPC attachment a decision rather than a default.

Cross-Account Lambda Execution Patterns

IAM Strategy for Multi-Account Architecture

Managing Lambda functions across multiple AWS accounts requires careful IAM design:

// Assume role pattern for cross-account access
import { STSClient, AssumeRoleCommand } from '@aws-sdk/client-sts';
import { DynamoDBClient, GetItemCommand } from '@aws-sdk/client-dynamodb';
import type { AwsCredentialIdentity } from '@aws-sdk/types';

export class CrossAccountExecutor {
  private stsClient: STSClient;
  
  constructor() {
    this.stsClient = new STSClient({});
  }

  async executeInAccount<T>(
    accountId: string,
    roleName: string,
    action: (credentials: AwsCredentialIdentity) => Promise<T>
  ): Promise<T> {
    const response = await this.stsClient.send(new AssumeRoleCommand({
      RoleArn: `arn:aws:iam::${accountId}:role/${roleName}`,
      RoleSessionName: `lambda-cross-account-${Date.now()}`,
      DurationSeconds: 3600,
      // Must match the sts:ExternalId condition on the target role
      ExternalId: process.env.CROSS_ACCOUNT_EXTERNAL_ID
    }));

    const issued = response.Credentials!;

    // The credentials have to reach the client that needs them. A client
    // constructed without them keeps using the function's own role, which
    // is the quiet failure mode of this pattern.
    return action({
      accessKeyId: issued.AccessKeyId!,
      secretAccessKey: issued.SecretAccessKey!,
      sessionToken: issued.SessionToken!,
      expiration: issued.Expiration
    });
  }
}

// Usage
await executor.executeInAccount('222222222222', 'CrossAccountLambdaRole',
  (credentials) => new DynamoDBClient({ credentials }).send(
    new GetItemCommand({ TableName: 'shared-config', Key: { id: { S: 'billing' } } })
  )
);

Cross-Account Resource Access Pattern

# IAM role for cross-account Lambda execution
CrossAccountExecutionRole:
  Type: AWS::IAM::Role
  Properties:
    RoleName: CrossAccountLambdaRole
    AssumeRolePolicyDocument:
      Version: '2012-10-17'
      Statement:
        - Effect: Allow
          Principal:
            AWS: 
              - arn:aws:iam::ACCOUNT-A:role/LambdaExecutionRole
              - arn:aws:iam::ACCOUNT-B:role/LambdaExecutionRole
          Action: sts:AssumeRole
          Condition:
            StringEquals:
              'sts:ExternalId': 'unique-external-id-per-partner'
    ManagedPolicyArns:
      - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
    Policies:
      - PolicyName: CrossAccountAccess
        PolicyDocument:
          Version: '2012-10-17'
          Statement:
            - Effect: Allow
              Action:
                - dynamodb:GetItem
                - dynamodb:PutItem
                - s3:GetObject
                - s3:PutObject
              Resource:
                - arn:aws:dynamodb:*:*:table/shared-*
                - arn:aws:s3:::shared-bucket/*

Advanced Dependency Management and Security

Dependency Scanning in CI/CD

Lambda deployment packages accumulate transitive dependencies faster than anyone reviews them by hand. The check belongs in CI, where it blocks a merge instead of surfacing in a quarterly audit:

# GitHub Actions workflow
name: Lambda Security Scan
on:
  push:
    paths: 
      - 'lambda/**'
      - 'package*.json'

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Node.js Security Audit
        run: |
          npm audit --audit-level moderate
          npm audit fix --dry-run
          
      - name: Dependency Vulnerability Scan
        uses: securecodewarrior/github-action-add-sarif@v1
        with:
          sarif-file: 'security-scan-results.sarif'
          
      - name: Check for Secrets
        uses: trufflesecurity/[email protected]
        with:
          path: ./
          base: main
          head: HEAD

Runtime Security Patterns

// Secure environment variable handling
export class SecureConfig {
  private static instance: SecureConfig;
  private config: Map<string, string> = new Map();
  
  private constructor() {
    this.loadConfig();
  }
  
  public static getInstance(): SecureConfig {
    if (!SecureConfig.instance) {
      SecureConfig.instance = new SecureConfig();
    }
    return SecureConfig.instance;
  }
  
  private loadConfig() {
    // Load from Parameter Store at runtime
    const requiredParams = [
      'DB_CONNECTION_STRING',
      'API_KEY',
      'JWT_SECRET'
    ];
    
    // Validate all required parameters exist
    const missingParams = requiredParams.filter(
      param => !process.env[param]
    );
    
    if (missingParams.length > 0) {
      throw new Error(`Missing required parameters: ${missingParams.join(', ')}`);
    }
    
    requiredParams.forEach(param => {
      this.config.set(param, process.env[param]!);
    });
  }
  
  public get(key: string): string {
    const value = this.config.get(key);
    if (!value) {
      throw new Error(`Configuration key '${key}' not found`);
    }
    return value;
  }
}

Where the Lambda Bill Actually Goes

Attributing Cost to Functions

Cost Explorer answers “which service” by default. It cannot answer “which function” unless every function carries a cost allocation tag that has been activated in the Billing console:

import {
  CostExplorerClient,
  GetCostAndUsageCommand
} from '@aws-sdk/client-cost-explorer';

// Grouping by a cost allocation tag turns one Lambda line item into a
// per-function breakdown. Untagged functions collapse into a single bucket.
export async function lambdaCostByFunction(start: string, end: string) {
  const client = new CostExplorerClient({});

  const response = await client.send(new GetCostAndUsageCommand({
    TimePeriod: { Start: start, End: end },  // YYYY-MM-DD, End is exclusive
    Granularity: 'MONTHLY',
    Metrics: ['UnblendedCost'],
    Filter: { Dimensions: { Key: 'SERVICE', Values: ['AWS Lambda'] } },
    GroupBy: [{ Type: 'TAG', Key: 'function-name' }]
  }));

  return (response.ResultsByTime ?? []).flatMap(period =>
    (period.Groups ?? []).map(group => ({
      period: period.TimePeriod?.Start,
      // TAG groups come back as "tagKey$tagValue"
      function: group.Keys?.[0]?.split('$')[1] || 'untagged',
      cost: Number(group.Metrics?.UnblendedCost?.Amount ?? 0)
    }))
  );
}

Two limits shape how you use this. Cost Explorer bills per API request, and its data lags actual usage by up to a day. It fits a monthly review, not a feedback loop during a deploy.

The Three Drivers Worth Checking First

1. Memory set once and never revisited. Every Lambda REPORT line carries both Memory Size and Max Memory Used, and AWS’s best-practices page walks through that comparison with a sample line reading Memory Size: 128 MB Max Memory Used: 18 MB. A function whose peak stays far below its allocation across a full traffic cycle pays for GB-seconds it never touches. The trap is that the opposite is just as common, because memory also buys CPU share. The Lambda Power Tuning project records both directions in its README: one workload goes “from 35s with 128MB to less than 3s with 1.5GB, while being 14% cheaper to run”, another “from 2.4s with 128MB to 300ms with 1GB, for the very same average cost”. Neither outcome is guessable from the code, which is why AWS recommends that tool by name.

Compute Optimizer answers the same question from CloudWatch history, and its blind spots are worth knowing before an empty result gets read as an all-clear. AWS generates Lambda recommendations only for functions configured at 1,792 MB or less that were invoked at least 50 times in the last 14 days. Past that memory size the finding reason is Inconclusive, below that invocation count it is Insufficient data, and functions with a finding of Unavailable never appear in the console. The functions most likely to be mis-sized are often the ones the tool declines to judge.

One refinement, and a limit on how far it carries. Tanasa’s runs found no cold-start improvement across allocations from 256 MB to 6 GB. That function’s init was dominated by unpacking and loading its package, and extra CPU does not shorten that. Memory buys CPU for the whole environment rather than for the handler alone, and AWS names imported libraries and layers among the things a higher setting helps. An init path that does real work at startup can still get faster with more memory. Comparing Init Duration at two allocations is what settles which case you are in.

2. Provisioned concurrency that outlived its reason. AWS states the mechanic plainly: “Lambda bills you for initialization even if the environment instance never processes a request. Provisioned concurrency runs continually and incurs separate billing from initialization and invocation costs.” Put the published rate against a calendar month and the floor becomes arithmetic. At $0.0000041667 per GB-second, one provisioned gigabyte held for 730 hours costs $0.0000041667 × 3600 × 730, about $10.95, before a single request arrives; on ARM, at $0.0000033334 per GB-second, the same gigabyte is about $8.76. Multiply by memory size and by the configured count to get the standing charge a launch left behind. Part of it comes back: duration on a provisioned environment bills at $0.0000097222 per GB-second instead of the $0.0000166667 on-demand rate, so a busy provisioned function recovers some of its floor.

Provisioned concurrency gets bought for a launch, sized for the launch plus the 10% buffer AWS suggests, and then never revisited. Compare the configured count against the ProvisionedConcurrencyUtilization metric; a value sitting near zero is a standing monthly transfer to AWS for nothing. Do not expect the logs to settle the other half of the question. Tanasa’s benchmark ran with provisioned concurrency of 1 and still recorded an init duration on 16 to 18% of requests, produced by asynchronous re-provisioning that standard CloudWatch logs cannot separate from a genuine cold start.

3. One function doing four jobs. A handler that grew to cover several responsibilities charges every request for all of them. Every dependency loads during init, including for requests that touch none of it. The memory setting has to satisfy the heaviest branch, so the cheap branches are billed at the expensive branch’s rate. The execution role has to hold the union of every permission any branch needs, which widens the blast radius alongside the bill. Splitting by responsibility shrinks each package, lets each part get its own memory setting, and narrows each role. It also multiplies what you deploy, monitor, and grant permissions to, so it pays off only when the responsibilities really do have different resource profiles. Nobody has published a figure for what that trade is worth, so treat it as a shape to look for in your own tagged cost report rather than a saving to forecast.

Memory Optimization Automation

What a script can do here is nominate candidates, not apply them. Memory buys CPU share in both directions. Trimming an allocation the function never reaches can stretch duration far enough to cost more than the GB-seconds it saved, or to push a latency target past its budget. Treat the output below as a shortlist for Power Tuning rather than a value to deploy:

// Automated memory optimization based on CloudWatch metrics
export class MemoryOptimizer {
  async optimizeFunction(functionName: string) {
    const metrics = await this.getCloudWatchMetrics(functionName, 30); // 30 days
    
    const analysis = {
      avgMemoryUsed: metrics.avgMemoryUsed,
      maxMemoryUsed: metrics.maxMemoryUsed,
      currentMemoryAllocated: metrics.currentMemory,
      avgDuration: metrics.avgDuration,
      invocations: metrics.invocations
    };
    
    // Candidate allocation to benchmark, not a value to apply
    const candidateMemory = this.calculateCandidateMemory(analysis);
    
    if (candidateMemory !== analysis.currentMemoryAllocated) {
      return {
        recommendation: 'BENCHMARK_MEMORY',
        current: analysis.currentMemoryAllocated,
        candidate: candidateMemory,
        savingsIfDurationHolds: this.calculateSavings(analysis, candidateMemory),
        confidence: this.calculateConfidence(metrics)
      };
    }
    
    return { recommendation: 'NO_CHANGE', reason: 'Already optimized' };
  }
  
  private calculateCandidateMemory(analysis: any): number {
    // 20% headroom over the observed peak. Memory also sets CPU share, so a
    // compute-bound function can get slower and dearer at this setting: the
    // number below is where Power Tuning starts, not where it ends.
    const memoryWithBuffer = Math.ceil(analysis.maxMemoryUsed * 1.2);

    // Lambda accepts any value from 128 MB to 10,240 MB in 1 MB steps.
    // The old fixed ladder that topped out at 3008 MB no longer applies.
    return Math.min(10240, Math.max(128, memoryWithBuffer));
  }
}

Lambda Extensions: Custom Monitoring and Processing

Building a Cost Monitoring Extension

An extension runs as its own process beside the runtime. It starts before the handler and stays alive after the response is returned, which makes it a reasonable place to keep a running cost total. It also means it cannot see the handler’s variables, and billed duration has to come from the Telemetry API rather than from a stopwatch in the extension process. That is one more moving part. The extension opens an HTTP listener, then subscribes to have platform.report records posted to it, and the listener has to be accepting connections before the subscription call goes out:

// Ships in /opt/extensions/cost-monitor and runs as its own process
import { createServer } from 'node:http';
import { CloudWatchClient, PutMetricDataCommand } from '@aws-sdk/client-cloudwatch';

const EXTENSION_NAME = 'cost-monitor';
const API = `http://${process.env.AWS_LAMBDA_RUNTIME_API}/2020-01-01/extension`;
const TELEMETRY_API = `http://${process.env.AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry`;
// Lambda delivers telemetry inside the sandbox only; port 9001 is reserved
const LISTENER_HOST = 'sandbox.localdomain';
const LISTENER_PORT = 4243;

class CostMonitoringExtension {
  private cloudWatch = new CloudWatchClient({});
  private functionName = process.env.AWS_LAMBDA_FUNCTION_NAME!;
  private extensionId = '';
  private billedMs = 0;

  async register() {
    const response = await fetch(`${API}/register`, {
      method: 'POST',
      headers: {
        // Must equal the extension's file name in /opt/extensions
        'Lambda-Extension-Name': EXTENSION_NAME,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({ events: ['INVOKE', 'SHUTDOWN'] })
    });

    // Every later call has to echo this back, or /event/next answers 403
    this.extensionId = response.headers.get('Lambda-Extension-Identifier')!;
  }

  // Lambda POSTs an array of records here, so the server has to be listening
  // before the subscription below is sent
  startTelemetryListener(): Promise<void> {
    return new Promise(resolve => {
      createServer((req, res) => {
        let body = '';
        req.on('data', chunk => { body += chunk; });
        req.on('end', () => {
          for (const event of JSON.parse(body)) {
            if (event.type === 'platform.report') {
              this.recordReport(event.record.metrics.billedDurationMs);
            }
          }
          res.writeHead(200).end();
        });
      }).listen(LISTENER_PORT, LISTENER_HOST, () => resolve());
    });
  }

  // The registration above only buys lifecycle events. Billed duration is a
  // separate subscription, and platform.report is the record that carries it.
  async subscribeToTelemetry() {
    await fetch(TELEMETRY_API, {
      method: 'PUT',
      headers: {
        'Lambda-Extension-Identifier': this.extensionId,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        schemaVersion: '2025-01-29',
        types: ['platform'],
        // Smaller buffers deliver sooner and cost more POSTs
        buffering: { maxItems: 1000, maxBytes: 262144, timeoutMs: 100 },
        destination: {
          protocol: 'HTTP',
          URI: `http://${LISTENER_HOST}:${LISTENER_PORT}`
        }
      })
    });
  }

  // One call per platform.report record
  private recordReport(billedDurationMs: number) {
    this.billedMs += billedDurationMs;
  }

  async processEvents() {
    while (true) {
      const response = await fetch(`${API}/event/next`, {
        method: 'GET',
        headers: { 'Lambda-Extension-Identifier': this.extensionId }
      });

      const event = await response.json();

      // The blocking GET above is also what tells Lambda the extension is
      // ready for the next invoke, so the loop must never skip it.
      if (event.eventType === 'SHUTDOWN') {
        await this.flush();
        return;
      }
    }
  }

  private async flush() {
    const memoryMB = Number(process.env.AWS_LAMBDA_FUNCTION_MEMORY_SIZE);

    await this.cloudWatch.send(new PutMetricDataCommand({
      Namespace: 'Lambda/Cost',
      MetricData: [{
        MetricName: 'EnvironmentCost',
        Value: this.estimateCost(this.billedMs, memoryMB),
        Unit: 'None',
        Dimensions: [
          { Name: 'FunctionName', Value: this.functionName },
          { Name: 'MemorySize', Value: String(memoryMB) }
        ]
      }]
    }));
  }

  private estimateCost(billedMs: number, memoryMB: number): number {
    // First-tier x86 on-demand rate; the per-request charge is billed separately
    const gbSeconds = (memoryMB / 1024) * (billedMs / 1000);
    return gbSeconds * 0.0000166667;
  }
}

const extension = new CostMonitoringExtension();
extension.register()
  .then(() => extension.startTelemetryListener())
  .then(() => extension.subscribeToTelemetry())
  .then(() => extension.processEvents());

Structured Logging Inside the Handler

Capturing logs in the handler process is a different job from writing an extension, and the two get conflated often enough to be worth separating. Wrapping console gives you structured records with no cross-process plumbing, and in exchange it only ever sees what this process writes:

// Structured logging wrapper with automatic error flagging
class StructuredLogger {
  private logs: any[] = [];
  private functionName: string;
  
  constructor() {
    this.functionName = process.env.AWS_LAMBDA_FUNCTION_NAME!;
    this.setupLogCapture();
  }
  
  private setupLogCapture() {
    // Capture all console.* calls
    const originalConsole = { ...console };
    
    console.log = (...args) => {
      this.logs.push({
        level: 'INFO',
        timestamp: new Date().toISOString(),
        message: args.join(' '),
        functionName: this.functionName
      });
      originalConsole.log(...args);
    };
    
    console.error = (...args) => {
      this.logs.push({
        level: 'ERROR',
        timestamp: new Date().toISOString(),
        message: args.join(' '),
        functionName: this.functionName,
        alert: true // Flag for immediate alerting
      });
      originalConsole.error(...args);
    };
  }
  
  async flushLogs() {
    if (this.logs.length === 0) return;
    
    // Send to your logging service
    await this.sendToLogService(this.logs);
    
    // Send alerts for errors
    const errors = this.logs.filter(log => log.alert);
    if (errors.length > 0) {
      await this.sendAlerts(errors);
    }
    
    this.logs = [];
  }
}

Migration Patterns: EC2/ECS to Lambda

Deciding Whether a Service Should Move

The migrations that work decompose the service first and port it second. Three checks decide whether it is a candidate at all.

Utilization comes first. A container idling at low CPU for most of the day pays for reserved capacity it never uses, and that is the shape per-request billing suits. Execution profile comes second: anything that regularly runs past Lambda’s 15-minute limit, holds a long-lived connection, or needs more than 10 GB of memory is out. Traffic shape comes third, because a flat, high, round-the-clock request rate is usually cheaper on containers than on per-invocation pricing.

Decomposition:

// 1. Extract discrete functions first
// From monolithic ECS service to focused Lambda functions

// Before: Single ECS task handling everything
class PaymentAPI {
  async processPayment(req: Request) { /* ... */ }
  async validateCard(req: Request) { /* ... */ }
  async sendNotification(req: Request) { /* ... */ }
  async updateInventory(req: Request) { /* ... */ }
}

// After: Specialized Lambda functions
// payment-processor-lambda
export const handler = async (event: PaymentEvent) => {
  return processPayment(event.paymentData);
};

// card-validator-lambda  
export const handler = async (event: CardEvent) => {
  return validateCard(event.cardData);
};

// notification-sender-lambda
export const handler = async (event: NotificationEvent) => {
  return sendNotification(event.notificationData);
};

The Cost Comparison That Matters

Comparing compute prices alone hides most of the difference. The container side of the ledger carries fixed costs that exist at zero traffic: the task itself, a load balancer, and usually a NAT Gateway. The Lambda side has no idle cost but adds a per-request charge, a per-GB-second charge, and whatever fronts it. API Gateway bills per million requests, an ALB brings an hourly floor plus a traffic-driven LCU charge, and a Function URL has no line item of its own in Lambda’s price list.

Put published rates on both sides and most of the comparison becomes arithmetic. Take a 512 MB function averaging 200 ms of billed duration behind an HTTP API, against a single Fargate task of 0.5 vCPU and 1 GB behind an ALB. All rates below are us-east-1 list prices from the AWS pricing pages; they vary by region and change over time.

Lambda, per million requests:

• Requests: $0.20 per million.
• Compute: 0.5 GB × 0.2 s = 0.1 GB-seconds per request. At $0.0000166667 per GB-second, the first-tier x86 rate that steps down past 6 billion GB-seconds a month, that is $1.67 per million.
• HTTP API: $1.00 per million for the first 300 million.
• Total: about $2.87 per million requests, and nothing at zero traffic.

Container, per month at 730 hours:

• Fargate: (0.5 × $0.04048 per vCPU-hour) + (1 × $0.004445 per GB-hour) = $0.024685 per hour, or $18.02.
• ALB: $0.0225 per hour is $16.43, plus $0.008 per LCU-hour once traffic arrives.
• Total: about $34.45 before a single request arrives.

Dividing $34.45 by $2.87 gives about 12 million requests a month, roughly 4.6 requests per second sustained. That figure is a lower bound on the crossover. Below it the container cannot win on price, because its fixed monthly cost alone already exceeds the Lambda bill. Above it the answer stays open, because one more charge has to be counted. The ALB draws LCU charges as soon as traffic arrives, and AWS bills whichever of four dimensions runs highest: new connections, active connections, processed bytes, or rule evaluations. A request count fixes none of them; payload size and connection reuse do. Read ConsumedLCUs on a load balancer already carrying comparable traffic, add it to the container side, and the crossover lands somewhere past 12 million. Capacity pushes it the same way, because a single task that can no longer serve the rate has to become two.

Every input moves the line. Double the memory or the duration and only the compute component moves: $1.67 becomes $3.34, which puts the Lambda total near $4.54 per million and pulls the lower bound to about 7.6 million requests a month. The per-request and HTTP API charges do not move with it. Add a NAT Gateway to either side and $0.045 an hour puts about $32.85 a month plus $0.045 per gigabyte on that side’s floor. Both sides also price ARM about 20% below x86, Lambda at $0.0000133334 per GB-second and Fargate at $0.03238 per vCPU-hour, so switching architecture shifts both sides instead of deciding between them.

Crossings run in the other direction too, and one of them is documented. InfoQ reported in 2023 that Prime Video’s audio and video quality monitoring service moved from Step Functions, Lambda, and S3 to a single process on ECS on EC2, cutting operational costs by a reported 90%. The serverless design had supported only about 5% of the expected load before it hit the account limit on state transitions. Read the cause carefully: the cost drivers were those state transitions and the high volume of S3 reads and writes for intermediate video frames and audio buffers. Lambda GB-seconds were never the line item under pressure. What generalizes is the mechanism, which is that per-unit billing on a very high frequency path comes to dominate everything else. Amazon has since withdrawn the original engineering write-up, so the account survives through secondary coverage.

Work both sides out with your own traffic before committing to either.

Migration Gotchas and Solutions

1. State Management Challenge

// Problem: ECS service had in-memory caching
// Solution: External state with DynamoDB

// Before (in ECS memory)
const cache = new Map<string, UserData>();

// After (Lambda with DynamoDB)
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';

export class UserCache {
  private dynamodb = new DynamoDBClient({});
  
  async get(userId: string): Promise<UserData | null> {
    // Use DynamoDB with TTL for caching
    const result = await this.dynamodb.send(new GetItemCommand({
      TableName: 'UserCache',
      Key: { userId: { S: userId } }
    }));
    
    return result.Item ? JSON.parse(result.Item.data.S!) : null;
  }
}

2. Connection Pool Migration

// Problem: ECS had persistent DB connections
// Solution: Connection per invocation with RDS Proxy

// Before (ECS with persistent connections)
const pool = new Pool({
  host: 'db.internal',
  max: 20,
  idleTimeoutMillis: 30000
});

// After (Lambda with RDS Proxy)
import { Client } from 'pg';

export const handler = async (event: any) => {
  const client = new Client({
    host: 'rds-proxy.cluster-xyz.us-east-1.rds.amazonaws.com',
    port: 5432,
    database: 'mydb',
    user: process.env.DB_USER,
    password: process.env.DB_PASSWORD,
    ssl: { rejectUnauthorized: false }
  });
  
  await client.connect();
  try {
    const result = await client.query('SELECT * FROM users WHERE id = $1', [event.userId]);
    return result.rows[0];
  } finally {
    await client.end();
  }
};

Advanced Architectural Patterns

Event-Driven Architecture with Lambda

// Saga pattern implementation for distributed transactions
import { SFNClient, StartExecutionCommand } from '@aws-sdk/client-sfn';

export class PaymentSaga {
  private stepFunctions: SFNClient;
  
  constructor() {
    this.stepFunctions = new SFNClient({});
  }
  
  async executePayment(paymentData: PaymentData) {
    // Deployed with the state machine, not rebuilt per invocation. Repeated
    // here because the compensation branches are the part usually left out.
    const sagaDefinition = {
      Comment: 'Payment processing saga',
      StartAt: 'ValidatePayment',
      States: {
        ValidatePayment: {
          Type: 'Task',
          Resource: 'arn:aws:lambda:us-east-1:123456789:function:validate-payment',
          Next: 'ProcessPayment',
          Catch: [
            {
              ErrorEquals: ['ValidationError'],
              Next: 'PaymentFailed'
            }
          ]
        },
        ProcessPayment: {
          Type: 'Task', 
          Resource: 'arn:aws:lambda:us-east-1:123456789:function:process-payment',
          Next: 'UpdateInventory',
          Catch: [
            {
              ErrorEquals: ['PaymentError'],
              Next: 'CompensateValidation'
            }
          ]
        },
        UpdateInventory: {
          Type: 'Task',
          Resource: 'arn:aws:lambda:us-east-1:123456789:function:update-inventory', 
          Next: 'SendConfirmation',
          Catch: [
            {
              ErrorEquals: ['InventoryError'],
              Next: 'CompensatePayment'
            }
          ]
        },
        SendConfirmation: {
          Type: 'Task',
          Resource: 'arn:aws:lambda:us-east-1:123456789:function:send-confirmation',
          End: true
        },
        // Compensation states
        CompensatePayment: {
          Type: 'Task',
          Resource: 'arn:aws:lambda:us-east-1:123456789:function:refund-payment',
          Next: 'CompensateValidation'
        },
        CompensateValidation: {
          Type: 'Task', 
          Resource: 'arn:aws:lambda:us-east-1:123456789:function:cleanup-validation',
          Next: 'PaymentFailed'
        },
        PaymentFailed: {
          Type: 'Fail',
          Cause: 'Payment processing failed'
        }
      }
    };
    
    const execution = await this.stepFunctions.send(new StartExecutionCommand({
      stateMachineArn: process.env.PAYMENT_SAGA_STATE_MACHINE!,
      input: JSON.stringify(paymentData)
    }));
    
    return execution.executionArn;
  }
}

Circuit Breaker Pattern for Lambda

// Circuit breaker for external service calls
export class CircuitBreaker {
  private failures: number = 0;
  private lastFailureTime: number = 0;
  private state: 'CLOSED' | 'OPEN' | 'HALF_OPEN' = 'CLOSED';
  
  constructor(
    private failureThreshold: number = 5,
    private recoveryTimeMs: number = 60000
  ) {}
  
  async execute<T>(operation: () => Promise<T>): Promise<T> {
    if (this.state === 'OPEN') {
      if (Date.now() - this.lastFailureTime > this.recoveryTimeMs) {
        this.state = 'HALF_OPEN';
      } else {
        throw new Error('Circuit breaker is OPEN');
      }
    }
    
    try {
      const result = await operation();
      this.onSuccess();
      return result;
    } catch (error) {
      this.onFailure();
      throw error;
    }
  }
  
  private onSuccess() {
    this.failures = 0;
    this.state = 'CLOSED';
  }
  
  private onFailure() {
    this.failures++;
    this.lastFailureTime = Date.now();
    
    if (this.failures >= this.failureThreshold) {
      this.state = 'OPEN';
    }
  }
}

// Usage in Lambda function
const circuitBreaker = new CircuitBreaker(5, 30000);

export const handler = async (event: any) => {
  try {
    return await circuitBreaker.execute(async () => {
      return await callExternalService(event.data);
    });
  } catch (error) {
    return {
      statusCode: 503,
      body: JSON.stringify({ error: 'Service temporarily unavailable' })
    };
  }
};

Series Wrap-Up

Part 1 covered cold starts and runtime choice, part 2 memory and duration, part 3 what you can see once functions are running. The patterns above are what an estate needs after that: shared dependencies, private networking, cross-account boundaries, and a cost model that survives a budget review.

The default holds in the ordinary case. Audit memory and provisioned concurrency against CloudWatch data before rewriting anything, keep functions outside a VPC unless they need a private resource, and budget every Layer’s bytes on the init path instead of treating a Layer as a free abstraction. Override it when the workload says so. A compute-bound function often gets cheaper with more memory rather than less, and a latency target can be worth provisioned concurrency at list price. A service with flat, round-the-clock traffic may belong on containers regardless of how clean the decomposition looks.

The first step needs no code change: pull Max Memory Used for every function with meaningful traffic and compare it against what each one is configured for.

The complete AWS Lambda guide series:

• Part 1: Cold Start Optimization and Runtime Selection
• Part 2: Memory Allocation and Performance Tuning
• Part 3: Production Monitoring and Debugging Strategies
• Part 4: Advanced Patterns and Cost Optimization (This post)

References

• Understanding the Lambda execution environment lifecycle - The 10-second Init budget shared by extension init, runtime init, and function init, the longer budget provisioned concurrency and SnapStart get instead, and AWS’s own bounds on how often cold starts happen and how long they last.
• Augment Lambda functions using Lambda extensions - How layers carrying extensions are extracted into /opt during init, the 250 MB unzipped ceiling for a function plus its extensions, and the CPU, memory, and storage an extension shares with the handler.
• Working with layers for Rust Lambda functions - AWS advising against layers for one runtime family, because manually loading assemblies during init raises cold start times.
• Lambda Insights extension versions for ARM64 - Published sizes for a real monitoring layer, including the binary, zip, and agent memory reductions that version 1.0.404.0 delivered.
• Size is (almost) all that matters for optimizing AWS Lambda cold starts - Adrian Tanasa’s independent benchmark, method included: package size against init duration, what happened when the same bytes moved into a layer, memory against cold start, and provisioned concurrency still reporting init durations.
• Lambda quotas - The hard limits used above: 250 MB unzipped deployment package including layers, five layers per function, 128 MB to 10,240 MB of memory, and the 15-minute execution ceiling.
• Giving Lambda functions access to resources in an Amazon VPC - How Lambda connects to VPC resources using Hyperplane ENIs and the performance implications of VPC attachment.
• Amazon VPC pricing - NAT Gateway hourly and per-gigabyte charges alongside PrivateLink interface endpoint pricing per availability zone, the rates behind the private-path floor above.
• Best practices for working with AWS Lambda functions - The REPORT line method for spotting over-provisioned memory, with AWS’s own worked example, plus its recommendation of Lambda Power Tuning by name.
• Configure Lambda function memory - AWS on CPU being allocated in proportion to memory, and the workloads a higher setting helps, imported libraries and layers among them.
• AWS Lambda Power Tuning - The Step Functions state machine that benchmarks a function across memory settings, and the README results showing more memory landing both cheaper and cost-neutral on different workloads.
• Resource requirements (AWS Compute Optimizer) - The memory ceiling and invocation count a Lambda function has to meet before Compute Optimizer will rate it, and what each finding reason means when it will not.
• Configuring provisioned concurrency for a function - AWS on billing initialization even when an environment never serves a request, the suggested 10% buffer when sizing, and the account concurrency cap.
• AWS Lambda pricing - Per-request and per-GB-second rates by architecture, the tiers above the first one, and the separate rates for provisioned concurrency and for duration on a provisioned environment.
• AWS Fargate pricing - Per-vCPU-hour and per-GB-hour rates used in the break-even above, with the ARM rates alongside x86.
• Elastic Load Balancing pricing - The hourly Application Load Balancer charge, the LCU rate that sits on top of it, and the four dimensions AWS measures before billing only the highest one.
• Amazon API Gateway pricing - HTTP API and REST API per-million-request rates, the front-door difference that moves most Lambda comparisons.
• Prime Video Switched from Serverless to EC2 and ECS to Save Costs - InfoQ’s account of the migration, including the state transition limit that capped the serverless design and the cost reduction reported after consolidation. Amazon withdrew the original engineering post, so this is the surviving source.
• Lambda Extensions API - Register and next-event endpoints, the Lambda-Extension-Identifier header, and the lifecycle events an extension can subscribe to.
• Lambda Telemetry API - The subscription request used above, the listener and buffering requirements, and the platform.report record that carries billed duration.