Azure Introduction

What is Azure?#

Microsoft Azure is a public cloud platform — a huge collection of computing, storage, networking, and managed services that you rent by the hour (or by the second, or by the request) instead of buying and racking physical servers yourself. Need a web server? A database? A place to store ten million uploaded images? A GPU to train a model? Azure rents you all of it, and you can spin resources up in minutes and delete them just as fast.

That's the entire pitch of "the cloud": instead of a company buying hardware that sits in its own building (on-premises, or "on-prem"), it rents capacity from a provider that already owns enormous datacenters full of it. Azure is one of the three dominant providers, alongside Amazon Web Services (AWS) and Google Cloud Platform (GCP). None of the underlying ideas are unique to Azure — if you learn Azure's mental model well, AWS and GCP will feel like the same concepts wearing different name tags.

Why does this matter to you as a student or a developer? Because almost no serious application today runs entirely on a machine sitting under someone's desk. Real products run "in the cloud," and understanding how that works — how a piece of code you wrote ends up running on a server somewhere, reachable by anyone on the internet — is a core piece of modern software literacy, not just an "ops" specialty.

The core mental model: subscriptions, resource groups, and resources#

Azure organizes everything into a strict hierarchy. Getting this hierarchy straight in your head early will save you a lot of confusion later, because almost every Azure concept slots into one of these levels.

Azure Account (your login / Microsoft Entra ID identity)
  └── Subscription (the billing boundary)
        └── Resource Group (a logical folder for related resources)
              └── Resources (the actual things: a VM, a database, a storage account...)

A resource is the smallest unit — a single virtual machine, a single database, a single storage account, a single web app. Everything you actually use in Azure is a resource.

A resource group is a container that holds resources which belong together — typically because they make up one application or one environment. If you're building a small web app, its resource group might contain: one App Service (the web server), one Azure SQL Database, and one storage account for uploaded files. The resource group itself doesn't "do" anything — it's purely organizational, but it has one enormously useful property: you can delete an entire resource group and everything inside it disappears in one action. This is the single best habit to build early: always create a fresh resource group for anything you're experimenting with, so cleanup is one command instead of hunting down five different resources.

A subscription is the billing and access-control boundary — it's what your invoice is calculated against, and it's the level at which Azure enforces certain hard limits (quotas). A single person learning Azure will usually only ever have one subscription. Companies often have several — one for production, one for testing, one per team — precisely so costs and permissions stay cleanly separated.

Think of it like a filing cabinet: the subscription is the cabinet, resource groups are the labeled drawers, and resources are the individual folders inside each drawer.

Regions: where your resources physically live#

Every resource you create in Azure gets placed in a region — a specific geographic area (East US, West Europe, Southeast Asia, and dozens more) made up of one or more physical Microsoft datacenters. When you create a virtual machine in East US, that's not a metaphor — there is an actual physical server in an actual building in Virginia running your workload.

Regions matter for three practical reasons:

• Latency — a user in Singapore talking to a server in Virginia will experience more delay than one talking to a server in Southeast Asia. Pick a region close to your users.
• Data residency and compliance — some laws (and some contracts) require that certain data physically stays within a country or region.
• Cost and availability — prices and which specific services/hardware are available can vary slightly by region.

Some regions are further divided into availability zones — physically separate datacenters within the same region, each with independent power and networking, so that a single datacenter failure doesn't take your whole application down if you spread resources across zones. For learning purposes, you don't need to worry about zones yet — just know the word exists and that it's a finer-grained reliability tool than the region itself.

Azure Portal vs Azure CLI#

There are two main ways to actually create and manage Azure resources, and you'll use both throughout your Azure journey.

The Azure Portal (portal.azure.com) is a web-based graphical interface. You click "Create a resource," fill in a form, and click "Review + create." It's the friendliest way to explore what Azure offers — every service has a page, every option has a tooltip explaining it — which makes it the best starting point while you're still learning what exists.

The Azure CLI (the az command) is a cross-platform command-line tool you install locally (or use free, pre-installed, inside Azure Cloud Shell right in the browser). Instead of clicking through forms, you run commands like:

az group create --name learning-rg --location eastus
az vm create --resource-group learning-rg --name my-vm --image Ubuntu2204

The CLI matters more than it might seem at first glance, for one crucial reason: it's repeatable. A sequence of az commands (or a proper Infrastructure-as-Code tool built on top of Azure, like an ARM template or Bicep file) can be saved, version-controlled, and run again to recreate the exact same setup — something no amount of clicking in a portal can reliably reproduce. Professional teams almost always manage real infrastructure through code, not by hand in the portal. As a rule of thumb: use the Portal to learn and explore a new service, then switch to the CLI (or code) once you understand what you're actually creating.

Signing up for a free account#

Azure offers a free tier specifically designed for learning, at azure.microsoft.com/free. As of this writing it includes:

• A time-limited credit (historically $200) usable on almost any service for the first 30 days, so you can experiment freely without worrying about the bill.
• 12 months free of a set of popular services (a certain amount of VM hours, Blob Storage, SQL Database, and more) even after the credit runs out.
• A set of "always free" services, available in limited quantities indefinitely — for example, a small allotment of Azure Functions executions every month, forever, as long as you stay under the limit.

Signing up requires a Microsoft account (a free outlook.com/hotmail.com account works, or you can use an existing one) and a credit card for identity verification — Azure will not charge it automatically once your free credit runs out; you have to explicitly upgrade to a pay-as-you-go subscription first. Still, it's a very good habit to set up a budget alert in the Cost Management section as soon as you sign up, so you get an email if spending crosses a threshold you choose (even $1) — free tiers are genuinely free, but it's easy to accidentally leave an expensive resource (like a large VM) running overnight.

A first hands-on look#

Once you're signed in to the portal, the two things worth doing immediately are:

1. Create a resource group (e.g., learning-rg) in a region close to you. This becomes your sandbox for every exercise.
2. Open Cloud Shell (the >_ icon in the top toolbar of the portal) and run:

az account show

This confirms which subscription you're using and which tenant (Entra ID directory) it belongs to — the two identity concepts sitting above everything described here. You now have everything in place to create your first real resource, which is exactly where the next page picks up.

Common mistakes#

• Forgetting resources are still billing even when "idle." A stopped-but-not-deallocated VM, or an idle database sitting at a paid tier, still costs money. Always check whether "stop" in a given service actually means "stop billing" or just "stop the running process."
• Scattering experiments across the default resource group. Always create a dedicated resource group per project or per experiment — it makes cleanup (and understanding what belongs to what) trivial.
• Picking a region at random. It seems like a minor detail during setup, but it affects latency, price, and which services are even available — get in the habit of choosing deliberately.
• Confusing "subscription" with "account." Your account (identity) can have access to multiple subscriptions (billing containers); they're not the same thing, and permissions/quotas are enforced at the subscription level.