Microsoft Azure

01The mental model: tenant, subscriptions, resource groups

At the top is a tenant: your organisation's Entra ID directory, which holds users, groups and app registrations. Under it are subscriptions, which are billing and quota boundaries; a common pattern is one subscription for production and one for non-production. Management groups sit above subscriptions to apply policy to many at once. Inside a subscription, every resource lives in a resource group: a folder for things that share a lifecycle, like the app, its database and its Key Vault for one environment. Deleting a resource group deletes everything in it, which is very handy for cleaning up test environments. Every create, update and delete goes through Azure Resource Manager (ARM), whether you use the portal, the az CLI, Bicep or Terraform. Compared with AWS, a subscription is close to an AWS account and a resource group has no exact equivalent, it is closer to a tag-based grouping you can act on.

• Tenant (Entra ID) → management groups → subscriptions → resource groups → resources.
• One resource group per app per environment keeps clean-up and permissions simple.
• Everything is an ARM resource with an ID, so it can be described as code.

02Hosting options: App Service, Container Apps, AKS, Functions

App Service is the classic platform for web apps: you choose a runtime (Node, PHP, .NET, Python, Java) or a container, and it handles the servers, TLS and scaling. You pay for an App Service plan, a set of VMs that can host several apps, so cost is fixed per plan size, not per request. Deployment slots let you deploy to a staging slot, warm it up and swap it into production with no downtime. Azure Container Apps runs containers serverlessly on top of Kubernetes without exposing it: autoscaling with KEDA rules (HTTP, queues, cron), scale to zero, revisions and traffic splitting. It is the closest equivalent to Google Cloud Run. AKS is full managed Kubernetes for teams that need the Kubernetes API. Azure Functions runs event-driven code; for new serverless apps Microsoft recommends the Flex Consumption plan, and the Linux Consumption plan is retiring in September 2028.

03Deploying a container to Azure Container Apps

A typical flow: create a resource group, an Azure Container Registry, and a Container Apps environment (the shared network and logging boundary for a group of apps). Build and push your image to the registry, then create the container app. Give the app a managed identity and grant it AcrPull on the registry so no registry password is needed. Ingress makes it reachable over HTTPS on a generated domain, and you can add a custom domain with a free managed certificate. Scale rules decide the minimum and maximum replicas; a minimum of zero is cheapest, a minimum of one avoids cold starts. Secrets can reference Key Vault directly, so the app reads them as environment variables without them ever living in your pipeline.

1az group create --name rg-app-prod --location westeurope
2az acr create --resource-group rg-app-prod --name exampleappacr --sku Basic
3az acr build --registry exampleappacr --image api:1.4.2 .
4 
5az containerapp env create --name cae-app-prod \
6  --resource-group rg-app-prod --location westeurope
7 
8az containerapp create --name api \
9  --resource-group rg-app-prod --environment cae-app-prod \
10  --image exampleappacr.azurecr.io/api:1.4.2 \
11  --registry-server exampleappacr.azurecr.io --registry-identity system \
12  --target-port 3000 --ingress external \
13  --min-replicas 0 --max-replicas 10

04Data: Azure SQL, PostgreSQL Flexible Server, Cosmos DB, Storage

Azure SQL Database is managed SQL Server in the cloud. You buy it in vCore or older DTU models; the serverless tier can auto-pause when idle and bill compute per second, which is great for dev databases. For open-source stacks, Azure Database for PostgreSQL Flexible Server and MySQL Flexible Server are managed instances with automated backups, zone-redundant high availability and stop/start for non-production. Cosmos DB is a globally distributed NoSQL database with several APIs (NoSQL, MongoDB, Cassandra); it is billed in request units, so a badly designed query or partition key costs real money. Azure Storage accounts hold blobs (files), queues, tables and file shares, with hot, cool, cold and archive tiers. Azure Cache for Redis is being succeeded by Azure Managed Redis, so check which one is current before starting a new project.

• .NET + SQL Server → Azure SQL Database.
• Laravel / Node + Postgres → PostgreSQL Flexible Server.
• Global, low-latency NoSQL with predictable partitions → Cosmos DB.

05Identity: Entra ID, RBAC and managed identities

