AWS WAF FAQs

AWS WAF is a web application firewall that helps protect web applications from attacks by allowing you to configure rules that allow, block, or monitor (count) web requests based on conditions that you define. These conditions include IP addresses, HTTP headers, HTTP body, URI strings, SQL injection and cross-site scripting.

As the underlying service receives requests for your web sites, it forwards those requests to AWS WAF for inspection against your rules. Once a request meets a condition defined in your rules, AWS WAF instructs the underlying service to either block or allow the request based on the action you define.

AWS WAF is tightly integrated with Amazon CloudFront, the Application Load Balancer (ALB), Amazon API Gateway, and AWS AppSync – services that AWS customers commonly use to deliver content for their websites and applications. When you use AWS WAF on Amazon CloudFront, your rules run in all AWS Edge Locations, located around the world close to your end users. This means security doesn’t come at the expense of performance. Blocked requests are stopped before they reach your web servers. When you use AWS WAF on regional services, such as Application Load Balancer, Amazon API Gateway, and AWS AppSync, your rules run in region and can be used to protect internet-facing resources as well as internal resources.

Yes, AWS WAF is integrated with Amazon CloudFront, which supports custom origins outside of AWS.

AWS WAF helps protects your website from common attack techniques like SQL injection and Cross-Site Scripting (XSS). In addition, you can create rules that can block or rate-limit traffic from specific user-agents, from specific IP addresses, or that contain particular request headers. See the AWS WAF Developer Guide for examples.

AWS WAF Bot Control gives you visibility and control over common and pervasive bot traffic to your applications. With Bot Control, you can easily monitor, block, or rate-limit pervasive bots, such as scrapers, scanners, and crawlers, and you can allow common bots, such as status monitors and search engines. You can use the Bot Control managed rule group alongside other Managed Rules for WAF or with your own custom WAF rules to protect your applications. See the AWS WAF Bot Control section in the developer guide.

Yes. To receive a history of all AWS WAF API calls made on your account, you simply turn on AWS CloudTrail in the CloudTrail's AWS Management Console. For more information, visit AWS CloudTrail home page or visit the AWS WAF Developer Guide.

Yes, support for IPv6 allows the AWS WAF to inspect HTTP/S requests coming from both IPv6 and IPv4 addresses.

Yes, you can setup new IPv6 match condition(s) for new and existing WebACLs, as per the documentation.

Yes. The sampled requests will show the IPv6 address where applicable.

Yes. You will be able to use all the existing features for traffic both over IPv6 and IPv4 without any discernable changes to performance, scalability or availability of the service.

AWS WAF can be deployed on Amazon CloudFront, the Application Load Balancer (ALB), Amazon API Gateway, and AWS AppSync. As part of Amazon CloudFront it can be part of your Content Distribution Network (CDN) protecting your resources and content at the Edge locations. As part of the Application Load Balancer it can protect your origin web servers running behind the ALBs. As part of Amazon API Gateway, it can help secure and protect your REST APIs. As part of AWS AppSync, it can help secure and protect your GraphQL APIs.

Please refer to the AWS Region Services table.

Yes, AWS has expanded its HIPAA compliance program to include AWS WAF as a HIPAA eligible service. If you have an executed Business Associate Agreement (BAA) with AWS, you can use AWS WAF to protect your web applications from common web exploits. For more information, see HIPAA Compliance.

AWS WAF charges based on the number of web access control lists (web ACLs) that you create, the number of rules that you add per web ACL, and the number of web requests that you receive. There are no upfront commitments. AWS WAF charges are in addition to Amazon CloudFront pricing, the Application Load Balancer (ALB) pricing, Amazon API Gateway pricing, and/or AWS AppSync pricing.

Rate-based Rules are type of Rule that can be configured in AWS WAF, allowing you to specify the number of web requests that are allowed by a client IP in a trailing, continuously updated, 5 minute period. If an IP address breaches the configured limit, new requests will be blocked until the request rate falls below the configured threshold.

Rate-based Rules are similar to regular Rules, with one addition: the ability to configure a rate-based threshold. If, for example, the threshold for the Rate-based Rule is set to (say) 2,000, the rule will block all IPs that have more than 2,000 requests in the last 5 minute interval. A Rate-based Rule can also contain any other AWS WAF Condition that is available for a regular rule.

A Rate-based Rule costs the same as a regular AWS WAF Rule which is $1 per rule per WebACL per month

Here are some popular use cases customers can address with Rate-based rules:

