Azure Firewall Basic vs. Standard vs. Premium: Choose by Traffic, Inspection, and Operations

Azure Firewall has three SKUs, so the first comparison often becomes a price ladder: Basic is cheap, Standard is normal, and Premium is best. That shortcut is attractive and wrong. The SKU determines more than price. It changes which names can be filtered, whether known malicious destinations can be denied, whether encrypted traffic can be inspected, how much traffic the service can process under documented conditions, and how much operational responsibility the team accepts.

The useful question is not:

Which Azure Firewall SKU has the most checkmarks?

It is:

Which traffic must cross a central policy point?
How precisely must that traffic be identified?
How deeply must encrypted and unencrypted traffic be inspected?
What peak and single-flow capacity must be sustained?
Who will operate the policy, certificates, alerts, exceptions, and rollback?

This is the sixth detailed note in the 12-topic Module 1 study plan for Coursera’s Azure Cybersecurity Solutions and Microsoft Defender course. The Module 1 review provides the wider security map. The preceding VNet, subnet, and NSG fundamentals note explained address boundaries and distributed L3/L4 filtering. This article moves to the central inspection point and asks which Azure Firewall capability and performance boundary fits the workload.

These are independent study notes, not a course transcript, assessment answer, production deployment record, or vendor sizing guarantee. Product behavior, performance tables, and documentation conflicts were reviewed against official Microsoft sources on August 11, 2026.

Explicitly out of scope

This article selects a SKU; it does not provide portal, CLI, PowerShell, Bicep, or Terraform deployment steps. Detailed UDR and DNS architecture is reserved for the next note. Rule implementation, structured log queries, and validation commands belong to the following note. A later comparison will examine DDoS Protection, NSGs, Azure Firewall, and WAF together. Exact regional prices, Virtual WAN secured-hub design, third-party NVA feature matrices, and workload-specific compliance interpretation also remain outside this article.

1. The decision this article helps you make

The decision is:

Does this workload need Azure Firewall, and if it does, which minimum SKU satisfies its traffic, inspection, performance, reliability, cost, and operating requirements without depending on an unsafe future migration assumption?

By the end, you should be able to:

explain why deploying a firewall does not automatically route traffic through it;
separate Azure Firewall from an NSG, NAT Gateway, WAF, and network virtual appliance (NVA);
identify the security and management capabilities common to all three SKUs;
describe Basic as a real bounded SKU rather than a toy or a slower Standard;
identify the requirements that move a design from Basic to Standard;
justify Premium with TLS inspection, IDPS, URL-level control, or performance evidence;
distinguish threat-intelligence reputation filtering from signature-based IDPS;
explain why HTTPS full-path inspection creates a certificate and privacy program;
interpret aggregate throughput and a single large flow separately;
model total cost beyond the firewall’s hourly price;
plan SKU migration with policy compatibility and rollback evidence; and
prove that the chosen control actually processes the intended traffic.

The output should be a decision record, not a screenshot of a SKU dropdown:

required traffic and prohibited traffic
+ path and bypass inventory
+ inspection-depth requirement
+ aggregate and single-flow measurements
+ selected SKU and rejected alternatives
+ policy, DNS, PKI, logging, and alert owners
+ cost model and growth trigger
+ positive, negative, performance, and recovery tests
+ migration and rollback plan

2. Start with the control requirement, not the SKU

Do not begin with “Can we afford Premium?” Begin with the connection and the risk.

Requirement field	Question	Useful evidence
Direction	Is the flow outbound, inbound, or workload-to-workload east-west?	Architecture and flow inventory
Source	Which subnet, workload role, private range, or external client initiates it?	Address and ownership record
Destination	Is the target an IP, FQDN, URL path, Azure service, or category?	Dependency inventory
Protocol and port	Is L3/L4 filtering enough, or is application context required?	Application contract
Encryption	Must HTTPS remain end-to-end, or is approved TLS inspection required?	Threat, privacy, and compliance decision
Threat response	Is alerting enough, or must known indicators and signatures be denied?	Detection and response requirement
Aggregate load	What are normal, p95, peak, and event-driven traffic volumes?	Flow and performance metrics
Single flow	Can one backup, replication, or transfer session be very large?	Per-connection test
Availability	Is zonal resilience enough, and what is the regional recovery design?	Reliability target and runbook
Operations	Who owns rules, DNS, certificates, false positives, logs, and incidents?	RACI and on-call plan
Economics	What fixed, variable, telemetry, and labor cost is acceptable?	Cost model and budget

