The Secret Life of AWS: The Edge (Amazon CloudFront)

 

The Secret Life of AWS: The Edge (Amazon CloudFront)

How to reduce global latency using a Content Delivery Network.

#AWS #CloudFront #Latency #Security






Part 51 of The Secret Life of AWS

Timothy was analyzing his new AWS X-Ray Service Map. The backend microservices were performing exceptionally well. The Step Functions orchestrated the orders perfectly, and the DynamoDB queries were returning in single-digit milliseconds.

However, the frontend telemetry told a different story.

"The backend is highly optimized," Timothy explained to Margaret, pointing at his dashboard. "But I am looking at the load times for our users in London and Tokyo. It is taking them over eight hundred milliseconds just to download the product images and the frontend JavaScript files. The users in Virginia get the same files in forty milliseconds."

Margaret looked at the architecture diagram. "Where are those static files stored?"

"In an Amazon S3 bucket located in the us-east-1 region in Virginia," Timothy replied.

"You are running into the physical limitations of the speed of light and network routing," Margaret said kindly. "When a user in Tokyo requests an image, that request has to cross the Pacific Ocean, navigate multiple internet service providers, reach your S3 bucket in Virginia, and then the image payload has to travel all the way back. You have optimized your compute layer, but you have not optimized your delivery layer. We need to implement a Content Delivery Network (CDN)."

The Origin and The Edge

Margaret opened the AWS Console and navigated to Amazon CloudFront.

"CloudFront is AWS's native CDN," she explained. "Instead of forcing every global user to retrieve files directly from your S3 bucket in Virginia, CloudFront distributes copies of your files to hundreds of data centers around the world. These data centers are called Edge Locations."

She clicked Create Distribution.

"First, we define the Origin," Margaret said, selecting Timothy's us-east-1 S3 bucket from the dropdown menu. "The Origin is the authoritative source of your data. It is where the original files live."

"But we do not leave the S3 bucket open to the public internet," she added, immediately navigating to the security settings. "Using Origin Access Control (OAC), we configure the bucket policy so that it rejects all public web traffic. It will only accept read requests that come specifically from this CloudFront distribution."

"When a user in Tokyo requests a product image," she continued, "the DNS routing directs them to the CloudFront Edge Location physically closest to them in Japan, not to Virginia. If the Edge Location already has a copy of that image, it serves it immediately. This is called a Cache Hit. The data travels a few miles instead of thousands of miles, dropping the latency from eight hundred milliseconds to under twenty milliseconds."

"Does this only work for static images?" Timothy asked.

"Not at all," Margaret replied. "CloudFront also accelerates our dynamic API calls. Instead of a user in Tokyo routing their Checkout API request across the unpredictable public internet, CloudFront ingests the request at the Tokyo Edge Location and speeds it across AWS's private, dedicated fiber network directly to our API Gateway."

Cache Misses and Time-to-Live (TTL)

Timothy thought about the data flow. "What happens if it is a brand-new product image, and the Edge Location in Tokyo doesn't have a copy yet?"

"That is a Cache Miss," Margaret replied. "The Edge Location realizes it does not have the file. It opens a dedicated, high-speed connection back to your S3 Origin in Virginia. It fetches the image, serves it to the user in Tokyo, and simultaneously saves a copy locally. The next user in Tokyo who requests that image will experience a Cache Hit."

"How long does the Edge Location keep the file?" Timothy asked. "If the marketing team updates a product image, I don't want the Edge Locations serving the old version forever."

Margaret scrolled down to the Cache Behavior settings. "We control that using Time-to-Live (TTL). We configure an HTTP header that tells CloudFront exactly how many seconds to cache the file. If we set a TTL of 86,400 seconds, the Edge Location will serve the cached copy for exactly 24 hours. After that, the cache expires, and the next request will force CloudFront to fetch the newest version from the Origin."

Versioning vs. Invalidations

"Twenty-four hours is a good default," Timothy noted. "But what if we make a critical mistake? What if we upload the wrong logo, and we need it replaced globally immediately? We cannot wait 24 hours for the TTL to expire."

"The standard architectural best practice is File Versioning," Margaret explained. "Instead of overwriting logo.png, you upload the corrected file as logo_v2.png and update your HTML to point to the new filename. Because CloudFront has never seen logo_v2.png before, it treats it as an instant Cache Miss and fetches the new file immediately, completely bypassing the 24-hour wait."

"If you absolutely must delete a file from the global cache without changing its name, we run a Cache Invalidation," she added, opening the Invalidations tab. "We specify the exact file path, such as /images/logo.png. CloudFront instantly broadcasts a command to every Edge Location worldwide, instructing them to delete their cached copy. However, invalidations take time to propagate and cost money at scale, so they should be reserved for emergencies."

Timothy updated the frontend application to point to the new CloudFront domain name. He watched the X-Ray telemetry update. The load times for users in London and Tokyo plummeted to match the local users in Virginia.

The application wasn't just observable anymore. It was globally distributed.


Key Concepts Introduced:

Amazon CloudFront is a fast, highly secure Content Delivery Network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency and high transfer speeds. It works by caching copies of your static and dynamic content at physical data centers located close to your end users, drastically reducing the distance data must travel over the public internet. It also optimizes dynamic traffic by routing API requests over the dedicated AWS global network backbone rather than relying on public internet routing.

The Origin is the definitive source of your content, such as an Amazon S3 bucket or an EC2 instance, where the original files are securely stored. To ensure security, Origin Access Control (OAC) is used to lock down the Origin so it can only be accessed through the CloudFront distribution, preventing users from bypassing the CDN and accessing the data directly. Edge Locations are the global AWS data centers that retrieve and cache data from the Origin to serve local user requests. When a user requests a file, a Cache Hit occurs if the Edge Location already holds a valid copy, serving it instantly. A Cache Miss occurs if the file is absent or expired, prompting the Edge Location to fetch a fresh copy from the Origin.

The duration a file remains in the cache is dictated by its Time-to-Live (TTL), a configuration that balances performance with data freshness. If content must be updated instantly, the best practice is File Versioning (changing the file name, e.g., image_v2.jpg), which forces a Cache Miss. In absolute emergencies where the filename cannot be changed, administrators can issue a Cache Invalidation. This command forces all Edge Locations worldwide to immediately discard their cached copies, ensuring that subsequent requests fetch the most up-to-date content directly from the Origin server.


Aaron Rose is a software engineer and technology writer at tech-reader.blog.

Comments

Popular posts from this blog

Insight: The Great Minimal OS Showdown—DietPi vs Raspberry Pi OS Lite

The New ChatGPT Reason Feature: What It Is and Why You Should Use It

Raspberry Pi Connect vs. RealVNC: A Comprehensive Comparison