Route 53: Production Domain

Concept

Your load balancer (an ALB, Application Load Balancer, is an AWS service that shares incoming web requests between several servers) answers at a name like myapp-alb-1234567890.ap-south-1.elb.amazonaws.com. Your CDN (CloudFront is the AWS content delivery network, a service that keeps copies of your files on servers around the world) answers at d1234abcd.cloudfront.net. No customer will ever type either name. This lesson connects your real domain to them with Route 53, the AWS DNS service. DNS (Domain Name System) is the system that turns a name such as yourapp.com into the IP address of a server. We also add features for production: routing that checks health, private internal names, email records, and a way to move a live domain without anyone noticing.

What Lesson 3 gave you, and what is new here

If any of these words feels unclear, read Lesson 3: DNS Deep Dive: From Domain Name to Server again first. This lesson builds on it:

• Hosted zone: the container for all the DNS records of one domain. You already created one and pointed your registrar's nameservers at it. (The registrar is the company where you bought the domain.)
• Records are the entries in a zone. An A record points a name to an IP address. A CNAME record points a name to another name. An MX record says where to deliver mail. A TXT record holds free text, often used as a proof. An NS record says which servers hold the zone. TTL (time to live) is how many seconds an answer may be saved (cached).
• Wildcard record: *.yourapp.com answers for any subdomain, so each customer (tenant) can have one.

New in this lesson:

Alias records — the AWS-only record type

A load balancer's address is a name, so the obvious record is a CNAME: yourapp.com → myapp-alb-….elb.amazonaws.com. But DNS has a strict rule: a CNAME cannot exist next to any other record with the same name. The bare domain (also called the “apex”, yourapp.com) always has other records. It must have an SOA record (basic facts about the zone) and NS records, and it usually has MX too. So the bare domain cannot be a CNAME.

Route 53 solves this with the Alias record. To the outside world it looks like an A record (or an AAAA record, which is the same thing for IPv6 addresses, the newer, longer kind). But Route 53 works it out inside, and it returns the current IP addresses of the AWS resource that it names.

Point the domain at the ALB and CloudFront

This is what we connect: yourapp.com and *.yourapp.com go to the ALB (the app). assets.yourapp.com goes to CloudFront (Lesson 11).

1. Create three alias records

   Go to Route 53 → your hosted zone → Create record. For each record, turn on Alias and pick the target from the dropdown list. The console fills in the target's address and its hosted-zone ID for you.

   Record name	Type	Alias to	Evaluate target health
   yourapp.com	A	Application Load Balancer → myapp-alb	Yes
   *.yourapp.com	A	Application Load Balancer → myapp-alb	Yes
   assets.yourapp.com	A	CloudFront distribution (Lesson 11)	No

   • The wildcard record does not cover the bare domain, so you create both records.
   • All CloudFront distributions use the same fixed hosted-zone ID. The ID of an ALB is different in each region. So it is better to pick from the dropdown list than to type it.
   • A change goes from PENDING to INSYNC on all Route 53 servers, usually within a minute.

2. Check it from the outside

   VerifyCopy all

   • dig +short acme.yourapp.comCopy

     dig is a command-line tool that asks DNS servers questions. Any subdomain should answer through the wildcard with the ALB's IPs. There are several, one per AZ. You never type them, because they can change

   • curl -sI https://yourapp.comCopy

     You should see HTTP/2 200 and a valid certificate. The answer comes from your Auto Scaling group through the ALB

3. Redirect www to the bare domain (or the reverse)

   Create www as an alias to the ALB as well. Then add one rule on the ALB's HTTPS listener. The rule says: if the host header is www.yourapp.com, redirect (301) to https://yourapp.comand keep the path and query. Search engines treat the two names as separate sites, so pick one as the official name.

Routing policies: simple, weighted, latency, failover

A normal record always gives the same answer. Route 53 can choose the answer depending on conditions. You choose a routing policy for each record.

