# Azure, AWS and Google Cloud Compared

> How Azure, AWS and Google Cloud differ where it matters: resource hierarchy, how IAM evaluates a request, policy engines, networking and equivalence.

- Web page: https://www.alesanalytics.com/architecture/cloud-providers
- Markdown: https://www.alesanalytics.com/architecture/cloud-providers.md
- Part of: [Enterprise Architecture Atlas](https://www.alesanalytics.com/architecture.md), section "Cloud platforms"
- Last verified: 13 October 2026
- Publisher: Ales Analytics

## 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

**Figure: Resource hierarchy in Azure, AWS and Google Cloud.** Identity root: a Microsoft Entra tenant; IAM in each AWS account, with IAM Identity Center for the organisation; a Google Cloud Identity organisation. Grouping: Azure management groups; AWS organizational units in AWS Organizations; Google Cloud folders under the organisation node. Hard security and billing boundary: the Azure subscription, the AWS account, the Google Cloud project. Soft grouping: the Azure resource group, which is not a security boundary; AWS tags and Google Cloud labels, which are metadata. The marked row is the one that matters most: the unit that isolates security, billing and quota. An Azure resource group looks as if it belongs in that row, and doesn't.

| 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.

**Figure: How each provider decides whether a request is allowed.** AWS: 1, any explicit deny means the request is denied; 2, every resource control policy must allow it; 3, every service control policy must allow it; 4, an identity or resource policy must allow it; 5, the permission boundary and session policy must allow it, and then it is allowed. Google Cloud: 1, the principal must be eligible under its principal access boundary, and a condition that cannot be evaluated counts as no; 2, a matching deny policy denies the request; 3, an allow inherited down the hierarchy allows it. Azure: 1, an applicable deny assignment denies the request, and all deny assignments are created by Azure itself; 2, the role assignments, added up from management group to resource, must grant it. Azure Policy is a separate engine that judges resource configuration, not the caller's permission. Three different algorithms, not three dialects of one. Azure Policy isn't part of the Azure sequence at all: it is a separate engine that judges the configuration of a resource, not the permission of the caller.

**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](https://www.alesanalytics.com/architecture/networking.md) 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.

## Verified claims

Each numbered statement above, tied to the page that says it, the date it was last checked and the conditions it holds under.

1. In AWS policy evaluation an explicit deny in any applicable policy overrides every allow, and a request must be allowed by every policy type that applies. Source: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html. Checked 13 October 2026, tier T1. Holds when: All AWS commercial Regions. Cross-account requests add the resource account's policies to the evaluation.
2. Resource control policies cap what can be done to resources in member accounts, whoever the caller is; they don't apply to the management account. Source: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html. Checked 13 October 2026, tier T1. Holds when: AWS Organizations with all features enabled. RCPs support a subset of services; check the supported list before relying on one.
3. Google Cloud principal access boundary policies define the resources a principal is eligible to access, and they fail closed. Source: https://cloud.google.com/iam/docs/principal-access-boundary-policies. Checked 13 October 2026, tier T1. Holds when: Google Cloud IAM. Enforcement depends on the principal type and the service; check the supported-services list.
4. Azure RBAC is additive: a caller's effective permissions are the union of their role assignments, inherited down the scope hierarchy. Source: https://learn.microsoft.com/en-us/azure/role-based-access-control/overview. Checked 13 October 2026, tier T1. Holds when: Azure control-plane and data-plane actions granted through Azure RBAC role assignments.
5. Azure deny assignments can't be created directly by customers; they are created and managed by Azure, for example by deployment stacks and managed applications. Source: https://learn.microsoft.com/en-us/azure/role-based-access-control/deny-assignments. Checked 13 October 2026, tier T1. Holds when: Azure RBAC as documented at the time of checking. Azure Policy deny effects on resource configuration are a separate engine and are customer-authored.

Should you have any questions regarding this page, please contact us at solutions@alesanalytics.com.

## Sources

1. [Policy evaluation logic, AWS IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html). Amazon Web Services, 2026. The order in which AWS evaluates explicit deny, RCPs, SCPs, identity and resource policies, permission boundaries and session policies.
2. [Resource control policies (RCPs), AWS Organizations User Guide](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html). Amazon Web Services, 2026. RCPs set the maximum permissions on resources in member accounts and never grant permissions.
3. [Principal access boundary policies](https://cloud.google.com/iam/docs/principal-access-boundary-policies). Google Cloud, 2026. Policies that define which resources a principal is eligible to access, evaluated before deny and allow.
4. [Deny policies](https://cloud.google.com/iam/docs/deny-overview). Google Cloud, 2026. Deny policies are checked before allow policies, and a deny condition that cannot be evaluated applies.
5. [What is Azure role-based access control (Azure RBAC)?](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview). Microsoft, 2026. Azure RBAC is additive; role assignments are inherited from management group to resource.
6. [Understand Azure deny assignments](https://learn.microsoft.com/en-us/azure/role-based-access-control/deny-assignments). Microsoft, 2026. Deny assignments block access even where a role grants it. All deny assignments are currently system-protected.
7. [What is Azure Policy?](https://learn.microsoft.com/en-us/azure/governance/policy/overview). Microsoft, 2026. A separate engine that evaluates resource configuration, with effects such as deny, audit, modify and deployIfNotExists.
8. [Continuous access evaluation in Microsoft Entra](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation). Microsoft, 2026. Tokens up to 28 hours in CAE sessions, revoked on critical events at participating resources.
9. [Gemini Enterprise Agent Platform lets you build, govern and optimize your agents](https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/gemini-enterprise-agent-platform/). Google, 2026. Announced at Google Cloud Next on 22 April 2026 as the evolution of Vertex AI, through which Vertex AI services now ship.

## Where to go next

- Previous: [The Numbers Architects Reason With](https://www.alesanalytics.com/architecture/numbers.md)
- Next: [Cloud Networking, DNS and Private Endpoints](https://www.alesanalytics.com/architecture/networking.md)
- Overview and every page: [Enterprise Architecture Atlas](https://www.alesanalytics.com/architecture.md)
- The whole site in one file: https://www.alesanalytics.com/llms-full.txt