AWS ALB vs NLB vs Cloudflare LB: $16 vs $5 Gap [2026]

Pick the wrong load balancer and you find out during an incident, not during planning. A team running HTTP microservices on Elastic Kubernetes Service does not need the same traffic cop as a fintech company pushing raw TCP order-book data, and neither of them needs what a globally distributed SaaS company needs when a whole AWS region goes dark. As of September 12, 2026, three tools dominate that decision for most engineering teams: AWS Application Load Balancer (ALB), AWS Network Load Balancer (NLB), and Cloudflare Load Balancing. They solve overlapping but distinct problems, they bill in completely different ways, and mixing them up costs real money and real downtime.

This comparison breaks down pricing to the cent, throughput characteristics, health-check behavior, DDoS posture, and Kubernetes integration for all three, using current 2026 rate cards verified against AWS’s Elastic Load Balancing pricing page and Cloudflare’s published plans. By the end you will know which one fits your architecture, what it costs at real traffic volumes, and how to migrate between them without an outage.

What AWS ALB, NLB, and Cloudflare Load Balancing actually are

Application Load Balancer operates at Layer 7 of the OSI model. It reads HTTP and HTTPS traffic, inspects headers, paths, and hostnames, and routes requests to different target groups based on that content. That makes ALB the natural front door for microservices, container platforms, and any application where routing decisions depend on what is inside the request, not just where it is headed. ALB terminates TLS at the load balancer, which means it can decrypt, inspect, and re-route based on the actual HTTP payload before re-encrypting (or not) to the backend.

Network Load Balancer works one layer down, at Layer 4. It moves TCP and UDP packets with minimal processing, which is why it handles far higher connection volumes at lower and more predictable latency than ALB. NLB does not read HTTP headers by default; it is largely a pass-through device, though it can be configured with TLS listeners for encrypted TCP termination when needed. Trading platforms, gaming backends, IoT ingestion pipelines, and anything sensitive to jitter tend to land on NLB rather than ALB.

Cloudflare Load Balancing is a different animal entirely. Rather than living inside a single AWS region, it operates from Cloudflare’s global edge network, routing traffic to origin servers based on geography, latency, or health status before a request ever reaches your infrastructure. It combines DNS-level steering with HTTP-level routing and bundles in Cloudflare’s network-level DDoS mitigation as part of the same product. Where ALB and NLB are regional building blocks assembled into a global system using Route 53, Cloudflare Load Balancing is sold as the global layer itself.

Full specs comparison: ALB vs NLB vs Cloudflare Load Balancing

The table below lines up the core technical and commercial differences as of September 2026, based on AWS’s Elastic Load Balancing pricing page and Cloudflare’s plans documentation.

Attribute	AWS Application Load Balancer	AWS Network Load Balancer	Cloudflare Load Balancing
OSI layer	Layer 7 (HTTP/HTTPS)	Layer 4 (TCP/UDP)	DNS + application-layer edge routing
Scope	Regional (per AWS region)	Regional (per AWS region)	Global (Cloudflare edge network)
Base hourly price (us-east-1)	$0.0225/hour (~$16.40/month)	$0.0225/hour (~$16.40/month)	N/A (flat monthly add-on)
Usage-based unit	$0.008 per LCU-hour	$0.006 per NLCU-hour	$0.50 per 500K DNS queries beyond free tier
Flat monthly starting price	N/A	N/A	$5/month for 2 origins + 5 health checks
TLS termination	Yes, native at the LB with SNI support	Optional, via TLS listener for encrypted TCP	Yes, at the edge via Cloudflare’s proxy
Health checks	HTTP/HTTPS, per target group	TCP, HTTP, or HTTPS, per target group	DNS-level and HTTP(S)-level, multi-region vantage points
Geo-routing / GSLB	No (needs Route 53 in front)	No (needs Route 53 in front)	Native, built into the product
Static IP support	No (DNS name only)	Yes, one static IP per AZ	Anycast IPs, not a per-account static IP
DDoS protection	Relies on separate AWS Shield/WAF	Relies on separate AWS Shield/WAF	Bundled network-level mitigation included
Kubernetes integration	AWS Load Balancer Controller (Ingress)	AWS Load Balancer Controller (Service type LoadBalancer)	Gateway API / external-dns integrations
Best routing granularity	Path, host, header, query string	Connection-level, flow hash	Geographic, latency, weighted, failover pools
Free tier	750 hours/month for 12 months (new accounts)	750 hours/month for 12 months (new accounts)	500,000 DNS queries/month, shared per account

