CloudFront & Global Accelerator

1. What Amazon CloudFront is

Amazon CloudFront is the AWS Content Delivery Network (CDN). The idea is simple: instead of making a user in Melbourne pull every image from a server in the United States, CloudFront caches the content at the edge, close to the user, and serves it from there.

What the deck highlights:

• It improves read performance because content is cached at the edge.
• It improves the user experience.
• There are hundreds of Points of Presence globally — edge locations, caches.
• It provides DDoS protection, precisely because it is spread worldwide, and it integrates with AWS Shield and AWS Web Application Firewall (WAF).

At a high level, a client sends an HTTP request such as GET /beach.jpg?size=300x300 to the nearest CloudFront edge location. If the edge has the object in its local cache, it answers immediately. If not, it forwards the request to your origin, caches what comes back, and serves it.

2. Origin types

An origin is where CloudFront fetches content when the cache misses. There are three families.

S3 bucket:

• for distributing files and caching them at the edge,
• also for uploading files to S3 through CloudFront,
• secured using Origin Access Control (OAC).

VPC origin:

• for applications hosted in VPC private subnets,
• targets an Application Load Balancer, a Network Load Balancer, or EC2 instances.

Custom origin (HTTP):

• an S3 website — you must first enable the bucket as a static S3 website,
• any public HTTP backend you want.

S3 as an origin, with OAC

When the origin is an S3 bucket, users reach the nearest edge (Los Angeles, Mumbai, Melbourne, São Paulo) over the public Internet, and the edge reaches the bucket over the private AWS network. The bucket itself stays private: Origin Access Control plus an S3 bucket policy allow only CloudFront to read it, so nobody can bypass the CDN and hit the bucket directly.

Exam tip

Note that an S3 bucket used as a CloudFront origin and an S3 static website used as a custom origin are two different configurations. The first is secured with OAC and the bucket stays private; the second requires the bucket to be enabled as a static website and is treated as a plain HTTP backend.

CloudFront vs S3 Cross-Region Replication

These two get confused because both make data “available in more places”.

	CloudFront	S3 Cross-Region Replication
Reach	Global edge network	Set up per region you want to replicate to
Freshness	Files are cached for a TTL (maybe a day)	Files are updated in near real time
Access	Read through the CDN	Read only at the destination
Best for	Static content that must be available everywhere	Dynamic content that needs low latency in a few regions

3. ALB or EC2 as an origin

Using VPC origins

VPC origins let you deliver content from applications hosted in your VPC private subnets, with no need to expose them on the Internet. Traffic can be delivered to a private Application Load Balancer, a private Network Load Balancer, or private EC2 instances.

Using the public network

If you are not using VPC origins, the origin must be reachable from the edge locations over the Internet, and security groups have to be opened accordingly:

• With a load balancer: the ALB must be public and its security group must allow the public IPs of the edge locations. The EC2 instances can stay private, with a security group that only allows the load balancer’s security group.
• Without a load balancer: the EC2 instances must be public, and their security group must allow the public IPs of the edge locations.

AWS publishes the list of CloudFront edge IP ranges at http://d7uri8nf7uskq.cloudfront.net/tools/list-cloudfront-ips, which is what you use to build those rules.

Exam tip

Remember the two-tier security group pattern: edge public IPs → load balancer SG, then load balancer SG → instance SG. An answer that opens the instances to 0.0.0.0/0 when a load balancer is in the picture is the wrong one.

4. Geo Restriction

You can restrict who can access your distribution by country:

• Allowlist — users can access your content only if they are in one of the approved countries.
• Blocklist — users are prevented from accessing your content if they are in one of the banned countries.

The country is determined using a third-party Geo-IP database. The classic use case is copyright law, where licensing only covers certain territories.

5. Pricing and price classes

CloudFront edge locations are all around the world, and the cost of data out varies per edge location — some regions are considerably more expensive than others.

To control that, you can reduce the number of edge locations used, for cost reduction. There are three price classes:

1. Price Class All keeps every region in play, which is what gives it the best performance of the three.
2. Price Class 200 keeps most of them, dropping the priciest regions from the set.
3. Price Class 100 narrows it furthest, down to the cheapest regions only.

Exam tip

Price classes trade latency for money. A question that says “reduce CloudFront cost, some users may accept higher latency” is answered by moving to Price Class 200 or 100 — not by disabling caching or shortening the TTL.

6. Cache Invalidation

CloudFront does not know when you update the origin. If you change index.html in S3, the edge locations keep serving the old copy until the TTL expires. That is painful right after a deployment.

