Lambda@Edge and Event-Driven Patterns

Lambda@Edge lets you run Lambda functions at CloudFront edge locations around the world—closer to end users—rather than in a centralised Region. This enables you to customise HTTP requests and responses with sub-millisecond added latency at the CDN layer. Lambda@Edge functions are deployed globally and invoked on every CloudFront cache hit or miss event, making them ideal for lightweight request manipulation tasks.

Lambda@Edge can intercept traffic at four points in the CloudFront request lifecycle:

• Viewer Request: fires when CloudFront receives a request from the viewer (user), before checking the cache
• Origin Request: fires when CloudFront forwards a cache miss to the origin
• Origin Response: fires when the origin returns a response before caching
• Viewer Response: fires before CloudFront returns the response to the viewer

Lambda@Edge has stricter limits than regular Lambda: 128 MB memory max (viewer events), 1 GB (origin events), 5 seconds max timeout (viewer), 30 seconds (origin). Functions must be created in us-east-1 and deployed to edge via CloudFront. No VPC support, no environment variables, no Lambda Layers. These constraints mean Lambda@Edge is designed for lightweight transformations, not heavy processing.

Lambda@Edge shines for: A/B testing (rewrite URLs to different origin paths based on cookies), authentication (validate JWTs at the edge before forwarding to origin), HTTP header manipulation (add security headers like HSTS, CSP, X-Frame-Options), URL normalisation (redirect www to non-www or enforce trailing slashes), and personalisation (serve different content based on viewer country from the CloudFront-Viewer-Country header).

CloudFront Functions are ultra-lightweight JavaScript functions that run at the viewer request/response stages only, with a 2 ms execution time limit and a much lower cost. For simple use cases (URL rewrites, header manipulation, cache key normalisation), CloudFront Functions are preferred over Lambda@Edge because they are faster and cheaper. Use Lambda@Edge when you need access to network calls, larger payloads, or the origin request/response trigger points.

Event-driven architecture connects services through events—messages that represent something that happened. In AWS, Lambda is the primary event consumer: it receives events from SQS, SNS, DynamoDB Streams, Kinesis, S3, EventBridge, and more. Each event triggers a Lambda execution, allowing systems to react asynchronously and independently without tight coupling. This pattern enables loose coupling, independent scaling, and fault isolation.

Lambda can be configured as an event source mapping for SQS. Lambda polls the queue, retrieves up to a batch size of messages (up to 10,000 for standard queues, 10 for FIFO), and invokes the function once per batch. If the function fails, the entire batch is returned to the queue. Configure a batch window to wait for more messages before invoking, improving throughput. Use a DLQ on the source SQS queue for messages that repeatedly fail.

DynamoDB Streams capture every item-level change (INSERT, MODIFY, REMOVE) as an ordered sequence of events. Lambda reads from the stream using an event source mapping with TRIM_HORIZON (start from oldest) or LATEST (start from newest). Lambda processes records in order within a partition. Failed batches block further processing of the same partition until resolved—use bisect on error to split failing batches and isolate problematic records.

Lambda processes Kinesis records similarly to DynamoDB Streams—one concurrent execution per shard. Key configuration options include parallelisation factor (up to 10 concurrent Lambda invocations per shard, processing sub-batches in parallel) and enhanced fan-out (dedicated 2 MB/s per shard throughput for the Lambda consumer). These options dramatically increase throughput for high-volume streams without increasing the shard count.

Amazon EventBridge is the recommended event bus for connecting AWS services and custom applications. Events flow into a bus, and rules filter events by pattern and route them to targets including Lambda, SQS, Step Functions, and more. EventBridge decouples event producers from consumers completely—neither knows about the other. The default event bus receives events from AWS services; create a custom event bus for your application events.

A common event-driven pattern is fan-out: one event triggers multiple parallel processing pipelines. Publish to an SNS topic, and multiple Lambda function subscriptions each react independently. For example, an order placed event fans out to: a Lambda that sends a confirmation email, a Lambda that updates inventory, and a Lambda that notifies the warehouse. Each consumer is independent and scales separately—no single consumer can block others.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Lambda@Edge runs functions at CloudFront edge locations with four trigger points (viewer request/response, origin request/response) for tasks like authentication, URL rewriting, and header manipulation, CloudFront Functions are the lower-cost, lower-latency alternative for simple viewer-stage transformations, and event-driven patterns using SQS, DynamoDB Streams, Kinesis, EventBridge, and SNS fan-out enable loosely coupled architectures where Lambda reacts to real-time events. Next up we explore SQS Standard vs FIFO Queues.