Two things jump out immediately. First, ALB and NLB share the identical $0.0225 hourly base rate, so the meaningful cost difference between them comes entirely from the LCU versus NLCU usage rate, $0.008 versus $0.006. Second, Cloudflare’s pricing model is structurally different: rather than metering every connection and byte the way AWS does, it charges a flat per-origin subscription fee plus metered DNS queries, which makes cost far more predictable but potentially more expensive at very low traffic volumes and cheaper at very high ones.

Pricing breakdown: what each load balancer actually costs

Load balancer pricing pages are notoriously hard to translate into a real monthly bill, so here is what each option costs at a few realistic traffic tiers, based on the current AWS Elastic Load Balancing rate card and Cloudflare’s published add-on pricing.

Scenario	AWS ALB	AWS NLB	Cloudflare Load Balancing
Small app, low steady traffic	~$16.40/month base + minimal LCU usage	~$16.40/month base + minimal NLCU usage	$5/month (2 origins, under 500K queries)
Mid-size app, moderate traffic (single origin pair)	$16.40 base + ~$0.32/hour at 40 LCU-hours, roughly $250-300/month	$16.40 base + ~$0.24/hour at 40 NLCU-hours, roughly $190-230/month	$5-10/month plus DNS query overage
Multi-region app, 8 origins across 2 pools	Multiple regional ALBs, each billed separately, plus Route 53	Multiple regional NLBs, each billed separately, plus Route 53	$35/month (8 origins at $5 each) plus query overage
Data transfer / bandwidth	Standard AWS data transfer rates apply on top	Standard AWS data transfer rates apply on top	Included in Cloudflare’s proxy bandwidth (plan-dependent)

The Load Balancer Capacity Unit model matters more than most teams realize when they first provision an ALB. One LCU covers up to 25 new connections per second, 3,000 active connections, 1 GB of processed bytes per hour, and 1,000 rule evaluations per second, with the first 10 rules evaluated for free. AWS bills for whichever of those four dimensions is highest in a given hour, not the sum, so a connection-heavy but low-bandwidth workload (long-lived WebSocket connections, for instance) can burn through LCUs differently than a bandwidth-heavy one (large file downloads) even at the same request count. NLB’s NLCU model works the same way at $0.006 per unit instead of $0.008, which is why NLB usually runs 15 to 25 percent cheaper than ALB for equivalent connection volumes, on top of NLB’s inherently lower per-connection overhead.

Cloudflare’s model flips the logic entirely. Instead of metering connections and bytes, it charges $5 per month for the first two origins and five DNS-level health checks, then $5 per month for each additional origin, so a deployment spanning eight origins across two pools runs $35 a month regardless of how much traffic actually flows through them. The first 500,000 DNS queries per month, shared across every load balancer in the account, come free; beyond that, Cloudflare charges $0.50 per additional 500,000 queries. For teams running dozens of low-traffic regional origins that need global failover more than raw throughput, that flat structure is dramatically cheaper and more predictable than paying AWS’s per-region, per-hour, per-capacity-unit stack multiplied across every region.

Performance and throughput: where each load balancer excels

Neither AWS nor Cloudflare publishes hard, apples-to-apples numbers for requests-per-second or millisecond-level connection latency across these three products, so treat any specific “X million req/s” claim you see elsewhere with skepticism unless it links to a reproducible benchmark. What is well documented, and consistent across AWS’s own architecture guidance, is the structural performance profile of each option.

