Comparing Response Times from CloudFront to an ALB in the Tokyo Region Using VPC Origins, HTTP/HTTPS, and Origin Shield
This page has been translated by machine translation. View original
Introduction
With CloudFront VPC origins, you can use an ALB placed in a private subnet as a CloudFront origin.
To investigate the communication latency from CloudFront to the origin, I prepared 8 configurations combining the presence or absence of a VPC origin, HTTP vs. HTTPS, and the presence or absence of Origin Shield, and compared response times by edge region.
Test Environment
Configurations Compared
The configurations compared are combinations of the ALB type (Public ALB, or internal ALB via VPC origin) and the origin protocol (HTTP, HTTPS). Adding Origin Shield (none, ap-northeast-1), I prepared 8 distributions.
| # | ALB type | Origin protocol | Origin Shield |
|---|---|---|---|
| 1 | Public ALB | HTTP | None |
| 2 | Public ALB | HTTP | ap-northeast-1 |
| 3 | Public ALB | HTTPS | None |
| 4 | Public ALB | HTTPS | ap-northeast-1 |
| 5 | VPC origin (internal ALB) | HTTP | None |
| 6 | VPC origin (internal ALB) | HTTP | ap-northeast-1 |
| 7 | VPC origin (internal ALB) | HTTPS | None |
| 8 | VPC origin (internal ALB) | HTTPS | ap-northeast-1 |
The settings common to all configurations are as follows.
- I specified Managed-CachingDisabled as the cache policy so that all requests are forwarded to the origin.
- I configured the ALB to return a fixed response via a listener rule.
- In the HTTP configurations, I specified the ALB's default DNS name as the origin.
- In the HTTPS configurations, I registered a custom domain with an ACM certificate attached in Route 53 and specified that domain as the origin.
Measurement Method
The request source is the Route 53 health checker (HTTP, 30-second interval).
For aggregation, I used the rows of the CloudFront standard logs where sc-status is 200, and converted time-taken to ms. time-taken is the time from when CloudFront receives the request until it writes the last byte of the response to the output queue.
I divided the edges into 6 regions by the first 3 characters of x-edge-location: US, EU (DUB), GRU (São Paulo), SYD (Sydney), SIN (Singapore), and NRT (Tokyo). I measured for about 4 hours.
Measurement Results
Response Time by Region
These are the average time-taken (ms) for each region. Shield in the table indicates the presence or absence of Origin Shield (ap-northeast-1). This is for the case where the origin protocol is HTTP.
| Region | Public ALB / No Shield | VPC origin / No Shield | Public ALB / With Shield | VPC origin / With Shield |
|---|---|---|---|---|
| US | 236.7 | 238.6 | 125.4 | 125.8 |
| EU | 407.3 | 412.6 | 212.5 | 215.2 |
| GRU | 517.1 | 519.5 | 270.4 | 269.3 |
| SYD | 221.2 | 222.3 | 117.3 | 120.8 |
| SIN | 137.1 | 140.6 | 78.1 | 81.6 |
| NRT | 12.2 | 9.2 | 8.9 | 10.3 |
This is for the case where the origin protocol is HTTPS.
| Region | Public ALB / No Shield | VPC origin / No Shield | Public ALB / With Shield | VPC origin / With Shield |
|---|---|---|---|---|
| US | 356.2 | 359.6 | 128.3 | 127.7 |
| EU | 612.6 | 623.2 | 216.5 | 214.2 |
| GRU | 773.8 | 783.6 | 272.9 | 272.2 |
| SYD | 327.1 | 333.2 | 123.9 | 125.9 |
| SIN | 206.5 | 210.9 | 80.1 | 78.9 |
| NRT | 13.9 | 13.0 | 11.3 | 9.4 |
The measured 200 responses number just over 50,000. From the two tables, the following 3 points can be confirmed.
- There is no notable difference in response time depending on whether a VPC origin is used. The difference is about 10 ms at most.
- HTTPS is slower than HTTP, and the difference grows larger in regions farther from Tokyo.
- Origin Shield greatly reduces response time in regions farther from Tokyo, with the reduction reaching up to about 500 ms with HTTPS.
When Specifying an Origin Domain for IPv6
Comparison Conditions
CloudFront VPC origins added dual-stack support in October 2026.
I added 2 configurations that connect from CloudFront to the origin over IPv6 and compared their response times with the IPv4 case.
The IPv6 connection was prepared with the following steps.
- I made the ALB dual-stack and gave it IPv6 addresses.
- I registered only an AAAA record for the origin domain, pointing to the ALB's IPv6 addresses. As a result, CloudFront resolves the origin with AAAA and connects over IPv6.
- The IPv4 configurations used for comparison specify the same ALB with an origin domain that has an A record.
The 2 added configurations are Public ALB and VPC origin, both with HTTP and no Origin Shield.
Measurement Results
These are the time-taken (ms) values for all POPs and for NRT.
| Configuration | All POPs avg | All POPs P95 | All POPs P99 | NRT avg | NRT P95 | NRT P99 |
|---|---|---|---|---|---|---|
| Public ALB, IPv4 | 248 | 521.2 | 528.5 | 13 | 37 | 39 |
| Public ALB, IPv6 | 249 | 522.2 | 532.2 | 12 | 38 | 40 |
| VPC origin, IPv4 | 252 | 525.4 | 535.4 | 10 | 40 | 72 |
| VPC origin, IPv6 | 253 | 526.4 | 538.1 | 10 | 38 | 71 |
Even when the connection from CloudFront to the origin used IPv6, the response time was almost the same as with IPv4.
Summary
The path itself from CloudFront to the ALB cannot be observed. However, as far as time-taken measured by the Route 53 health checker over several hours shows, I was able to confirm that response time does not change even when using a VPC origin.
For configurations that place an ALB as the CloudFront origin, where the main Region is a single Region such as Tokyo, please consider VPC origins first. If you do not use multi-Region deployment of VPC resources, gRPC, or origin-related triggers of Lambda@Edge, there is no additional charge for VPC origins. VPC origins can reduce unnecessary exposure paths.
I was also able to confirm the effects of adopting Origin Shield and switching the origin protocol to HTTP as means of reducing latency. Even if you want to encrypt traffic all the way to the origin with HTTPS, the added latency can be offset by Origin Shield. For workloads that do not require end-to-end communication encryption within AWS and that prioritize latency reduction, please also consider using VPC origins with HTTP.
