AWS CloudFront CDN

# CHAPTER 7

AWS CloudFront CDN #

1. Introduction #

The internet is bound by the laws of physics. If your S3 bucket or EC2 server is located in New York, and a user in Tokyo clicks your website, that data must travel through underwater fiber-optic cables across the globe. This physical distance causes latency (lag), resulting in slow load times and lost customers. AWS solves this geographic limitation using Amazon CloudFront, a global Content Delivery Network (CDN). In this chapter, we will learn how to drastically improve website performance and security by caching our content at the edges of the internet.

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Define what a Content Delivery Network (CDN) is.

• Understand the concept of Edge Locations vs AWS Regions.

• Explain the mechanics of Caching and Time To Live (TTL).

• Deploy an Amazon CloudFront Distribution.

• Secure an S3 bucket so it is only accessible via CloudFront.

3. Beginner-Friendly Explanation #

Imagine you publish a highly popular newspaper in New York.

• Without a CDN: A subscriber in Tokyo wants to read the paper. You print it in NY and mail it via an airplane. It takes 3 days to arrive.

• With a CDN: You build a small printing kiosk (An Edge Location) right in the center of Tokyo. When the first person in Tokyo asks for the paper, the kiosk calls NY, downloads the PDF, and prints it. Crucially, the kiosk keeps a copy of the PDF (Caching). When the next 10,000 people in Tokyo ask for the paper, the kiosk prints it locally in seconds, completely ignoring New York.

CloudFront is a global network of hundreds of digital kiosks that hold copies of your website close to your users.

4. Edge Locations vs. AWS Regions #

As we learned in Chapter 1, AWS has around 30 major Regions (massive data centers). However, AWS has over 400 Edge Locations. These are much smaller, highly distributed server hubs located in almost every major city in the world. CloudFront operates exclusively out of these Edge Locations.

5. The CloudFront Workflow #

1. 1. The Origin: This is where the original, master copy of your data lives. It is usually an S3 Bucket or an EC2 Web Server.

1. 2. The Distribution: You create a CloudFront Distribution and point it at your Origin. CloudFront gives you a unique global URL (e.g., d12345.cloudfront.net).

1. 3. The Request: A user in Sydney requests an image via the CloudFront URL.

1. 4. Cache Miss: The Sydney Edge Location checks its memory. It doesn't have the image. It fetches it from your NY Origin, saves a copy in Sydney, and sends it to the user.

1. 5. Cache Hit: Another user in Sydney requests the same image. The Sydney Edge Location instantly returns the saved copy. The NY server does zero work.

6. Time To Live (TTL) and Cache Invalidation #

How long does the Edge Location keep the copy? This is defined by the TTL (Time To Live), usually measured in hours or days. If you upload a brand new logo to your S3 bucket, users in Sydney will still see the old logo until the TTL expires! To force the Edge Locations to delete the old copies immediately, you must run a CloudFront Invalidation.

7. Mini Project: Deliver S3 Website through CloudFront #

Let's supercharge the S3 static website we built in Chapter 6.

Step-by-Step Tutorial:

1. 1. Open the AWS Console and search for CloudFront.

1. 2. Click Create Distribution.

1. 3. Origin Domain: Click the box and select your S3 Bucket from Chapter 6.

1. 4. Origin Access (Crucial Security Step): Select Origin access control settings (OAC). This tells CloudFront to securely authenticate with S3. Click "Create control setting" and accept the defaults.

1. 5. Viewer Protocol Policy: Select Redirect HTTP to HTTPS. (CloudFront provides free HTTPS encryption globally!).

1. 6. Web Application Firewall (WAF): Select "Do not enable security protections" (to avoid charges for this tutorial).

1. 7. Scroll down and click Create Distribution.

1. 8. IMPORTANT: At the top of the next screen, you will see a yellow banner asking you to update your S3 bucket policy. Click Copy policy.

1. 9. Go back to your S3 Bucket -> Permissions -> Bucket Policy. Replace your old public policy with the copied policy. This explicitly blocks the public internet from accessing the S3 bucket directly, forcing everyone to use the fast, secure CloudFront URL!

1. 10. Wait 5 minutes for CloudFront to deploy globally. Then, access your site using the Distribution domain name (e.g., https://dxxxx.cloudfront.net).

8. Best Practices #

• Never Serve Images from EC2: Your EC2 server has limited bandwidth and CPU. If 1,000 users request a 5MB image from EC2, the server will crash. Always move heavy static assets (Images, CSS, JS, Videos) to S3, and serve them via CloudFront. The EC2 server should only compute dynamic HTML or JSON.

9. Common Mistakes #

• Forgetting Invalidation: Junior developers often spend hours debugging their HTML or CSS because their website changes aren't appearing on the live site. They forget that CloudFront is caching the old CSS file. Always run an Invalidation (/*) when deploying new frontend code.

10. Exercises #

1. 1. Define what a "Cache Hit" and a "Cache Miss" are in the context of a Content Delivery Network.

1. 2. Why is it a security best practice to lock down an S3 bucket so it can *only* be accessed by CloudFront via Origin Access Control (OAC)?

11. MCQs with Answers #

12. Interview Questions #

• Q: Differentiate between an AWS Region and an AWS Edge Location. How do they work together in an S3 + CloudFront architecture?

• Q: Explain the concept of Time To Live (TTL) in a CDN. What are the architectural trade-offs between configuring a very short TTL versus a very long TTL?

13. FAQs #

Q: Can CloudFront cache a dynamic Node.js API response? A: Yes! While CloudFront is famous for static images, you can configure it to cache dynamic JSON responses based on Query Parameters or Headers. However, you must be extremely careful not to cache user-specific data (like a private bank account balance), or User A might see User B's data!

14. Summary #

In Chapter 7, we defeated the latency of physical distance. We introduced Amazon CloudFront and the concept of Content Delivery Networks. By understanding the distinction between Origins (where data lives) and Edge Locations (where data is cached), we achieved two massive architectural upgrades: our website now loads instantly anywhere in the world, and we automatically secured it with HTTPS encryption without configuring a single SSL certificate manually.

15. Next Chapter Recommendation #

Our website is fast and secure, but the URL d12345.cloudfront.net is terrible for marketing. Proceed to Chapter 8: AWS Route 53 DNS Management.