Migrating traffic to inbound external links with custom domains

This section describes how to migrate existing bid-request traffic from your current endpoint infrastructure to RTB Fabric inbound external links with custom domains. The migration uses DNS-based traffic routing, requires zero application changes on either the demand-side or supply-side, and supports incremental cutover with instant rollback.

Migration overview

Inbound external links with custom domains migration is DNS-based. You update the CNAME record for your public bid endpoint so that it resolves to your regional RTB Fabric Gateway endpoint instead of your existing origin. Because RTB Fabric preserves the request path, query string, and all HTTP headers exactly as received, neither your bidder application nor your upstream partners require any changes.

The migration sequence is:

Pre-migration checklist

Complete the following steps before changing any DNS records:

Gradual cutover with Route 53 weighted routing

Use Amazon Route 53 weighted routing records to incrementally shift traffic from your legacy endpoint to the RTB Fabric Gateway. Weighted routing distributes DNS responses proportionally across records based on their assigned weights.

Step 1: Create the initial weighted record set

Create two weighted CNAME records for your bid endpoint domain. Assign the majority of traffic to your existing origin.

At this point, approximately 10% of DNS resolutions direct traffic to RTB Fabric.

Step 2: Monitor and validate

Monitor the following for the initial traffic slice:

Allow the initial slice to run for a minimum of one full traffic cycle (typically 1-4 hours depending on your traffic patterns).

Step 3: Increase traffic incrementally

If metrics are healthy, increase the RTB Fabric weight in stages:

Update the Route 53 record weights for each stage:

aws route53 change-resource-record-sets --hosted-zone-id <zone-id> --change-batch '{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "east-bid.example.com",
      "Type": "CNAME",
      "SetIdentifier": "rtbfabric",
      "Weight": 50,
      "TTL": 60,
      "ResourceRecords": [{"Value": "<gateway-id>.<account-id>.gateway.rtbfabric.<region>.amazonaws.com"}]
    }
  }, {
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "east-bid.example.com",
      "Type": "CNAME",
      "SetIdentifier": "legacy",
      "Weight": 50,
      "TTL": 60,
      "ResourceRecords": [{"Value": "legacy-origin.example.com"}]
    }
  }]
}'

Step 4: Complete the cutover

After validating at 100% traffic on RTB Fabric, remove the legacy weighted record and convert back to a standard CNAME:

east-bid.example.com. 300 IN CNAME <gateway-id>.<account-id>.gateway.rtbfabric.<region>.amazonaws.com.

Restore the TTL to your standard value (for example, 300 seconds).

Rollback procedures

Rollback at any stage consists of redirecting DNS back to the legacy origin.

During weighted routing (partial cutover)

Set the RTB Fabric record weight to 0 and the legacy record weight to 100:

aws route53 change-resource-record-sets --hosted-zone-id <zone-id> --change-batch '{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "east-bid.example.com",
      "Type": "CNAME",
      "SetIdentifier": "rtbfabric",
      "Weight": 0,
      "TTL": 60,
      "ResourceRecords": [{"Value": "<gateway-id>.<account-id>.gateway.rtbfabric.<region>.amazonaws.com"}]
    }
  }, {
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "east-bid.example.com",
      "Type": "CNAME",
      "SetIdentifier": "legacy",
      "Weight": 100,
      "TTL": 60,
      "ResourceRecords": [{"Value": "legacy-origin.example.com"}]
    }
  }]
}'

After full cutover

Replace the CNAME target with the legacy origin:

east-bid.example.com. 60 IN CNAME legacy-origin.example.com.

Rollback does not require any changes to:

The RTB Fabric configuration remains in place and can be reused when you retry migration.

Multi-region migration

For customers operating in multiple AWS Regions, migrate each region independently. Each region has its own gateway endpoint, certificate configuration, and routing rules.

Create region-specific CNAME records pointing to each region's gateway: