ELB vs CloudFront: What It Is and When to Use It

Definition

Elastic Load Balancing (ELB) and Amazon CloudFront are both AWS services that route incoming network traffic, but they solve different problems at different scales. ELB is a regional service that distributes traffic across multiple backend targets (like Amazon EC2 instances or containers) within a single AWS Region to ensure high availability and fault tolerance. Amazon CloudFront is a global Content Delivery Network (CDN) that caches content in hundreds of edge locations worldwide, accelerating content delivery and reducing latency for end-users by serving requests from a location physically closer to them.

How It Works

Understanding the distinction between ELB and CloudFront requires thinking about their scope: regional versus global.

Elastic Load Balancing (ELB) operates within a chosen AWS Region. When a user sends a request to an application, it first hits the ELB's public endpoint. The ELB then acts as a local traffic controller, inspecting the request and forwarding it to one of its registered healthy targets in one of the region's Availability Zones (AZs). It continuously runs health checks on these targets; if one becomes unhealthy, the ELB stops sending traffic to it, automatically improving the application's fault tolerance.

There are three main types of Elastic Load Balancers:

Application Load Balancer (ALB): Operates at Layer 7 (HTTP/HTTPS) and makes intelligent, content-based routing decisions. It can route traffic based on the request's path (/api, /images), hostname (api.example.com), HTTP headers, or query string parameters. This makes it ideal for modern microservices-based architectures.
Network Load Balancer (NLB): Operates at Layer 4 (TCP/UDP/TLS) and is built for extreme performance and ultra-low latency. It can handle millions of requests per second while maintaining the source IP address of the client. NLBs are often used for TCP-based workloads like gaming, IoT, or high-throughput APIs.
Gateway Load Balancer (GWLB): A Layer 3/4 service used to deploy, scale, and manage third-party virtual network appliances like firewalls, Intrusion Detection/Prevention Systems (IDS/IPS), and deep packet inspection systems.

Amazon CloudFront operates on a global scale. When you configure a CloudFront distribution, your content (e.g., images, videos, CSS/JS files, or even dynamic API responses) is copied from your origin server (which could be an S3 bucket, an EC2 instance, or an ELB) to a worldwide network of over 750 Points of Presence (PoPs), or edge locations.

When a user requests your content, their request is routed via DNS to the nearest edge location.

If the content is already in the edge location's cache (a cache hit), CloudFront delivers it immediately, resulting in very low latency.
If the content is not in the cache (a cache miss), CloudFront forwards the request to the origin server, retrieves the content, delivers it to the user, and stores a copy in the edge location's cache for subsequent requests.

This process significantly improves performance for users far from your origin region and reduces the load on your origin servers. Even for dynamic content that cannot be cached, CloudFront can improve performance by terminating the user's connection at a nearby edge location and then carrying the request over the optimized AWS global network back to the origin.

Using ELB and CloudFront Together

A very common and powerful architecture is to use both services together. In this setup, CloudFront acts as the global entry point for all user traffic. It serves cached static content from the edge and forwards requests for dynamic content to the Application Load Balancer, which then distributes the load across the backend application fleet. This architecture provides a multi-layered defense, global performance acceleration, and regional high availability.

To ensure traffic only comes from CloudFront, you can configure your ALB to only accept requests containing a secret custom header that CloudFront adds, or by using CloudFront's VPC Origin feature to connect directly to an internal (private) ALB.

Key Features and Limits