NLB is built for extreme connection volume and minimal latency variance because it does not parse application-layer content. It preserves the source IP address by default, supports one static IP per Availability Zone (plus Elastic IP support), and is designed to handle very high request rates with latency in the low single-digit milliseconds under normal load, since it is doing packet forwarding rather than content inspection. That architecture is why financial trading systems, real-time multiplayer game backends, and MQTT/IoT brokers default to NLB rather than ALB.

ALB trades some of that raw throughput for routing intelligence. Because it terminates TLS and parses HTTP headers, paths, and query strings before making a routing decision, it carries more per-request overhead than NLB, but that overhead buys path-based routing, host-based routing, weighted target groups for canary deployments, and native integration with AWS WAF for request-level filtering. For the overwhelming majority of REST APIs, web applications, and containerized microservices, that trade-off is the right one, and the added latency is negligible relative to backend processing time.

Cloudflare Load Balancing’s performance story is about geography rather than raw packet-forwarding speed. Because it steers traffic from its edge network before a request ever reaches AWS, Azure, GCP, or an on-premises data center, it can route a user in Singapore to a Singapore-region origin and a user in Frankfurt to a Frankfurt-region origin automatically, cutting the network hop that would otherwise happen if every user hit a single regional ALB or NLB first. For single-region deployments, that global steering is irrelevant; for anything running active-active across two or more regions, it typically produces the single largest latency win of the three options.

Health checks and failover behavior

ALB runs HTTP or HTTPS health checks against each target group, with configurable paths, ports, response-code thresholds, and interval timing, and automatically pulls unhealthy targets out of rotation and re-adds them once they pass checks again. NLB supports TCP, HTTP, or HTTPS health checks at the target-group level, tuned for the same high-throughput, low-overhead philosophy as the rest of the product. Both operate within the blast radius of a single AWS region: if that region has a control-plane issue, health checks and the load balancer go down together.

Cloudflare’s health checks run from multiple global vantage points simultaneously, at both the DNS level and the HTTP(S) level, which means a Cloudflare Load Balancer can detect and route around a regional AWS outage that would otherwise take an ALB or NLB, and everything behind it, offline. That cross-provider, cross-region failover is the single biggest reason teams add Cloudflare Load Balancing in front of AWS load balancers rather than choosing one over the other.

DDoS protection: bundled versus bolt-on

This is one of the sharpest differences between the AWS options and Cloudflare. ALB and NLB are metered load balancers with no DDoS mitigation built into the product itself; protection against volumetric or application-layer attacks comes from separately provisioned AWS Shield (Standard is free and automatic, Advanced is a paid add-on) and AWS WAF rules attached to the ALB. That means a large-scale attack shows up as connections and bandwidth against LCUs or NLCUs and the data-transfer bill unless Shield Advanced and WAF rules are actively absorbing and filtering the traffic before it reaches the load balancer.

Cloudflare Load Balancing sits inside a platform that markets network-level DDoS mitigation as a first-class, always-on feature of being on Cloudflare’s network at all, independent of the Load Balancing add-on’s $5-per-origin fee. For teams that already route DNS and traffic through Cloudflare for other reasons, that mitigation effectively comes bundled in rather than billed as a separate, usage-metered service the way AWS Shield Advanced is. Teams comparing DDoS exposure across Cloudflare, AWS Shield, and Akamai in more depth will find the same pattern: Cloudflare treats mitigation as part of the platform, AWS treats it as a configurable add-on.

Kubernetes and container platform integration

All three integrate with containerized workloads, but the mechanics differ. ALB is the default target for the AWS Load Balancer Controller when creating a Kubernetes Ingress resource on EKS, letting a single ALB route to multiple services based on host or path rules, which keeps costs down versus provisioning one load balancer per service. NLB is the default target when creating a Kubernetes Service of type LoadBalancer, and is the standard choice when a service needs raw TCP/UDP exposure, a static IP, or extreme connection throughput that an Ingress-routed ALB is not built for.

