Multi-Cloud Strategy in 2021: Solving the Schrems II & Latency Dilemma

The "Cloud Agnostic" Lie and the Legal Reality of 2020

If you attended any virtual tech conference this year, you heard the buzzwords: "Cloud Agnostic," "Poly-cloud," "Interoperability." It sounds fantastic in a PowerPoint deck. But for those of us managing actual infrastructure in Norway, the reality is far messier. The ruling by the CJEU in July 2020 (Schrems II) invalidated the EU-US Privacy Shield. This wasn't just a legal footnote; it was a structural demolition of the lazy "just put it all on AWS" strategy for handling European personal data.

As a CTO, you are now squeezed between two forces: the developer's demand for the latest hyperscaler managed services, and Datatilsynet's (The Norwegian Data Protection Authority) looming threat of enforcement. You cannot simply ignore data sovereignty anymore.

The solution isn't to retreat entirely to on-premise hardware (we aren't going back to 2010). The solution is a Sanitized Hybrid Architecture. You treat the US hyperscalers as ephemeral compute layers for stateless workloads, while your state—your database, your customer PII, your authentication keys—resides on sovereign, local infrastructure. This is where a provider like CoolVDS fits, not just as a host, but as a compliance anchor in Oslo.

Architecture: The "Fortress and The Field"

Let's look at a topology that works. I call it "The Fortress and The Field."

• The Field (Public Cloud): Front-end scaling groups (AWS ASGs or Google Cloud Run). These handle traffic spikes, render HTML, or process stateless queues. They hold zero persistent sensitive data.
• The Fortress (Local VPS): A high-performance NVMe instance sitting in Norway. This hosts the PostgreSQL database, the Redis cache, and the Vault secrets engine. It is protected by Norwegian law and low-latency peering via NIX (Norwegian Internet Exchange).

The Connectivity Problem: IPsec is Dead, Long Live WireGuard

Historically, connecting these clouds meant configuring IPsec site-to-site VPNs. It was slow, CPU-intensive, and a nightmare to debug when the tunnel stalled. In 2020, with the release of Linux kernel 5.6, WireGuard became the standard. It is leaner, faster, and significantly easier to audit.

Here is how we bond a dynamic AWS front-end to a static CoolVDS backend securely. Do not rely on public IPs for database traffic. Ever.

Step 1: The CoolVDS Backend (The Hub)

On your Ubuntu 20.04 LTS instance in Oslo, install WireGuard and generate keys:

apt update && apt install wireguard
umask 077
wg genkey | tee privatekey | wg pubkey > publickey

Create /etc/wireguard/wg0.conf. Note the MTU; hyperscaler networks often use Jumbo frames or have specific encapsulation overheads, but 1360 is usually a safe bet to avoid fragmentation across the open internet.

[Interface]
Address = 10.100.0.1/24
SaveConfig = true
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820
PrivateKey = [YOUR_SERVER_PRIVATE_KEY]

# Peer: AWS Frontend 1
[Peer]
PublicKey = [AWS_CLIENT_PUB_KEY]
AllowedIPs = 10.100.0.2/32

Performance: NIX Peering vs. The World

Why bother keeping the DB in Norway? Latency and Egress fees. Hyperscalers charge exorbitant rates for data leaving their ecosystem. By keeping your "heavy" data (databases, storage) on CoolVDS, you leverage our flat-rate bandwidth structures. More importantly, check the latency.

Pro Tip: Use mtr (My Traceroute) with the -z flag to display AS numbers. You want to see traffic handing off at NIX (AS1967 or similar local exchanges) rather than bouncing through Stockholm or Frankfurt.

When your users are in Oslo, serving data from Frankfurt adds 15-25ms of round-trip time. Serving it from a local data center adds <2ms. For a Magento store doing 40 SQL queries per page load, that difference aggregates to nearly a full second of load time. That kills conversion rates.

Optimizing the Local Node: NVMe Tuning

If you are treating your local VPS as the "Fortress," it must be fast. Standard SSDs don't cut it for high-concurrency databases. You need NVMe. But hardware is only half the battle; Linux needs to know how to use it.

On many virtualized kernels, the I/O scheduler defaults to cfq or mq-deadline. For high-speed NVMe backed virtualization (like KVM), you often want none or kyber to let the device handle the queues without OS overhead.

Check your scheduler:

If you see [mq-deadline], consider switching it for database workloads. Add this to your GRUB config or apply at runtime:

echo none > /sys/block/vda/queue/scheduler

Furthermore, ensure your sysctl.conf is tuned for a high-throughput network bridge, especially if you are tunneling traffic via WireGuard:

# /etc/sysctl.conf
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
net.ipv4.ip_forward=1
net.ipv4.tcp_slow_start_after_idle=0

Enabling TCP BBR (Bottleneck Bandwidth and RTT) is crucial for stabilizing throughput over the WAN link between your cloud providers.

The Cost Reality Check

Let's look at the TCO. A managed PostgreSQL instance (Multi-AZ) on a major US cloud provider with 4 vCPUs and 16GB RAM can easily run upwards of $300/month before bandwidth. The bandwidth costs for egress can double that bill if you are data-heavy.

Conclusion: pragmatic sovereignty

The era of blindly deploying to a single US region is over. Between the Schrems II ruling and the increasing need for edge performance, the smart money is on hybrid architectures. Keep your logic where it scales, but keep your data where it's safe.

By using tools like WireGuard to stitch together commodity compute with premium, sovereign storage, you build a system that is robust, compliant, and cost-effective.

Ready to secure your data sovereignty? Don't let compliance fears stall your infrastructure. Deploy a high-performance, GDPR-aligned NVMe instance on CoolVDS today and build your fortress in Oslo.