Edge and DNS outside AWS: a third-party CDN or DNS in front of AWS origins
When DNS or the CDN layer lives outside AWS (Cloudflare as the example) and the origin is an ALB, CloudFront or S3 — what changes at the apex (CNAME flattening instead of Route 53 alias), what CloudFront-only protections stop applying (origin-facing prefix list, OAC, VPC origins), certificate and Host-header rules, and the failures each mismatch causes.
markdownpatternv4B5CE-1CN1stage: buildtrust: officialtrust: fieldservice: cloudfrontservice: route53service: elbservice: external-edgeinterface: anyCloudflare in front of AWSexternal DNS AWSCNAME flatteningapex domain ALBRoute 53 alias alternativethird-party CDN ALB originCloudflare S3 originCloudFront vs CloudflareACM DNS validation external DNSError 1014origin protection without CloudFront
Edge and DNS outside AWS
Moving DNS or the CDN off AWS works, but you lose the AWS-only joins. Route 53 alias records, CloudFront's origin-facing prefix list, OAC for private S3 buckets, and VPC origins for private load balancers all disappear. Replace each one deliberately, or keep that layer on AWS.
External DNS, AWS endpoints
| Need | With Route 53 | With an external DNS provider |
|---|---|---|
Apex (example.com) → ALB or CloudFront | Alias A/AAAA record: free queries, follows the target's IPs | A CNAME at the apex isn't allowed in plain DNS. Use the provider's flattening (Cloudflare returns the target's IPs in place of the CNAME), or an ALIAS/ANAME-style record. Never hard-code an ALB's IPs, because they change |
www → ALB or CloudFront | Alias or CNAME | CNAME to the ALB or distribution DNS name |
| ACM certificate validation | One-click "Create records in Route 53" | Add the _x… CNAME by hand. Watch for providers that append the domain (…example.com.example.com.). Validation times out after 72 hours |
| Health-checked failover | Route 53 health checks + failover records | The provider's equivalent, if any |
Flattening caveats from Cloudflare's documentation: some third-party domain-verification checks fail because the CNAME itself isn't returned; a target with no A/AAAA records yields an empty answer; and a CNAME to another Cloudflare account returns Error 1014.
Moving DNS hosting means changing the registrar's name servers. Resolvers cache them for 24–48 hours (guides/route53/point-domain-at-aws.md).
Third-party CDN in front of AWS origins
| Origin | What changes without CloudFront | Do instead |
|---|---|---|
| ALB | CloudFront's prefix list com.amazonaws.global.cloudfront.origin-facing covers only CloudFront's ranges, and VPC origins (private ALBs) are a CloudFront feature | The ALB must be internet-facing. Restrict its security group to the CDN's published IP ranges, if it publishes them, and add an origin secret header checked by the app or WAF (UNVERIFIED common practice) |
| Private S3 bucket | OAC signing is CloudFront-only, so another CDN can't read a private bucket with an OAC-style grant | Make objects public (lose privacy), use the CDN's own signed-origin feature if it has one (provider-specific), or keep CloudFront for S3 |
| S3 website endpoint | HTTP only, public bucket required, as for CloudFront | Same constraints |
| CloudFront itself | Placing another CDN in front of CloudFront | Possible as a custom origin. But two AWS distributions chained ("stacked distributions") return 403; avoid CDN-on-CDN where possible |
TLS and Host headers
- The CDN connects to the ALB by its DNS name or your custom name. The ALB's certificate must cover the name the CDN sends as SNI and
Host. The ALB's default…amazonaws.comname can't be on a public certificate, so use a custom origin hostname with an ACM certificate. - Health checks and ALB routing see the CDN's
Hostheader. Host-based listener rules must match what the CDN forwards.
When to keep CloudFront anyway
- A private S3 bucket (OAC) or a private ALB/NLB/EC2 origin (VPC origins, dual-stack and WebSockets supported in 2026).
- AWS WAF on CloudFront, one AWS bill, and IAM-controlled configuration as code.
- Certificates managed in ACM (us-east-1) and alias records at the apex.
When an outside CDN or DNS is the better fit
- The organization already runs its DNS or edge security on another provider and wants one control plane across clouds.
- Origins span several clouds.
Comparative price and performance aren't evaluated here. Fastly, Akamai and others are named in the overview only.
Known-bad
| Configuration | Symptom |
|---|---|
| External DNS: apex CNAME without flattening support | Provider rejects the record, or apex doesn't resolve |
| A records with an ALB's current IPs | Works until the ALB's IPs change, then the site breaks |
| External CDN → ALB origin using the ALB's default DNS name over HTTPS | TLS name mismatch at the CDN (no public certificate exists for that name) |
| External CDN → private S3 bucket | 403: no OAC outside CloudFront |
| ALB security group still restricted to the CloudFront prefix list after moving to another CDN | Timeouts at the CDN (equivalent of CloudFront's 504) |
| ACM validation CNAME deleted during a DNS migration | Certificates stop renewing automatically |