Azure Application Gateway Web Application Firewall becomes difficult to operate when teams treat every blocked request as a reason to disable another rule. The better design is to understand the layers of the WAF policy: managed rules provide broad protection against common web attacks, custom rules express application-specific intent, exclusions narrow inspection only where a known field creates false positives, and rate limiting controls abusive request volumes. Those mechanisms solve different problems and should not be used interchangeably.
This topic matters well beyond a single Azure service. It sits at the intersection of application delivery, network security and cloud architecture, which is why it supports exams such as AZ-104, AZ-305 and AZ-700. Candidates building broader platform knowledge can place it inside the Microsoft Azure infrastructure certification path or the wider cloud architecture certification landscape.
Start with a WAF policy, not a pile of exceptions
A Web Application Firewall inspects HTTP and HTTPS requests for patterns associated with attacks such as SQL injection and cross-site scripting. Application Gateway WAF v2 uses a policy object to organize that behavior. A sound design starts by deciding which applications, listeners or paths the policy should protect and what operating mode is appropriate, then tuning from evidence.
Detection mode is useful during initial rollout because rule matches are logged without turning every match into a production outage. Prevention mode is where the WAF actively blocks according to the policy. The important architectural point is that detection should be a learning stage, not a permanent substitute for enforcement. Teams should analyze what the application legitimately sends, identify false positives and move toward prevention with controlled tuning.
The WAF is not a general-purpose network firewall. It understands web requests and application-layer patterns. That distinction matters when teams confuse it with network firewall controls. Azure Firewall, network security groups and WAF can all be part of the same design, but they inspect different layers and protect against different failure modes.
Managed rules provide the broad security baseline
Managed rule sets are the starting point because they package a large body of attack-detection logic. They are designed to detect common malicious request patterns without requiring each organization to write its own signatures. In Application Gateway WAF, current managed rule sets include the OWASP Core Rule Set family and Microsoft-managed rule sets depending on configuration.
The wrong response to a noisy managed rule is to switch off an entire rule group without understanding why it fired. A false positive usually means that a legitimate request contains data that resembles an attack pattern. The engineering task is to determine which part of the request is causing the match, how broadly that request pattern occurs and whether the application can be changed to avoid the ambiguity.
If tuning is required, prefer the narrowest change that makes legitimate traffic work. Disabling a large rule group expands the attack surface for every protected request. A per-rule exclusion that ignores one known field for one relevant rule can be much safer than turning off inspection of an entire category.
Rule-set version also matters. Features such as modern rate limiting and granular exclusions depend on current WAF engine capabilities. Treat a version upgrade as a controlled change: review release notes, test representative traffic and watch logs before assuming the new behavior is identical to the old policy.
Custom rules express application-specific intent
Managed rules answer the question “Does this request look like a known class of web attack?” Custom rules answer questions that are specific to your environment. You might block traffic from a geography that the application never serves, allow a trusted operational source, reject requests with a particular header pattern, or apply a rate limit to a sensitive endpoint.
Custom rules can match request attributes and then take actions such as allow, block or log. Priority matters because the WAF evaluates custom rules in priority order. A broad allow rule placed above a more precise block can create a bypass, while a broad block placed too early can make later rules irrelevant. Design custom rules as a small, understandable policy rather than an ever-growing list of emergency patches.
Keep business intent visible in rule names and documentation. “BlockBadTraffic01” says little six months later. A rule named for the reason it exists—such as restricting an administrative path to approved source ranges—makes review much easier. Cloud security is operational work, and policy readability becomes a security feature when multiple teams have to maintain the configuration.
Exclusions should be surgical
An exclusion tells the WAF not to inspect a particular request attribute in a specified context. This can be necessary when legitimate data repeatedly triggers a managed rule. For example, an application may send a header or argument containing characters that resemble SQL syntax even though the request is valid.
The key design principle is scope. If one request header causes false positives in one SQL-injection rule, excluding that header from every rule is much broader than necessary. Application Gateway WAF supports per-rule exclusions so teams can narrow the exception to the relevant rule, group or rule set. Global exclusions exist, but they deserve much stronger scrutiny because they remove a field from inspection across the policy.
Every exclusion should have an owner, a reason and a review point. Applications evolve, and the condition that justified an exclusion may disappear after a code change. Permanent, undocumented exclusions are a common way for temporary operational fixes to become long-term security debt.
When a team is preparing for cloud security work, this is a useful example of the general principle of least privilege applied to inspection: exempt only what has to be exempted. The same reasoning appears throughout cybersecurity architecture, even when the product names differ.
Rate limiting protects availability, but it is not exact traffic shaping
Application Gateway WAF v2 can apply rate-limiting rules through custom WAF policy rules. This is useful when an endpoint receives abnormally high traffic, when a misconfigured client floods the service, or when a simple layer of request-volume control can reduce denial-of-service pressure.
Rate limits should not be designed as if the WAF were a precision API quota system. Application Gateway instances maintain their own counters, so a scaled-out gateway can observe different request volumes on different instances. The threshold is therefore a protective control, not a guaranteed tenant-wide transaction counter.
That distinction affects architecture decisions. If a business process requires exact per-customer quotas, put the authoritative limit in the application or an API-management layer designed for that purpose. Use WAF rate limiting to protect availability and reject obviously abusive patterns before they consume deeper application resources.
Threshold selection also requires real traffic data. A number that looks safe during testing can block legitimate bursts during a product launch or batch process. Start from observed request distributions, consider how traffic is grouped, and monitor the effect after enforcement.
Design rule order around explicit security outcomes
A maintainable WAF policy usually has a small number of high-confidence custom rules, a current managed rule set, and narrow exclusions justified by evidence. The order should make the intended outcome easy to reason about. Broad exceptions belong under particular suspicion because they can short-circuit protections that engineers assume are still active.
One useful review technique is to take representative requests—normal user traffic, administrative traffic, known scanner traffic and deliberately malicious test cases—and walk through what each policy layer will do. If the answer depends on tribal knowledge or a rule nobody can explain, the policy has become too complicated.
Logging is part of that design. WAF diagnostics should make it possible to identify which rule fired, what request attribute matched and whether the action was block, allow or log. That evidence supports tuning and incident analysis. It also prevents a common operational mistake: weakening security simply because an application team reports “the firewall blocked something.”
Use WAF with the rest of the Azure security architecture
Application Gateway WAF protects web applications, but a secure workload still needs identity controls, network segmentation, secret management, workload hardening and monitoring. A WAF cannot compensate for an exposed database, excessive permissions or a compromised administrator. It should be one control in a layered design.
For Azure administrators, the topic connects naturally to virtual networks, private endpoints, monitoring and policy. For network engineers, it connects to application delivery and routing. For cloud security engineers, it is one of several controls that must be combined with identity and platform security. That is why the topic appears across AZ-104, AZ-305 and AZ-700 learning paths rather than belonging to one isolated exam.
A good architecture also decides where internet-facing inspection belongs. Some environments use Application Gateway WAF for regional application ingress, Azure Front Door WAF at the global edge, or both for different layers of protection. The correct choice depends on traffic flow, regional design, application requirements and the operational model.
Practical review checklist
- Use a current WAF policy and understand whether it is in detection or prevention mode.
- Keep managed rules as the security baseline rather than disabling large groups to stop false positives.
- Use custom rules for application-specific intent and give them clear priorities.
- Prefer per-rule exclusions over broad global exclusions.
- Use rate limiting for protective throttling, not exact business quotas.
- Review WAF logs before changing policy and keep a documented reason for each exception.
- Test the policy with legitimate, abusive and deliberately malicious requests after significant changes.
The goal is not to produce the largest rule set. It is to create a policy whose behavior can be explained, tested and maintained. When every exception is narrow and every custom rule has a clear purpose, Application Gateway WAF becomes a reliable architectural control rather than a collection of unexplained production fixes.