Optimizing application performance: The strategic benefits of combining Amazon CloudFront with Application Load Balancers

As organizations scale globally, balancing user experience with operational costs becomes increasingly complex. Integrating Amazon CloudFront with Application Load Balancer (ALB) addresses this challenge by reducing latency by serving content from over 750 edge locations worldwide and maintaining persistent TCP connections between CloudFront and ALB origins while reducing Data Transfer Out (DTO) expenses through the CloudFront tiered pricing structure (including flat-rate). Furthermore, this provides significantly lower rates than standard Amazon Web Services (AWS) data transfer costs. Moreover, this pattern, described in Figure 2, supports multi-Region deployments with intelligent edge-based routing, so that organizations can distribute traffic across AWS Regions, implement sub-second failover mechanisms, and substantially reduce origin server load through effective caching strategies. The security includes the following:

1. A comprehensive availability protection against all known network and transport layer attacks through AWS Shield Standard and optional AWS Shield Advanced and AntiDDoS AMR WAF Rule for sophisticated Layer 7 Distributed Denial of Service (DDoS) attacks.
2. Centralized SSL/TLS certificate management.
3. The ability to isolate backend infrastructure within private VPCs using the CloudFront VPC Origin maintaining global accessibility.

This guide examines the measurable performance improvements and key architectural considerations that organizations must evaluate when migrating to this CloudFront-ALB integration pattern.

Architecture and migration consideration

The architecture shown in Figure 1 demonstrates a traditional web application deployment where an ALB serves as the internet-facing entry point for user traffic.

Figure 1: Web application deployment where an ALB acts as the internet-facing entry point

End users access the application through DNS services such as Amazon Route 53, which translates the domain name using different record types that ultimately resolve to the ALB’s IP address. CloudFront provides two DNS options:

1. CNAME records: Standard DNS records that map one domain name to another but can’t be used for zone apex domains (such as com).
2. Alias records: Route 53-specific extensions that enable zone apex domain routing (such as com) where CNAME records are prohibited, responding directly with IP addresses instead of requiring more DNS lookups. Alias records support multiple routing types including A/AAAA for IP addresses and HTTPS records that provide protocol information (HTTP/2 and HTTP/3) during DNS resolution. Therefore, clients can establish optimal connections immediately without protocol discovery overhead.

Security is enforced through TLS-encrypted communication between users and the ALB, and it’s enhanced by AWS WAF that protects against common web vulnerabilities, sophisticated bot activities, and DDoS attacks. Although this configuration effectively supports applications requiring multiple domain management and dynamic content delivery, integrating CloudFront with ALB delivers the following measurable benefits.

• Improved global performance through edge location content delivery
• Enhanced security through the following:
  • Multiple protection layers, including TCP connection termination for slow-reading or slow-writing attacker and an application layer based on AWS WAF
  • The CloudFront VPC Origin capabilities for private infrastructure access
  • Reduced DTO costs

Figure 2: Optimized web application deployment where CloudFront acts as global internet-facing entry point

The architecture shown in Figure 2 presents an optimized web application design where CloudFront acts as the global entry point through its distributed edge locations. It automatically selects the locations closest to users to minimize latency and maximize availability. This design relocates AWS WAF functionality to the edge, preserving rule effectiveness for policies involving source IP, JA3/JA4, ASN validation, and TLS connection parameters. Users access the application through DNS services such as Route 53, which resolves to CloudFront distributions through either CNAME or Alias records. The solution uses the CloudFront VPC Origin functionality to establish direct, secure communication channels with the ALB within the private VPC environment. Performance gains are realized through two primary mechanisms: static assets are delivered from the CloudFront edge cache, dramatically reducing Time-To-First-Byte (TTFB), while dynamic content benefits from the CloudFront persistent TCP connection pooling with the ALB. This delivers improved response times despite the added network hop through the CloudFront layer.

The next section describes the main considerations during the evaluation or testing phase, and the migration and production phases.

Testing/development environment

