DEV Community

Cover image for From Zero to Auto-Scaling Hero: Deploying a VMSS on Azure 🚀
David Cletus
David Cletus

Posted on

From Zero to Auto-Scaling Hero: Deploying a VMSS on Azure 🚀

#cloud #azure #beginners #developer

From Zero to Auto-Scaling Hero: Deploying a VMSS on Azure 🚀

Ever wondered how big websites survive a sudden rush of visitors without crashing? The secret is auto-scaling — the server army quietly grows when traffic spikes, and shrinks back down when things calm down, so nobody pays for computers they don't need.

In this post, I'm walking you through exactly how I built that on Microsoft Azure — from a completely empty subscription to a live webpage served by 5 auto-scaling virtual machines sitting behind a load balancer.

By the end, you'll have your own mini traffic-proof web app running in the cloud, and you'll know how to tear it all down without leaving a single unpaid bill behind.

📚 This is part of a series! I've already covered the foundational pieces in earlier posts:

If any of the early steps below feel unfamiliar, those posts break them down in full detail. Here, I'll recap them quickly and then dive deep into the part that's new: auto-scaling with VMSS.

🧩 What We're Actually Building

Think of it like building a house, street by street:

  1. Resource Group – an empty folder that holds everything we create (so we can delete it all in one click later)
  2. Virtual Network (VNet) + Subnet – the private street our servers will live on
  3. Virtual Machine Scale Set (VMSS) – a group of identical servers that can grow or shrink automatically
  4. Load Balancer – the traffic cop that spreads visitors evenly across all the servers
  5. A tiny Apache web page – so we have something to actually see working in the browser

Here's the flow in one picture (in your head, for now): Resource Group → Network → Subnet → Scale Set → Load Balancer → 🌍 Live Website

✅ Before You Start

Step 1: Say Hello to the Azure Portal 👋

Everything starts here — portal.azure.com. This is mission control for every Azure resource you'll ever create.

The Azure homepage — our home base for the whole build.

Step 2: Quick Recap — Resource Group, VNet & Subnet 📁🛣️🏘️

I've already walked through this part step-by-step in an earlier post, so here's the short version — check out Setting up a Resource Group, Virtual Network & Subnet on Azure for the full click-by-click guide.

Here's what happened, in a nutshell:

  1. Created a Resource Group called Smyles-RG — the folder that holds everything in this project, so it can all be deleted in one click later.

  1. Built a Virtual Network called Smyles-VN inside that resource group — a private, isolated network, like a gated estate for our resources.

  1. Carved out a Subnet called Smyles-Subnet inside the VNet — a smaller slice of that estate where our servers will actually live.

💡 Simple English tip: Resource Group = the folder. VNet = the private estate. Subnet = the specific street inside it. Our servers move in next.

With the land prepped, we're ready for the main event.

Step 3: Create the Virtual Machine Scale Set (VMSS) 🖥️🖥️🖥️

This is the star of the show. A VMSS doesn't create just one server — it creates a template for identical servers that Azure can multiply or shrink automatically based on demand.

3.1 — Find and open VMSS

  1. Search "vmss" in the top search bar and select Virtual machine scale sets.

  1. Click Create.

3.2 — Basics: name, region, and zones

