Route Traffic with Route 53

You’ve built your web server, deployed it on EC2, and hardened it with security groups — but what happens when users type your domain name and get a connection refused because nothing is translating that friendly URL to your instance’s IP address? That gap is exactly what Route 53 solves. In this lesson, you’ll learn how to route traffic to a web server with Route 53, turning a raw IP into a reliable, human-friendly endpoint that can scale with your infrastructure.

The problem this lesson solves

Imagine you’ve just launched an EC2 instance running a simple web server on port 80. You’ve tested it with curl http://54.213.45.67 and it works perfectly. But now you need to share it with the world — or with a client. Asking them to type an IP address is ugly, hard to remember, and breaks the moment you replace that instance. Worse, IP addresses change when you stop and start instances, so any hardcoded reference becomes stale.

You need a DNS (Domain Name System) service that maps your domain name, like app.example.com, to your web server’s IP address. Route 53 is AWS’s managed DNS service, and it does exactly that — routing user requests to your web server reliably, with low latency and high availability.

But DNS is more than just a phonebook. Route 53 supports multiple routing policies, health checks, and integration with other AWS services, making it the glue that connects your domain to your infrastructure. In this tutorial, you’ll configure a hosted zone, create a record set, and route traffic to your EC2 web server.

Core concept / mental model

Think of DNS as the phonebook of the internet. When a user types app.example.com, their browser asks a DNS resolver, “What’s the IP address?” The resolver walks through a chain (root → TLD → your hosted zone) until it finds an A record that answers with an IP like 54.213.45.67. The browser then connects to that IP — your web server.

Route 53 is AWS’s authoritative DNS. You create a hosted zone for your domain (e.g., example.com), which becomes the source of truth for all DNS records under that domain. Then you add records to define how traffic is routed — for example, an A record that points app.example.com to your EC2 instance’s IP.

Pro tip: Route 53 isn’t just for public domains. You can use private hosted zones for internal service discovery, cutting out the public internet entirely.

Key components you’ll work with: - Hosted zone: A container for all DNS records of a domain. - Record set: A single DNS mapping, like app.example.com → 54.213.45.67 (A record). - TTL (Time to Live): How long resolvers cache your record before re-querying. - Routing policy: How Route 53 responds to queries — simple, weighted, latency-based, etc.

How it works step by step

The flow of routing traffic to your web server looks like this:

1. Create or register a domain (or use an existing one). For this lesson, we’ll assume you have a domain you control, e.g., example.com.
2. Create a hosted zone in Route 53 for example.com. This generates four name server (NS) records that you must add to your domain registrar.
3. Update your registrar’s NS records to point to the Route 53 nameservers. This tells the internet that Route 53 is authoritative for your domain.
4. Create an A record in the hosted zone to map app.example.com (or the apex) to your web server’s IP address.
5. Test the setup by resolving the domain and hitting the web server.

Each step builds on the previous one. If you skip the NS update, your hosted zone exists but nobody can find it — the phonebook is written but the phone number is silent.

Hands-on walkthrough

Let’s walk through the complete process using the AWS Console (you can also use CLI commands). We’ll assume you already have an EC2 instance running a web server, and you have a domain you control.

Step 1: Get your EC2 instance’s IP

First, grab the public IPv4 address of your instance from the EC2 console. In this example, we’ll use 54.213.45.67.

Step 2: Create a hosted zone

In the Route 53 console:

1. Go to Hosted zones.
2. Click Create hosted zone.
3. Enter example.com as the domain name.
4. Choose Public hosted zone (since we’re routing public traffic).
5. Click Create.

You’ll see a Zone ID and four NS records like ns-1234.awsdns-01.org. Save these — you’ll need them in Step 3.

Step 3: Update your registrar’s nameservers

At your domain registrar (e.g., GoDaddy, Namecheap, or AWS Registrar), find the DNS management settings and replace the existing nameservers with the four NS records from Route 53.

Pro tip: DNS propagation can take anywhere from minutes to 48 hours. For testing, you can bypass DNS by using dig against the Route 53 nameservers directly.

