TM Taeyang Moon
Hands-on Lab · ~60 min · Beginner–Intermediate

Build a highly available web server

VMSS + Application Gateway + Autoscale

Run several web servers with a Virtual Machine Scale Set (VMSS), distribute traffic with Application Gateway (L7 + WAF), and configure autoscale so servers grow and shrink with demand.

VMSSApplication Gateway WAF_v2AutoscaleVirtual Network

Lab information

🧭 What you will build in this lab 인터넷 → [공용 IP] → [Application Gateway + WAF] → [VMSS: web000000, web000001 …] Application Gateway acts like a "smart front desk" that distributes incoming requests across multiple web servers, and automatically adds more servers when they become busy.

Prerequisites

💡 Why use the portal? In production, you typically automate this with code (Bicep/Terraform), but when learning for the first time, clicking through the portal helps you visually understand what each component is and how it connects. (A version that deploys the same architecture as code is available in demos/vmss-appgw-ha/.)

Lab steps

Module 0: Create a resource group (5 minutes)

Goal: Create the "container" that will hold all resources for this lab.

  1. In the search box at the top of the portal, enter Resource groups → click it.
  2. Click + Create.
  3. Enter the following values: - Subscription: (your subscription) - Resource group: rg-lab-ha - Region: Korea Central
  4. Select Review + create → Create.

💡 Why start with a resource group? Every Azure resource lives inside a resource group. If you keep everything in one container, you can delete the whole container at the end of the lab and clean up costs easily (see Module 7).

✅ Check: If rg-lab-ha appears in the resource group list, you are successful.

Module 1: Create a virtual network (VNet) and two subnets (8 minutes)

Goal: Create the "private network" where the web servers and Application Gateway will live. Divide it into two subnets (smaller areas).

  1. Search for Virtual networks → + Create.
  2. On the Basics tab: - Resource group: rg-lab-ha - Name: lab-vnet - Region: Korea Central
  3. On the IP addresses tab, configure subnets as follows: - Confirm that the default address space is 10.0.0.0/16. - Change the default subnet name to snet-appgw and the range to 10.0.1.0/24 (or delete it and add a new one). - Click + Add subnet → name snet-vmss, range 10.0.2.0/24 → Add.
  4. Select Review + create → Create.

💡 Why split the subnets in two? Application Gateway requires a dedicated subnet used only by itself. Therefore, we separate snet-appgw (gateway only) and snet-vmss (web servers). Microsoft recommends a /24 size (about 251 IP addresses) for gateway autoscaling.

✅ Check: If you see both snet-appgw and snet-vmss in the lab-vnet > Subnets blade, you are successful.

Module 2: Run web servers with a VMSS (Virtual Machine Scale Set) (12 minutes)

Goal: Create multiple identical web servers at once and automatically install the nginx web server at boot time.

  1. Search for Virtual machine scale sets → + Create.
  2. On the Basics tab: - Resource group: rg-lab-ha - Name: lab-vmss - Region: Korea Central - Orchestration mode: Flexible (recommended) - Security type: Standard - Image: Ubuntu Server 22.04 LTS - Size: Standard_B2s (low cost, sufficient for a demo) - Authentication type: Password → username azureuser, enter a strong password (write it down) - Set Scaling (instance count): 2.
  3. On the Networking tab: - Virtual network: lab-vnet - Subnet: select snet-vmss. - Load balancing options: leave as None — Application Gateway will be attached separately in the next module.
  4. On the Advanced tab > Custom data, paste the following cloud-init: ```yaml #cloud-config package_update: true packages:
    • nginx runcmd:
    • HOSTN=$(hostname)
    • echo "

      Azure 고가용성 웹서버 랩

      응답 인스턴스: $HOSTN

      새로고침 해보세요.

      " > /var/www/html/index.html
    • systemctl enable nginx
    • systemctl restart nginx ```
  5. Select Review + create → Create. (1–2 minutes)

💡 What is VMSS? Think of it as a "template mold." It stamps out identical VMs, whether you need 1 or 100. cloud-init (custom data) is an installation script that runs automatically when a VM first boots. This ensures every instance has the same web page.

✅ Check: If two instances appear as "Running" in the lab-vmss > Instances blade, you are successful.

Module 3: Create Application Gateway (WAF) and connect it to the VMSS (15 minutes)

