Amazon CloudFront - AWS's CDN That Actually Works (Sometimes)

CloudFront is AWS's CDN that's been around since 2008. It works like any other CDN - caches your content closer to users so they don't have to reach back to your origin server every time. Sounds simple, right? It's not.

The Three-Tier Shit Show

CloudFront has this weird three-tier architecture that AWS loves to overcomplicate:

Edge Locations are the 700+ servers where your content gets cached. These are spread across major cities, but don't expect even coverage. Some locations are fast, others will make you want to throw your laptop. The official edge location list changes constantly because AWS keeps adding more, which is nice, but good luck figuring out which one your users are actually hitting.

Regional Edge Caches sit between the edge locations and your origin. AWS has 13 of these globally, and they're supposed to reduce origin load. In practice, they add another layer of potential failure. When something goes wrong, you get to debug through two cache layers instead of one.

Embedded PoPs are AWS's attempt to get even closer to users by putting cache servers inside ISP networks. Sounds great until you realize you have zero visibility into which ones are working and which ones are basically broken.

Cache Behavior Hell

Here's where CloudFront gets really fun. Cache behaviors in CloudFront are batshit insane - whoever designed the priority system was either drunk or hates developers. They work backwards from what any sane person would expect. You configure cache behaviors to tell CloudFront how to handle different URL patterns, but good luck figuring out which one actually matches.

I learned this the hard way last Tuesday when CSS updates deployed everywhere except three random edge locations in Germany. Spent 6 hours pulling my hair out before realizing we had cache behavior priority conflicts. Rule #2 was overriding rule #1 because reasons. The CloudFront troubleshooting docs are actually decent, unlike most AWS documentation.

Cache invalidations are 'instant' according to AWS marketing, but I've timed them at 15-20 minutes regularly. AWS docs claim 2 minutes maximum - that's complete horseshit. I've literally watched paint dry faster. Use versioned URLs instead - it's faster and actually works.

AWS Integration: The Lock-In

The only reason to choose CloudFront over Cloudflare or Fastly is if you're already deep in the AWS ecosystem. Data transfer from S3 or EC2 to CloudFront is free, which is nice because AWS charges for everything else.

CloudFront works well with S3 for static sites and ALB for dynamic content. The ACM integration for SSL certificates is actually smooth, and Shield Standard DDoS protection is included.

Here's where AWS gets you by the balls - once you're using CloudFront, you're trapped in their pricing nightmare. Scaling globally means your AWS bill starts looking like a small country's GDP. Asian traffic costs 3x more than US traffic - $0.140/GB vs $0.085/GB. Nobody mentions this gotcha until you get a $5000 bill for serving videos to users in Tokyo.

Performance Reality Check

CloudFront performance varies wildly by location. US East Coast? Lightning fast. Southeast Asia? Prepare for disappointment. The AWS global infrastructure page shows all their edge locations, but doesn't mention that some are significantly better than others.

We eventually said fuck it and switched to Cloudflare after getting daily complaints from our Singapore users about 8-second page loads. Our Bangkok users were threatening to cancel subscriptions. Cloudflare's edge network just performed better in those regions. CloudFront is fine if your users are mostly in North America and Europe.

The Bottom Line

CloudFront works fine if you're already paying AWS for hosting and don't want to deal with another vendor. It's not the fastest CDN, not the cheapest, and definitely not the most user-friendly. But it integrates well with other AWS services and won't randomly break your site.

Before committing: test your specific use case from multiple global locations, budget for Asian traffic costs, and plan your cache strategy around versioned URLs instead of invalidations. If you need global performance that doesn't suck everywhere, honestly consider Cloudflare first.

Edge Functions: Two Ways to Overcomplicate Things

CloudFront gives you two serverless options that both suck in different ways.

CloudFront Functions run at every edge location. They're fast (under 1ms) and cheap (\$0.10 per million requests), but limited to basic JavaScript. Good for URL rewrites and header manipulation. The 1MB code limit means no fancy libraries - just vanilla JS and your own suffering.

Lambda@Edge runs at regional locations, supports Node.js and Python, and can run for 30 seconds. Sounds perfect, right? Wrong. I wasted three days debugging why our auth flow was randomly shitting the bed with 8-second delays. Turns out cold starts were murdering our login UX - users thought the site was broken. Use CloudFront Functions unless you absolutely need the extra power.

Security That Actually Matters

Shield Standard comes free and stops basic DDoS attacks. It's actually decent - stopped a 50Gbps attack on our site without breaking a sweat. Shield Advanced costs $3,000/month and includes cost protection, but only makes sense if you're getting hit regularly.

Geographic blocking works, but it's country-level only. Want to block just one city? Too bad. Signed URLs are useful for paid content, but the signature generation is finicky. Read the docs carefully or you'll spend hours debugging "AccessDenied" errors.

Origin Shield: Expensive But Sometimes Worth It

Origin Shield costs \$0.0075 per 10,000 requests but can save your origin from getting hammered. If your origin does expensive database queries or image processing, Origin Shield collapses requests from multiple edge locations into one.

Enabled Origin Shield after our image resizing API kept getting absolutely hammered and crashing every Tuesday morning. Went from 100 simultaneous resize requests (which killed our poor server) down to 1 clean request. Server stopped having weekly nervous breakdowns. Worth the extra cost for compute-heavy origins.

Monitoring That Doesn't Suck

CloudFront's CloudWatch integration is surprisingly good. Real-time metrics show request rates, error rates, and cache hit ratios within seconds. Set up alarms for error rate spikes - they'll save you when cache behaviors go wrong.

Key metrics to monitor: CacheMissRate (should be under 15% for most sites), 4xxErrorRate and 5xxErrorRate (both should be under 1%), and OriginLatency (spikes indicate backend issues).

Real-time logs to Kinesis cost \$0.01 per million log lines but are invaluable for debugging. We pipe these logs to catch bot traffic trying to scrape our API and identify when our CDN configs are completely fucked. Saved us from a $3000 overage bill last month when bots were hammering unused endpoints. Sample at 1% to avoid log costs eating your budget.

Standard access logs to S3 are free (you pay S3 storage) and perfect for analytics. Format is documented but weird - use a log parser like GoAccess or write your own.

DevOps Integration: Terraform or Die

The CloudFormation templates are garbage. Use Terraform's CloudFront provider instead - it's actually maintained and doesn't randomly break.

Config changes take forever - anywhere from 5 to 20 minutes to propagate globally. I once waited 25 minutes for a simple cache rule change. Plan your deployments around this shit or you'll be debugging phantom issues. Hard lesson learned: always deploy CloudFront changes first, then wait at least 15 minutes before touching application code. Made this mistake once and spent 2 hours figuring out why half our users were seeing the old site.

The AWS CLI works well for automation:

## Create invalidation
aws cloudfront create-invalidation --distribution-id ABCDEF123 --paths \"/*\"

## Check deployment status  
aws cloudfront get-distribution --id ABCDEF123 --query 'Distribution.Status'

Pro tip: Use wait commands in your CI/CD to wait for deployments to complete before running tests.