Pros and Cons of Public Cloud WAFs
With cyberattacks rising meteorically each year, every DevOps and development team knows it’s crucial to put a web application firewall (WAF) in front of their applications, services and APIs.
Deploying and managing WAFs used to be the job of the security operations team alone. Then came Kubernetes, microservices, serverless and APIs.
These nascent application and architecture patterns splinter traditional monoliths into thousands, and even tens of thousands, of smaller applications, a significant percentage of which need their own security and WAF. As a result, managing and deploying a WAF has become everyone’s business — from developers to DevOps to DevSecOps — as responsibility for security “shifts left” to empower teams to deploy apps and code iterations faster.
Not all WAFs are alike, however. Price, performance, capability, ease of management and other factors all determine operational complexity and expense. At the most basic level, however, in the cloud-computing era, your choice of a WAF always starts with a simple question: Should I buy the WAF offered by my public cloud vendor or bring my own? There are pros and cons to both sides, and here we will look at public cloud WAFs in depth.
Public Cloud WAF Pros
Public clouds have done a remarkable job of providing WAF solutions that cover 80% of the common use cases. Here are some advantages of buying your cloud vendor’s WAF:
- Ease of deployment — Public cloud vendors make sure it’s easy to deploy their WAFs. They optimize for simple configuration of applications running in their cloud and design the WAF to fit into the existing workflows and tooling they offer. Deploying the WAF is usually very low friction and might be perfect for proofs of concept (POCs) where you don’t care about scale, cost, or future-proofing and reliability.
- Initial cost — The cost of a WAF that protects a small application with only a handful of rules or access control lists (ACLs) is usually minimal — a rounding error, a cup of coffee.
- Integration with other services — Public clouds try to make it very easy to integrate their native WAF with the other services they offer, such as logging tools, DNS management and load balancers or traffic-shaping tools. Easy integration is particularly important if you are running Kubernetes or other container orchestration and automation tools. It also saves time and reduces operational complexity for smaller teams that have many other responsibilities beyond security.
Public Cloud WAF Cons
Unfortunately, the downsides can outweigh the upsides when you rely on a public cloud WAF as your primary security solution, particularly for Kubernetes-driven architectures and modern applications. The downsides include:
- Limited scaling — Public cloud WAFs tend to be “one-size-fits-most” solutions that don’t give you granular control over scaling. For example, you might need your microservices and APIs to scale quickly for a flash sale or game launch, but only in a specific geography. Or you might want to scale the WAF horizontally to match your load-balancing strategies. These sophisticated types of configurations are generally hard to achieve with public cloud WAFs built for vanilla use cases.
- May not handle complex architectures — Closely related to scaling issues are challenges with complex architectures. As examples, public cloud WAFs may struggle or even prove unable to meet the requirements of use cases such as an architecture with thousands of microservices, firewalling against not only north-south but also east-west traffic, and enforcement of significant quality of service (QoS) demands or service-level agreements (SLAs).
- Complex pricing and unpredictable costs — Public cloud WAFs are often priced on multiple parameters, such as number of access control lists (ACLs), number of firewall rules, number of firewall groups, number of regions and number of requests handled. This makes predicting costs extremely complicated and can result in sticker shock when unforeseen events happen, such as a major scaling event or a complex cyberattack.
- Don’t support multi- or hybrid cloud — A WAF in one public cloud obviously cannot protect traffic into another public cloud or your private cloud. With most organizations opting for multicloud or hybrid architectures, this creates significant friction and diseconomies of scale. Your teams have to master the authentication schemes, management consoles and rules syntax that are particular to each cloud’s WAF.
- Lock-in — If you have built out complex rules and groups in one cloud, exporting them or switching to your own firewall when you expand to another cloud is likely to be complicated and time-consuming. Sure, you can manually execute the move, but in a microservices organization, that might mean migrating a large number of firewall rules — and potentially forfeiting a tremendous amount of hard-won institutional knowledge about what rules work under which conditions.
Conclusion: Pick the Right WAF for the Job
Broadly speaking, public cloud WAFs are useful for a good number of use cases. Specifically, they might be great for running simple applications, POCs and simpler architectures. They work well in highly predictable situations where pricing complexity and sticker shock are of less concern. And public cloud WAFs are particularly advantageous if your organization standardizes all operations on one public cloud.
Public cloud WAFs often don’t measure up for larger applications, more complex use cases and evolving application architectures. In particular, the management of public cloud WAFs can quickly become onerous for Kubernetes, microservices and serverless environments where there might be thousands of microservices, and east-west traffic is as much a concern as north-south traffic.
Public clouds may not offer sufficient granularity when a developer or DevOps team needs more control over scaling paradigms and rules (horizontal versus vertical). The management consoles in public clouds automate and simplify management of ACLs and rules, but they generally cannot work across clouds or in hybrid cloud situations unless you run the public cloud’s on-premises solution.
The bottom line? Consider your use case, your applications’ behavior and requirements, and what the future will bring. Switching WAFs mid-course is painful and can affect performance and costs.