Setting up sovereign cloud reference architectures: three patterns that work

What you will build and why it matters

Sovereign cloud architecture means designing infrastructure so that data residency, processing location, and legal jurisdiction stay predictable and provable, not just documented in a policy PDF. This guide walks through three reference patterns for managed cloud infrastructure that we deploy repeatedly for SaaS platforms, agencies, and e-commerce clients: single-region EU, active-passive multi-region, and hybrid private-public. By the end you will know which pattern fits your compliance requirements and traffic profile, and how to configure and verify each one.

These are not theoretical models. Each pattern below reflects configurations we run in production for clients handling GDPR-regulated data, payment infrastructure, or public-sector contracts.

Prerequisites and assumptions

Before implementing any of these patterns, you need the following in place:

• An existing application that is stateless at the compute layer, or a plan to get there. Sovereign patterns assume you can run multiple app server instances without session affinity issues.
• Infrastructure as code tooling: Terraform or OpenTofu, plus Ansible or a similar configuration management tool.
• A clear data classification: which datasets are subject to GDPR, DORA, or sector-specific regulation, and which are not.
• Access to at least one EU-based provider (bare metal or private cloud) and, for the hybrid pattern, a public cloud account for burst capacity.
• Basic familiarity with load balancer configuration (HAProxy or Nginx) and database replication (PostgreSQL streaming replication or MySQL group replication).

If you are still deciding whether to build on open-source infrastructure or a public cloud provider, read choosing between the open-source sovereign stack and managed public cloud first. This guide assumes that decision is made.

Step-by-step implementation

Pattern 1: single-region EU (baseline sovereignty)

This is the right starting point for most SaaS companies and agencies that need to prove EU data residency without the operational overhead of multi-region replication.

Architecture: all compute, storage, and backups live in one EU region (for example, Amsterdam or Frankfurt), with no data leaving that boundary at any layer, including logging and error tracking.

1. Provision compute across at least two availability zones within the region, never a single physical rack.
2. Deploy a load balancer tier (HAProxy) in front of application servers:

frontend web_front
    bind *:443 ssl crt /etc/haproxy/certs/app.pem
    mode http
    default_backend app_servers

backend app_servers
    balance roundrobin
    option httpchk GET /health
    server app1 10.0.1.11:8080 check
    server app2 10.0.1.12:8080 check
    server app3 10.0.1.13:8080 check

3. Configure PostgreSQL streaming replication within the region, with a synchronous standby for zero data loss on failover:

# postgresql.conf on primary
synchronous_standby_names = 'standby1'
wal_level = replica
max_wal_senders = 5

# recovery config on standby
primary_conninfo = 'host=10.0.1.21 port=5432 user=replicator'

4. Route all third-party services (email delivery, error tracking, analytics) through EU-based providers. This step is frequently skipped and quietly breaks the sovereignty guarantee. See data sovereignty best practices for email, error tracking, and analytics for the specific providers to check.
5. Enable automated, encrypted backups stored in the same region, with a documented retention policy (typically 30 days daily, 12 months monthly for compliance workloads).

Pattern 2: active-passive multi-region

Use this pattern when you need disaster recovery across two EU regions (for example, Netherlands and Germany) without doubling your infrastructure spend, and when your compliance requirement allows failover as long as both regions stay within the EU.

1. Stand up a full replica environment in a second EU region, sized at 30-50% of production capacity (enough to run degraded, not enough to run idle at full cost).
2. Replicate the database asynchronously to the secondary region:

# On secondary region standby
primary_conninfo = 'host=

3. Use DNS-based failover with health checks (Route 53, or an EU-based alternative like ClouDNS with health monitoring) pointed at both regions:

failover_policy:
  primary: eu-west (Amsterdam)
  secondary: eu-central (Frankfurt)
  health_check_interval: 10s
  failover_threshold: 3 consecutive failures

4. Automate promotion of the standby database to primary with a scripted runbook, not a manual SSH session under pressure:

