Which four ways of deploying a web application firewall exist, and when does each fit?

• a. On your own infrastructure, on-premises — when part of your own data centre is set up as a DMZ for a public web presence.
• b. On rented cloud infrastructure — when the web servers already run in the cloud, so the WAF belongs there too.
• c. As a cloud service (SaaS WAF) — when you do not want to run the WAF's base operation yourself.
• d. As an integrated part of a cloud solution — the big providers (AWS, Azure, Google) and web-hosting / content-delivery providers build WAF functions into their offerings.

* From top to bottom, you run less of the WAF yourself and depend more on the provider. *

The common logic is put the WAF where the web servers are, and decide how much of it you want to operate. A WAF must sit in the path of the traffic, so a WAF in your own data centre suits servers in your own DMZ, while servers in the cloud are best protected by a WAF in the same cloud. The last two variants hand over the operation: with SaaS you buy filtering as a service, and with an integrated WAF it is simply a feature you switch on in the platform that already hosts your application. Less operation means less effort, but also less control over details such as rule tuning and inspection limits.

Go deeper:

• Software as a service — Wikipedia — what moving the operation to a provider means.
• Content delivery network — Wikipedia — the edge networks that now come with WAF functions built in.