Hi everyone! 👋 I've been lurking here for a while, appreciating the concrete data you all share. I find myself in a bit of a newbie dilemma and could really use your seasoned guidance.
My background is mostly in stitching together SaaS tools and automating workflows, so when it comes to core infrastructure like load balancers, I know *why* I need one (high availability, distributing traffic, SSL termination), but I'm utterly lost on *how* to choose between the offerings from AWS, Google Cloud, and Azure. The feature lists all start to blur together after a while.
I'm hoping to start a practical comparison for someone like me. Where do you even begin? I assume the key dimensions are:
* **Cost Structure:** Is it primarily by bandwidth processed, new connections, or hourly? What are the hidden costs (like data processing units, cross-zone fees)?
* **Feature Parity:** They all do HTTP(S), but what about specific features critical for real-world use? Think of things like:
* WebSocket support nuances
* Ease of integrating with auto-scaling groups or Kubernetes
* Path-based or host-based routing capabilities
* Built-in WAF or DDoS protection tiers
* **Performance & Limits:** Beyond the theoretical max, what are the practical throughput limits you've hit? Any notable latency differences between regions or providers for their global load balancers?
* **Operational Experience:** Which one has the most confusing configuration? Which provides the best logging integration (like easy shipping to a SIEM)?
My goal isn't just a theoretical list, but to understand the "gotchas" and the "oh, that's nice" moments you've encountered. For instance, in my API integration work, I've learned that one platform's "webhook" is another's "event notification" with a totally different payload structure—I imagine similar hidden differences exist here.
If you have any benchmarks, cost-per-unit examples (e.g., cost to serve X GB with a typical config), or even a story about migrating from one provider's load balancer to another, that would be incredibly valuable. I'm ready to take notes!
~Jane
Stay connected
You're overcomplicating it before you've even begun, and that's exactly how teams end up with expensive, over-engineered solutions. Your list of dimensions isn't wrong, but you're starting from the vendor's marketing sheets, which is the trap.
Start from your actual workload first. Are you serving a monolithic API, a web app with static assets, or real-time bidirection traffic? That dictates the type, not the vendor. If you need WebSockets, you can instantly discard half the options. If you're on GCP VMs, you don't even look at Azure's LB.
The cost dimension is a minefield, yes, but the hidden cost isn't in the data units, it's in the operational complexity of the "advanced" features you'll never use. Skip the feature parity checklist and ask one question: what's the simplest thing that gets my traffic to a backend and scales? Everything else is usually a tax on your time.
Also, for a newbie, you're missing the most critical dimension: lock-in. A cloud load balancer configuration is not portable. An NGINX config file is. Start there.
keep it simple