Cloudflare’s Kubernetes story runs through the emerging Gateway API standard and tools like external-dns, positioning Cloudflare as the global entry point in front of one or more regional Kubernetes clusters rather than as the in-cluster load balancer itself. Teams standardizing on the Gateway API model for ingress control, rather than the older Ingress resource, will find that pattern increasingly common. Teams mid-migration on ingress tooling can see how ALB, NLB, and Gateway API-based controllers fit together in a single cluster in the deeper walkthrough on setting up a Kubernetes ingress controller after NGINX’s end of life.

Five real-world use cases and which load balancer fits

Abstract specs only get you so far. Here is how the decision plays out across five common architectures.

1. A REST API backing a mobile app, single AWS region. ALB is the default and correct choice. Path-based routing lets one load balancer front multiple microservices, native TLS termination simplifies certificate management, and integration with AWS WAF gives request-level filtering without adding another vendor. There is no global routing requirement to justify Cloudflare’s added layer, and NLB’s raw throughput is unnecessary at typical mobile-API request volumes.

2. A multiplayer game server backend. NLB is the near-universal choice here because game traffic is connection-heavy, latency-sensitive UDP or raw TCP, and static IPs matter for client-side connection pinning. Teams building this kind of infrastructure on AWS typically pair NLB with AWS Global Accelerator for cross-region routing rather than reaching for ALB’s HTTP-aware features, which add latency without adding value for this workload.

3. A multi-region SaaS platform with active-active failover. This is Cloudflare’s strongest case. Native geo-routing sends users to the nearest healthy origin, cross-region health checks detect a full AWS region outage that would otherwise take a purely AWS-based setup down with it, and flat per-origin pricing scales predictably as new regions come online. Most teams in this category still run ALB or NLB inside each region behind Cloudflare, using Cloudflare for the global layer and AWS for the regional layer rather than choosing one exclusively.

4. A financial services order-matching or market-data feed. NLB, without much debate. The combination of extremely high connection counts, sub-millisecond latency sensitivity, and the need to preserve source IP addresses for compliance and audit logging makes NLB’s Layer 4 pass-through model the only sensible option among the three; ALB’s content inspection adds unacceptable overhead and Cloudflare’s edge routing adds a network hop that latency-sensitive trading infrastructure cannot tolerate.

5. A content-heavy e-commerce site expecting seasonal traffic spikes and needing baked-in attack protection. Cloudflare Load Balancing paired with Cloudflare’s CDN and DDoS mitigation is the common pattern, since the same platform handling static asset caching also handles origin failover and volumetric attack absorption without a second vendor relationship. Teams that are AWS-only but still need WAF-level protection typically layer ALB with AWS WAF and Shield Advanced instead, accepting the extra configuration for the sake of staying inside one cloud provider’s billing and IAM boundary.

Pros and cons of each load balancer

AWS Application Load Balancer

Pros: native HTTP/HTTPS routing by path, host, and header; deep integration with AWS WAF, ACM certificates, and the AWS Load Balancer Controller for EKS; supports weighted target groups for canary and blue-green deployments; usage-based pricing scales down to near-zero for low-traffic apps.

Cons: regional only, requires Route 53 for any cross-region routing; higher per-connection overhead than NLB due to content inspection; DDoS mitigation is a separate, billed add-on rather than bundled; costs become harder to predict at scale because LCU billing depends on whichever usage dimension is highest in a given hour.

AWS Network Load Balancer

Pros: extremely high throughput and low, predictable latency; supports static IPs per Availability Zone; preserves source IP by default; NLCU rate is 25 percent cheaper per unit than ALB’s LCU rate; ideal for TCP/UDP workloads that do not need HTTP-aware routing.

Cons: no native content-based routing; regional only, same Route 53 dependency as ALB for global reach; TLS termination for content inspection is not its design center; like ALB, it depends on separately configured AWS Shield/WAF for DDoS protection.

Cloudflare Load Balancing

Pros: native global routing with geographic, latency, and failover-pool logic; flat, predictable per-origin pricing; DDoS mitigation is part of the platform rather than a separate purchase; can fail over across entirely different cloud providers or data centers, not just across AWS regions; setup is fast since it does not require Route 53 or a VPC redesign.

