Azure Introduction

Microsoft Azure is a public cloud platform: instead of buying and running your own servers, you rent computing power, storage, networking and higher-level services from Microsoft's global datacenters, and pay only for what you use.

The three service models

• IaaS (Infrastructure as a Service) — you manage the OS and everything above it; Azure manages the physical hardware. Example: Virtual Machines.
• PaaS (Platform as a Service) — you deploy your code; Azure manages the runtime, OS patching and scaling. Example: App Service.
• SaaS (Software as a Service) — fully managed software you just use. Example: Microsoft 365.

How you manage Azure

• Azure Portal — a web UI for clicking through resource creation and configuration.
• Azure CLI & PowerShell — command-line tools for scripting repeatable actions.
• ARM templates / Bicep — infrastructure as code, so environments can be version-controlled and redeployed.

Azure Data Centers

A datacenter is a physical facility — power, cooling, networking and racks of servers — that Microsoft owns and secures. Azure runs on hundreds of these facilities worldwide, but you never pick a datacenter directly.

What you actually choose

When you deploy a resource, you choose a region (like East US or UK South). Azure decides which underlying datacenter(s) host it. In regions with Availability Zones, those datacenters are physically separate buildings with independent power and cooling, which is what lets you build highly available applications.

Why this matters

• Physical security, compliance certifications and redundant infrastructure are Microsoft's responsibility.
• Your responsibility is choosing the right region and resiliency features (availability sets, zones, region pairs) for your workload.

Azure Geographies

A geography is a discrete market area — usually aligned with a country or a group of nearby countries — that contains one or more Azure regions. Geographies exist mainly to satisfy data residency, sovereignty and compliance requirements.

Key idea

Data that stays "within a geography" typically never leaves that legal/political boundary, which matters for customers with regulatory obligations (banking, government, healthcare).

• Examples of geographies: United States, Europe, India, Australia, Japan.
• Each geography usually contains at least one region pair, so data can be replicated for disaster recovery while staying inside the same legal boundary.

Azure Regions

A region is a set of datacenters deployed within a defined perimeter, connected through a dedicated low-latency network. It's the primary thing you select when you create a resource — for example East US, West Europe, or Southeast Asia.

Region pairs

Most regions are paired with another region at least 300 miles away in the same geography (e.g. East US ↔ West US). Azure prioritizes recovering one region of a pair first during a broad outage, and some services replicate automatically across the pair.

Choosing a region

• Latency — pick a region close to your users.
• Service availability — not every Azure service is available in every region.
• Compliance — some data must stay within a specific geography.
• Pricing — costs vary slightly by region.

Azure Resource Groups

A resource group (RG) is a logical container that holds related Azure resources — for example a VM, its disk, its network interface and its public IP. Every resource must belong to exactly one resource group.

What a resource group is not

• It's not a network boundary — resources in different RGs can still talk to each other.
• It doesn't have to match your organizational chart — group by lifecycle or application, not by team.

Basic rules

• A resource can only live in one resource group at a time, but can be moved between groups.
• Resources in a group can span multiple regions.
• Deleting a resource group deletes everything inside it.

Resource Group Benefits

Organizing resources into groups isn't just tidiness — it unlocks real management capabilities.

Lifecycle management

Deploy, update and delete an entire application's resources together. Tear down a whole test environment with one delete instead of hunting down each piece.

Access control

Assign RBAC roles at the resource group level, and every resource inside inherits that access — far less work than assigning permissions resource by resource.

Cost tracking

View billing broken down by resource group, so you can answer "how much does this specific app cost?" at a glance.

Policy & tagging

• Apply Azure Policy at the group level to enforce standards (allowed regions, required tags, SKUs).
• Apply consistent tags (like environment: production) across everything inside automatically.

Management Groups

Management groups sit above subscriptions in Azure's hierarchy, letting large organizations manage access, policy and compliance across many subscriptions at once.

The hierarchy

Root management group
  └── Management group (e.g. "Production")
        └── Management group (e.g. "Finance")
              └── Subscription
                    └── Resource group
                          └── Resource

• Supports up to six levels of management groups, not counting the root.
• Every subscription in your tenant lives under a single root management group by default.
• Policies and RBAC roles applied at a management group are inherited by every subscription and resource beneath it.

Availability Set

An availability set is a logical grouping that protects a small cluster of VMs from planned maintenance and unplanned hardware failures within a single datacenter.

How it works

• Fault Domains (FDs) — groups of hardware that share a power source and network switch. VMs are spread across FDs so one hardware failure doesn't take down every instance.
• Update Domains (UDs) — groups that get rebooted together during planned maintenance, one UD at a time, so the whole set is never patched simultaneously.

Availability sets must be configured at VM creation time — you can't add an existing standalone VM to one afterward.

Availability Set vs Zone

Both protect VM-based workloads from downtime, but at different physical scopes.

Virtual Machine Scale Sets

A Virtual Machine Scale Set (VMSS) manages a group of identical, load-balanced VMs that can grow or shrink automatically based on demand — the standard way to run stateless workloads at scale on Azure IaaS.

Why use one instead of individual VMs

