What happens when your load balancer quietly becomes the most important architectural decision in your stack? Most teams pick one early, wire it up, and never revisit it. Then a compliance audit asks where TLS terminates, a partner demands a static IP for allow-listing, or a gRPC service starts dropping connections under load, and suddenly the choice matters more than the framework you argued about for three sprints.
This piece walks through the real differences between AWS Application Load Balancer (ALB), AWS Network Load Balancer (NLB), and Cloudflare Load Balancing), with an eye on what teams will be deciding in 2027. No vendor cheerleading. Just the tradeoffs that bite in production.
The Layer 7 vs Layer 4 split is the whole ballgame
Before anything else, understand that ALB and NLB live at different layers of the network stack. ALB operates at Layer 7, meaning it reads HTTP, HTTPS, gRPC, and WebSocket traffic. It understands hosts, paths, headers, and cookies. NLB operates at Layer 4, handling raw TCP, UDP, and TLS streams without caring what’s inside them.
That single distinction cascades into almost every other difference. Because ALB parses HTTP, it can route `/api/` to one target group and `/images/` to another. Because NLB doesn’t parse anything, it can push millions of packets per second with minimal latency overhead and preserve the original client IP address all the way to your backend.
If you want the deeper mechanics of how these systems actually distribute traffic, there’s a solid breakdown of how cloud load balancing architecture routes traffic to the right server that’s worth reading before you commit to a design. (What is Elastic Load Balancing?)
A side-by-side comparison
Here’s the practical matrix most teams wish they’d seen before their first migration.
| Capability | AWS ALB | AWS NLB | Cloudflare Load Balancing |
|---|---|---|---|
| OSI layer | Layer 7 | Layer 4 | Layer 7 (plus TCP) |
| Protocol awareness | HTTP, HTTPS, gRPC, WebSocket | TCP, UDP, TLS | HTTP, HTTPS, TCP |
| Static IPs | No (native) | Yes, per Availability Zone | Anycast IPs |
| Client source IP preserved | No (via headers) | Yes | Via headers |
| Path and host routing | Yes | No | Yes |
| WAF integration | Native AWS WAF | Requires ALB in front | Cloudflare WAF |
| Scope | Regional | Regional | Global |
| TLS termination | Yes, with ACM | Pass-through or terminate | At the edge |
| Cross-cloud origins | No | No | Yes |
Read that table twice. The rows that surprise people are almost always static IPs, source IP preservation, and scope.
Why NLB still wins on raw network behavior
NLB’s headline feature isn’t speed, it’s predictability. It hands out static IP addresses per Availability Zone, and it preserves the client’s source IP as traffic reaches your targets. That matters enormously for three groups:
- Partners and B2B integrations that require you to publish a fixed IP range for their firewall allow-lists.
- Compliance regimes that demand deterministic network paths.
- UDP workloads like game servers, DNS, or real-time media, which ALB simply cannot handle.
The tradeoff is that NLB gives you almost nothing else. No path routing. No native WAF. No redirects or fixed responses. If you want HTTP intelligence on top of NLB, you chain an ALB behind it, which adds a hop, adds latency, and adds a configuration surface that someone will eventually misconfigure.
A common mistake: teams put NLB in front of everything “for performance” and then bolt on an ALB anyway for routing. At that point you’re paying for two load balancers and debugging health checks across both. Only reach for NLB-first when you genuinely need static IPs, source IP preservation, or non-HTTP protocols.
Where ALB earns its keep
ALB is the default for a reason. It handles host-based and path-based routing, supports redirects and fixed responses, integrates natively with AWS WAF, Cognito, and OIDC, and speaks gRPC and HTTP/2 end to end. For a microservices architecture built around gRPC, ALB is close to a no-brainer.
The catch is that ALB terminates TLS at the load balancer using ACM certificates. That’s convenient, but it means your traffic is decrypted at the ALB and re-encrypted (or not) to the backend. If you have end-to-end encryption requirements or mTLS between services, you need to think carefully about where that handshake happens.
Another catch: ALB has no native static IPs. AWS’s answer is Global Accelerator, which provides anycast IPs and cross-region failover in front of your ALB or NLB. That’s a real architectural component, not a checkbox, and it changes your DNS strategy.
Cloudflare’s global angle
Cloudflare Load Balancing isn’t a regional load balancer in the AWS sense. It sits on an anycast network: traffic enters at the nearest point of presence and is steered globally from there. That reframes the problem: you choose which origin gets a request and which continent it enters through.
For teams running multi-cloud or hybrid estates, this is the killer feature. Cloudflare can health-check and fail over across AWS, GCP, Azure, and on-premises origins in a single pool configuration. AWS ELBs, by contrast, are tightly bound to a single VPC and region.
The cost is control granularity. Cloudflare terminates TLS at its edge, which means your certificate lives with Cloudflare (or you use custom certificates). Some regulated industries will find that acceptable; others won’t. And Cloudflare’s feature set evolves quickly, so any capability claim should be verified against current documentation rather than a blog post from two years ago.
If you’re weighing whether a global layer is worth the added complexity, this explanation of what cloud load balancing actually means and when to use it helps frame the decision in terms of traffic patterns rather than vendor features.
The 2027 decisions that will actually matter
No credible source makes 2027-specific predictions about load balancer architecture, so treat this section as analysis, not prophecy. That said, several forces are clearly converging.
gRPC and HTTP/2 everywhere. Service-to-service communication is moving toward gRPC, and ALB supports it natively while NLB does not do HTTP-aware routing at all. If your 2027 roadmap includes gRPC microservices, your L7 layer needs to understand it.
TLS termination as a compliance question. Where the handshake happens is increasingly an audit item and a performance choice. ALB terminates with ACM, NLB can pass through or terminate, and Cloudflare terminates at the edge. Document your decision now, because changing it later is painful.
Multi-cloud as a resilience requirement. Cloudflare’s cross-cloud origins are a genuine differentiator here. AWS Global Accelerator gives you cross-region failover, but not cross-provider.
Health check topology. AWS target-group health checks are regional and configurable per group. Cloudflare health checks can probe from multiple regions globally. The difference shows up during partial outages, when a regional check might miss a problem that a global check catches.
For a structured look at how these pieces fit together in practice, the cloud load balancing implementation guide covers the sequencing questions most teams hit mid-project.
Common mistakes that break production
A few patterns show up over and over in postmortems.
Assuming ALB preserves source IP. It doesn’t. You get `X-Forwarded-For` headers, and if your application logic reads the socket address instead of the header, every request looks like it came from the load balancer. Rate limiting and geo-blocking silently break.
Forgetting that NLB health checks are protocol-level. A TCP health check passes as long as the port accepts connections, even if the application behind it is returning 500s. Pair NLB with application-level checks or you’ll route traffic to a dead service.
Chaining NLB and ALB without a latency budget. The double-hop is real. Measure it before you commit.
Treating Cloudflare as a drop-in replacement for an ELB. It isn’t. Cloudflare steers traffic globally to origins; it doesn’t replace the regional load balancing inside your VPC. Most mature architectures use both.
Ignoring idle timeout mismatches. ALB has a configurable idle timeout, and if your backend keeps connections open longer than the client expects, you get sporadic 502s that are maddening to debug.
If you want a catalog of these failure modes, there’s a useful rundown of common cloud load balancing problems that break production worth bookmarking.
How to actually choose
A simple decision sequence works for most teams:
- List your protocols. Any UDP or raw TCP? You need NLB or Cloudflare TCP. Pure HTTP/gRPC? ALB or Cloudflare.
- Check your IP requirements. Partners or firewalls demanding static IPs? NLB, or Global Accelerator in front of ALB.
- Map your TLS policy. Where must the handshake terminate? That answer eliminates options fast.
- Decide your scope. Single region? Regional ELB is fine. Multi-cloud or global user base? Cloudflare’s anycast entry earns its place.
- Measure before you chain. If you’re stacking NLB plus ALB, benchmark the added latency against your SLA.
A practical walkthrough of the setup mechanics lives in this cloud load balancing tutorial with a hands-on setup, which is useful once the architecture is settled.
Conclusion
The ALB versus NLB versus Cloudflare question isn’t really a contest. It’s a question of which constraints bind hardest: protocol support, IP determinism, TLS termination location, or global reach. ALB gives you HTTP intelligence and deep AWS integration. NLB gives you raw network predictability and static IPs. Cloudflare gives you a global entry point that spans clouds.
In 2027, most serious architectures will use at least two of the three. The teams that struggle are the ones that pick one load balancer and expect it to do everything. The teams that sleep well have drawn a clear line around what each layer is responsible for, documented where TLS terminates, and tested their failover before they needed it.
FAQ
What is the main difference between AWS ALB and NLB?
ALB works at Layer 7 and understands HTTP, HTTPS, gRPC, and WebSocket traffic, so it can route by host, path, and header. NLB works at Layer 4 and handles raw TCP, UDP, and TLS without inspecting content. That means NLB can preserve client source IPs and offer static IPs, while ALB offers rich routing and native WAF integration.
Does ALB support static IP addresses?
Not natively. ALB exposes DNS names that resolve to changing IPs. If you need static IPs in front of an ALB, the standard approach is AWS Global Accelerator, which provides anycast IP addresses and cross-region failover. NLB, by contrast, offers static IPs per Availability Zone out of the box.
When should I choose Cloudflare Load Balancing over an AWS load balancer?
Choose Cloudflare when you need a single global entry point across multiple clouds or on-premises origins, when you want anycast routing to the nearest point of presence, or when you need global health checks that probe from multiple regions. If your entire estate lives in one AWS region and you need VPC-internal routing, an AWS load balancer is usually simpler.
Can I use NLB and ALB together?
Yes, and many teams do. The common pattern places NLB in front to get static IPs and source IP preservation, then forwards to an ALB for HTTP routing and WAF. The cost is an extra network hop and a larger configuration surface, so benchmark the added latency before committing.
Where does TLS termination happen with each option?
ALB terminates TLS at the load balancer using ACM certificates. NLB can either pass TLS through untouched or terminate it. Cloudflare terminates TLS at its edge, using either Cloudflare-issued or custom certificates. That difference matters for compliance, mTLS requirements, and end-to-end encryption policies.
Does Cloudflare Load Balancing replace an AWS load balancer?
Generally no. Cloudflare steers traffic globally to your origins, but it doesn’t provide the regional, VPC-internal load balancing that distributes requests across instances inside a subnet. Most mature architectures use Cloudflare at the edge and an AWS load balancer inside the network, each handling a distinct job.
