We close Chapter 28 with a very powerful idea: executing logic very close to users, at the «edge» of the network. Until now, our Lambdas (Chapter 14) ran in a specific region. But what if you could run code in the hundreds of locations that CloudFront (subchapter 16.2) has distributed around the world, right next to each user? That’s what Lambda@Edge and CloudFront Functions allow: bringing compute to the edge (the edge of the network) to respond faster and personalize content.

Remember from subchapter 16.2 that CloudFront is AWS’s CDN: it has locations distributed all over the world (points of presence or «edge locations») that serve content to users from the point closest to them, reducing latency. That set of locations close to users is what we call the edge (the edge of the network).

The idea of this subchapter: run code in those edge locations, not just serve files. That way, the logic runs next to the user, not in a distant region.

If all your logic runs in a region (for example, in Europe), a user in Japan has to “go back and forth” to Europe for every operation, which adds latency (delay). For certain simple tasks that could be solved near the user, that trip is a waste. It would be better to run that small logic in the edge location closest to the user.

Running logic at the edge means running code in the locations close to users (CloudFront’s), instead of in a central region. This is useful for tasks that are best solved right when a request arrives at or leaves the edge, without traveling to the region:

• Personalize responses according to the user (their country, language, device).
• Redirect requests according to certain rules.
• Check things (basic authentication, headers) before proceeding.
• Modify the request or response on the fly.

Analogy: running logic at the edge is like having a receptionist at the door of every branch of a bank, instead of having to call headquarters for everything. If you come in and just need to be directed to a window or given a brochure in your language, the local receptionist solves it instantly, without calling headquarters (which is far away). Only complex transactions go to headquarters. Bringing simple tasks “to the door” makes everything faster.

AWS offers two ways to run code at the edge, one more powerful and one lighter:

CloudFront Functions are very lightweight and extremely fast functions, designed for simple tasks that run on every request with minimal latency. They are ideal for simple, high-volume manipulations:

Lambda@Edge are Lambdas (Chapter 14) that run at the edge, more powerful than CloudFront Functions: they allow more complex logic (longer execution time, access to more resources, etc.), at the cost of a bit more latency and cost.

💡 Practical rule: for simple and high-volume tasks (manipulating headers or URLs), use CloudFront Functions (faster and cheaper). For more complex logic, use Lambda@Edge. Choose the lightest tool that solves your need.

The advantage of running logic at the edge is twofold:

• Lower latency: the logic runs close to the user, so it responds faster (without the trip to the region).
• Global personalization: you can adapt content to each user (language, country, device) at the point closest to them, giving a fast, tailored experience worldwide.

This fits with the performance efficiency pillar of the Well-Architected Framework (subchapter 27.1): using the right location so the system performs as well as possible for each user.

Real-world example: a global website wants each user to see content in their language and be redirected to their country’s version as quickly as possible. They use a CloudFront Function that, on each request, looks at the user’s country (from a header that CloudFront adds) and rewrites the URL to serve the correct version, all in the nearest edge location, in milliseconds. For another, more complex task—checking an authentication token and personalizing the response according to the user’s profile—they use Lambda@Edge, which has the necessary power. The result: users all over the world get personalized and fast content, because the logic runs next to them, not on the other side of the planet.

• CloudFront (subch. 16.2) has locations all over the world (the edge) close to users. You can run code in them, not just serve files.
• Running logic at the edge means running code close to the user (not in a distant region), ideal for personalizing responses, redirecting, checking, or modifying requests on the fly. Like a receptionist at the door of every branch instead of always calling headquarters.
• AWS offers two options: CloudFront Functions (very lightweight and ultra-fast, for simple tasks like rewriting URLs or headers) and Lambda@Edge (more powerful, for complex logic).
• 💡 Use the lightest that solves your need: CloudFront Functions for simple and high-volume; Lambda@Edge for complex.
• Provides lower latency (logic close to the user) and global personalization, in line with the performance efficiency pillar of the Well-Architected Framework.

You’ve completed Chapter 28 and mastered serverless architectures at scale: event-driven, the Saga pattern, Step Functions, and edge computing! In Chapter 29 we’ll move on to another major domain: data platforms on AWS (data lakes, streaming, and large-scale analytics).