Fill in the resource group (Smyles-RG), give the scale set a name (Smyles-vmms), pick your region, and choose Zones 1, 2, 3 for high availability (this spreads your servers across different physical data centers, so one outage doesn't take everything down).

3.3 — Orchestration and scaling mode

Choose:

  • Orchestration mode: Flexible — the modern, more flexible way Azure manages your servers
  • Scaling mode: Autoscaling — this is the whole point! Let Azure decide how many servers we need based on CPU usage

3.4 — Configure the scaling rules

Click Configure to fine-tune exactly how the auto-scaling should behave.

Click Add a scaling condition, name it (Smyles-scaling-condition), and set the instance limits — I chose a minimum of 2 and a maximum of 5 servers.

Then define the actual trigger rules:

  • Scale out (add a server) when CPU usage goes above 80%
  • Scale in (remove a server) when CPU usage drops below 20%

Save it, and you'll see both the Default condition and our new Smyles-scaling-condition sitting side by side.

💡 In plain English: "If the servers are working too hard (above 80% CPU), add a helper. If they're bored (below 20% CPU), send a helper home. Never go below 2 or above 5 helpers."

3.5 — Instance details: OS, size, and count

Set the instance count to 5, choose the image — I picked Ubuntu Server 24.04 LTS — and select a size. I went with the budget-friendly Standard B1ms.

3.6 — Admin account

Create a login for the servers. I used the username smyles with a password (SSH keys work too, if you prefer).

3.7 — Networking: plug into our VNet

Head to the Networking tab. Select Smyles-VN and Smyles-Subnet. Click Create new nic to set up the network card for our servers.

Name the NIC (Smyles-Networkinterface), keep the network security group on Basic, and allow HTTP (port 80) so the outside world can actually reach our website.

3.8 — Add a Load Balancer

Still on the Networking tab, choose Azure load balancer, then click Create a load balancer.

Name it Smyles-loadbalancer, set the type to Public (so it has an internet-facing address), and the protocol to TCP. Click Create.

💡 Simple English tip: A load balancer is like a receptionist. Visitors don't talk to individual servers — they talk to the receptionist, who quietly sends them to whichever server is free.

3.9 — Health monitoring

Switch to the Health tab and enable Application health monitoring. This lets Azure automatically detect and replace any server that stops responding.

Click Configure and set:

  • Protocol: HTTP
  • Port: 80
  • Request path: /

Then Save.

3.10 — Custom Data (the magic script)

This is where the servers get their personality. In the Advanced tab, under Custom data and cloud-init, I pasted a small Bash script that automatically installs a web server and creates a webpage — the moment each server boots up, it's already ready to greet visitors.

Here's the exact script I used:

#!/bin/bash
sudo apt-get update -y
sudo apt-get install apache2 -y
sudo systemctl enable apache2
sudo systemctl start apache2
HOSTNAME=$(hostname)
cat <<EOF | sudo tee /var/www/html/index.html
<!DOCTYPE html>
<html>
<body style="font-family:Arial;text-align:center;padding-top:100px;background:#f4f4f4">
<h1 style="color:#0078D4">Hello from $HOSTNAME</h1>
<p>Azure VMSS Instance</p>
</body>
</html>
EOF
sudo systemctl restart apache2
Enter fullscreen mode Exit fullscreen mode

What this script does, in plain English:

Line What it means
apt-get update Refreshes the list of available software
apt-get install apache2 Installs Apache — a popular web server
systemctl enable/start apache2 Turns the web server on, and keeps it on after reboots
HOSTNAME=$(hostname) Grabs the unique name of this particular server
cat <<EOF ... EOF Writes a simple HTML webpage that greets visitors with the server's own name
systemctl restart apache2 Restarts the web server so the new page shows up

The cool part? Because this script runs on every single instance in the scale set, each server will proudly display its own unique name — so when we later refresh the load balancer's page, we can literally watch traffic bounce between different servers!

3.11 — Review and create

With everything configured, click Review + create. Wait for the green "Validation passed" banner, then click Create.

Sit back and relax while Azure spins up 5 identical virtual machines for you. ☕

Step 4: See It Come Alive 🌍

4.1 — Grab the load balancer's address

Open your new scale set (Smyles-vmss) and go to Networking → Load balancing.

Copy the Frontend IP address — this is the single public address that represents all five of your servers.

4.2 — Paste it in your browser

Paste that IP address into a new browser tab and hit enter...

"Hello from smyles-vmR4TV8G" — a real, working, auto-scaling web app, built entirely from the ground up! Refresh the page a few times and watch the hostname change as the load balancer sends you to different servers behind the scenes. That's auto-scaling infrastructure in action. 🎉

Step 5: Clean Up — Don't Leave the Lights On! 💡

Cloud resources cost money for every hour they exist, even if nobody's visiting your website. Once you're done experimenting, tear it all down — and thanks to our Resource Group trick from Step 2 (or see the full explanation in my earlier Resource Group post), this takes seconds.

  1. Go back to Resource groups and open Smyles-RG.

  1. Click Delete resource group.

  1. Type the resource group name to confirm (Azure double-checks so you don't delete anything by accident), then click Delete.

And just like that — the VMs, load balancer, network, subnet, and everything else vanish, and your billing stops. One folder in, one folder out. Also do the same for NetworkWatcherRG 🧹

🎯 What We Actually Learned

  • Resource Groups keep your projects tidy and easy to delete
  • Virtual Networks & Subnets give your servers a private, controlled space to live in
  • VMSS with Autoscaling means your infrastructure grows and shrinks with real demand — you stop paying for idle servers
  • Load Balancers spread traffic so no single server gets overwhelmed
  • Custom Data / cloud-init lets you automate server setup completely — no manual SSH-ing into five different machines
  • Health monitoring keeps your app resilient by auto-replacing unhealthy instances

That's the entire journey — from an empty Azure subscription to a self-healing, self-scaling website, torn down responsibly at the end. If you followed along, you didn't just read about cloud infrastructure — you built it. 🙌

Got questions or stuck somewhere? Drop a comment below — happy to help troubleshoot!

Follow me for more hands-on Azure and cloud engineering walkthroughs, straight from my own learning journey. ☁️

Top comments (0)