Enabling IPv6 on a CDN involves more than publishing an AAAA record. A complete rollout covers two independent connections: the viewer-to-CDN path and the CDN-to-origin path. It must also account for dual-stack DNS, origin listeners, firewall allowlists, signed URLs, real client IP handling, log parsers, analytics systems, and IPv4 fallback. Any component that still assumes every IP address is IPv4 can block users, distort security decisions, or silently discard monitoring data.
With Amazon CloudFront, viewer traffic can use both IPv4 and IPv6. For supported custom origins, CloudFront can also connect using IPv4 only, IPv6 only, or dual-stack networking. A controlled migration usually starts by enabling dual-stack access for viewers, correcting application and logging compatibility, and then evaluating IPv6 on the origin connection as a separate change.
Features and configuration details in this article were reviewed on August 7, 2026. Cloud service capabilities can change, so verify the available options in the current console and official documentation.
Separate the Two CDN IPv6 Connections
| Connection | Purpose | Main Configuration | Common Misunderstanding |
|---|---|---|---|
| Viewer → CDN | Lets users on IPv6 networks reach the edge over IPv6 | Enable IPv6 on the distribution and publish A and AAAA DNS answers | Assuming the CDN will automatically use IPv6 to reach the origin |
| CDN → Origin | Controls whether edge servers use IPv4, IPv6, or either protocol for origin requests | Origin IP address type, origin DNS, listeners, routing, and firewall rules | Publishing an AAAA record without confirming that the service listens on IPv6 |
An IPv6 viewer does not require an IPv6 origin. A user can connect to CloudFront over IPv6 while CloudFront continues to fetch content from the origin over IPv4. Conversely, adding IPv6 to the origin does not automatically make IPv6 available to viewers. Viewer support still depends on the distribution and public DNS configuration.
Which CloudFront IPv6 Connection Mode Should You Use?
Viewer side: enable IPv6
When IPv6 is enabled, CloudFront can accept viewer requests from both IPv4 and IPv6 networks. AWS also notes that CloudFront can use IPv4 to serve a viewer when its systems determine that IPv4 would provide a better experience. Enabling the feature therefore does not mean every eligible request will immediately use IPv6.
Origin side: IPv4 only, IPv6 only, or dual-stack
CloudFront currently provides three IP address type choices for supported custom origins. These choices do not apply to Amazon S3 origins or VPC origins:
IPv4 only: The default and the safest choice for an origin that has not completed IPv6 readiness work.
IPv6 only: The origin domain must resolve to a working IPv6 address, and the service, network route, and firewall must fully support IPv6.
Dual-stack: CloudFront can choose between IPv4 and IPv6 to help maintain performance and availability.
If the immediate objective is to serve users on IPv6 networks, you can enable IPv6 for viewers without changing the origin to IPv6. Treat dual-stack origin connectivity as a separate deployment with its own tests and rollback plan.
How Should A and AAAA Records Be Configured?
CloudFront manages address resolution for its default distribution domain. When you use your own domain, the required DNS records depend on the DNS provider and record type.
Using Route 53 alias records
If IPv6 is enabled on the distribution and viewers use a custom domain, AWS instructs Route 53 users to create two alias records for that domain:
A alias: Routes IPv4 DNS queries to the CloudFront distribution.
AAAA alias: Routes IPv6 DNS queries to the same distribution.
A zone apex cannot use a conventional CNAME record. Route 53 alias records—or equivalent ANAME, ALIAS, or CNAME-flattening features offered by other DNS providers—are normally used for an apex domain. Names and exact behavior vary by provider.
Using a conventional CNAME
AWS documentation explains that if a custom hostname is already a CNAME pointing to the CloudFront distribution domain, a separate CNAME change is generally unnecessary for IPv6. The target distribution name can return the applicable addresses. You should still validate the final DNS and HTTPS behavior from real IPv4-only, IPv6-only, and dual-stack networks.
# Check IPv4 resolution dig A cdn.example.com # Check IPv6 resolution dig AAAA cdn.example.com # Force an HTTP request over each address family curl -4 -I https://cdn.example.com/test-object curl -6 -I https://cdn.example.com/test-object
If the local network has no working IPv6 route, a failed curl -6 request does not prove that the CDN is misconfigured. Repeat the test from a native IPv6 network or an external monitoring location.
What Should Be Checked Before Enabling IPv6 to the Origin?
1. Confirm that the AAAA record points to the intended endpoint
An AAAA response is only the first requirement. Confirm that the address belongs to the correct server or load balancer, is not a retired address, and does not bypass a security layer that currently protects the IPv4 path. Record the DNS answers and TTL before and after the change.
2. Confirm that the application actually listens on IPv6
Assigning an IPv6 address to a server does not guarantee that Nginx, Apache, an application container, or a load balancer is listening on it. Check the listener configuration and make an HTTPS request that validates the certificate, SNI behavior, virtual host, status code, and returned content.
3. Configure IPv6 routing, firewalls, and security groups
IPv4 and IPv6 are separate address families. An IPv4 CIDR allowlist does not automatically permit IPv6 traffic. AWS provides separate CloudFront managed prefix lists for IPv4 and IPv6 origin-facing servers. If an origin security group only accepts CloudFront traffic, choose the list or lists that match the configured origin connection mode.
4. Test TLS and application health
HTTPS origin requests over IPv6 still have the same TLS requirements. The certificate must match the configured origin domain, the chain must be complete, the port must be reachable, and a supported TLS version must be negotiable. Do not stop at a successful TCP connection; validate status codes, headers, and the response object.
Compatibility Risks for Allowlists, WAF, and Signed URLs
IP-dependent logic is one of the most frequently missed parts of an IPv6 migration. Check whether:
WAF IP sets include the required IPv6 CIDR ranges.
Application database fields can store complete IPv6 addresses.
Regular expressions incorrectly accept only digits and periods.
Rate limiting groups IPv6 addresses at a suitable prefix level.
Admin panels, download links, or API allowlists accept IPv6.
Third-party risk engines, geolocation databases, and SIEM tools parse IPv6 correctly.
Important CloudFront signed URL and signed cookie limitation: AWS states that the IpAddress condition in a custom policy supports standard IPv4 CIDR notation, not IPv6. Do not simply enable IPv6 on a distribution that relies on this restriction. If some content must retain an IPv4 address restriction while other content supports IPv6, AWS suggests using separate distributions.Do not treat every complete IPv6 address as a permanent user identifier. Privacy addresses can change, and one person or device can appear under multiple addresses. Rate limiting, authentication, and fraud controls should not rely mechanically on a single full address.
How Should an Application Read the Real Client IPv6 Address?
The c-ip field in CloudFront standard and real-time logs can contain either an IPv4 or IPv6 address. For custom origins, X-Forwarded-For can also contain both formats and may include a list of proxy addresses.
An application should not automatically take the first or last string in a forwarded address list and call it the client. A safer process is to:
Trust forwarded headers only when the request comes from a known proxy or CDN.
Parse the proxy chain according to the application's trusted proxy rules.
Use a maintained IP address library for parsing and normalization.
Store addresses in an IPv6-capable field or binary representation.
Accept compressed notation when displaying or comparing addresses.
For example, 2001:db8::1 and its fully expanded form can represent the same address. Direct string comparison, manual zero padding, and splitting on colons are error-prone.
Updating Logs, Monitoring, and Analytics for IPv6
| Component | Typical IPv6 Failure | Recommended Change |
|---|---|---|
| Log collector | Field too short or parser supports only IPv4 | Use a standard IP parser and test compressed and expanded IPv6 samples |
| Database | Address stored in VARCHAR(15) | Use an IPv6-capable type, binary storage, or a suitably sized normalized field |
| Reports | Network grouping based on periods | Use an IP library for prefixes and subnet calculations |
| Alerts | Unrecognized addresses are silently discarded | Count parser failures separately and create an alert |
| Geolocation and risk | Outdated IPv6 coverage | Update the database and avoid treating an unknown location as automatically malicious |
The c-ip field can be used to estimate the share of CloudFront requests coming from IPv6 clients. Checking for a colon may be adequate for a rough report, but security rules and prefix aggregation should use a proper IP address library.
Why DNS Alone Is Not an IPv4 Fallback Plan
A dual-stack hostname normally provides both A and AAAA answers. Modern clients commonly start IPv6 and IPv4 connection attempts in parallel or with a short delay rather than waiting for one address family to time out completely. This behavior is often called Happy Eyeballs. It reduces the impact of a poor path, but it does not repair a broken deployment.
Users can still experience delays or failures when:
The AAAA record points to a routable address on which the application does not work.
An IPv6 firewall silently drops packets and causes a long handshake timeout.
An older client, SDK, or corporate proxy has weak fallback behavior.
DNS caches retain an AAAA record that has already been removed.
An application dependency is available only over IPv4.
A practical fallback strategy therefore combines client dual-stack behavior, CDN connection selection, a DNS rollback procedure, and server-side monitoring. The presence of an A record by itself is not a guarantee of fast or universal fallback.
A Safer IPv6 Deployment Sequence
Inventory dependencies: List DNS, CDN, origins, WAF rules, allowlists, signed URLs, logs, databases, and third-party services.
Fix compatibility first: Make sure IP fields, parsers, and security rules accept IPv6.
Enable viewer IPv6 on a test hostname: Validate A, AAAA, HTTPS, caching, and error responses.
Test different network types: Cover IPv4-only, IPv6-only, and dual-stack access.
Roll out gradually: Monitor request volume, 4xx and 5xx responses, TLS errors, DNS failures, and IPv6 share.
Keep the origin on IPv4 initially: Stabilize the viewer change instead of changing both network segments at once.
Test a dual-stack origin separately: Validate AAAA answers, listeners, certificates, firewalls, CloudFront prefix lists, and origin metrics.
Prepare rollback: Record the original CDN and DNS settings before deployment.
What Should Be Monitored After Launch?
IPv4 and IPv6 request counts and percentages.
4xx, 5xx, and connection failures by address family.
DNS A and AAAA resolution success and latency.
TLS handshake failures and certificate errors.
Time to first byte across networks and regions.
WAF blocks, allowlist denials, and rate-limit anomalies.
Log parser failures, unknown address formats, and geolocation misses.
IPv4 and IPv6 origin request shares and error rates.
Save an IPv4 baseline before making the change. Without a baseline, an increase in errors can be difficult to attribute to IPv6, an application release, or ordinary origin instability.
Frequently Asked Questions
Does the origin need IPv6 after CloudFront IPv6 is enabled?
No. The viewer-to-CloudFront and CloudFront-to-origin connections are separate. Viewers can use IPv6 while CloudFront continues to reach the origin over IPv4.
Does an AAAA record prove that a website supports IPv6?
No. An AAAA record only maps a name to an address. Routing, service listeners, firewalls, TLS, virtual hosts, and application responses must also work.
Will every user switch to IPv6 after it is enabled?
No. Network availability, operating systems, clients, and path quality affect address-family selection. CloudFront can also use IPv4 when it determines that IPv4 offers a better viewer experience.
Can IPv6 be rolled back immediately by deleting the AAAA record?
Not always. Recursive resolvers and clients can retain the old answer until its TTL expires. A rollback plan should account for DNS caching, CDN configuration propagation, and users who still hold the previous result.
Will IPv6 automatically make the CDN faster?
Not necessarily. IPv6 can have a more direct path on some networks and a weaker path on others. Compare real measurements across the regions and network providers that matter to the application.
Conclusion
A successful CDN IPv6 rollout is not an “add AAAA and finish” change. Viewer connectivity, origin connectivity, DNS, security controls, and observability must be treated as one system. For most existing websites, the lower-risk sequence is to make every component IPv6-aware, enable viewer dual-stack access, observe it, and only then test a dual-stack origin.
Three CloudFront details deserve particular attention: Route 53 custom domains need both A and AAAA alias records; logs and X-Forwarded-For can contain IPv6; and the IpAddress condition in a signed URL or signed cookie custom policy does not support IPv6. Designing around these constraints before launch is more reliable than removing AAAA records during an incident.
CloudFlew provides CDN services based on CloudFront. Before enabling IPv6, document the current domains, origin types, IP allowlists, and logging pipeline, and then introduce dual-stack capability according to measured test results.
References
AWS CloudFront Developer Guide: Enable IPv6 for CloudFront distributions, reviewed August 7, 2026
AWS Route 53 Developer Guide: Routing traffic to a CloudFront distribution, reviewed August 7, 2026
AWS CloudFront Developer Guide: Create a signed URL using a custom policy, reviewed August 7, 2026
AWS CloudFront Developer Guide: Request and response behavior for custom origins, reviewed August 7, 2026
AWS CloudFront Developer Guide: Locations and IP address ranges of CloudFront edge servers, reviewed August 7, 2026
IETF RFC 8305: Happy Eyeballs Version 2, reviewed August 7, 2026
