← All posts

AWS vs. GCP vs. Azure: Org Hierarchy, Identity, and Key Management, Mapped

Published June 11, 2026 · 3iDATA · ~13 min read

Move between clouds for long enough and you notice something: AWS, Google Cloud, and Azure all make you answer the same three questions before you ship anything real. How do I organize my accounts? Who is allowed to do what? And how are my encryption keys created and controlled? Each cloud answers identically in spirit and differently in vocabulary — and the vocabulary is where teams get lost. This post is a practical Rosetta stone: the concepts, the names in each cloud, and the places where the mental model quietly breaks.

The three problems every cloud solves

Strip away the branding and every cloud governance discussion is really about three layers stacked on top of each other:

• Structure — a hierarchy of containers (organization → grouping → workload boundary) so you can isolate environments, apply guardrails, and split the bill.
• Identity & permissions — who (or what) can perform which actions on which resources, and the guardrails that cap what any permission can ever grant.
• Key management — where cryptographic keys live, who can use them, and who can administer them (which is a separate question from who can encrypt with them).

Most teams can rattle off the pieces in the cloud they know best — AWS Organizations, OUs, accounts, IAM roles and permissions, KMS keys and key permissions; or GCP projects, service accounts, Cloud KMS, and IAM bindings. The hard part is the full picture: the layers that are easy to forget, and how each piece maps onto the other two clouds. That's what the rest of this post lays out, one layer at a time.

Layer 1 — the resource hierarchy

Every cloud has a top-level organization node, an optional middle grouping layer you nest for departments/environments, and a workload boundary that doubles as the unit of billing and blast-radius isolation. Policies set high up inherit downward in all three.

The first real difference hides here. In AWS the account is a hard isolation boundary — the default unit of blast radius — so mature AWS estates run dozens or hundreds of accounts. In GCP the project plays both roles at once: it's the grouping and the billing/isolation unit, which is why GCP has no separate "resource group" concept. Azure adds a fourth level — the resource group — that AWS and GCP don't have, sitting below the subscription as a mandatory lifecycle container you deploy and delete as a unit.

Layer 2 — preventive guardrails (the permission ceiling)

Before you grant anyone anything, each cloud lets you set an upper bound on what permissions can ever exist below a node — a ceiling that no individual grant can punch through. This is distinct from handing out access; it's the "you may never, organization-wide" layer.

AWS recently split this in two: SCPs are principal-centric ("our people can't do X") and the newer RCPs are resource-centric ("nobody — even an outside account — can touch this S3 bucket / KMS key / role unless they're in our org"). Used together they close gaps neither could alone. The mental model trap: in AWS and GCP an SCP/Org-Policy never grants anything — it only subtracts. Azure is structured differently: it cleanly separates RBAC (permissions) from Azure Policy (compliance and configuration), so the "guardrail" job is mostly Azure Policy's, while the "who can do what" job is entirely RBAC's.

Layer 3 — identity and permissions

This is the "IAM roles and permissions" and "service accounts and bindings" layer. Every cloud expresses a grant as the same triple — a principal, a role (a bundle of permissions), and a scope — but assembles it differently.

The deepest difference is where the grant lives. In AWS you mostly attach policies to the identity (a role or user), and the permission travels with them. In GCP the allow policy is attached to the resource — you grant principal P the role R on resource X, and it inherits down the hierarchy. Azure's role assignment is similar to GCP's binding but anchored to a scope in the management-group → subscription → resource-group → resource chain. Once you internalize "AWS = identity-attached, GCP/Azure = resource/scope-attached," a lot of cross-cloud confusion evaporates.

Layer 3b — workload identity (the part people forget)

Humans aren't the only principals. Your code needs an identity too, and getting this right is the single biggest lever on least privilege. The golden rule in all three clouds: never use long-lived static keys — attach a managed identity to the workload instead.

Note the naming overlap that trips everyone up: an "IAM role" in AWS is a workload identity you assume, whereas a "role" in GCP and Azure is just a permission bundle — the identity is a service account or managed identity. Same word, two different jobs. GCP service-account keys and Azure service-principal secrets exist, but both clouds now steer you hard toward keyless federation for anything running outside their perimeter.

Layer 4 — key management

Finally, the encryption layer. Each cloud has a managed key service, organizes keys in a small hierarchy, and — critically — distinguishes using a key (encrypt/decrypt) from administering a key (rotate, disable, set policy).