• I want to block or count an IP address when that IP address exceeds the configured threshold rate (configurable in web requests per trailing 5 minute period)
• I want to know which IP address are currently being blocked because they exceeded the configured threshold rate
• I want IP addresses that have been added to the block list to be automatically removed when they are no longer violating the configured threshold rate
• I want to exempt certain high-traffic source IP ranges from being blocked by my Rate-based rules

Yes. Rate-based rules are compatible with existing AWS WAF match conditions. This allows you to further refine your match criteria and limit rate-based mitigations to specific URLs of your website or traffic coming from specific referrers (or user agents) or add other custom match criteria.

Yes. This new rules type is designed to protect you from use cases such web-layer DDoS attacks, brute force login attempts and bad bots.

Rate-based Rules support all the visibility features currently available on the regular AWS WAF Rules. Additionally, they will get visibility into the IP addresses blocked as a result of the Rate-based Rule.

Yes. Here is an example. Suppose that you want to limit requests to the login page on your website. To do this, you could add the following string match condition to a rate-based rule:

• The Part of the request to filter on is “URI”.
• The Match Type is “Starts with”.
• A Value to match is “/login” (this need to be whatever identifies the login page in the URI portion of the web request)

Additionally, you would specify a Rate Limit of, say, 15,000 requests per 5 minutes. Adding this rate-based rule to a web ACL will limit requests to your login page per IP address without affecting the rest of your site.

Yes. You can do this by having a separate IP match condition that allows the request within the Rate-base Rule.

The accuracy of the IP Address to country lookup database varies by region. Based on recent tests, our overall accuracy for the IP address to country mapping is 99.8%.

Managed Rules are an easy way to deploy pre-configured rules to protect your applications common threats like application vulnerabilities like OWASP, bots, or Common Vulnerabilities and Exposures (CVE). AWS Managed Rules for AWS WAF are managed by AWS, whereas Managed Rules from AWS Marketplace is managed by third-party security sellers.

You can subscribe to a Managed Rule provided by a Marketplace security Seller from the AWS WAF console or from the AWS Marketplace. All subscribed Managed Rules will be available for you to add to an AWS WAF web ACL.

Yes, you can use Managed Rules along with your custom AWS WAF rules. You can add Managed Rules to your existing AWS WAF web ACL to which you might have already added your own rules.

The number of rules inside a Managed Rule does not count towards your limit. However, each Managed Rule added to your web ACL will count as 1 rule.

You can add a Managed Rule to a web ACL or remove it from the web ACL anytime. The Managed Rules are disabled once you disassociate a Managed Rule from any web ACLs.

AWS WAF allows you to configure a “count” action for a Managed Rule, which counts the number of web requests that are matched by the rules inside the Managed Rule. You can look at the number of counted web requests to estimate how many of your web requests would be blocked if you enable the Managed Rule.

Yes, you can configure CloudFront to present a custom error page when requests are blocked. Please see the CloudFront Developer Guide for more information

After an initial setup, adding or changing to rules typically takes around a minute to propagate worldwide.

AWS WAF includes two different ways to see how your website is being protected: one-minute metrics are available in CloudWatch and Sampled Web Requests are available in the AWS WAF API or management console. These allow you to see which requests were blocked, allowed, or counted and what rule was matched on a given request (i.e., this web request was blocked due to an IP address condition, etc.). For more information see the AWS WAF Developer Guide.

AWS WAF allows you to configure a “count” action for rules, which counts the number of web requests that meet your rule conditions. You can look at the number of counted web requests to estimate how many of your web requests would be blocked or allowed if you enable the rule.

Real-Time Metrics are stored in Amazon CloudWatch. Using Amazon CloudWatch you can configure the time period in which you want to expire events. Sampled Web Requests are stored for up to 3 hours.

Yes. AWS WAF helps protect applications and can inspect web requests transmitted over HTTP or HTTPS.

Account Takeover Prevention (ATP) is a managed rule group that monitors traffic to your application’s login page to detect unauthorized access to user accounts using compromised credentials. You can use ATP to prevent credential stuffing attacks, brute force login attempts, and other anomalous login activities. As login attempts are made to your application, ATP checks in real time whether the user names and passwords submitted have been compromised elsewhere on the web. Checking for anomalous login attempts coming from bad actors, ATP correlates requests seen over time to help you detect and mitigate brute force attempts and credential stuffing attacks. ATP also offers optional JavaScript and iOS/Android SDKs that can be integrated into your application to provide you with additional telemetry on user devices that attempt to log in to your application to better protect your application against automated login attempts by bots.

