Networking & Content Delivery
Boost application performance: Amazon CloudFront enables HTTPS record
Amazon CloudFront announced support for Amazon Route 53 HTTPS DNS alias record across its global network, enabling clients to discover the optimal HTTP protocol during the initial DNS resolution phase rather than in a subsequent connection step. This helps users improve performance and security, and simultaneously reduce operational expenses.
This post explores the implementation details, performance improvements and how to set up this feature.
DNS HTTPS record
The HTTPS record is a specialized form of the Service Binding (SVCB) DNS record defined in RFC 9460. These record types enhance the flexibility of secure internet connections, making them more reliable and faster. HTTPS records achieve this by reducing the number of round trips needed to establish a connection and by supporting future protocol upgrades.
The HTTPS DNS record provides more detailed information than other record types (such as A or AAAA) about the services available for a specific domain. This record type provides essential details, such as supported protocols and ports, and can even specify alternate servers to which clients can connect.
When a client performs a DNS lookup and an HTTPS record is available, it immediately receives information about available protocols. This eliminates the need for a separate TLS negotiation and protocol discovery. This allows browsers and mobile applications to establish direct, secure connections on their first attempt using the most performant protocol, thereby reducing latency and vulnerability to downgrade attacks.
HTTPS DNS record format:
<domain> <TTL> IN HTTPS <priority> <target> <parameters>
Example:
mysite.com. 300 IN HTTPS 1 . alpn=h2,h3
Components:
• Domain: Your website’s FQDN (ends with dot)
• TTL: Cache duration in seconds (300-86400)
• Priority: 0 for alias, >0 for service endpoint
• Target: “.” for same domain, or specify different domain
• Parameters: Key-value pairs like alpn=h2,h3 for Application-Layer Protocol Negotiation protocol negotiation values
Lower TTL = more dynamic updates, higher TTL = better caching performance.
Browser support
Major browsers already support HTTPS record types. Chrome, Safari, and Firefox—which collectively represent the vast majority of web traffic—already make these queries by default.
When browsers make a DNS query request, they typically send both the traditional A/AAAA record request and the new HTTPS record request simultaneously. The browser uses the protocol information from HTTPS record response and the IP address to establish the optimal connection. This approach makes sure of optimal performance when HTTPS records are available while maintaining compatibility with DNS servers that don’t yet support them.
In the case where the client doesn’t support this feature, it follows the traditional DNS resolution process as explained in the section, Traditional DNS Resolution and Connection Upgrade Flow. This allows for a risk-free optimization that can only improve performance without potentially breaking compatibility with older clients.
Traditional DNS Resolution and Connection Upgrade Flow
The following sequence diagram shows how clients traditionally discover HTTP/3 support through the Alt-Svc header after an initial HTTP/1.1 or HTTP/2 connection, necessitating multiple connection establishments to upgrade to HTTP/3.

Figure 1: DNS resolution and HTTP/3 upgrade process without HTTPS record
In the following steps we explain the sequence.
Steps 1-2: DNS query
(1) Client queries DNS for www.example.com A/AAAA?
(2) DNS returns CloudFront Edge IPs only
Result: Client has IP address but no protocol information
Steps 3-7: Initial HTTP/2 connection
(3) TCP Handshake (3-way) to CloudFront
(4) TCP Established
(5) TLS Handshake over TCP
(6) TLS Established over TCP
(7) HTTP/2 Request
Response: HTTP/2 Response with Alt-Svc: h3=”:443″
Result: Client learns about HTTP/3 support after first request
HTTP/3 over QUIC delivers better performance for modern web applications, but the connection upgrade process requires an additional roundtrip that introduces latency. In the following section we show how to improve this by using HTTPS DNS records with our CloudFront distributions.
CloudFront HTTPS DNS record with HTTP/3: secure resolution and connection establishment flow
The following sequence diagram shows the DNS resolution with HTTPS record type and subsequent connection establishment between a client and web server.

Figure 2: DNS resolution with HTTPS record type for HTTP/3 connection
In the following steps we explain the sequence.
Steps 1-2: DNS query
(1) Client queries DNS for www.example.com HTTPS and A/AAAA
(2) DNS returns CloudFront Edge IPs + HTTPS record with alpn=h2,h3
Result: Client learns HTTP/3 support through DNS
Steps 3-6: Direct connection
(3) Client initiates QUIC Handshake (1-RTT) to CloudFront
(4) QUIC connection established
(5) Client sends HTTP/3 requests
(6) CloudFront responds with HTTP/3
This preceding diagram demonstrates how the HTTPS DNS record type works to provide early hints for modern web protocols such as HTTP/3 and QUIC that it supports. This allows for a more secure and efficient connection establishment process.
How to create CloudFront HTTPS DNS record
First you must enable HTTP/2 and/or HTTP/3 on your CloudFront distributions. On an existing distribution, go to the Settings container and choose Edit. From there you can enable HTTP/2 or HTTP/3 for the distribution, as shown in the following figure.

Figure 3: Required CloudFront configuration
When your CloudFront distribution has HTTP/2 and/or HTTP/3 enabled you can enable HTTPS records for custom domains through Route 53. Edit the Hosted Zone for your domain, then choose Create Record, as shown in the following figure. For the Record Name, enter the subdomain that matches the domain on your CloudFront distribution. Then, create an alias record of the type HTTPS. Under Route Traffic To, choose Alias to a CloudFront distribution and choose your CloudFront distribution. When it’s saved, CloudFront starts sending HTTPS records for your domain.

Figure 4: Route 53 alias record of type HTTPS
CloudFront cost optimization: using Route 53 alias HTTPS records
When optimizing costs for CloudFront, most strategies focus on maximizing cache hit ratios, offloading origins, reducing data transfer out, and minimizing HTTPS/TLS handshake overheads. However, there’s a powerful yet often overlooked cost-saving technique that arises from Route 53 through the use of alias records.
Traditionally, Route 53 DNS queries are billed on a per-query basis. But when you use alias records (such as alias A for IPv4-only CloudFront distributions, or alias A and AAAA for dual-stack IPv4/IPv6 distributions), Route 53 waives these DNS query charges. This provides a direct reduction in operational costs for high-traffic domains. Support for alias HTTPS records to CloudFront further extends these savings.
Now 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 eliminates costs for the three most common DNS record types (A, AAAA, and HTTPS). Furthermore, this is especially impactful not only for large enterprises with global traffic, but also for startups aiming to scale. It provides valuable peace of mind by eliminating charges for the most common DNS record queries as their usage grows.
Summary: a step forward for web performance
Amazon CloudFront and Amazon Route 53 support of HTTPS DNS records represents a meaningful advance in web performance optimization. Eliminating unnecessary connection setup round trips allows CloudFront to deliver content more quickly and efficiently to end users. HTTPS record support on CloudFront is available today in all edge locations. You can start using these new features through the AWS Management Console. There are no further charges for using HTTPS records from CloudFront or Route 53.