Pointing a custom domain to an AWS-hosted web application sounds simple until you hit an SSL error, a stuck DNS validation, or a CloudFront distribution that refuses to serve your site over HTTPS. In this walkthrough, we go beyond the standard Amplify tutorial and show you the full production-ready path to connect a custom domain to AWS using Route 53, AWS Certificate Manager (ACM), and CloudFront, while avoiding the misconfigurations that trip up most developers.
Why Route 53 Is the Right Choice for AWS-Hosted Apps
You can technically use any DNS provider (GoDaddy, Cloudflare, Namecheap) to point a domain to an AWS resource, but Route 53 offers native integration that removes friction:
- Alias records that map directly to AWS resources (CloudFront, ALB, S3, API Gateway) without extra latency.
- Automatic DNS validation for ACM certificates in one click.
- Health checks and failover routing built in.
- Faster propagation because AWS controls the authoritative nameservers.

Architecture Overview
Before touching the console, understand what you are building. A typical AWS-hosted web app with a custom domain looks like this:
| Layer | Service | Role |
|---|---|---|
| Domain registration | Route 53 or third-party registrar | Owns the domain name |
| DNS | Route 53 Hosted Zone | Resolves domain to AWS resources |
| SSL/TLS | AWS Certificate Manager (ACM) | Issues free public certificates |
| CDN / HTTPS termination | CloudFront | Serves the app globally over HTTPS |
| Origin | S3, ALB, Amplify, EC2, API Gateway | Hosts the application |
Step 1: Create a Route 53 Hosted Zone
- Open the Route 53 console and choose Hosted zones.
- Click Create hosted zone, enter your domain (for example
pixelseed.net), and select Public hosted zone. - Route 53 generates four NS records. Copy them.
- If your domain is registered outside AWS, log in to your registrar and replace the existing nameservers with those four NS values.
Common mistake: Leaving the old nameservers active. Some registrars display them alongside new ones. Remove them completely, otherwise DNS queries will bounce between providers and cause intermittent failures.

Step 2: Request an SSL Certificate in ACM
To serve your app over HTTPS, you need a certificate issued by ACM. The critical detail most tutorials miss:
If you plan to use CloudFront, request the certificate in the us-east-1 (N. Virginia) region. CloudFront only accepts ACM certificates from that region. For ALB or API Gateway regional endpoints, use the region where the resource lives.
- Go to ACM in the correct region.
- Click Request certificate and choose Public certificate.
- Add both the apex (
pixelseed.net) and the wildcard (*.pixelseed.net) so you can cover subdomains later. - Choose DNS validation.
- Once issued (usually within minutes), click Create records in Route 53. ACM will automatically add the CNAME validation records.
Why DNS validation over email validation?
- Auto-renews as long as the DNS record stays in place.
- No dependency on WHOIS contact emails.
- Works with automation (Terraform, CloudFormation, CDK).
Step 3: Set Up a CloudFront Distribution
CloudFront is where HTTPS termination happens and where most misconfigurations occur.
- Open the CloudFront console and create a new distribution.
- Set the origin to your S3 bucket, ALB, Amplify app, or API Gateway endpoint.
- Under Viewer protocol policy, choose Redirect HTTP to HTTPS.
- In Alternate domain names (CNAMEs), add
pixelseed.netandwww.pixelseed.net. - Attach the ACM certificate you created earlier.
- Set the Security policy to TLSv1.2_2021 or newer.
- Deploy. Note the CloudFront domain name (something like
d1234abcd.cloudfront.net).
Watch out for these CloudFront traps
- Missing CNAME entry: If your custom domain is not listed in Alternate domain names, CloudFront will serve its default certificate and browsers will throw
SSL_ERROR_BAD_CERT_DOMAIN. - Wrong certificate region: The dropdown will be empty if the certificate is not in us-east-1.
- S3 origin permissions: Use Origin Access Control (OAC) instead of the deprecated OAI. OAC is now the AWS default and supports SSE-KMS.

Step 4: Create Route 53 Alias Records
Now connect the domain to CloudFront.
- Go back to your Route 53 hosted zone.
- Create a new record for the apex domain:
- Record name: leave blank (apex)
- Record type: A
- Toggle Alias on
- Route traffic to: Alias to CloudFront distribution, then pick your distribution
- Repeat for
wwwsubdomain, or create a redirect. - Optionally add an AAAA alias record for IPv6.
Why alias, not CNAME? CNAME records are not allowed at the apex of a domain per DNS specs. Route 53 alias records are AWS-specific and solve this while remaining free of extra query charges.
Step 5: Verify and Troubleshoot
After saving, propagation is usually under five minutes with Route 53, though browsers and OS caches can hold old records for longer. Use these checks:
dig pixelseed.netornslookup pixelseed.netto confirm the CloudFront target.- Open your domain in a private window to bypass local DNS caches.
- Use SSL Labs to validate the certificate chain.
- Check CloudFront Invalidations if content looks stale.

Common Misconfigurations That Break HTTPS
| Symptom | Likely cause | Fix |
|---|---|---|
| Certificate stuck in Pending validation | CNAME validation record missing or in wrong zone | Re-create the record via ACM console |
| Browser shows CloudFront default cert | Custom CNAME not added to distribution | Edit distribution, add alternate domain name |
| 522 or 504 errors | Origin security group blocks CloudFront | Whitelist CloudFront prefix list com.amazonaws.global.cloudfront.origin-facing |
| Slow DNS propagation | Old nameservers still active at registrar | Remove legacy NS entries completely |
| Mixed content warnings | App loads assets over HTTP | Force HTTPS at app level and in CloudFront |
Bonus: Automate the Whole Stack with Terraform
If you deploy multiple projects, click-ops does not scale. A minimal Terraform module can provision the hosted zone, ACM certificate, CloudFront distribution, and alias records in one apply. This also ensures reproducibility across staging and production environments, and it plays nicely with CI/CD pipelines.
FAQ
Can I connect a custom domain to AWS if my domain is registered at GoDaddy or Namecheap?
Yes. You have two options: either change the registrar nameservers to point to a Route 53 hosted zone, or keep DNS at the registrar and add the CNAME/A records manually. The Route 53 route is cleaner for alias records at the apex.
How long does DNS propagation take with Route 53?
Route 53 records typically propagate within 60 seconds globally. Delays usually come from client-side caches or from registrar nameserver changes, which can take up to 48 hours in rare cases.
Do I need CloudFront if I use AWS Amplify Hosting?
No. Amplify provisions CloudFront and ACM for you. The steps above apply when you host on S3, EC2, ECS, or a Lambda-backed API Gateway where you manage the CDN layer yourself.
Is the ACM certificate really free?
Yes, public ACM certificates are free as long as they are used with an AWS service (CloudFront, ALB, API Gateway, App Runner). You only pay for the underlying resource.
Can I use one certificate for multiple domains?
Yes. Add multiple Subject Alternative Names (SANs) or use a wildcard like *.pixelseed.net. A single ACM certificate can cover up to 10 domains by default, extendable via a support request.
Wrapping Up
Connecting a custom domain to AWS is straightforward once you understand the interplay between Route 53, ACM, and CloudFront. Get the region right for ACM, use alias records at the apex, and always verify the certificate is attached to your distribution before pointing DNS. Follow this order and you will avoid the two most painful bugs in AWS hosting: broken HTTPS and unpredictable propagation.
Need help architecting a scalable AWS setup for your web app? Get in touch with the Pixelseed team. We ship production-ready cloud infrastructure every day.