"Multi-cloud" gets thrown around as if clouds were interchangeable once you know one. They are not, but they are also not as different as vendor marketing wants you to believe. The only way to find out where the real line sits is to deploy the same thing three times and pay attention to what actually transferred. So I took one containerized app and pushed it to AWS, Azure, and GCP in the same afternoon. Here is exactly what carried over and what did not.
The same container, three CLIs
# AWS: push to ECR, deploy to App Runner
aws ecr create-repository --repository-name demo-app
docker push <account>.dkr.ecr.us-east-1.amazonaws.com/demo-app:v1
aws apprunner create-service --service-name demo-app --source-configuration file://source.json
# Azure: push to ACR, deploy to Container Apps
az acr create --name demoacr --resource-group demo-rg --sku Basic
docker push demoacr.azurecr.io/demo-app:v1
az containerapp create --name demo-app --resource-group demo-rg --image demoacr.azurecr.io/demo-app:v1
# GCP: push to Artifact Registry, deploy to Cloud Run
gcloud artifacts repositories create demo-repo --repository-format=docker --location=us-central1
docker push us-central1-docker.pkg.dev/PROJECT/demo-repo/demo-app:v1
gcloud run deploy demo-app --image us-central1-docker.pkg.dev/PROJECT/demo-app:v1
Three completely different command syntaxes. If you only measure "how many new commands did I type," multi-cloud looks brutal. That is the wrong measurement.
What actually transferred
The concepts did, almost entirely. Every one of these deployments needed the same mental checklist:
- A container registry, authenticated before push
- A managed compute layer that pulls from that registry and runs the container
- Environment variables and secrets injected at deploy time, not baked into the image
- A public endpoint with HTTPS handled for me
- Logs and basic metrics available without extra setup
Once I had that checklist in my head from the AWS pass, the Azure and GCP passes were mostly "find the equivalent command," not "relearn the idea." The second cloud took under half the time of the first. The third took less than that.
What did not transfer, and cost real time
IAM was the honest exception. AWS IAM policies, Azure RBAC role assignments, and GCP IAM bindings are conceptually similar, permissions attached to identities, but the syntax, the scoping model, and the default-deny versus default-allow behavior differ enough that I made a real mistake on each cloud the first time through: an over-permissive service account here, a missing role binding there. Networking defaults were the second exception; what counts as "publicly reachable by default" is not the same answer on all three.
# The three IAM mental models, compressed
# AWS: attach a policy document to a role, mostly allow-by-exception
# Azure: assign a built-in or custom role to a principal at a scope (sub/RG/resource)
# GCP: bind a role to a member on a resource, IAM is closer to the surface everywhere
What this means for how you should actually train
If a course teaches "AWS from scratch," "Azure from scratch," and "GCP from scratch" as three unrelated modules, it is teaching the syntax three times and the concepts zero times, which is the slow way to get multi-cloud competent. The efficient path is the opposite: learn the concepts once, deep, on whichever cloud your job actually uses, then treat every additional cloud as a syntax-and-IAM problem, not a fresh start. That is a very different training design than most bootcamps run, and it is worth knowing which kind of program you are signing up for before you pay.
This distinction matters even more once you are past learning for yourself and into upskilling a whole team, where the cost of teaching three clouds as three separate courses multiplies fast. If that is the situation you are in, how corporate cloud training for development teams in Pakistan actually approaches this differently is worth reading before you scope a training budget.
I wrote up the complete case for why multi-cloud training is where the market is heading, and what a well-designed multi-cloud curriculum actually looks like, over here: Why Multi-Cloud Training Is the Future: Pakistan's Cloud Academy Landscape.
If you've deployed to more than one cloud, was IAM the thing that tripped you up too, or was it something else? Drop it in the comments. 👇
Top comments (0)