AWS Lambda for Developers

AWS Lambda is a serverless compute service that runs your code in response to events and automatically manages the underlying compute resources. You upload your code, configure a trigger, and Lambda executes your code only when needed, scaling automatically from zero to thousands of concurrent executions. You pay only for the compute time consumed—no charge when your code is not running.

Lambda functions run inside ephemeral execution environments. When a trigger event arrives, the Lambda service performs the following steps:

- Downloading your code (from S3 or ECR) into a sandbox. - Starting a new runtime process (e.g., Python, Node.js, Java). - Running any code outside the handler (initialization code). - Invoking the handler function. Cold starts add latency, typically 100ms to 1+ seconds depending on runtime, deployment package size, and memory allocation.

Lambda can be invoked synchronously or asynchronously, or via stream-based polling.

Lambda scales by creating new execution environments. For synchronous invocations, scaling is limited by your account's Regional concurrency limit (default 1,000 concurrent executions). For asynchronous invocations, Lambda can scale to very high concurrency but applies internal throttling to protect downstream services. For stream-based sources, Lambda creates one shard iterator per shard and processes each shard sequentially; concurrency equals the number of shards.

Lambda Function URLs provide a dedicated HTTPS endpoint for your function. They support synchronous invocation only. You can configure authentication (AWS_IAM or NONE) and CORS. No API Gateway needed, but limited features (no custom domains, no throttling per endpoint, no API keys).

Lambda can mount an Amazon EFS file system for persistent, shared storage. This is useful for large datasets that exceed /tmp limits or need to be shared across invocations. The function must be in the same VPC as the EFS mount target. Access is controlled via IAM and security groups.

#### Python Function with DynamoDB

import boto3
import os

dynamodb = boto3.resource('dynamodb')
table_name = os.environ['TABLE_NAME']
table = dynamodb.Table(table_name)

def lambda_handler(event, context):
    # event['key'] contains the partition key
    response = table.get_item(Key={'pk': event['key']})
    return response['Item']

#### Node.js Function with Connection Reuse

const AWS = require('aws-sdk');
const docClient = new AWS.DynamoDB.DocumentClient();

exports.handler = async (event) => {
    const params = {
        TableName: process.env.TABLE_NAME,
        Key: { pk: event.key }
    };
    const data = await docClient.get(params).promise();
    return data.Item;
};

Lambda@Edge runs functions at CloudFront edge locations in response to CloudFront events: viewer request, origin request, viewer response, origin response. Functions must be in us-east-1. Execution timeout is 5 seconds for viewer events and 30 seconds for origin events. Environment variables and layers are not supported. Functions cannot access VPC resources.

A social media platform uploads user images to S3. Each upload triggers a Lambda function that resizes the image into multiple dimensions (thumbnail, medium, large) using the Sharp library, stores the resized images back to S3, and records metadata in DynamoDB. The function is configured with 512 MB memory and 30-second timeout. To handle sudden spikes (e.g., viral event), the function uses reserved concurrency of 500 to avoid overwhelming DynamoDB. Provisioned concurrency of 50 is set to keep a baseline warm for latency-sensitive thumbnail generation. The function uses a layer for the Sharp binary to keep the deployment package small. Cold starts are mitigated by using Node.js runtime and periodic 'ping' events from CloudWatch Events every 5 minutes. The team monitors thumbnail latency and uses Lambda Power Tuning to find the optimal memory. Misconfiguration: initially, the function had no reserved concurrency, causing DynamoDB throttling errors during peak times. Adding reserved concurrency solved it.

A financial services company ingests stock trade data from Kinesis Data Streams. A Lambda function processes each record, enriches it with reference data from DynamoDB, and writes the result to an S3 bucket for analytics. The function is configured with 1 GB memory and 5-minute timeout. The Kinesis stream has 100 shards, so the Lambda function processes 100 batches concurrently (one per shard). The function uses a DynamoDB DAX cluster for low-latency reference data lookups. The team sets the batch window to 60 seconds to accumulate records before invocation, reducing DynamoDB calls. They also configure a dead-letter queue (SQS) for failed records. Common issue: the function's execution role lacked permission to write to S3, causing silent failures. CloudWatch alarms on error count alerted the team.

A SaaS startup uses Lambda behind API Gateway to serve REST APIs. Each API endpoint corresponds to a separate Lambda function (e.g., /users, /orders). The functions are written in Python and use a shared layer for common utilities. They use Amazon RDS Proxy to pool database connections to Aurora Serverless. The functions are VPC-enabled and use VPC endpoints for S3 and DynamoDB to avoid NAT costs. Provisioned concurrency is set on critical endpoints to keep p99 latency under 200 ms. The team uses canary deployments via Lambda aliases: 90% traffic to version 1, 10% to version 2. CloudWatch Synthetics monitors the API endpoints. Misconfiguration: one function had a timeout of 3 seconds, but an external API call sometimes took 4 seconds, causing intermittent 504 errors. Increasing timeout to 10 seconds fixed it.