Auto Scaling Web Application Firewalls (WAF) Are Optimized For Cost

There are multiple benefits to leveraging an auto-scaling WAF; today we will discuss the financial benefits. Most, if not all, traditional appliance based WAFs are priced by performance; the more traffic the WAF can handle – the more expensive it is. To deliver the appropriate security and compliance, it is critical that your WAF keep up with traffic at all times. If it cannot, either your WAF will be overrun and stop protecting your web applications or, if it is deployed in industry best practice proxy mode, it will not be able to serve all requests and hence cause severe latency and unavailability. Naturally, these valid concerns cause capacity anxiety. The majority of web based applications experience traffic spikes over a period of time (peaks at certain hours, seasons or specific events like the post Thanksgiving Black Friday sale) so you need to size and buy a WAF that has sufficient power to keep up with traffic at the most busy hour at the most busy day of the year. Outside of these peak hours, your expensive WAF resources are standing idle and not delivering a return on your investment. Now what if you only pay for the capacity you actually use and what if capacity automatically adjusts to increased load? This requirement is a primary driver for applications moving to Cloud based fabrics – to accommodate both capacity on demand and the associated automation of delivering more resources as traffic increases (and subsequently less as it returns to the baseline state). Having this same capability for your WAF would allow you to only pay for the higher WAF performance when you need it and it would also completely take away the capacity anxiety that may cause you to select an even bigger and more expensive WAF to be on the safe side. Deploying Alert Logic’s Web Security Manager (WSM) in Amazon Web Services as an auto scaling WAF gives you exactly that: you pay for the capacity you need and there is no capacity anxiety because the stack is natively integrated with Amazon Auto Scaling. With Auto Scaling, instead of optimizing your WAF capacity for peak performance requirements, you optimize for cost by selecting the Amazon instance that most cost efficiently serves the majority of your traffic. When traffic load surges some more of the same instances are simply spun up to increase performance. So how does it work? How do you determine what instance to run on? The vast majority of web based applications experience traffic patterns that fluctuate based on activity. The simplest example is a consumer e-commerce site that has spikes in usage based on seasonal sales and holidays. If we take a look at the chart below, an obvious observation is that a c1xlarge instance would be overkill since the price is flat over the entire period, which indicates that there is no variation in number of instances because there is excess capacity over the entire year. This is similar to serving the traffic using a fixed capacity non-auto scaling appliance. The variations in t1.micro and c1.medium show that both instance types are auto scaled to adapt to seasonal variations in traffic load with the c1.medium instance as the most cost efficient option since the total cost over the year is the lowest compared to the two other instance types.

The chart shows the relative cost of serving traffic for a consumer e-commerce site that has spikes in usage based on seasonal sales and holidays. Price index is calculated using the AWS t1.micro1 instance as the base. The totals shown below the chart are a summation for the entire year per instance type. For this traffic profile the c1.medium instance would be the most cost efficient choice. Having the auto-scaling capability is great but what happens if your baseline usage changes due to changes in your business? For instance, you add additional web applications to your workload or expand your geographical footprint. In these instances, your baseline usage may change and you may want to adjust your load profile and have your WSM stack on a different instance type to achieve better economies. That’s an easy problem. You simply modify your auto-scaling group to use the new instance type and then you euthanize the workers one at a time. When new workers are spun up automatically they will be running on the new instance type. The operation will not even interrupt availability. ConclusionAlert Logic’s auto-scaling Web Security Manager WAF allows you to scope your hardware resources; thus optimizing for cost based on baseline and expected variations in traffic load rather than having to scope hardware resources for peak capacity requirements. Because WSM is auto scaled to adjust capacity to surges in traffic, you no longer have to worry about peak conditions – and pay for it all year. In addition, auto-scaling provides active/active high availability and instance capacity can easily be adjusted, in flight, without affecting web application availability – critical capabilities to support your mission critical workloads.

  • 1 – The capacity numbers for the t1.micro instance are based on an estimated average of about 0.8 ECU (Elastic Compute Unit) being available. That is a little less than the m1.small. However, since ECUs for the t1.micro are between 0.2 and 2 you may actually be able to serve the load above at an even lower price.
  • From aws.amazon.com: Micro instances (t1.micro) provide a small amount of consistent CPU resources and allow you to increase CPU capacity in short bursts when additional cycles are available. They are well suited for lower throughput applications and websites that require additional compute cycles periodically. Source: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts_micro_instances.html