*Configuring a Weighted Routing Policy in Route 53

Summary

In this lab I used a weighted routing policy in Amazon Route 53 to share traffic between two EC2 web servers running in different Availability Zones. I created two A records with the same name, learn.sakibs-domain.com, each pointing to one server's public IP and each given a weight of 50. Route 53 then answered lookups for that name with one IP or the other, in proportion to the weights. I didn't own a registered domain, so I verified the distribution by querying the hosted zone's own name server many times and counting how often each IP came back. Finally, I reviewed how health checks let Route 53 stop sending traffic to a server that goes down.

Lab Environment

Weighted records:

Part 1: Preparing the Web Servers

1. Launched two web servers

I followed Parts 1 and 2 of the Route 53 record types lab twice, launching two Amazon Linux instances in the default VPC, each running Apache with the same web page:

Putting them in different Availability Zones meant that a problem in one AZ wouldn't take down both servers, which is the point of spreading traffic across them.

Both used a security group allowing SSH (22) for setup and HTTP (80) for the website.

2. Verified both servers

I opened http://WEB_SERVER_1_PUBLIC_IP and http://WEB_SERVER_2_PUBLIC_IP in my browser, and both showed the same page. I noted each server's public IPv4 address for the DNS records.

3. Removed the old learn record

The learn A record from the record types lab used the simple routing policy. Route 53 doesn't allow a simple record and weighted records with the same name and type at the same time, so I deleted the old learn A record from the hosted zone first. I also deleted the test CNAME, since it pointed to learn and wasn't part of this lab.

Part 2: Creating the First Weighted Record

In the Route 53 console, I opened the sakibs-domain.com hosted zone, clicked Create record, and entered:

I clicked Create records.

• The weight is a number from 0 to 255 that controls how often this record's answer is returned compared with other records of the same name.
• The record ID is a label that tells apart records sharing the same name and type. It has to be unique among them.
• I lowered the TTL to 60 seconds, so changes to the weights would take effect faster during testing.

Part 3: Creating the Second Weighted Record

I clicked Create record again and entered:

I clicked Create records. The hosted zone now listed two A records named learn.sakibs-domain.com, one with record ID record-1 and one with record-2.

Normally, a name can only have one record of each type. Routing policies like weighted are the exception: they allow several records with the same name and type, and Route 53 chooses between them for each lookup.

Part 4: Testing the Weighted Routing Policy

1. Test record in the console

In the hosted zone, I clicked Test record, entered learn as the record name and A as the type, and clicked Get response several times. The returned IP switched between Web-Server-1 and Web-Server-2, rather than always being the same.

2. nslookup against the name server

From PowerShell on my computer, I asked the hosted zone's name server directly:

nslookup learn.sakibs-domain.com ns-315.awsdns-39.com

Running it several times returned one IP or the other each time.

Each lookup returns only one of the two IPs. Route 53 picks which one for each query, based on the weights.

Part 5: Measuring the Weight Distribution

1. Ran many lookups at once

To see the pattern, I ran 20 lookups in a row in PowerShell and counted how often each IP came back:

1..20 | ForEach-Object {
  (Resolve-DnsName learn.sakibs-domain.com -Server ns-315.awsdns-39.com -Type A).IPAddress
} | Group-Object | Select-Object Count, Name

With both weights at 50, each IP came back roughly half the time. The split wasn't exactly 10 and 10, because Route 53 chooses randomly for each query according to the weights. Over many queries, the counts get closer to the expected percentages.

2. Calculated the expected traffic share

Route 53 calculates each record's share of traffic like this:

Traffic percentage = (record's weight ÷ total of all weights) × 100

The weights don't need to add up to 100. Only their proportions matter, so 1 and 1 behaves exactly like 50 and 50.

A weight of 0 means Route 53 never returns that record, unless every record with that name has a weight of 0, in which case they're all returned equally. Setting a weight to 0 is a quick way to take a server out of rotation without deleting its record.

3. Why querying the name server mattered

The original lab used Google's public resolver (8.8.8.8) for this test, which requires a registered domain. Querying the hosted zone's own name server had an extra advantage: it skipped caching. A resolver like 8.8.8.8 remembers an answer for the record's TTL, so repeated lookups through it can keep returning the same IP even though Route 53 would choose differently. Asking ns-315.awsdns-39.com directly gave a fresh choice on every query.

Part 6: Understanding Route 53 Health Checks

So far, Route 53 had no idea whether either server was actually working. If Web-Server-2 crashed, Route 53 would keep returning its IP for about half of all lookups, and those users would get an error.

A health check solves this:

1. Route 53 sends a request to the server from locations around the world every 10 or 30 seconds, for example an HTTP request to port 80.
2. If enough checks fail in a row, Route 53 marks the server unhealthy.
3. When a weighted record is linked to a health check, Route 53 stops returning that record's IP while it's unhealthy, and sends all traffic to the remaining healthy records.
4. When the server passes its checks again, Route 53 brings it back and resumes splitting traffic by the configured weights.

To set this up, I would create a health check under Route 53 → Health checks for each server's IP on HTTP port 80, then select it in each weighted record's Health check ID setting.

What I Learned

• A weighted routing policy lets several records share the same name and type, and Route 53 picks one for each lookup in proportion to their weights.
• Each weighted record needs a unique record ID to tell it apart from the others with the same name.
• Each record's share of traffic is its weight divided by the total weight. Weights only matter relative to each other.
• A weight of 0 takes a record out of rotation without deleting it.
• The split is random per query, so it only matches the percentages closely over many lookups.
• Caching by resolvers can hide the distribution, because a cached answer is reused for the TTL. A low TTL and querying the authoritative name server make testing clearer.
• A simple record and weighted records can't share the same name and type.
• Common uses for weighted routing:
• Load sharing between servers or regions
• Canary releases, sending a small share of traffic, like 5%, to a new version before switching everyone over
• Blue/green deployments, shifting traffic gradually from the old environment to the new one
• Without health checks, weighted routing keeps sending traffic to a server even if it's down. Health checks let Route 53 route only to healthy servers.
• DNS-based routing works at the lookup level, not per request. A user's browser keeps using the IP it received until the cached answer expires, so this isn't as precise as a load balancer, which spreads every individual request.

Cleanup

Both instances and their public IPv4 addresses were billed by the hour, so I deleted everything from this lab:

1. Deleted the weighted records

In the sakibs-domain.com hosted zone, I selected both learn A records (record-1 and record-2), clicked Delete records, and confirmed.

2. Terminated the instances

In the EC2 console, I selected Web-Server-1 and Web-Server-2 and clicked Instance state → Terminate (delete) instance. This also deleted their root volumes and released their public IPs.

3. Deleted the security group

Once both instances showed Terminated, I deleted the security group they had used.

4. Deleted the hosted zone (when finished with Route 53 labs)

With only the NS and SOA records left, the hosted zone could be deleted from Hosted zones → Delete. A hosted zone is billed monthly unless it's deleted within 12 hours of being created, so I deleted it once I was done with the Route 53 labs rather than leaving it in my account.