Entra ID (the new name for Azure Active Directory) is both the directory for your staff and the identity provider for your apps. It does single sign-on, MFA and conditional access for people, and OAuth 2.0 / OpenID Connect for applications through app registrations. Permissions on Azure resources use Azure RBAC: assign a role (Reader, Contributor, Storage Blob Data Reader…) to a principal at a scope (management group, subscription, resource group or single resource). The most useful feature for developers is managed identity: Azure gives your App Service, Container App or Function an identity that can get tokens automatically. Grant that identity a role on Key Vault, Storage or the database, and your code connects using DefaultAzureCredential with no password at all. For CI, GitHub Actions can log in with workload identity federation (OIDC) instead of a stored client secret.

1import { DefaultAzureCredential } from "@azure/identity";
2import { SecretClient } from "@azure/keyvault-secrets";
3 
4// Works locally (az login) and in Azure (managed identity), no secrets in code
5const credential = new DefaultAzureCredential();
6const vault = new SecretClient("https://kv-app-prod.vault.azure.net", credential);
7 
8const secret = await vault.getSecret("stripe-api-key");
9console.log(secret.name, "loaded");

06Production tips and pricing traps

Azure bills many things by the hour whether you use them or not. An App Service plan costs the same with zero apps or ten. A VM that is shut down from inside the OS still bills; you must deallocate it. Premium features can surprise you: Application Gateway, Azure Firewall, Front Door premium tiers, Bastion and NAT Gateway all have fixed hourly costs that can outgrow a small app. Log Analytics charges per GB ingested, so a chatty app with verbose logging can cost more in logs than in compute; set a daily cap and retention. Use Cost Management budgets and alerts from day one, tag resources with owner and environment, and put test environments in their own resource groups so they can be deleted in one command. Reservations and savings plans lower the price of steady compute by committing for one or three years.

07Networking: VNets, private endpoints and the public-access trap

By default many Azure PaaS services (Storage, SQL, Key Vault, Cosmos DB) have public endpoints protected only by authentication and optional IP firewalls. For production data, the stronger pattern is private endpoints: the service gets a private IP inside your VNet, a private DNS zone resolves its normal hostname to that IP, and you disable public network access. Apps reach the VNet through VNet integration (App Service, Functions Flex and Premium) or by running the Container Apps environment inside a VNet. The common failure is DNS: if the privatelink zone is not linked to the VNet, the app still resolves the public IP and gets blocked. Hub-and-spoke topologies put shared services (firewall, VPN, DNS) in a hub VNet peered with app spokes. Each piece has a cost: private endpoints bill per hour and per GB, Azure Firewall is expensive for small projects.

1# Private endpoint for a PostgreSQL Flexible Server is set at creation;
2# for Key Vault, deny public access and add a private endpoint:
3az keyvault update --name kv-app-prod --public-network-access Disabled
4 
5az network private-endpoint create --name pe-kv-app-prod \
6  --resource-group rg-app-prod --vnet-name vnet-app-prod --subnet snet-private \
7  --private-connection-resource-id $(az keyvault show -n kv-app-prod --query id -o tsv) \
8  --group-id vault --connection-name kv-conn

08Azure Policy and landing zones

Azure Policy evaluates every ARM request against rules: deny resources outside allowed regions, require tags, deny public IPs, enforce TLS 1.2, deploy diagnostic settings automatically. Effects include Deny, Audit, Modify and DeployIfNotExists, so policies can both block and fix. Assign them at management group level so every new subscription inherits them. Microsoft's Cloud Adoption Framework describes "landing zones": a pre-built structure of management groups, policies, central logging, networking and identity that new workloads plug into. For a small company that is overkill, but the core ideas scale down well: a platform subscription for shared things, separate application subscriptions, policies at the top, and infrastructure as code for everything. Defender for Cloud then scores your secure posture and flags misconfigurations.

09AKS in practice: tiers, upgrades and identity

AKS has a free control plane tier for experiments and a Standard tier with an uptime SLA, plus AKS Automatic, which preconfigures node autoscaling, security and monitoring in the spirit of GKE Autopilot. You still pay for the node VMs in standard clusters. Pick Azure CNI Overlay networking for most new clusters: pods get IPs from a private overlay range, so you do not exhaust VNet addresses. Use Microsoft Entra Workload ID so pods get tokens for their own managed identity through a Kubernetes service account, instead of mounting secrets. Upgrades matter: AKS supports only a window of Kubernetes versions, so set an auto-upgrade channel and planned maintenance windows, use multiple node pools (system and user), and test upgrades on staging. Container Insights and managed Prometheus give monitoring, but watch the Log Analytics ingestion cost.