An Alibaba Cloud DDoS test has to confront one behavior that most managed protections do not have: the free tier's last resort is to take you offline on purpose.
Anti-DDoS Basic is on by default for every Alibaba Cloud public IP, and for small attacks it quietly absorbs them. But its final move, once an attack crosses a per-instance threshold, is not to keep scrubbing. It is to null-route the IP for a cool-down period so the attack cannot spill into shared infrastructure. Every packet to that address is dropped, the attacker's and your customers' alike.
From the platform's point of view this is correct. From your users' point of view it is the exact outage the attacker wanted, delivered by your own provider's protection.
So the headline finding on an Alibaba Cloud estate is not a misconfigured rule. It is a number: the offered volume at which Anti-DDoS Basic stops defending your availability and starts defending everyone else's. Below it you are protected. Above it you are blackholed. A test that never finds that number has not tested the thing most likely to cause your next outage.
This is the Alibaba-specific instance of structured DDoS testing. The methodology is the same one that governs any environment. The contour is Alibaba's: a free L3/L4 floor whose terminal action is a self-inflicted null-route, a set of paid tiers that replace that blackhole with real mitigation, and a separately provisioned web application firewall for everything above the network layer.
The free floor protects the cloud, not necessarily you
Picture the request path as a stack of controls, and separate what you inherit for free from what you have to buy and wire in.
At the bottom, Alibaba Cloud turns on Anti-DDoS Basic for every public IP at no charge. It absorbs volumetric and protocol pressure up to a threshold that scales with the instance and region.
Cross that threshold and the behavior changes in kind, not degree. The IP is placed in a blackhole, a remotely triggered null-route, and stays there until a cool-down timer expires. This is the same mechanism a carrier uses to protect its own backbone, applied here to protect Alibaba's shared network.
Above the floor sit the paid options that change this picture: Anti-DDoS Origin Enterprise, which raises or removes the blackhole threshold and protects the origin IP in place, and the Anti-DDoS proxy tiers, which put a scrubbing reverse proxy in front of the service. Neither is on until you provision it.
At a glance: what an Alibaba Cloud DDoS test validates
| Alibaba Cloud control | What it is supposed to do | What the test actually verifies |
|---|---|---|
| Anti-DDoS Basic | Always-on, free L3/L4 absorption per public IP | The blackhole threshold, and that crossing it null-routes legitimate traffic too |
| Anti-DDoS Origin (Enterprise) | Raise or remove the blackhole threshold, protect the origin IP in place | Whether it is enabled, and the real offered rate it sustains without a null-route |
| Anti-DDoS Pro / Premium (proxy) | Reverse-proxy scrubbing at scale, geo-scoped | Whether live DNS resolves through it, and whether the origin is reachable around it |
| Alibaba Cloud WAF | L7 rule enforcement, rate limiting, bot defense | Whether it is provisioned, in the path, and enforcing rather than logging |
| Cloud Firewall / security groups | Stateful L3/L4 filtering and access control | Whether direct-to-ECS access is denied; whether the state table is the bottleneck |
| SLB / ALB | Distribute connections, terminate TLS | The connection and request ceiling for the size; reachability of backends around it |
| ECS instance | Serve the application | The single-node ceiling and which kernel limit gives way first |
The recurring theme: the control that is always on is the one whose success condition is your outage, and the controls that actually keep you serving are the ones you have to turn on.
None of the paid tiers matter for a hostname that never resolves through them. Confirming that every public name actually routes through the protection you provisioned is a separate check, covered in is your protection actually in the path.
The protection surface you are testing
Be precise about what each layer does, and whether it is actually present, before designing the test. On Alibaba Cloud that precision hinges on one distinction: the free floor manages the platform's risk, and the paid tiers manage yours.
Anti-DDoS Basic: always on, and its last resort is a blackhole
Anti-DDoS Basic requires no configuration. It watches every public IP and scrubs volumetric and protocol attacks up to a scrubbing threshold, then blackholes the IP once traffic exceeds the blackhole threshold.
Two numbers govern it, and both are worth measuring rather than assuming. The scrubbing threshold is where automated cleaning begins. The blackhole threshold is where cleaning stops and the null-route begins. Between them you are defended; above the second one you are offline by design.
The durable test step is to characterize both thresholds for your instance types and regions, and to confirm what a legitimate user experiences during a blackhole window: not degraded service, but no service, for the full cool-down, with no way to shorten it from your side except by removing the attack surface the null-route is protecting.
This is a genuine floor, and it is worth appreciating for what it is not. It does not read the application request, so it does not stop an HTTP flood that completes valid handshakes. A SYN flood or carpet-bombing run across an instance range is its domain; a well-formed request storm is not.
Anti-DDoS Origin Enterprise and the proxy tiers
The paid products exist precisely to replace the blackhole with mitigation, and they take two different shapes.
Anti-DDoS Origin Enterprise protects the origin IP in place. There is no CNAME change and no proxy hop; it raises or removes the blackhole threshold on the addresses you already run, and provides higher-capacity scrubbing across the account's assets in a region. The test question is simple and binary: is it enabled for this workload, and what offered rate does it actually sustain before anything sheds?
The Anti-DDoS proxy tiers work like any scrubbing edge. You point a CNAME at the proxy, it cleans traffic and forwards to the origin, and it comes in two geo-scoped forms: one for assets inside mainland China, which carries the usual ICP-filing requirement, and one for assets outside it. Because it is a reverse proxy in front of a separate origin, it inherits the same invariant every edge does, examined in depth in Cloudflare DDoS testing: it protects the service only while all traffic actually arrives through it.
The L7 layer: Alibaba Cloud WAF is a separate product
Nothing in the DDoS family reads the application request. Alibaba Cloud WAF is a distinct product with its own provisioning, its own rules, and its own place in the path, whether chained behind an Anti-DDoS proxy or deployed in front of the origin directly.
That separation is the second false green after the blackhole. A team can hold a WAF subscription, apply it to some domains, and run a public endpoint whose live DNS never traverses it. And where the WAF is in the path, a rule can sit in a monitoring mode that logs matches without blocking them, the Alibaba analog of AWS WAF COUNT, Azure WAF Detection, and Cloud Armor preview: true. The test verifies both facts: that the WAF is actually in the path, and that its rules enforce rather than observe.
Cloud Firewall, security groups, and SLB
Alibaba Cloud gives you a stateful Cloud Firewall with access control and intrusion prevention, plus per-instance security groups. Both track connection state, and both tables are finite. Under a TCP connection flood the filter that protects you is also a candidate layer of first failure: it can exhaust its state table at a traffic rate that looks idle on a bandwidth graph.
Server Load Balancer, in its classic, application, and network forms, terminates TLS and distributes connections across a backend pool. It is a balancer, not a WAF: it does not score requests or rate-limit by key, and it does nothing to stop a flood of valid requests from reaching the backends it spreads them across. A connection flood or slow-read attack consumes its slots without consuming much bandwidth.
ECS instances and ACK
An ECS instance is a fixed-size machine with kernel limits, conntrack table size, accept queue depth, and ephemeral port range, that cap concurrent work. Behind the free floor, with no proxy tier and no WAF, an application-layer flood lands here, and the single-node ceiling becomes the layer of first failure. The mechanics of that fixed-node L7 gap are worked through for the near-identical budget-VPS shape in DigitalOcean DDoS testing; the short version is that if a request storm reaches the instance, the only thing in its way is what you put there.
If you run Container Service for Kubernetes instead, the failure modes shift to ingress chokepoints and autoscaler timing, covered in Kubernetes DDoS testing. Test it as a cluster, not as a bare instance.
What Alibaba Cloud DDoS testing actually surfaces
A useful test is organized around the gaps that recur on Alibaba Cloud estates. They follow from the shape above: a free floor that null-routes, paid tiers that may not be enabled or in the path, and a fixed compute ceiling behind all of it.
The blackhole threshold is the headline finding
On a cloud with a managed WAF in the account, the common finding is a rule in a permissive mode. On Alibaba Cloud the prior finding is quantitative: the volume at which your own provider takes the service offline to protect its network.
That number reframes several assumptions. "Anti-DDoS Basic is enabled" does not mean "protected against volumetric attack"; it means "protected until a threshold, then null-routed." An attacker who knows the shape only has to push past the blackhole threshold, briefly, to convert a modest flood into a full cool-down outage. And because the null-route is total, none of your L7 controls or application logic ever get a chance to matter; the traffic never reaches them.
The test measures the blackhole threshold directly, confirms the cool-down behavior, and then answers the only question that resolves it: whether a paid tier, Anti-DDoS Origin Enterprise on the IP or an Anti-DDoS proxy in front of it, is provisioned to raise or remove the threshold for this workload. That is the difference between a control that protects the platform and one that protects your uptime.
Origin exposure drops you back to the blackhole
When you do run an Anti-DDoS proxy, its value collapses the moment the ECS origin is reachable on its own public IP. A direct connection skips the scrubbing proxy and the WAF and lands on the instance behind nothing but Anti-DDoS Basic, which means the attacker has not only bypassed your paid mitigation, they have dropped you back onto the tier that null-routes.
The origin's address leaks through historical DNS, certificate transparency logs at crt.sh, an A record that was never moved behind the proxy, or an IP hard-coded in a client bundle. The full mechanics are in how attackers bypass CDN protection, and the invariant is the same one that governs a productized third-party edge in IBM Cloud DDoS testing.
The lock is specific: put the ECS instances in a private VNet segment, and write a Cloud Firewall or security-group rule that allows the application ports only from the Anti-DDoS proxy's back-to-source ranges, denying direct public access, ideally paired with an origin-authentication secret so a guessed address alone is not enough. The defining test is a direct connection to the instance's public IP from outside the allowed source. It must be refused. If it succeeds, every paid layer is voided in one move.
The fixed ceiling with nothing behind it
Where an attack reaches the ECS instance, whether because no proxy is in the path or because the origin was reachable around it, the instance's own kernel is usually the layer of first failure. It gives way at a request rate that looks unremarkable on a bandwidth chart. A connection flood fills the conntrack table, a burst of half-open connections exhausts the accept queue, a flood of new TLS sessions burns CPU on handshakes. None of these fill the pipe; they fill a table or a core.
A fixed-size instance has no elasticity to soften that, so the number the test produces, the offered rate at which goodput collapses, is the number that matters. Identify which limit goes first for this instance type and workload. It is the same discipline whether a proxy is present or not, because the proxy is exactly what determines how much of the flood ever reaches that ceiling.
Alibaba Cloud authorization: platform policy on top of owner authorization
An Alibaba Cloud DDoS test runs into platform policy that sits on top of, never in place of, authorization from the target's legal owner.
Alibaba Cloud's acceptable-use terms prohibit using its network to attack others, and its abuse and Anti-DDoS systems watch for traffic that resembles an attack, including traffic you generate against your own instance. A high-volume simulated flood can read as an attack whether you source it from inside Alibaba Cloud or aim it inward, and either can trigger automated action, up to and including the very blackhole you are trying to characterize.
That last point is worth planning around. A test designed to find the blackhole threshold will, if it succeeds, trip a real null-route on the IP under test, so it belongs on an instance you can afford to lose to a cool-down, coordinated with support, and never on a production address without an explicit, scoped canary.
The durable instruction is procedural, because specific policies and contact processes change. Before any Alibaba Cloud test, read the current acceptable-use and DDoS-testing guidance, and coordinate the window with support if your plan approaches volumes their systems would flag. Authorization from the legal owner of the target is mandatory regardless of platform policy. The same discipline of running the test without disrupting production applies in full.
Designing the test: environment, scope, and measurement
The structure that keeps an Alibaba Cloud test informative and safe is the one that governs any production-adjacent test, with an Alibaba contour.
Environment selection
The strongest first target is a staging environment built from the same Terraform or Resource Orchestration Service templates as production: the same instance types, the same security groups and Cloud Firewall rules, the same SLB configuration, and critically the same protection state, either fronted by the same Anti-DDoS tier and WAF or deliberately not, matching production. A mirror that adds a proxy tier production lacks, or omits one production has, tests the wrong stack.
The blackhole finding in particular is best confirmed on a disposable staging IP, because confirming it means triggering it. Where a finding can only be observed in production, the reachability of the ECS public IP, for instance, a tightly scoped canary with explicit abort criteria does the job.
Scope as a bounding document
The scope names the exact resources: instance IDs and their public IPs, which Anti-DDoS tier protects which addresses, whether an Anti-DDoS proxy is in the path and its geo scope, the WAF instances and the domains they front, the SLBs, and the security groups and Cloud Firewall policies in force. It sets the vectors and maximum rates, the test windows, the kill switch, and the escalation path.
On Alibaba Cloud specifically, the scope should record the protection tier per IP, because the test will deliberately compare a proxy-fronted or Origin-Enterprise-protected path against a bare Anti-DDoS Basic path, to characterize both the blackhole threshold and the difference a paid tier makes.
Measurement per control
Each control gets a measured outcome. Anti-DDoS Basic: the scrubbing and blackhole thresholds, and the cool-down behavior. Anti-DDoS Origin Enterprise or proxy: the offered rate sustained without a null-route, and what the proxy filtered. WAF: whether it was in the path and enforcing rather than logging. Cloud Firewall and security groups: whether direct-to-ECS connections were refused, and whether the state table held. SLB: the connection and request rate at which it began shedding. ECS: the offered rate at which goodput collapsed and which kernel limit gave way first.
The deliverable is not "the site stayed up." It is a per-layer characterization: what engaged, at what threshold, in what order, and what a real user experienced while it did. Folding those numbers into a defensible posture is the subject of DDoS resilience testing.
Mapping attack classes to Alibaba Cloud controls
A thorough test exercises each layer against the control meant to defend it, including the layers where the defender is a paid product that may be absent. The mechanics of each class are covered in DDoS attack vectors, and real adversaries rarely send one class at a time, which is the subject of multi-vector DDoS testing.
- L3/L4 volumetric and protocol (SYN flood, UDP reflection, ACK flood, carpet-bombing) are Anti-DDoS Basic's domain up to the blackhole threshold, and past it they become a null-route unless Anti-DDoS Origin Enterprise or a proxy tier is enabled. The test confirms the thresholds, the cool-down, and that a paid tier actually changes them.
- Connection-state floods (TCP connection flood, slow-read, half-open) are absorbed by the SLB up to its size, then by the instance's conntrack and accept queue. This class reveals the connection ceiling and the state-table limit, which sit well below the bandwidth ceiling.
- L7 application floods (HTTP floods, HTTP/2 abuse, slow attacks) have a managed defender only where Alibaba Cloud WAF is provisioned and in the path. Where it is absent, or in a logging mode, this class lands on the instance directly and tests whatever L7 control you added, or proves that none exists.
- Application-logic abuse (credential stuffing under any rate limit, expensive search, cart abuse) is the hardest class anywhere. The WAF's bot and API controls address part of it; the rest is an application-code concern that no platform solves for you.
Procurement note: subscription versus project engagement
One consideration sits at the procurement layer rather than the technical one. DDoS testing is engaged both as an ongoing subscription and as a discrete project.
The models suit different cadences. An Alibaba Cloud deployment that changes when a proxy tier is finally put in front of a service, when Anti-DDoS Origin Enterprise is enabled on a new address, or when an instance comes up outside the protected set, maps naturally onto project engagements: the test happens when the change happens. A continuously deploying estate may prefer a standing capability.
Neither is universally correct. Annual-subscription commitments can price out a team whose real need is a handful of well-scoped tests a year. Match the engagement model to the cadence the estate warrants, not the model a vendor leads with.
FAQ
What is Alibaba Cloud DDoS testing?
Controlled, authorized generation of attack-shaped traffic against Alibaba Cloud-hosted workloads, to verify how the stack behaves under pressure. It validates the specific deployment: the Anti-DDoS Basic scrubbing and blackhole thresholds, whether a paid Anti-DDoS tier is enabled and in the path, whether Alibaba Cloud WAF is enforcing, the SLB and security-group limits, and the ECS ceiling, rather than testing whether Alibaba's protection works in general.
Does Alibaba Cloud protect against DDoS attacks?
At L3/L4, up to a point: Anti-DDoS Basic is free and always on, and it absorbs attacks until they cross a per-instance blackhole threshold, at which point it null-routes the IP for a cool-down period to protect shared infrastructure. Sustained protection above that threshold requires a paid tier, Anti-DDoS Origin Enterprise or an Anti-DDoS proxy. It does not include a managed WAF; application-layer defense is a separate Alibaba Cloud WAF subscription or your own stack.
What is the Anti-DDoS Basic blackhole, and why does it matter for testing?
It is an automatic null-route: once attack traffic to an IP exceeds the blackhole threshold, Alibaba Cloud drops all traffic to that address for a fixed cool-down, legitimate users included. It matters because it means the free tier's worst-case behavior is a complete outage of your service, delivered to protect the platform. Finding the threshold, and confirming whether a paid tier removes it, is usually the single most valuable result of the test.
Do you need permission to run an Alibaba Cloud DDoS test?
Treat it as required. Alibaba Cloud's acceptable-use terms prohibit attack traffic, and its abuse and Anti-DDoS systems can act on traffic that resembles an attack, including against your own instance, potentially triggering the blackhole itself. Read the current guidance, coordinate a high-volume test with support, run threshold-finding tests on disposable IPs, and obtain written authorization from the target owner regardless.
What is the first thing to validate on an Alibaba Cloud deployment?
The blackhole threshold, and whether anything raises it. Establish the offered volume at which Anti-DDoS Basic null-routes each public IP, confirm whether Anti-DDoS Origin Enterprise or a proxy tier is provisioned to change that, and confirm the ECS origins refuse any connection that does not arrive through the intended path. The most common false green is reading "Anti-DDoS Basic enabled" as protection when its terminal action is your outage.
Where Alibaba Cloud resilience is actually decided
The durable knowledge from a test separates cleanly from the perishable. Five years from now, Anti-DDoS Basic will still absorb small attacks and null-route large ones, the paid tiers will still be the difference between a threshold and a guarantee, the WAF will still be a separate product you have to put in the path, and origin exposure will still drop a proxied service back onto the blackhole. Those are stable.
What you have to keep re-verifying is everything built on top:
- the blackhole threshold for each instance type and region, which moves as you resize and relocate
- whether a paid tier is still enabled on every public-facing IP, or a new address came up on bare Basic
- whether live DNS still resolves through the Anti-DDoS proxy, or a record was repointed at the origin
- whether every ECS public IP is still firewalled to the proxy back-to-source ranges
- whether the WAF is still enforcing rather than quietly switched to a logging mode during an incident
None of that shows up on a console that reports Anti-DDoS Basic as active. It shows up the first time real attack-shaped traffic crosses the threshold and the platform makes the decision it was always going to make: protect its own network, and let your address go dark for the cool-down. The point of testing is to learn where that line is before an attacker charges you to find it.