1. Create a CloudFront distribution with existing ALB as the origin. CloudFront can communicate with ALBs on any port using either: 1) HTTPS with a valid TLS certificate matching the ALB’s domain name (recommended), or 2) HTTP without encryption. Although the HTTP option is available, we don’t recommended this because as it doesn’t follow AWS security best practices. HTTPS ensures encrypted communication between CloudFront and your ALB, thereby protecting data in transit across the entire request path.
2. Best practice: Instead of using the existing internet-facing ALB, you can create a new Internal ALB and configure it as a CloudFront VPC Origins.
3. During the CloudFront distribution creation, the process provides a recommended cache configuration for VPC Origin.
4. Optional: Associate a custom domain/subdomain with your CloudFront distribution, or use the default CloudFront domain (for example d123456789.cloudfront.net). CloudFront supports different strategies to import and validate TLS certificates
5. If your production ALB uses host-header routing rules, then they must include whichever domain you choose (either your custom domain or the CloudFront canonical domain). Furthermore, you must verify that the CloudFront origin request policy is configured to forward the Host header to the origin.
6. Replicate the existing AWS WAF WebACL (attached to the ALB) to a new WebACL (Global) and attach it to CloudFront to evaluate AWS WAF effectiveness at the edge. Manually copy managed rules and custom rules using the AWS Management Console JSON editor or by recreating rules manually. After migration, remove the WebACL attached to your ALB.
7. Now the application is ready for testing.

Extra considerations when migrating to a production environment

We recommend CloudFront VPC Origin. However, starting the migration process using an internet-facing ALB enables gradual traffic migration. When you complete the migration to CloudFront, you can migrate your internet-facing ALB to a CloudFront VPC Origin to strengthen your security posture.

TLS certificates and DNS records

For internet facing ALBs, if you’re using Route 53 as the DNS Provider, then use Route 53 weighted routing to gradually shift traffic from ALB (starting at 90%) to CloudFront (10%), adjusting weights until reaching full CloudFront distribution. If you use any different DNS provider, then plan this DNS change during a maintenance window to minimize service disruption.

Whether you’re using an internet-facing or internal ALB, it requires a valid TLS certificate for a domain or subdomain, which CloudFront uses to forward traffic to the origin. For optimal security, prioritize internal ALBs to remove public internet exposure.

Multiple domain configuration

When your ALB routes multiple domains to different target groups using host-header or path-pattern based listener rules, we recommend using CloudFront SaaS Manager for multi-tenant architectures. This solution is ideal when you need to route different hostnames or URL paths to separate target groups behind a single ALB.

ALB security group updates

For internet-facing ALB: Update the security group to allow inbound traffic from the CloudFront managed prefix list (com.amazonaws.global.cloudfront.origin-facing and com.amazonaws.global.ipv6.cloudfront.origin-facing) on ports 80 (HTTP) and 443 (HTTPS). This establishes that only CloudFront edge locations can reach your ALB while blocking direct internet access.

Origin authentication with custom headers

Configure CloudFront to send a custom header (for example X-Origin-Verify: secret-value) to the ALB and configure the ALB to only forward requests that contain this header, which prevents direct ALB access that bypasses CloudFront.

IPV6 support and TLS 1.3

If your ALB already supports IPv6, then configure the CloudFront Origin IP Address type to IPv6 or dual-stack during migration to enable end-to-end IPv6 delivery. CloudFront now supports TLS 1.3 for origin connections, automatically negotiating TLS 1.3 when your ALB supports it. Customers can upgrade their ALB TLS version or enforce strict TLS 1.3-only communication for enhanced security and improved connection performance.

Origin request policies

By default, CloudFront excludes query strings, HTTP headers, and cookies from origin requests to your ALB. Configure origin request policies to forward necessary headers such as Host (required for ALB routing rules), cookies for session-based applications, and query strings for dynamic content. Moreover, forward CloudFront-generated headers if your application needs access to viewer’s device type, IP address, geographic location, or TLS connection details. For Cross-Origin Resource Sharing (CORS) applications, configure your origin request policy to forward CORS-related headers.

Caching policies

When migrating from direct ALB access to CloudFront, AWS recommends the UseOriginCacheControlHeaders managed cache policy for web applications and dynamic content. This policy respects your ALB’s Cache-Control headers while maintaining optimal cache performance at edge locations. Similarly use UseOriginCacheControlHeaders-Query String if Query strings are included in the cache key

Response headers

If your ALB already sends certain headers, then the CloudFront response header policies can override, append, or preserve them. During migration, audit existing ALB response headers to avoid conflicts or duplicate headers that could break application functionality or security policies. For enhanced security, use CloudFront to remove metadata headers such as “Server” and “X-Powered-By” that expose underlying infrastructure details unnecessary for client functionality. For CORS applications, ensure CloudFront preserves CORS response headers from your ALB.Origin settings.

Origin settings

Configure high keep-alive timeout values, but make sure that they are lower than your ALB’s idle timeout to maintain persistent connections with your ALB. This reduces TCP and TLS handshake overhead for subsequent requests and improves overall performance. Consider increasing the response timeout from the default 30 seconds if your applications needs longer processing times. Keep the other origin timeout settings at default values.

Viewer mTLS

