CloudFront Posts

For two years, the answer to "can I put my WebSocket backend in a private subnet behind CloudFront?" was a flat no. You could shield a REST API, a static site, or a server-rendered app behind CloudFront VPC origins and keep the load balancer entirely off the public internet. But the moment a client tried to upgrade an HTTP connection to a WebSocket, the handshake failed. People discovered this the hard way: a clean wss:// request would come back as a 502, and AWS Support would confirm the limitation in writing. The workaround was always the same retreat: make the load balancer public again, bolt on a WAF, and accept the larger attack surface as the cost of doing real-time business.

Five ways to expose a Lambda function over HTTP. At least. AWS keeps adding more. Most teams pick API Gateway on day one and never revisit that decision. Fine. API Gateway handles a lot.

I recently published a deep-dive into CloudFront's architecture covering its internals, origin architecture, cache behavior, security, and edge compute capabilities. The most common follow-up question: should we use CloudFront or Cloudflare?

Amazon CloudFront is one of the most underestimated services in the AWS portfolio. Most teams think of it as a caching layer you put in front of your S3 bucket or Application Load Balancer to speed up static asset delivery. That understanding was roughly correct in 2015. It is incomplete today. CloudFront has evolved into a globally distributed edge compute and security platform that handles request routing, WAF enforcement, DDoS mitigation, authentication, A/B testing, header manipulation, and serverless compute, all before a request ever reaches your origin. This article covers the architectural patterns and operational lessons I have accumulated from architecting systems that serve traffic through CloudFront across dozens of AWS accounts.