AWS and Azure: Identity, Billing and Service Shape
The clearest differences are structural: how identity is modelled, how billing containers work, and how each fits an existing organisation.
AWS and Azure are both full-range platforms, and feature-by-feature comparison ages badly. The structural differences are stable and more useful.
Identity is the biggest difference
Azure’s identity plane is a directory shared across Microsoft services. If an organisation already uses Microsoft 365, the identities that sign into email are the same ones that can be granted access to cloud resources. Groups, conditional access and sign-in policies carry over.
AWS keeps identity inside the account by default, with IAM users and roles, and connects to external directories through federation that you configure.
For an organisation already invested in Microsoft identity, this is frequently the deciding factor, and it has nothing to do with compute.
Containers and grouping
Azure layers a tenant, subscriptions beneath it, and resource groups within those. Resource groups are lifecycle containers: delete the group and everything in it goes.
AWS uses accounts as the boundary, with organisations for consolidated management. There is no direct equivalent of the resource group as a lifecycle unit; tagging and infrastructure-as-code fill that role.
The resource group is genuinely convenient for temporary work, because cleanup is one action rather than an exercise in remembering.
Billing containers
Azure’s subscription is both the billing unit and the quota boundary, which makes it natural to separate environments by subscription. AWS bills per account, so separation by environment tends to mean more accounts.
Trial behaviour differs too. Azure trial subscriptions have a spending cap that stops resources rather than billing, which is covered in Azure subscriptions and tenants.
Where each tends to be chosen
- Azure where the organisation already runs Microsoft identity, Windows Server or SQL Server, and where licensing arrangements carry across.
- AWS where breadth of services matters, where the team already has AWS experience, or where a specific service has no close equivalent.
For straightforward Linux workloads, both are entirely adequate and the choice usually comes down to people rather than platforms.
Account options
Catalogue configurations reflect each model. Azure listings distinguish trial profiles from pay-as-you-go readiness and credit tiers. AWS listings separate capacity, credit and service readiness, as described in reading AWS configurations.
Side by side configurations and current prices for both providers are on the AWS vs Azure page in the Cloud Matrix.
Cloud accounts on OldCloudShop
Ten providers, every configuration and the starting price for each.
Continue in the library
Other entries covering account structure, billing, security and provider infrastructure.