AWS Egress $28,000 — GCP Global VPC Cuts Cost 40%

Choosing a cloud provider is no longer just about virtual machines; it's about choosing an ecosystem. AWS, Azure, and GCP each offer a unique philosophy toward infrastructure, data, and developer experience. While they all provide the fundamental building blocks of modern computing—compute, storage, and networking—the way they implement identity, global networking, and managed services varies significantly.

In this guide, we'll break down the architectural nuances of the 'Big Three,' why they were designed with different priorities, and how to navigate their CLI tools to manage resources. By the end, you'll have the technical perspective needed to make an informed multi-cloud or single-cloud decision for your production workloads.

The most important insight that separates senior engineers from the rest? Egress pricing. AWS charges $0.09/GB inter-region. GCP's global VPC eliminates that cost entirely for traffic on its backbone. For a 2PB/month workload, that's $160,000 difference. Not a rounding error — a hiring decision.

Why Cloud Provider Choice Is a Cost Architecture Decision

AWS, GCP, and Azure are cloud platforms that offer compute, storage, and networking services, but their egress pricing and network topology differ radically. The core mechanic: every byte leaving a cloud region incurs a cost, and each provider charges differently for cross-region, cross-VPC, and internet-bound traffic. GCP’s global VPC treats the entire network as a flat fabric, so inter-region traffic uses Google’s backbone at no extra charge beyond standard compute rates. AWS and Azure charge per-GB egress between VPCs and regions, often $0.05–$0.12/GB, which can balloon to $28,000 for 200 TB/month.

In practice, GCP’s single VPC spans regions with internal IPs, eliminating the need for transit gateways or VPC peering costs. AWS requires explicit VPC peering or Transit Gateway attachments, each with per-GB processing fees. Azure uses virtual network peering with similar egress charges. The key property: GCP’s model makes multi-region architectures cost-linear with compute, not super-linear with data movement. For data-heavy workloads like media processing, ML training, or database replication, this difference dominates total cloud bill.

Use GCP when your system moves large volumes of data between regions — think global CDN backends, cross-region analytics pipelines, or disaster recovery replication. Use AWS or Azure when you need specific managed services (Lambda, DynamoDB, AKS) or regulatory compliance zones GCP lacks. The decision isn’t about feature count; it’s about whether your data gravity makes egress the dominant cost driver.

Core Philosophy and Market Position

Each cloud provider started from a different origin, and that history drives their current strengths and weaknesses.

AWS (Amazon, 2006): Launched as an internal infrastructure platform for Amazon's retail operations. The philosophy is 'primitive-first' — offer building blocks that can be composed any way. This leads to breadth over simplicity. AWS has over 200 services, from machine learning (SageMaker) to satellite ground stations (Ground Station). The downside: steep learning curve and complex pricing. Over 80% of enterprises use AWS as their primary cloud.

Azure (Microsoft, 2010): Built to leverage Microsoft's enterprise footprint. The philosophy is 'hybrid-first' — seamless integration with on-premises Active Directory (now Entra ID), Windows Server, SQL Server, and Office 365. Ideal for organizations with existing Microsoft Enterprise Agreements (EAs). The Azure Hybrid Benefit can reduce Windows Server and SQL Server licensing costs by up to 80% compared to other clouds. Second-largest cloud provider, dominant in Fortune 500.

GCP (Google, 2011): Born from Google's internal infrastructure (Borg, Colossus, Spanner). The philosophy is 'data-first' — leverage Google's expertise in AI/ML, big data, and container orchestration. GCP effectively invented Kubernetes (K8s) before open-sourcing it in 2014. The networking layer (global VPC) is unmatched, keeping traffic on Google's private fiber backbone. Third-largest cloud provider but fastest-growing segment in data analytics and AI.

# io.thecodeforge: Standardizing Resource Creation across CLIs

# AWS: Create an EC2 Instance (t3.micro is the modern burstable standard)
aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --count 1 \
    --instance-type t3.micro \
    --key-name ForgeKeyPair \
    --security-group-ids sg-0858102434db6c694