Traffic between user devices and your application is secured by the SSL/TLS protocol that you configure for the AWS service you use to front your application, such as Amazon CloudFront, Application Load Balancer, Amazon API Gateway, or AWS AppSync. Once a user credential reaches AWS WAF, AWS WAF inspects the credential and then immediately hashes and discards it, and the credential never leaves the AWS network. Any communication between AWS services you use in your application and AWS WAF is encrypted in transit and at rest.

Bot Control gives you visibility and control over common and pervasive bot traffic that can consume resources, skew metrics, cause downtime, and perform other undesired activities. Bot Control checks various header fields and request properties against known bot signatures to detect and categorize automated bots, such as scrapers, scanners, and crawlers.

Account Takeover Prevention (ATP) gives you visibility and control over anomalous login attempts from bad actors using compromised credentials, helping you prevent against unauthorized access that may lead to fraudulent activity. ATP is used to protect your application’s login page.

Bot Control and ATP can be used independently of each other or used together. As with Bot Control managed rule groups, you can use ATP’s default rule action to block matching requests, or you can customize the behavior of ATP using AWS WAF mitigation functionality.

On the AWS WAF console, create a new web ACL, or modify an existing web ACL if you are using AWS WAF already. You can use the wizard to help you configure basic settings, such as which resource you want to protect and which rules to add. When prompted to add rules, select Add Managed Rules and then select Account Creation Fraud Prevention from the list of managed rules. To configure ATP, enter the URL of your application’s login page and indicate where the user name and password form fields are located within the request’s body.

JavaScript and Mobile SDKs provide additional telemetry on user devices that attempt to log in to your application to better protect your application against automated login attempts by bots. You do not need to use one of the SDKs, but we recommend that you do so for additional protection.

When ATP determines that a user’s credential has been compromised, it generates a label to indicate a match. By default, AWS WAF automatically blocks login attempts that are determined to be malicious or anomalous (for example, abnormal levels of failed login attempts, repeat offenders, and login attempts from bots). You can change how AWS WAF responds to matches by writing AWS WAF rules that act on the label.

Account Creation Fraud prevention (ACFP) is a paid managed rule group that allows you to detect and mitigate fake account creation attack against your sign-up or registration page. You can use ACFP to prevent promotional or sign-up abuse, loyalty or rewards abuse and phishing. As new accounts sign-up, ACFP verifies each credential (i.e., username and password) submitted, email domains used, and other information like phone numbers, address fields entered in real-time and blocks the sign-up attempt if any of this information is considered stolen, or has bad reputation. In addition, ACFP includes fraud risk predictions that you can use without requiring any deep knowledge of ML-based detection models. ACFP also offers recommended JavaScript and iOS/Android SDKs that can be integrated into your application to provide you with additional telemetry on user to better protect your application against automated login attempts by bots.

Account Takeover attacks an application’s sign-in page with a goal of gaining unauthorized access to an existing account, whereas account creation fraud targets the application’s sign-up page with a goal of committing fraud through these fake accounts. ATP is focused on preventing credential stuffing and brute force attacks, where attackers automate hundreds of login attempts, testing stolen credentials across multiple sites. Instead, ACFP focuses on preventing automated fraud such as promotional or sign-up abuse, loyalty or rewards abuse and phishing. ACFP and ATP can be used independently of each other or used together.

On the AWS WAF console, create a new web ACL, or modify an existing web ACL if you are using AWS WAF already. You can use the wizard to help you configure basic settings, such as which resource you want to protect and which rules to add. When prompted to add rules, select Add Managed Rules and then select Account Takeover Prevention from the list of managed rules. To configure ACFP, enter the URL of your application’s account creation and registration page. In addition, you can also indicate where the user name, password, address, and phone number form fields are located within the request’s body.

Optional but highly recommended. SDK integration provides additional information such as browser versions, plugins and canvas data that increases the efficacy of ACP rules. If SDK integration is not used, we enforce this using Challenge action. Challenge action does not work well with Single page applications (SPA) and Native Mobile apps, so for these applications, SDK integration is mandatory. For other apps that can withstand a page refresh such as HTML pages, SDK integration is optional. We support JS SDK for web applications, and Android and iOS SDK for native mobile applications.

You can observe how ACFP is protecting your application by reviewing the Fraud Dashboard on the console, WAF full logging, and CloudWatch Metrics.

Dashboard: A centralized dashboard for monitoring requests analyzed by ACFP and ATP CloudWatch Metrics: All rule actions with the ACFP rule group will emit CloudWatch Metrics that customers can use to create alerts and notifications.

WAF Logging: All requests analyzed by ACFP will be logged in WAF logs, so You can use the existing logging solutions to query and analyze logs for ACFP managed rule. ACFP will log details such as rule actions, label information and risk scoring, which can be used to track efficacy of ACFP.