Performance Testing with Azure Firewall Basic SKU

Posted on September 14, 2023

Reading Time: 4 minutes

Overview:

Azure Firewall is a cloud-native, stateful, managed firewall service with built-in high availability, with incredible automated scaling and throughput capabilities, and many security features. In some cases, though, the price point can be a bit high to get started if they’re being used for basic L3/L4 rules, routing, and NAT capabilities. For this reason, last year the “Basic” Azure Firewall SKU was released.

There are two costs associated with Azure Firewall:

• Firewall base cost (per unit)
• Data Processed

The base cost per firewall unit is as follows (in East US, as of September 2023):

• Premium: $1,277/mo
• Standard: $912/mo
• Basic: $288/mo

As for the data processing costs, they are as follows:

• Premium: $0.016/GB ($16/TB)
• Standard: $0.016/GB ($16/TB)
• Basic: $0.065/GB ($65/TB)

You will note that with the lower base cost, comes a higher processing charge, so don’t get too excited thinking you can just swap production to a Basic SKU and save money, make sure and do your homework.

The features and comparisons of these SKUs is well documented at https://learn.microsoft.com/en-us/azure/firewall/choose-firewall-sku

You can look at a more in-depth list of features and capabilities of the Firewall Basic SKU here https://learn.microsoft.com/en-us/azure/firewall/basic-features.

You will notice that the documentation states that the Firewall Basic SKU says that it’s “recommended for environments with an estimated throughput of 250 Mbps”, this got me thinking though, how much throughput can it actually handle? Understandably this SKU is primarily designed for lower level or lab environments, but what if I need to do a data load or something, is it really limited to 250 Mbps?

Lab Testing:

To test this theory, I built a little lab environment:

• Hub network with an Azure Firewall Basic SKU
• Two spoke networks with a Route Table that point all traffic through the Hub Firewall
• A Windows Client OS in the “client” vnet
• A Linux server in the “server-vnet” network
• Both VMs are configured as DS4_v4 so they have plenty of CPU and are capable of up to 10Gbps so we can be sure they won’t be a bottleneck in the testing.

Now that I have the lab environment build, I wanted to test the throughput of the firewall in two ways:

• SNAT the traffic through the Firewall to the Internet
• Route the traffic between spokes

Internet Speed Test:

For the first test, I chose to simply use everyone’s favorite at-home test – speedtest.net. To verify that we’re using the firewall as the path to the internet, I also took a screenshot of the public IP associated with it to compare to the speed test.

You will note that the IP address in both the pip and on the speed test are the same, and also that it looks like we’re getting 1Gbps through the Firewall Basic SKU to the internet.

Intranet Speed Test:

The second test is between spoke networks, routed through the hub. For this I configured my Linux server with the OpenSpeedTest docker container, you will notice the private IP in the address bar. This is a very cool project that I also run at home for quick diagnostics and load testing.

In this test, the client OS is traversing the peer to the hub network, then being routed by the Azure Firewall across the peer to the server network; with this test I got roughly 1Gbps as well, with <1 ms latency.

 

Conclusion:

While payloads like speedtest.net are surely not what I would consider a thorough load test, these are the types of results I was looking for in this quick test. If we were testing something for production, we would want to include things like max connections, speed per connection, total bandwidth, scaling metrics, etc.

The throughput available in Azure Firewall is impressive, with the Standard SKU capable of up to 30 Gbps and the Premium up to 100 Gbps (see https://learn.microsoft.com/en-us/azure/firewall/firewall-performance for more information). The Firewall Basic SKU though still holds its own, showing that it’s capable of 1 Gbps throughput which in many cases of lower-level or lab environments is more than enough. While I didn’t create an auto-deploy ARM template for this lab environment, let me know if it would be useful and I’ll put something together on GitHub.

If you have any questions, comments, or suggestions for future blog posts please feel free to comment below or reach out on LinkedIn or Twitter. I hope I’ve made your day a little bit easier!