| Feature | Elastic Load Balancing (ELB) | Amazon CloudFront | | :--- | :--- | :--- | | Primary Function | Regional load distribution, fault tolerance | Global content caching and delivery acceleration | | Scope | Regional (operates across Availability Zones within one AWS Region) | Global (operates across 750+ edge locations worldwide) | | Layer | ALB: Layer 7 (HTTP/S), NLB: Layer 4 (TCP/UDP), GWLB: Layer 3/4 | Layer 7 (HTTP/S), supports WebSockets and HTTP/3 | | Health Checks | Actively monitors the health of backend targets and routes traffic only to healthy ones. | Periodically checks origin health and can failover to a secondary origin. | | Security | Integrates with AWS WAF, AWS Shield Standard (free DDoS protection), Security Groups, and Network ACLs. | Integrates with AWS WAF at the edge, AWS Shield Advanced, and provides geo-restriction capabilities. | | Routing | ALB offers advanced routing based on path, host, header, query string. NLB offers TCP/UDP based routing. | Caches content based on cache policies (headers, cookies, query strings). Routes to origins based on path patterns. | | Static IP | NLB can be assigned a static Elastic IP address per AZ. ALBs do not have static IPs. | Does not provide a single static IP, but provides a stable range of IPs via a managed prefix list for allow-listing. | | Edge Compute | N/A | Supports Lambda@Edge and CloudFront Functions for running code at the edge to manipulate requests and responses. |

Service Quotas (Defaults, often adjustable):

ELB: Limits on load balancers per region, listeners per load balancer, rules per load balancer, and targets per target group.
CloudFront: Limits on distributions per account, cache policies, origin request policies, and the number of invalidations you can run concurrently.

Common Use Cases

Use Elastic Load Balancing (ELB) when you need to:

Achieve High Availability: Distribute traffic across multiple EC2 instances in different Availability Zones to protect your application from a single point of failure.
Implement Microservices: Use an Application Load Balancer to route traffic to different containerized services based on the URL path (e.g., /users to the user service, /orders to the order service).
Handle High-Throughput TCP/UDP Traffic: Use a Network Load Balancer for workloads like online gaming, streaming media, or financial trading platforms that require extreme performance and low latency.
Scale Network Security Appliances: Use a Gateway Load Balancer to horizontally scale third-party firewalls and inspection tools for your VPC traffic.

Use Amazon CloudFront when you need to:

Accelerate a Static Website: Serve a website hosted on Amazon S3 through CloudFront to provide fast page loads for users anywhere in the world.
Deliver Video or Large Files: Distribute video-on-demand (VOD) or live streaming content, software downloads, or other large files globally with high throughput and low latency.
Improve Dynamic API Performance: Terminate API requests at the edge and leverage the AWS backbone network to reduce latency for dynamic API calls, even if the content isn't cached.
Reduce Origin Server Load: Offload requests for static assets (images, CSS, JS) to CloudFront's cache, allowing your origin servers to focus on processing dynamic requests.
Enhance Security: Use AWS WAF at the edge to block malicious traffic like SQL injection or cross-site scripting before it ever reaches your application.

Pricing Model

The pricing models for ELB and CloudFront are fundamentally different, reflecting their distinct functions.

Elastic Load Balancing Pricing:

You are charged for each hour or partial hour that a load balancer is running.
You are also charged for Load Balancer Capacity Units (LCUs) or their equivalent (NLCUs for NLB, GLCUs for GWLB).
An LCU is a metric based on the dimension with the highest usage (new connections, active connections, processed bytes, and rule evaluations for an ALB).
This means you pay a base hourly rate plus a variable charge that scales with your traffic volume and complexity. Even an idle load balancer incurs the hourly charge.

Amazon CloudFront Pricing:

Pay-as-you-go: The traditional model bills based on two main dimensions: Data Transfer Out to the internet (priced per GB, with rates varying by geographic region) and the number of HTTP/HTTPS requests.
Flat-rate plans: Introduced in late 2025, these plans offer a fixed monthly price that bundles CDN delivery, AWS WAF, Route 53 DNS, CloudWatch Logs, and more, with no overage charges. Tiers like Free ($0/mo), Pro ($15/mo), and Business ($200/mo) are available, making costs highly predictable.
There is a generous free tier for the pay-as-you-go model, which includes 1 TB of data transfer and 10 million requests per month.
Crucially, data transfer from AWS origins (like S3, EC2, and ELB) to CloudFront is free, which can lead to significant cost savings.

