Networking 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.

I have built real-time features into more systems than I can count: chat, live dashboards, IoT telemetry pipelines, collaborative editors, trading feeds, notification systems. Every one of them started with the same question: which protocol? The answer has never been the same twice, and the wrong choice has cost me weeks of rework more than once. WebSockets get all the attention. SSE gets overlooked. gRPC streaming gets misunderstood. Long polling gets dismissed too quickly. MQTT gets ignored entirely outside IoT circles. Each of these protocols solves a different problem, and the differences become painfully obvious only after you have built, deployed, and tried to scale the wrong one.

NAT Gateway costs are the silent budget killer in multi-account AWS environments. I've audited organizations spending $15,000/month on NAT Gateway data processing alone, spread across dozens of VPCs, each with its own pair of NAT Gateways. When I showed them they could cut that by 40-70% with a centralized egress VPC and Transit Gateway, the conversation shifted fast. The architecture is straightforward. The cost math requires attention. The routing setup has genuine gotchas that will break production if you get them wrong.

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.

I've yet to ship a production architecture on AWS that doesn't involve Elastic Load Balancing somewhere. Most teams slap a load balancer in front of their service and move on. Fair enough. That works until it doesn't. After debugging enough 502 cascades at 2 AM, I can tell you: the differences between the four ELB types, and what happens when you pick wrong, deserve way more attention than they typically get. So here it is. Patterns, trade-offs, and operational scars from years of running load-balanced architectures at scale.

Three years of locking down SageMaker environments across regulated industries taught me one thing early: your networking decisions on day one determine whether the ML infrastructure passes an audit six months later. Teams treat SageMaker networking as an afterthought. Notebook instances get default settings. Models train with full internet access. Then the security review arrives and everybody scrambles. Give the networking layer the same rigor you'd give any production VPC workload.