For applications requiring enhanced client authentication, configure the CloudFront mutual TLS to validate client certificates at edge locations before forwarding requests to your ALB. This offloads mTLS authentication from your ALB while establishing that only trusted clients reach your backend applications.

Performance evaluation

While comprehensive CloudFront performance evaluation requires monitoring multiple metrics including cache-hit ratio, origin latency, 4xx/5xx error rates, and bytes downloaded, this section focuses specifically on time to first byte (TTFB) as the primary performance indicator. TTFB provides a holistic measure that captures the cumulative impact of DNS resolution times, TCP connection establishment, SSL/TLS handshake durations, and initial response delivery across the complete request-response cycle. This analysis compares TTFB measurements between direct ALB deployments and CloudFront configurations positioned in front of the ALB, with testing conducted across multiple geographic regions to evaluate two distinct scenarios:

1. Viewers positioned close to the origin servers
2. Viewers located at significant distances from the origin infrastructure

As shown in Figure 3, CloudFront consistently outperformed direct ALB access across all testing scenarios, with the most significant performance gains observed when serving content to geographically distant clients. The geographic distance between clients and origin servers directly correlated with performance improvements: Regional connections showed gains of 15-25% TTFB, while intercontinental requests demonstrated substantial improvements of 35-50% TTFB. The comprehensive evaluation encompassed both static and dynamic content types across HTTP and HTTPS protocols to establish definitive architectural performance baselines. The testing methodology employed curl for granular timing analysis, Apache Bench for concurrent load simulation, and CloudWatch Canaries and CloudWatch RUM for real-world performance validation.

Figure 3: TTFB results

Note: Consider Essential CloudFront Metrics like Cache-Hit Ratio, Origin latency, 4xx/5xx error rates, Bytes downloaded when evaluating CloudFront performance.

Cost considerations

CloudFront offers a Free Tier that includes 1 TB of DTO to the internet and 10 million HTTP or HTTPS requests each month. DTO from any AWS origin to CloudFront is free. You only incur charges for CloudFront DTO to the internet (clients) and HTTP requests.

You can reduce these costs further with the following:

• CloudFront Flat-Rate Pricing Plans.
• CloudFront Savings Bundle.
• Committing to minimum traffic volumes (typically 10 TB/month or higher).
• Consider Regional DTO costs to the origin if your application predominantly uses PUT/POST requests or is WebSocket-based. It’s waived by flat-rate.
• CloudFront DTO only counts bytes from the response, excluding exchanging TLS certificates, while, for example, Amazon Elastic Compute Cloud (Amazon EC2) DTO counts all of the bytes in the wire including TLS.
• CloudFront compresses objects before serving them to viewers, in some cases reducing file sizes to less than a quarter of the original. Furthermore, CloudFront data transfer pricing is based on total data served, thus compressed objects cost less to deliver than uncompressed ones.
• Customers never incur request fees or data transfer charges for requests blocked by AWS WAF attached to CloudFront.
• Origin offload with persistent connections significantly reduces ALB Load Balancer Capacity Unit (LCU) costs by optimizing connection management. This feature enables CloudFront to reuse existing TCP upstream connections to your origin server across multiple user requests, rather than establishing new connections for each request. CloudFront maintains persistent connections and removes redundant TCP and TLS handshakes, reducing both latency and the computational overhead that drives LCU consumption at your origin load balancer
• Users can configure Route 53 alias HTTPS records that point directly to CloudFront distributions, and Route 53 serves these DNS queries free of charge. This removes costs for the three most common DNS record types (A, AAAA, and HTTPS).

Conclusion

Amazon CloudFront-ALB integration delivers measurable value across three dimensions:

• enhanced global performance improving user experience,
• cost optimization through reduced DTO and LCU expenses, flat-rate pricing options, and compression savings, and
• comprehensive security through edge-level DDoS protection, AWS WAF at 750+ locations, and VPC Origin.

The platform supports modern protocols including full IPv6 and TLS 1.3 for enhanced security and performance, automatically compresses content to reduce bandwidth costs, and integrates seamlessly with AWS Certificate Manager for SSL/TLS certificate management.

The advanced features of CloudFront such as automatic failover provide seamless high availability across multiple AWS Regions, while edge compute capabilities through Lambda@Edge and CloudFront Functions enable real-time request processing at global locations.

Organizations serving global audiences can’t afford to ignore performance improvements of 30-55% for global users. These substantial gains represent competitive advantages that directly impact conversion rates and user retention. For enterprises needing maximum performance, security, and cost efficiency at global scale, CloudFront-ALB integration is more than an optimization—it’s a strategic imperative that transforms application delivery from Regional constraint to global competitive advantage.

About the authors