12. On the Add backend pool page, click + Add and select the virtual machines created earlier.

*

13. On the Add IP Configurations to Backend Pool page, select the virtual machines and click Add and then save.

*

14. Configure Load Balancing Rule

Click on Next: Inbound rules.

Under the Load balancing rules section, click + Add load balancing rule.

Select the following details:

• Name: LoadBalancerRule
• IP version: IPv4
• Frontend IP address: Select Frontend
• Backend pool: Select BackendPool
• Protocol: TCP
• Port: 80
• Backend port: 80

Health probe: Click Create new and configure:

• Name: HealthProbe
• Protocol: TCP
• Port: 80
• Interval: 5 seconds

Click Review + Create

Note: If session persistence is enabled, a client's subsequent requests will always go to the same backend server.

Note: An inbound rule is required on the Load Balancer to allow incoming traffic and forward it to backend resources. Without it, the Load Balancer will not accept or route any traffic, even if the backend pool and health probes are configured.

Note: You can create up to 100 load balancing rules.

*

15. On VM1, delete the existing NSG RDP rule and create a new one that:

Allows RDP (port 3389) only from within the Azure Virtual Network (source: VirtualNetwork service tag).

• On your Virtual Machine (e.g., VM1) blade, click "Network settings" under "Networking."
• Click "Add inbound security rule" (located on the right pane).

Configure Rule:

• Source: Select "Service Tag".
• Source Service tag: Select "Virtual network".
• Destination: Select "IP Addresses".
• Destination IP addresses/CIDR ranges: Enter the private IP address of your VM (e.g., 10.1.0.4).
• Service: Select "RDP".
• Priority: Enter a priority (e.g., 100).
• Name: Enter a name for the rule (e.g., Allow_RDP_via_Bastion).

Add Rule: Click the "Add" button to create the rule.

Note: This ensures that RDP access to VM1 is allowed only from within the Azure virtual network, effectively requiring users to connect through Azure Bastion (which uses a private IP inside the VNet) instead of exposing RDP publicly.

Note: Access is restricted to the VM’s private IP address only (10.1.0.4)

*

16. On VM1, delete an existent HTTP rule and add a second NSG inbound rule that allows the Azure Load Balancer to send HTTP (port 80) and HTTPS (port 443) traffic to the VM.

• On your Virtual Machine's (VM1) blade, click "Network settings" under "Networking."
• Click "Add inbound security rule" (on the right pane).

Configure Rule:

• Source: Select "Service Tag".
• Source service tag: Choose "AzureLoadBalancer".
• Destination port ranges: Enter "80, 443".
• Priority: Set a priority (e.g., 110).
• Name: Give the rule a descriptive name(e.g., Allow_LoadBalancer_HTTP_Inbound).

Add Rule: Click the "Add" button to create the rule.

*

17. On VM1, create a "Web App Public Access" third NSG rule that allows inbound traffic on ports 80 and 443 from the Internet (as the source), but restrict the destination IP to the VM’s private IP.(BackendPool subnet only)

• On your Virtual Machine's (VM1) blade, click "Network settings" under "Networking."
• Click "Add inbound security rule" (on the right pane).

Configure Rule:

• Source: Select "Service Tag".
• Source service tag: Choose "Internet".
• Destination: Select "IP Addresses".
• Destination IP addresses/CIDR ranges: Enter the BackendPool subnet range (e.g., 10.1.0.0/24).
• Destination port ranges: Enter 80, 443.
• Protocol: Select "TCP".
• Action: Select "Allow".
• Priority: Enter "120"
• Name: Give the rule a descriptive name (e.g., Allow_public_access_from_internet).

Add Rule: Click the "Add" button to create the rule.

Note: This ensures that only traffic from the Internet targeting the VM’s specific IP range (i.e., the BackendPool subnet) through the Load Balancer is allowed, providing public access while limiting exposure.

*

18. Repeat steps 14 to 16 on VM2 to apply the same NSG rules.

Note: You also could add all the VMs to an Application Security Group (ASG) and apply the three NSG rules to the ASG instead of configuring them individually on each VM.

Bonus (Optional): Create an Application Security Group (ASG) and assign two VMs to it by associating their network interfaces.

Step 1: Create the ASG

1. Go to the Azure Portal.

2. Search for and select “Application Security Groups.”

