TNS
VOXPOP
Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
0%
No: TypeScript remains the best language for structuring large enterprise applications.
0%
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
0%
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
0%
I don’t know and I don’t care.
0%
Security

Pros and Cons of Public Cloud WAFs

Consider your use case, your applications' behavior and requirements, and what the future will bring when selecting a web application firewall.
Jul 28th, 2022 8:48am by
Featued image for: Pros and Cons of Public Cloud WAFs
Feature image via Pixabay

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.

Alessandro Fael Garcia
Alessandro is a senior solutions engineer in the NGINX product group at F5. He empowers engineers in their journey to stay ahead of the curve by using the latest NGINX tech offerings. In his free time, Alessandro enjoys traveling (currently on hold), cooking and any and all outdoor exercise.

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.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Pragma.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.