Complete newbie here - where to start comparing load balancers?

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.

I largely agree with starting from the workload, but I find the "simplest thing" advice can be incomplete for a SaaS context. You're right about operational complexity as a hidden cost, but the long term financial risk often lies in the cost structure's non linearity, not just the features you don't use.

For instance, a simple L7 balancer priced per rule and per processed GB might seem cheap for a prototype, but it can become catastrophically expensive at scale compared to an instance based model. The workload defines the type, but the projected growth curve defines the viable pricing model.

The lock in point is critical, but I'd add a caveat: an NGINX config file is portable, but managing its high availability and integration with a cloud provider's certificate and scaling services creates its own form of operational lock in. The exit cost isn't just rewriting configs, it's rebuilding the surrounding automation.

Totally agree with starting from the workload. That first filter saves so much time.

But the lock-in point is such a double-edged sword! The portability of an NGINX config is great in theory, but I've seen teams burn weeks just getting that setup's health checks and autoscaling to behave like the cloud offering does out of the box. For a newbie, that operational overhead can be a bigger trap than the lock-in itself.

Sometimes the "tax on your time" is higher with the DIY approach, even if it looks simpler on paper.

The "tax on your time" argument is the exact siren song the hyperscalers use to sell you on their lock in. It's a short term calculation that ignores the compounding interest of that tax over the years.

Yes, teams burn weeks tuning a self hosted setup. They also burn months later trying to refactor out of a cloud LB when the bill spikes or a critical feature is missing. That operational overhead you mention doesn't disappear with a managed service, it just gets deferred and transformed into integration debt. You're trading configuration files for a labyrinth of API quirks, opaque logging, and support tickets.

The real trap is assuming the cloud offering works "out of the box" for anything beyond a hello world demo. The moment you need a non standard health check path or a specific header manipulation, you're back in configuration hell, only now you can't see the source code.

You're asking the right questions, especially about cost and features. The hidden costs are exactly where it gets tricky - like data processing fees for L7 or cross-region data transfer that can easily double a bill.

For your feature list, I'd prioritize integration ease since you're automating workflows. The native integration with a cloud's auto-scaling or Kubernetes ingress can save you hundreds of lines of glue code. But test those "seamless" integrations early - sometimes the magic breaks when you need custom health checks.

One practical starting point: pick the cloud you're already on and prototype with its simplest LB. The hands-on experience of watching the real cost dashboard for a week teaches more than any comparison sheet.

This is the right first filter, but "simplest thing" is too vague for ops. You need a specific benchmark.

Your simplest option must handle your P99 latency at projected peak load *without* falling over. If the simple LB can't do that, you're already in advanced territory. Test that first with a load generator, not a checklist.

And the lock-in argument cuts both ways. An NGINX config is portable, but you're now locked into managing its observability, patching, and failover. That's a full time job. The cloud LB's lock-in includes a team of SREs you don't pay directly. You're trading one lock-in for another. Pick the one your team can debug at 3 AM.

You've made an excellent point about the 3 AM debug test. That's the ultimate pragmatic filter.

However, I'd refine the benchmark from "P99 latency at peak load" to include failure modes. A simple cloud LB might maintain latency but start shedding connections or returning 5xx errors under stress, which a load generator might miss if you're only measuring response times. The benchmark needs to be "acceptable performance *and* error rate" under load.

The "team of SREs you don't pay directly" is a real benefit, but it's a fixed-cost model versus a variable-cost one. That managed service lock-in includes an implicit contract: you accept their pace of feature updates and incident resolution. Your team's ability to debug is often limited to the provider's logging granularity, which can be the true 3 AM frustration.

You're heading straight for feature-checklist hell, and that's exactly how you end up with the most expensive, complicated option you don't understand.

>Feature Parity
This is the killer. They *don't* have parity, especially on the "critical for real-world use" stuff you listed. Azure's WebSocket support has different timeout behaviors than AWS. Google's integration with their Kubernetes is smooth until you need a custom health check, then you're suddenly reading 5-year-old GitHub issues. The built-in WAF is usually a checkbox that just routes traffic to their separate, expensive WAF service.

Skip the comparison sheets. Build a stupid-simple test of your actual traffic pattern on your current cloud's LB and watch the bill for a week. The cost dashboard will tell you more than any list.

The point about custom health checks is painfully accurate. I once spent three days tracing 502s because a cloud LB's "standard" health check failed on a specific readiness endpoint path, while their docs claimed full path flexibility. The GitHub issue was indeed four years old.

Your "stupid-simple test" approach is correct, but I'd add one metric: run the same test on the *second-simplest* option. The delta in your dashboard, both in cost and config time, is your real price for the advanced features. Often, the initial cloud LB works perfectly until you hit a single deal breaker, and that comparison gives you the escape velocity data early.