Choosing Regions
When you deploy a container you choose which regions it runs in. That choice drives latency for your users, where your data is processed, and what you pay. This article walks through how to make it well.
When you deploy a container you choose which regions it runs in. That choice drives latency for your users, where your data is processed, and what you pay. This article walks through how to make it well.
The three factors
Latency to your users
Your container runs an independent instance in each region you select, and traffic is served from the region closest to the user (or distributed across regions, depending on your DNS mode). The closer a region is to your users, the lower the round-trip time they experience.
Match regions to where your users actually are:
| Users concentrated in | Consider |
|---|---|
| Europe | helsinki-1, falkenstein-1 |
| North America | virginia-1 |
| Asia-Pacific | singapore-1 |
The four live regions are:
| Region ID | Location | Class |
|---|---|---|
helsinki-1 | Helsinki, Finland (Europe) | Standard |
falkenstein-1 | Falkenstein, Germany (Europe) | Standard |
virginia-1 | Ashburn, Virginia, USA (North America) | Standard |
singapore-1 | Singapore (Asia-Pacific) | Premium |
Data residency
If your workload must be processed within a particular jurisdiction, pick only regions in that jurisdiction. A container's data stays in the regions you select — there is no replication to regions you did not choose. To keep processing in Europe, for instance, deploy only to the two European regions. See Data residency.
Cost
Regions are classed standard or premium. Premium regions carry a higher per-millicore and per-GB rate. Each region is billed independently, so a container in three regions costs roughly three times a single-region deployment of the same size. Weigh the reach a region buys against what it adds to the bill. See How billing works.
Single region versus multiple regions
A single region
The simplest setup: all traffic goes to one location. A good fit for:
- Development and staging environments.
- Applications whose users sit in one geography.
- Cost-sensitive workloads.
The trade-off is that users far from the region see higher latency, and if that region has an outage your application is unavailable.
Multiple regions
Running in several regions puts your application closer to users worldwide and removes the single point of failure — one region can go down without taking the whole service with it. A good fit for:
- Production applications with a global audience.
- Latency-sensitive workloads.
- Anything that needs to stay up through a regional outage.
The trade-off is cost (each region is billed independently) and the need for your application to be stateless, or to handle state and session affinity itself, since any region may serve any request.
Start with the single region closest to most of your users, then add regions as your audience spreads or your uptime requirements grow. Adding and removing regions is a configuration change, not a rebuild.
A simple decision path
- Where are your users? Pick the region nearest the largest group first.
- Any residency constraint? If so, restrict your choices to permitted regions before anything else.
- Do you need to survive a regional outage? If yes, add at least a second region.
- What is the budget? Prefer standard regions where they meet your latency needs; reach for a premium region only where its location is what you need.