Weighted routing — the safest way to migrate

Say you have an old setup (the app on Vercel) and a new one (the ALB). Instead of moving everyone at once, create two records with the same name. Give each one its own record ID (the API calls it SetIdentifier) and a weight. Traffic is split in that ratio:

Start at 10. Watch the error rate and the delay for an hour. Then go to 50, then 100, and then remove the old record. If anything looks wrong, set the weight to 0. A rollback takes as long as your TTL. This is the DNS version of a canary release (a small group of users tries the new version first).

Health checks and DNS failover

A Route 53 health check is a robot that runs outside your VPC, in several AWS locations. It requests a URL every 10 or 30 seconds. If enough of these robots see failures, the check turns unhealthy. Any record that is tied to it is then removed from the answers. Your endpoint must be reachable from the internet for this to work.

Create one in Route 53 → Health checks. Use HTTPS, yourapp.com, the path /api/health, an interval of 30 seconds, and unhealthy after 3 failures. Then attach it to a record.

Failover routing uses the health check. You make two records. One is marked PRIMARY (with the health check) and one is marked SECONDARY. While the primary is healthy, everyone gets it. When it fails, DNS switches to the secondary. A common cheap secondary is a simple “we'll be right back” page in S3 (the AWS file storage service) behind CloudFront. The site shows a simple page instead of failing completely, and it costs very little.

Private hosted zones — names that only exist inside the VPC

A private hosted zone is a zone that is attached to a VPC. Its records answer only to resources inside that VPC, and the internet cannot see them. It solves a problem from Lesson 8. The RDS hostname (myapp-db.abc123xyz.ap-south-1.rds.amazonaws.com) is pasted into .env and SSM. When you restore a snapshot or the database fails over, the hostname changes, and you must edit every config.

The fix is to give the database a name that you control.

Create a private hosted zone internal.yourapp.com and attach it to the myapp VPC. Add one CNAME in it: db.internal.yourapp.com points to the RDS endpoint, with a TTL of 60. The app's connection string now uses @db.internal.yourapp.com:5432.

Do you restore a snapshot? Update one record instead of the config of every server. The VPC needs the settings enableDnsHostnames and enableDnsSupport (we set the first one in Lesson 6). There is one catch. The RDS certificate contains the AWS hostname, not your custom name. If your database driver checks that the name matches, the check fails. With sslmode=require the traffic is still encrypted, but the name is not checked. Or you can give the driver the AWS name as the TLS server name.

Email records: MX, SPF, DKIM, DMARC

When your domain sends email (welcome messages, password resets), DNS decides whether the mail reaches the inbox or the spam folder. The MX record says where to deliver mail that is sent to you. Three more records prove that mail that claims to come from yourapp.com is real. SPF is a record that lists the servers allowed to send mail for your domain. DKIM is a record that holds a public key, so receivers can check that a message was signed by you. DMARC is a record that tells receivers what to do with mail that fails SPF or DKIM. Amazon SES is the AWS service for sending email:

Moving a live domain without downtime

Here is the situation. The site runs on Vercel (or an old host) and you are moving it to this AWS setup. DNS is where downtime can sneak in, because old answers stay in caches. A runbook (a list of steps to follow) for this move looks like this:

1. Two days before: copy everything and lower the TTL

   Export the existing zone. Recreate every record type in the Route 53 hosted zone: MX, TXT, and verification CNAMEs, not only the A record. Then lower the TTL of the records that will change to 60 seconds. Wait at least as long as the old TTL, so that the change reaches everywhere. This one step makes the switch fast and easy to undo.

2. Test the new setup for real before anyone is sent to it

   Bypass DNS and talk to the ALB directlyCopy all

   • curl -sI --resolve yourapp.com:443:<ALB-IP> https://yourapp.com/Copy

     Sends the request for yourapp.com to one of the ALB's IPs, and the certificate still checks out. Test login, uploads and every important page. No DNS change is needed

