Cross-Region Bandwidth

Every VPC ships with a free default bandwidth between regions, but it is intentionally very small — enough to verify reachability (a ping between regions, a quick latency check) and not much more. Any real workload — even a lightly used production service — needs the rate raised. Setting the right number for each region pair is what this page is about.

You do this by raising the Cross-Region Bandwidth for the region pair. This is the only knob the console exposes for cross-region capacity. There is no "Region Link" object to create, no peering to accept, no route to add — you pick a region pair, pick a committed rate, and pay for it.

The rate is flexible: you can set it anywhere from a few Mbps up to 10 Gbps and beyond, and you can adjust it up or down at any time without dropping existing connections.

Cross-Region Bandwidth

When to Raise Bandwidth

Effectively, whenever real application traffic has to cross regions. The free baseline is there to prove the path exists and to measure latency — it is not sized to carry a production workload. A few concrete signals that you need to raise it:

  • You're deploying anything beyond a connectivity test. Even a small replication stream, a message bus, or a cross-region health check will outgrow the free baseline.

  • Large scheduled transfers. Replication, data-warehouse sync, video transcoding pipelines, backups — size to the window, not the 24-hour average.

  • A critical path needs a committed floor. Production-critical region pairs should not ride on the free baseline; raise the bandwidth to the rate you can plan against.

When You Don't Need To

You're only verifying the path. If all you need is a ping between regions or a one-time latency sample, the free default is sized for exactly that.

Cross-VPC reachability. Cross-Region Bandwidth applies to traffic inside a VPC. It does not create a path between two separate VPCs — no amount of bandwidth will connect VPCs that aren't connected.

Reaching a regulated region (e.g., China). Regulated regions are not solved by raising bandwidth. Their connectivity is arranged under the applicable regulatory constraints — that's a separate conversation with supportenvelope.

How It's Purchased

In the console, navigate to Cross-Region Bandwidtharrow-up-right (under the VPC section), then:

  1. Choose the VPC.

  2. Choose the source region and destination region — the pair you want to accelerate.

  3. Pick a committed bandwidth in Mbps.

  4. Confirm. The rate applies within a short provisioning window.

You can adjust the bandwidth of an active pair at any time. The change takes effect within a short provisioning window and does not drop existing connections.

Bandwidth you purchase applies to the chosen pair in both directions.

Billing

Cross-Region Bandwidth bills on the configured rate, not actual usage. A 1 Gbps purchase costs the same whether the path runs at 50% or 0.5%. This makes the cost predictable but also means under-utilized purchases are wasted spend — review them periodically.

The free default mesh continues to exist alongside any paid bandwidth. If you cancel a purchase, the pair falls back to the best-effort baseline rather than going dark.

Sizing

A few guidelines:

  • Replication and backup workloads — size to the peak rate you want to sustain, not the average. If a nightly sync needs to move 1 TB in four hours, that's roughly 560 Mbps, not the 24-hour average of 93 Mbps.

  • Interactive traffic — latency is usually the constraint, not bandwidth. Raising bandwidth rarely helps a chatty RPC workload.

  • Leave headroom — sustained traffic above the configured rate is shaped, which causes loss at TCP's congestion point. Size 20–30% above the peak you expect.

Common Patterns

Replication pipe between primary and replica. Primary database in one region, replica in another, both in the same VPC. The free mesh handles everyday chatter, but you purchase Cross-Region Bandwidth sized for the replication stream to give it a committed floor.

Scheduled bulk transfer. A nightly job moves warehouse extracts between regions. You size the purchase to the job's window so the transfer finishes on time.

Burst-prone interactive service. A service that's usually quiet but occasionally surges. Buy enough bandwidth to cover the surge, not the average. The shaping behavior at the ceiling is what determines user experience at peak.

Things to Watch

  • Bandwidth is a hard ceiling. The committed rate is also the max rate. Traffic beyond it is shaped, not bursted. Size accordingly.

  • Purchases are per region pair. Raising bandwidth between Hong Kong and Frankfurt does nothing for Hong Kong ↔ Singapore. Each pair is priced independently.

  • Default baseline stays. You don't need to buy bandwidth for pairs that are happy on the free mesh. Only pay for the pairs that actually need more.

Last updated