When clients ask me which cloud has the “best” WAF, they usually expect a simple ranking. In reality, cloud based WAF like AWS WAF, Azure Web Application Firewall and Google Cloud Armor all implement the same basic idea, intercepting HTTP(S) traffic in front of web apps and APIs and filtering known bad patterns such as SQL injection, cross site scripting and other application layer attacks.

The differences show up in how they package rule sets, integrate with their respective platforms and charge for protection.

I will focus on the native WAF services fronting typical web or API workloads, not third party marketplace products.

AWS WAF in practice

AWS WAF sits in front of CloudFront, Application Load Balancer, API Gateway and AWS AppSync. It inspects each request against rules in a Web ACL and then allows, blocks or counts traffic.
You build policies from your own rules and managed rule groups, including AWS Managed Rules which cover common vulnerabilities aligned with industry standards such as the OWASP Top 10.

One practical strength is AWS WAF Bot Control, a managed rule group that classifies and controls automated traffic, from scrapers to search engine crawlers, with simple allow or rate limit actions.
In incident reviews this has been useful when clients suddenly see marketing scrapers or poorly written partner integrations overwhelming an API.

From a cost perspective AWS uses a pay as you go model. You pay per Web ACL, per rule (including managed groups) and per million inspected requests. Current public guidance shows charges per Web ACL per month, per rule per month and around a fraction of a dollar per million requests, with managed rule groups priced per group on top.
This granular model scales nicely for a handful of applications but can surprise finance teams when security teams aggressively add rules during an incident.

Azure Web Application Firewall

Microsoft exposes Azure WAF in two main places: Application Gateway for regional Layer 7 load balancing and Azure Front Door for global edge delivery.
In both, you define a WAF policy that combines managed rules, custom rules and exclusions and you can attach that policy at different scopes, for example globally on a gateway or per listener or path.

The current recommended managed rule set for Application Gateway WAF is the Default Rule Set 2.1, which Microsoft base on the OWASP Core Rule Set 3.3.2 and extend with their own signatures to reduce false positives.
Azure also offers a managed Bot Manager rule set to classify and handle different bot categories when you use Front Door or newer Application Gateway capabilities.

Pricing is more tightly coupled to the underlying delivery product. For Application Gateway WAF, charges depend on gateway size or capacity units plus data processed, with published examples that show per hour gateway pricing and per gigabyte data charges.
Azure Front Door WAF pricing layers on per policy and per WAF request costs as part of the Standard and Premium SKUs, which in turn charge for outbound data and requests at the edge.

In design workshops I often see Azure customers caught between the operational simplicity of a single global WAF policy on Front Door and the cost of Premium tier, especially for low margin, high volume consumer sites. Community discussions frequently highlight that Azure WAF, particularly on Application Gateway v2 and Front Door Premium, can feel expensive relative to AWS and GCP for certain traffic profiles.

Google Cloud Armor

On Google Cloud, Cloud Armor is the main WAF and L7 DDoS protection service. It sits in front of HTTP(S) load balancers and evaluates traffic using security policies that include preconfigured WAF rules, custom rules, IP and geographic filters and rate limiting.

Google offers preconfigured WAF rules built from open source and industry standard signatures that target common categories of web attacks, including those in the OWASP Top 10.
On the Enterprise tier, Cloud Armor adds adaptive protection that uses machine learning to identify and mitigate high volume Layer 7 DDoS patterns specific to your applications.

Pricing for Cloud Armor Standard is again pay as you go: you pay per security policy per month, per rule per month and per million WAF requests, with published figures around a small monthly fee per policy, around one unit per rule and a fractional dollar per million requests.
Managed Protection or Enterprise tiers add a larger monthly commitment that bundles WAF and DDoS features with an allowance of protected resources.

Rule sets, coverage and false positives

All three providers ship managed rules aligned with common web vulnerabilities. AWS Managed Rules and Cloud Armor preconfigured rules aggregate many individual signatures into named packages for quick deployment.
Azure’s Default Rule Set 2.1 starts from OWASP CRS 3.3.2, then modifies signatures and adds Microsoft specific protections based on their threat intelligence.

In lab style independent tests that compare multiple WAF vendors, including the large cloud providers, results show meaningful differences in detection rates and false positives between managed rule sets, even when everyone claims OWASP coverage.

This matches what I see in the field: on some API heavy workloads Azure’s managed rules generate more tuning work, while on others Cloud Armor’s preconfigured rules need more focused exclusions around mobile traffic.

Deployment and tuning: a 2 a.m. story

The sharpest comparison I have came during an incident bridge a few years ago. A retail client had front ends in all three clouds after an acquisition. During a bot driven credential stuffing campaign, the Azure hosted login behind Application Gateway WAF started to fall over first. Custom rules and the managed rule set were all in detection mode, because earlier false positives had made the team nervous about blocking.

On AWS we enabled a stricter managed rule group and Bot Control on the CloudFront distribution, then added a rate based rule per source IP.

The interesting lesson was not that one cloud was magically safer. It was that the operational friction to move from “log only” to carefully “block” differed. Azure’s more complex pricing and association model had led the team to consolidate policies and tolerate more noise, which in turn made them reluctant to flip on blocking when it really mattered.

Observability and operations

All three platforms export WAF logs to their native logging stacks: CloudWatch Logs and Kinesis for AWS, Log Analytics / Sentinel for Azure, and Cloud Logging and BigQuery for GCP.

Tuning always comes down to how quickly you can slice those logs by rule, attack type and source and then push changes through infrastructure as code.

In multicloud environments, I find AWS slightly ahead in terms of consistency between services that sit behind the WAF, since ALB, CloudFront and API Gateway all treat AWS WAF as a first class citizen with similar configuration models.

Azure’s split between Application Gateway and Front Door is powerful but adds architectural decisions to every project, while Cloud Armor’s strengths really appear when you also rely heavily on Google’s global HTTP(S) load balancing and want tight DDoS integration.

Pricing and cost predictability

Broadly:

• AWS WAF has fine grained, consumption based pricing for Web ACLs, rules and requests, which scales smoothly but can explode if you attach many rules across many resources without governance.
• Azure WAF costs are tightly coupled to Application Gateway or Front Door instances, capacity and data, which can make per application costing harder and sometimes more expensive for regional gateways or Front Door Premium.
• Cloud Armor offers a relatively simple pay as you go model for policies, rules and WAF requests, with optional higher tiers that bundle DDoS and curated rules into a fixed monthly subscription.

Recent industry comparisons of cloud security services also highlight that total cost of ownership for native WAF varies widely once you factor in log storage, engineering time for tuning and the need for additional WAAP capabilities such as API specific protection.

How I choose between them

When I sit down with an organisation that already has a primary cloud, I almost always recommend staying native for the initial WAF deployment, provided we commit to automation and structured tuning:

• On AWS first, lean into AWS Managed Rules and Bot Control, export logs to a central analytics platform and treat Web ACLs as code.
• On Azure, decide early whether Front Door or Application Gateway is your main perimeter and standardise WAF policies and rule sets accordingly, keeping a close eye on the bill.
• On GCP, start with Cloud Armor’s preconfigured rules and build towards adaptive protection for public, internet facing APIs.

For organisations that truly span all three clouds, the operational cost of understanding three different rule engines and pricing schemes often justifies a separate WAAP layer. Even then, I still keep the native WAFs in place as a coarse, always on shield in front of the shared edge.