Part 7 · 2 chapters · ~15 min

AWS and GCP Side by Side

One wallet API built on both clouds tier by tier, with a service map that includes Azure for reference; then the five differences that actually change designs: network scope, organisation and identity, load balancer scope, serverless containers and analytics, and what exists in Africa.

20

The same design, service by service

one product, two clouds
  1. Edge and web: a CDN in front of a private bucket, with a WAF.
  2. Compute and load balancing: Fargate behind a regional ALB, or Cloud Run behind a global ALB.
  3. Data: managed Postgres with HA plus managed Redis, reachable privately only.
  4. Storage and events: signed URLs, a queue with dead-lettering, and a stream into analytics.
  5. Identity: roles or service accounts per service, a secret store and KMS.
  6. Observability: each provider's stack, or OpenTelemetry to a vendor.
needAWSGCPAzure (for reference)
VMsEC2Compute EngineVirtual Machines
managed KubernetesEKSGKE (Autopilot)AKS
serverless containersFargate, App RunnerCloud RunContainer Apps
functionsLambdaCloud FunctionsFunctions
object storageS3Cloud StorageBlob Storage
managed PostgresRDS, AuroraCloud SQL, AlloyDBDatabase for PostgreSQL
key-value / documentDynamoDBFirestore, BigtableCosmos DB
cacheElastiCache, MemoryDBMemorystoreCache for Redis
queueSQSCloud Tasks, Pub/SubService Bus, Queue Storage
streamKinesis, MSKPub/Sub, Managed KafkaEvent Hubs
warehouseRedshift, AthenaBigQuerySynapse, Fabric
CDNCloudFrontCloud CDN, Media CDNFront Door
DNSRoute 53Cloud DNSAzure DNS
secrets / keysSecrets Manager / KMSSecret Manager / Cloud KMSKey Vault
IaC (native)CloudFormation, CDKInfrastructure Manager (Terraform)Bicep, ARM
observabilityCloudWatch, X-RayCloud Logging, Monitoring, TraceMonitor, App Insights
deeper
The older Deploying The Core Bank module builds one specific system, a core bank, on both clouds and prices it. This chapter is the general map; that module is the worked example.
ONE DESIGN, TWO CLOUDS
a wallet API with uploads, events and a ledger, built on AWS and on GCP, tier by tier
swipe the figure sideways, or tap expand for full screen
1/6
edge, web
Edge and web: AWS CloudFront in front of an S3 bucket (origin access control) for the static app, with AWS WAF; GCP Cloud CDN behind the global external Application Load Balancer with a GCS backend bucket, with Cloud Armor. Both terminate TLS at the edge with managed certificates.
21

Where the clouds really differ

five differences that change designs
  1. Network scope: AWS VPCs are regional; GCP VPC networks are global.
  2. Organisation: AWS uses accounts as the boundary; GCP uses a project hierarchy with inherited IAM.
  3. Load balancing: GCP's front end is global anycast; AWS ALBs are regional.
  4. Serverless containers: Cloud Run is the GCP default. AWS splits the same job across three services.
  5. Analytics: BigQuery and Spanner are GCP's distinctive services.
  6. In Africa: both clouds have South African regions and West African edge locations. Check service availability before choosing a region.
multi-cloud
Running one product actively on two clouds doubles the platform work and keeps you to the services both share. It is rarely worth it for availability, since a second region on one cloud is cheaper and simpler. It is sometimes worth it for regulation, negotiation leverage, or a service only one cloud has. Portability through containers, Terraform, OpenTelemetry and Postgres is cheap insurance. Active multi-cloud is an expensive policy.
WHERE THE CLOUDS REALLY DIFFER
the five differences that change designs, not just service names
swipe the figure sideways, or tap expand for full screen
1/6
network scope
Network scope: an AWS VPC lives in one region, with subnets per zone; going multi-region means a VPC per region and connecting them. A GCP VPC network is global, with subnets per region; instances in europe-west1 and africa-south1 share one private network out of the box. Multi-region private networking is simpler on GCP.