A genuinely current wrinkle: as of Key Vault API version 2026-02-01, Azure RBAC is the default access model for new vaults — the older per-vault "access policies" are now the legacy path, which finally aligns Key Vault with how the rest of Azure does permissions. AWS remains the odd one out here: a KMS key's key policy is authoritative and can grant access independently of IAM, so a common AWS gotcha is locking yourself out of a key by writing an IAM policy while forgetting the key policy. In GCP, KMS access is just IAM bindings like everything else — granted at the project, key ring, or individual key level.

The whole Rosetta stone, on one screen

Where the mental model breaks

A clean mapping table is dangerous if you trust it too literally. The four places the analogy leaks:

• "IAM role" means two different things. In AWS it's an assumable identity; in GCP/Azure a "role" is only a permission set and the identity is separate. Don't translate it word-for-word.
• AWS attaches permissions to identities; GCP and Azure attach them to resources/scopes. Your "where do I look to audit access?" instinct has to flip when you change clouds.
• The account/project/subscription isn't the same blast radius. An AWS account is a strong wall; a GCP project is wall + bill + grouping in one; an Azure subscription is mostly a billing/scale boundary, with the resource group doing day-to-day lifecycle.
• Guardrails subtract, grants add — except Azure splits the jobs. SCPs/Org-Policies only ever cap permissions; Azure does capping via Policy and granting via RBAC as two separate systems.

Practical takeaways

• Design the hierarchy first. Decide your org → grouping → boundary layout before the first workload; retrofitting accounts/projects/subscriptions later is painful in every cloud.
• Set ceilings high, grant low. SCP/RCP, Org Policy, or Azure Policy at the top; specific roles at the narrowest scope that works.
• Default to managed identities. IAM roles (AWS), service accounts (GCP), managed identities (Azure) — and keyless federation for anything crossing a cloud boundary.
• Treat key admin as privileged. Separate "encrypt/decrypt" from "rotate/disable/set policy," and in AWS always check the key policy, not just IAM.
• If you use Terraform/OpenTofu, these primitives are exactly what you'll codify — aws_organizations_* / google_folder / azurerm_management_group, and the IAM/RBAC and KMS resources beneath them. See Terraform vs. OpenTofu in 2026.

Go deeper, per cloud

Every cloud's architecture and security certifications are built squarely on these primitives — the resource hierarchy, IAM/RBAC, and key management. If you want to drill them hands-on, CertLabPro has tracks for each:

• AWS — Solutions Architect Associate (SAA-C03) for the hierarchy and IAM, and Security Specialty (SCS-C03) for SCPs/RCPs and KMS. New to AWS? Start with Cloud Practitioner (CLF-C02).
• Google Cloud — Professional Cloud Architect for org/folders/projects and IAM, and Professional Cloud Security Engineer for IAM deny policies, Org Policy, and Cloud KMS.
• Azure — Solutions Architect Expert (AZ-305) for management groups and governance, and Security Engineer (AZ-500) for RBAC, Azure Policy, and Key Vault. New to Azure? Start with Azure Fundamentals (AZ-900).

The bottom line

AWS, Google Cloud, and Azure are not as different as their docs make them feel. Each gives you a hierarchy to organize accounts, an identity-and-permissions model built on principal-role-scope, a guardrail layer that caps what permissions can exist, and a key service that separates using keys from administering them. Learn the four layers once and the cross-cloud translation is mostly vocabulary. Learn the four places the analogy leaks, and you'll avoid the mistakes that vocabulary hides. Those fundamentals — hierarchy, identity, least privilege, and key management — are exactly what our certification labs are built to teach, across all three clouds.

Sources

• Microsoft Learn — Organize your resources with management groups
• Microsoft Learn — Understand Azure role assignments
• Microsoft Learn — Key Vault API 2026-02-01 and later: Azure RBAC as default
• Microsoft Learn — Managed HSM access control
• AWS — Introducing Resource Control Policies (RCPs)
• AWS Organizations — Authorization policies (SCPs & RCPs)
• Google Cloud — Resource hierarchy (organization, folders, projects)
• Google Cloud — Understanding allow policies (bindings)
• Google Cloud — Cloud KMS access control with IAM
• Google Cloud — Keyless access with Workload Identity Federation

← Back to all posts