Retiring a US$43,000 WAF contract with a shared AWS platform

An oil and gas company retired its full Imperva service after moving application protection onto a shared AWS platform. The commercial result was the removal of a US$43,266 annual contract expense and an avoided renewal. The engineering result was a repeatable way to publish and protect applications across AWS accounts.

For engineers, onboarding became a small configuration change: declare the application’s public hostname, backend destinations and health check. An Azure DevOps pipeline turns that declaration into certificates, load-balancer routing and a CloudFront distribution. DNS ownership and central security policy remain in their respective accounts.

That combination matters. A security migration can reduce a supplier bill while creating a new queue of manual work. Here, the architecture and delivery process were designed together so the organisation could operate the replacement as a platform.

Share the foundation across applications

The replacement uses CloudFront as the public entry point, private shared Application Load Balancers in the DMZ accounts, and AWS WAF policies managed from a central security account. Host-based routing directs each application to its own target group and backend destinations.

Applications reuse the load-balancer and security foundation while retaining a separate CloudFront distribution and application configuration. This avoids rebuilding the same infrastructure for every new site.

The account design also preserves operational responsibilities:

• DMZ accounts contain the application entry infrastructure, with separate production and nonproduction environments.
• The DNS account owns the public hosted zone and delegates the required record-management access.
• The security account manages the shared WAF policy through AWS Firewall Manager.

Application onboarding therefore fits into an established boundary. Engineers can request a route without taking ownership of the organisation’s DNS zone or redefining its central security baseline.

Avoid paying for an idle load balancer at every origin

The application estate had many origins, but modest traffic per application. Across May–August 2026, its production CloudFront distributions received approximately 115 million requests—about 10.8 requests per second combined. Fourteen of the sixteen production distributions averaged fewer than one request per second over that period. These are HTTP requests, including automated traffic, rather than a count of people using the applications.

That traffic profile matters commercially. An ALB carries an hourly charge even when an application receives very few requests. Giving every quiet origin its own ALB repeats that standing cost without making useful use of the additional infrastructure.

By October 2026, the platform served 21 application distributions through four shared ALBs, split by environment and region. A dedicated-ALB alternative for the same application inventory would require 21 load balancers. Using current Sydney and Oregon prices and a 730-hour month, the ALB hourly charges would be approximately US$373/month dedicated versus US$70/month shared.

Zoom outZoom inReset100%Close

The cost of keeping the load balancers running, before traffic-based charges. The shared design retains separate production and nonproduction pools in each region.

That is an 81% reduction in the modelled ALB hourly-charge component, or approximately US$3,635 a year. Sharing helps keep the replacement platform’s ongoing AWS cost low. Capacity-unit charges, CloudFront, WAF, logging and other operating costs still apply. The rates come from AWS’s Elastic Load Balancing pricing, checked on 8 October 2026.

The design shares infrastructure within the appropriate account, environment and region. Each application keeps its own hostname, target group and backend destinations. A high-volume application, an incompatible security requirement or a need for an independent change boundary can justify a dedicated ALB. For a long tail of quiet applications, paying the standing charge once per pool is a better starting point.

Average traffic is only part of that decision. The busiest production hour in the same four-month window averaged about 391 requests per second across the distributions. Short bursts can be higher. Capacity planning therefore includes peaks, request sizes, connections and backend performance, alongside the lower everyday load.

Give engineers a small interface to a complete deployment

The engineer-facing interface is a YAML file. A site entry describes the intent; the infrastructure templates and pipeline supply the implementation.

The pipeline generates the required parameters, deploys regional certificates and the private load-balancer configuration, then creates the per-application CloudFront resources. It also handles cache invalidation and cleanup of superseded certificates and removed-site resources.

The operational value is the removal of repeated handoffs between separate console tasks. A new application’s certificate, route, distribution and DNS integration are connected in one delivery process. Engineers review the proposed configuration in version control, and operators have the deployment result to inspect.

The central WAF policy has its own deployment pipeline and owner. That allows application onboarding and security-policy changes to follow their respective review paths while working together in the deployed system.

Make the commercial comparison useful

The retired Imperva Marketplace agreement cost US$43,266.43 for one year. It covered the full service and expired in July 2026. With Imperva turned off, the organisation avoided renewing that annual contract.

Across May–August 2026, five selected AWS services in the associated accounts—AWS WAF, Firewall Manager, CloudFront, Elastic Load Balancing and Secrets Manager—billed US$1,948.50 in total. That averages about US$487 per month, or roughly US$5,846 a year at the same run rate.

Zoom outZoom inReset100%Close

The retired annual contract and the observed run rate for five AWS services. These figures have different cost scopes.

The difference is approximately US$37,421 a year before other AWS costs, migration effort and ongoing operations. The AWS figure is an account-level service basket: some shared charges can sit inside it, while services such as log storage and AWS Config sit outside it. A full investment decision also includes the people needed to maintain the platform.

These numbers give a useful starting point for the commercial decision. The annual supplier expense has gone; the replacement has a much smaller observed service-cost basket. The organisation now needs to manage its own operating cost, capacity and security responsibilities explicitly.

For another organisation, the opportunity will depend on its contract, application mix, traffic and support requirements. AWS WAF pricing includes usage-based charges, and the surrounding delivery services have their own costs. Model the complete service you intend to operate.

Use a migration sequence that protects the applications

The rollout progressed from policy development in October 2025 to COUNT-mode observation in November, then blocking in December. Application cutovers began in February 2026, ahead of the July contract expiry.

That sequence gave the team time to examine legitimate application behaviour and tune compatibility before relying on enforcement. A rule that blocks a required business transaction creates an operational problem, even when the rule is behaving as configured.

Infrastructure deployment and live traffic cutover were deliberately separated for existing domains. The pipeline builds the replacement route while leaving an existing DNS target in place. An operator then cuts over one domain at a time, with the previous value saved, a check for unexpected changes and a rollback path.

This made the migration manageable at application level. The team could investigate a problem or reverse a cutover without making every application part of the same release decision.

Decide what your team is ready to own

A shared platform concentrates some responsibilities. A change to a shared load balancer or WAF policy can affect several applications, so it needs review, appropriate testing and an owner who understands those dependencies.

The operating model needs named responsibility for rule tuning, logs, failed deployments, certificate changes, capacity and application exceptions. It also needs a clear path for an application team to explain a legitimate request that the WAF rejects.

Those responsibilities belong in the commercial comparison. The replacement removed the external service and its renewal; it also put more of the architecture and operating decisions directly under the organisation’s control.

Start with one workload and its dependencies

The broader lesson is to connect security architecture with the way engineers deliver change. A small configuration interface is valuable when it sits on top of explicit account boundaries, repeatable infrastructure and a controlled route into production.

An AWS Workload Foundations Assessment examines those decisions for one workload: its exposure, dependencies, identity and network boundaries, deployment process, operating ownership and cost baseline. It gives you a practical migration or improvement plan before you commit to replacing a service.

For the implementation, read the technical companion on shared ALBs, cross-account Route 53 and Azure DevOps.