We value your privacy

We use cookies to analyse site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Microsoft security
  3. Azure Firewall
Azure Firewall, Dubai and the UAE

Three SKUs, and the gap between them is not gradual. Basic cannot block a known malicious address, only tell you about it.

Azure Firewall Basic supports threat intelligence in alert mode only. Standard adds alert and deny, network level FQDN filtering, web categories and DNS proxy. Premium adds TLS inspection, a managed intrusion detection and prevention system with over 67,000 signatures, and URL filtering on the full path. Choosing between them is the whole design decision.

Book an Azure network security reviewSee the SKU comparison
Azure Firewall design and deployment for UAE organisations
  • 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
What it does

Eight things that determine which SKU you actually need.

Microsoft describes Azure Firewall as a cloud-native, intelligent network firewall security service offering threat protection for Azure cloud workloads, fully stateful, with built-in high availability and unlimited cloud scalability, inspecting both east-west and north-south traffic. The features below are where the three SKUs diverge sharply.

Threat intelligence, and the Basic caveat that matters

Threat intelligence based filtering alerts on traffic to and from known malicious IP addresses and domains sourced from the Microsoft threat intelligence feed. In Standard and Premium it can alert and deny. In Basic, Microsoft states plainly that the feature only provides alerts and cannot deny traffic. An organisation that chose Basic on price is running a firewall that watches known-bad destinations rather than blocking them.

FQDN filtering, in two very different forms

All three SKUs support application level FQDN filtering, based on server name indication, for HTTPS and SQL traffic without TLS termination. Only Standard and Premium support network level FQDN filtering across all ports and protocols using DNS resolution, which is what lets you filter outbound NTP, SSH, RDP and anything else by name rather than by address.

TLS inspection is Premium only, and it is the big one

Premium decrypts outbound traffic, processes it, then re-encrypts and forwards it, creating two TLS connections, one with the web server and one with the client. That covers outbound inspection of traffic from Azure to the internet and east-west inspection of traffic within Azure including to and from on-premises. Without it, most of what is happening inside HTTPS is invisible.

A managed IDPS, with signatures you can tune

Premium provides signature-based intrusion detection and prevention with over 67,000 rules in more than 50 categories, 20 to 40 or more new rules released daily, and support for customising up to 10,000 IDPS rules. Individual signatures can be set to disabled, alert, or alert and deny, and private IP ranges are configured so the system can tell inbound from outbound from east-west traffic.

Web categories, and why Premium categorises differently

Standard and Premium both allow or deny access by web category. The difference is what gets examined. Microsoft published example is instructive: for an HTTPS request to www.google.com/news, Standard examines only the FQDN and categorises it as a search engine, while Premium examines the complete URL and categorises it as news. Full path URL filtering is Premium only and depends on TLS inspection.

Throughput, which is a hard ceiling on Basic

Basic is a fixed scale unit with two virtual machine backend instances, recommended for an estimated throughput of 250 Mbps. Standard autoscales up to 30 Gbps with 1 Gbps fat flow support. Premium reaches 100 Gbps with 10 Gbps fat flow support. Because Basic is a fixed scale unit rather than autoscaling, growth is a migration rather than a setting.

DNS proxy, and the reason it exists

Standard and Premium can act as a DNS proxy, processing and forwarding DNS queries from virtual networks to your chosen server, and can use custom DNS while resolving the firewall own outbound dependencies through Azure DNS. Microsoft states this functionality is crucial for reliable FQDN filtering in network rules, which makes it a dependency rather than a convenience.

Everything shares the same operational floor

All three SKUs include built-in high availability with no extra load balancers to configure, availability zone deployment at no extra cost, source and destination network address translation, full Azure Monitor logging with SIEM integration, central management through Firewall Manager, policy analytics, and automation through REST, PowerShell, CLI, templates and Terraform.

The decision most estates get wrong

Basic is not a smaller Standard. It is missing the thing that blocks.

