Same shapes, different rules
Azure, AWS and Google Cloud are built from the same primitives, and from a distance their constructs line up neatly: each has an identity root, a way of grouping things, a hard boundary for security and billing, and somewhere to attach policy. Up close, the rules differ in ways that change designs. This page covers the four places where the differences matter most: the resource hierarchy, how a permission is evaluated, which policy engine does what, and networking.
The resource hierarchy
Resource hierarchy in Azure, AWS and Google Cloud
Microsoft Entra tenant
IAM in each account
Identity Center for the organisation
Cloud Identity organisation
Management groups
Organizational units
In AWS Organizations
Folders
Under the organisation node
Subscription
Account
Project
Resource group
Not a security boundary
Tags
Metadata, not a boundary
Labels
Metadata, not a boundary
| Concept | Azure | AWS | Google Cloud |
|---|---|---|---|
| Identity root | Entra tenant | IAM in each account; IAM Identity Center for the organisation | Cloud Identity organisation |
| Grouping | Management groups | Organizational units (OUs) | Folders |
| Hard security and billing boundary | Subscription | Account | Project |
| Soft grouping | Resource group, which is not a hard security boundary | Tags | Labels |
| Where policy attaches | Management group, subscription, resource group, resource | Root, OU, account | Organisation, folder, project, resource |
The row to get right is the third. An AWS account and a Google Cloud project are genuine walls: separate quotas, separate billing, and permissions that don't cross unless you say so. An Azure subscription plays the same role. An Azure resource group looks as if it might, because it is the thing you put resources in, but it's a soft grouping, and treating it as a security boundary is one of the more common Azure design mistakes.
On-premises estates have their own version of the same ladder: an Active Directory forest or a cluster as the hard boundary, OUs and sites for grouping. Kubernetes has the cluster as its hard boundary and namespaces as a soft one.
How a permission is evaluated
This is the most important structural difference between the three clouds, and it can't be papered over with a common abstraction. Each provider runs a different algorithm.
How each provider decides whether a request is allowed
AWS
- 1.Any explicit deny?If so, the request is denied.
- 2.Does every resource control policy allow it?
- 3.Does every service control policy allow it?
- 4.Does an identity or resource policy allow it?
- 5.Do the permission boundary and session policy allow it?If all of these do, it's allowed.
Google Cloud
- 1.Is the principal eligible under its principal access boundary?A condition that can't be evaluated counts as no.
- 2.Does a deny policy match?If so, the request is denied.
- 3.Is there an allow, inherited down the hierarchy?If so, it's allowed.
Azure
- 1.Does a deny assignment apply?All of them are created by Azure itself.
- 2.Do the role assignments, added up from management group to resource, grant it?If so, it's allowed.
AWS
An explicit deny always wins. After that, a request has to be allowed by every layer that applies to it[1], and the effective permission is the intersection of them all.
Resource control policies (RCPs) are evaluated before service control policies (SCPs). An RCP caps what can be done to resources in member accounts, whoever the caller is[2], and RCPs don't affect the management account. An SCP caps what principals in the organisation can do. Neither ever grants anything; they only set ceilings. Inside those ceilings, an identity-based or resource-based policy has to allow the action, and permission boundaries and session policies can narrow it further. Role trust policies and KMS key policies must allow explicitly as well.
Google Cloud
Where the principal may act is checked first. Principal access boundary (PAB) policies define the set of resources a principal is eligible to touch at all, and they fail closed[3]. Deny policies are checked before allow policies, and a deny condition that cannot be evaluated is treated as applying. Up to ten PAB policies can be bound to a principal set, and which permissions they block depends on the enforcement version.
Azure
Role assignments add up. Azure RBAC is an additive model: assignments made at a management group, subscription, resource group or resource are inherited downwards, and a caller has the union of everything assigned to them[4]. If a deny assignment applies, access is blocked. But all deny assignments are currently system-protected, created by Azure itself for features such as deployment stacks and managed applications[5]. You can't write your own to say "nobody may do this".
The token Azure Resource Manager receives carries the caller's transitive group memberships. Role definitions and assignments are stored globally.
Two separate engines sit beside this. Azure Policy judges the configuration of a resource (deny, audit, modify, deploy if not exists), not the permission of the person making the change. Entra directory roles are a different plane from Azure RBAC entirely.
What "nobody may do X" turns into
Because the algorithms differ, the same requirement is built differently on each cloud.
| Requirement | AWS | Google Cloud | Azure |
|---|---|---|---|
| Organisation-wide "nobody may do X" | SCP deny | Organisation deny policy, or PAB | Composed: Azure Policy deny on the configuration, plus RBAC scoping on who can act |
| Data must stay inside the organisation | RCP plus SCP plus endpoint policies | PAB plus VPC Service Controls | Private endpoints plus Azure Policy plus Conditional Access |
| Guardrail on configuration | AWS Config rules, or SCP conditions | Organisation Policy constraints | Azure Policy |
The Azure column is the one people get wrong. There is no customer-authored, organisation-wide deny on permissions equivalent to an SCP. Azure Policy can stop a resource being created or configured in a particular way; RBAC can limit who holds a role. The two together approximate an SCP, and the gap between them is where surprises live.
Networking deltas
| Concern | Azure | AWS | Google Cloud |
|---|---|---|---|
| Scope of the network | Regional VNet | Regional VPC | Global VPC |
| Transit between networks | Virtual WAN, hub and spoke | Transit Gateway, Cloud WAN | Network Connectivity Center, Shared VPC |
| Private access to platform services | Private Endpoint plus a private DNS zone | PrivateLink interface endpoints | Private Service Connect |
| Perimeter against data exfiltration | Composed from parts | Composed: endpoint policies, RCPs, SCPs | VPC Service Controls |
| Global edge | Front Door | CloudFront, Global Accelerator | Global external Application Load Balancer |
Two rows matter more than the rest. Google's VPC is global, so one network spans regions; AWS and Azure networks are regional, and connecting regions is something you build. And only Google has a first-class data perimeter, VPC Service Controls, which stops data leaving a defined set of projects even through a valid API call with valid credentials. On the other two clouds you assemble an equivalent from endpoint policies and organisation policy, and you test it. The networking page goes deeper.
Tokens and revocation
| Microsoft Entra | AWS | Google Cloud | Kubernetes | |
|---|---|---|---|---|
| Machine credential | Managed identity, or a federated identity credential; agent identities through a blueprint | STS role session | Service account, or Workload Identity Federation | Projected ServiceAccount token, with an audience and an expiry |
| Revocation by event | Continuous access evaluation: tokens up to 28 hours, revoked on critical events at participating resources | Session revocation through a policy condition | Not verified for this edition | Bound tokens invalidated when the pod is deleted |
Equivalence classes
When a design says "use object storage" or "use managed Kubernetes", it is quietly claiming that the provider's version is equivalent to everyone else's. The atlas makes that claim explicit with five classes.
| Class | Meaning | Example |
|---|---|---|
| E1 | Functionally equivalent; swap with small changes | Object storage, queues |
| E2 | Equivalent capability, different operating model | Managed Kubernetes identity and networking, serverless concurrency and cold starts, the Azure storage account as a namespace and security unit |
| E3 | Structurally different; cannot be normalised | Permission evaluation, policy engines, global databases |
| E4 | Unique to one provider; a lock-in flag | TPUs, Copilot over Microsoft Graph, VPC Service Controls |
| E5 | The same word for different things | "Agent", "project", "zone", "policy" |
The classes are relative to a purpose. Object storage is E1 if all you care about is the API shape and durability, and it isn't if you care about authorization, because S3 bucket policies, Azure account keys and SAS tokens, and Google's uniform bucket-level IAM are three different models. So the atlas writes E1 with facet deltas: E1, but different on authorization and namespace. The five facets worth declaring are consistency, authorization, failure domain, lifecycle and versioning, and namespace. If a platform abstraction hides a facet that differs, it either leaks the difference or silently changes the behaviour.
| Capability | Class | What differs |
|---|---|---|
| Object storage, queues | E1 with facets | Access model: account keys and SAS, bucket policy, or uniform IAM |
| Managed Kubernetes | E1 for the workload API, E2 for identity and networking | Workload identity binding, CNI modes, upgrade mechanics |
| Serverless | E2 | Concurrency, cold starts, networking |
| Globally consistent database | E3 | Spanner, DynamoDB global tables and Cosmos DB consistency levels are different models |
| Policy engines | E3 | Azure Policy judges configuration; SCPs and RCPs cap permission; Google has Organisation Policy plus deny |
AI platforms
Each cloud now has an AI platform that bundles model access, agents and tooling:
- Microsoft Foundry, including Foundry Models, which is where Azure OpenAI now sits.
- Amazon Bedrock, with Bedrock AgentCore for running agents, generally available since 13 October 2025.
- Gemini Enterprise Agent Platform, announced at Google Cloud Next on 22 April 2026, which Google describes as the evolution of Vertex AI. Google says Vertex AI services and roadmap updates now ship through the Agent Platform.
Treat a rename like the last one as an alias, not a migration. Workloads are reported to run unchanged, but endpoint and API names after the rename were not verified for this edition, so check yours.