This exercise can produce a legitimate answer of no Azure Firewall. If a small workload needs only subnet-level L3/L4 segmentation, an NSG may be sufficient. If it needs only predictable outbound SNAT and high connection scale, NAT Gateway may fit. If it needs inbound HTTP exploit protection, WAF is the relevant control. Selecting no firewall is responsible when the required control is provided elsewhere and the residual risk is accepted explicitly.

3. Learn four Azure Firewall nouns and one precondition

Several objects are casually called “the firewall,” but they have different jobs.

Concept	Meaning	Beginner mistake
Azure Firewall resource	The managed enforcement service with private and optional public data-path addresses	Assuming its existence changes routes
Firewall Policy	The separate policy resource containing security and operational settings	Treating policy as a screenshot stored inside one firewall
SKU	Basic, Standard, or Premium capability and performance boundary	Treating it only as a billing tier
Rule hierarchy	Rule collection groups, collections, and individual NAT/network/application rules	Assuming every priority is one flat ordered list
Routing precondition	UDR, routing intent, or topology that makes traffic traverse the firewall	Testing a policy while traffic bypasses it

A policy tier and firewall tier must be compatible with the functions being used. A Premium firewall does not gain TLS inspection because the name says Premium; it needs a compatible Premium policy and explicit feature configuration. Conversely, a policy containing Premium-only functions cannot simply be attached to a lower-tier firewall.

The core memory model is:

Route decides whether traffic reaches Azure Firewall.
Policy decides what Azure Firewall does with that traffic.
SKU defines which policy functions and performance ceilings are available.
Evidence proves the real result.

4. Separate Azure Firewall from adjacent controls

This is a boundary summary, not a full product comparison.

Control	Best question	What it does not prove or replace
NSG	May this source/destination/protocol/port flow pass a subnet or NIC boundary?	Central FQDN policy, SNAT, TLS inspection, IDPS, or WAF
NAT Gateway	Which explicit public IP and SNAT capacity should private outbound traffic use?	Destination policy, content inspection, unsolicited inbound publishing, or SIEM-ready firewall decisions
Azure Firewall	Should centrally routed network or application traffic be allowed, denied, translated, logged, or inspected?	Route creation, user identity, secure coding, endpoint protection, or regional DR
WAF	Does an inbound HTTP/S request resemble a web exploit such as SQL injection or XSS?	General TCP/UDP egress, non-web protocols, or subnet segmentation
NVA	Does a vendor-specific virtual appliance meet specialized inspection, SD-WAN, VPN, or policy requirements?	Automatic Azure-managed lifecycle unless the offering explicitly provides it

Azure Firewall and NSGs commonly work together. NSGs keep least-privilege boundaries close to workloads; Azure Firewall centralizes selected traffic across networks. NAT Gateway can also be attached to AzureFirewallSubnet in supported designs to expand outbound SNAT capacity while Azure Firewall continues inspection. More products do not automatically mean more security—the data path, ownership, failure behavior, and cost must remain understandable.

Azure Firewall Premium is also not an inbound web application firewall. Premium TLS inspection is designed for outbound and east-west forward-proxy scenarios. Public HTTP/S applications normally use Azure Application Gateway WAF or Azure Front Door WAF at the inbound edge, sometimes combined with Azure Firewall elsewhere in the path.

5. Trace the common data paths

The three SKUs share the same fundamental requirement: traffic must be sent through the service.

Outbound
Workload subnet
  → UDR or routing intent
  → Azure Firewall private IP
  → policy and optional inspection
  → SNAT path
  → Internet destination

East-west
Source workload
  → symmetric route through Azure Firewall
  → network/application decision
  → destination workload
  → valid return path

Inbound non-HTTP/S publishing
Internet client
  → Azure Firewall public IP
  → DNAT rule
  → private backend

Deploying the resource does not pull traffic toward it. A workload with an Internet route that bypasses Azure Firewall remains uninspected. A route that sends the outbound packet through the firewall but returns through another path can create asymmetric-flow failure. A correct policy on the wrong path is operationally equivalent to no policy for that flow.

The next Module 1 note will implement UDR and DNS design in detail. For this comparison, retain one gate before any SKU discussion:

Can the architecture route the required traffic through this regional firewall and prove that no unintended bypass remains?

6. Understand the processing baseline before comparing SKUs

When enabled, threat-intelligence filtering evaluates known malicious indicators before NAT, network, or application rules. Azure Firewall then processes rule types in this broad order:

Threat intelligence
→ DNAT rules
→ Network rules
→ Application rules
→ Default deny if nothing allows the flow

Rules are terminating: a matching decision stops later evaluation for that flow. DNAT translates inbound traffic and implicitly permits the translated connection, so its source condition must not be an unexplained wildcard. Network rules match L3/L4 attributes and can handle inbound, outbound, or east-west traffic. Application rules provide outbound and east-west application-level controls; they do not act as inbound WAF rules.