The three SKUs are not a linear price and performance ladder. Specific security capabilities are simply absent from Basic, and one of them is the reason people deploy a firewall.

  • Threat intelligence based filtering in Basic supports alert mode only. Microsoft states it cannot deny traffic. In Standard and Premium the same feature alerts and denies traffic to and from known malicious IP addresses and domains.
  • Basic also has no network level FQDN filtering across all ports and protocols, no web categories, no DNS proxy and no forced tunnelling, and it is a fixed scale unit with two backend instances rather than an autoscaling service.
  • Microsoft positions Basic for small and medium businesses at an estimated throughput of 250 Mbps, which is a legitimate use case. It stops being legitimate the moment somebody assumes it is doing what Standard does.
  • The failure mode we see is a Basic deployment chosen during a cost exercise, with a security architecture document written against Standard capabilities. Nobody notices until an incident review asks why traffic to a known malicious domain was allowed.
Ask us which SKU your design actually needs
How we approach it

Four things that make an Azure Firewall deployment worth what it costs.

This is a managed service, so the platform work is genuinely small. The value is entirely in choosing the right SKU for the requirement and writing a rule base that somebody can still understand in three years.

We size the SKU against the requirement, not the budget line

If the security design says block traffic to known malicious destinations, Basic cannot deliver it and no amount of configuration will change that. If it says inspect inside HTTPS, only Premium can. Writing the capability requirement first and choosing the SKU second avoids the deployment that satisfies a procurement decision and not the architecture.

We get DNS right before relying on FQDN rules

Network level FQDN filtering resolves names to addresses, so it is only as reliable as the resolution behind it. Microsoft states DNS proxy functionality is crucial for reliable FQDN filtering in network rules, and that is a dependency to design deliberately rather than discover when a rule intermittently fails for reasons nobody can reproduce.

We tune IDPS rather than switching it on and walking away

Premium ships over 67,000 signatures across more than 50 categories with 20 to 40 or more added daily, supports customising up to 10,000 rules, and lets each signature be set to disabled, alert, or alert and deny. Configuring private IP ranges so the system can distinguish inbound, outbound and east-west traffic is what makes that tuning meaningful.

We use policy analytics to prune, not just to add

Rule bases only ever grow, because adding a rule solves today problem and removing one risks breaking something nobody remembers. Policy analytics shows rule usage over time, which turns pruning from a guess into an evidence-based exercise. That is the single most useful recurring activity on a firewall estate.

Where this fits

Six UAE situations where the Azure-native firewall is the right choice.

Azure Firewall inspects both east-west and north-south traffic, is fully managed, and is centrally administered through Firewall Manager across subscriptions. Those three properties decide most of the cases below.

A hub and spoke landing zone across several subscriptions

Firewall Manager provides a central place to manage Azure Firewalls across multiple subscriptions, applying a common set of network and application rules through firewall policies, and supports both virtual network and Virtual WAN secure hub environments. For a landing zone with per-workload subscriptions, that is the difference between one policy set and a dozen drifting ones.

A regulated firm that needs to inspect encrypted outbound traffic

Premium TLS inspection terminates and inspects TLS connections to detect, alert and mitigate malicious activity inside HTTPS, creating two connections, one with the server and one with the client. Where an obligation requires visibility of what leaves the environment, that capability is not optional and it is Premium only.

A business that needs URL rather than domain control

The published example makes the difference concrete. For an HTTPS request to a news path on a search engine domain, Standard sees only the domain and categorises it as a search engine, while Premium examines the full URL and categorises it as news. Where policy is written at path level rather than domain level, that gap decides the SKU.

An operator routing cloud traffic back through on-premises

Forced tunnelling, available on Standard and Premium, routes all internet-bound traffic to a designated next hop instead of directly to the internet, so an existing on-premises edge firewall or network virtual appliance can process it first. Deployment without a public IP address in forced tunnel mode is supported on the same SKUs.

An organisation replacing a self-managed virtual appliance

A firewall appliance running as a virtual machine in Azure carries patching, sizing, licensing and availability design that somebody has to own. Azure Firewall has built-in high availability with no extra load balancers required, availability zone support at no extra cost, and autoscaling on Standard and Premium, which removes most of that operational surface.