# Azure: Create a VM with a focused Resource Group
az vm create \
    --resource-group ForgeProdRG \
    --name ForgeWorkerVM \
    --image Ubuntu2204 \
    --size Standard_B1s \
    --admin-username forgeadmin \
    --generate-ssh-keys

# GCP: Create a GCE Instance with high-performance networking
gcloud compute instances create forge-app-node \
    --project=thecodeforge-prod \
    --zone=us-central1-a \
    --machine-type=e2-micro \
    --network-interface=network-tier=PREMIUM,stack-type=IPV4_ONLY \
    --image-family=debian-11 \
    --image-project=debian-cloud

Compute Comparison: EC2 vs Azure VM vs GCE — Spot Instances and Burstable Pricing

Each provider's compute service reflects its design goals. AWS EC2 offers the broadest selection of instance families, including FPGAs (F1), GPU (P4), and Graviton ARM instances. Azure VMs deeply integrate with Windows licenses and offer Reserved Instances with Azure Hybrid Benefit to reduce Windows Server costs. GCE stands out with custom machine types (pick exact vCPU/memory), sustained-use discounts (automatically scale down), and preemptible VMs at up to 90% discount.

Burstable performance: AWS T-family (t3, t4g) uses CPU credits; Azure B-series uses credits; GCP E2-micro/nano have no burst credits — they're always throttled. T3 unlimited mode allows bursting beyond credit balance at extra cost.

For containerized workloads, GKE runs most efficiently due to Google's Borg lineage; AWS EKS and Azure AKS are close competitors but require more manual tuning for pod density. GKE Autopilot (serverless Kubernetes) eliminates node management entirely — unique among providers.

# io.thecodeforge: Compute resource definitions for comparison

resource "aws_instance" "forge_app" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.large"
  # no preemptible option natively in AWS; use Spot
}

resource "azurerm_linux_virtual_machine" "forge_app" {
  name                = "forge-app-vm"
  resource_group_name = azurerm_resource_group.example.name
  location            = "East US"
  size                = "Standard_DS2_v2"
  admin_username      = "forgeadmin"
  network_interface_ids = []
}

resource "google_compute_instance" "forge_app" {
  name         = "forge-app-instance"
  machine_type = "e2-standard-2"
  zone         = "us-central1-a"
  allow_stopping_for_update = true
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }
}

Regions and Zones: Where Your Latency and Your Budget Sleep Together

Cloud providers charge different prices for the same compute in different geographic locations. That’s not a footnote; it’s a fist fight with your finance team. AWS’s us-east-1 is cheap because it’s old and crowded. Azure’s Brazil South is expensive because they had to lay undersea cable. GCP’s us-west1 is a steal if your users are on the West Coast. The real trap? Data egress. Moving traffic between regions costs real money. One misrouted backup job can burn through your monthly margin. You pick a primary region based on user latency, but you pick a DR region based on data transfer costs and regulatory compliance. Always calculate egress in your TCO model before you sign. And don’t assume zones within a region are free—they’re not. GCP charges for cross-zone traffic. AWS gives you a few TB free. Azure’s pricing is a spreadsheet nightmare. Test your inter-zone data movement in a proof of failure, not a proof of concept.

// io.thecodeforge — devops tutorial

provider: gcp
project: production-finops

# Compare spot instance cost across zones in ONE region
regions:
  - name: us-west1
    zone: us-west1-a
    spot_price_hourly: 0.0065
  - name: us-west1
    zone: us-west1-b
    spot_price_hourly: 0.0072
  - name: us-west1
    zone: us-west1-c
    spot_price_hourly: 0.0081

# same machine type (e2-small) - price drifts by 20%
# Pick the cheapest zone for your batch jobs or die by a thousand cents.

Security in Google Cloud Platform: IAM Is Not a Suggestion, It’s a Fence

