Enable WAF protection for an ALB instance

How it works

A WAF-enabled ALB instance uses the WAF 3.0 SDK integration model. In this model, WAF does not act as an inline network node (gateway) for traffic forwarding. Instead, it only extracts, inspects, and protects traffic. This approach avoids the network latency, configuration complexity (such as certificate synchronization), and potential single points of failure associated with the transparent proxy mode.

For more information, see Comparison of WAF 3.0 and WAF 2.0.

Usage notes

For WAF-enabled ALB instances:

• Supported regions:

  Area	Region
  China	China (Chengdu), China (Qingdao), China (Beijing), China (Guangzhou), China (Hangzhou), China (Ulanqab), China (Shanghai), China (Shenzhen), China (Zhangjiakou), China (Hong Kong), China (Heyuan)
  Asia Pacific	Philippines (Manila), Indonesia (Jakarta), Japan (Tokyo), Malaysia (Kuala Lumpur), Singapore, Thailand (Bangkok), South Korea (Seoul)
  Europe & Americas	Germany (Frankfurt), US (Silicon Valley), US (Virginia), Mexico (Queretaro)
  Middle East	Saudi Arabia (Riyadh), UAE (Dubai)

• WAF-enabled ALB instances use the WAF 3.0 SDK integration model. If you have a WAF 2.0 instance in your account, you must first release the WAF 2.0 instance or migrate it to WAF 3.0.

  By default, ALB does not add the X-Forwarded-Proto header to requests. After you release a WAF 2.0 instance, accessing the ALB instance directly may cause service issues such as infinite redirects because backend servers cannot identify the original protocol (HTTP or HTTPS). To prevent this issue, you must manually enable the X-Forwarded-Proto request header in the ALB listener configuration.

• WAF-enabled ALB instances do not support the data leakage prevention feature of WAF.

Enable WAF protection for an ALB instance

After you enable WAF protection, the ALB instance is automatically integrated with your WAF instance. If you do not have a WAF instance, a pay-as-you-go WAF instance is automatically created.

WAF instances are deployed in regions within the Chinese Mainland and outside the Chinese Mainland. Your ALB instance integrates with a WAF instance in the same area.

View protection records

After you enable WAF protection for an ALB instance, WAF automatically creates a protected object with the -alb suffix and enables the core web protection rule by default. This rule automatically generates security reports that show its protection records.

To meet other security requirements, you can configure protection rules.

If multiple domain names resolve to the same ALB instance and you need to configure different protection rules for each domain name, you must add the domain names as protected objects.

Disable WAF protection

Disabling WAF protection means that traffic to your ALB instance is no longer protected by WAF. As a result, security reports will not include data for this traffic, and you will no longer be charged WAF request processing fees.

However, because the WAF instance and its protection rules still exist, you are still charged for the WAF service. To completely stop billing, you must disable WAF.

• Disable WAF protection: After you disable WAF protection, your ALB instance is downgraded from WAF-enabled to Standard. This change does not affect your services.

• Temporarily disable WAF: If many legitimate requests are incorrectly blocked, you can temporarily disable WAF protection to quickly restore your services.

  • After you temporarily disable WAF protection, the ALB instance remains a WAF-enabled instance. Traffic still flows through the WAF SDK that is embedded in the ALB instance but is no longer forwarded to the WAF cluster for inspection. Instead, the ALB instance directly forwards the traffic to backend servers.

  • Temporarily disabling WAF affects all protected objects associated with the WAF instance. Proceed with caution.

Apply in a production environment

• Canary testing: First, enable WAF protection for an ALB instance in a non-production environment that mirrors your production environment. Perform this action during off-peak hours. After you confirm that your services run as expected, enable protection for the ALB instance in your production environment.

• Continuous monitoring: After you enable WAF protection, monitor your business metrics and network performance metrics. Check security reports and configure CloudMonitor notifications to stay informed about attacks and security events.

• Rule tuning: Regularly review WAF interception logs, analyze false positives, and adjust protection rules to improve accuracy.

Billing

• Instance fee: Instance fee = Instance unit price (USD/hour) × Billing duration (hours)

• LCU fee: Hourly LCU fee = max{LCUs for new connections, LCUs for concurrent connections, LCUs for processed data, LCUs for rule evaluations} × LCU unit price

• Internet data transfer fee:

  • The internet data transfer fee applies only to internet-facing ALB instances, not to internal instances.

  • Internet-facing ALB instances use Elastic IP Addresses (EIPs) or Anycast EIPs. You are billed separately for the associated EIP or Anycast EIP.

• WAF 3.0 billing: WAF 3.0 supports the subscription and pay-as-you-go billing methods.

  • If you do not have a WAF instance, a pay-as-you-go WAF instance is automatically provisioned and you are billed for its usage when you create a WAF-enabled ALB instance.

  • If you have a subscription WAF 3.0 instance, you will not incur additional WAF fees when you create a WAF-enabled ALB instance.

FAQ