A small environment where Basic genuinely is the right answer

Microsoft positions Basic for small and medium businesses, at an estimated throughput of 250 Mbps, with a fixed scale unit of two backend instances. That is a legitimate choice for a small footprint, provided the security design is written against what Basic actually does rather than what Standard does, and provided the growth path is understood as a migration.

Three positions

How UAE organisations secure Azure network traffic.

The middle column is common in estates that lifted and shifted. Network security groups do useful work at layer four and stop well short of what the traffic actually needs.
Stateful layer three and four filtering
Azure Firewall, right SKUYes
Network security groups onlyYes
A virtual appliance nobody managesYes
Filtering by fully qualified domain name
Azure Firewall, right SKUYes
Network security groups onlyNo
A virtual appliance nobody managesVaries
Known malicious destinations blocked
Azure Firewall, right SKUYes, Standard and above
Network security groups onlyNo
A virtual appliance nobody managesVaries
Web category control
Azure Firewall, right SKUYes, Standard and above
Network security groups onlyNo
A virtual appliance nobody managesVaries
Inspection inside TLS
Azure Firewall, right SKUYes, Premium
Network security groups onlyNo
A virtual appliance nobody managesVaries
Intrusion detection and prevention
Azure Firewall, right SKUYes, Premium
Network security groups onlyNo
A virtual appliance nobody managesVaries
High availability without extra design
Azure Firewall, right SKUYes
Network security groups onlyNot applicable
A virtual appliance nobody managesNo
Scales with traffic automatically
Azure Firewall, right SKUYes, Standard and above
Network security groups onlyNot applicable
A virtual appliance nobody managesNo
Central policy across subscriptions
Azure Firewall, right SKUYes
Network security groups onlyNo
A virtual appliance nobody managesNo
Patching and lifecycle burden
Azure Firewall, right SKUNone
Network security groups onlyNone
A virtual appliance nobody managesYours
Feature
Azure Firewall, right SKU
Network security groups only
A virtual appliance nobody manages
Stateful layer three and four filtering
YesYesYes
Filtering by fully qualified domain name
YesNoVaries
Known malicious destinations blocked
Yes, Standard and aboveNoVaries
Web category control
Yes, Standard and aboveNoVaries
Inspection inside TLS
Yes, PremiumNoVaries
Intrusion detection and prevention
Yes, PremiumNoVaries
High availability without extra design
YesNot applicableNo
Scales with traffic automatically
Yes, Standard and aboveNot applicableNo
Central policy across subscriptions
YesNoNo
Patching and lifecycle burden
NoneNoneYours
The SKU comparison

Sixteen capabilities across Basic, Standard and Premium.

Reproduced from the published feature comparison table. The pattern to notice is that the security-defining features cluster in the lower half.
CapabilityBasicStandardPremium
Stateful firewall with five-tuple rulesYesYesYes
Source and destination network address translationYesYesYes
Built-in high availabilityYesYesYes
Availability zonesYesYesYes
Application level FQDN filtering, SNI basedYesYesYes
Network level FQDN filtering, all ports and protocolsNoYesYes
Web content filtering by web categoriesNoYesYes
URL filtering on the full path, with SSL terminationNoNoYes
Outbound TLS termination, forward proxyNoNoYes
Threat intelligence based filteringAlert onlyAlert and denyAlert and deny
Fully managed intrusion detection and preventionNoNoYes
DNS proxy and custom DNSNoYesYes
Cloud scalabilityUp to 250 MbpsUp to 30 GbpsUp to 100 Gbps
Fat flow supportNot applicable1 Gbps10 Gbps
Multiple public IP addressesSupportedUp to 250Up to 250
Forced tunnellingNoYesYes
How an engagement runs

Five steps, and the rule base is the part that outlives the project.

