Architecture 1: the static site

Lesson 4-2 covered what enabling static website hosting on an S3 bucket replaced.

A whole web server whose only job was handing out files, something like nginx on an instance. S3 itself serves the files, with no machine of yours involved.

This lesson turns that bucket into a production setup with a real domain, HTTPS, and worldwide speed.

Portfolio, docs, landing page

The production static-site stack is four pieces, three of them managed:

• S3 holds the built files (lesson 4-2).
• CloudFront is AWS's CDN (content delivery network): 400+ edge locations, small caches in cities worldwide. Visitors fetch from the nearest edge, which serves from its cache or pulls from your bucket once and remembers it. This kills both problems S3-alone has: latency for far-away users (lesson 1-2's speed-of-light problem) and it serves repeat traffic from cheaper edge bandwidth (lesson 8-1's meter 4).
• Certificate Manager issues the free TLS certificate, so the site is HTTPS.
• Route 53 (lesson 5-3) holds the DNS records, pointing yoursite.dev at the CloudFront distribution with an alias record.

Deploying is still aws s3 sync from lesson 4-2, plus telling CloudFront to drop its cached copies:

aws s3 sync ./build s3://my-portfolio
aws cloudfront create-invalidation --distribution-id E2ABC123 --paths "/*"

Monthly cost for a typical portfolio: well under $1. There is no server to patch, no security group, nothing to wake you up.

The number that makes a CDN work

The hit ratio is the share of requests the edge answers from cache without bothering S3. A typical static site sits around 95%.

requests=100000
hit_ratio=95
misses=$((requests * (100 - hit_ratio) / 100))
echo "of $requests requests, edges answer $((requests - misses)) from cache"
echo "S3 only sees the $misses misses"

Output

of 100000 requests, edges answer 95000 from cache
S3 only sees the 5000 misses

That single ratio explains both benefits at once. 95,000 requests never cross an ocean, so lesson 1-2's speed-of-light problem applies to only 5,000 of them, and the other 95,000 are answered from a cache in the visitor's own city.

It does the same thing to the bill. Only the 5,000 misses spin lesson 8-1's transfer-out meter on the bucket, and the cached 95,000 leave through CloudFront's cheaper edge bandwidth. Raising the hit ratio from 95% to 99% cuts the origin's share fivefold, which is why cache headers on static assets are a cost lever and not just a performance one.

Fixing 300 ms for a visitor in Singapore

CloudFront fixes it, by serving from an edge location near Singapore after the first fetch.

The 300 ms is physics, as lesson 1-2 established. The request crosses the Pacific and the response crosses back, and no amount of tuning changes the distance.

An edge cache in Singapore answers locally once it has the file, so the second visitor from that region gets roughly your 40 ms. Only the first miss pays the full crossing.

What makes this worth noticing is what you did not have to do. There is no second bucket, no replication to configure, and no deployment to an ap-southeast region. One distribution in front of one bucket covers every city CloudFront has an edge in.

The monthly bill for this architecture

The answer is about 2 cents: 1 GB × $0.023 per GB-month is $0.023, which rounds to $0.02.

Only one of the four services in the diagram is metering anything at all. CloudFront's always-free tier covers the traffic, Certificate Manager issues public certificates at no charge, and S3's storage line is the entire variable cost.

Route 53 does add a real 50 cents a month per hosted zone, the one flat fee in this stack, so a domain-backed portfolio is closer to 52 cents than to 2.

Either way the comparison is the point. The smallest EC2 server from lesson 8-2 costs about $8 a month to do this same job worse, with a slower experience for distant visitors and an operating system you now own.