Step-by-Step Guide: Creating and Configuring Azure Firewall with Load Balancer Integration + Monitoring

In this blog, I’ll walk you step by step through creating, configuring Azure Firewall and Monitoring, starting from best practices for setting up a Virtual Network (VNet) and Firewall, to integrating a Load Balancer.

For easier reading, you can view the same blog on Notion at this link: ***Complete Azure Firewall-Load Balancer-Monitoring Integration***

Before we begin, it’s important to understand how internet connectivity works in Azure and the different ways to configure VM inbound and outbound traffic. I’ve covered this in detail in another blog here: 👉 Understanding Azure VM Internet Connectivity Options

Now, let’s get started.

Section 1: Creating VNet and Firewall

1. In the Azure portal, search for Virtual networks → click Create.

2. Select an existing Resource Group (or create a new one). Choose the correct Region.

• Click Next: Security to go to Security tab.

3. Enable Bastion Host. Since we’ll be creating VMs in a private subnet, we will be using Bastion Host to connect to them.

• This also creates a public IP for Bastion Public IP.

• Enable Firewall.
• Choose the Firewall SKU carefully. Basic is good enough for demo purpose. I selected basic.

Basic vs Standard Firewall

Basic SKU requires two subnets: AzureFirewallManagementSubnet and AzureFirewallSubnet. It has limited bandwidth and capabilities, requiring the dedicated AzureFirewallManagement Subnet .

Standard & Premium SKUs can handle management and user traffic in a single AzureFirewallSubnet, without needing a separate management subnet.

You cannot upgrade Basic to Standard, but you can upgrade Standard → Premium.

Standard is significantly more expensive than Basic (I’ve included pricing comparison for both the cases at the end).

📖 More details: Choose the right Firewall SKU

4. Create a Firewall Policy.

Classic Rules vs Firewall Policy:

Firewall Policies are recommended — they support centralized, hierarchical management with rule collection groups, inheritance, and centralized control via Firewall Manager.

Classic rules lack these advanced capabilities and are only supported in Standard SKU.

Note: Firewall Policy is free for a single firewall, but if reused across multiple firewalls, it becomes a billable object ($100 per policy per region). 📖 Firewall Policy Pricing

• You’ll also notice two public IPs getting created if using Basic SKU (one for Firewall, one for Management traffic).
• Click Next: IP addresses to congigure subnets.

5. On the IP Addresses tab:

• Subnets created: AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet, and Default.

• Edit the Default subnet → rename to WorkerSubnet (or create a new one with /24 range).

• Scroll down in the Edit subnet drawer, and Enable Private Subnet, which blocks direct outbound access by default. We are going to give access via Firewall.

• Click Save → Review + Create.

6. On the final Review + Create page, verify and click Create. Deployment takes 5–10 minutes.

👉 If you already have a VNet deployed and want to add Firewall:

1. First go to Vnet -> subnets, Add required subnets (AzureFirewallSubnet, and AzureFirewallManagementSubnet if using Basic). These names must match exactly.

2. Go to Firewall -> Create a Firewall, these steps are similar to the above creation. Select SKU, associate with your VNet, configure Firewall Policy, attach public IPs, and deploy.

Section 2: Creating a VM in WorkerSubnet

1. Go to Virtual Machines → Create. Select the same Resource Group and region as the firewall.

2. Select Image.

• Now scroll down to select the Image and Size. I have chosen Ubuntu Server as the Image and the cheapest option, Standard_B1s — 1 vCPU, as the Size. This is the most crucial factor that impacts your pricing, and as you can see, the page also displays the pricing on the right-hand side.

3. Configure Authentication

• Scroll down to Authentication. I’ve selected Password (less secure than SSH keys, but fine for now). Set a username and password, then copy and save them. Leave other settings as default
• Click on Networking tab.

4. On the Networking tab:

• Select the VNet and WorkerSubnet.

• Set Public IP = None (we’ll use Firewall for secure access).

• Check Delete NIC when VM is deleted.

Enable Delete NIC when VM is deleted. While NICs are free, unused public IPs incur charges. We aren’t creating one, but it’s good practice.

5. Leave other defaults → Review + Create → Deploy (2–5 minutes).

Section 3: Creating a Route Table and Routes

1. Go to Route Tables → + Create. Select Resource Group, region, name it, leave Propagate Gateway Routes = Yes.

2. After deployment, open the Firewall and copy its private IP before configuring the routes.

• Firewall -> Private IP

3. Create Route:

• Now go back to the newly created Route table. In Route Table → Routes → + Add Route:

• Destination = 0.0.0.0/0
• Next hop = Firewall Private IP (paste the Firewall Private IP here)
• This basically forces all traffic through the firewall.

4. Associate subnet:

• Go to Subnets → Associate with WorkerSubnet.

Section 4: Firewall Policy

By default, all traffic is blocked.

1. By default, all traffic is blocked by the firewall. You can verify this by logging into the VM and running curl ifconfig.me to check the public IP it uses to connect to the internet.

• Run hostname -I to check VM’s private IP.
• login to the VM. Virtual Machines -> VM-1 -> Connect -> Bastion

• Since we haven’t configured any Public IP for the VM, and the VM is in the private subnet, curl ifconfig.me → should fail since outbound is blocked.
• It also also cannot do sudo apt update

2. Configure Firewall Policy:

• Application Rules:
• Firewall → Firewall Policy → Application Rule

• Add a rule with Source = WorkerSubnet (10.0.0.0/24). For the source IP, I used the WorkerSubnet range, though you can restrict it to a single VM IP for more granular control.
• Destination = *

👉 About Priority: Each rule has a priority value. Rules are processed in ascending order — lower numbers have higher priority. Once traffic matches a rule, processing stops.

