Cloud Internals #1: Inside AWS Edge Infrastructure

What happens before a request reaches your origin: Regions, Availability Zones, CloudFront POPs, Regional Edge Caches, and Origin Shield.

When a user opens a website through Amazon CloudFront, the request does not simply “go to AWS.”.

Before it reaches the origin, it may pass through multiple infrastructure layers:

Amazon CloudFront Request Flow

Each layer exists for a reason.

• Reduce latency
• Reduce origin load
• Improve cache efficiency
• Improve availability
• Protect backend infrastructure

This is the real value of understanding AWS edge infrastructure.

It is not only about knowing what a Region or an Edge Location is. It is about understanding how AWS uses geography, caching, networking, and failure boundaries to move content closer to users while reducing pressure on backend systems.

1. The architecture view: AWS locations are not equal layers

AWS global infrastructure is built from different types of locations, but these locations do not all serve the same purpose.Some locations are used to run core cloud workloads.Some are used to isolate failure.Some are used to deliver content closer to users.Some are used to reduce repeated origin access.

A useful architecture view looks like this:

AWS Global infrastructure & Content Delivery Map

AWS services are hosted across multiple worldwide locations, including Regions, Availability Zones, Local Zones, and Wavelength Zones. AWS defines each Region as a separate geographic area, and Availability Zones as isolated locations inside each Region.

But when we talk about CloudFront, caching, and edge delivery, the important question is not only:

Where is AWS located?,The better question is:

What path does a user request follow before it reaches the origin?

That request path is where the architecture becomes interesting.

2. The request-path mental model

Imagine a user requests this object:

https://example.com/images/banner.jpg

If the website uses CloudFront, the request may follow this path:

Not every request touches every layer every time.

If the object is already cached at the nearest CloudFront edge location, CloudFront can return it immediately.

If the object is not cached there, CloudFront may check a deeper cache layer before contacting the origin.

The main mental model is:

• Edge Location = closest cache to the user
• Regional Edge Cache = larger middle cache
• Origin Shield = optional origin-protection cache
• Origin = source of truth

So AWS edge infrastructure is not just a map of global locations.

It is a layered delivery system.

3. Region: where core infrastructure lives

A Region is a separate geographic area where AWS operates cloud infrastructure.

Examples:

• us-east-1 Northern Virginia
• eu-west-1 Ireland
• ap-south-1 Mumbai
• ap-southeast-1 Singapore

When we choose a Region, we are deciding where the main infrastructure of an application will live geographically.

That decision affects:

• Latency
• Cost
• Legal and compliance requirements
• Service availability
• Disaster recovery strategy
• Data residency
• User experience

For example, if most users are in South Asia, deploying an application in a closer Region such as Mumbai or Singapore will usually produce a better latency profile than deploying the origin far away.

A Region is not just a dropdown in the AWS Console.

It is an architecture decision.

AWS describes a Region as a physical location around the world where it clusters data centers. AWS also explains that each Region consists of a minimum of three isolated and physically separate Availability Zones.

So when we say:

Deploy the workload to a Region

we are really choosing a geographic boundary for:

• Compute
• Storage
• Networking
• Compliance
• Disaster recovery
• Failure planning

A Region gives the application a physical and geographic home.

4. Availability Zone: the failure-isolation boundary

Inside a Region, AWS provides multiple Availability Zones, usually written like this:

ap-south-1a ap-south-1b ap-south-1c

AWS says each Region has at least three Availability Zones, which helps customers design highly available applications.

The deeper concept is this:

An Availability Zone is a failure boundary.

An AZ exists because physical infrastructure can fail.

• Power can fail.
• Cooling can fail.
• Network links can fail.
• Hardware can fail.
• A data center can have operational problems.

Cloud systems are not designed with the assumption that failure will never happen.They are designed with the assumption that failure will happen somewhere, sometime.That is why production workloads often run across multiple Availability Zones.

Example:

AWS Region ├── AZ-A → Application server 1 ├── AZ-B → Application server 2 └── AZ-C → Application server 3

If an application runs only in one AZ and that AZ has a problem, the application may become unavailable.If the application is designed across multiple AZs, traffic can be served from healthy zones.

AWS describes Availability Zones in a Region as connected through low-latency, high-bandwidth, highly redundant networking over dedicated metro fiber.

That detail matters.

It means AZs are separate enough to isolate many physical failures, but connected enough to support highly available regional architectures.

So the important model is:

Availability Zone = failure isolation + low-latency regional connectivity

Availability Zones are how AWS turns physical failure into an architecture design problem.

5. Edge Location / Point of Presence: where users meet AWS edge infrastructure

A CloudFront Point of Presence, or POP, is an edge location where CloudFront receives viewer requests and serves cached content.

AWS describes CloudFront as a service that speeds up delivery of static and dynamic web content through a worldwide network of edge locations. When a user requests content through CloudFront, the request is routed to the edge location that provides the lowest latency.

