Lambda@Edge | Overview.

AWS Lambda@Edge - Overview.

Scope:

• Intro,
• Where Lambda@Edge Runs,
• Lambda@Edge Trigger Points (run at four different CloudFront event stages),
• Deployment Flow,
• Execution Environment,
• Sample Flow,
• Advantages,
• Limitations.

Intro:

• lambda@Edge is a feature of Amazon CloudFront that allows developers to run code at AWS edge locations globally, which are closer to the end users. 
• lambda@Edge improves performance and reduces latency by customizing content delivery or running application logic without needing to provision or manage servers.

Architecture

1. Where Lambda@Edge Runs

• twtech Lambda code is replicated to AWS edge locations around the world.
• It executes in the AWS region closest to the viewer or the origin, depending on the event type.
• AWS automatically handles replication, scaling, and failover.

2. Lambda@Edge Trigger Points (run at four different CloudFront event stages):

Event type	Runs
Viewer Request.	Before CloudFront checks its cache (immediately after request hits edge)
Viewer Response.	Before CloudFront returns content to the viewer
Origin Request.	Before CloudFront forwards request to the origin
Origin Response.	Before CloudFront sends origin’s response to the viewer

3. Deployment Flow

1. twtech creates the function in AWS Lambda (in us-east-2 only).
2. twtech chooses a CloudFront distribution and associate the function with one or more event triggers.
3. AWS replicates the function code and configuration to all required edge locations.
4. On the first trigger after deployment, AWS runs the function at the edge — no call back to your home region.

4. Execution Environment

• Languages: Node.js, Python.
• Execution time limits:
• Viewer events → up to 5 seconds
• Origin events → up to 30 seconds
• Memory: 128 MB – 10 GB
• Network access: ✅ Yes (can call APIs, S3, DynamoDB, etc.).
• AWS SDK: Available to interact with AWS services.
• Runs in fully managed Lambda containers (similar to regional Lambda, but optimized for edge).

5. Sample Flow

Imagine you have a viewer-request Lambda@Edge function that checks a JWT token for authentication.

Flow:

1. User request hits CloudFront.
2. Viewer-request trigger invokes Lambda@Edge at the nearest edge.
3. Lambda@Edge reads the Authorization header, validates the token (could call an auth API or verify with a public key).
4. If valid → forward the request to CloudFront cache/origin.
5. If invalid → return 403 Forbidden immediately.

6. Advantages

• Global low latency with heavy logic possible.
• Full AWS Lambda features at the edge.
• Can customize both viewer and origin traffic.
• Integrates with other AWS services.

7. Limitations

• Slower cold starts than CloudFront Functions (can be hundreds of ms to seconds).
• More expensive than CloudFront Functions.
• Deployment latency — changes take minutes to propagate globally.
• Can’t run outside the 4 specific event types.