Multi Cloud Architecture

Design multi-cloud architectures using a decision framework to select and integrate services across AWS, Azure, GCP, and OCI. Use when building multi-cloud systems, avoiding vendor lock-in, or leveraging best-of-breed services from multiple providers.

Published by @Seth Hobson·from wshobson/agents·0 agent reads / 30d·0 saves·

Multi-Cloud Architecture

Decision framework and patterns for architecting applications across AWS, Azure, GCP, and OCI.

Purpose

Design cloud-agnostic architectures and make informed decisions about service selection across cloud providers.

When to Use

  • Design multi-cloud strategies
  • Migrate between cloud providers
  • Select cloud services for specific workloads
  • Implement cloud-agnostic architectures
  • Optimize costs across providers

Cloud Service Comparison

Compute Services

AWSAzureGCPOCIUse Case
EC2Virtual MachinesCompute EngineComputeIaaS VMs
ECSContainer InstancesCloud RunContainer InstancesContainers
EKSAKSGKEOKEKubernetes
LambdaFunctionsCloud FunctionsFunctionsServerless
FargateContainer AppsCloud RunContainer InstancesManaged containers

Storage Services

AWSAzureGCPOCIUse Case
S3Blob StorageCloud StorageObject StorageObject storage
EBSManaged DisksPersistent DiskBlock VolumesBlock storage
EFSAzure FilesFilestoreFile StorageFile storage
GlacierArchive StorageArchive StorageArchive StorageCold storage

Database Services

AWSAzureGCPOCIUse Case
RDSSQL DatabaseCloud SQLMySQL HeatWaveManaged SQL
DynamoDBCosmos DBFirestoreNoSQL DatabaseNoSQL
AuroraPostgreSQL/MySQLCloud SpannerAutonomous DatabaseDistributed SQL
ElastiCacheCache for RedisMemorystoreOCI CacheCaching

Reference: See references/service-comparison.md for complete comparison

Multi-Cloud Patterns

Pattern 1: Single Provider with DR

  • Primary workload in one cloud
  • Disaster recovery in another
  • Database replication across clouds
  • Automated failover

Pattern 2: Best-of-Breed

  • Use best service from each provider
  • AI/ML on GCP
  • Enterprise apps on Azure
  • Regulated data platforms on OCI
  • General compute on AWS

Pattern 3: Geographic Distribution

  • Serve users from nearest cloud region
  • Data sovereignty compliance
  • Global load balancing
  • Regional failover

Pattern 4: Cloud-Agnostic Abstraction

  • Kubernetes for compute
  • PostgreSQL for database
  • S3-compatible storage (MinIO)
  • Open source tools

Cloud-Agnostic Architecture

Use Cloud-Native Alternatives

  • Compute: Kubernetes (EKS/AKS/GKE/OKE)
  • Database: PostgreSQL/MySQL (RDS/SQL Database/Cloud SQL/MySQL HeatWave)
  • Message Queue: Apache Kafka or managed streaming (MSK/Event Hubs/Confluent/OCI Streaming)
  • Cache: Redis (ElastiCache/Azure Cache/Memorystore/OCI Cache)
  • Object Storage: S3-compatible API
  • Monitoring: Prometheus/Grafana
  • Service Mesh: Istio/Linkerd

Abstraction Layers

Application Layer
    ↓
Infrastructure Abstraction (Terraform)
    ↓
Cloud Provider APIs
    ↓
AWS / Azure / GCP / OCI

Cost Comparison

Compute Pricing Factors

  • AWS: On-demand, Reserved, Spot, Savings Plans
  • Azure: Pay-as-you-go, Reserved, Spot
  • GCP: On-demand, Committed use, Preemptible
  • OCI: Pay-as-you-go, annual commitments, burstable/flexible shapes, preemptible instances

Cost Optimization Strategies

  1. Use reserved/committed capacity (30-70% savings)
  2. Leverage spot/preemptible instances
  3. Right-size resources
  4. Use serverless for variable workloads
  5. Optimize data transfer costs
  6. Implement lifecycle policies
  7. Use cost allocation tags
  8. Monitor with cloud cost tools

Reference: See references/multi-cloud-patterns.md

Migration Strategy

Phase 1: Assessment

  • Inventory current infrastructure
  • Identify dependencies
  • Assess cloud compatibility
  • Estimate costs

Phase 2: Pilot

  • Select pilot workload
  • Implement in target cloud
  • Test thoroughly
  • Document learnings

Phase 3: Migration

  • Migrate workloads incrementally
  • Maintain dual-run period
  • Monitor performance
  • Validate functionality

Phase 4: Optimization

  • Right-size resources
  • Implement cloud-native services
  • Optimize costs
  • Enhance security

Best Practices

  1. Use infrastructure as code (Terraform/OpenTofu)
  2. Implement CI/CD pipelines for deployments
  3. Design for failure across clouds
  4. Use managed services when possible
  5. Implement comprehensive monitoring
  6. Automate cost optimization
  7. Follow security best practices
  8. Document cloud-specific configurations
  9. Test disaster recovery procedures
  10. Train teams on multiple clouds

Related Skills

  • terraform-module-library - For IaC implementation
  • cost-optimization - For cost management
  • hybrid-cloud-networking - For connectivity

Bundled with this artifact

3 files

Reference files that ship alongside this artifact. Agents pull these in only when the task needs them.

More on the bench

SKILL0

Oncall Runbook

Write an on-call runbook for a service — covering alert definitions, escalation paths, common incident responses, and on-call handoff procedures. Use when asked to write an on-call guide, create alert runbooks, document escalation procedures, or prepare an on-call handoff document. Produces a structured on-call runbook with per-alert response procedures, escalation matrix, diagnostic commands, and handoff template.

software-engineering+2
1
SKILL0

Monitoring Setup Guide

Write a monitoring setup guide for a service — defining what to measure, how to alert on it, and how to build the observability stack covering the four golden signals, business metrics, log strategy, distributed tracing, alerting rules, dashboard layout, and observability debt. Use when asked to set up monitoring for a service, define alerting strategy, write an observability plan, create a dashboard specification, or document logging standards for a team. Produces a metric definitions table, alert rules specification, dashboard layout wireframe, log schema, tracing setup checklist, and monitoring gap analysis.

software-engineering+2
1
SKILL0

CI CD Pipeline Builder

Generate pragmatic CI/CD pipelines from detected project stack signals — fast baseline generation, repeatable checks, environment-aware deployment stages. Use when setting up CI for a new project, refactoring existing pipelines, or standardizing deployment workflows across multiple repos.

software-engineering+2
1