🗺️ Azure Services: A Map for People Who Know Linux

How Azure is organized (tenant, subscription, resource group, resource), the handful of services you meet first, a translation table from Linux ideas to Azure ones, and what costs money while it sits there doing nothing

The one idea to learn first: the scope

Everything in Azure lives in a hierarchy, and every setting (access, policy, tags, budgets) can be attached at any level of it. Microsoft calls the four levels management scopes:

1. Management group. A folder of subscriptions, for companies with many. You can skip it for now.
2. Subscription. The container with the bill. (The account tutorial explains it.)
3. Resource group. A folder of related resources inside a subscription.
4. Resource. The actual thing: a virtual machine, a disk, a storage account, a virtual network.

(Above all of these sits the tenant: the Entra ID directory that decides who can sign in.) Settings flow downward: an access role or a policy given at the subscription applies to every resource group and resource in it. One given at a resource group applies to that group only.

Resource groups: the rules that matter

From Microsoft's documentation:

• Every resource lives in exactly one resource group. You can move it to another later.
• Put things in the same group when they live and die together: "all resources in your resource group should share the same lifecycle". A test project is one group. Something shared by many projects (a DNS zone, say) is another.
• Deleting a resource group deletes everything in it. This is the best cleanup tool you have, and the most dangerous one.
• A resource in one group can use resources in another (a web app talking to a database elsewhere).
• Tags put on a group are not inherited by the resources in it.
• The group has a location, which is where its metadata is kept (see the regions tutorial). The resources inside may be elsewhere, but keep them together unless you have a reason.
• Up to 800 instances of one resource type per group (some types are exempt): you will meet that limit only in big projects.
• You can attach locks to a group (CanNotDelete or ReadOnly) to protect it from accidents.

Why every tool gives the same answer

Everything you do, in the portal, in the CLI, in PowerShell, in a script or from a template, goes through one front door: Azure Resource Manager (ARM). It checks who you are and whether you may do it, and then passes the request to the right service. That is why anything the portal can do, the CLI can do, and why you can learn the portal first and automate later.

Resources come from resource providers with names such as Microsoft.Compute (virtual machines), Microsoft.Storage (storage accounts) and Microsoft.Network (networks): you see them in error messages and in the resource IDs.

And for repeatable setups, you describe the result and let Azure make it so. This is declarative infrastructure, and Azure's own formats are ARM templates (JSON) and Bicep (a friendlier language that compiles to them). Terraform is the other popular tool. A Terraform basics tutorial is still on the Coming Soon list of this section.

Ways to work

• The portal (portal.azure.com): good for looking, learning and one-off changes.
• Cloud Shell: a terminal in the portal with the CLI and PowerShell ready.
• The Azure CLI (az) or Azure PowerShell: for scripts, and for repeatable steps like the ones in the other tutorials.
• Bicep, ARM templates, Terraform: when you want to rebuild the same thing again.

The first services you will meet

Grouped by what you would do on a Linux server. These are the ones that appear in nearly every tutorial.

Compute: where programs run

• Virtual Machines. A server you manage: the same thing as a VM anywhere. You pick a size (CPU and memory), an image (Ubuntu, Debian, Windows) and a disk. You patch it. The free Azure VM guide walks through one.
• App Service. You give it your web app (Python, Node, .NET, Java, PHP or a container) and Azure runs it, patches the operating system and scales it. No server to administer.
• Container Instances and Container Apps. Run a container image without managing machines.
• Azure Kubernetes Service (AKS). A managed Kubernetes cluster. See the Kubernetes node access tutorial.
• Functions. A small piece of code that runs when something happens (a web request, a timer, a message).

Storage: where data lives

• A storage account is the container for several kinds of storage. The name must be globally unique, 3 to 24 characters, only lowercase letters and digits.
• Blob storage: files and objects, accessed by URL, in tiers from "hot" to "archive". The closest thing to an S3 bucket.
• Azure Files: a network file share you mount like NFS or SMB (Azure Files supports SMB and, on some tiers, NFS: from the documentation, not run here). Compare it with the NFS page, where we shared a dataset between two machines ourselves.
• Managed Disks: the disks of virtual machines. They keep billing when the VM is stopped.
• Queues and Tables: small messaging and key-value stores in the same account.

Networking: how things reach each other

• Virtual Network (VNet) and subnets: your private network. Resources get private addresses inside it.
• Network Security Group (NSG): the firewall rules for a subnet or a network card: the same idea as pf or iptables, written as numbered rules with allow and deny.
• Public IP address: a reachable address. It is a billable resource of its own.
• Load Balancer and Application Gateway: spread traffic over several machines. The Application Gateway understands web requests.
• Azure DNS: host DNS zones.
• VPN Gateway: connect your network to Azure over an encrypted tunnel (compare with the WireGuard page for two machines you manage yourself).
• Bastion: browser-based SSH and remote desktop to machines that have no public address. Convenient, and billed by the hour.

Identity and secrets