Goal: Create an L7 gateway that receives internet requests and distributes them to the two web servers, with WAF (Web Application Firewall) enabled.

  1. Search for Application gateways → + Create.
  2. On the Basics tab: - Resource group: rg-lab-ha, name: lab-appgw, region: Korea Central - Tier: WAF V2 - WAF policy: Create new (name lab-wafpolicy), mode Prevention - Autoscaling: Yes (minimum 1) - Virtual network: lab-vnet, subnet: snet-appgw
  3. On the Frontends tab: - Frontend IP type: Public - Public IP address: Create new → name lab-appgw-pip.
  4. On the Backends tab: - + Add backend pool → name vmssBackendPool. - Leave "Add backend pool without targets" as No, set Target type: VMSS → select lab-vmss → Add.
  5. On the Configuration tab — connect the routing rule: - + Add a routing rule: rule name routingRule, priority 100. - Listener: name httpListener, frontend Public, protocol HTTP, port 80. - Backend targets tab: select backend pool vmssBackendPool → backend settings Add new (name httpSettings, port 80, HTTP) → Add. - Add the rule.
  6. Select Review + create → Create.

⏳ This step takes 5–10 minutes. Application Gateway is slow to create because it provisions several internal components. Time for a coffee ☕

💡 Why enable WAF? WAF (Web Application Firewall) blocks common web attacks such as SQL injection and XSS at the gateway layer. Applying the OWASP rule set (an industry-standard list of attacks) in "Prevention" mode automatically blocks suspicious requests.

✅ Check: After deployment completes, if lab-vmss is connected under lab-appgw > Backend pools > vmssBackendPool, and Backend health shows healthy (green), you are successful.

Module 4: Verify load balancing (5 minutes)

Goal: See that requests arriving at one address are distributed across multiple servers.

  1. In lab-appgw > Overview, copy the Frontend public IP address.
  2. In your browser address bar, enter http://<that IP> → connect.
  3. Check the response instance name on the page and refresh several times (Ctrl+F5).

💡 Why does the name change? Application Gateway distributes (load balances) requests to different instances. Because cookie-based affinity is disabled, a different server may respond each time you refresh.

✅ Check: If the instance name alternates in the form web... as you refresh, load balancing is working.

Module 5: Verify high availability (5 minutes)

Goal: Confirm that the service continues even if one server fails.

  1. In lab-vmss > Instances, select one instance → Stop or Delete.
  2. Refresh the Application Gateway address in your browser again.

💡 Why does it keep working? Application Gateway's health probe checks each server every 30 seconds. It automatically removes failed servers from the distribution target list and sends traffic only to healthy servers. This is high availability.

✅ Check: If the page still responds normally after you take down one server, you are successful. (Only the healthy instance name appears.)

🔁 For the next module, return the instance count to a healthy state (2 instances). If you stopped an instance, Start it; if you deleted one, wait for automatic recovery or manually add an instance.

Module 6: Create and demonstrate autoscale rules (10 minutes)

Goal: Create rules that automatically add servers (scale-out) and remove servers (scale-in) based on CPU utilization.

  1. Open the lab-vmss > Scaling blade.
  2. Select Custom autoscale.
  3. Instance limits: Minimum 2 / Maximum 5 / Default 2.
  4. Add a rule (scale-out): - Metric: Percentage CPU, operator Greater than, threshold 70, duration 5 minutes (average). - Operation: Increase count by, instance count 1, cool down 3 minutes.
  5. Add a rule (scale-in): - Metric: Percentage CPU, operator Less than, threshold 30, duration 5 minutes (average). - Operation: Decrease count by, instance count 1, cool down 5 minutes.
  6. Click Save.
  7. Generate load to increase CPU. In lab-vmss > Instances, select one instance > (Portal SSH or Run command), then: - Enter this in VMSS > Instances > (select) > Run command > RunShellScript: bash sudo apt-get update -y && sudo apt-get install -y stress-ng sudo stress-ng --cpu 0 --timeout 300s

💡 Why is autoscale useful? When traffic is low, you run fewer servers to save cost; when traffic spikes, Azure automatically adds servers so the service does not slow down or fail. No one has to wake up at night to turn on servers. If average CPU stays above 70% for 5 minutes, instances are added one at a time.

✅ Check: In lab-vmss > Scaling > Run history or Instances, if the instance count increases from 2→3→… within about 5 minutes, you are successful. When the load stops, the instance count decreases again after about 5 minutes.

Cleanup

⚠️ Be sure to delete the resources when the lab is complete. Application Gateway is billed while it is running.

In the portal: rg-lab-ha resource group > Delete resource group > enter the name and delete.

In the CLI:

az group delete -n rg-lab-ha --yes --no-wait

✅ Deletion status: [ ] Complete

Instructor notes

References

← All labsPortal home