Azure Fundamentals for Web Hosting: Hosting on Azure Virtual Machines (IaaS web server setup and hardening)

What VM-based web hosting means (and when to use it)

Hosting a website on an Azure Virtual Machine (VM) means you run your own web server inside a full operating system that you manage. This is Infrastructure as a Service (IaaS): Azure provides the virtualized compute, storage, and networking building blocks, while you control the OS configuration, installed software, and most security/operations tasks.

Choose VM-based hosting when you need OS-level control, such as: installing custom modules, using legacy software, running background services alongside the web server, controlling exact OS versions and kernel settings, or meeting requirements that don’t fit managed platforms.

Build path overview

• Pick an OS image (Linux or Windows) appropriate for your web stack.
• Size the VM for a small workload and plan for scaling later.
• Configure disks (OS disk + optional data disk) with the right performance tier.
• Set up secure access (SSH keys for Linux; RDP with restricted access for Windows).
• Install and configure the web stack (Nginx/Apache or IIS).
• Expose only required ports and enforce rules with a Network Security Group (NSG).
• Plan operations: patching, backups, snapshots, and basic resilience options.

Step 1: Choose an image (Windows vs. Linux)

Linux images (common for Nginx/Apache)

Linux is often chosen for lightweight web servers and automation-friendly administration. Common choices include Ubuntu LTS and Debian. Prefer LTS releases for stability and longer security update support.

Windows images (common for IIS/.NET)

Windows Server is typically chosen when you need IIS, Windows authentication integrations, or Windows-only components. Ensure the image version aligns with your application requirements (for example, Windows Server 2022 for newer workloads).

Practical guidance

• If your app is a typical PHP/Node/Java static or reverse-proxy setup, start with Ubuntu LTS + Nginx.
• If your app requires IIS or Windows-specific dependencies, start with Windows Server + IIS.
• Keep the image “clean” (base OS) unless you explicitly want a marketplace image that pre-installs a stack; prebuilt images can be convenient but may include defaults you still need to harden.

Step 2: Size the VM for small workloads

VM size affects CPU, memory, and network throughput. For small web workloads, start with a general-purpose size and scale up if you observe CPU or memory pressure.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

Common starting points

• Small dev/test or low-traffic site: 1–2 vCPU, 1–4 GB RAM.
• Small production site with moderate traffic: 2 vCPU, 4–8 GB RAM.

Practical sizing checklist

• CPU-bound? (dynamic pages, heavy TLS, compression): prioritize more vCPU.
• Memory-bound? (app caches, many concurrent workers): prioritize more RAM.
• Disk I/O-bound? (CMS, frequent reads/writes): choose faster disk tiers and consider a data disk.

Step 3: Disks and storage layout (OS disk + data disk)

At minimum, a VM has an OS disk. For better manageability and performance, you can add a separate data disk for web content, logs, or application data. Separating OS and data can simplify backups and troubleshooting.

Recommended layout

• OS disk: keep for operating system and installed packages.
• Data disk (optional): store website content, application files, and/or logs depending on your design.

Practical steps (conceptual)

• Choose a disk performance tier appropriate for your workload (higher tiers for write-heavy apps).
• If using a data disk on Linux, format and mount it to a stable mount point (for example, /var/www or /data) and ensure it mounts on boot.
• If using a data disk on Windows, initialize it in Disk Management, assign a drive letter, and place site content/logs there if desired.

Step 4: Secure access: SSH keys and restricted RDP

Because you manage the OS, administrative access is a major security concern. The goal is to allow admin access only when needed, from known sources, using strong authentication.

Linux: SSH with keys (avoid passwords)

• Create or use an SSH key pair and configure the VM for key-based authentication.
• Disable password authentication for SSH where possible.
• Use a non-root admin user and elevate via sudo.

Example hardening settings (Linux SSH server):

# /etc/ssh/sshd_config (examples; validate for your distro/version) PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes

Windows: RDP with restricted access

• Do not leave RDP open to the entire internet.
• Restrict RDP to a known source IP range (for example, your corporate VPN egress IP) using NSG rules.
• Use strong credentials and consider additional controls such as Just-In-Time access if available in your environment.

Practical access workflow

