Anti-DDoS Basic Is a Default, Not a Defense

The assumption

Every ECS instance on Alibaba Cloud comes with Anti-DDoS Basic attached automatically, at no additional cost. That fact tends to get compressed, in conversation, into "we're protected against DDoS," a clean, closed statement that sounds like it resolves the question rather than opening a more specific one. I said that sentence myself, more than once, in security reviews, before I'd ever looked up what "protected" actually bounded.

The problem

Anti-DDoS Basic mitigates volumetric attacks up to a defined threshold: a real, published, and comparatively modest capacity relative to the scale of a serious, sustained attack. It's genuinely useful against the low-grade, opportunistic traffic that constitutes a meaningful share of internet background noise: scanner traffic, unsophisticated botnet chatter, the kind of low-effort flood that shows up against essentially any public IP address sooner or later. It was never sized, priced, or marketed as protection against a determined, large-scale attack: that's what Anti-DDoS Pro and Premium exist for, as paid, explicitly-provisioned tiers with dramatically higher mitigation capacity, procured deliberately rather than attached by default.

The gap isn't that Alibaba Cloud hides this: the tiered structure and capacity differences are documented plainly, with specific numbers published for each tier. The gap is that "some DDoS protection, automatically, for free" is such a reassuring starting point that it's easy to never ask the follow-up question: protection up to what threshold, and does that threshold have any relationship to what my actual exposure looks like. The word "protection" does a lot of quiet work in that sentence. It implies a category (defended versus undefended) rather than a quantity (defended up to X, and not beyond it), and categories don't invite follow-up questions the way quantities do.

Why "free and automatic" is the part that disarms scrutiny

Most security controls a team adopts involve some friction: a purchase decision, a configuration step, a line item someone has to justify in a budget review. That friction, annoying as it is, does double duty as a forcing function: it makes someone articulate what the control is for and what it costs, which tends to surface its actual scope along the way. Anti-DDoS Basic has none of that friction. It's there before anyone asks for it, which means nobody articulates its scope, because nobody had to decide to adopt it in the first place. The absence of a decision point is also the absence of a moment where someone would naturally have looked up the number.

Compare that to how teams usually treat Anti-DDoS Pro. Provisioning Pro means someone opens a pricing page, picks a capacity tier, and signs off on a recurring cost. That process, however brief, produces a document trail and at least one moment where a person had to think about the number in Gbps they were buying and why. Basic produces no equivalent trail. It shows up in the account the moment the instance does, described in the console with the same word ("protection") that Pro uses, with no comparable moment where anyone was forced to translate that word into a number.

The mitigation threshold isn't a secret, but it isn't surfaced either

None of this means the number is hidden. Alibaba Cloud publishes Anti-DDoS Basic's mitigation capacity in its documentation, and it's a five-minute lookup for anyone who thinks to go looking. The gap isn't secrecy, it's surfacing: the number lives in a documentation page a team would only visit if they already suspected there was something worth checking, not in the console view or billing summary most people actually look at day to day. A fact that's technically public but practically unconsulted behaves, for most operational purposes, like a fact nobody knows.

The experiment

I looked at this less as a live-fire test (simulating a genuine large-scale volumetric attack against real infrastructure is both impractical to do responsibly and unnecessary to make the point, and would risk affecting shared infrastructure well beyond my own instances) and more as a sizing exercise: comparing Anti-DDoS Basic's documented mitigation capacity against publicly reported attack sizes from recent years, for a workload profile representative of a small-to-mid-size production service, the kind of workload most teams running a handful of ECS instances actually have, not a hyperscale target.

I built the comparison in three parts: Basic's documented threshold, taken directly from Alibaba Cloud's published specifications; a rough estimate of the workload's realistic peak legitimate traffic, to establish what "normal" looks like for the kind of service being sized; and a distribution of publicly reported volumetric attack sizes from recent incident writeups and vendor threat reports, to see where a real attack would actually land relative to both numbers.