For more details, consult the AWS Pricing Calculator.

Pros and Cons

| Service | Pros | Cons | | :--- | :--- | :--- | | Elastic Load Balancing | High Availability: Automatically distributes traffic, improving fault tolerance. Scalability: Scales automatically to handle traffic demands. Advanced Routing (ALB): Content-based routing is perfect for microservices. Extreme Performance (NLB): Handles millions of requests per second with low latency. | Regional Scope: Cannot reduce latency for a globally distributed user base. Cost for Idle: You pay an hourly fee even if there is no traffic. No Caching: Does not cache content; every request is passed to a backend target. | | Amazon CloudFront | Global Performance: Dramatically reduces latency by caching content close to users. Cost-Effective Data Transfer: Data Transfer Out rates are typically cheaper than from EC2/ELB, and transfer from AWS origins is free. Enhanced Security: Provides a front line of defense with AWS Shield and WAF at the edge. Predictable Pricing: New flat-rate plans eliminate billing anxiety from traffic spikes. | Caching Complexity: Configuring cache policies to optimize cache-hit ratio can be complex. Propagation Time: Changes to a distribution can take several minutes to propagate globally. Not a Load Balancer: While it distributes load to origins, it is not a replacement for a regional load balancer for achieving high availability across AZs. |

Comparison with Alternatives

AWS Global Accelerator: Like CloudFront, Global Accelerator uses the AWS global network to improve performance. However, it is a Layer 4 service that provides you with static Anycast IP addresses to route traffic to regional endpoints (like NLBs or ALBs). It is best for non-HTTP use cases (like gaming or IoT) or for stateful applications that require static IPs, whereas CloudFront is optimized for HTTP/S content caching and delivery.

Exam Relevance

Both ELB and CloudFront are fundamental services that appear frequently across multiple AWS certification exams, including:

AWS Certified Solutions Architect - Associate (SAA-C03): Expect questions on choosing the right load balancer type (ALB vs. NLB) and designing highly available and scalable architectures using ELB with Auto Scaling Groups. You'll also need to know when to use CloudFront to improve performance and reduce costs.
AWS Certified Developer - Associate (DVA-C02): Focus will be on how developers interact with these services, such as using ALB path-based routing for microservices.
AWS Certified SysOps Administrator - Associate (SOA-C02): Questions will likely cover monitoring ELB health checks, troubleshooting, and managing CloudFront distributions and invalidations.
AWS Certified Advanced Networking - Specialty (ANS-C01): Deep-dive questions on complex routing scenarios, security configurations (WAF integration), and performance optimization using both services are common.

For exams, you must know the difference between regional load balancing (ELB) and global content delivery (CloudFront) and be able to design architectures that use them together effectively.

Frequently Asked Questions

Q: Can I use CloudFront without an ELB?

A: Yes, absolutely. CloudFront can use various origins, including Amazon S3 buckets (for static websites), EC2 instances directly, or API Gateway. Using an S3 bucket as an origin for a static website is one of the most common and cost-effective use cases for CloudFront.

Q: Do I need an ELB if I'm already using CloudFront?

A: It is highly recommended for any production application running on EC2 or containers. While CloudFront provides a global entry point, an ELB provides regional fault tolerance by distributing traffic across multiple instances in different Availability Zones. Without an ELB, your CloudFront distribution would point to a single EC2 instance, creating a single point of failure.

Q: Which service provides a static IP address?

A: A Network Load Balancer (NLB) can be configured with a static Elastic IP address in each Availability Zone it is enabled for. An Application Load Balancer (ALB) does not have a static IP address; its IP addresses change over time. Amazon CloudFront does not have a single static IP for a distribution, but AWS provides a managed prefix list—a stable range of IP addresses—that you can use to allow traffic from CloudFront into your security groups.

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.