# Edge Services and Global Architectures

> Chapter 16 of the Courseiva AWS-SAP-C02 curriculum — https://courseiva.com/learn/aws-sap-c02/edge-services-and-global-architectures

**Official objective:** 1.5 — Design architectures for global, low-latency workloads

## Introduction

Edge services and global architectures solve one fundamental problem: latency, the painful delay between a user's action and the system's response. For the SAP-C02 exam, you must know how to design systems that serve users across the planet as if they were all next door to the server room.

## The International Pizza Chain Analogy

You have 20 pizza shops spread across 10 countries. A customer in Tokyo orders a pizza at 7 PM local time. If your only pizza kitchen is in New York, the dough must be mixed, topped, baked, and flown 11,000 kilometres. The pizza arrives cold, the cheese is rubbery, and the customer is furious. That is the old world of centralised computing: one kitchen, one data centre, one long, slow journey for every order.

Now, you build small preparation stations in Tokyo, London, São Paulo, and Sydney. Each station keeps pre-portioned dough, sauce, and cheese in stock. When a Tokyo customer orders, the local station bakes the pizza in 6 minutes. The pizza is hot, the cheese is perfectly melted, and the customer is happy. The recipe and quality standards come from headquarters (the main cloud region), but the actual baking happens close to the customer. This is edge computing: your application's logic and data are cached and processed at locations near the user, not in a single central warehouse. In AWS terms, these pizza stations are edge locations, and the network of delivery scooters is Amazon CloudFront. The pizza boxes are cacheable content — popular pizzas that get made once and served many times. The special-order pizzas are dynamic content that must still phone home to the central kitchen. Your global architecture is a network of these distributed pizza stations, all working together to serve every customer as if the shop were on their corner.

## Core explanation

Edge services and global architectures are the set of tools and design patterns that let you run your application from many different locations simultaneously, so users everywhere get fast, reliable experiences.

Let us start with the core problem: the speed of light. Data cannot travel faster than roughly 200,000 kilometres per second in a fibre-optic cable. This is a hard physical limit. If your only server is in Virginia, USA, and a user is in Sydney, Australia, the data must travel roughly 16,000 kilometres each way. Even at the speed of light in glass, that round trip takes about 160 milliseconds just for the physics — plus the time your server spends processing the request, plus the time your database takes to answer. In practice, this adds up to over a second of delay. For a web page, a one-second delay can cut customer satisfaction by 16%. For a real-time game or a financial trading application, it is catastrophic.

AWS solves this with a global network of over 600 points of presence, called edge locations. An edge location is not a full data centre with thousands of servers and databases. It is a small, strategically placed facility with caching servers and specialised hardware. These edge locations are the pizza stations from the analogy. They sit inside major internet exchange points, close to where huge numbers of users connect to the internet.

The first and most famous edge service is Amazon CloudFront. CloudFront is a content delivery network, or CDN. A CDN caches (stores copies of) your static files — images, videos, CSS stylesheets, JavaScript files — at edge locations around the world. When a user in Berlin requests your homepage, the request goes to the nearest edge location in Frankfurt or Berlin itself. If that edge location has a cached copy of the homepage's images and scripts, it serves them instantly. The origin server in Virginia never even sees the request. This reduces load on your main servers and dramatically speeds up the experience for the user.

But edge services go far beyond simple static file caching. AWS WAF (Web Application Firewall) runs at the edge. This means it inspects incoming HTTP requests for malicious patterns — SQL injection, cross-site scripting — before the request ever reaches your main servers. AWS Shield, the distributed denial-of-service (DDoS) protection service, also operates at the edge. It can absorb massive attacks, in the terabit-per-second range, because the edge network itself has enormous bandwidth capacity. If attackers try to flood your application with garbage traffic, the edge absorbs it, and your actual application servers in the region never notice.

The next crucial service is AWS Global Accelerator. Global Accelerator does not cache anything. Instead, it uses the AWS global network to route user traffic to the nearest healthy application endpoint. Think of it as a smart traffic director. A user in India trying to reach your application in London would normally travel across the public internet, which is unpredictable. With Global Accelerator, the user's traffic enters the AWS network at the nearest edge location, then travels entirely inside AWS's private, high-speed fibre backbone to your London application. This makes the connection significantly faster and more consistent.