This layer exists because distance still matters.

Even in cloud computing, network packets move through physical infrastructure.

A request from Sri Lanka to an origin in the United States may travel a much longer network path than a request served from a closer edge location.CloudFront helps by placing delivery infrastructure closer to users.

Simple model:

Without CloudFront:

User → long internet path → Origin

With CloudFront:

User → nearby edge location → cached response

The key idea:

Edge infrastructure is AWS’s answer to the speed limit of geography.CloudFront POPs are not the same thing as AWS Regions.

A Region is where core infrastructure usually lives.A POP is where users connect to AWS edge infrastructure for low-latency delivery.

AWS explains that CloudFront sends a distribution’s configuration to edge locations or POPs, which are collections of servers in geographically dispersed data centers where CloudFront caches copies of files.

That means the POP does not become your origin.It becomes a closer delivery layer between your users and your origin.

6. What happens inside a CloudFront POP?

When a viewer makes a request, CloudFront routes that request to a POP that can best serve the viewer, typically the nearest edge location in terms of latency. At the POP, CloudFront checks whether the requested object is already in cache.

There are two major outcomes.

Case 1: POP cache hit

The object is already available at the POP.

POP cache hit

This is the fastest path.The request does not need to go back to the origin.The response is served close to the user.

Case 2: POP cache miss

The object is not available at the POP.

POP cache miss

At this point, the request does not always jump directly to the origin.

CloudFront has another important layer:

Regional Edge Cache.This is where the architecture becomes more interesting.

7. Regional Edge Cache: the middle cache layer

A Regional Edge Cache is a larger CloudFront cache layer between CloudFront POPs and your origin.

AWS explains that Regional Edge Caches sit between origin servers and POPs. POPs serve content directly to viewers, while Regional Edge Caches have larger caches than individual POPs, so objects can remain cached longer. This helps reduce the need for CloudFront to go back to the origin server and improves performance for viewers.

This layer matters because POPs are close to users, but they have limited cache capacity.

A Regional Edge Cache is not as close as every POP, but it has larger cache capacity and can keep objects longer.

A useful comparison:

• Layer Role
• POP / Edge Location Closest cache to the viewer
• Regional Edge Cache Larger middle cache
• Origin Source of truth

A request flow with Regional Edge Cache can look like this:

Regional cache hit

In this case, the origin was protected.

The request did not need to reach:

• S3
• EC2
• Application Load Balancer
• API Gateway
• Custom origin server

That matters because every origin request can consume backend capacity, increase latency, and sometimes increase cost.

A strong mental model:

• POP = fast and close
• Regional Edge Cache = larger and more persistent
• Origin = source of truth

AWS’s CloudFront features page describes Regional Edge Caches as being situated within AWS Regions, between application web servers and CloudFront POPs and embedded POPs.

8. Origin Shield: an optional origin-protection layer

CloudFront can also use Origin Shield.

Origin Shield is an optional centralized caching layer between CloudFront’s Regional Edge Caches and your origin.

With Origin Shield, the path becomes:

CloudFront Content Delivery Path

AWS says Origin Shield adds an additional layer of caching between Regional Edge Caches and your origin. All requests from all Regional Edge Caches go through Origin Shield, further reducing the load on your origin.

This matters when traffic is global.

Imagine users from many parts of the world request the same object at around the same time.Without a centralized shield layer, multiple Regional Edge Caches may send similar cache-miss requests toward the origin.

Without Origin Shield:

Regional Edge Cache 1 → Origin Regional Edge Cache 2 → Origin Regional Edge Cache 3 → Origin

With Origin Shield:

Regional Edge Cache 1 → Origin Shield Regional Edge Cache 2 → Origin Shield Regional Edge Cache 3 → Origin Shield ↓ Origin

Origin Shield can reduce duplicate origin fetches because requests from multiple Regional Edge Caches are funneled through one additional cache layer.

Origin Shield is especially useful when:

• Traffic is global
• Many viewers request similar content
• The origin is expensive to scale
• The origin performs dynamic generation
• The origin should be protected from repeated cache misses

The key mental model:

Origin Shield is not mainly about making the user closer to AWS. It is about making the origin less exposed to repeated cache misses.

9. Origin: the source of truth

The origin is where CloudFront gets the original content.

An origin can be:

• Amazon S3 bucket
• Application Load Balancer
• EC2 instance
• API Gateway endpoint
• Media server
• Custom HTTP server

AWS describes an origin domain as the DNS domain name of the resource where CloudFront gets objects, such as an S3 bucket or HTTP server. The origin is important because it is the source of truth.CloudFront caches copies, but the origin holds the authoritative version of the content or application response.

That is why reducing unnecessary origin access matters.

It can improve:

• Performance
• Availability
• Cost efficiency
• Backend stability
• Scalability

