AWS Day-19: AWS CloudFront (Content Delivery Network) & S3 Integration

1. Why Do We Need a Content Delivery Network (CDN)?

When serving static assets, media, or web applications globally, relying solely on a centralized storage system or server introduces significant performance bottlenecks.

• The Global Latency Problem: If an application's central storage or server is hosted in a single region (e.g., North Virginia, US), users accessing the platform from distant geographic locations (e.g., India or Australia) experience high latency.
• Network Hops: Every web request must traverse multiple routers and intermediate network hops across the globe. The greater the physical distance and number of hops, the higher the round-trip time (RTT) and the slower the content delivery.
• Direct Storage Exposure Risks: Allowing end users to directly access an object storage bucket (like an AWS S3 bucket) presents severe security vulnerabilities, lack of caching optimization, and unpredictable data egress pricing.

2. Core Mental Model: Real-World Analogy & CDN Architecture

Real-Life Analogy: The Local Library vs. The National Archive

Imagine you live in New Delhi and want to read a rare historical manuscript stored exclusively in a national archive in Washington, D.C.

• Without CDN: Every single citizen wanting to read that manuscript must send a request all the way to Washington, D.C., causing massive shipping delays, high transit costs, and congestion at the central archive.
• With CDN: Instead of everyone querying the central archive, copies of the manuscript are placed in local neighborhood libraries (Edge Locations) worldwide. When a user in Delhi requests the manuscript, the local library hands it over instantly.

How CloudFront Operates

3. What is AWS CloudFront?

AWS CloudFront is a managed Content Delivery Network (CDN) service provided by Amazon Web Services that securely delivers data, videos, applications, and APIs to customers globally with low latency and high transfer speeds.

• Edge Locations: CloudFront relies on a global network of proxy servers called Edge Locations distributed worldwide.
• Caching Mechanism: CloudFront caches content (images, CSS, JS, video files) at these edge locations. When a user requests an asset, CloudFront routes the request to the nearest edge location.
• Origin Servers: If the requested content is not cached at the edge (Cache Miss), CloudFront fetches it from the designated Origin (such as an S3 bucket, EC2 instance, Application Load Balancer, or API Gateway) and stores a local copy for subsequent requests.

4. Why Use CloudFront with Amazon S3?

Hosting a static website directly on an S3 bucket and exposing it publicly is a common anti-pattern in production environments. Integrating CloudFront with S3 solves four major engineering challenges:

5. Step-by-Step Configuration Walkthrough

In the demonstration, instructor Piyush walks through hosting a static website on Amazon S3 and putting an AWS CloudFront distribution in front of it securely using an Origin Access Identity (OAI).

Step 1: Create an S3 Bucket for Static Hosting

1. Navigate to the S3 Console and click Create Bucket.
2. Bucket Name: Name the bucket identical to your custom domain (e.g., www.tutorials-with-piyush.com).
3. Region: Select your desired AWS Region (e.g., us-east-1).
4. Block Public Access: Ensure Block all public access remains CHECKED (critical for security so users cannot bypass CloudFront).
5. Bucket Versioning: Enable versioning to protect against accidental object deletions.
6. Click Create Bucket.

Step 2: Enable Static Website Hosting & Upload Assets

1. Open the newly created S3 bucket, go to the Properties tab, scroll to Static website hosting, and click Edit.
2. Select Enable, choose Host a static website, and specify:
   • Index document: index.html
   • Error document: error.html
3. Click Save changes.
4. Go to the Objects tab and upload your static files (index.html, CSS stylesheets, and media assets).

Step 3: Create a CloudFront Distribution

1. Navigate to the CloudFront Console and click Create distribution.
2. Origin Domain: Select your S3 bucket from the dropdown list (AWS will warn about static website hosting endpoints; select the S3 bucket origin).
3. Origin Access: Choose Legacy access identities (or Origin Access Control - OAC).
4. Select Create new OAI (acts as a virtual service account granting CloudFront read-only access to the S3 bucket).
5. Bucket Policy: Select Yes, update the bucket policy so AWS automatically injects the necessary permissions into your S3 bucket policy.
6. Viewer Protocol Policy: Configure HTTP to HTTPS redirection if required.
7. Web Application Firewall (WAF): Enable or disable WAF depending on security and cost requirements.
8. Price Class: Choose whether to use all global edge locations or restrict to specific regions (e.g., North America and Europe) to manage costs.
9. Click Create distribution. CloudFront takes a few minutes to deploy globally.

6. Verifying Security & Access Control

Once the CloudFront distribution is deployed successfully:

1. Direct S3 Access Test: Copy the S3 bucket's static website endpoint URL and attempt to access it directly in a browser.
   • Result: 403 Forbidden error. This confirms that public access is successfully blocked, and users cannot bypass CloudFront.
2. CloudFront Distribution URL Test: Copy the CloudFront distribution domain name (e.g., d111111abcdef8.cloudfront.net) and open it in a browser.
   • Result: The website renders successfully with minimal latency, served directly from the nearest Edge Location.

Behind the Scenes: S3 Bucket Policy Generated by OAI

To allow CloudFront to securely read objects from the private S3 bucket without making the bucket public, AWS automatically appends a bucket policy similar to this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E1ABC123EXAMPLE"
      },
      "Action": "S3:GetObject",
      "Resource": "arn:aws:s3:::tutorials-with-piyush.com/*"
    }
  ]
}

7. Real-World Pitfalls, Pricing & Cleanup

• Cost Awareness: CloudFront is a paid service. While it optimizes data transfer costs at scale, practicing and leaving distributions or large assets active in a free-tier or personal AWS account can incur unexpected charges.
• Deployment Delays: CloudFront updates and initial deployments take 5 to 10 minutes to propagate across global edge servers. Changes made to S3 files may not reflect instantly at the edge unless an invalidation (/*) is created.
• Resource Cleanup: Always delete your CloudFront distribution (disable it first, then delete) and empty/delete your S3 buckets after completing Hands-On labs to avoid ongoing billing.

8. Summary and Key Takeaways

• Content Delivery Network (CDN): CloudFront caches static and dynamic content across a global network of Edge Locations, drastically reducing latency for international users.
• Architecture Flow: User requests route to the nearest CloudFront Edge Location rather than traversing multiple network hops to a centralized origin server.
• Security Best Practices: S3 buckets should always block public access when paired with CloudFront, utilizing an Origin Access Identity (OAI) or Origin Access Control (OAC) for secure communication.
• Reduced Costs: Caching heavy static assets (audio, video, images, CSS) at edge locations decreases direct S3 download request volume and associated data transfer costs.
• Error 403 Forbidden: A successful secure setup results in direct S3 URLs throwing a 403 Forbidden error, while the CloudFront distribution URL successfully renders the application.
• Global Reach vs. Cost: Engineers can configure CloudFront price classes to serve specific geographic regions (e.g., North America and Europe) to optimize performance versus operational expenses.
• Cache Invalidation: When website assets are updated in S3, a CloudFront cache invalidation must be performed to push fresh content to edge servers.
• Resource Hygiene: Always remember to disable and delete CloudFront distributions and S3 buckets promptly after completing lab exercises to prevent unwanted AWS billing.