GCP’s security model is built on three pillars: IAM for identity, VPC Service Controls for data boundaries, and Cloud Armor for edge defense. The mistake most teams make is treating IAM like a permissions menu. It’s not. It’s an access graph that attaches to every API call. If your service account has roles/compute.admin on a project, that’s not a role—it’s a loaded weapon. GCP enforces resource-hierarchy inheritance: org -> folder -> project -> resource. If you give a folder-level viewer access, every project under it inherits that view. That’s great for org-wide observability, but deadly if you accidentally give iam.serviceAccountUser at the org level. The real production trick: use custom roles with a deny-by-default principle. And don’t forget VPC Service Controls. They prevent data exfiltration even if a service account key leaks. GCP’s Security Command Center will scream at you for unencrypted buckets and overly permissive firewall rules. Listen to it. Or wait for the audit.

// io.thecodeforge — devops tutorial

# Custom IAM role - read-only on Compute but deny on secrets
resource: google_project_iam_custom_role
name: compute_readonly_no_secrets
project: production-12345
role_id: ComputeReadOnlyNoSecrets
title: "Compute Read-Only, No Secrets"
description: "List instances, but never read Secret Manager"
permissions:
  - compute.instances.list
  - compute.instances.get
  - compute.zones.get
  # explicitly excluded: secretmanager.versions.access
stage: GA

# Attach to a service account, not a user
# Never use primitive roles (owner/editor/viewer) in production.

Implementing Cloud-Native Projects: Where the Hype Meets Your YAML

Cloud-native isn't a badge of honor. It's a hard constraint on your architecture. GCP, AWS, and Azure all offer managed Kubernetes, but they fundamentally disagree on how you should build stateless, observable systems.

AWS forces you to assemble cloud-native from Lego bricks — EKS, Fargate, App Mesh, and Cloud Map — each with its own IAM policy and bill. You own every piece, which means you also own every failure mode. GCP leans hard into Google's internal dogma: Anthos and GKE with autopilot and built-in config sync. You get less control but faster velocity if your team commits to their way. Azure pitches Azure Kubernetes Service plus Dapr as the magic abstraction layer, betting that microservices complexity needs a framework.

The real test isn't the control plane. It's how your team handles state, secrets, and RBAC across environments. Pick the provider whose native tooling punishes less for your team's weakest skill. I've seen teams burn months on AWS service mesh configs that GKE handles with two annotations. Choose the path of least config resistance.

// io.thecodeforge — devops tutorial

# Real GKE config vs EKS config for the same app
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-processor
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payment
  template:
    metadata:
      labels:
        app: payment
    spec:
      # GKE: Workload Identity for secretless auth
      serviceAccountName: payment-sa
      containers:
      - name: processor
        image: us-central1-docker.pkg.dev/prod/payment:v2.1
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-creds
              key: url

Conclusion: Your Decision Matrix Ends at Your Team's Weakest Skill

Stop comparing EC2 instance families by the penny. The cloud provider that wins is the one where your worst developer can deploy without opening a support ticket.

For startups running stateless microservices with a small SRE team: GCP. Its default IAM and GKE autopilot hide enough complexity that one senior can cover three juniors. For enterprises with regulatory baggage and a decade of Active Directory: Azure. You'll waste money on licensing, but the compliance path is paved. For teams that need every possible service and have the ops headcount to manage them: AWS. You'll pay more in engineer-hours than compute, but you'll never hit an architectural ceiling.

The decision framework is brutally simple: Count how many of your engineers can honestly explain the difference between a NAT gateway and a VPC endpoint. If the number is less than three, pick the provider that automates that decision away. If it's more, pick the one with the deepest service catalog. Everything else — regions, spot pricing, security — is just noise your finance team will blame you for later.

Ship fast, break things, but don't let your cloud choice be the thing that breaks.

// io.thecodeforge — devops tutorial

# Quick decision: evaluate your team's weakest skill
decision:
  providers:
    - name: GCP
      when: "Your team can't explain Kubernetes RBAC without a 30-minute meeting"
      risk: "Google deprecates APIs quarterly — plan for migration"
    - name: AWS
      when: "You have dedicated platform engineers who hate vendor lock-in"
      risk: "IAM policy explosion — budget 0.5 FTE just for permissions cleanup"
    - name: Azure
      when: "Your CISO mandates SSO with existing on-prem AD"
      risk: "Cost forecasting is a full-time job — Azure pricing calculator is fiction"