Where a server sits used to be a procurement detail. Today it shapes three things at once: how fast your application feels to users, which laws govern the data it holds, and how well you recover when a facility or region fails.
This guide walks through the decision the way an infrastructure team should make it: start with the data and the users, put numbers on latency, map the legal constraints in general terms, account for every copy of the data (not just the primary), and write the result into your contracts.
One note before starting: this is an engineering guide, not legal advice. Privacy and residency rules change, depend on facts specific to your business, and are interpreted differently by different regulators. Use this material to frame the questions, then confirm every legal conclusion with qualified counsel in the jurisdictions that matter to you.
Start with the data, not the map
Before choosing a city, classify what the system stores and processes. Most organizations end up with a small number of data classes, each with its own placement rules.
- Personal data. Anything that identifies a person: names, emails, IP addresses, device identifiers, location history. Most privacy laws attach here.
- Sensitive or special categories. Health, biometric, financial, government ID, children's data. These usually carry stricter handling and transfer rules.
- Regulated sector data. Payment data, banking records, health records, public sector data. Sector regulators often add requirements on top of general privacy law.
- Business confidential data. Source code, models, contracts, pricing. Not always regulated, but customers may still demand control over location.
- Operational data. Logs, metrics, traces, support tickets. Often overlooked, frequently full of personal data, and commonly shipped to a third country by default.
For each class, record where the data subjects are, where the data is created, who needs to access it and from where, and what any customer contracts already promise.
Latency: what distance actually costs
Light in optical fiber travels at roughly 200,000 km per second, about two thirds of its speed in a vacuum. That works out to about 1 ms of round trip time for every 100 km of fiber. Real cable routes are longer than straight lines, and every router and exchange point adds a little, so measured round trip times are typically 1.3 to 2 times the straight line figure.
Rough, real world round trip times look like this.
- Same metro area. 1 to 5 ms.
- Same region, up to about 1,000 km. 10 to 25 ms.
- Across the continental United States, coast to coast. 60 to 80 ms.
- US East Coast to Western Europe. 75 to 100 ms.
- US East Coast to India. 180 to 250 ms.
- Singapore to India. 50 to 80 ms.
- US West Coast to Singapore. 160 to 200 ms.
- US East Coast to Sao Paulo. 110 to 140 ms.
Why this matters more than it looks: a page or API call rarely needs one round trip. At 200 ms per round trip, five sequential round trips mean a full second of waiting before any server processing. The same flow at 20 ms costs 100 ms.
Practical guidance: interactive applications feel responsive when the round trip to the origin stays under about 50 ms, and most users notice delays once total response time passes a few hundred milliseconds. Latency between your own tiers matters too: an application server and its database should normally sit in the same facility or availability zone, because chatty database traffic multiplies every millisecond.
Residency, sovereignty and transfer rules in general terms
Three terms get used loosely. Data residency is where data is physically stored. Data localization is a legal requirement that certain data stay within a country. Data sovereignty is the broader idea that data is subject to the laws of the place where it is held, and sometimes the laws of the country where the provider is based. Most general privacy laws do not require localization. Instead, they regulate transfers across borders and the safeguards around them.
- GDPR (European Union and EEA). Personal data can leave the EEA, but only under a recognized mechanism: an adequacy decision for the destination country, standard contractual clauses with a transfer risk assessment, binding corporate rules, or narrow exceptions. Transfers to US organizations certified under the EU-US Data Privacy Framework are covered by an adequacy decision. Remote access from another country counts as a transfer.
- CCPA as amended by CPRA (California). No localization requirement. The focus is on consumer rights (access, deletion, opting out of sale or sharing) and on contracts with service providers that limit how they use the data. Several other US states have passed broadly similar laws.
- LGPD (Brazil). Structured much like GDPR. International transfers require a legal basis such as adequacy, standard contractual clauses approved by the national authority (ANPD), or specific consent, and the authority has issued regulations detailing these mechanisms.
- DPDP Act (India). The Digital Personal Data Protection Act, 2023 generally allows transfers outside India except to countries the government restricts by notification, with implementing rules being phased in. Sector rules in India can be stricter than the general law, and they take precedence where they apply.
- Other countries. Some jurisdictions require that certain categories of data, or at least a copy of them, be stored locally, or require approval for transfers. If you serve users in a country, check its rules early rather than at contract time.
A provider headquartered in one country and hosting in another can be subject to legal requests from both. Ask counsel how it applies to your situation and record the answer in your design documents.
Sector rules that override the general picture
Industry rules frequently impose stricter or more specific requirements than general privacy law. Common examples include:
- Payments. PCI DSS does not dictate a country, but it defines how cardholder data environments are segmented, accessed and audited, and that affects which facilities and providers qualify. Some national regulators go further: the Reserve Bank of India, for example, requires payment system data to be stored only in India.
- Health. In the United States, HIPAA does not require domestic hosting, but it requires a business associate agreement with any provider handling protected health information. Many health customers add contractual US-only requirements anyway.
- Financial services. Banking and insurance regulators commonly require notification or approval for material outsourcing, audit rights for the regulator, and documented exit plans.
- Public sector. Government programs often require in-country hosting, cleared personnel or specific authorization frameworks, and these requirements usually pass down to subcontractors.
When a customer contract or a regulator imposes a location requirement, it becomes a hard constraint.
Backups, replicas and the copies you forget
Most residency failures are not about the primary database. A system that stores production data in one country but ships nightly backups, log streams or support exports to another has, in practice, a multi-country footprint.
List every place a copy of the data can land:
- Backups and snapshots. Where are they stored, how long are they kept, and are they encrypted with keys you control?
- Replicas. Read replicas, standby databases and cross-region replication for disaster recovery.
- Logs and observability. Application logs, access logs, traces and error reports often contain IP addresses, user IDs and request bodies.
- CDN and caches. Edge caches may hold personal content in many countries. Configure what can be cached and where.
- Support and administration. Remote access by engineers or support staff in another country can count as a transfer under several laws.
- Analytics and AI pipelines. Data exported for analysis, model training or inference may move to a different region or provider.
A common and defensible pattern is to keep the primary and its immediate standby in one jurisdiction, place disaster recovery copies in a second facility within the same jurisdiction where possible, and when cross-border backup is necessary, encrypt before transfer with keys held in the primary jurisdiction. Whether encryption changes the legal analysis depends on the law and the facts, so confirm that point with counsel as well.
A dedicated 1 Gbps link moves roughly 10 TB per day at full utilization, and less in practice. If a full restore of your largest dataset over that link takes longer than your recovery time objective, you need a larger link, a closer copy or a different recovery plan.
Multi-region designs and what they cost
Running in more than one region solves two different problems: proximity to users in different geographies, and survival of a regional outage.
- Single region, multiple facilities. Primary and standby in separate data centers within the same metro or country. Low replication latency, simple residency story, protects against facility failure but not a regional event.
- Active-passive across regions. One region serves traffic, a second holds replicas and can be promoted. Asynchronous replication means the recovery point is seconds to minutes behind. Good balance for most business systems.
- Active-active across regions. Both regions serve traffic. Requires careful handling of writes, conflict resolution or partitioned ownership of data, and much more testing. Justified for global user bases with strict availability needs.
- Regional cells. Each region holds its own users' data and serves only them, with minimal shared state. This aligns well with residency requirements: European users in a European cell, Indian users in an Indian cell, and so on.
Synchronous replication between regions adds the full round trip to every write, so a 70 ms link adds at least 70 ms to every committed transaction. Most teams use synchronous replication only within a metro area and asynchronous replication across longer distances. Also budget for the duplicated infrastructure, the cross-region transfer charges where they apply, and the engineering time to run regular failover tests.
Contract clauses to request
Technical design only holds if the contract supports it. When evaluating any hosting or cloud provider, ask for clauses or written commitments covering the following, and have counsel review the final wording.
- Named locations. The country, and ideally the facility or region, for primary data, backups and replicas, stated in the order form or statement of work.
- No relocation without approval. The provider will not move data to another location without your prior written consent.
- Data processing agreement. Roles (controller and processor), processing purposes, security measures, and transfer mechanisms where cross-border flows exist.
- Subprocessor list and notice. A current list of subprocessors with their locations, and advance notice with a right to object before changes.
- Remote access disclosure. From which countries provider staff can access systems or data, and under what controls.
- Breach notification. A defined notification window that fits your own regulatory deadlines, plus the information the provider will supply.
- Government access requests. A commitment to notify you where legally permitted, and to challenge overbroad requests.
- Audit and evidence. Access to third party audit reports or facility certifications relevant to your sector, and a process for regulator audits if you need one.
- Exit and deletion. Data export in usable formats, a transition period, and certified deletion of all copies, including backups, at the end of the contract.
A checklist for your next design review
- Every data class inventoried with its data subjects' jurisdictions.
- Legal, regulatory and contract location limits listed and confirmed with counsel.
- RTT from main user bases to each candidate site: measured, not estimated.
- App servers and databases share a facility or zone.
- Copy map: primary, replica, backup, log, cache, analytics, support export.
- Cross-border flows: documented transfer basis, named owner.
- Backup keys are held in the intended jurisdiction.
- RPO and RTO defined, and the backup link can meet them.
- Failover tested in the last six months, results recorded.
- Contracts fix sites, bar unapproved moves, cover subprocessors, breach notice, exit.
- Decision and rationale documented. Next audit or questionnaire: hours, not weeks.
How Vonahost can help
Vonahost lets customers choose the country of each server, and data is not moved without their approval. Dedicated servers, NVMe VPS and SSD VPS are deployed in the region you choose, and managed cloud can run on Vonahost's own platform or in AWS and Google Cloud regions, which helps when a design calls for regional cells or a disaster recovery site in a specific jurisdiction.
Every Vonahost proposal states the configuration, location, responsibilities and monthly price in US dollars, so the placement decisions from your design review are written into the order itself. Legal conclusions remain a matter for your counsel.