Step 4: Create an A record

Now add the record that routes traffic:

1. Select your hosted zone, click Create record.
2. Record name: app (this becomes app.example.com).
3. Record type: A.
4. Value: 54.213.45.67 (your EC2 public IP).
5. TTL: 300 (5 minutes is a good default).
6. Routing policy: Simple (more on this later).
7. Click Create records.

Step 5: Test

Wait a few minutes for DNS propagation, then test from your terminal:

dig app.example.com

You should see an answer section containing 54.213.45.67.

Then test with curl:

curl http://app.example.com

If your web server is running, you’ll get the HTML response. Let’s confirm with a simple example:

$ curl -v http://app.example.com 2>&1 | grep '< HTTP'
< HTTP/1.1 200 OK

Pro tip: If you get a Name or service not known error, the record hasn’t propagated yet — wait and retry, or query the Route 53 nameservers directly using dig app.example.com @ns-1234.awsdns-01.org.

Full CLI alternative

If you prefer the CLI, here’s a Python script using boto3 to do the same thing:

import boto3

# Create a client for Route 53
client = boto3.client('route53')

# Your parameters
hosted_zone_name = 'example.com'
ec2_public_ip = '54.213.45.67'

# Create hosted zone
response = client.create_hosted_zone(
    Name=hosted_zone_name,
    CallerReference='my-zone-2023',
)
hosted_zone_id = response['HostedZone']['Id']

# Create A record
client.change_resource_record_sets(
    HostedZoneId=hosted_zone_id,
    ChangeBatch={
        'Changes': [
            {
                'Action': 'CREATE',
                'ResourceRecordSet': {
                    'Name': 'app.' + hosted_zone_name,
                    'Type': 'A',
                    'TTL': 300,
                    'ResourceRecords': [{'Value': ec2_public_ip}]
                }
            }
        ]
    }
)

print(f"A record created pointing to {ec2_public_ip}")

Run it after installing boto3 and configuring credentials. Output:

A record created pointing to 54.213.45.67

Compare options / when to choose what

So far we used a simple A record, but Route 53 offers several routing policies. Here’s how to choose:

For a single web server, simple routing is perfect. As you scale, you can upgrade to weighted or latency-based policies — the record type stays the same, you just change the policy.

Pro tip: For a production website with multiple instances, consider using a Load Balancer and point your A record at its alias instead of a single IP. Route 53 integrates seamlessly with ALBs via alias records.

Troubleshooting & edge cases

Issue: Dig shows no answer

• Cause: DNS hasn’t propagated yet, or your registrar NS update failed.
• Fix: Re-check the NS records at your registrar. Use dig app.example.com @ns-1234.awsdns-01.org to test directly; if that works, propagation is just slow.

Issue: Curl returns connection refused

• Cause: Your EC2 instance’s security group doesn’t allow inbound traffic on port 80.
• Fix: Edit the security group to add a rule allowing HTTP from 0.0.0.0/0. Also ensure your web server is actually listening: sudo netstat -tulpn | grep :80.

Issue: You replaced your EC2 instance and the IP changed

• Cause: You didn’t assign an Elastic IP.
• Fix: Attach an Elastic IP to your instance, and keep your A record pointing to that static IP. Alternatively, switch to a CNAME to your instance’s public hostname (but watch out: CNAMEs don’t work at the zone apex).

Edge case: You’re using a subdomain from a parent domain

If you don’t own example.com but want to route traffic to yourname.example.com, you don’t need a hosted zone — just ask the owner to add a CNAME record pointing to your web server.

What you learned & what's next

You’ve successfully routed traffic to your web server with Route 53. You now understand the core DNS concepts: hosted zones, record sets, TTL, and routing policies. You can create an A record, update nameservers, and test the resolution. You can also troubleshoot common DNS and firewall issues.

What’s next? In the upcoming lesson, you’ll learn how to monitor your web server’s health with Route 53 health checks and automatically fail over to a backup instance — a crucial step toward building resilient infrastructure.

To reinforce this lesson, try the practice recap, then move on!