CloudFront and Global Accelerator: Closer to Your Visitors

In part eleven your site got a name, but its server is still in one place. A distant visitor's request crosses continents and many networks on the public internet, and every request takes time.

You have two services for this problem: CloudFront keeps a copy near the visitor, and Global Accelerator shortens the road itself.

CloudFront: a copy near every visitor #

CloudFront is a content delivery network (CDN). It uses the edge locations spread around the world: the first visitor to request a file makes CloudFront fetch it from your origin and keep it, and later visitors in the same area get it directly from the edge location.

What do you gain?

• Higher speed: the answer comes from somewhere close.
• Less load on the origin: most requests end at the edge.
• Protection: it comes with Shield Standard against DDoS attacks, and you can add WAF.
• Free HTTPS: with an ACM certificate, and TLS handled at the edge.

Origins #

The origin is where the content originally lives. The key point is that visitors shouldn't be able to skip CloudFront and reach it directly:

We cover S3 in detail in the object storage section.

What gets cached, and for how long? #

• Cache key: the URL by default. The more headers or cookies you add to it, the lower the chance of finding a ready copy, so keep it minimal.
• Lifetime: from the origin's Cache-Control header, or from CloudFront's settings.
• Behaviors: rules by path, such as /images/* with a long lifetime and /api/* with no caching. One domain can serve both static and dynamic content.

Clearing the cache #

If you change a file, the old copy stays until it expires. You have two solutions:

• Invalidation: you ask CloudFront to clear paths, such as /*. The first 1,000 paths each month are free.
• A version in the file name: such as main.css?v=12, so a new version is a new URL. This is the better solution for static files.

Extra features #

• Geo restriction: allow or block certain countries, for example for content licensed to one country.
• Signed URLs: for paid or private content, with a link that expires.
• CloudFront Functions and Lambda@Edge: short code running at the edge, such as redirects and header changes.

Pricing #

You have two options, and prices can change, so check them before deciding:

• Pay as you go: you pay for outgoing data and requests, at rates that vary by area. Each month you get 1 TB and 10 million requests free. Price classes let you leave out the most expensive areas in exchange for less coverage.
• Flat-rate plans: Free, Pro, Business and Premium, with a monthly price per distribution and no surprises, including other services such as WAF.

Data moving from S3 or an ALB to CloudFront is free.

CloudFront or S3 replication between Regions? #

Global Accelerator: a faster road #

Some traffic can't be cached: a game over UDP, a voice call or a payment request. It has to reach your application itself, and on the public internet it passes through many networks with unsteady delays.

Global Accelerator brings the visitor onto AWS's private network at the nearest edge location, and carries on along it to your application.

Two static addresses through Anycast #

On the ordinary internet (Unicast), each address has one machine. With Anycast, several places share the same address, and the network takes you to the nearest.

Global Accelerator gives you two static addresses of this kind, pointing at ALBs, NLBs, EC2 servers or Elastic IPs, even across Regions. That gives you:

• Addresses that don't change: your customers can allow them in their firewalls.
• Fast failover: it follows the application's health and moves traffic, with no waiting for DNS caches on people's devices.
• Traffic control: you set each Region's share, so you can try a new version in one of them.
• Protection: Shield Standard, and your application isn't exposed directly.

It costs a fixed hourly fee plus an extra data charge, so it has no free allowance like CloudFront's.

Which should you choose? #

If your application is HTTP, start with CloudFront.

The full picture so far #

The visitor's path now looks like this: Route 53 gives them the address, then CloudFront answers from the nearest location if it has a copy, otherwise it passes the request to the ALB, which spreads it across Auto Scaling servers that read from ElastiCache and RDS.

Hands-on: see the cache for yourself #

We'll put CloudFront in front of your web-1 server from part three, since it allows HTTP from anywhere. From CloudShell:

ORIGIN=$(aws ec2 describe-instances \
  --filters "Name=tag:Name,Values=web-1" "Name=instance-state-name,Values=running" \
  --query "Reservations[0].Instances[0].PublicDnsName" --output text)

aws cloudfront create-distribution \
  --origin-domain-name "$ORIGIN" \
  --query "Distribution.[Id,DomainName]" --output table

Note the ID and domain from the table, and wait until it's ready, which takes a few minutes:

aws cloudfront wait distribution-deployed --id YOUR-DISTRIBUTION-ID

Now request the page three times and look at the headers:

for i in 1 2 3; do
  curl -s -o /dev/null -D - https://YOUR-DOMAIN.cloudfront.net \
    | grep -iE "^(x-cache|age|x-amz-cf-pop)"
  echo
  sleep 2
done

The first request returns Miss from cloudfront, and later ones Hit from cloudfront with a growing age. x-amz-cf-pop shows the edge location that answered you.

Now change the page on the server through EC2 Instance Connect:

echo "<h1>New version</h1>" | sudo tee /usr/share/nginx/html/index.html

Open the CloudFront link and you'll find the old page, because it's still cached. Clear it from CloudShell:

aws cloudfront create-invalidation \
  --distribution-id YOUR-DISTRIBUTION-ID --paths "/*"

Moments later the new page appears.

Summary #

• CloudFront keeps copies near visitors, so the site gets faster and the origin gets less load.
• Keep your origin private through OAC or VPC origins, so nobody can skip CloudFront.
• A version in the file name beats clearing the cache every time.
• Global Accelerator doesn't cache, but carries any TCP or UDP over AWS's network with two static addresses.
• If your application is HTTP, start with CloudFront.

Test yourself #

Before you move on, try these questions to check you've got this part. Each one is a practical scenario, and the explanation appears once you answer.

All this brings the visitor to your network's door, but how is the network itself built? In part thirteen we open up the VPC and build one from scratch.