The hierarchy also contains rule collection groups and collections with their own priorities, and parent policies can affect local policy evaluation. This is why “my allow rule has priority 100” is incomplete evidence. The complete evidence includes applicable policy inheritance, collection type, route, DNS result, and matching log.

7. Capabilities shared by Basic, Standard, and Premium

Basic is not missing the definition of a firewall. All three SKUs provide a substantial common baseline.

Shared capability	Practical meaning
Stateful firewall	New flows are evaluated using connection attributes; permitted response traffic is tracked
Network rules	Central IP, port, protocol, source, and destination filtering
Application FQDN rules	Application-level destination-name control for supported HTTP/S and SQL scenarios
SNAT and DNAT	Outbound source translation and inbound destination translation
Built-in high availability	Microsoft operates multiple service instances without a customer-managed load balancer
Availability Zone support	A supported regional deployment can be spread across zones
Firewall Policy and Manager	Central policy and multi-firewall management capabilities
Tags	Service tags and FQDN tags reduce hardcoded address maintenance in supported rules
Azure Monitor integration	Logs and metrics can be sent to operational destinations when diagnostics are configured
Automation	REST, CLI, PowerShell, templates, and Terraform can manage the service

Three qualifications matter.

First, integrated logging is not retained logging. The team still configures diagnostic settings, destinations, retention, access, alerts, and cost controls. Second, built-in high availability is not regional disaster recovery. Azure Firewall is regional; multi-region continuity needs another regional design. Third, application FQDN filtering is not full URL inspection. A domain decision such as downloads.example.com is different from a path decision such as downloads.example.com/approved/package.

8. Basic: essential controls inside a firm boundary

Azure Firewall Basic is a candidate when the requirement is small, stable, and explicit—not merely because a lab needs the cheapest checkbox.

What Basic provides

Stateful network rules and application-level FQDN rules.
SNAT and DNAT.
Built-in high availability and Availability Zone support.
Central Firewall Policy, logging, tags, and automation.
Threat-intelligence alert-only signals for known malicious indicators.
A documented throughput ceiling of 250 Mbps.

What Basic does not provide

DNS proxy or custom DNS settings in the firewall.
FQDN destinations in network rules for arbitrary TCP/UDP protocols.
Threat-intelligence Alert and Deny enforcement.
Web-category filtering in the current primary feature matrices.
TLS inspection, managed IDPS, or full-path URL filtering.
Standard or Premium scale ceilings.

Basic therefore fits a controlled workload where application FQDN allowlists, L3/L4 policy, NAT, and central logs are sufficient; measured peak traffic remains comfortably below 250 Mbps; and alert-only threat intelligence has a real monitoring owner. If the team requires non-HTTP FQDN rules, custom DNS alignment, automatic denial of known malicious destinations, web categories, or easy capacity growth, Basic is the wrong functional boundary even when average bandwidth is low.

Basic still has infrastructure overhead

Basic always uses a management NIC. A VNet deployment needs the dedicated AzureFirewallSubnet and AzureFirewallManagementSubnet; current deployment guidance uses at least /26 for each. The management NIC has a separate management public IP used by the Azure platform for updates, health, and service operations, not as a customer ingress address.

That matters for total design. A tiny application can have low traffic while the firewall still needs two reserved subnets, public IP resources, policy, logs, routing, ownership, and monthly fixed deployment cost. “Basic is cheaper” does not mean “Basic is operationally free.”

Write exit triggers before choosing Basic

Move away from Basic if:
- measured peak approaches the 250 Mbps boundary;
- non-HTTP FQDN network rules become required;
- custom DNS or DNS proxy becomes required;
- threat intelligence must block rather than only alert;
- category, TLS, IDPS, or URL-level inspection becomes mandatory; or
- the growth plan makes a constrained Basic migration unacceptable.

9. Standard: the enterprise policy baseline

Standard is often the practical middle tier for a shared regional hub. It retains the common firewall functions and adds capabilities that make central enterprise egress policy easier to operate.

Standard additions

Autoscaling with documented aggregate throughput up to 30 Gbps under published conditions.
FQDN destinations in network rules for supported TCP/UDP traffic.
DNS proxy and custom DNS configuration.
Threat intelligence in Alert and Deny mode.
Web categories based on the FQDN according to the latest SKU-selection matrices.
Forced-tunneling and management-NIC patterns documented for enterprise routing.
Expanded public-IP support for larger SNAT and DNAT designs.

Network-rule FQDN filtering is more than typing a hostname. The firewall must resolve the name consistently with the client. The stable operating pattern is:

