WAF 3.0 protects your Application Load Balancer (ALB) instances from web attacks without changing your existing network architecture or DNS configuration. Protection is enabled through an SDK embedded directly in the ALB data plane — no extra gateway hop, no certificate or configuration drift between WAF and ALB.
How it works
When traffic reaches your ALB instance, the embedded SDK performs real-time threat detection in the forwarding path. The SDK blocks malicious requests and forwards valid ones to the backend server. Because WAF does not participate in traffic forwarding as a separate gateway, requests pass through only one gateway. This eliminates extra-hop latency and removes the need to synchronize certificates and cipher suites between WAF and ALB.
Prerequisites
Before you begin, make sure that:
Same account: The ALB instance and WAF instance belong to the same Alibaba Cloud account, unless you have configured multi-account management.
Supported region: The ALB instance is in one of the following regions. If not, use CNAME record mode instead.
Supported instance type: Only Basic and Standard ALB instances in the Running state can be upgraded to the WAF-enabled edition.
Identity verification: Complete identity verification before purchasing a WAF-enabled ALB instance.
Supported regions:
Area | Regions |
China | China (Chengdu), China (Qingdao), China (Beijing), China (Guangzhou), China (Hangzhou), China (Ulanqab), China (Shanghai), China (Shenzhen), China (Zhangjiakou), China (Hong Kong) |
Asia-Pacific | Philippines (Manila), Indonesia (Jakarta), Japan (Tokyo), Malaysia (Kuala Lumpur), Singapore, Thailand (Bangkok), South Korea (Seoul) |
Europe and Americas | Germany (Frankfurt), US (Silicon Valley), US (Virginia), Mexico |
Middle East | SAU (Riyadh - Partner Region) |
Step 1: Open the ALB onboarding page
Log on to the Web Application Firewall 3.0 console. In the top navigation bar, select the resource group and region (Chinese Mainland or Outside Chinese Mainland) of your WAF instance. In the left navigation pane, click Onboarding. Click the Cloud Native tab, then click Application Load Balancer (ALB) from the cloud service list.
Step 2: Authorize the cloud service (first-time only)
If this is your first time using cloud-native integration, follow the on-screen prompts and click Authorize Now. This creates the AliyunServiceRoleForWAF service-linked role, which you can view on the Identities > Roles page of the RAM console.
Step 3: Add the ALB instance
In the list on the right, find the ALB instance to protect and click Add Now in the Actions column. If the instance does not appear, click Synchronize Assets in the upper-right corner.
When the status shows Full Protection, the instance is added successfully.
Adding an ALB instance to WAF automatically upgrades it to the WAF-enabled edition. This incurs additional fees on the ALB side.
You can also add multiple ALB instances in a batch or click One-Click Onboarding to add all instances at once.
Step 4: Verify that protection is active
Enter your website domain followed by a cross-site scripting (XSS) test string in your browser:
<your-website-domain>/alert(xss)If WAF returns a 405 error page, it has successfully intercepted the request and protection is active.
What to do next
Configure and manage protection rules
WAF automatically creates a protected object with a -alb suffix and enables default protection rules, including the core protection module. View them on the Protection Config > Protected Objects page.
If the default rules do not meet your requirements, create or edit protection rules. See Protection configuration overview.
If multiple domains resolve to the same ALB instance and you want different protection rules for each, manually add the domains as protected objects.
Related operations
Rollback (remove WAF protection)
Temporarily disable WAF protection: If you encounter issues such as a high number of false positives, go to the Protected Objects page in the WAF console and turn off the WAF Protection Status switch. See Disable WAF protection with one click.
Remove WAF protection: Go to the Cloud Native tab, click Application Load Balancer (ALB) from the cloud service list, find the target instance, and click Remove in the Actions column. In the dialog box that appears, click OK.
ImportantAfter removal, traffic to the ALB instance is no longer WAF-protected, and security reports will not include data for that traffic.
For pay-as-you-go instances: request processing charges stop after removal, but feature usage fees continue because the WAF instance and its protection rules remain. To stop all WAF billing, see Terminate the WAF service.
Enable and manage WAF protection in the ALB console
You can also enable and manage WAF protection from the ALB console:
Apply in production
Enabling and removing WAF protection for ALB instances does not interrupt services. However, when adding an ALB instance, you should still monitor logs and service health to ensure service availability.
Rollout strategy: During off-peak hours, first add a non-production ALB instance to WAF. Run it for a period to confirm normal operation before adding production ALB instances.
Verify services: After adding the instance, confirm that your services are running normally:
Check logs: Look for significant fluctuations in the ratio of
200status codes or sudden QPS spikes or drops. If you have enabled ALB or WAF log services, refer to ALB logs or WAF logs for inspection.Service monitoring: Check that business functions are working correctly, such as user access and transactions.
Ongoing maintenance: After adding production instances, perform ongoing maintenance and pay attention to attack and false positive events.
Review events: Monitor security reports and configure Cloud Monitor notifications to stay informed about attack and security events.
Tune rules: Review attack logs to identify false positives and adjust protection rules accordingly.
Limitations
Limitation | Details |
Identity verification | Required before purchasing a WAF-enabled ALB instance |
Eligible instance types | Basic and Standard ALB instances in the Running state only |
Container Service for Kubernetes (ACK) | To enable WAF for an ALB instance in ACK, see Use WAF-enabled ALB instances to protect applications |
Subscription — max integrated instances | Basic Edition: 300 / Pro Edition: 600 / Enterprise Edition: 2,500 / Ultimate Edition: 10,000 |
Pay-as-you-go — max integrated instances | 10,000 |
Unsupported features | Data leak prevention; automatic Web SDK integration for the anti-crawler scenario in Bot Management |
FAQ
Why can't I find the ALB instance I want to add?
Click Synchronize Assets in the upper-right corner of the Onboarding page first.
If the instance still does not appear, it does not meet the prerequisites. For example, an ALB instance outside the Chinese mainland requires a WAF instance in the same region group for cloud-native integration. If your region is not supported, use CNAME record mode instead.
One domain resolves to multiple ALB instances — how do I add WAF protection?
In cloud-native mode, add all of those ALB instances to WAF. In CNAME record mode, add the domain and configure the multiple ALB instance CNAMEs as origin addresses.
Multiple domains resolve to the same ALB instance — how do I apply different rules to each?
After adding the ALB instance in cloud-native mode, all domains on it are protected by the default policy. To apply different protection rules per domain, manually add each domain as a protected object. In CNAME record mode, add each domain individually.
Can I use both cloud-native and CNAME record modes for the same domain on an ALB instance?
No. Using both modes simultaneously causes forwarding conflicts and protection failure. To switch a domain from CNAME record mode to cloud-native mode: point your DNS records back to the origin, wait for DNS changes to propagate, delete the CNAME record mode configuration, and then add the ALB instance in cloud-native mode.
What are the differences between WAF 2.0 and WAF 3.0 integration with ALB?
WAF 3.0 uses an SDK embedded in the ALB instance. The SDK handles traffic extraction, detection, and protection without sitting in the forwarding path, so requests pass through only one gateway. This eliminates extra-hop latency and removes the need to synchronize certificates and cipher suites between WAF and ALB.
WAF 2.0 uses a transparent proxy. Traffic is redirected through WAF, which blocks attacks and forwards clean requests to the origin. Requests pass through two gateways, so you must keep configurations such as timeouts and certificates in sync across both.
For a full comparison, see Compare WAF 3.0 with WAF 2.0.