Every "AWS to Azure to GCP" cheat sheet does the same thing: it gives you a table. S3 equals Blob Storage. EC2 equals Compute Engine. Done, ship it.
Except it's not done. The table tells you where to start, not where you'll get burned.
Where it actually breaks
Take storage. S3 is flat: bucket, then objects. Azure inserts a Storage Account above the container, and that account is where networking rules, access keys, and replication settings actually live. Port an S3-shaped Terraform module over without accounting for that layer, and you'll spend an afternoon figuring out why your access policies don't apply where you expect.
Or take networking. An AWS VPC is regional. A GCP VPC is global by default. "Just create a VPC" means two completely different blast radii depending on which cloud you're standing in.
The one that actually matters for security people: aws_iam_role doesn't map to an Azure resource at all. Azure's permission model is structurally different, role assignments work differently, service principals aren't IAM roles wearing a different name. Treating them as equivalent is where real misconfigurations come from, not typos.
Why I built Cloud Rosetta
I work in cloud infrastructure day to day, and I kept hitting these gaps mid-project, usually the expensive way. So I built a dictionary that does what the comparison charts don't: for each concept, it names the equivalent across AWS, Azure, and GCP, explains specifically where the analogy breaks, and links the actual Terraform resource for each provider so you can go verify instead of trusting me.
It's a single self-contained HTML file, no tracker, works offline, and the dictionary itself is open to PRs, especially from people with production scars on whichever cloud is the "minority" one in a given entry.
Live site: https://edeak54.github.io/cloud-rosetta/
Source: https://github.com/edeak54/cloud-rosetta
If you've been burned by an analogy that didn't hold, open an issue, that's exactly the kind of entry this needs more of.
Top comments (0)