Client DNS query
→ Azure Firewall DNS proxy
→ approved upstream Azure or custom DNS
→ firewall and client observe aligned answers
→ network FQDN rule can track the resolved destination

DNS proxy is disabled by default. Enabling it only on Azure Firewall while clients continue using a different resolver can produce timing and IP-answer differences. Detailed DNS design belongs to the next note, but the SKU decision must already assign an owner for it.

Standard’s security boundary

Standard does not provide TLS inspection, managed IDPS, or full URL-path filtering. It can allow updates.example.com and can categorize a site by its domain, but it cannot inspect an encrypted request path such as /approved/releases/agent.msi without terminating TLS. It can deny destinations that match Microsoft’s known malicious indicator feed, but that reputation decision is not signature inspection of arbitrary packet payloads.

Choose Standard when centralized FQDN, DNS, threat-deny, category, NAT, and higher-scale requirements are real, while encrypted-content inspection and IDPS are not approved requirements.

10. Premium: deeper inspection and different responsibilities

Premium includes Standard capabilities and adds advanced inspection and higher published performance boundaries.

Premium additions

Outbound and east-west TLS inspection.
Microsoft-managed signature-based intrusion detection and prevention system (IDPS).
Full URL-path filtering, including HTTPS when TLS inspection is enabled on the application rule.
More granular URL-level web categorization.
Documented aggregate performance up to 100 Gbps in specific configurations.
A much higher single-flow performance boundary in its base configuration.

These features support sensitive workloads that need to detect exploits, command-and-control traffic, malware-related signatures, and prohibited encrypted destinations. Performance can justify Premium only when the intended Premium feature combination—not the base-SKU headline—meets the tested aggregate and single-flow requirement.

Premium is not “turn on every switch.” Each inspection function changes the system:

Feature	New responsibility
TLS inspection	CA design, Key Vault access, client trust, certificate rotation, exceptions, privacy review
IDPS	Mode selection, signature tuning, false-positive handling, incident ownership, capacity testing
URL filtering	Approved path inventory, redirect and embedded-resource testing, exception lifecycle
Advanced categories	Category validation, business exceptions, change requests, privacy boundaries
Higher capacity	Production-shaped load tests, prescaling decision, cost and regional capacity review

A Premium resource with these features disabled behaves differently from a tuned Premium inspection service. The evidence must show which functions are enabled, where they apply, and how the team responds when they block legitimate traffic.

11. TLS inspection is a PKI and privacy program

End-to-end HTTPS normally hides the request payload and full URL path from an intermediate firewall. Azure Firewall Premium TLS inspection creates two protected sessions:

Client
  ⇄ TLS session signed by the organization's inspection CA
Azure Firewall Premium
  ⇄ separate TLS session to the real server
Destination

The firewall decrypts the traffic between those sessions, applies configured inspection, and re-encrypts it. This makes deeper visibility possible, but the organization has intentionally inserted a trusted intermediary into encrypted communication.

The operating requirements include:

a valid intermediate CA certificate stored as a supported Key Vault secret;
a managed identity that can retrieve the secret;
distribution of the trusted root CA to every inspected client or workload;
certificate expiry, rotation, revocation, and emergency replacement procedures;
application testing for certificate pinning, mutual TLS, custom trust stores, and non-browser clients;
explicit exclusions for traffic that must not or cannot be decrypted;
privacy, legal, employee, health, financial, and regulatory review;
protected access to firewall decision logs and incident evidence that may expose sensitive destination URLs and metadata; and
capacity tests with TLS and the intended IDPS mode enabled.

For HTTPS full-URL filtering, TLS inspection must be enabled at the application-rule level. Without it, the firewall can generally see the destination name through supported metadata but cannot read the encrypted path. Do not promise /approved/path control while leaving the tunnel opaque.

TLS inspection also does not turn Azure Firewall into inbound WAF. Microsoft documents outbound and east-west inspection for Azure Firewall Premium; inbound web protection uses a reverse-proxy service such as Application Gateway WAF in the appropriate architecture.

12. Threat intelligence and IDPS answer different questions

The two features are often collapsed into “threat blocking,” but their evidence and limits differ.

Capability	Question	Basic	Standard	Premium
Threat intelligence	Is the IP, FQDN, or URL a known malicious indicator in Microsoft’s feed?	Alert only	Alert or Alert and Deny	Alert or Alert and Deny
IDPS	Does traffic match a managed attack, exploit, malware, or command-and-control signature?	No	No	Yes

Threat intelligence is evaluated before NAT, network, and application rules when enabled. It is reputation-driven and can use allowlist exceptions. It does not prove that an unlisted destination is safe, and it does not inspect every payload as IDPS.