Cons: not a substitute for a regional load balancer; still typically needs ALB or NLB (or an equivalent) behind it inside each region; per-origin pricing can add up for architectures with many small backend pools; less granular Layer 4 control than NLB for raw TCP/UDP performance workloads.

Combining all three in one architecture: a practical pattern

Most engineering teams do not actually choose one of these three load balancers and stop there; the pattern that shows up repeatedly in production multi-region architectures layers them on top of each other, with each one doing the job it is best suited for. A typical setup looks like this: Cloudflare Load Balancing sits at the outermost layer, resolving DNS and steering each user to the nearest healthy region based on latency or geography. Inside each region, an ALB handles the HTTP-aware routing between microservices, terminating TLS and applying WAF rules before traffic ever reaches application code. Where a specific service inside that region needs raw TCP throughput, such as a WebSocket gateway or a gRPC backend, an NLB sits behind (or beside) the ALB to handle that traffic without the Layer 7 overhead.

The reason this layered approach works better than picking a single tool is that each layer fails independently. If Cloudflare’s edge has an issue, DNS-level failover to a backup provider (or a direct A record pointing at a regional ALB) keeps traffic flowing. If a single AWS region has an outage, Cloudflare’s cross-region health checks reroute new connections to a healthy region within seconds, well before most users notice. And if a specific service inside a healthy region degrades, the ALB’s per-target-group health checks pull just that service out of rotation without affecting the rest of the region. Teams that skip the outer Cloudflare layer and rely solely on Route 53 for cross-region failover typically see longer recovery times, since DNS TTL expiration and client-side DNS caching introduce delay that Cloudflare’s edge-level rerouting avoids.

The tradeoff is operational complexity. Three layers of load balancing means three sets of health checks to tune, three places where a misconfiguration can silently drop traffic, and three separate billing line items to track. Smaller teams running a single-region product should resist the urge to add Cloudflare Load Balancing just because larger companies use it; the added resilience only pays for itself once multi-region failover is an actual business requirement, not a hypothetical one.

Common misconceptions about cloud load balancers

A handful of assumptions cause more misconfigured infrastructure than almost anything else in this space. The first is believing NLB is simply a “faster ALB.” They are architecturally different tools built for different traffic types, and swapping an ALB for an NLB in front of an application that depends on path-based routing or header inspection will break routing entirely rather than just making it faster. The second misconception is assuming Cloudflare Load Balancing alone provides high availability without anything behind it; Cloudflare routes traffic to origins, but if those origins are a single EC2 instance with no regional load balancer or auto-scaling group in front of it, Cloudflare is just routing users efficiently to a single point of failure.

A third common mistake involves cost estimation: teams frequently budget for ALB or NLB using request count alone, when AWS actually bills on whichever of the four LCU or NLCU dimensions is highest in a given hour. A workload with modest request volume but many long-lived connections, such as a chat application or a streaming API, can rack up a far larger bill than a naive requests-per-month estimate would suggest. The fourth misconception is treating AWS Shield Standard as equivalent to Cloudflare’s bundled DDoS protection; Shield Standard covers common network and transport-layer attack patterns automatically, but the more sophisticated application-layer mitigation that Cloudflare markets as part of its base platform requires the paid Shield Advanced tier plus properly configured WAF rules on AWS, which is a meaningfully different cost and effort profile than “it’s already included.”

Migration guide: moving between load balancer types

Switching load balancer types mid-production is one of the more error-prone infrastructure changes a team can make, mostly because DNS propagation and connection draining timing determine whether users notice anything at all. Here is the sequence that keeps the change boring.

