Three SKUs, and the distance between them is a cliff rather than a slope. Basic will tell you about a known malicious address. It cannot stop traffic reaching it.
On Basic, threat intelligence runs in alert mode and nothing else. Standard brings alert and deny, network level FQDN filtering, web categories and DNS proxy. Premium goes further with TLS inspection, a managed intrusion detection and prevention system carrying more than 67,000 signatures, and URL filtering across the full path. Which of the three you pick is essentially the entire design decision.

- 250 Mbps to 100 GbpsThe throughput range across the three SKUs
- Alert onlyWhat Basic threat intelligence can do
- 67,000 signaturesPremium IDPS, in over 50 categories
- All three SKUsBuilt-in high availability and availability zones
Eight things that determine which SKU you actually need.
Threat intelligence, and the Basic caveat that matters
Threat intelligence based filtering raises alerts on traffic heading to or coming from known malicious IP addresses and domains, drawn from the Microsoft threat intelligence feed. Standard and Premium can alert and deny. On Basic the documentation states outright that the feature only provides alerts and cannot deny traffic at all. Any business that selected Basic on price is running a firewall that watches known-bad destinations go by.
FQDN filtering, in two very different forms
Application level FQDN filtering works on all three, driven by server name indication, covering HTTPS and SQL traffic with no TLS termination involved. Network level FQDN filtering is a different matter and exists only on Standard and Premium. It works across every port and protocol using DNS resolution, and it is what allows you to filter outbound NTP, SSH, RDP or anything else by name instead of by address.
Only Premium does TLS inspection, and that is the decisive difference
What Premium does is decrypt outbound traffic, process it, then re-encrypt and forward it, which means two TLS connections exist rather than one, the firewall holding one with the web server and one with the client. That covers outbound inspection from Azure to the internet, and east-west inspection inside Azure including traffic to and from on-premises. Without it, almost everything happening inside HTTPS is invisible to you.
A managed IDPS, with signatures you can tune
The Premium intrusion detection and prevention system is signature based, carrying over 67,000 rules across more than 50 categories, with somewhere between 20 and 40 new rules arriving daily and room to customize up to 10,000 of them. Each individual signature can be set to disabled, to alert, or to alert and deny. Private IP ranges get configured so the system can distinguish inbound from outbound from east-west traffic, which it otherwise cannot.
Web categories, and why Premium categorizes differently
Both Standard and Premium can permit or refuse access by web category. What differs is how much of the request each one looks at. The published example makes it concrete: given an HTTPS request to www.google.com/news, Standard reads only the FQDN and files it under search engines, while Premium reads the complete URL and files it under news. Full path URL filtering exists on Premium alone, and it depends on TLS inspection being in place.
Throughput, which is a hard ceiling on Basic
Basic runs as a fixed scale unit on two virtual machine backend instances, with a recommended throughput around 250 Mbps. Standard autoscales to 30 Gbps and supports 1 Gbps fat flows. Premium reaches 100 Gbps with 10 Gbps fat flows. Note the consequence of Basic being fixed rather than autoscaling: outgrowing it is a migration project, not a slider you move.
DNS proxy, and the reason it exists
Acting as a DNS proxy is available on Standard and Premium, processing and forwarding DNS queries from your virtual networks to whichever server you nominate, and able to use custom DNS while still resolving the firewall own outbound dependencies through Azure DNS. The documentation calls this crucial for reliable FQDN filtering in network rules, which makes it a dependency to plan for rather than a convenience to enable later.
Everything shares the same operational floor
Every SKU includes the same foundation: high availability built in with no load balancers for you to configure, availability zone deployment at no extra charge, source and destination network address translation, complete Azure Monitor logging that integrates with your SIEM, central management through Firewall Manager, policy analytics, and automation through REST, PowerShell, the CLI, templates and Terraform.
Basic is not a scaled-down Standard. What it lacks is the part that actually blocks anything.
These are not three rungs on a price and performance ladder. Particular security capabilities are simply missing from Basic altogether, and one of the missing ones happens to be the reason organizations deploy a firewall in the first place.
- On Basic, threat intelligence based filtering runs in alert mode and only alert mode. The documentation states it cannot deny traffic. The identical feature on Standard and Premium both alerts on and denies traffic heading to or arriving from known malicious IP addresses and domains.
- Basic is also without network level FQDN filtering across all ports and protocols, without web categories, without DNS proxy and without forced tunneling. On top of that it runs as a fixed scale unit on two backend instances instead of autoscaling.
- Basic is positioned for small and medium businesses at a throughput of roughly 250 Mbps, and for that audience it is a perfectly legitimate product. It stops being legitimate the moment anybody assumes it does what Standard does.
- The failure we see repeatedly is a Basic deployment selected during a cost exercise, sitting underneath a security architecture document written against Standard capabilities. The mismatch goes unnoticed until an incident review asks why traffic to a known malicious domain was permitted.
Four things that decide whether this deployment repays what you spend on it.
The SKU gets chosen against the requirement rather than against the budget line
Where the security design calls for blocking traffic to known malicious destinations, Basic cannot do it, and no amount of configuration will change that fact. Where it calls for inspecting inside HTTPS, Premium is the only option. Write the capability requirement first and choose the SKU afterwards, and you avoid the deployment that satisfies a procurement decision while failing the architecture it was meant to serve.
We get DNS right before relying on FQDN rules
Filtering by name at network level means resolving those names to addresses, so the whole thing inherits the reliability of whatever does the resolving. DNS proxy functionality is described as crucial for reliable FQDN filtering in network rules. Design that dependency deliberately, or discover it when a rule starts failing intermittently for reasons nobody can reproduce on demand.
The intrusion detection system gets tuned rather than switched on and abandoned
There are more than 67,000 signatures in Premium spread across over 50 categories, with somewhere between 20 and 40 new ones arriving each day, room to customize up to 10,000 rules, and the ability to set any individual signature to disabled, to alert, or to alert and deny. What makes that tuning meaningful rather than cosmetic is configuring the private IP ranges, so the system can actually tell inbound, outbound and east-west traffic apart.
Policy analytics gets used for pruning rules, not only for adding them
A rule base only ever grows, for an obvious reason: adding a rule solves the problem in front of you today, while removing one risks breaking something nobody can remember the purpose of. Policy analytics shows how rules are actually used over time, which converts pruning from guesswork into an evidence-based exercise. Of everything you can do repeatedly on a firewall estate, that returns the most.
Six situations, common across American businesses, where the Azure-native firewall is the correct answer.
A hub and spoke landing zone across several subscriptions
Firewall Manager gives you a single place to administer firewalls spread across several subscriptions, applying one common set of network and application rules through firewall policies, and it covers both virtual network and Virtual WAN secure hub environments. In a landing zone where each workload has its own subscription, that is the difference between maintaining one policy set and watching a dozen of them drift apart.
A regulated business required to see inside its own encrypted outbound traffic
TLS inspection on Premium terminates and examines TLS connections in order to detect, alert on and mitigate malicious activity hiding inside HTTPS, holding two connections in the process, one with the server and one with the client. When an obligation demands visibility of what leaves your environment, whether that obligation comes from a NYDFS-regulated parent company, a federal contract or a security addendum a customer made you sign, the capability stops being optional. And it exists on Premium alone.
A business that needs URL rather than domain control
The documented example illustrates it neatly. Send an HTTPS request to a news path sitting on a search engine domain and Standard sees the domain alone, filing it under search engines, while Premium reads the entire URL and files it under news. Any policy written at path level rather than domain level runs straight into that gap, and the gap decides your SKU for you.
A business routing cloud traffic back through on-premises
Available on Standard and Premium, forced tunneling sends all internet-bound traffic to a next hop you designate rather than straight out to the internet, so an on-premises edge firewall or a network virtual appliance you already run gets to process it first. Those same two SKUs also support deployment with no public IP address at all when running in forced tunnel mode.
A business replacing a self-managed virtual appliance
Run a firewall appliance as a virtual machine in Azure and somebody has to own its patching, its sizing, its licensing and its availability design. Azure Firewall arrives with high availability built in and no load balancers to add, availability zone support at no additional charge, and autoscaling on Standard and Premium. Most of that operational surface simply disappears.
A small estate where Basic is genuinely the correct choice
Basic is positioned for small and medium businesses at roughly 250 Mbps of throughput, running on a fixed scale unit of two backend instances. For a small footprint that is a sound decision, subject to two conditions: the security design has to be written against what Basic genuinely does rather than what Standard does, and everybody has to understand that outgrowing it means a migration rather than an upgrade.
How US businesses secure Azure network traffic.
| Feature | Azure Firewall, right SKU | Network security groups only | A virtual appliance nobody manages |
|---|---|---|---|
Stateful layer three and four filtering | Yes | Yes | Yes |
Filtering by fully qualified domain name | Yes | No | Varies |
Known malicious destinations blocked | Yes, Standard and above | No | Varies |
Web category control | Yes, Standard and above | No | Varies |
Inspection inside TLS | Yes, Premium | No | Varies |
Intrusion detection and prevention | Yes, Premium | No | Varies |
High availability without extra design | Yes | Not applicable | No |
Scales with traffic automatically | Yes, Standard and above | Not applicable | No |
Central policy across subscriptions | Yes | No | No |
Patching and lifecycle burden | None | None | Yours |
Sixteen capabilities across Basic, Standard and Premium.
Capability
Stateful firewall with five-tuple rules
- Basic
- Yes
- Standard
- Yes
- Premium
- Yes
Capability
Source and destination network address translation
- Basic
- Yes
- Standard
- Yes
- Premium
- Yes
Capability
Built-in high availability
- Basic
- Yes
- Standard
- Yes
- Premium
- Yes
Capability
Availability zones
- Basic
- Yes
- Standard
- Yes
- Premium
- Yes
Capability
Application level FQDN filtering, SNI based
- Basic
- Yes
- Standard
- Yes
- Premium
- Yes
Capability
Network level FQDN filtering, all ports and protocols
- Basic
- No
- Standard
- Yes
- Premium
- Yes
Capability
Web content filtering by web categories
- Basic
- No
- Standard
- Yes
- Premium
- Yes
Capability
URL filtering on the full path, with SSL termination
- Basic
- No
- Standard
- No
- Premium
- Yes
Capability
Outbound TLS termination, forward proxy
- Basic
- No
- Standard
- No
- Premium
- Yes
Capability
Threat intelligence based filtering
- Basic
- Alert only
- Standard
- Alert and deny
- Premium
- Alert and deny
Capability
Fully managed intrusion detection and prevention
- Basic
- No
- Standard
- No
- Premium
- Yes
Capability
DNS proxy and custom DNS
- Basic
- No
- Standard
- Yes
- Premium
- Yes
Capability
Cloud scalability
- Basic
- Up to 250 Mbps
- Standard
- Up to 30 Gbps
- Premium
- Up to 100 Gbps
Capability
Fat flow support
- Basic
- Not applicable
- Standard
- 1 Gbps
- Premium
- 10 Gbps
Capability
Multiple public IP addresses
- Basic
- Supported
- Standard
- Up to 250
- Premium
- Up to 250
Capability
Forced tunneling
- Basic
- No
- Standard
- Yes
- Premium
- Yes
Five steps, and of everything produced, it is the rule base that outlives the project.
- 1
Establish the capability requirement, then the SKU
Five questions. Must known malicious destinations be blocked, or is alerting on them acceptable. Does traffic inside TLS have to be inspected. Is intrusion detection and prevention a requirement. Is policy written at URL level or at domain level. And what throughput is realistic for you. The SKU falls out of those five answers rather than being chosen first and justified afterwards.
- 2
Design the topology and the routing
Hub and spoke or a Virtual WAN secure hub, where availability zones sit, what public IP addresses are needed, and whether forced tunneling has to push internet-bound traffic through an on-premises edge you already operate. One point deserves emphasis: east-west inspection only occurs for traffic genuinely routed through the firewall, which makes routing design a security decision rather than a networking one.
- 3
Build the policy with tags rather than addresses
Service tags represent groups of address prefixes maintained and updated automatically on your behalf, while FQDN tags cover well-known Azure service traffic such as Windows Update. Both cut the number of rules a human has to look after considerably, and both carry on working when the underlying address ranges change beneath them.
- 4
Tune threat protection to the environment
On Premium we configure the private IP ranges first, so the intrusion detection system can tell inbound from outbound from east-west, then tune signatures category by category with individual rules set to disabled, to alert, or to alert and deny. On Standard, threat intelligence moves from alert into deny once the traffic has been watched for long enough that the false positive risk is understood rather than guessed at.
- 5
Wire logging and establish a pruning rhythm
Everything logs into Azure Monitor and feeds your SIEM, the Azure Firewall workbook handles the analysis, and a scheduled review using policy analytics hunts down rules that no longer match any traffic at all. Without that final step a rule base grows without limit, and a rule base nobody maintains eventually stops representing anybody deliberate intent.
What US businesses ask about Azure Firewall.
Fifteen questions that decide the design.
Sizing the SKU
- What throughput do you actually need?250 Mbps, 30 Gbps or 100 Gbps.
- Do you need to block known malicious destinations?Basic only alerts.
- Do you need TLS inspection?Premium only.
- Do you need signature-based IDPS?Premium only.
- Are you in a payment card environment?PCI DSS compliance is listed for Premium.
Policy design
- Network rules, application rules or both?They behave differently.
- Is DNS proxy needed for FQDN network rules?Microsoft calls it crucial.
- Are service tags and FQDN tags in use?They reduce rule sprawl significantly.
- Is east-west traffic in scope?The firewall inspects it, if routed there.
- Do you need forced tunneling?Standard and Premium only.
Operations
- Where do the logs go?Azure Monitor, with SIEM integration.
- Is Firewall Manager used across subscriptions?One policy set, many firewalls.
- Has anyone run policy analytics?It shows rule usage over time.
- Who reviews and removes stale rules?Rule bases grow, nobody prunes.
- Which IDPS signatures are tuned?Up to 10,000 can be customized.
The pages around this one.
Establish whether your firewall is able to stop traffic to a known malicious address, or merely report it.
The answer is determined by your SKU rather than by anything configurable, and it is a question most businesses have never thought to ask. It takes about a minute to establish, and now and then it changes the entire security architecture conversation.
Related Services
Explore more solutions that work great with this service
Microsoft Defender for Cloud Services
Defender for Cloud deployment for US organizations: enabling free
Learn moreMicrosoft Sentinel
Cloud-native SIEM and threat intelligence
Learn moreFirewall Rule Base Audit
Rule bases reviewed, tightened and documented
Learn moreSophos Firewall
Sophos XGS design, deployment and managed support
Learn moreManaged Security Services
Managed security services (MSS) for US businesses, delivered remotely
Learn moreCloud Migration
Seamless migration to Azure, AWS, or Google Cloud
Learn more