Multi-Cloud Architecture Design Principles and Practical Operations Strategy

Why Adopt Multi-Cloud

• Avoid vendor lock-in: Preserve negotiating leverage and spread outage risk
• Regulatory compliance: Data sovereignty requirements (certain data must be stored in a specific country)
• Best-of-breed services: Combine AWS Lambda + GCP BigQuery
• Disaster recovery: Fail over to another cloud if one cloud goes down

Architecture Patterns

Application Distribution Pattern

[AWS] Web/app servers, RDS, CloudFront CDN
[GCP] BigQuery analytics, ML/AI, Looker dashboards
        └──── VPN/dedicated interconnect ────┘

Active-Active High Availability

Users
  ├── [AWS ap-northeast-2] → App servers → DB (Primary)
  └── [Azure Korea Central] → App servers → DB (Replica)

Global load balancer: Cloudflare / Route 53

Disaster Recovery Tiers

Cloud-Neutral Abstraction

# Bad example: using the AWS SDK directly
import boto3
boto3.client('s3').upload_file('file.txt', 'bucket', 'file.txt')

# Good example: an abstraction layer
class ObjectStorage:
    def upload(self, local_path, remote_path): ...

class AWSS3(ObjectStorage):
    def upload(self, local, remote):
        boto3.client('s3').upload_file(local, 'bucket', remote)

class GCS(ObjectStorage):
    def upload(self, local, remote):
        storage.Client().bucket('b').blob(remote).upload_from_filename(local)

storage = AWSS3() if os.getenv('CLOUD') == 'aws' else GCS()

Unified Monitoring

# Prometheus multi-cloud configuration
scrape_configs:
  - job_name: 'aws-nodes'
    ec2_sd_configs:
    - region: ap-northeast-2
      port: 9100

  - job_name: 'gcp-nodes'
    gce_sd_configs:
    - project: my-gcp-project
      zone: asia-northeast3-a
      port: 9100

Multi-Cloud Pitfalls

Pitfall 1: Underestimating operational complexity You need experts for both clouds.

Pitfall 2: Cross-cloud data transfer costs Services that talk to each other frequently should live in the same cloud.

Pitfall 3: Untested disaster recovery Without regular DR drills, failover will not work when you need it.

Multi-cloud means paying a complexity tax in exchange for flexibility. Adopt it only when the business requirements are clear.

Diagnosing Cross-Cloud Connectivity Failures

The hardest multi-cloud failures to diagnose are those that work inside each cloud but fail only between clouds.

Causes

• Overlapping VPC/VNet CIDRs send routing one way only
• The VPN tunnel is up, but route advertisement (BGP) covers only some ranges
• One side's security group or firewall is open, but the other side's NSG/firewall rule is missing
• A small MTU somewhere on the path fails only large packets (small requests work, large responses hang)

Diagnosis

# path trace and per-hop loss
mtr -rwc 50 10.20.1.15
# MTU check: set DF and shrink the size until it passes (Linux)
ping -M do -s 1372 -c 3 10.20.1.15
# port-level connectivity
nc -vz -w 3 10.20.1.15 5432

In the cloud consoles, check VPN tunnel status, learned BGP routes, and REJECT/Deny records in flow logs on both sides.

Fix and prevention

• Allocate CIDR ranges per cloud centrally at design time, and tune MSS/MTU on tunnel interfaces to fit the path.
• Put synthetic monitoring (periodic TCP connection tests) on key cross-cloud links to detect segment failures first.