• click Add. It may take a few minutes for the rule to take effect.

3. Network Rules:

• Allow any protocol, any port, source = WorkerSubnet.
• Go to Network rules on the left. Allow any protocol, all ports (*), and set the source as the WorkerSubnet range.

• Click Add. If it fails, wait until the application rule is created.
• You can add one policy at a time.

4. Checking the VM again:

• curl ifconfig.me should now show the Firewall Public IP.
• Internet access (curl https://google.com) and sudo apt update should now work.

We have successfully configured outbound access to the VM. Now we will give inbound access via Load Balancer using Azure Firewall DNAT.

Section 5: Load Balancer Integration

Now let’s enable inbound access through a Load Balancer via Firewall.

1. Create a second VM (VM-2) in the same subnet with same configurations as VM-1. Verify both VMs use Firewall’s public IP (ifconfig.me).

1. Install Apache2 on both VMs:

sudo apt update
sudo apt install apache2 -y
echo "VM Private IP: $(hostname -I)" | sudo tee /var/www/html/index.html 
sudo systemctl restart apache2

• This should create an HTML page which displays the VM’ IP.

2. Create a Load Balancer:

• Resource Group + Region same as Firewall.
• SKU = Standard.
• Type = Internal (since we’re routing via Firewall).

• Frontend IP Config → choose WorkerSubnet

• Now click Next: Backend pools. Here you create a Backend Pool and simply select the two VMs we just created.

• Inbound Rules → create Load Balancing Rule (TCP, Port 80). Create Health Probe.
• Chose Frontend Ip address as Dynamic (Choose static for production for stability).

Dynamic or Static IP? A static IP is fixed, while a dynamic IP may change when the load balancer is stopped, started, or redeployed. Static IPs are recommended to avoid updating DNAT rules each time the IP changes (explained in the next section). For this demo, I’m using a dynamic IP since it’s cheaper — dynamic IPs are free when the resource is stopped, while static IPs incur charges regardless.

• Scroll down to create Health Probe.

• Save the load balancing rule

• Finally, you can keep everything else default and click on Review + Create.

Section 6: DNAT Rule in Firewall

To integrate Load Balancer with Firewall:

1. Create DNAT Rule → Go to Firewall-policy → DNAT rules

2. Create a rule:

• Destination IP : Firewall Public IP, Destination Port : 80
• Translated IP : Load balancer IP, Translated Port: 80

If you’re using a Dynamic IP for your Load Balancer (Section 5), the IP will change whenever it’s restarted or redeployed. In that case, you must also update the DNAT rule with the new IP.

• You will find the load balancer IP in load balancer -> Frontend IP configuration

• Click: Add

3. Edit VM NSG inbound inbound port rule:

Now we have configured the Firewall and load balancer integrations, the final piece is to enable the VMs to use the Firewall IP

• VM-1 -> Networking -> Networking settings -> create port rule : inbound port rule

• We want the traffic to be coming from the Firewall, therefore we have to give the firewall private IP as the source IP

• Destination port 80

• Repeat the same for VM-2

4. Verify VM connectivity:

• Go to the load balancer -> Settings -> load Balancing rules.
• Click on View details

• You will be able to see the two VMs should be up with a green tick.

Section 7: Verification

Use the Firewall Public IP to access the VM: http://<Firewall-Public-IP>

• This should show the VM HTML page that we deployed.

• The IP 10.0.0.5 is the VM-2 IP.
• To verify if both the VMs are being load balanced. You can change the status of VM-2 from UP to Down. This should now route the traffic to VM-1.
• Load Balancer -> Backend pools

Successful

• This is showing 10.0.0.4, which is my VM-1 private IP.

Notes on Public Load Balancer

In this demo, we used an Internal Load Balancer with Firewall Public IP as the entry point. This is the preferred design, as it simplifies the setup.

If you already have a Public Load Balancer and want to integrate it with the Firewall, follow the same steps — just add an extra route in your route table:

• Keep VM NSG inbound port rules same; source as Firewall Private IP.
• Add a Route in Route Table with next hop = Internet via Firewall.

• This avoids traffic asymmetry and ensures Firewall logs all traffic.

📖 More on Load Balancer + Firewall Integration

Section 8: Monitoring

This is the final step of our integration.

In Azure Monitor, pricing depends on the volume of logs ingested and the retention period. For Firewall logs, you must create a Log Analytics Workspace.

• Retention: 31/90 days included; extendable up to 12 years.
• Cost: ~$2.30 per GB. 📌 Full pricing details

Setup

1. Go to Azure Firewall → Monitoring → Diagnostic Settings → + Add diagnostic settings.
2. Select which logs/metrics you want to collect (or choose all).
3. Attach a Log Analytics Workspace (create one if not available).
4. Optionally, enable Archive to Storage Account for long-term retention.
5. Click Save.

Query Logs

1. Generate some activity from your VMs to populate logs (may take ~5 minutes).
2. Go to Firewall → Monitoring → Logs.
3. In the query section, switch to KQL mode.
4. Run:

AzureDiagnostics

This should display your logs.

5. If no results appear, wait a few more minutes or adjust the Time Range.

6. You can also switch the Time Zone at the bottom of the query editor for easier readability.

Wrapping Up

We’ve successfully:

• Created a VNet with Firewall
• Deployed VMs in private subnet
• Configured Route Tables + Firewall Policies
• Integrated Load Balancer with Firewall using DNAT rules
• Verified inbound + outbound connectivity
• Configured Monitoring

Pricing

Here’s the pricing comparison for the same project using Azure Firewall Basic vs. Standard. As discussed earlier, the Basic tier is significantly cheaper.

Basic:

Standard:

Replicating this project with the Basic Firewall will cost you under ₹200.

💬 Feel free to drop your questions and thoughts in the comments below!