• All instances are created from the same image/configuration, so there's nothing to configure per-VM.
• Instances can be spread across fault domains, update domains, and availability zones automatically.
• Works with autoscale rules and sits behind a Load Balancer or Application Gateway.

Create a VM Scale Set

1. In the Azure Portal, search for Virtual machine scale sets and click Create.
2. Basics — pick subscription, resource group, scale set name, region, and choose an availability zone spread if offered.
3. Image & size — select the OS image and VM size that each instance will use.
4. Instance count — set the initial number of instances (you can change this later, or let autoscale handle it).
5. Disks — choose managed disk type (Standard SSD, Premium SSD).
6. Networking — attach a virtual network and, if needed, put the set behind a Load Balancer or Application Gateway so traffic is distributed across instances.
7. Scaling — either set a fixed instance count or enable autoscale with min/max/default values.
8. Review the summary and click Create.

az vmss create \
  --resource-group myRG \
  --name myScaleSet \
  --image Ubuntu2204 \
  --instance-count 2 \
  --upgrade-policy-mode automatic

Autoscale a VM Scale Set

Autoscale automatically adds or removes instances based on real-time metrics, so you have enough capacity under load and don't pay for idle VMs the rest of the time.

Setting it up

1. Open the scale set → Scaling in the left menu.
2. Switch from "Manual scale" to Custom autoscale.
3. Set an instance range: minimum, maximum, and a default.
4. Add a scale-out rule, e.g. "Increase instances by 1 when Average CPU % > 70 over 10 minutes."
5. Add a matching scale-in rule, e.g. "Decrease instances by 1 when Average CPU % < 30 over 10 minutes."
6. Set a cooldown period between scale actions so it doesn't overreact to short spikes.

When to Use a VM

A Virtual Machine is the most flexible — and most hands-on — compute option in Azure. It's the right call in specific situations, and overkill in others.

Good fit for a VM

• You need full control of the OS, kernel, or specific software/driver versions.
• You're doing a "lift-and-shift" migration of an existing on-premises server.
• You run legacy software that requires a specific Windows Server or Linux distro.
• Licensing requirements tie an application to dedicated infrastructure.

Consider PaaS or serverless instead when

• You're building a new web app or API — App Service removes patching and scaling work.
• Your workload is event-driven or bursty — Azure Functions scales to zero and bills per execution.
• You want managed containers without managing VMs — Azure Kubernetes Service (AKS) or Container Apps.

Create a VM in the Azure Portal

1. Sign in to portal.azure.com → Create a resource → Virtual machine.
2. Basics — choose subscription, resource group, VM name, region, availability options, and the OS image.
3. Pick a size based on expected CPU/RAM needs.
4. Set the administrator account — SSH key (Linux) or username/password (Windows).
5. Inbound port rules — allow only the ports you need (e.g. RDP 3389 or SSH 22), ideally scoped to your own IP.
6. Disks — choose OS disk type (Standard SSD is a good default for dev/test).
7. Networking — select or create a virtual network, subnet, and public IP if the VM needs to be internet-reachable.
8. Review the Management, Monitoring and Tags tabs, then click Review + create.
9. Once validation passes, click Create and wait for deployment to finish.

RDP Connection Error

"Can't connect to the remote computer" is one of the most common Azure VM issues, and it's almost always one of a handful of causes.

Checklist

1. Is the VM running? Check its status in the portal — a stopped or deallocated VM won't respond.
2. NSG rule for port 3389 — confirm an inbound rule allows RDP from your IP, on both the NIC and subnet-level Network Security Groups.
3. Windows Firewall inside the guest OS — if it was changed, RDP may be blocked even with the right NSG rule.
4. Correct public IP — the VM's public IP can change if it's dynamic and the VM was restarted; recheck it in the portal.
5. Just-in-time access lock — if JIT VM access is enabled, port 3389 stays closed until you explicitly request access.
6. RDP service not running / disk full — use Boot diagnostics or the Serial Console to check the guest OS state without needing RDP.

Azure Just-in-Time VM Access

Just-in-time (JIT) VM access, part of Microsoft Defender for Cloud, locks down management ports (RDP 3389, SSH 22, etc.) by default and only opens them for a limited window when you explicitly request access.

Why it matters

Open management ports are one of the most common attack vectors — automated scanners constantly probe for exposed RDP/SSH. JIT reduces that exposed window from "always open" to "open for 1–3 hours, from your IP only."

How to enable it

1. Go to Microsoft Defender for Cloud → Workload protections → Just-in-time VM access.
2. Select the VM(s) and click Enable JIT on VMs.
3. Configure which ports are protected, the allowed source IP range, and the maximum request time.
4. When you actually need to connect, click Request access — the port opens for your IP only, for the time window you set.

Public vs Private IP Address

Azure App Service

App Service is Azure's fully managed PaaS for hosting web apps, REST APIs and mobile backends. You deploy your code; Azure handles the OS, runtime patching, and infrastructure.

What it supports

• .NET, Java, Node.js, Python, PHP, Ruby, and custom containers.
• Built-in autoscaling and load balancing.
• Deployment slots for staged rollouts.
• Custom domains, free/managed SSL certificates.
• Direct integration with GitHub Actions, Azure DevOps, and container registries for CI/CD.