Premium IDPS examines signature patterns in supported inbound, outbound, east-west, and hybrid traffic. Non-encrypted traffic can be inspected across ports and protocols. Encrypted HTTPS payload visibility depends on TLS inspection. Modes include Off, Alert, and Alert and Deny, with signature-level tuning controls.

A sensible rollout is:

Inventory and route the target flows
→ enable IDPS in Alert mode
→ investigate high-confidence and repeated matches
→ tune documented false positives and unavoidable exceptions
→ test capacity with the real feature combination
→ move approved signatures or policy to deny
→ retain rollback and alert ownership

Do not assume global Alert and Deny means every signature drops traffic. Microsoft documents system-defined alert-only behavior and override constraints for some signatures. An IDPS bypass list is not a performance accelerator; it changes inspection coverage and must have a security justification.

13. Distinguish FQDN, category, and full URL decisions

The destination precision increases by SKU and feature.

IP address
→ FQDN: downloads.example.com
→ category: software downloads
→ full URL: https://downloads.example.com/approved/agent.msi

Control	Basic	Standard	Premium
Application-rule FQDN	Yes	Yes	Yes
Network-rule FQDN for broader TCP/UDP use	No	Yes	Yes
DNS proxy and custom DNS	No	Yes	Yes
Web categories	No in current primary matrices	FQDN-level	Full-URL granularity with inspection where required
Full URL path	No	No	Yes; HTTPS requires TLS inspection

FQDN filtering is useful for a named service whose addresses change. It is not an identity guarantee: a domain permission does not authenticate the workload or authorize an application operation. Web categories reduce list maintenance, but categories can change and may need business exceptions. Full URL control is precise, yet modern pages call redirects, APIs, content delivery networks, and embedded resources, so allowing one visible page path may not make the application work.

Premium also has category-specific privacy behavior. Microsoft documents that the Education, Finance, Government, and Health and medicine web categories do not support TLS termination through category rules; approved specific URLs must instead be added explicitly to application rules. Treat that as a reminder that technical visibility is constrained by privacy and compliance, not as a reason to add broad exceptions.

14. Read performance figures as conditions, not promises

The short SKU selector rounds capability into memorable numbers. The detailed Azure Firewall performance page, updated August 4, 2026, publishes more specific maximum test results. The following is a decision aid, not an SLA.

SKU or tested Premium mode	Published aggregate maximum	Published single TCP maximum	Important condition
Basic	Up to 0.25 Gbps	Up to 0.25 Gbps	Fixed capacity; Basic does not autoscale
Standard	30 Gbps	1.5 Gbps	Initial aggregate capacity is much lower than the maximum
Premium, base tested configuration	100 Gbps	9 Gbps	Feature combination and traffic mix matter
Premium with TLS inspection and IDPS `Alert and Deny`	Up to 22 Gbps	Up to 0.6 Gbps	Published combined-feature test; validate the intended traffic mix

The general SKU summary currently lists “fat flow” as 1 Gbps for Standard and 10 Gbps for Premium, while the newer detailed performance benchmark reports 1.5 and 9 Gbps single TCP maxima. For engineering decisions, retain the source date and test against the detailed current performance document rather than treating either pair as guaranteed capacity.

Aggregate throughput is the sum of many flows. A single large flow is one connection, such as a backup or replication stream. A service can have modest aggregate traffic and still fail a single-flow requirement, or have many small connections that exhaust connection and SNAT resources before reaching a bandwidth headline.

Standard and Premium scale out gradually. Microsoft documents a scale-out time of roughly five to seven minutes after utilization thresholds are reached and recommends performance tests that last at least 10 to 15 minutes with new connections. A sudden event does not instantly receive the published maximum. Predictable peaks can justify prescaling, which supports configured capacity-unit ranges for Standard and Premium, adds capacity-unit billing, and still does not guarantee unlimited regional capacity.

The test plan must reproduce:

protocol and packet size;
aggregate and single-flow volumes;
new connections per second and concurrent connections;
TLS inspection and the intended IDPS mode;
number and shape of rules;
SNAT destination concentration;
zone, hub, spoke, peering, and hybrid path; and
at least one scale-out and recovery interval.

15. Use a gated SKU decision tree

Is centralized routing, policy, NAT, logging, or inspection required?
├─ No
│  └─ Select only the needed controls: NSG, NAT Gateway, WAF, or another design
└─ Yes
   │
   ├─ Are peak traffic and growth comfortably within 250 Mbps,
   │  and are network-rule FQDN, DNS proxy/custom DNS,
   │  threat-intel deny, categories, TLS, IDPS, and URL paths unnecessary?
   │  └─ Yes → Basic candidate
   │
   ├─ Is TLS inspection, managed IDPS, full URL filtering,
   │  URL-level categories, more than 30 Gbps aggregate,
   │  or a large single flow required?
   │  └─ Yes → Premium candidate only if the intended inspection mode
   │           validates the actual performance requirement
   │
   └─ Otherwise → Standard candidate for central enterprise policy

