Table of Contents
- 1. Introduction
- 2. About the ASN Match Rule Statement
- 3. About the Aggregation Key for Rate-Based Rules
- 4. Support in WafCharm
- 5. Conclusion
1. Introduction
AWS announced on June 5, 2025, that AWS WAF now supports ASN (Autonomous System Numbers).
Announcing ASN match support for AWS WAF
ASNs are unique identifiers assigned to large internet networks managed by organizations such as internet service providers and enterprises. This update introduces an ASN match rule statement and an aggregation key for rate-based rules.
In this blog post, we'll take a look at how to use ASNs in your WAF rules.
2. About the ASN Match Rule Statement
When you open the Inspect dropdown menu on the AWS WAF rule configuration page, you'll see a new option labeled [Originates from an ASN in]. By specifying ASNs, the configured rule action will be applied to requests that originate from the specified ASN.
To specify an ASN, you must first identify the ASN you want to detect.
Please keep in mind that if no rules related to ASN are configured, ASN values will not appear in WAF logs. If you want to identify the ASN of a specific request, you’ll need to use a method other than WAF logs.
ASNs are determined by AWS WAF based on IP addresses, so you must specify which IP address to use for evaluation. You can choose either the Source IP address or IP address in header.
If you select Source IP address, the value "0" is assigned as the ASN when AWS WAF cannot determine an ASN for the given IP address. If you want to define how to handle requests for cases where the ASN cannot be determined, you can create a condition that matches ASN value "0".
The logic for using IP address in header is the same as that for conditions targeting IP addresses. One important limitation to note is that when you select IP address in header, the [Position inside header] setting is fixed to: [Use the first IP address value in the header to inspect against this rule.] by default. In most cases, the first IP address represents the client’s IP address. However, if you need to inspect a different position in the header, this cannot be done using ASN-based conditions, as ASN evaluation only applies to the first IP.
Please refer to the AWS official documentation below for more information about the ASN match rule statement.
Autonomous System Number (ASN) match rule statement
3. About the Aggregation Key for Rate-Based Rules
In rate-based rules, you can specify the ASN as aggregation keys. For more information about rate-based rules, please refer to the blog posts below.
How to use rate-based rules
You can now specify detailed conditions in rate-based rules
AWS WAF now supports URI paths as custom key in rate-based rules
As stated in the blog posts above, the aggregation key (custom key) is used to aggregate requests based on components other than IP addresses to rate limit requests. If you choose to aggregate requests using the ASNs, the rate-based rule will be applied when requests with the same ASN value exceed the threshold. This option would be useful if you want to identify requesters based on ASNs.
ASNs are determined by AWS WAF, just like the ASN match rule statement. You are required to specify which IP address to use for evaluation. When using rate-based rules, if you select IP address in header, the first IP address in the header will be used as well.
Please refer to the AWS official documentation below for more information about using ASN in rate-based rules.
Aggregating rate-based rules in AWS WAF
4. Support in WafCharm
As of June 10th, 2025, WafCharm has not yet been updated with this change. If you add a regular rule or a rate-based rule using ASNs, an error may occur in WafCharm. We apologize for the inconvenience and will update this blog post as soon as we are up to date.
5. Conclusion
With this update, ASN support has been added to both the match rule statement and the aggregation key for rate-based rules.
In terms of value stability, ASNs are more consistent than IP addresses. When you want to detect access at the organization level, you do not need to specify individual IP addresses or continually update the values that may change on the daily basis, which makes ASNs a a more efficient choice.
On the other hand, since detection is performed at the organization level, clients may not be able to access your service at all if they are using infrastructure provided by that organization. This includes the risk of unintentionally blocking health checks from cloud services or restricting access from users who rely on a specific internet service provider.
This applies to other conditions as well, but to avoid false positives, it may be a good idea to start with the Count action or to block only known malicious sources.
