Cost-effective ways for securing your web applications using AWS WAF

AWS WAF helps you protect against common web exploits and bots that can affect availability, compromise security, or consume excessive resources. Configuring AWS WAF in a cost-effective way has been a frequent topic of discussion among our customers. In this post, learn how to use the different components of AWS WAF to secure your web applications in a cost-effective way.

AWS WAF pricing model

AWS WAF does not have any upfront commitments and is charged for each web ACL and each rule that you create. In addition, you are charged for the number of web requests processed by the web access control list (ACL). AWS WAF has additional pricing if you use intelligent threat detection (such as AWS WAF Bot Control; AWS WAF Fraud Control; CAPTCHA; Challenges).

Challenge and CAPTCHA actions for Targeted Bot Control and AWS WAF Fraud Control are free of cost. When the CAPTCHA and Challenge actions are associated with the Common Bot Control managed rule group or custom rule groups, there is an associated cost to it. The challenge and CAPTCHA attempts are not visible in AWS WAF logs, which makes it difficult to estimate costs associated with it. The cost for CAPTCHA is determined by the number of attempts made, regardless of whether it is used through the JS API or as a rule action. However, for Challenge you are charged based on the number of challenge responses served by the rule action. Currently, the Challenge JS SDK is free of cost, but it is subject to change.

The pricing for AWS WAF is consistent across all AWS Regions. Monthly fees are prorated on an hourly basis. For pricing examples and additional AWS Marketplace charges, please refer to AWS WAF pricing.

In this post we categorized the AWS WAF configuration into three sections: base configuration, intelligent threat mitigation, and logging.

Base configuration

To configure AWS WAF cost effectively, note that AWS WAF evaluates your rule set from top-to-bottom, following the ascending order of the rules’ priority values. The evaluation process considers terminating and non-terminating rule actions, determining whether to halt or continue processing the rule set accordingly.

• Allow and Block are terminating actions – Allow and Block actions stop all other processing of the web ACL on the matching web request.
• Count is a non-terminating action – When a rule with a Count action matches a request, AWS WAF counts the request, then continues processing the rules that follow in the web ACL rule set.
• CAPTCHA and Challenge – When a rule with the CAPTCHA or Challenge action matches a request, AWS WAF inspects aws-waf-token status. If the request has a valid token, then AWS WAF treats the match as a Count match and proceeds to process the subsequent rules in the web ACL rule set. However, if the aws-waf-token was found to be expired, invalid or absent, clients are presented with a CAPTCHA or Challenge attempt.

For additional information, refer to Web ACL rule and rule group evaluation , Processing order of rules and rule groups in a web ACL and CAPTCHA and Challenge action behavior.

Known good and bad traffic

Now that you understand the evaluation logic, you can start building the AWS WAF rule set. It’s a good idea to start with an Allow and Block list as the first two rules. This makes sure that you let known good traffic through and block known malicious sources without any additional processing.

Examples of entries in an Allow list would be of automated systems inside your trust domain, like a continuous integration/continuous deployment (CI/CD) system, a monitoring solution, archiving solution, etc. The Allow rules could include trusted IP ranges, trusted HTTP headers like user-agents, etc.

Figure 1: AWS WAF allowed rule statement to allow requests from specific IP address

You can populate the block list with known malicious traffic based on past observations. This knowledge can be derived from other web applications or kept empty and utilized during ongoing events as needed.

Figure 2: AWS WAF rule set blocking requests originating from a specific country and IP addresses

Depending on the kind of web application you are protecting and where your users are located, you may want to block, enrich the request with additional information through labels, or challenge, based on the AWS Managed Rule groups for IP reputation. This rule groups can also help reduce the amount of requests that are processed by rules further down the rule set.

Flow control

Use the free AWS Managed Rule set after Allow or block rules. This helps to Block malicious traffic prior to additional rule evaluations down the processing order.

Figure 3: AWS WAF free AWS Managed Rule groups

Some customers like to follow the Allow/Block list rules or the free managed ruleset with a Blanket Rate Based Rule. The idea behind this is to protect your resource from getting a sudden spike of requests. Rate based rules are an effective way to protect your web application from DDoS attacks, or even from unexpected traffic influxes. By default, rate-based rules aggregate requests by source IP. However, you can customize the aggregation key based on parameters like header, query string, query argument, cookie, label namespace, HTTP method, and URI path.

You can use rate-based rules to protect different parts of your web application, which by design consumes more compute capacity. For example, you can rate limit requests based on aws-waf-token cookie and URI by creating a rule before intelligent threat detection ruleset. These rate-based rules can protect you from incurring in additional WAF costs from rules further down the rule set.

Figure 4: AWS WAF rate-based rule limiting requests to login page based on user-agent and IP addresses

Apply WebACLs per content type

Build rule sets with rules that apply to your web application. Start by identifying the underlying technologies and build from there. For example, if your web application is written in Java, then don’t need to protect it from common PHP vulnerabilities. If your Amazon CloudFront distribution is only serving static objects from Simple Storage Service (Amazon S3), then you might not even need to apply a WebACL to it.

Intelligent Threat Mitigation

Unlike free AWS Managed Rule groups, the pricing model for Intelligent Threat Mitigation features differs and we show you how to use them in a cost-effective way.