Final gate for every candidate:
Can the region, topology, routing, DNS, PKI, budget, operations,
performance test, migration, and rollback requirements be satisfied?

Use the highest mandatory requirement, not the average of preferences. One approved Premium-only requirement makes Premium the minimum even when most flows need only network rules. Conversely, “regulated workload” alone is not a technical requirement. Name the control, traffic scope, evidence, and owner that the regulation or risk assessment requires.

Create a decision matrix with Must, Should, and Not required. A Premium checkmark in a Should row does not override a budget or operational constraint automatically. The decision owner resolves the tradeoff and records residual risk.

16. Scenario A: a small controlled workload selects Basic

Assume a regional internal service has three small subnets and a measured peak of 60 Mbps. Its required central flows are:

outbound HTTPS to a short list of vendor FQDNs;
outbound NTP and DNS by fixed IP and port;
one narrowly sourced DNAT path for a non-web protocol;
central allow/deny logs; and
alerting on known malicious indicators.

It does not require custom DNS in the firewall, network-rule FQDNs, automatic threat-intelligence denial, categories, TLS inspection, or IDPS. Growth planning keeps the p95 and tested peak far below 250 Mbps. The operations team can investigate alert-only threat-intelligence events.

Basic is defensible here. The evidence package should still include:

measured peak and 12-month growth estimate
+ application FQDN and network-flow inventory
+ two /26 firewall subnet reservations
+ management public IP purpose
+ positive and negative connection tests
+ alert destination and response owner
+ Standard migration/rebuild trigger
+ monthly fixed and variable cost

Basic would become a poor choice if “we may need custom DNS next quarter” or “security expects known malicious destinations to be blocked” is already credible. Saving the first month’s SKU difference while creating an uncertain migration is not economy.

17. Scenario B: a multi-spoke service selects Standard

Assume several application spokes use a shared regional hub. Workloads need:

centrally governed Internet egress;
custom DNS and aligned DNS proxy behavior;
FQDN network rules for non-HTTP TCP/UDP dependencies;
threat intelligence in Alert and Deny mode;
FQDN-based web categories;
peaks of several Gbps; and
common policy, logging, and exception ownership across subscriptions.

They do not have an approved requirement to decrypt HTTPS, run managed IDPS, or filter full paths. Public web applications use WAF at their approved edge, while NSGs preserve tier boundaries close to workloads.

Standard is the minimum functional fit:

NSG          → local tier segmentation
WAF          → inbound HTTP/S exploit protection
Standard     → central egress/east-west policy, FQDN, DNS, TI deny, NAT, logs
NAT Gateway  → optional SNAT scale when the measured design needs it

The selection is not complete until the team proves that every spoke’s intended route reaches the firewall, DNS answers remain aligned, direct Internet bypass is closed, and actual capacity remains below the tested boundary during a long enough scale test.

18. Scenario C: a sensitive workload justifies Premium

Assume a payment-processing environment has a risk-approved requirement to:

inspect outbound and selected east-west HTTPS;
detect and block managed exploit and command-and-control signatures;
allow only approved URL paths for a sensitive software supply route;
distinguish categories below the domain level; and
validate a high-volume replication flow under the intended TLS and IDPS mode, recognizing that the published IDPS-prevention single-flow maximum is lower than Standard’s base single-flow maximum.

Premium is justified by named controls, not by the word “payment.” The implementation program includes:

an inspection CA and Key Vault operating model;
root trust deployment to workloads;
certificate-pinning and mutual-TLS discovery;
privacy-approved noninspection categories and exceptions;
IDPS Alert-mode observation before prevention;
full-scale tests with TLS and IDPS enabled;
WAF for inbound public HTTP/S;
NSGs for local segmentation;
structured firewall and IDPS logs with incident ownership; and
a downgrade plan that explains which controls would be lost.

Premium’s documented PCI DSS suitability does not certify the customer’s entire environment. Identity, application, key management, vulnerability remediation, logging, segmentation, evidence, and operating processes still determine compliance.

19. Model total cost, not only SKU price

Azure Firewall pricing varies by region, currency, agreement, and date. Hardcoding a monthly number would age quickly. Use the cost drivers instead.

Estimated monthly cost
= deployment hours × SKU fixed hourly rate
+ processed GB × SKU data-processing rate
+ optional Standard/Premium prescaling capacity-unit hours
+ public IP and NAT Gateway resources where used
+ VNet peering, inter-zone, inter-region, and Internet transfer where applicable
+ Log Analytics ingestion, query, retention, archive, and export
+ Key Vault and certificate operations for TLS inspection
+ engineering, review, false-positive tuning, incident, and recovery labor

