Building a GDPR-Proof Multi-Cloud Architecture: Beyond the AWS Hype

Let’s be honest about the state of cloud computing in 2023. If you are a CTO or Lead Architect operating in Norway, you are currently stuck between a rock and a hard place. On one side, you have the hyperscalers (AWS, Azure, GCP) offering infinite scalability but charging exorbitant egress fees and posing constant Schrems II compliance headaches. On the other side, you have on-premise hardware which is capital intensive and painful to scale.

The solution isn't to abandon the public cloud, nor is it to go 'all-in' on a single vendor. The pragmatic move is a Hybrid Multi-Cloud Strategy. We keep the data heavy, compliance-critical workloads on sovereign Norwegian infrastructure—like CoolVDS—and use hyperscalers strictly for what they are good at: bursting compute and global CDN edges.

This isn't just theory. Below is the technical blueprint, including the configuration of encrypted mesh networking and load balancing, to build a resilient, cost-effective infrastructure that keeps the Datatilsynet happy.

The Architecture: Core-to-Edge

The concept is simple. Your "Stateful Core" lives in Oslo. This includes your primary PostgreSQL databases, Redis clusters, and backend APIs processing sensitive user data. This ensures low latency (sub-2ms) for your Norwegian user base and strict GDPR adherence. Your "Stateless Edge" lives on AWS or Google Cloud, handling ephemeral workloads like image processing or sudden traffic spikes.

Pro Tip: The biggest hidden cost in multi-cloud is data egress. Hyperscalers charge you to move data out. By keeping your primary database on CoolVDS, you avoid paying AWS to retrieve your own data. You only pay for the computed results sent to the client.

Step 1: The Encrypted Mesh (WireGuard)

Legacy IPsec VPNs are bloated and slow. In 2023, the standard for interconnecting clouds is WireGuard. It lives in the Linux kernel (5.6+), offering higher throughput and lower CPU usage. We need to link a CoolVDS instance in Oslo with an AWS EC2 instance in Frankfurt.

Here is a production-ready wg0.conf for the Oslo hub. Note the use of PersistentKeepalive to punch through NATs.

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

# Peer: AWS Frankfurt Node
[Peer]
PublicKey = [AWS_NODE_PUBLIC_KEY]
AllowedIPs = 10.0.0.2/32
Endpoint = 35.158.xx.xx:51820
PersistentKeepalive = 25

To bring this interface up without installing heavy network managers:

On a standard CoolVDS NVMe instance, we benchmark WireGuard throughput at near line-speed because we don't oversell CPU cycles. This is critical when you are replicating database WAL files across the tunnel.

Step 2: Traffic Steering with HAProxy

Once the network is bridged, we need to route traffic intelligently. We use HAProxy 2.6+ to split traffic. Read requests can go to local read-replicas, while heavy processing jobs are routed to the cloud.

This configuration defines a backend that prioritizes the local Norwegian servers and only fails over to the cloud if the local capacity is exhausted or down.

global
    log /dev/log local0
    maxconn 4096
    user haproxy
    group haproxy

defaults
    log     global
    mode    http
    option  httplog
    timeout connect 5000
    timeout client  50000
    timeout server  50000

frontend main_ingress
    bind *:80
    bind *:443 ssl crt /etc/haproxy/certs/site.pem
    acl is_api path_beg /api
    use_backend oslo_core if is_api
    default_backend aws_edge

backend oslo_core
    balance roundrobin
    option httpchk GET /health
    # CoolVDS instances in Oslo - Low Latency
    server core-01 10.0.1.10:80 check inter 2s rise 2 fall 3
    server core-02 10.0.1.11:80 check inter 2s rise 2 fall 3

backend aws_edge
    balance leastconn
    # AWS Instances over WireGuard tunnel
    server aws-fra-01 10.0.0.2:80 check inter 5s
    server aws-fra-02 10.0.0.3:80 check inter 5s

Step 3: Infrastructure as Code (Terraform)

Managing hybrid environments manually is a recipe for disaster. We use Terraform to define the state. While AWS has a dedicated provider, for generic VPS providers (like CoolVDS) or on-prem hardware, we use the remote-exec provisioner or the libvirt provider if accessible. In this example, we bootstrap the CoolVDS node to prepare it for the cluster.

resource "aws_instance" "edge_node" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  tags = {
    Name = "Edge-Frankfurt"
  }
}

resource "null_resource" "coolvds_core" {
  connection {
    type     = "ssh"
    user     = "root"
    host     = var.coolvds_ip
    private_key = file("~/.ssh/id_rsa")
  }

  provisioner "remote-exec" {
    inline = [
      "apt-get update",
      "apt-get install -y wireguard haproxy",
      "sysctl -w net.ipv4.ip_forward=1",
      "echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf"
    ]
  }
}

output "vpn_endpoint" {
  value = aws_instance.edge_node.public_ip
}

The Database Consistency Challenge

Running a split-brain architecture requires careful database management. For PostgreSQL 15, we utilize Streaming Replication over the WireGuard tunnel. However, latency between Oslo and Frankfurt (approx. 20-30ms) means synchronous replication will kill your write performance.

We configure asynchronous replication. To ensure we don't lose data during a network partition, we adjust the wal_keep_size in postgresql.conf to retain enough WAL segments to handle a few hours of downtime.

Why Local Infrastructure Matters

There is a misconception that "The Cloud" exists everywhere. It doesn't. It exists in specific data centers. For a business targeting Norway, hosting in a data center in Ireland or Frankfurt introduces inevitable latency. When your application requires real-time interaction or high-frequency trading data, that 30ms round-trip time accumulates.

This is where CoolVDS acts as the anchor. By peering directly at NIX (Norwegian Internet Exchange), we offer single-digit millisecond latency to Norwegian ISPs. You get the raw performance of NVMe storage and dedicated KVM resources without the "noisy neighbor" effect often found in container-based hyperscale instances.

Final Thoughts

A multi-cloud strategy is not about complexity; it's about optionality. It gives you the leverage to negotiate with vendors and the technical assurance that your data remains sovereign. By combining Terraform for orchestration, WireGuard for security, and a high-performance regional host like CoolVDS, you build a fortress, not just a server stack.

Stop paying for latency. Deploy your core infrastructure where your users are.