Intro / when to use weighted routing

Weighted routing lets you split traffic across multiple resources by assigning each record a numeric weight. Use it when you want:

• Gradual traffic shifts (canary / traffic shaping)

• Splitting load across regions or instance types for testing

• Simple A/B testing where you control the percentage of traffic sent to each backend

Weighted routing is not region-aware (use latency, geolocation, or geoproximity for region-based choices). It simply returns the configured records according to weight and health status. It somehow acts like a regional load balancer

Prerequisites

1. A hosted zone for your domain

open Route 53 → Hosted zones and pick your domain).

1. Two reachable endpoints for the demo:

2. US‑North‑California‑Server — IP: 13.56.59.133

1. US‑North‑Virginia‑Server — IP: 35.174.3.77

Console steps: Weighted Routing Policy

• Open your hosted zone and click "Create record".

• Choose record name (e.g., app). In my case, I used weighted.

• Type: A. Routing policy: Weighted.

For the California server record:

• Value: 13.56.59.133

• Weight: 30

• Record ID: You can add any name of your choice. I used North-California

• TTL: e.g., 60 seconds (shorter for test)

(Optional) Associate a health check so Route 53 can omit this endpoint if it fails.

Create a new record before saving the first one

Repeat for the Virginia server:

• Value: 35.174.3.77

• Weight: 70

• Record ID: North-Virginia

• TTL: same as above

• (Optional) Associate health check

• Save.

Example AWS CLI JSON to create two weighted A records

Save this JSON to weighted-change.json (replace HostedZoneId and domain/name values):

{
  "Comment": "Create weighted A records for app.example.com",
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com.",
        "Type": "A",
        "TTL": 60,
        "SetIdentifier": "north-california",
        "Weight": 30,
        "ResourceRecords": [
          { "Value": "13.56.59.133" }
        ]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com.",
        "Type": "A",
        "TTL": 60,
        "SetIdentifier": "north-virginia",
        "Weight": 70,
        "ResourceRecords": [
          { "Value": "35.174.3.77" }
        ]
      }
    }
  ]
}

Then run:

aws route53 change-resource-record-sets \
  --hosted-zone-id ZXXXXXXXXXXXXX \
  --change-batch file://weighted-change.json

You can save weighted-change.json anywhere on your local machine or build repo

Health checks (Optional)

• Attach health checks to each weighted record if you want Route 53 to stop returning a record when that endpoint is unhealthy.

• If a record with an associated health check becomes unhealthy, Route 53 excludes it from DNS responses (so the weight is effectively redistributed among healthy records).

Testing weighted distribution

To verify weighting, use the URL you generated (i.e. http://weighted.cloudproject.click) to test which server your traffic is directed to.

You will realize that the North Viginia server will be one loading since it was the one assigned a weight of 70

Why weights and health checks together?

• Weights control what percentage of DNS responses point to each backend (traffic shaping).

• Health checks ensure failed backends are removed from responses thus avoiding sending traffic to unhealthy endpoints during a rollout or test.

• Together they provide controlled, safe traffic shifts with automatic failover of unhealthy endpoints.

Notes and best practices

• Lower TTLs (e.g., 30–60s) let you change routing faster and also introduce caching behavior.

• Use descriptive Record ID values so it’s clear which record maps to which backend.

• Monitor health checks to confirm which servers are not in operation.