Audit current traffic patterns first. Pull CloudWatch metrics for existing ALB or NLB request counts, connection counts, and bandwidth over at least two full weeks, including any seasonal peak, before estimating cost or capacity on the target platform.
Stand up the new load balancer in parallel rather than replacing the existing one in place. Provision the new ALB, NLB, or Cloudflare Load Balancer pool alongside the current setup so both can run simultaneously during validation.
Register the same backend targets (EC2 instances, ECS tasks, EKS pods, or origin servers) with the new load balancer’s target groups or origin pools, matching health-check paths and thresholds to the existing configuration.
Validate health checks pass consistently on the new load balancer for at least 30 minutes before sending any real traffic, watching for false negatives caused by mismatched timeout or threshold settings.
Shift a small percentage of traffic first, using weighted Route 53 records or Cloudflare’s weighted load-balancing pools, rather than cutting over 100 percent at once.
Monitor error rates, latency percentiles, and connection counts on both the old and new load balancer side by side for at least one full business cycle, including any daily traffic peak.
Increase the traffic weight incrementally, typically in 10 to 25 percent increments, only after each step shows stable error rates and latency.
Update DNS TTLs in advance of the cutover so any final rollback, if needed, propagates quickly instead of taking hours.
Decommission the old load balancer only after a full traffic cycle has run entirely on the new one with no rollback triggered, and after confirming no lingering DNS caches are still resolving to the old endpoint.
Update infrastructure-as-code definitions, monitoring dashboards, and runbooks to reflect the new load balancer as the source of truth, removing references to the retired resource.

Teams moving from ALB to NLB (or vice versa) generally complete this process in under a day since both live inside the same AWS account and VPC. Adding Cloudflare Load Balancing in front of an existing AWS setup takes longer mainly because of DNS propagation timing and the need to validate Cloudflare’s health checks against origins that were previously only checked from within AWS itself.

Security and compliance considerations

ALB’s native integration with AWS WAF means request-level filtering, rate limiting, and managed rule groups (covering common patterns like SQL injection and known bad bot signatures) can be attached directly to the load balancer without any third-party tooling, which matters for organizations that need to keep their entire security stack inside one AWS account boundary for audit purposes. NLB, by contrast, does not inspect Layer 7 content at all, so any application-layer filtering has to happen either upstream (via an ALB or WAF layer in front of it) or downstream at the application itself; that is by design, not an oversight, since NLB’s entire value proposition depends on not parsing payloads.

Cloudflare’s model bundles TLS termination, bot management on higher plan tiers, and DDoS mitigation into the same platform that handles load balancing, which simplifies the security architecture for teams willing to route traffic through a third party before it reaches AWS, Azure, or on-prem infrastructure. Organizations in regulated industries should note that Cloudflare terminating TLS at its edge means Cloudflare, not just AWS, is inside the trust boundary for encrypted traffic, which is a meaningful compliance conversation for anyone handling healthcare or financial data under strict data-residency rules.

Cost optimization tips for each platform

For ALB, the biggest lever is understanding which of the four LCU dimensions a workload actually maxes out. A WebSocket-heavy app burning through the active-connections dimension will not benefit from bandwidth optimization, while a file-transfer-heavy app burning through the processed-bytes dimension needs compression and caching more than connection pooling. Consolidating multiple services behind a single ALB using path-based routing, rather than provisioning one ALB per service, also cuts the fixed $0.0225 hourly charge multiplied across every service.

For NLB, since it is already the cheaper per-unit option, the main savings come from right-sizing the number of Availability Zones enabled; each AZ with a registered target adds to the static IP and cross-zone load balancing footprint, and cross-zone data transfer charges can add up in accounts that are not tracking them. For Cloudflare, since pricing is per origin rather than per byte, consolidating backend pools and using fewer, larger origins instead of many small ones directly reduces the monthly bill; a setup running 20 tiny origins at $5 each costs far more than the same total capacity run behind 4 larger origins.

The verdict: which load balancer should you actually use

There is no single winner here because these three tools are not really competing for the same job. If a workload is an HTTP API or web application living in one AWS region and content-aware routing is needed, ALB at $0.0225/hour plus $0.008 per LCU-hour is the correct default, and reaching for anything else adds complexity without adding value. If a workload is connection-heavy, latency-sensitive TCP or UDP traffic where every millisecond and every dropped packet matters, NLB’s $0.006 per NLCU-hour rate and Layer 4 pass-through architecture is the only one of the three built for that job. And if a business genuinely operates across multiple regions or providers and an outage in any single one of them has to be invisible to users, Cloudflare Load Balancing’s flat $5-per-origin pricing and native global health checking earns its keep, almost always sitting in front of ALB or NLB rather than replacing them.