Typically four to eight weeks. Deployment is quick because the service is managed. Working out what should be allowed, and writing it in a way that is still maintainable later, is where the effort goes.
  1. 1

    Establish the capability requirement, then the SKU

    Whether known malicious destinations must be blocked rather than merely alerted on, whether traffic inside TLS must be inspected, whether intrusion detection and prevention is required, whether policy is written at URL or domain level, and what throughput is realistic. The SKU falls out of those answers rather than driving them.

  2. 2

    Design the topology and the routing

    Hub and spoke or Virtual WAN secure hub, availability zone placement, public IP requirements, and whether forced tunnelling is needed to send internet-bound traffic through an existing on-premises edge. East-west inspection only happens for traffic that is actually routed through the firewall, so routing design is security design here.

  3. 3

    Build the policy with tags rather than addresses

    Service tags representing groups of address prefixes that Microsoft maintains and updates automatically, and FQDN tags for well-known Azure service traffic such as Windows Update. Both dramatically reduce the number of rules a human has to maintain, and both keep working when Microsoft address ranges change.

  4. 4

    Tune threat protection to the environment

    On Premium, private IP ranges configured so the IDPS can distinguish inbound, outbound and east-west traffic, then signature tuning by category with individual rules set to disabled, alert, or alert and deny. On Standard, threat intelligence moved from alert to deny once the traffic has been observed and the false positive risk understood.

  5. 5

    Wire logging and establish a pruning rhythm

    Full logging into Azure Monitor with SIEM integration, the Azure Firewall workbook for analysis, and a scheduled review using policy analytics to find rules that no longer match anything. Rule bases grow indefinitely without that last step, and an unmaintained rule base eventually stops representing anybody intent.

Straight answers

What organisations ask about Azure Firewall.

It follows from four questions. Do you need to block traffic to known malicious addresses, not just alert on it, which rules out Basic. Do you need to inspect inside TLS, which means Premium. Do you need signature-based intrusion detection and prevention, which also means Premium. And what throughput do you need, given Basic is capped at 250 Mbps, Standard reaches 30 Gbps and Premium reaches 100 Gbps.

Microsoft lists the limitations directly: threat intelligence is alert mode only and cannot deny traffic, throughput is limited to 250 Mbps, DNS proxy is not available so it uses Azure DNS only, network level FQDN filtering is not supported so only application FQDN filtering works, web categories are not supported, and forced tunnelling is not supported. It is also a fixed scale unit with two backend instances rather than autoscaling.

No, they work at different levels and most designs use both. Network security groups filter at layer three and four close to the resource. Azure Firewall is a stateful, centrally managed service that adds filtering by fully qualified domain name, threat intelligence, web categories and, on Premium, TLS inspection and intrusion prevention. The firewall gives you policy, the groups give you segmentation.

No, and Microsoft treats them as separate services in the same network security category, alongside Azure DDoS Protection. Azure Firewall protects outbound and internal traffic and inbound traffic through destination network address translation. Protecting a public web application against application layer attacks is what Azure Web Application Firewall is for, and inbound TLS termination is listed as being handled through Azure Application Gateway.

On Premium, it decrypts outbound traffic, processes it, then re-encrypts and sends it to the destination, creating two TLS connections, one with the web server and one with the client. That enables outbound inspection of traffic from internal clients in Azure to the internet, and east-west inspection of traffic within Azure including to and from on-premises. It also underpins full path URL filtering.

Premium provides signature-based IDPS with over 67,000 rules in more than 50 categories, 20 to 40 or more new rules released daily, and support for customising up to 10,000 rules. Signatures can individually be set to disabled, alert, or alert and deny. Configuring private IP ranges lets it determine whether traffic is inbound, outbound or east-west, which materially improves the accuracy of the decisions.

Because network level FQDN filtering depends on DNS resolution. Microsoft states DNS proxy functionality is crucial for reliable FQDN filtering in network rules, since the firewall must resolve the same names the client resolves. Standard and Premium support DNS proxy and custom DNS, where the firewall uses your DNS server while still resolving its own outbound dependencies through Azure DNS. Basic supports neither.

The published example is the clearest explanation. For an HTTPS request to www.google.com/news, Firewall Standard examines only the FQDN part, so www.google.com is categorised as a search engine. Firewall Premium examines the complete URL, so www.google.com/news is categorised as news. Premium also offers a web category check feature to identify how a specific FQDN or URL is categorised, and a route to request category changes.