3. Cut over — weighted first if you can

   Change the nameservers at the registrar to the four Route 53 NS values only if the zone is completely ready. If it is not, change only the records. Use the weighted move from above (10, then 50, then 100), or switch the record at a quiet hour.

4. Watch, keep the old stack, then raise the TTL

   Keep the old host running for at least the old TTL plus one day. Users behind resolvers with old saved answers still reach it. Watch the 5xx rate and the delay on the ALB. When all is stable, raise the TTL again to 300–3600 seconds. This lowers query costs and speeds up lookups. Only then turn off the old setup.

Protecting the domain itself

A perfect setup is worth nothing if someone else controls the domain. Real incidents come from the boring parts:

• Expiry. Turn on auto-renew and keep a valid payment method. Companies have lost domains because a card expired. Also put the expiry date in a calendar.
• Security of the registrar account. The account that owns the domain has the highest power. Use MFA (a second login step, such as a code from an app). Use a shared team mailbox, not one person's address, as the contact. Do not reuse passwords. Whoever controls this account controls all your DNS.
• Domain lock and privacy. Turn on the transfer lock, which stops anyone from moving the domain away. WHOIS privacy hides your personal details from the public registration database. Route 53 Domains includes it for free on most TLDs (a TLD is the ending, such as .com).
• Dangling records. A dangling record points to something that no longer exists. For example, it may point to an S3 bucket, an ELB or a third-party service that you deleted. Someone else can claim that name and take over your subdomain. This is called a “subdomain takeover”. Delete the DNS record when you delete the resource behind it.
• CAA record. This is a short record that limits which certificate authorities (the companies that issue certificates) may issue certificates for your domain. Examples: 0 issue "amazon.com" and 0 issue "letsencrypt.org".
• DNSSEC adds digital signatures to your DNS answers, so nobody can fake them. Route 53 supports it. But it adds risk: one mistake with a key can make the domain stop working. Turn it on on purpose, after you understand it. Do not turn it on just because it exists.

What this costs

The whole DNS part of this project costs roughly $1–3 a month plus the domain fee. It is the cheapest part of the setup, and it gives you a lot of control.

Troubleshooting table

Two lookups that solve most DNS problems

Use these together with dig +trace and a question to a public resolver (Lesson 3). They solve almost every DNS problem.

Interview corner

Practice task before Lesson 14

1. Create alias records for the apex, * and www pointing at the ALB, and assets pointing at CloudFront. Verify each with dig and curl.
2. Add the ALB rule that redirects www to the bare domain and confirm the 301 with curl -I.
3. Create two weighted records for a test subdomain (canary.yourapp.com). Point one to the ALB and one to a plain IP, with weights 50/50. Look it up many times in a row and watch the split (and the caching).
4. Create a Route 53 health check on /api/health. Stop the app on every server (or temporarily change the target group path), and watch the health check turn unhealthy in the console.
5. Create the private hosted zone, add db.internal.yourapp.com, and from an EC2 server run dig +short db.internal.yourapp.com. From your laptop the same command should return nothing.
6. Write down the cutover runbook for your own domain in six bullet points. Include the TTL you would set and when.

Conclusion

Route 53 is where the long AWS names become your own brand. It also gives you safe tools for changing things in production.

• Alias records for anything in AWS, including the bare domain, where a CNAME is not allowed.
• Routing policies turn DNS into a traffic tool: weighted records for step by step moves, failover for outages of a whole site.
• Private zones give internal resources names that stay the same after restores and failovers.
• Email needs its own records (MX, SPF, DKIM, DMARC), and every record type must move with the zone.
• TTL is your rollback speed. Keep it low around changes and high the rest of the time. Test with --resolve before you switch.

The whole setup is now live on your own domain. But you built it by hand, and you deploy by logging in over SSH. Now it is time to automate the release with CI/CD.

End of Lesson 13. Next: Lesson 14 — CI/CD with GitHub Actions.