3. Click “+ Create.”

4. Fill in the details:

   • Subscription: Choose your subscription.

   • Resource Group: Select the same one your VMs are in.

   • Name: ASG1

   • Region: Must match the region of your VMs.

5. Click “Review + Create”, then “Create.”

*

Step 2: Associate VMs with the ASG

For each VM:

1. In the Azure Portal, go to each Virtual Machine you want to associate.
2. In the left menu, under Networking, click Application security groups.
3. Click + Add application security groups.
4. Select the ASG you created (e.g., ASG1) from the list.
5. Click Add to associate the ASG with the VM’s network interface.

🔁 Repeat for VM2.

*

Step 3: Create NSG and associate it with the BackendPool subnet

• In the Azure portal's search bar, type "nsg".
• From the search results under "Services," click "Network security groups."

Fill in the "Basics" tab:

• Select your "Subscription".
• Choose an existing "Resource group" or "Create new".
• Enter a "Name" for the NSG (e.g., NSG_BackendSN).
• Select a "Region" (e.g., "East US").
• Review + create: Click the "Review + create" button.

Note: You don’t need separate NSGs for each VM; instead, create a shared NSG for the subnet and use Application Security Groups (ASGs) in the rules to target only the appropriate VMs. This reduces duplication and makes your security setup easier to manage.

• In your NSG (e.g., NSG_BackendSN), click "Subnets" under "Settings" in the left-hand menu.
• Click the "+ Associate" button.
• Choose the "Virtual network" that contains your subnet (e.g., VNET1 (rg_sb_eastus)).
• Choose the "Subnet" you want to associate (e.g., BackendPool).
• Click the "OK" and then "Save" button (not visible in this crop but typically present) to confirm the association.

*

Step 4: Use the ASG in NSG Rules

Now you can create NSG rules that apply to all VMs in the ASG, instead of configuring them individually.

1. Go to Network Security Groups.

2. Select your NSG.

3. Under “Inbound security rules”, click “+ Add.”

4. In the rule:

   • Destination: Choose “Application Security Group”

   • Destination ASG: Select ASG1

   • Configure ports, protocols, priority, and name.

5. Click Add.

Note: Use the same rules configured earlier, but set the destination to 'Application Security Group', then select the previously created ASG1 from the dropdown menu instead of configuring each VM individually.

*

19. Install IIS on Both Virtual Machines

• Connect to each VM via RDP using Azure Bastion

*

20. Open PowerShell as Administrator.

Run the following command to install IIS:

Copy Command: Install-WindowsFeature -name Web-Server -IncludeManagementTools

*

21. Replace the default HTML file located at C:\inetpub\wwwroot\iisstart.htm with your modified version.

Note: Replacing the default iisstart.htm allows us to uniquely identify each VM by customizing its web page.

Copy Code

*

22. Repeat steps 17 to 19 for VM2 but use the code for VM2:

Copy Code

*

23. Test the Load Balancer

From the left menu, go to Frontend IP Configuration, copy the IP address, and paste it into your browser.

*

24. You will be redirected to one of the two Virtual Machines in the backend pool.
Note: Try performing a hard refresh a few times by pressing CTRL + Shift + R to load content from the other virtual machine or use different browsers.

*

Bonus: Automate the installation of IIS on all VMs already deployed in the East US region using a PowerShell script.

1. Create an iis.ps1 script on your local system, then either upload it to Azure or execute it directly within an Azure PowerShell session.

Copy code

*

2. Run the script by entering ./iis.ps1 in your Azure PowerShell session.

3. IIS is now installed on all VMs in the East US region.

Note: Many bulk installations and configurations, such as the Microsoft Antimalware extension, IIS, SQL Server, .NET Framework, and other VM extensions or software, can be automated efficiently using PowerShell scripts.

*

Conclusion
By following these steps, you've successfully built a secure and highly available web application infrastructure in Azure. You created a private network, deployed fault-tolerant virtual machines, enabled secure management access with Azure Bastion, enforced traffic control using NSG rules, and configured IIS as a web server. Finally, by placing the VMs behind an Azure Load Balancer, you ensured both scalability and uninterrupted access to your application. This setup not only supports production-level availability but also aligns with Azure best practices for security and performance.

*

Written by Kirill.A - Azure & Cybersecurity Consultant at AntusNet