• Default stance: no broad admin ports exposed.
• When you need admin access, temporarily allow SSH (22) or RDP (3389) from your trusted IP, perform the task, then remove or tighten the rule again.

Step 5: Install a web stack

Option A (Linux): Nginx

Nginx is commonly used as a high-performance web server and reverse proxy.

Example setup on Ubuntu/Debian:

sudo apt update sudo apt install -y nginx sudo systemctl enable --now nginx

Place a simple site:

echo 'Hello from Azure VM' | sudo tee /var/www/html/index.html

Verify locally on the VM:

curl -I http://localhost

Option B (Linux): Apache

Apache is widely used and has a large module ecosystem.

sudo apt update sudo apt install -y apache2 sudo systemctl enable --now apache2

Option C (Windows): IIS

IIS is the standard Windows web server. You can install it using Server Manager or PowerShell.

PowerShell: Install-WindowsFeature -Name Web-Server -IncludeManagementTools

Then place content in the default site directory and test locally from the VM using a browser or PowerShell request.

Step 6: Open only required ports and enforce with NSGs

For a typical public website, the only inbound ports you usually need are HTTP (80) and HTTPS (443). Administrative ports (SSH 22, RDP 3389) should be restricted to trusted sources or disabled when not in use.

NSG rule design (practical approach)

• Inbound allow: TCP 80 from Internet to the VM (or to the subnet/VM NIC as appropriate).
• Inbound allow: TCP 443 from Internet to the VM.
• Inbound allow (admin): TCP 22 or 3389 only from your trusted IP range.
• Inbound deny: everything else (often covered by default NSG behavior, but ensure no broad allow rules exist).

Port minimization checklist

• Do you really need HTTP (80)? If you enforce HTTPS, you may still keep 80 open only to redirect to 443.
• Do you need SSH/RDP always? Prefer temporary access patterns.
• Remove any “Any/Any” inbound allow rules.

Basic OS hardening for a web VM

Keep the attack surface small

• Install only necessary packages and roles.
• Disable or remove unused services.
• Use a host firewall (Linux: ufw or firewalld; Windows: Windows Defender Firewall) in addition to NSGs.

Run the web server with least privilege

• Use standard service accounts (for example, www-data on Linux) and avoid running services as administrator/root.
• Lock down file permissions so the web process can read what it needs and write only where required (for example, upload directories).

Enable HTTPS (TLS) planning

Your VM will typically terminate TLS at the web server (Nginx/Apache/IIS) unless you place a reverse proxy/load balancer in front. Plan certificate storage and renewal. Keep private keys protected and restrict access to certificate files.

Operations fundamentals: patching, backups, snapshots, resilience

Patching and updates

With IaaS, you are responsible for OS and application patching.

• Linux: use your distro’s package manager and consider unattended security updates for critical patches.
• Windows: configure Windows Update policies and maintenance windows.
• Practice: patch regularly, and patch faster for internet-facing services.

Backups (VM-level and data-level)

Plan backups for both the VM configuration and your application data.

• VM-level backups: capture the VM state and attached disks through a backup service/policy so you can restore after accidental deletion or corruption.
• Data-level backups: for databases or frequently changing content, use application-consistent backups where possible (for example, database dumps or native backup tools) in addition to VM backups.
• Test restores: a backup you never restored is an assumption, not a plan.

Snapshots (point-in-time disk copies)

Disk snapshots are useful before risky changes (OS upgrades, major configuration edits). They are not a full backup strategy by themselves, but they can provide quick rollback for a disk.

• Use snapshots as a short-term safety net.
• Label snapshots clearly (date, purpose) and clean them up to control cost.

Basic resilience options (conceptual)

A single VM is a single point of failure. For higher availability, you can distribute instances across fault domains or physical locations.

• Availability Sets: place multiple VMs in a set so Azure spreads them across different fault and update domains within a datacenter. This helps reduce downtime during maintenance or hardware failures.
• Availability Zones: place VMs in different zones (separate physical locations within a region). This improves resilience against datacenter-level issues.

Practical takeaway: if the site is important, plan for at least two instances and a way to route traffic between them (often combined with a load-balancing layer), and keep your VM configuration reproducible so you can rebuild quickly.