• You can force a full or partial cache refresh, bypassing the TTL, by performing a CloudFront invalidation.
• You can invalidate all files (*) or a specific path (/images/*).

Invalidate:
  - /index.html
  - /images/*

Real-world example

You deploy a new build of a static site to the S3 bucket behind CloudFront. Visitors still see the old page because the edge cache has not expired. You create an invalidation for /index.html and /images/*; the next request forces the edge to refetch from the origin, and users see the new version immediately.

7. The global users problem

Picture this: you have deployed an application behind a public ALB in one region, but your users are in America, Australia, Europe and India, and they want to access it directly — this is not cacheable static content. Their traffic crosses the public Internet through many hops, and every hop adds latency.

What you want is to enter the AWS network as early as possible and stay on it, to minimize latency. That is exactly the problem AWS Global Accelerator solves.

Unicast IP vs Anycast IP

Two addressing concepts make Global Accelerator click:

• Unicast IP: one server holds one IP address. Two servers have two different addresses, 12.34.56.78 and 98.76.54.32, and the client must pick the right one.
• Anycast IP: all servers hold the same IP address, and the client is routed to the nearest one. Both servers answer on 12.34.56.78.

8. AWS Global Accelerator

AWS Global Accelerator leverages the AWS internal network to route traffic to your application.

• 2 Anycast IPs are created for your application.
• The Anycast IPs send traffic directly to edge locations near the user.
• The edge locations send the traffic to your application over the private AWS network, instead of continuing across the public Internet.

Its characteristics:

• Works with Elastic IP, EC2 instances, ALB and NLB, public or private.
• Consistent performance
  • Intelligent routing to the lowest-latency endpoint, and fast regional failover.
  • No issue with client caching, because the IP address does not change.
  • Runs over the internal AWS network.
• Health checks
  • Global Accelerator performs health checks on your applications.
  • Helps make your application global, with failover in less than 1 minute for an unhealthy endpoint.
  • Great for disaster recovery, thanks to those health checks.
• Security
  • Only 2 external IPs need to be whitelisted.
  • DDoS protection thanks to AWS Shield.

Real-world example

An online game speaks UDP and has players across Asia and Europe. UDP traffic is not cacheable, so a CDN does not help. With Global Accelerator, players connect to two fixed Anycast IPs, enter the AWS network at the nearest edge location, and continue to the region running the game servers; if that region fails a health check, traffic shifts in under a minute.

9. Global Accelerator vs CloudFront

The two services are alike in two ways: both use the AWS global network and its edge locations, and both integrate with AWS Shield for DDoS protection. The difference is the kind of traffic they optimize.

	CloudFront	Global Accelerator
Speeds up	Content that can be cached, images and videos among them, and equally content that cannot — API calls, dynamically assembled pages	Just about any TCP or UDP application
How	The response itself comes out of the edge	The edge forwards the packets on to your application, wherever in AWS it runs, across one region or several
Also good for	—	Anything not speaking HTTP: game traffic over UDP, IoT over MQTT, Voice over IP. Also HTTP workloads with two specific needs — fixed IP addresses, or regional failover that is fast and predictable

Exam tip

Keyword shortcut: hear “cache”, “static content”, “video”, “dynamic site delivery” and pick CloudFront. Hear “UDP”, “MQTT”, “VoIP”, “static IP addresses”, “fast regional failover” and pick Global Accelerator.

Quick recap

Item	What to remember for the exam
CloudFront	CDN, caches at hundreds of edge locations, DDoS protection, integrates with Shield and WAF
Origins	S3 (secured with OAC), VPC origin (private ALB/NLB/EC2), custom HTTP origin (S3 static website or any public backend)
CloudFront vs CRR	CloudFront = global edge, cached for a TTL, static content; CRR = set up per region, near real-time, read only, dynamic content in a few regions
Public-network origins	ALB must be public and allow the edge public IPs; EC2 can stay private and allow only the LB security group; with no LB, EC2 must be public
Geo Restriction	Allowlist / blocklist by country using a third-party Geo-IP database; use case is copyright
Price classes	All (best performance) · 200 (excludes the most expensive regions) · 100 (least expensive regions only)
Invalidation	Forces a cache refresh, bypassing the TTL; invalidate * or /images/*
Anycast IP	Every server shares one IP, the client is routed to the nearest one
Global Accelerator	2 Anycast IPs, enters the AWS network at the edge; works with EIP, EC2, ALB, NLB (public or private); health-check failover under 1 minute; only 2 IPs to whitelist
Choosing between them	Cacheable or HTTP with dynamic delivery → CloudFront; TCP/UDP, non-HTTP, static IPs, fast regional failover → Global Accelerator