The deployment charge continues while the firewall is allocated, even when application traffic is idle, and the pricing FAQ says a partial deployment hour is billed as a full hour. Deallocating the firewall stops its service billing, but other resources have their own meters and the firewall’s private IP can change after allocation, which can affect route dependencies. A production firewall is therefore not normally treated like a desktop VM that someone casually stops overnight.

Centralizing one firewall per region can reduce duplicate firewall instances, but spoke peering and traffic-path charges can offset part of that saving. Basic can lower the firewall meter while increasing operational cost if missing DNS or prevention functions require another service or manual response. Premium can increase direct cost yet reduce a named risk—only if the team actually enables and operates the feature.

Use the Azure pricing calculator before approval and Cost Management after deployment. Compare forecast with actual processed data, telemetry ingestion, and capacity at least monthly during adoption.

20. Design reliability and operations with the SKU

All three SKUs provide built-in high availability and support Availability Zones. As of the verification date, new firewalls in regions with multiple Availability Zones are zone-redundant by default, and Microsoft says existing nonzonal deployments are being migrated during calendar year 2026. A zone-redundant deployment improves resilience to a zonal failure. It does not make existing TCP sessions immortal, guarantee capacity in every zone, or protect against an entire regional outage.

The layers are:

Layer	Responsibility
Instance failure	Managed service replaces unhealthy backend capacity
Zone failure	Zone-redundant regional deployment plus client retry behavior
Region failure	Separately deployed regional firewall, policy availability, routing, DNS, and failover plan
Policy error	Versioned policy, staged deployment, tests, approval, and rollback
DNS failure	Resolver health, aligned client/firewall configuration, monitoring, and recovery
Certificate failure	CA and secret rotation, trust deployment, expiry alert, and bypass decision
Capacity event	Metrics, prescaling or architecture change, SNAT plan, and tested thresholds

Operate Azure Firewall as a security service:

manage policy as code where practical;
give every rule a purpose, owner, review date, and expiry when temporary;
separate global parent policy from workload-specific child decisions carefully;
enable only diagnostic categories that serve a detection, audit, or troubleshooting purpose;
alert on health, missing telemetry, capacity, broad rule changes, and policy failures;
back up policy and test restore or redeployment;
maintain an emergency rollback that does not leave Any access behind; and
review region, SKU, limit, price, and documentation changes on a schedule.

“Fully managed” means Microsoft manages the service infrastructure and scaling behavior. It does not mean Microsoft knows the organization’s required destinations, rotates the customer’s inspection CA, tunes false positives, decides rule exceptions, or answers incidents.

21. Prove path, policy, inspection, and capacity separately

A green deployment is only Layer 0 evidence. Use multiple layers.

Layer 1: path evidence

Export effective routes and confirm the Azure Firewall private IP is the intended next hop.
Test direct-Internet and cross-spoke bypass paths that should be unavailable.
Confirm the return path remains symmetric.
Inventory public IPs and prove which component performs SNAT or DNAT.

Layer 2: policy evidence

Retain the effective Firewall Policy, parent relationship, SKU, and feature settings.
Test one required allow and a nearby prohibited destination, port, FQDN, or path.
Confirm the expected NAT, network, or application rule matches.
Verify default deny rather than assuming no response means firewall denial.

Layer 3: inspection evidence

Confirm the selected SKU’s threat-intelligence mode and alert destination; Basic supports alert only.
For Premium, prove client trust, certificate presentation, TLS-inspection scope, and approved exclusions.
Introduce IDPS in Alert mode, tune documented false positives, and perform approved nonproduction prevention tests.
Confirm HTTPS full-path decisions are tested with TLS inspection actually enabled.

Layer 4: capacity and reliability evidence

Measure normal, p95, peak aggregate, single-flow, new-connection, and concurrent-connection behavior.
For Standard and Premium, run at least a 10–15 minute production-shaped test with new connections so scale-out behavior is visible; test Basic against its fixed 250 Mbps boundary.
Observe health, throughput, latency, processed data, SNAT utilization, and rule-hit telemetry.
Test retry behavior during maintenance or a controlled dependency failure.
Compare actual costs and logs with the forecast.

An Allow log proves a firewall decision, not application health. A successful application request proves connectivity, not necessarily that the intended firewall processed it. Preserve both the route evidence and the matching timestamped firewall evidence.

22. Migrate with compatible policy and rollback evidence

