AWS Architecture Guide

Edge Locations and CDN Thinking

Goal

Explain why edge delivery changes latency, traffic flow, and workload design.

The Short Version

Edge delivery moves content closer to users so the application does not have to serve every request from the origin Region. In AWS, that usually means using a content delivery network such as CloudFront to serve content through globally dispersed edge infrastructure.

The durable idea is:

Edge delivery reduces distance to users, but it also changes what should be cached, protected, and observed.

Why This Matters

Without edge delivery, every static asset request, page fetch, or repeated API call may travel back to the origin Region. That increases latency and can increase cost or load on the origin.

With a CDN, the design changes:

  • some content is cached near users

  • the origin sees fewer repeated requests

  • security controls can be applied at the edge

  • the application can separate static delivery from dynamic processing

A Simple Flow

User
  -> CloudFront edge
  -> cached content, if available
  -> origin Region, if needed

This is a simplified model, but it captures the architectural point. The edge is not the application. It is a delivery layer that helps the application feel closer to the user.

Practical Meaning

Edge delivery is useful when a workload has:

  • globally distributed users

  • static assets such as images, scripts, or downloads

  • APIs that benefit from lower latency or edge protection

  • a need to reduce origin load

The architecture question is not whether edge delivery is "modern." The question is which parts of the workload benefit from being closer to the user and which parts should stay in the Region.

Example: Public Portal With Static And Dynamic Traffic

Consider a customer portal that serves invoices, profile pages, and a small set of dynamic APIs.

An effective design might:

  • cache static files and downloadable assets at the edge

  • send dynamic requests to the origin Region

  • apply edge security controls before traffic reaches the application

  • keep the data tier private even though the content tier is distributed

That reduces latency for repeat content without pretending the edge can replace the whole application.

Common Mistakes

  • Assuming a CDN is only for large media companies.

  • Caching content that should not be cached.

  • Treating edge delivery as a substitute for application design.

  • Forgetting that origin observability still matters when the edge absorbs traffic.

If Someone Asks You

If someone asks, "Why would I use edge delivery in AWS?" a clear answer is:

Use edge delivery when users are far from the origin, when repeated content can be cached safely, or when you want to reduce origin load and improve response time. The design still needs a clear split between edge-deliverable content and origin-only behavior.

What You Should Remember

CDN thinking is about moving the right traffic closer to the user, not moving the whole workload out of the Region.

Questions to Check Your Understanding

  1. What kind of traffic benefits most from edge delivery?

  2. Why is the origin still important when using a CDN?

  3. What should you be careful not to cache?

Further Study