Now that we’ve applied the rules for known good and bad traffic, and setup a flow control mechanism, we can start to introduce other AWS Managed Rule groups that are aligned with the technological stack of your application and as well as your business value.

It is advisable to restrict the requests sent to Intelligent Threat Mitigation rules based on the potential impact of attacks on your business. For example, what’s the impact of bots scraping your static assets vs. your product listing page? Use scope-down statements to narrow down the inspection of requests by Intelligent Threat Mitigation rules.

Figure 5: AWS BotControl rule group using scope-down statement to inspect all API calls

AWS WAF charges for challenge actions only when it’s terminating. Any tokens acquired through the challenge SDK are free of cost. For CAPTCHA actions, AWS WAF charges based on the number of attempts by a user and the cost is applicable regardless of rule action or JavaScript SDK.

When using CAPTCHA action, make sure you use a meaningful immunity time to reduce the number of requests analyzed and to improve user experience. For rules using a Challenge action, as long as you already have the AWS WAF client application integration in-place (JavaScript SDK and Mobile SDK), you should scope down the rule based on the presence of the aws-waf-token cookie. This makes sure that requests processed by that rule are coming from clients that are capable of handling the Challenge mechanism. As called out earlier, the challenge SDKs are free of cost and charges for challenge action are only applicable outside of intelligent threat detection managed rule set.

For more information, refer to Best practices for intelligent threat mitigation.

Figure 6: AWS WAF rule set to inspect aws-waf-token cookie and take an action

AWS WAF logging options

By enabling logging, you can access comprehensive information regarding the traffic analyzed by your WebACL. When configuring logging, you have the option to specify which log fields should be redacted and apply filters based on labels and actions. It is important to note that the request body is never logged.

As of today, AWS WAF can deliver logs to three different destinations, an Amazon CloudWatch Logs log group, an Amazon S3 bucket, or an Amazon Kinesis Data Firehose.

1. Amazon CloudWatch Logs: The benefit of utilizing CloudWatch logs is the seamless integration with other CloudWatch services like Logs Insights and Contributor Insights. The logged information is readily available for consumption and querying. If you do not currently have another log collection product or are already utilizing CloudWatch for this purpose, then this option is recommended.
2. Amazon Kinesis Data Firehose: Using Amazon Kinesis Data Firehose is the optimal choice when you have the requirement to deliver logs to a specific destination, whether it is an AWS service or a third-party log collector. Note that additional charges may apply depending on the destination you choose, such as Amazon OpenSearch, Amazon S3, or a third-party vendor. If you transfer data to another AWS Region or over the internet, then data transfer fees may be incurred. When delivering logs to Amazon S3 through Firehose, it is important to consider buffer settings to optimize either for delivery time or cost.
3. Amazon S3: If your organization already utilizes Amazon S3 as a centralized log aggregation solution, then this option is beneficial. AWS WAF relies on CloudWatch Logs to deliver logs to Amazon S3, and the associated delivery cost can be found under “Vended Logs” in CloudWatch. Using Amazon Kinesis Data Firehose for delivering AWS WAF logs becomes more cost-effective when your AWS WAF is analyzing billions of requests.

Example comparison table:

When choosing to send your logs to CloudWatch Logs or S3, you’ve the possibility to manage data retention. This makes sure that your log data is managed effectively and stored in accordance with your data policy requirements.

AWS Shield Advanced Considerations

AWS Shield Advanced provides sensitive detection and tailored mitigations against large and complex DDoS attacks, near real-time visibility into attacks, and integration with AWS WAF. The subscription cost includes the cost of any AWS WAF web ACL that you attach to a Shield Advanced protected resource. Furthermore, this cost only covers basic service costs and no Intelligent Threat Mitigation rules or logging you configure on the web ACL.

To apply this Shield Advanced cost coverage, make sure that all AWS WAF protected resources are also added to Shield Advanced protections so that AWS WAF is not charged separately. The intention is to have resources protected by all recommended services for DDoS to give you the best coverage and security benefit.

If you want to understand whether Shield Advanced is a good fit for your applications, then you can check our documentation and pricing for details.

Security Savings Bundle

If you are using AWS CloudFront and associated AWS WAF for inspection, AWS CloudFront provides the security savings bundle option, where you could save up to 30% on CloudFront charges and 10% credits for AWS WAF usage with your CloudFront distribution. For more information, refer CloudFront security savings bundle.

Summary of cost-effective AWS WAF web ACL configuration

1. Use Allow and Block rules
2. Establish flow control
3. Use AWS free managed rule groups
4. Use scope-down statements for paid rule groups
5. Limit the requests that you send to paid rule groups
6. Tune and configure token handling
7. Implement intelligent threat detection using AWS WAF SDKs
8. Use Shield Advanced for DDoS protection
9. Configure cost-optimal logging based on request volume

Figure 7: Example rule set, with Allow/Block first, followed by AWS Managed rule groups

Conclusion

This post explains some best practices that can help you optimize your costs for common use cases when configuring AWS WAF. AWS WAF is customizable, so you can tailor how you configure AWS WAF Rules and Rule groups cost effectively. Moreover, to keep updated with AWS WAF, refer to AWS WAF Security Blog and what’s new with AWS Security, Identity, & Compliance.

If you have feedback about this post, submit comments in the Comments section. If you have questions about this post, start a new thread on AWS WAF re:Post or contact AWS Support.