Yes, on all three SKUs. Microsoft states high availability is built in, so no extra load balancers are required and there is nothing to configure. Availability zone deployment is supported on all SKUs for increased availability, at no extra cost, and the firewall can also be associated with a specific zone for proximity reasons where that matters more than spread.

Azure Firewall Manager, which provides a central place to manage Azure Firewalls across multiple subscriptions and uses firewall policies to apply a common set of network and application rules and configurations across your tenant. It supports firewalls in both virtual network and Virtual WAN secure hub environments, with the secure hub option using Virtual WAN route automation to simplify routing traffic to the firewall.

Two things. Service tags, which represent a group of IP address prefixes that Microsoft manages and updates automatically as addresses change, and FQDN tags, which allow well-known Azure service traffic such as Windows Update through with a single rule. Then policy analytics, which shows rule management over time and gives you evidence for removing rules rather than a guess.

Yes, through forced tunnelling on Standard and Premium. Microsoft describes configuring the firewall to route all internet-bound traffic to a designated next hop instead of going directly to the internet, so an on-premises edge firewall or other network virtual appliance can process it first. Deployment without a public IP address in forced tunnel mode is supported, using a separate management network interface.

Microsoft states all SKUs are Payment Card Industry, Service Organization Controls and International Organization for Standardization compliant. PCI DSS compliance specifically is listed for the Premium SKU, which Microsoft positions for highly sensitive and regulated environments such as payment and healthcare. Whether that satisfies your particular obligation is a question we would work through against the obligation itself.

All SKUs support DevOps integration through REST, PowerShell, the Azure CLI, templates and Terraform. In practice the firewall policy is the artefact worth putting under version control, because rule changes are the changes most likely to cause an outage and the ones most likely to be made under time pressure without a record.

We scope per environment, driven by the SKU, the number of virtual networks and subscriptions, whether TLS inspection and IDPS tuning are in scope, and whether you want the rule base migrated from an existing appliance. The service itself is billed by Microsoft on its own published terms, which we size with you rather than estimating here.
Before you deploy

Fifteen questions that decide the design.

The first group sizes the SKU, the second designs the policy, and the third is the operational half that determines whether the firewall stays useful after the migration project ends.

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 tunnelling?
    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 customised.
Related reading

The pages around this one.

Azure security audit

The assessment that usually identifies whether the current network design holds up.

Learn more

Defender for Cloud

Posture management for the workloads sitting behind the firewall.

Learn more

Network monitoring

The operational layer that watches whether any of it is still working.

Learn more
Next step

Check whether your firewall can block a known malicious address, or only tell you about it.

That is a SKU fact rather than a configuration one, and it is a question most organisations have never asked. It takes a minute to answer and it occasionally changes the whole security architecture conversation.

Book an Azure network security reviewCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

Azure Security Audit

Subscription audit, starting with the free tier you already own

Learn more

Defender for Cloud

Azure posture, and the free tier almost nobody has enabled

Learn more

Network Monitoring NOC

24/7 NOC monitoring with named engineers

Learn more

Azure Cloud Solutions

Azure landing zone, migration, FinOps, managed

Learn more

Azure Key Vault

Secrets, keys and certificates out of config files

Learn more

Fortinet FortiGate Dubai

Sizing, deployment and managed firewall lifecycle

Learn more

Microsoft Security Dubai

Entra, Defender, Purview, Sentinel, and what you already own

Learn more

Entra Global Secure Access

Internet Access, Private Access and tenant restrictions

Learn more
GR IT SERVICES

Leading IT services provider in Dubai,
delivering enterprise-grade solutions
for businesses across the UAE.

Microsoft CSP PartnerCISGuard

Get the Helpdesk app

Raise and track IT tickets from your phone.

Download on the App StoreGet it on Google Play
Learn more about the app

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support Dubai
  • IT AMC Dubai
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • Iris Bay Tower, Office 903,
    Business Bay, Dubai, UAE
  • +971 56 613 2743
  • hello@gritservices.ae
  • gritservices.ae

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie Policy