Data Residency Explained: When Geography Matters for Storage

A European customer signs up for your SaaS. Under EU regulations, their personal data must be stored “within the EU.” A US customer’s data has more flexibility. A Russian customer’s data must stay in Russia (legally required). Data residency — where data is physically stored — has become one of the larger constraints on modern multi-region architecture.

This post covers what data residency requires, which regulations drive it, the technical patterns to comply, and how IP-based routing fits in.

What Data Residency Means

Data residency = the geographic location where data is physically stored.

This is distinct from:

• Data sovereignty — Whose laws govern the data. Often tied to residency but separately specified.
• Data localization — Strict requirement that data stay in-country, often with no copies outside.

Different jurisdictions have different requirements. Some require localization (data may never leave); others allow residency in specific regions; others have flexible rules with data transfer agreements.

Regulations Driving Residency

GDPR (EU)

The EU’s General Data Protection Regulation doesn’t strictly require localization, but it does require adequate protection for data transferred outside the EU. In practice, US-EU data transfers (post-Schrems II) require specific safeguards (Standard Contractual Clauses, certifications under the EU-US Data Privacy Framework).

Many companies simplify by keeping EU data in EU regions.

Russia

Federal Law 242-FZ requires personal data of Russian citizens to be processed and stored on servers physically located in Russia. Strict; enforced.

China

Cybersecurity Law and Personal Information Protection Law require data localization for “critical information infrastructure” and personal data, with state security review for cross-border transfers.

India

Personal Data Protection rules require certain categories of personal data to be stored in India.

Many other countries

Brazil (LGPD), South Korea (PIPA), Australia (various sector-specific), Canada (PIPEDA), etc. — each has its own rules.

The trend is more residency rules, not fewer. Multi-region architecture is increasingly the default.

Technical Patterns to Comply

Region-aware storage

Architect your data layer so that customer data resides in a specific cloud region. AWS, GCP, Azure all provide regions in the major jurisdictions.

US customers → us-east-1
EU customers → eu-west-1 (Ireland) or eu-central-1 (Frankfurt)
APAC → ap-northeast-1 (Tokyo) or ap-south-1 (Mumbai)

User-region mapping determines which region holds their primary data.

Region-specific accounts / clusters

For stricter compliance (Russia, China), you might run entirely separate stacks per region with no cross-border replication.

Logical partitioning

Tag each record with its residency. Queries filter by region. Backup and audit reports show per-region totals.

Encryption boundaries

For cross-border replication that does happen (e.g., for analytics), encrypt with region-specific keys so the destination can’t fully decrypt without explicit authorization.

IP-Based Routing and Residency

When a user signs up, you need to determine which region to put them in. The most common signal: IP-based geolocation.

const result = await convertIP(req.ip)
const country = result.success ? result.data.continent.country.code : 'US'
const region = countryToRegion(country)
await createUserInRegion(region, userData)

But IP alone isn’t always sufficient:

• Travelers sign up while abroad — wrong region.
• VPN users look like they’re in a different country.
• Mobile users on roaming networks.
• Legitimate cross-border situations — a Polish citizen working in Germany.

For high-stakes compliance, supplement IP with:

• Self-declared country at signup.
• Billing address when payment is added.
• Document verification for regulated industries.

A defensible compliance position: “we make a reasonable effort based on multiple signals.”

User Migration

What happens when a user moves? Or when you discover the IP-based assignment was wrong?

Migration is usually painful:

• Data has to be exported from one region, imported to another.
• Some integrations might tie data to region-specific URLs.
• Audit trails need to follow.
• Downtime windows.

For most users, migrations are rare. Plan the architecture so the common case (correct initial assignment, no migration) is smooth.

Cross-Region Replication

A common pattern: keep primary copies in the user’s residency region, but allow read-only replicas elsewhere for performance.

• Primary in EU (residency-compliant).
• Cache in US (faster reads for global ops staff).
• Encrypted so US cache can’t be read without EU-stored keys.

Whether this satisfies regulations depends on the jurisdiction and the specifics. Russia, no. EU with appropriate safeguards, usually yes. Always check with legal.

