Shift traffic between two origins by weight

You shift requests from one origin to another in steps, with the weights of the addresses of a Load Balancer connector, from Azion Console, the API, or the Azion CLI. To keep a standby out of traffic until the primary fails instead, refer to Add a backup origin to a connector.

Under Round Robin, each address receives a share of the requests in proportion to its weight, a whole number from 1 to 100. The weight sets a proportion, not an exact split: each data center balances on its own, so the share an address receives varies around the one its weight asks for. A weight cannot be 0, so an origin leaves the rotation through its Active switch, not through its weight.

1. Both origins sit on one connector as Primary addresses, and the new origin starts with a small weight.
2. Hold each set of weights until the new origin has served enough requests to show its errors.
3. When new errors appear, turn the new origin’s address off to roll back.
4. When no new error appears, raise the new origin’s weight, and hold again.
5. When the new origin carries the share you want, turn the old origin’s address off to cut over.

Prerequisites

The examples use old-origin.example.com for the current origin and new-origin.example.com for the new one. Replace them with yours.

Put both origins on the connector

The connector gets Load Balancer with Round Robin, and the new origin joins as a second Primary address. A weight of 9 on the current origin and 1 on the new one sends about one request in ten to the new origin. A connector holds up to 15 addresses with Load Balancer on.

Host takes a name both origins answer for, such as ${host}, which sends the host the client requested. A literal name of the current origin would reach the new origin under a name it may not answer for. The examples set Max Retries, Connection Timeout, and Read/Write Timeout to 3, 30, and 60, the values the Console fills in. The API and the CLI give a key the body leaves out 0, 60, and 120.

The connector holds two active addresses and sends about one request in ten to the new origin. A connector change reaches Azion’s distributed infrastructure over several minutes, and until every data center holds it, some requests reach the current origin alone.

In the Migrate an application to a new origin without downtime use case, this section takes these values:

The connector holds two active addresses and sends about one request in a hundred to the new origin. A connector change takes several minutes to reach every data center, and until then some requests reach the old origin alone.

Change the weights

Each step changes only the weights. Hold a step long enough for the new origin to serve the requests that expose its faults before you take the next one. Each record of the HTTP Requests data source of Real-Time Events carries Upstream Status and Upstream Addr, the status and the address of the origin that answered, so a filter on the new origin’s address shows its errors.

The new origin receives the share of the new weights once the change reaches each data center. During the spread, some data centers still apply the previous weights, so judge a step only after it has spread.

In the Migrate an application to a new origin without downtime use case, this section takes these values:

The new origin receives the share of the step once the change reaches each data center. During the spread, some data centers still apply the previous weights.

Take an origin out of rotation

The Active switch of an address takes it out of rotation without deleting it. The address keeps its ports, role, and weight, so turning it back on restores the step it left. Turning the new origin’s address off rolls back, and turning the current origin’s address off cuts over.

The address that is off receives no request once every data center holds the change. The change takes several minutes to spread, so keep the origin you turned off answering until no request reaches it.

The Migrate an application to a new origin without downtime use case uses the values of this example.

Measure the share and the errors of each origin

Each step is judged on what each origin received and how it answered. The checks below read a response header that tells the two origins apart, such as the server header each one sends, the requests of one hour grouped by upstream address in Real-Time Metrics, and the failing requests of the new origin in Real-Time Events. The examples use www.example.com for the site and <new-origin-ip> for the IP address that new-origin.example.com resolves to, which the event filters match on.

• Both origins answer. Send the same request several times and read the header that tells the origins apart:

  curl -s -D - -o /dev/null https://www.example.com/

  At equal weights, about half of the answers carry the new origin’s header. At weights of 99 and 1, most runs show only the old origin’s header, because one request in a hundred goes to the new one. The answers come in no fixed order.

• The new origin receives its share. Query the requests of one hour grouped by upstream address. Replace the token, the hour, and the hostname:

  Shell

  01curl -X POST 'https://api.azion.com/v4/metrics/graphql' \

  02 -H 'Content-Type: application/json' \

  03 -H 'Authorization: Token [TOKEN VALUE]' \

  04 -d '{"query":"query OriginShare { workloadBreakdownMetrics(aggregate: { sum: requests }, groupBy: [upstreamAddr], orderBy: [sum_DESC], limit: 10, filter: { tsGte: \"2026-10-05T13:00:00\", tsLt: \"2026-10-05T14:00:00\", hostEq: \"www.example.com\" }) { upstreamAddr total: sum } }"}'

  The API answers 200 with one row per upstream address, in the form {"data":{"workloadBreakdownMetrics":[{"upstreamAddr":"<new-origin-ip>:443","total":<requests>}, …]}}. The new origin’s total against the sum of all rows tracks the share of the weights.

• No new errors on the new origin. In Azion Console > Real-Time Events, select the HTTP Requests data source and a period that covers the step, and enter this filter in Filter by:

  upstream_addr like '%<new-origin-ip>%' AND upstream_status='502'

  An empty result means that no request to the new origin ended with 502. Repeat the filter with the other 5xx codes your origin can return.

• The rollback holds. After a rollback, run the filter upstream_addr like '%<new-origin-ip>%' over the minutes after the change. The newest records stop once every data center holds the change.

A step that seems to have no effect may still be propagating. Repeat the check after a few minutes before you change the weights again.

These checks confirm the Migrate an application to a new origin without downtime use case.

Next steps