Route 53, AWS's Domain Name System (DNS) service, is also a global edge service. DNS is the phonebook of the internet — it translates human-readable names like "myapp.com" into IP addresses that computers use to find each other. Route 53 uses edge locations to answer DNS queries very quickly. It also offers sophisticated routing policies:

- Latency-based routing: Route 53 measures the network latency between the user and each AWS region where your application runs. It then gives the user the IP address of the region that will give them the lowest latency.
- Geolocation routing: Route 53 directs traffic based on the user's physical location. You could send users in Europe to your Dublin region and users in Asia to your Singapore region, regardless of actual latency.
- Geoproximity routing: This is like geolocation but you can set a bias to shift traffic. For example, you could send 80% of European traffic to Dublin and 20% to London, even though both are equally close.
- Weighted routing: You send a percentage of traffic to each region. This is useful for testing a new version of your application in one region with a small group of users before rolling it out everywhere.
- Failover routing: If your primary region goes down, Route 53 automatically directs all traffic to your secondary, disaster recovery region.

All these routing policies are managed through DNS. Because DNS responses are cached by the user's own internet service provider (ISP), you have to consider the time-to-live (TTL) setting. A short TTL means DNS changes propagate quickly but the user's device has to query DNS more often, adding slight delay. A long TTL means faster responses but slow updates when you need to change routing, for example during a disaster.

Now we must discuss origin shielding and multi-region architectures. Simply placing copies of your application in multiple AWS regions (say, US East, EU West, and Asia Pacific) is known as a multi-region architecture. But these regions are fully functional, separate data centres. They run your actual application servers, databases, and processing logic. Edge services like CloudFront sit in front of these regions, caching what they can. However, if a user requests a cache miss (content not yet cached), CloudFront must fetch the content from one of your regional origins. To optimise this, you can use origin shielding: an extra layer of caching between the edge locations and your main application servers. This aggregation means many edge locations can fetch content from a single shield, which then fetches from the origin server only once, drastically reducing load on your application.

For truly global, low-latency workloads, you must also consider how you synchronise data between regions. If you have an application where users can write data (like a social media post or a product review), you cannot just cache it at the edge — you must store it permanently. AWS provides several services for this:

- Amazon DynamoDB Global Tables: A fully managed, multi-Region, multi-master database. You write data in one region, and it is automatically replicated to all other regions within seconds. Reads and writes at any region are fast because they hit a local copy.
- Amazon Aurora Global Database: For relational databases, Aurora can span multiple regions with a primary region for writes and up to five secondary regions for fast local reads. If the primary region fails, you can promote a secondary to primary in under a minute.
- Amazon S3 Cross-Region Replication: You can automatically replicate objects from one S3 bucket in one region to another bucket in a different region. This is useful for static assets (images, videos) that need to be available globally.

Putting it all together: a global architecture for a low-latency workload uses edge services (CloudFront, Global Accelerator, Route 53) in front of multiple application regions (multi-region deployment) with data synchronisation (Global Tables, Aurora Global Database) between those regions. Static content is cached at the edge. Dynamic API calls are routed to the nearest region via Global Accelerator or Route 53 latency routing. Security inspection (WAF, Shield) happens at the edge. If a whole region fails, Route 53 failover routing sends all traffic to the remaining healthy region.

This is what the SAP-C02 exam expects you to design. You must know which service fits which scenario, the trade-offs between them, and the common pitfalls that can destroy your latency gains.

## Real-world context

You are a solutions architect at a global e-commerce company called ShopGlobal. The company has 50 million monthly active users spread across North America, Europe, Asia, and Australia. Users shop for products, view images, watch product videos, and check out. The website is currently deployed in a single AWS region: us-east-1 (Northern Virginia). Users in Australia consistently report page load times of 4-5 seconds. Users in Europe report 2-3 seconds. The CEO demands that every user, everywhere, can load the home page in under 1 second. The CTO also wants the site to survive the complete failure of the us-east-1 region without more than 5 minutes of downtime.

Here is exactly what you do, step by step.