Geofencing for Compliance

Sometimes data residency overlaps with geofencing — controlling who can access your service from which countries. See geofencing 101.

Example: a German company that operates only domestically might block non-German IPs entirely. The data residency rule (data stays in Germany) is reinforced by access control (users come from Germany).

For most services, you allow global access but route data to the right region based on user info.

Provider Selection

When selecting cloud providers, consider:

• Region coverage — Do they have regions where your customers’ data must reside?
• Sovereign options — For sensitive markets (Germany, France, China), regional providers may be preferred over global ones for regulatory reasons.
• Local laws — A provider headquartered in country X may be subject to that country’s data demands even if data is stored elsewhere.

For EU customers, EU-headquartered or EU-only-operating providers offer more certainty than US-headquartered ones (despite GDPR-equivalent contracts).

What “Stored In” Means in Practice

Surprisingly subtle. Considerations:

Backups

Are backups in the same region? They count as “stored data” too.

Caches

A CDN cache in another country — does that count? Usually no (transient), but it depends.

Logs

Application logs often go to a central logging service. Are user identifiers in those logs? Where are the logs stored?

Database replicas

Read replicas in another region — does that violate residency? Usually yes for strict regimes.

A complete data-residency strategy considers all storage tiers, not just the primary database.

DSARs and Subject Access Requests

GDPR and CCPA give users the right to:

• Access their data.
• Delete their data.
• Export their data.

Residency complicates this. Your DSAR system needs to query data in the correct region. For users with mixed-region data (rare but possible), the response combines from multiple regions.

Most multi-tenant SaaS automates DSAR queries through their data residency map.

Audit and Reporting

Compliance often requires auditable reports of:

• How many users in each region.
• Where their data is stored.
• Who has accessed it.
• Any cross-border transfers and the legal basis.

Build these reports into the system from the start. Retrofitting is painful.

Edge Cases for IP-Based Region Detection

For IP-based country detection:

• CGNAT IPs in mobile networks can geolocate to unexpected places. Use Wi-Fi if available; verify against billing.
• Recently re-allocated IPs may have stale data. Cross-check.
• Anycast IPs (CDN, DNS) don’t have one location. Not a typical user-IP concern; just be aware.
• IPv6 prefixes have varying geolocation quality.

For high-stakes compliance, never rely on IP alone. Confirm at signup; verify at payment.

Implementation Sketch

A typical user signup flow:

async function signUp(req: Request): Promise<User> {
    const ip = req.ip
    const geo = await convertIP(ip)
    
    const tentativeCountry = geo.success ? geo.data.continent.country.code : null
    const tentativeRegion = mapCountryToRegion(tentativeCountry)
    
    // Show country selector at signup; pre-fill with IP guess
    const userCountry = req.body.country ?? tentativeCountry ?? 'US'
    const userRegion = mapCountryToRegion(userCountry)
    
    // Create user in the right region
    const userId = await createUserInRegion(userRegion, {
        email: req.body.email,
        country: userCountry,
        // ...
    })
    
    return userId
}

The pattern: IP suggests a country; the user confirms; the user’s region is the authoritative source for residency decisions.

TL;DR

• Data residency = where data is physically stored.
• Regulations driving it: GDPR (with transfer safeguards), Russia 242-FZ (strict), China PIPL, India PDP, others.
• Technical patterns: region-aware storage, logical partitioning, encryption boundaries.
• IP-based routing gives a first guess at region; supplement with self-declared + billing.
• Backups, caches, and logs all count toward residency.
• Cross-region replication with appropriate safeguards is sometimes OK; not always.
• DSAR systems must work across regions.
• For new architectures, plan residency from day one — retrofitting is painful.

Data residency is one of those compliance topics that’s grown in importance every year. The regulations keep multiplying; the technical patterns keep maturing. For the related privacy laws, see GDPR and IP addresses; for geographic access control, geofencing 101. IP-based region detection is the first signal for many of these decisions; the Ip2Geo API returns country with every lookup.