• Microsoft Entra ID: the users, groups, apps and sign-ins of the tenant.
• Azure RBAC: who can do what, at which scope (Owner, Contributor, Reader, and hundreds of more specific roles).
• Managed identities: an identity for a resource, so a virtual machine or a web app can reach other services without a password in a file. Use them whenever you can.
• Key Vault: a safe place for secrets, keys and certificates.

Data

• Azure SQL (SQL Server), Azure Database for PostgreSQL and MySQL: managed databases, where Azure does the patching and the backups.
• Cosmos DB: a globally distributed NoSQL database.

Watching and governing

• Azure Monitor and Log Analytics: metrics, logs and alerts (the idea of the monitoring page, as a service).
• Cost Management: cost analysis and budgets.
• Policy: rules such as "only allow these regions", applied across a scope.
• Tags: labels (env=test, owner=anna) that show up on the bill, so that you can see who spent what.

Linux idea, Azure idea

• sudo and file permissions → RBAC roles at a scope.
• Users in /etc/passwd → Entra ID users and groups.
• A password in a config file → a managed identity and Key Vault.
• A disk and /etc/fstab → Managed Disks (attached to one machine) or Azure Files (a share for many).
• iptables, nftables, pf → Network Security Groups (and Azure Firewall for larger networks).
• nginx as a reverse proxy → Application Gateway (or Azure Front Door for worldwide web traffic).
• /var/log and syslog → Azure Monitor and Log Analytics.
• Cron → Functions with a timer, or a scheduled job, depending on the size (from the documentation, not run here).
• Backups with rsync or zfs send → Azure Backup and snapshots of disks.
• SSH key login stays the same: SSH key login: pick "SSH public key" when you create the VM, and the portal creates the key pair for you.
• A hostname and /etc/hosts → Azure DNS (public) and Private DNS zones (inside the network).

What costs money while it sits there

This is the part that matters most for learners, and it agrees with the free VM guide:

• A virtual machine keeps billing for compute until it is deallocated, and shutting it down from inside the operating system does not do that: use Stop in the portal (or az vm deallocate) until the status says Stopped (deallocated).
• Disks keep billing even for a stopped or deleted machine, if the disk is left behind.
• A public IP address bills by the hour while it exists.
• Bastion, NAT Gateway, Load Balancer, Application Gateway and VPN Gateway bill for existing, whether you send traffic or not.
• Outbound data beyond the free amount is billed.
• Managed databases mostly bill while they exist, even idle (serverless tiers are the exception: check the tier).

The cleanup habit that fixes almost all of this: one resource group per experiment, and delete the group when you finish.

A first small path (from the documentation, not run here)

This is the shape of a tidy experiment, with no machine to pay for: one group, one storage account, then everything removed. It needs a signed-in account.

az group create --name demo-rg --location eastus
az storage account create --name YOURUNIQUENAME123 --resource-group demo-rg --location eastus --sku Standard_LRS
az resource list --resource-group demo-rg --output table
az group delete --name demo-rg --yes --no-wait

• The first command makes the resource group in a region you choose.
• The second makes a storage account in that group. The name must be globally unique, lowercase letters and digits only. Standard_LRS is the cheapest redundancy: three copies inside one datacenter: fine for a test, not for data you cannot lose (see the zones tutorial).
• The third lists what is in the group: the way to check that nothing is hiding.
• The last deletes the group and everything in it. --no-wait returns at once, and the deletion goes on in the background.

Then check Cost analysis the next day, as the account tutorial says.

What this page did not cover

Azure Firewall, Front Door, Backup and Site Recovery, Active Directory Domain Services, hybrid setups with ExpressRoute, the AI and analytics services, and everything that needs an enterprise agreement. Each is a tutorial of its own, and the Microsoft Learn documentation covers them in depth.

The cheat sheet

• Scopes: management group, subscription (the bill), resource group (the folder), resource (the thing). Settings flow downward.
• Resource group rules: one group per resource, same lifecycle, deleting the group deletes everything, tags are not inherited, the group has a location.
• One front door: ARM. Portal, CLI, PowerShell, templates, Bicep and Terraform all use it.
• First services: Virtual Machines, App Service, Storage account (Blob, Files), Virtual Network and NSG, Entra ID and RBAC, Key Vault, a managed database, Monitor and Cost Management.
• Linux to Azure: sudo is RBAC, passwd is Entra ID, fstab is Disks or Files, pf is NSG, syslog is Monitor, secrets in files are Key Vault and managed identities.
• Billing traps: a VM not deallocated, disks and public IPs left behind, Bastion, NAT, gateways and load balancers, idle databases.
• Tidy experiment: az group create, create things in it, az resource list --resource-group NAME --output table, az group delete --name NAME --yes --no-wait.

← Azure Regions and Availability Zones: Where Your Things Actually Live · ↑ All tutorials · Azure Load Balancer: Set Up a Public Load Balancer for Two Servers, and What Goes Wrong →