Firewall, WAF, and WAAP often come up in the same conversation, sometimes as if they meant the same thing. At Azion, the three meet, but each one plays a different role in protecting an application. Firewall is where the rules live. Web Application Firewall (WAF) is one of the modules those rules call. WAAP is the market’s name for the combination of protections that, at Azion, runs inside a single firewall.
In practice, the firewall you attach to an application works rule by rule, in the order you set. It decides when to call WAF, check a Network List, trigger Bot Manager, or apply rate limiting, and each request is recorded in Real-Time Events. In a stack built from separate tools, each tool has its own rules engine and console, and explaining a block means cross-referencing logs from different sources.
Here’s how this architecture works, from rule order to tracing a block.
What’s the difference between Firewall and WAF at Azion?
Firewall is a platform resource, like Applications, Connectors, and Workloads. It works as the policy object you create, name, and reuse. In this post, Firewall with a capital F is the platform resource, and firewall in lowercase is each firewall you create. Each firewall holds Rules Engine rules and the modules those rules can call.
WAF is an Azion product that runs as one of those modules. It inspects the content of HTTP requests at layer 7, which a traditional network firewall, focused on address, port, and protocol, doesn’t analyze. What is a Web Application Firewall (WAF)? covers the concept in more depth. At Azion, WAF scores each request across eight threat families, including SQL injection, XSS, directory traversal, and remote file inclusion. It has no rules engine of its own and only acts when a firewall rule applies the Set WAF behavior.
The other modules follow the same logic. The table sums up what each name means:
| Name | What it is | How it fits into the firewall |
|---|---|---|
| Firewall | Platform resource: the policy object, with rules and modules | Attached to a workload in the deployment |
| WAF | Product that scores requests across eight threat families | Module turned on in the firewall and called by rules with Set WAF |
| Network Shield | Product that matches the client address against Network Lists | Module on by default, used by rules with the network criterion |
| Bot Manager | Product that scores requests with bot detection rules | Runs as a function in the firewall (Functions module), called by rules with Run Function |
| DDoS Protection | Always-on protection, with nothing to configure | Runs before any rule and can’t be turned off |
| Rate limiting, Deny, Drop | Rules Engine behaviors | Available in any firewall, with no module required |
Rate limiting, Deny, and Drop appear as behaviors because they belong to the Rules Engine itself. That’s why an application can limit login attempts per IP even before WAF is turned on.
WAAP (Web Application and API Protection) is the market’s name for the combination of WAF, bot management, API protection, and DDoS mitigation. The video WAAP sem mistério (in Portuguese) explains the concept.
At Azion, that combination is a single firewall policy in front of the application, not a bundle of tools that share a brand. The reference architecture for protecting web applications describes it this way. DDoS Protection acts first. Then a Network Lists rule runs, followed by a rule that calls the WAF rule set and another that calls Bot Manager. Because these steps live in the same firewall, you decide their order, instead of it depending on which tool receives the traffic first. Why a Unified WAAP Platform Reduces SOC Risk shows what that means for operations.
How does a request pass through Azion Firewall?
The path starts at the workload. Its deployment sets which application serves the domain and, optionally, which firewall inspects that traffic. A firewall that no deployment references inspects nothing. Since the binding lives in the deployment, one firewall can protect several workloads without being copied.
When the request reaches an Azion data center, DDoS Protection acts before any rule. Then the firewall evaluates its rules in the configured order. Each rule pairs criteria with behaviors such as Deny, Drop, Set Rate Limit, Set Custom Response, Set WAF, and Run Function. The criteria you can use depend on which modules are on. The request path works in any firewall, the network address requires Network Shield, and the method and headers require WAF. The Rules Engine for Firewall page lists them all.
The first behavior that ends processing decides what happens to the request. Only Set WAF and Run Function let another behavior follow them in the same rule. If no rule blocks the request, it goes on to the application and then to the origin. If a rule blocks it, it never reaches the origin. The page on how Firewall works details this order.
Order also affects operations. When the Network Lists rule comes first, an address you’ve already decided to refuse gets that rule’s response and is never scored by WAF or Bot Manager. That reduces the volume those modules have to process, which is why the reference architecture puts that rule at the top.
Can one WAF rule set cover several applications?
Yes, and that’s one of the practical effects of WAF being a module. The WAF rule set holds the sensitivity per threat family, across five levels, and the exceptions for false positives. The operating mode, Logging or Blocking, belongs to the rule that calls it. So the same rule set can run in Logging on a newly published API and in Blocking on checkout, without duplicating the configuration.
In API v4, the behavior of each of those rules looks like this, with the same waf_id and different modes:
Network Lists work the same way. One list can feed several rules across several firewalls, and a change to the list reaches all of them without anyone editing rule by rule. For both the infrastructure and security teams, that means fewer objects to maintain and a policy that doesn’t need to be copied.
If you prefer to keep the policy alongside the code, you can declare the firewall, the rule set, and the rules in a file and approve the change in code review. The change is then applied at deploy time through the CLI, Terraform, or the API. Bringing application security into the deployment process walks through this flow.
The same model shows up in Azion’s secure MCP server, which coding agents such as Claude Code use to operate the account. Its tools cover the firewall, the rules, the function instances, the WAF rule sets, the exceptions, and the Network Lists. Every write accepts dry_run, which returns the request that would be sent to the API without sending it, so the team can review the change before applying it. The agent that writes your code also suggests your security policy shows an agent proposing these changes.
How do you find which rule blocked a request?
To find which rule blocked a request, start with the block response. The 400 page the client gets when WAF blocks doesn’t say which rule fired, but it carries the x-azion-request-id header. With that ID, you can find the request event in Real-Time Events, in the HTTP Requests data source.
Because WAF, Network Shield, and rate limiting run in the same firewall, the HTTP Requests event holds what they did to the request, and that’s where the investigation starts. What a function such as Bot Manager executed appears in the Functions data source. The Waf Block field shows whether WAF blocked the request. Waf Match lists the violation along with the part of the request that triggered it, and Waf Score shows the score per threat family.
For blocks that didn’t come from WAF, the Stack Trace field lists the rules the request executed. Read it together with the response status: 400 when WAF blocks, 403 for Deny, 429 for rate limiting, and no response at all for Drop. That tells you whether the block came from WAF, a Network List, a rate limit, or a function. WAF, Bot, and DDoS Security: The Case for a Shared Control Plane shows how the delay of cross-referencing consoles across separate tools opens room for coordinated attacks.
With that information, tuning happens in the same place. You can create an exception in the rule set for the rule that caused the false positive, or adjust the sensitivity of the threat family. You can also keep WAF in Logging on the paths still under observation while the rest stay in Blocking. The guide Find the WAF score of a blocked request walks through the steps.
Events are available for 7 days. Data Stream sends Applications and WAF events to SIEMs such as Splunk and IBM QRadar, observability tools such as Datadog, and data warehouses such as BigQuery.
A unified platform starts with the product architecture
Talking about a unified platform is easy when products share a brand, a contract, or a dashboard. The real difference shows up in the path each request takes. At Azion, WAF, Network Shield, Bot Manager, and rate limiting work as steps of a single firewall. They run in the order you set and are recorded in Real-Time Events, with no integration to build later.
That changes the work of two teams. The security team approves a policy once and sees it apply to every application that references that firewall, including the ones still to come. The infrastructure team can explain a block without opening three different consoles.
When protection starts as a single policy, the question stops being which tool blocked the request and becomes whether the rule did what you expected.
Want to see how this works for your applications? Talk to an Azion expert, or create a free account and turn on WAF in Logging mode to see, in Real-Time Events, what it would block in your real traffic.