CloudFront does not remove the need for good origin design.It reduces how often the origin must do repeated work.

10. Full request journey: cache hit vs cache miss

Now let’s combine the layers.

Fastest path: POP cache hit

POP cache Hit

This is the best case.The user gets the response from a nearby edge location.The origin is not touched.

Middle path: Regional Edge Cache hit

REC Hit

The request still avoids the origin.This is slower than a POP cache hit, but much better than going all the way back to the origin.

Deeper path: Origin Shield hit

Origin Shield Hit

The origin is still protected.The request went deeper into the CloudFront cache hierarchy, but it did not reach the origin.

Full origin path: cache miss everywhere

Full Origin Path

After the origin responds, CloudFront may cache the response based on cache behavior, headers, TTL settings, and cache policy.This layered model is the real value of understanding AWS edge infrastructure.

It shows that edge delivery is not just:

User → AWS → Server

It is closer to:

User → POP → Regional Edge Cache → Origin Shield → Origin

depending on cache state and configuration.

11. Why this architecture matters

This architecture affects real systems in several ways.

Latency

The closer the response is to the user, the faster the experience usually becomes.

POP cache hit = usually fastest Regional Edge Cache hit = still avoids origin Origin fetch = usually slowest

CloudFront improves performance by routing requests to low-latency edge locations and caching content closer to viewers.

The deeper idea:

Latency is not only a software problem. It is also a geography problem.Even if the application code is optimized, distance still affects network response time.That is why edge infrastructure exists.

Origin load

If every user request reaches the origin, the backend must handle all traffic.

With CloudFront caching:

Many requests can be served from edge caches. Fewer requests reach the origin.

AWS states that CloudFront caching can reduce the number of requests that an origin server must respond to directly because more objects are served from edge locations closer to users.

So caching is not only about speed.It is also about reducing backend pressure.

Availability

If an origin becomes overloaded, the application may slow down or fail.Caching reduces pressure on origin infrastructure.It does not replace proper backend architecture, but it can improve resilience.

A well-designed system still needs:

• Multiple Availability Zones
• Health checks
• Load balancing
• Auto scaling
• Monitoring
• Failover planning

But caching helps by preventing unnecessary repeated origin requests.

Cost

Origin requests, compute usage, backend scaling, and data transfer can all affect cost.Caching can reduce repeated backend work.

The important idea:

Good caching is not only a performance optimization. It is also an origin-protection strategy.If fewer requests reach the origin, the backend may need less compute capacity, perform less repeated work, and handle traffic more efficiently.

12. Important distinctions in the architecture

Several AWS infrastructure terms sound similar, but they represent different layers of the system.

Region vs Edge Location

A Region is where core AWS infrastructure and services are deployed.An Edge Location or POP is part of the edge network used to serve users with lower latency.

A website may have its origin in one Region and still use CloudFront edge locations globally.

Origin infrastructure → Region User-facing delivery → Edge Locations / POPs Availability Zone vs Edge Location

An Availability Zone helps isolate failure inside a Region.An Edge Location helps deliver content closer to users.

They solve different problems.

Availability Zone → failure isolation Edge Location → low-latency content delivery POP vs Regional Edge Cache

A POP is the closest cache layer to the user.A Regional Edge Cache is a larger cache layer between POPs and the origin.

• POP → closer to user, smaller cache
• Regional Edge Cache → farther than POP, larger cache
• Regional Edge Cache vs Origin Shield

A Regional Edge Cache is part of CloudFront’s default cache hierarchy.Origin Shield is an optional centralized cache layer that can further reduce origin load.Origin Shield becomes especially useful when traffic comes from many locations and multiple Regional Edge Caches might otherwise send repeated cache-miss requests to the origin.

13. Final mental model

AWS global infrastructure is not only a map.

It is a layered system.

Region = where core infrastructure lives Availability Zone = where failure is isolated POP / Edge Location = where users meet AWS edge infrastructure Regional Edge Cache = larger middle cache before origin Origin Shield = optional centralized origin-protection cache Origin = source of truth

The full request path may look like this:

Viewer ↓ CloudFront POP / Edge Location ↓ Regional Edge Cache ↓ Origin Shield, optional ↓ Origin

Once we understand this path, AWS terms stop being isolated definitions.They become architecture tools.Cloud infrastructure is not magic.It is geography, caching, networking, failure isolation, and software-controlled delivery working together.

References

[1] AWS Documentation — Regions, Availability Zones, Local Zones, and Wavelength Zones https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions-availability-zones.html

[2] AWS Global Infrastructure — Regions and Availability Zones https://aws.amazon.com/about-aws/global-infrastructure/regions_az/

[3] AWS Documentation — AWS Availability Zones https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-availability-zones.html

[4] AWS Documentation — AWS Regions and Availability Zones https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions-availability-zones.html