Week 19: Multi-Cloud Fundamentals — Azure & GCP Core Services

1. Azure Core Services

Azure's organizing unit is the resource group — a logical container for everything belonging to one project or environment, roughly analogous to tagging everything the same way in AWS, except a resource group is a first-class object you can delete wholesale to tear down everything inside it at once.

IAM users/roles → Microsoft Entra ID (formerly Azure AD) + RBAC role assignments. Azure RBAC assigns built-in or custom roles at the subscription / resource-group / resource scope — closer to AWS's policy-attached-to-a-scope model than it first looks.
VPC → Virtual Network (VNet). Subnets and route tables work almost identically; Network Security Groups (NSGs) play the security-group role.
EC2 → Virtual Machines. VM Scale Sets are the rough equivalent of an Auto Scaling Group.
S3 → Blob Storage. Containers (Blob's "bucket") support Hot/Cool/Archive access tiers, a closer analog to S3's storage classes than a separate service.
EKS → Azure Kubernetes Service (AKS). Same upstream Kubernetes; AKS's control plane is free, unlike EKS's per-cluster hourly charge.

terminal — the Azure CLI equivalent of an EC2 launch

az group create --name capstone-rg --location eastus

az vm create \
  --resource-group capstone-rg \
  --name capstone-vm \
  --image Ubuntu2204 \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys

Notice the shape is identical to the aws ec2 run-instances workflow from Week 8 — a resource group instead of "everything tagged the same," a VM size instead of an instance type, but the same underlying decisions: which image, how much compute, which network.

2. GCP Core Services

GCP's organizing unit is the project — every resource, and every billing record, belongs to exactly one project, which is a stricter boundary than AWS's account-plus-tags or Azure's resource group.

IAM users/roles → Cloud IAM (predefined & custom roles). GCP IAM roles bind directly to a project/folder/organization hierarchy; there's no separate "role" object attached after the fact the way an EC2 instance profile is — bindings are declared against the resource.
VPC → VPC (same name). A GCP VPC is global by default — one VPC can span every region without peering, unlike AWS where a VPC is regional and cross-region needs peering or Transit Gateway.
EC2 → Compute Engine. Managed Instance Groups are the Auto Scaling Group equivalent.
S3 → Cloud Storage. Storage classes (Standard/Nearline/Coldline/Archive) map closely to S3's; bucket names are globally unique across all of GCP, same constraint as S3.
EKS → Google Kubernetes Engine (GKE). GKE originated Kubernetes' upstream development at Google — its Autopilot mode manages node provisioning for you entirely, closer to Fargate-for-Kubernetes than EKS's default node-group model.

terminal — the gcloud CLI equivalent of an EC2 launch

gcloud projects create capstone-project --name="Capstone"
gcloud config set project capstone-project

gcloud compute instances create capstone-vm \
  --zone=us-central1-a \
  --machine-type=e2-small \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud

The mental model transfers faster than the exact commands

You don't need to memorize gcloud or az syntax the way you know aws — what actually transfers, and what an interviewer is checking for, is recognizing "this is their VPC, this is their IAM, this is their managed Kubernetes" quickly enough to be productive reading someone else's Terraform for a cloud you haven't used daily.

3. Why (and When) Teams Go Multi-Cloud

"Multi-cloud" gets pitched as vendor-independence, but the honest version is more specific and much less common in practice than the marketing suggests. Real reasons teams end up running infrastructure across two providers:

Acquisition — by far the most common real-world cause: Company A runs on AWS, acquires Company B running on GCP, and unifying onto one cloud is a multi-year, high-risk migration nobody wants to prioritize immediately.
Best-of-breed for a specific workload — using GCP's BigQuery for a data warehouse while the rest of the stack stays on AWS, because BigQuery's serverless query performance is worth the operational cost of a second cloud for that one workload.
Regulatory or contractual requirement — a customer or jurisdiction that mandates infrastructure not be concentrated with a single vendor.
Negotiating leverage — genuine multi-cloud capability strengthens a large enterprise's position when renegotiating an Enterprise Discount Program with any one vendor.

What multi-cloud is not, in almost all real organizations: running the same application actively on two clouds simultaneously "just in case one goes down." The engineering cost of that — every service needs to work identically against two sets of APIs, every Terraform module needs two providers, every team needs fluency in both — is enormous, and outages severe enough to justify it are rare enough that most companies accept the risk instead of paying that tax continuously.

Kubernetes is the actual portability layer, not the cloud provider's API

The reason EKS, AKS and GKE all matter to learn is that a workload running on Kubernetes is close to portable between them almost for free — the same Deployment, Service and Ingress manifests apply with minor changes. The real multi-cloud strategy most teams use in practice is standardizing on Kubernetes as the abstraction layer, not writing application code against each cloud's native SDK directly.

4. Hands-on Exercise

Hands-on

Stand up the same workload's building blocks on Azure and GCP's free tiers

Reproduce a small piece of your Week 8 AWS setup on both other clouds.

Requirements:

Create a free-tier Azure account, create a resource group and a small VM inside it, and connect over SSH.
Create a free-tier GCP account, create a project, and launch a Compute Engine instance in it.
Upload a file to Blob Storage on Azure and to Cloud Storage on GCP, and note the access-tier/storage-class option each offers.
Write a short comparison table (reuse the format from Sections 1–2) mapping every AWS service you've used in this course to its Azure and GCP equivalent, from memory first, then check against the official docs.
Tear down every resource on both clouds when you're done to avoid any ongoing charges.

Hint

az group delete --name capstone-rg --yes and gcloud projects delete capstone-project are the fastest full teardowns — deleting the resource group or project cascades to everything inside it, the same "one command tears it all down" property Terraform gives you within a single cloud.

5. Knowledge Check

Three quick questions. Expand each to check your answer.

What's the key structural difference between how a GCP VPC and an AWS VPC relate to regions?

An AWS VPC is scoped to a single region, and connecting resources across regions requires VPC peering or a Transit Gateway. A GCP VPC is global by default — subnets within it can span every region with no peering required, which changes how you'd design cross-region connectivity compared to AWS.

What's the most common real-world reason a company ends up running infrastructure on two clouds?

Acquisition — one company on AWS acquiring another already built on GCP or Azure, after which fully migrating onto a single cloud is a large, risky, multi-year project few organizations prioritize immediately. This is far more common in practice than deliberately designing a new system to actively run across two clouds simultaneously for redundancy.

Why is Kubernetes described as "the actual portability layer" for teams pursuing multi-cloud, rather than each cloud's native SDK?

A workload expressed as standard Kubernetes Deployments, Services and Ingress manifests runs with only minor changes on EKS, AKS or GKE, because all three run the same upstream Kubernetes API. Writing application code directly against a specific cloud's native SDK (its exact IAM, storage, or queueing APIs) ties that code to one provider in a way Kubernetes manifests largely don't.