First, you enable Amazon CloudFront. You create a CloudFront distribution and point it to the existing us-east-1 Application Load Balancer (ALB) as the origin. You configure CloudFront to cache all static files (images, CSS, JavaScript) for 24 hours. You set this by configuring cache behaviour rules: paths like /images/*, /static/*, and /videos/* are cached. For dynamic content (the shopping cart, user profile), you set CloudFront to forward all requests to the origin every time (no caching) but still use the edge network for the TCP connection benefits. The first user in Sydney now loads the page in 2 seconds instead of 4, because images come from a Sydney edge location.

Second, you enable AWS WAF on the CloudFront distribution. You use the managed rule sets for common threats (SQL injection, cross-site scripting, known bad bots). This blocks malicious traffic at the edge, before it ever reaches the ALB. The application servers now handle 40% fewer total requests because the edge blocks bad traffic and serves cached content directly.

Third, you deploy the application into a second region: ap-southeast-2 (Sydney) and eu-west-1 (Ireland). You use infrastructure as code (AWS CloudFormation) to replicate the entire stack: Virtual Private Cloud (VPC), subnets, ALB, auto scaling groups, and databases. You set up DynamoDB Global Tables for the product catalogue and user sessions. You set up Amazon Aurora Global Database for the transactional order data, with the primary writer in us-east-1 and reader replicas in Sydney and Ireland.

Fourth, you configure Route 53 with latency-based routing. You create a record set for www.shopglobal.com with two entries: one pointing to the us-east-1 ALB, one pointing to the Sydney ALB, and one to the Ireland ALB. Route 53 automatically measures which region responds fastest for each user and routes them there. Users in Australia now get traffic directed to the Sydney region. Users in Europe get routed to Ireland. You set a TTL of 60 seconds so that if you need to change routing quickly, the change propagates fast.

Fifth, you enable AWS Global Accelerator for the dynamic API traffic that cannot be cached. You create two endpoint groups: one for us-east-1 and one for Sydney, pointing to the respective Network Load Balancers (NLBs) in each region. You do not use NLBs for the website itself; you use Global Accelerator for the mobile app's API calls. The mobile app pings a single Global Accelerator DNS name, and the traffic is automatically routed into the nearest healthy region. This eliminates the need for the mobile app to do complex client-side routing.

Finally, you test the disaster recovery scenario. You simulate a failure of us-east-1 by shutting down the primary database. DynamoDB Global Tables handles this transparently — the other regions continue to serve reads and writes. Aurora Global Database takes about 1 minute to promote the Ireland reader to the new primary writer. Route 53 health checks detect that the us-east-1 ALB is unhealthy (because the database is down, the application returns a 503 error). Route 53 automatically stops sending traffic to us-east-1 and sends all traffic to the healthy regions. The total outage is under 2 minutes for read-only operations and under 5 minutes for writes.

The result: page load times drop to under 800ms worldwide. The site survives the region failure. The CEO and CTO are happy. You have successfully designed a global, low-latency architecture using edge services and multi-region deployment.

## Exam focus

The SAP-C02 exam tests your ability to architect global, low-latency workloads across multiple AWS regions and edge services. This is not a trivia test about features. You must be able to decide which service to use in a given scenario and explain why the other options are wrong.

Here are the exact concepts the exam loves to test, with the traps they set:

CloudFront vs Global Accelerator:
- Trap: The scenario says "users need fast access to static and dynamic content". A beginner might pick CloudFront only. The exam wants you to recognise that CloudFront caches only what you configure. If the content is dynamic (real-time chat, personalised API responses), CloudFront's cache hit ratio will be near zero, so you get no benefit. Instead, for dynamic content, you should use Global Accelerator, which optimises the network path without caching.
- Trap: The scenario says "users need consistent IP addresses for whitelisting". CloudFront has a large, changing set of IP addresses. Global Accelerator provides two static IP addresses (or you can bring your own). The exam tests that you know this distinction.

Route 53 routing policies:
- Trap: The scenario says "we want to route traffic based on actual measured performance". A beginner picks geolocation routing. The exam wants latency routing, which bases decisions on real-time network conditions, not fixed geography.
- Trap: The scenario says "we need to route 5% of traffic to a new version of the application for testing". You must use weighted routing, not failover or latency.
- Trap: They might give a scenario where both latency and geolocation seem viable. The correct answer is the one that matches the requirement. If the requirement is "lowest latency", pick latency routing. If the requirement is "comply with data sovereignty laws" (users in Germany must go to Frankfurt), pick geolocation routing.

Origin Shield vs Multi-Region Origins:
- Trap: The scenario says "reduce load on the application servers". The answer is origin shielding, not deploying a second region. Origin Shield aggregates cache misses from all edge locations into a single request to the origin. Deploying a second region adds complexity and cost. Only use multiple regions when you need low-latency writes or disaster recovery.
- Trap: The scenario says "improve latency for write operations". Edge services cannot help here because writes must go to the database. You need DynamoDB Global Tables or Aurora Global Database.

WAF at the edge vs WAF on a regional ALB:
- Trap: The exam might ask "where should we deploy WAF to block a DDoS attack". The answer is on CloudFront (edge) because it absorbs traffic before it reaches your origin. WAF on an ALB only protects the ALB itself, not the network edge.
- Trap: The exam might ask about blocking specific IP addresses. Both edge and regional WAF can do this, but edge WAF is preferred for global workloads.

Key definitions to memorise:
- Edge location: A facility used by CloudFront and Global Accelerator for caching and network optimisation. Not a full region.
- Regional edge cache (origin shield): An intermediate cache layer between CloudFront edge locations and your origin server.
- Origin: The source of truth for your content — an S3 bucket, an ALB, or an EC2 instance.
- Time to live (TTL): How long a DNS record or cached object is considered valid before it must be refreshed.
- Dynamic content: Content that changes per request (personalised pages, stock prices). Do not cache it with long TTLs.
- Static content: Content that does not change frequently (logos, CSS, product images). Cache it aggressively.

Question patterns:
- "Which combination of services provides the lowest latency for a global audience?" Answer: CloudFront for static, Global Accelerator for dynamic, Route 53 latency routing, multi-region origins.
- "How do you handle a regional failure with minimal downtime?" Answer: Route 53 failover routing with health checks on each region's ALB.
- "What is the most cost-effective way to serve static assets globally?" Answer: CloudFront with S3 as the origin.
- "How do you ensure write operations are fast globally?" Answer: DynamoDB Global Tables or Aurora Global Database with local writes and cross-region replication.

Memorise this pattern: edge services handle read-heavy, cacheable content and provide network optimisation. For write-heavy workloads, you need multi-region databases. The exam will mix these up to see if you understand the distinction.

## Step by step

1. **Identify the Content Type** — Separate your application's traffic into static (images, CSS, JavaScript, videos) and dynamic (API responses, personalised content, real-time data). Static content benefits from caching at edge locations. Dynamic content needs network path optimisation.
2. **Deploy CloudFront for Static Content** — Create a CloudFront distribution with your origin (S3 bucket or ALB) as the source. Configure cache behaviours to set TTLs for static paths. Enable origin shield to reduce load on the origin. This step alone can reduce page load times by 50-80% for geographically distributed users.
3. **Enable Global Accelerator for Dynamic Traffic** — Create an AWS Global Accelerator accelerator and associate it with the Network Load Balancers in your chosen regions. This provides two static IP addresses and routes traffic over the AWS backbone. Users anywhere in the world get consistent, low-latency connections to your dynamic APIs.
4. **Configure Route 53 Global Routing** — Set up a hosted zone in Route 53. Create an A record for your domain (e.g., api.mysite.com) using latency-based routing. Add one record for each region where your application is deployed. Configure health checks to automatically remove unhealthy regions from routing.
5. **Set Up Multi-Region Data Synchronisation** — For databases, use DynamoDB Global Tables (NoSQL) or Aurora Global Database (relational) to replicate data across regions. This ensures that writes in one region are visible in all regions within seconds. Without data synchronisation, users might see stale content or experience data loss during a region failure.
6. **Apply Edge Security with WAF and Shield** — Attach AWS WAF to your CloudFront distribution. Use managed rule sets for common threats and create custom rules to block traffic from known bad IPs. Enable AWS Shield Advanced for additional DDoS protection. This protects your entire global footprint from a single configuration point.

## Comparisons

### CloudFront vs Global Accelerator

**CloudFront:**
- Caches static content at edge locations for fast repeated requests.
- Primarily uses HTTP/HTTPS protocols (though it supports WebSocket).
- Does not provide static IP addresses; uses a large dynamic IP range.

**Global Accelerator:**
- Does not cache content; optimises network path for dynamic and UDP traffic.
- Supports TCP, UDP (for real-time apps), and HTTP/HTTPS equally.
- Provides two static IP addresses (or allows you to bring your own).

### Route 53 Latency Routing vs Route 53 Geolocation Routing

**Route 53 Latency Routing:**
- Routes traffic based on actual measured network latency from edge locations.
- Automatically adapts to changing network conditions (congestion, outages).
- Best choice for pure performance optimisation without legal constraints.

**Route 53 Geolocation Routing:**
- Routes traffic based on the user's geographic location (country or continent).
- Does not consider current network performance; uses a fixed mapping of locations to regions.
- Best choice when compliance or data sovereignty laws require specific regional hosting.

### Single Region Architecture vs Multi-Region Architecture

**Single Region Architecture:**
- All compute, storage, and databases are in one AWS region.
- Simpler to manage and fewer cross-region data transfer costs.
- Single point of failure: if the region goes down, the application is unavailable.

**Multi-Region Architecture:**
- Application is deployed in two or more regions with data synchronisation.
- Higher operational complexity and increased data transfer costs.
- Survives a full region outage with Route 53 failover and cross-region databases.

## Diagram

_A simple flow showing how a user in Tokyo connects to edge services (CloudFront, Global Accelerator, Route 53) which route traffic to the healthiest and fastest regional application deployment._

```mermaid
flowchart TD
    User[User in Tokyo] --> Edge[Edge Location Tokyo]
    Edge --> CloudFront[CloudFront CDN]
    CloudFront --> Cache{Cache Hit?}
    Cache -- Yes --> User
    Cache -- No --> OriginShield[Origin Shield / Regional Edge Cache]
    OriginShield --> Region1[App Region US East]
    OriginShield --> Region2[App Region EU West]
    OriginShield --> Region3[App Region Asia Pacific]
    GlobalAccelerator[Global Accelerator] --> User
    GlobalAccelerator --> Region1
    GlobalAccelerator --> Region2
    GlobalAccelerator --> Region3
    Route53[Route 53 DNS] --> User,
    Route53 --> Region1,
    Route53 --> Region2,
    Route53 --> Region3
```

## Common misconceptions

- **Misconception:** CloudFront and Global Accelerator are essentially the same service; pick whichever is cheaper. **Reality:** CloudFront caches content at the edge for fast reads. Global Accelerator does not cache; it optimises the network path for any type of traffic (including UDP and dynamic TCP). They serve different purposes and are often used together. (Both use the same edge network and both improve performance, so beginners assume they are interchangeable. The cache vs no-cache distinction is subtle but critical.)
- **Misconception:** Using CloudFront automatically makes all your content load faster, even dynamic API calls. **Reality:** CloudFront only speeds up content it can cache. If your API responses are unique per user (like a personalised shopping cart), CloudFront will forward every request to the origin anyway, adding a tiny amount of overhead. For dynamic content, use Global Accelerator instead. (Beginners hear 'CDN makes everything faster' without understanding that caching only works for repetitive, cacheable content.)
- **Misconception:** To achieve low latency globally, you must deploy your application in every AWS region where you have users. **Reality:** You only need to deploy in a few strategically chosen regions (e.g., US East, EU West, Asia Pacific). Edge services like CloudFront and Global Accelerator can provide low-latency access to users far from those regions by caching and routing traffic optimally. (It feels intuitive that 'more servers closer = faster', but edge services do the heavy lifting of distribution without the operational cost of managing dozens of full application stacks.)
- **Misconception:** Route 53 latency routing measures the geographic distance between the user and the region. **Reality:** Latency routing measures actual network latency by sending probes from edge locations to your endpoints. Geographic distance is a poor predictor of latency because of internet routing quirks and network congestion. (The word 'latency' sounds abstract, so beginners map it to the more concrete concept of distance. The exam tests this precisely.)
- **Misconception:** Worldwide user responses/performance WorldWide is the same if you use CloudFront. **Reality:** CloudFront improves performance everywhere, but users very close to an edge location with a cache hit will always be faster than users far from any edge location. The number of edge locations is large but finite. Australia, for example, has only a few edge locations, so users in remote parts of Australia may still experience higher latency than users in London. (Advertisements make CDNs sound like magic. Beginners assume every user gets sub-100ms latency, but physical distance and internet infrastructure still matter.)

## Key takeaways

- CloudFront is a CDN that caches static content at 600+ edge locations to reduce latency for repetitive requests.
- Global Accelerator improves performance for dynamic and non-cacheable traffic by routing it over the AWS global network backbone, not the public internet.
- Route 53 latency routing directs users to the AWS region that provides the lowest actual network latency, not the closest geographic region.
- Origin shielding (regional edge cache) reduces load on your application servers by aggregating cache misses from multiple edge locations.
- Multi-region architectures with DynamoDB Global Tables or Aurora Global Database are required for low-latency writes and regional disaster recovery.
- AWS WAF and Shield deployed at the edge block malicious traffic before it can reach your application servers, reducing load and protecting against DDoS attacks.

## FAQ

**What is the difference between an AWS region and an AWS edge location?**

An AWS region is a full data centre cluster with compute, storage, and database services. An edge location is a small facility close to users that caches content and provides network optimisation. There are 33 regions and over 600 edge locations.

**Do I need to deploy my application in every AWS region to get low latency everywhere?**

No. Deploying in two or three strategically chosen regions (e.g., US East, EU West, Asia Pacific) combined with CloudFront and Global Accelerator can serve users worldwide with low latency.

**Can CloudFront cache API responses?**

Yes, but only if the API response is the same for multiple users (e.g., a weather forecast for a city, not a personalised user profile). You must configure CloudFront to cache based on specific query parameters or headers.

**What happens if my primary region goes down with a multi-region architecture?**

Route 53 health checks detect the failure and stop sending traffic to that region. Users are redirected to the next healthiest region. If you use DynamoDB Global Tables or Aurora Global Database, writes continue in the secondary region after a failover.

**Is Global Accelerator a CDN?**

No. A CDN caches content. Global Accelerator does not cache anything — it uses the AWS global network to route traffic to the nearest healthy endpoint, improving performance for any type of traffic, including UDP and TCP applications.

**How do I choose between Route 53 latency routing and geolocation routing?**

Use latency routing when your goal is the fastest possible performance. Use geolocation routing when you need to comply with data sovereignty laws or direct specific countries to specific regions for contractual reasons.

## Check your understanding

1. **You need to serve static images stored in S3 to a global user base with the lowest possible latency. Which AWS service should you use?**

   Answer: Amazon CloudFront. It caches images at edge locations worldwide, so users fetch them from the nearest point rather than directly from the S3 bucket in a single region.

2. **What determines which route a user takes when using Route 53 latency-based routing?**

   Answer: Route 53 measures the network latency from its edge locations to each of your application endpoints and returns the IP address of the endpoint with the lowest latency for that user's location.

3. **Your application serves real-time chat traffic that cannot be cached. How do you improve latency for users worldwide?**

   Answer: Use AWS Global Accelerator. It routes the chat traffic over the AWS global backbone network, providing consistent low-latency connections without caching.

4. **You need to survive a full AWS region failure with less than 5 minutes of downtime. Which architectural pattern should you use?**

   Answer: Deploy your application in at least two AWS regions with DynamoDB Global Tables or Aurora Global Database for data replication, and use Route 53 failover routing with health checks to redirect traffic away from the failed region.

5. **What is the purpose of origin shielding (regional edge cache) in CloudFront?**

   Answer: Origin shielding aggregates cache misses from all edge locations into a single request to the origin server, reducing the load on the origin and improving cache hit ratios.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-sap-c02/edge-services-and-global-architectures