Start with the reason for a second region
Consider an application running in Europe, with a Kubernetes cluster, a database and background workers. Its US customer base is growing. Adding servers in the US sounds like the obvious next step, but the architecture depends on what those servers are supposed to improve.
For faster responses, frequent requests need to finish close to the customer. For disaster recovery, another region needs enough data and capacity to take over. For access to a particular GPU, a remote worker may only need to retrieve a job and upload a result. These are three different requirements.
This Europe-to-US example gives us a concrete way to work through those decisions.
Choose between one cluster and separate regional clusters
Kubernetes can run nodes across regions if the networking and supporting components allow it. The harder question is whether those nodes should belong to the same cluster.
First distinguish availability zones from regions. Zones are separate failure locations within a region; regions are larger geographical areas that can be much farther apart. Kubernetes' multi-zone guidance describes spreading workloads across zones, commonly within one region. Running across continents introduces much longer and less predictable communication paths.
There are three arrangements worth comparing:
| Arrangement | How it works | Main operational concern |
|---|---|---|
| One control plane, remote workers | Cluster management stays in Europe; some workloads run on US nodes | Remote workers depend on the link to Europe for cluster management |
| Control plane spread across regions | Cluster management and its state store span locations | Consensus and control-plane availability depend on inter-region connections |
| One cluster per region | Each region schedules and manages its own workloads | More clusters to operate, with application data and traffic coordinated separately |
For a service that must keep operating in either continent, our default recommendation is separate regional clusters. For an occasional remote compute job, an independent worker consuming a durable queue may be simpler still. It need not join the application's Kubernetes cluster at all.
Understand the risk of stretching the control plane
The control plane manages the cluster: it schedules workloads and reconciles their desired state. Its etcd database stores cluster state and uses a majority of voting members to agree on changes.
With three etcd voters, two must remain connected for consensus. Put two in Europe and one in the US: losing Europe removes the majority. Put one in each of three distant regions: consensus must cross regional links. The etcd documentation explicitly identifies higher consensus latency and replication traffic as costs of cross-region deployment.
Keeping etcd together and adding only remote workers avoids that particular consensus problem. It still leaves those workers dependent on a distant control plane. During a disconnection, already-running containers may continue, but scheduling, reconciliation and access to remote services can be affected.
This is why “three nodes in different countries” is not enough to describe resilience. Identify which nodes hold cluster state, which run applications, and which connections each needs to remain useful.
Check whether private networking connects your locations
A provider offering private networking does not necessarily offer it between every region. Check the exact locations before designing around a shared private address space.
Hetzner is a good example. Its Networks FAQ allows a Network to span locations within one network zone. According to its location list, Falkenstein, Nuremberg and Helsinki share eu-central. A private Network can therefore connect those locations, including across Germany and Finland. Its US and Singapore locations belong to other network zones; the same Network cannot extend to them.
| Provider | Cross-region private networking |
|---|---|
| Hetzner Cloud | Shared Networks are limited to locations in the same network zone |
| AWS | Inter-region VPC peering connects VPCs using private IP addresses over the AWS backbone |
| Google Cloud | VPC networks have global scope, with subnets in individual regions |
AWS documents the connection through VPC peering. Google documents a different arrangement through its global VPC model. Routing, access rules and applicable transfer charges still need attention. Private connectivity does not guarantee a particular application response time.
These provider details were checked on September 13, 2026. In the Europe-to-US example, the network design must follow the selected provider's actual boundaries.
Use a VPN when provider networking is insufficient
An encrypted tunnel can connect servers across providers or across locations without shared private networking. WireGuard is one possible building block. It creates another piece of infrastructure to configure and maintain: tunnel endpoints, keys, routes and recovery when an endpoint disappears.
Plan non-overlapping address ranges for the locations that must communicate. Measure the link with realistic traffic, including large transfers. Check packet-size handling and available bandwidth as well as latency; a successful ping proves very little about a database replication stream or a video workload.
A VPN over the public Internet also depends on the underlying Internet route. It can provide encrypted connectivity, but its presence alone is not a reason to spread a cluster's control plane across continents.
Keep frequent database calls close to the application
Suppose a US application server makes six sequential calls to a database in Europe. At an illustrative 90 milliseconds per round trip, network waiting alone contributes about 540 milliseconds. Those are example numbers, not measurements of a particular provider.
Moving the application server has helped only part of the request. To reduce the total delay, examine which calls can be combined, cached or served from local data. A read replica can help suitable reads; it does not automatically make writes local.
For PostgreSQL, asynchronous streaming replication allows the standby to lag behind the primary. A customer who updates something and immediately reads it from the replica may see the earlier value. Synchronous replication can wait for a remote standby's acknowledgement, which adds network delay and a dependency on that standby's availability.
For the example application, a reasonable initial choice could be local US reads for data that tolerates delay, while writes and freshness-sensitive reads go to Europe. If fast US writes are essential, that requirement may justify assigning customers to regional databases or evaluating a database designed for distributed writes. Both choices add application work.
Design database failover before redirecting traffic
Assume Europe becomes unreachable. Sending users to the US application will not restore writes while that application still relies on the European primary database.
Promoting a US replica requires a separate recovery decision. How much replication lag can be accepted? How is the old primary prevented from accepting conflicting writes if it is still running? How will the application discover the new writer?
PostgreSQL's failover guidance warns about both servers believing they are primary. Preventing the old writer from continuing is often called fencing. A dropped connection alone does not establish that the other server has stopped.
Make the order explicit: establish which database may accept writes, bring dependent services into a working state, then route the relevant traffic. Recovery also needs to rebuild redundancy afterwards. A successful switch that leaves only one database running is an intermediate state.
Test what happens when a region loses connectivity
Use a controlled environment to interrupt the link between regions while leaving both sides running. This exposes a different failure from shutting down a server cleanly.
Check whether users can log in, whether workers can obtain new jobs, and whether services can access their configuration and credentials. A region may have its own cluster while still depending on a single authentication service or queue elsewhere.
Measure how long recovery takes and whether any acknowledged data is lost. Restore the connection and check for duplicate jobs, conflicting writes and clients still using old endpoints. The surviving region also needs enough spare capacity for the traffic it is expected to receive.
A practical starting architecture
For an application expanding from Europe to the US, start with regional clusters and local copies of the services required to answer requests. Keep deployment definitions shared and reviewable. Choose an explicit database arrangement based on which operations need fresh data or local writes.
Use cross-region connections for identified purposes: replication, selected API calls or job delivery. Treat each connection as a dependency with a cost and a failure behaviour. Add automatic failover only after its data and capacity requirements have been exercised.
If the actual requirement is disaster recovery rather than faster US traffic, a standby deployment with tested restoration may be sufficient. Running every service actively in several regions is a substantial commitment. The right amount of infrastructure is the amount needed to meet the application's response-time and recovery requirements.
Cover photograph: Albert Stoynov / Unsplash. Illustrative network equipment.