pg_ctl promote -D /var/lib/postgresql/data
# then update application connection strings via config management, not manual edits

5. Test the failover quarterly, not just after building it. This is the step most teams skip, and it is the only step that actually proves the architecture works.

Pattern 3: hybrid private-public

This pattern fits teams that need guaranteed data residency for regulated workloads (payment data, health records, government contracts) but want elastic burst capacity for traffic spikes, such as e-commerce flash sales.

1. Keep the system of record (database, PII storage, payment processing) on private infrastructure inside the EU, fully under your control.
2. Use public cloud capacity only for stateless, non-sensitive workloads: static asset delivery, image processing, or read-only caching layers.
3. Enforce the boundary at the network level, not just in application logic:

# Example firewall rule restricting outbound DB traffic to private subnet only
iptables -A OUTPUT -p tcp --dport 5432 -d 10.0.0.0/8 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 5432 -j DROP

4. Route burst traffic through a CDN configured to keep EU traffic within EU edge nodes. See understanding CDN data sovereignty for which providers actually guarantee this versus which just claim it.
5. Document the data flow diagram showing exactly which system touches regulated data. Auditors and enterprise procurement teams will ask for this before contract signature.

Verification: how to confirm it works

Each pattern needs proof, not just configuration. Here is what to check:

• Data residency proof: run traceroute and packet capture on a sample transaction to confirm no hop leaves the EU. Cross-check with your cloud provider's published data center locations.
• Failover time (multi-region pattern): measure actual time from primary failure detection to secondary serving traffic. Target under 60 seconds for DNS-based failover with a 10-second health check interval; anything above 5 minutes suggests your health check thresholds are too conservative.
• Replication lag: monitor with SELECT now() - pg_last_xact_replay_timestamp(); on the standby. Sustained lag above 5 seconds under normal load indicates network or I/O bottlenecks that will cause data loss on an unplanned failover.
• Boundary enforcement (hybrid pattern): attempt a connection from the public cloud segment to the private database port and confirm it is rejected at the firewall, not just blocked by application logic that could be bypassed.
• Uptime under real failover: run a scheduled failover drill and measure actual customer-facing downtime, not just infrastructure switch time. A common gap is DNS caching adding 2-5 minutes beyond your technical failover time.

For teams running high-traffic workloads, it is worth reading why 99.9% uptime doesn't tell the full story to understand what these numbers actually mean for customer experience during a regional event.

Common pitfalls to avoid

• Treating region toggles as sovereignty. Selecting "EU" in a cloud console does not guarantee subprocessors, support staff, or backup replication stay in the EU. Verify contractually and technically.
• Skipping third-party service audits. Your database can be perfectly compliant while your error tracking tool ships stack traces (often containing user data) to a US-based endpoint.
• Under-provisioning the passive region. A standby sized too small will not actually serve production load during failover, defeating the purpose of the pattern.
• Never testing failover. An untested disaster recovery plan is a hypothesis, not a capability.
• Ignoring data in transit between hybrid tiers. Encrypt every connection between private and public segments, and rotate credentials regularly.

Next steps and related reading

Once you have picked a pattern, the next decision is how to migrate existing workloads onto it without downtime. Our 6-phase zero downtime migration playbook covers the cutover mechanics in detail. If you are still weighing single-region against multi-region against hybrid at a strategic level, our companion piece on sovereign cloud architectures: single-region, multi-region, and hybrid patterns goes deeper into the decision criteria.

From here, plan a quarterly review cadence: revisit your data classification as new features ship, re-test failover after any significant infrastructure change, and re-audit third-party subprocessors annually as their own infrastructure evolves.

Build it once, run it correctly

Each of these patterns works in production, but they demand ongoing operational discipline: replication monitoring, failover drills, and subprocessor audits do not run themselves. That is the part most teams underestimate when they scope this internally.

Need this running in production without building it yourself? See our managed infrastructure services or schedule a call.