# rough traffic profile for a representative small-to-mid production service
Peak legitimate traffic (measured):       tens of Mbps, bursting under load spikes
Anti-DDoS Basic mitigation threshold:     low single-digit Gbps
Median reported volumetric attack (2024-2025 industry reporting): high single-digit
                                           to low double-digit Gbps
Large, headline-scale reported attacks:   hundreds of Gbps to multiple Tbps

The proof

Basic covers the workload's own traffic comfortably, and the noise floor above it

Anti-DDoS Basic's mitigation capacity comfortably covers the low end of that spectrum: exactly the opportunistic, unsophisticated traffic it's designed for, and comfortably above the workload's own legitimate peak traffic, which is the baseline it needs to clear to be useful at all. Against the kind of background scanning and low-effort flood traffic that hits almost any public IP eventually, Basic did exactly what it advertises.

Basic does not approach the scale of a determined attack

It does not remotely approach the scale of attacks that have been publicly reported against real infrastructure in recent years, which routinely exceed Basic's threshold by one or more orders of magnitude, and headline-scale attacks exceed it by two to three orders of magnitude. That's not a flaw in Basic. It was never positioned as protection against that scale of event; nothing in its documentation claims otherwise. But "Anti-DDoS Basic is attached to every instance" and "we have meaningful DDoS protection against a real attack" are, numerically, very different claims, and only the first one is automatically true regardless of what workload it's attached to.

Anti-DDoS Basic:     mitigation capacity in the low single-digit Gbps range
Anti-DDoS Pro:       provisioned capacity, scaled to purchased tier
Reported large-scale
volumetric attacks:  routinely exceed Basic's threshold by 10-100x

The specific numbers shift year over year as both attack scale and mitigation products evolve, which is itself part of the point. A threshold that felt adequate when a team last checked it can become inadequate purely because the landscape moved, with no change on the team's end at all. This is a meaningfully different failure mode from a misconfiguration: nobody has to make a mistake for the coverage gap to widen. Time alone does it, as attackers' available bandwidth grows and Basic's threshold, tuned for the low end of the threat distribution, stays where it was set.

What I think now

I now ask for the specific mitigation threshold number, compare it against the workload's realistic exposure (public-facing, revenue-relevant, previously targeted, associated with anything that draws attention like a high-profile launch or a controversial product), and treat "we're on Anti-DDoS Basic" as the beginning of a sizing conversation rather than its conclusion. For anything public-facing and business-critical, that conversation usually ends in at least evaluating Pro, even if the final decision is still to stay on Basic for cost reasons; the point is that it becomes a decision, not a default.

I've also started treating this threshold check as something to repeat on a cadence rather than something to do once, because the comparison isn't static: reported attack scale has grown substantially over the past several years, and a sizing conversation held two years ago used numbers that may no longer describe the current threat landscape, even if nothing about the workload itself has changed.

There's a broader habit I've taken from this that applies past DDoS specifically: any time a security control ships attached by default, free, and unrequested, I now ask what number defines its actual scope, on the assumption that a control without a signup friction is also a control without a natural moment where anyone checked that number. Free defaults are usually free precisely because they're cheap to provide at a modest, bounded capacity; the price of "attached automatically" is often "sized for the common case," and the common case is, by definition, not the case anyone is worried about when they ask "are we protected." I apply the same question now to default rate limits, default log retention windows, and default backup frequencies: each one is a real, useful default with a specific number behind it, and each one deserves the same two questions Anti-DDoS Basic did. What's the number, and does it happen to match what I actually need, or only what's cheap to give everyone by default.

The lesson learned

"We have DDoS protection" collapses a real, sized, tiered product into a single reassuring phrase. Anti-DDoS Basic is a genuinely useful default with a specific, finite capacity, not a substitute for asking whether that capacity matches your actual risk. The number is public. The sizing conversation using that number is the part that has to happen deliberately, and it has to happen more than once, because the number that mattered last year isn't guaranteed to be the number that matters now.