Routing Traffic with Route 53 and CloudFront
When to Use
- Attach a custom domain to a CloudFront distribution and route it through Route 53.
- Coordinate ACM validation, CloudFront alternate domain names, and alias A/AAAA records.
- Plan a low-risk DNS cutover or diagnose the Route 53-to-CloudFront boundary.
Do not use this skill for CloudFront caching/origin work without DNS changes; use
cloudfront. Do not use it for Route 53 records targeting non-CloudFront
endpoints; use route53.
Prerequisites and Quick Reference
- Capture the account, public hosted-zone ID, FQDN, distribution ID/domain, current DNS answers and
TTLs, certificate ARN/status, and rollback target.
- Confirm the ACM certificate is in
us-east-1, covers the FQDN, and is issued before DNS cutover.
- Confirm the distribution is deployed and lists the FQDN as an alternate domain name.
- Prefer alias A and AAAA records for Route 53-hosted domains; retain the change ID and prior records.
Overview
Domain expertise for configuring Amazon Route 53 to route traffic to Amazon CloudFront distributions using custom domain names. Covers hosted zone management, alias A/AAAA records, alternate domain name (CNAME) configuration, and ACM certificate setup for HTTPS.
Configure Route 53 to route traffic to a CloudFront distribution
To set up a custom domain for a CloudFront distribution with Route 53 DNS, follow the procedure exactly.
See Route 53 CloudFront routing procedure.
The procedure covers:
- Verifying CloudFront distribution status and CNAME configuration
- Requesting and validating ACM certificates (must be in us-east-1)
- Creating or locating public hosted zones
- Creating alias A and AAAA records pointing to CloudFront
- Monitoring DNS propagation
Verification and Recovery
- Before cutover, verify the certificate and distribution readiness checks above. Do not create the
alias first and hope the distribution converges later.
- After the change reports
INSYNC, query authoritative name servers for A and AAAA, then make an
HTTPS request using the custom hostname. Assert the certificate hostname, expected distribution
response, and an application-specific body/header condition.
- Confirm direct origin access remains blocked when origin protection is expected.
- If any assertion fails, stop, restore the captured prior A/AAAA records, wait for that change to
become
INSYNC, and repeat DNS and HTTPS checks. Preserve the failed change ID and observations.
Evaluation Prompts
- Normal: “Route
www.example.com to an existing CloudFront distribution with A/AAAA aliases.”
- Difficult edge: “Cut over the zone apex with low risk when an old CNAME-like target is cached and
IPv6 clients must work.”
- Should not activate: “Create latency-based Route 53 records for two API Gateway endpoints.”
Source Boundary
The certificate-region, alternate-domain, and Route 53 alias requirements are sourced from the AWS
documentation below and the imported Apache-2.0 upstream. The readiness gate, evidence capture,
application assertion, and rollback sequence are curator recommendations.
Additional Resources
Troubleshooting
Domain not in CloudFront CNAMEs
Add the domain as an alternate domain name in the CloudFront distribution configuration before creating Route 53 records.
SSL certificate issues
ACM certificates for CloudFront must be in us-east-1. Ensure the certificate is validated and associated with the distribution.
Private hosted zone
CloudFront only works with public hosted zones. Create a public hosted zone if only a private one exists.
DNS propagation delays
Changes typically propagate within 60 seconds but full global propagation can take up to 48 hours. Use nslookup or dig to verify.
1---2name: routing-traffic-with-route53-and-cloudfront3description: Use when routing a custom domain to Amazon CloudFront with Route 53 alias A/AAAA records, alternate domain names, ACM certificates, and IPv6. Coordinates readiness, DNS cutover, verification, and rollback across both services.4license: Apache-2.05---67# Routing Traffic with Route 53 and CloudFront89## When to Use1011- Attach a custom domain to a CloudFront distribution and route it through Route 53.12- Coordinate ACM validation, CloudFront alternate domain names, and alias A/AAAA records.13- Plan a low-risk DNS cutover or diagnose the Route 53-to-CloudFront boundary.1415Do not use this skill for CloudFront caching/origin work without DNS changes; use16[cloudfront](https://github.com/mouadja02/skills/blob/main/skills/cloud-aws/networking/cloudfront/SKILL.md). Do not use it for Route 53 records targeting non-CloudFront17endpoints; use [route53](https://github.com/mouadja02/skills/blob/main/skills/cloud-aws/networking/route53/SKILL.md).1819## Prerequisites and Quick Reference2021- Capture the account, public hosted-zone ID, FQDN, distribution ID/domain, current DNS answers and22 TTLs, certificate ARN/status, and rollback target.23- Confirm the ACM certificate is in `us-east-1`, covers the FQDN, and is issued before DNS cutover.24- Confirm the distribution is deployed and lists the FQDN as an alternate domain name.25- Prefer alias A and AAAA records for Route 53-hosted domains; retain the change ID and prior records.2627## Overview2829Domain expertise for configuring Amazon Route 53 to route traffic to Amazon CloudFront distributions using custom domain names. Covers hosted zone management, alias A/AAAA records, alternate domain name (CNAME) configuration, and ACM certificate setup for HTTPS.3031## Configure Route 53 to route traffic to a CloudFront distribution3233To set up a custom domain for a CloudFront distribution with Route 53 DNS, follow the procedure exactly.34See [Route 53 CloudFront routing procedure](references/route53-cloudfront-routing.md).3536The procedure covers:3738- Verifying CloudFront distribution status and CNAME configuration39- Requesting and validating ACM certificates (must be in us-east-1)40- Creating or locating public hosted zones41- Creating alias A and AAAA records pointing to CloudFront42- Monitoring DNS propagation4344## Verification and Recovery45461. Before cutover, verify the certificate and distribution readiness checks above. Do not create the47 alias first and hope the distribution converges later.482. After the change reports `INSYNC`, query authoritative name servers for A and AAAA, then make an49 HTTPS request using the custom hostname. Assert the certificate hostname, expected distribution50 response, and an application-specific body/header condition.513. Confirm direct origin access remains blocked when origin protection is expected.524. If any assertion fails, stop, restore the captured prior A/AAAA records, wait for that change to53 become `INSYNC`, and repeat DNS and HTTPS checks. Preserve the failed change ID and observations.5455## Evaluation Prompts5657- **Normal:** “Route `www.example.com` to an existing CloudFront distribution with A/AAAA aliases.”58- **Difficult edge:** “Cut over the zone apex with low risk when an old CNAME-like target is cached and59 IPv6 clients must work.”60- **Should not activate:** “Create latency-based Route 53 records for two API Gateway endpoints.”6162## Source Boundary6364The certificate-region, alternate-domain, and Route 53 alias requirements are sourced from the AWS65documentation below and the imported Apache-2.0 upstream. The readiness gate, evidence capture,66application assertion, and rollback sequence are curator recommendations.6768## Additional Resources6970- [Routing traffic to a CloudFront distribution](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html)71- [CloudFront alternate domain names](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html)7273## Troubleshooting7475### Domain not in CloudFront CNAMEs7677Add the domain as an alternate domain name in the CloudFront distribution configuration before creating Route 53 records.7879### SSL certificate issues8081ACM certificates for CloudFront must be in us-east-1. Ensure the certificate is validated and associated with the distribution.8283### Private hosted zone8485CloudFront only works with public hosted zones. Create a public hosted zone if only a private one exists.8687### DNS propagation delays8889Changes typically propagate within 60 seconds but full global propagation can take up to 48 hours. Use `nslookup` or `dig` to verify.