AWS vs Azure

AWS and Azure cover much of the same ground, so the choice usually comes down to structure and to what your team already knows. Azure attaches identity to the platform far more tightly than AWS does, and that is felt on the first day rather than the hundredth.

Configurations and prices in the catalogue

These tables read from the live product records, so they match the product pages exactly.

Accounts, tenants and subscriptions

An AWS account holds resources, permissions and billing together. You add structure by adding accounts.

Azure splits those jobs. A tenant is the identity directory. A subscription is the billing and resource container inside it, and resource groups organise what lives in a subscription. One tenant can hold several subscriptions, and a subscription is where a promotional balance or a spending limit applies.

Practically, that means an Azure environment is described by two things rather than one, and both need to be recorded when an environment changes hands.

Where each one tends to fit

AWS suits

• Teams whose tooling, runbooks and hiring already assume AWS.
• Work that wants the broadest single-platform service list.
• Cases where one account per client is the cleanest isolation you can get.

Azure suits

• Organisations already using Microsoft identity for staff sign-in.
• Windows-heavy workloads and licensing arrangements.
• Teams that want billing separated from identity by design.

What to check before you buy

• Which configuration above carries the balance or capacity your project needs.
• Whether a spending limit is in place on the subscription and whether you want it there.
• Which tenant an environment belongs to, and who else has directory-level access.
• How multi-factor authentication will be set up before anything production-shaped is deployed.

For the longer written comparison, read AWS and Azure: Identity, Billing and Service Shape in the Cloud Library.

Questions