Azure App Service Plan

An App Service Plan defines the compute resources — region, VM size, and pricing tier — that host one or more App Service apps. It's the unit that actually gets billed, not the individual app.

Key points

• Multiple apps can share one plan, splitting the same underlying compute (useful for many small, low-traffic apps).
• The plan's tier determines available features: custom domains, autoscale, deployment slots, VNet integration, and more.
• Scaling up (changing the tier/size) and scaling out (adding instances) both happen at the plan level.

Azure App Service Pricing Tiers

Deploy a Web App in Azure

1. In the portal: Create a resource → Web App.
2. Choose a resource group, unique app name, runtime stack, operating system, and region.
3. Select or create an App Service Plan and pricing tier.
4. Click Review + create, then Create.
5. Once deployed, choose a deployment method under Deployment Center:
   • GitHub Actions / Azure DevOps — automatic build + deploy on every push.
   • Local Git — git push azure main deploys directly.
   • ZIP deploy — az webapp deploy --src-path app.zip.
6. Browse to https://<app-name>.azurewebsites.net to confirm it's live.

az webapp up --name my-web-app --resource-group myRG --runtime "DOTNETCORE:8.0"

Deploy a Web App with a Database

1. Create an Azure SQL Database (or your database of choice) in the same region as the web app.
2. On the SQL server's Networking blade, allow "Allow Azure services and resources to access this server" so the web app can reach it.
3. Copy the connection string from the database's Connection strings page.
4. In the Web App → Configuration → Connection strings, add it there rather than hardcoding it in your code.
5. For secrets, prefer a Key Vault reference in app settings instead of storing the password in plain text.
6. Redeploy or restart the app so it picks up the new configuration, then test the connection.

Deploy a Web App with DB & Entity Framework

When your app uses Entity Framework Core, the schema needs to exist in Azure SQL before the app can use it — that's what migrations are for.

Typical flow

1. Create your migrations locally: dotnet ef migrations add InitialCreate.
2. Point the connection string at your Azure SQL Database (via appsettings.json for local testing, or App Service configuration for the deployed app).
3. Apply the migration to the cloud database: dotnet ef database update --connection "<azure-sql-connection-string>".
4. Deploy the application code as usual (ZIP deploy, GitHub Actions, etc.).

Connect to Azure SQL from SSMS

1. In the Azure Portal, open your SQL server and copy the Server name (looks like myserver.database.windows.net).
2. Go to the server's Networking blade and click Add your client IPv4 address so the firewall allows your machine.
3. Open SQL Server Management Studio and click Connect → Database Engine.
4. Enter the server name, choose SQL Server Authentication (or Microsoft Entra ID for identity-based auth), and enter your credentials.
5. Click Connect — the database(s) should now appear in Object Explorer.

Promote Builds from Local to Azure

A safe release path moves code through stages rather than pushing straight from a laptop to production.

A typical pipeline

1. Local development — write and test code, commit to source control.
2. Build pipeline (Azure DevOps or GitHub Actions) — compiles, runs tests, and produces a deployable artifact.
3. Deploy to a staging slot — the artifact is deployed to a non-production deployment slot first.
4. Validate — smoke-test the staging slot against its own URL.
5. Swap to production — once validated, swap staging into production with no downtime.

dotnet publish -c Release -o ./publish
az webapp deploy --resource-group myRG --name my-web-app --slot staging --src-path ./publish.zip
az webapp deployment slot swap --resource-group myRG --name my-web-app --slot staging

Deployment Slots

Deployment slots are live App Service apps with their own hostname, running on the same App Service Plan as your production app — available from the Standard tier and above.

Why use them

• Deploy and test a new version at myapp-staging.azurewebsites.net without touching production.
• When ready, swap staging and production — the swap is near-instant and involves no downtime, because it happens by re-routing traffic, not by copying files live.
• If something's wrong after a swap, swap back just as quickly.

Deployment Slot Setting

By default, app settings and connection strings swap along with the code when you swap slots. A slot setting (also called "sticky") is marked to stay with its slot instead of following the swap.

When to use it

• A setting like ENVIRONMENT_NAME that should always say "staging" in the staging slot, even after a swap.
• Connection strings that point to slot-specific resources (e.g. a staging database that should never accidentally become the production connection string).

How to mark one

1. Go to the app's Configuration blade.
2. Find the setting or connection string.
3. Check the Deployment slot setting checkbox next to it, then save.

Deployment Slots Auto Swap

Auto swap automatically promotes a slot straight into production every time a new deployment finishes and passes warm-up — removing the manual "click swap" step from continuous deployment.

How it works

1. Push code to the slot (e.g. via CI/CD).
2. App Service warms up the new instance in the background using the app's configured warm-up path.
3. Once warm-up succeeds, the slot is automatically swapped into production with no manual intervention.

Enabling it

1. Open the slot → Configuration → General settings.
2. Turn on Auto swap and choose the destination slot (usually production).
3. Optionally configure a custom warm-up path so Azure waits for your app to be truly ready, not just "process started."