Standard and Premium have a documented easy SKU-change path when the firewall uses Firewall Policy, the region and configuration are supported, and Premium-only settings are handled correctly. Microsoft describes this path as zero downtime, but a production change still needs a maintenance window, full-scale test, monitoring, and rollback.

For a Standard-to-Premium change:

inventory policy, routes, public IPs, diagnostics, DNS, and dependencies;
prepare or generate a compatible Premium policy;
change the SKU through the supported path;
verify ordinary flows before enabling new inspection;
introduce TLS and IDPS in controlled phases; and
retain the prior policy and recovery criteria.

For Premium-to-Standard, first remove or redesign Premium-only requirements. TLS inspection, IDPS prevention, full URL rules, and URL-level category behavior cannot simply remain in a Standard policy. Downgrade is a security-control change, not only a cost change.

Basic does not share the same simple, general zero-downtime change promise. Current Microsoft documentation limits easy SKU change to Standard and Premium and contains conflicting Basic transition wording. A safe plan assumes one of the following until the actual subscription, region, API, and support path are verified:

parallel firewall and policy deployment in a separate VNet or hub
(Azure allows only one firewall per VNet)
→ controlled route cutover
→ public-IP allowlist coordination
→ positive, negative, and performance validation
→ rollback to the prior path

The cutover design must also cover the new hub or VNet peering, public IP dependencies, and symmetric return path. If future Standard or Premium requirements are credible, include migration complexity in today’s Basic total cost.

23. Record time-sensitive conflicts and use a final checklist

Official documentation is usually the best source, but it can be updated asynchronously. As of August 11, 2026, several Microsoft pages do not fully agree.

Topic	Current conflict	Safe design treatment
Basic forced tunneling	The October 2025 feature matrix marks it unavailable; the June 2026 FAQ says Basic supports it; all Basic firewalls use a management NIC	Treat the newer targeted FAQ as a signal, but validate region, API, topology, and support before approval
Basic SKU migration	The change-SKU page limits or rejects some Basic paths, then contains contradictory later wording	Do not promise one-click or zero-downtime Basic migration; test or plan parallel cutover
Web categories	Newer SKU selectors say Standard and Premium with different granularity; a standalone page still describes Premium-only scope	Use the newest SKU selector and verify the portal/API in the target region
Single-flow performance	Summary tables list 1/10 Gbps; the August 2026 detailed performance page reports 1.5/9 Gbps in its tested configurations	Size from the dated detailed test and reproduce the workload
Forced tunneling and DNAT	General limitations and management-NIC exceptions are described differently across the forced-tunnel material	Validate inbound publication as its own topology; do not infer support from one checkbox

This is not a reason to guess. It is a reason to record the document date, test the actual environment, and open a Microsoft support case when a production design depends on the disputed behavior.

Architecture and SKU checklist

Operations and evidence checklist

24. Self-review questions and one-minute memory card

Questions

Why does creating Azure Firewall not automatically inspect a workload’s traffic?
When can an NSG be sufficient without Azure Firewall?
Why should a stable-outbound-IP requirement begin with NAT Gateway evaluation?
Which core capabilities exist in all three Azure Firewall SKUs?
Why is Basic not simply Standard at a lower speed?
Which requirements make Standard the minimum reasonable tier?
Why is threat intelligence different from IDPS?
Why can Premium not inspect an HTTPS full path unless TLS inspection is enabled?
What new trust and privacy responsibilities appear with TLS inspection?
Why does Premium not replace WAF for public inbound HTTP/S?
Why must aggregate throughput and a single large flow be measured separately?
Why is “Premium supports 100 Gbps” not a performance guarantee?
What evidence proves traffic traversed the intended firewall rather than another route?
Why should Basic migration not be promised as a one-click zero-downtime change?
Which costs exist beyond the SKU’s displayed hourly price?

Memory card

Need → Path → Control → Scale → Operate → Prove

Route makes traffic reach the firewall.
Policy decides whether the traffic may pass.
SKU defines available inspection depth and performance ceilings.
Logs and tests prove the result.

Basic
= bounded central firewall, 250 Mbps, threat alerts

Standard
= enterprise DNS/FQDN policy, categories, threat deny, scale

Premium
= TLS inspection, IDPS, full URL control, higher conditional limits

Most features ≠ best fit.
Maximum throughput ≠ guaranteed throughput.
Managed infrastructure ≠ managed security operations.

The final memory line is:

Choose the lowest Azure Firewall SKU that satisfies every mandatory control and tested capacity requirement, then fund the routing, DNS, PKI, logging, and incident work that makes the SKU real.

The next Module 1 detailed note will design Azure Firewall deployment, UDR, and DNS behavior. It remains planned until the complete English and Korean article pair is ready; no empty route is linked.