The most common mistake teams make is treating this as an either/or decision when the majority of mature, multi-region production architectures on AWS run all three simultaneously: NLB or ALB inside each region depending on the traffic shape, with Cloudflare Load Balancing as the global steering and failover layer on top. Budget accordingly, and pick each layer based on the actual traffic characteristics at that layer rather than defaulting to whatever load balancer the last engineer happened to reach for.

Frequently asked questions

Is AWS ALB or NLB cheaper?

Both share the same $0.0225 per hour base rate, but NLB’s usage-based charge is $0.006 per NLCU-hour versus ALB’s $0.008 per LCU-hour, making NLB roughly 25 percent cheaper per capacity unit for equivalent connection volumes. The bigger cost driver in practice is which of the four billing dimensions (new connections, active connections, bandwidth, or rule evaluations) a specific workload maxes out, since AWS bills on whichever is highest, not the sum.

Can Cloudflare Load Balancing replace an AWS load balancer entirely?

Not usually. Cloudflare Load Balancing operates at the DNS and edge-routing layer, steering traffic toward the best origin, but a regional load balancer, application server, or API gateway is still needed behind each origin to actually distribute requests among individual backend instances. Most production setups run Cloudflare in front of ALB or NLB rather than as a full replacement for either.

Does NLB support HTTPS and content-based routing like ALB?

NLB can terminate TLS via a TLS listener for encrypted TCP traffic, but it does not parse HTTP headers, paths, or hostnames to make routing decisions the way ALB does. For routing based on the URL path or the Host header, ALB is the correct tool; NLB is built for raw connection throughput, not content inspection.

How does Cloudflare Load Balancing pricing scale with traffic?

Cloudflare charges $5 per month for the first two origins and five DNS-level health checks, then $5 per month for each additional origin, plus $0.50 per additional 500,000 DNS queries beyond the free 500,000-query monthly allowance shared across the account. Unlike AWS’s per-byte, per-connection billing, Cloudflare’s model is largely flat regardless of request volume, which makes costs more predictable at scale but potentially less optimal for very low-traffic single-origin deployments.

Which load balancer works best with Kubernetes on EKS?

ALB is the default target for Kubernetes Ingress resources via the AWS Load Balancer Controller, letting one load balancer route to multiple services by host or path. NLB is the default for Kubernetes Services of type LoadBalancer, typically used when a workload needs raw TCP/UDP exposure or a static IP rather than HTTP-aware routing. Teams adopting the newer Gateway API standard increasingly pair either option with Cloudflare or another edge provider for the global entry point.

Do ALB and NLB provide DDoS protection out of the box?

AWS Shield Standard is automatically included at no extra cost for all AWS customers and provides baseline protection against common network and transport-layer attacks, but more advanced, application-layer mitigation requires AWS Shield Advanced and AWS WAF rules configured separately and billed on top of the load balancer’s own usage charges. Cloudflare Load Balancing, by contrast, sits on a network that includes DDoS mitigation as a standard part of the platform.

What happens if an entire AWS region goes down while using only ALB or NLB?

A regional outage takes down the ALB or NLB in that region along with everything registered behind it, since both are regional resources. Recovering requires either a pre-configured Route 53 failover policy pointing to a healthy region or a global layer like Cloudflare Load Balancing sitting in front of multiple regional load balancers, detecting the outage via cross-region health checks, and rerouting traffic automatically.

Is it worth using all three load balancer types in one architecture?

For organizations running multi-region production workloads with a mix of HTTP APIs and raw TCP/UDP services, yes. A common pattern uses NLB for latency-sensitive TCP/UDP traffic, ALB for HTTP APIs and web applications within each region, and Cloudflare Load Balancing as the global steering layer that routes users to the nearest healthy region and fails over automatically if one goes down. Smaller, single-region applications rarely need more than one of the three.