Organizations do not all operate their applications in the same manner, so one deployment method cannot realistically work for everyone. Some companies use only a single public cloud, while others divide their computing tasks between several clouds and their own data centers. And an increasing number of businesses also run significant portions of their systems directly on Kubernetes. Web Application and API Protection (WAAP) platforms must support all these different setups, which makes the deployment model an initial consideration rather than something to think about later.
What Are The Main Deployment Models For WAAP
Cloud-based or edge deployment
Cloud-based or edge deployment operates the WAAP as a service managed at the network’s perimeter. This commonly happens using DNS redirection or routing similar to a CDN, checking data before it gets to its source. Setting this up is usually very quick, often becoming active in just a few minutes, because no changes are needed for the application’s existing infrastructure. While it works well for public traffic, it cannot see internal, service-to-service traffic that never goes outside the public network.
On-premises / self-hosted deployment
On-premises / self-hosted deployment means the WAAP runs as a physical device or a virtual appliance inside the organization’s own data center, placed directly before the applications it guards. This setup provides the highest level of control over the infrastructure. It is frequently necessary for businesses with strict rules or compliance requirements about where data must reside, which typically includes financial services and government agencies. The downside is more work for operations staff: the organization takes responsibility for planning capacity, applying updates, and increasing scale, instead of relying on a managed network for these tasks.
Hybrid deployment [i.e., on-prem + Cloud Setting]
Hybrid deployment [i.e., on-prem + Cloud Setting] is usually what most of the large organizations use, i.e., a mix of systems: older ones that cannot be relocated, and new projects built specifically for the cloud. This approach then puts a single, unified policy in place for both, instead of making a company choose one over the other. The main difficulty involves making sure a rule operates identically on both a cloud API and an on-site application,preventing the two sets of rules from slowly diverging.
Kubernetes-native deployment
Kubernetes-native deployment, the most recent and rapidly expanding approach, places itself as a sidecar container or an ingress controller directly within the cluster, instead of only at the network’s edge. A significant portion of actual attack traffic in current systems travels between services within the cluster (east-west), not just from external sources (north-south). An edge-only deployment cannot detect this internal traffic. This method typically uses standard Kubernetes functions, so application code changes are not necessary.
Multi-cloud deployment
Multi-cloud deployment is less a separate strategy and more a requirement that applies to other models. A WAAP system operating across AWS, Azure, and Google Cloud must behave consistently, regardless of which cloud hosts a workload. It cannot rely on vendor-specific rule sets that only function correctly in one environment.
Deployment is a process and not just a one-time placement decision
Deciding where to put the WAAP is only one part of the choice. How you activate it is equally important, and people often overlook this aspect. If a WAAP starts in blocking mode immediately against traffic that has not been analyzed, it usually flags and generates a lot of false positives that teams either relax the rules until they are useless or remove the system from that path entirely.
A more stable approach involves starting in monitoring mode, observing real traffic long enough to learn what typical behavior looks like and making a baseline of it, before turning on enforcement. Even then, it is best to roll it out to a few essential services first, rather than across the entire system all at once. This sequence should be part of the deployment discussion from the beginning, not something to fix after problems appear in production.
There is also an argument for adding protection earlier than at runtime. Policy checks can be integrated into the CI/CD pipeline, so a poorly configured build is identified in staging before it ever reaches production. This does not replace runtime deployment; it simply moves some of the decision-making forward.
It helps to understand where these approaches no longer apply. A WAAP checks traffic moving between clients and servers. It cannot see the code once it has been sent to a mobile application or a browser bundle on a user’s device. That area has its own separate controls, and no deployment method changes that boundary.
How to choose between them
A few questions can quickly help you decide:
- Where does the traffic truly come from? Is it solely the public internet, or are there many internal service-to-service calls that an edge deployment would not see?
- Are there any data residency rules that would immediately prevent using only a cloud/edge model?
- Is the application a traditional single system behind one origin point, or are there many microservices spread across a cluster?
- How much ongoing operational work can the security team realistically handle themselves, compared to what they can pass on to a managed service?
The Key takeaway
There is seldom just one correct way to deploy systems; the best option depends on how data moves and what limitations an organization has. This choice rarely remains constant as technical systems develop. What continues to be useful over time includes:
- A single platform using machine learning for WAF, API, bot, DDoS, and CDN protection. This system should operate consistently across all these models, instead of treating edge, on-premises, hybrid, and Kubernetes environments as distinct products with different rules.
- This consistency allows a deployment to begin small and expand quickly, rather than requiring redesigns every time the underlying infrastructure changes.
- A vendor who can provide quick setup, simple administration, and continuous, local support.
A platform that only performs well with edge deployment becomes a significant problem once traffic moves to Kubernetes or a hybrid setting.
Secure Every Request Before It Reaches You
Discover APIs, block zero-day attacks and bots, and enforce policies at scale without slowing your developers down.
