Azure Cloud

Azure is Microsoft's cloud platform, organized around resource groups as the primary unit of lifecycle management, and notable for its deep integration with Microsoft's existing enterprise identity/directory stack (Entra ID, formerly Azure Active Directory) and .NET tooling.

Resource hierarchy

Management Groups (optional, for organizing multiple subscriptions) → Subscriptions (the billing/quota boundary, roughly analogous to an AWS account or GCP project) → Resource Groups (a logical container for resources that share a lifecycle) → Resources.

A Resource Group is Azure's most distinctive organizational idea versus AWS/GCP — resources are typically deployed, managed, and deleted together as a group (deleting a resource group deletes everything in it), which makes it a natural unit for "one environment" or "one application's infrastructure" rather than a purely cosmetic label.

Identity and access: Entra ID and RBAC

az role assignment create \
  --assignee alice@example.com \
  --role "Storage Blob Data Reader" \
  --scope /subscriptions/.../resourceGroups/my-rg

• Microsoft Entra ID (formerly Azure Active Directory) is Azure's identity provider — the same directory used for Microsoft 365 in many organizations, which is why Azure identity work often intersects with an organization's existing enterprise directory rather than being a cloud-only concern.
• Azure RBAC assigns built-in or custom roles at a chosen scope (management group, subscription, resource group, or a single resource) — permissions inherit downward, the same general shape as GCP's hierarchy, distinct from AWS's flatter per-resource policy attachment model.
• A Managed Identity (system-assigned or user-assigned) is Azure's equivalent of an AWS IAM role or GCP service account — an identity a resource (a VM, a Function App) uses to call other Azure services without embedded credentials.

Core service map (by category, not exhaustive)

| Category | Common services | | --- | --- | | Compute | Virtual Machines, Azure Functions (serverless), AKS (managed Kubernetes), App Service (managed web app hosting) | | Storage | Blob Storage (object storage), Azure Files, managed Disks | | Database | Azure SQL Database (managed SQL Server engine), Azure Database for PostgreSQL/MySQL, Cosmos DB (globally-distributed multi-model NoSQL) | | Networking | Virtual Network (VNet), Azure Front Door/CDN, Azure DNS, Application Gateway | | Identity/security | Microsoft Entra ID, Azure RBAC, Key Vault | | Messaging/integration | Service Bus, Event Grid, Event Hubs | | Observability | Azure Monitor, Application Insights, Log Analytics |

Infrastructure as code and CLI

az login
az group create --name my-rg --location eastus
az vm list --output table

// Bicep (Azure's newer, more concise native IaC language)
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'mystorageacct'
  location: 'eastus'
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

ARM templates (JSON) are Azure's original native IaC format; Bicep is a newer, more readable domain-specific language that compiles down to ARM JSON and is now the generally-recommended native option. Terraform is also widely used for Azure, especially in organizations standardizing one IaC tool across multiple cloud providers.

Distinctive capabilities

• Resource Groups as a lifecycle unit — deleting one resource group reliably tears down everything deployed together in it, a cleanup guarantee that AWS/GCP don't offer as directly at the platform level.
• Cosmos DB's multi-model, multi-consistency design — one service exposes multiple APIs (SQL/Core, MongoDB-compatible, Cassandra-compatible, Gremlin graph, table) over the same underlying globally-distributed storage, with a choice of five consistency levels rather than a single fixed model.
• Hybrid/on-premises integration — Azure Arc and Azure Stack extend Azure management (including RBAC and policy) to on-premises or other-cloud resources, reflecting Azure's enterprise/hybrid-first positioning more than AWS or GCP typically emphasize.
• Deep first-party .NET and Windows Server integration — while Azure supports the same broad language ecosystem as other clouds, its App Service, Functions, and Visual Studio tooling have historically had the tightest first-party .NET workflow of the three major clouds.

Common pitfalls

• Treating "subscription" and "resource group" as interchangeable — a subscription is the billing/quota boundary; a resource group is a lifecycle grouping within it. Confusing the two leads to misplaced expectations about where a quota or a bulk-delete actually applies.
• Broad RBAC scope out of convenience (assigning a role at the subscription level when a single resource group would do) — inherits down further than intended and is harder to audit later.
• A Key Vault access policy or RBAC assignment mismatch — Key Vault historically supports both a legacy "access policy" model and RBAC for controlling access; mixing assumptions about which model is active on a given vault is a common source of "permission denied" surprises.
• Not accounting for region/service availability gaps — not every Azure service is available in every region at the same time; check regional availability before assuming a service can be deployed wherever a resource group happens to live.
• Assuming Bicep and ARM are different systems — Bicep is a syntax layer that compiles to ARM JSON; anything expressible in ARM is reachable from Bicep, and errors often surface in terms of the underlying ARM template.

Learn more

• Microsoft Azure documentation
• Azure Well-Architected Framework — the canonical cross-cutting best-practices reference.
• Azure CLI reference, Bicep documentation
• Terraform AzureRM provider docs