Alibaba Cloud Anti-DDoS Origin Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security

Category

Security

1. Introduction

Alibaba Cloud Anti-DDoS Origin is a managed Security service that helps protect internet-facing IP resources (such as public IPs on cloud workloads) from Distributed Denial of Service (DDoS) attacks. It is designed to keep services reachable by detecting abnormal traffic patterns and applying scrubbing/mitigation before malicious traffic overwhelms your origin.

In simple terms: you attach Anti-DDoS Origin to the public IPs that matter, and Alibaba Cloud provides upstream DDoS detection and mitigation capacity so your applications can continue serving legitimate users during attacks.

Technically, Anti-DDoS Origin works at the network edge (primarily Layer 3/Layer 4) to counter volumetric and protocol-based DDoS attacks. It monitors inbound traffic to protected IP assets, identifies attack signatures and anomalous rates, and applies mitigation policies in Alibaba Cloud’s DDoS protection infrastructure. The goal is to reduce or eliminate malicious traffic while allowing legitimate traffic to reach your origin.

The problem it solves: DDoS attacks can saturate bandwidth, exhaust connection tables, and destabilize network stacks and load balancers. Without upstream mitigation, even well-architected applications can become unreachable. Anti-DDoS Origin addresses this by providing cloud-scale capacity and managed mitigation closer to the source of the attack traffic.

Note on naming and product family: Alibaba Cloud has multiple DDoS-related products (for example, Anti-DDoS Basic and Anti-DDoS Proxy). This tutorial is specifically about Anti-DDoS Origin in Alibaba Cloud Security. Always verify the latest naming/editions in the official console and documentation because Alibaba Cloud periodically updates packaging and console navigation.


2. What is Anti-DDoS Origin?

Official purpose (in practical terms): Anti-DDoS Origin is intended to protect origin IP assets (public-facing IP addresses and certain Alibaba Cloud public endpoints) against DDoS attacks by providing managed, upstream DDoS detection and mitigation.

Core capabilities (what it generally does)

  • DDoS detection for abnormal inbound traffic patterns.
  • Mitigation/scrubbing for volumetric and protocol attacks (commonly L3/L4).
  • Visibility into attack events and traffic trends (attack reports, metrics).
  • Operational controls to manage protected assets and response behavior (exact knobs vary by edition—verify in official docs).

Major components (conceptual model)

While the exact UI and object model can vary by region/edition, Anti-DDoS Origin commonly involves: – Protected asset: the IP or cloud resource endpoint you want to protect (for example, an EIP or public IP). – Mitigation capacity: the level of protection capacity you purchase (often expressed as mitigation/cleaning bandwidth and/or QPS/pps constraints—verify exact dimensions). – Attack event center: event history, attack details, and mitigation status. – Monitoring and alerting: integration with Alibaba Cloud monitoring/notifications (verify supported integrations).

Service type

  • Managed cloud Security service (DDoS protection at/near Alibaba Cloud’s network edge).
  • Typically subscription-based product packaging for higher protection tiers (verify supported billing modes in your region).

Scope (how it’s scoped in Alibaba Cloud)

  • Generally account-scoped for purchasing/instance management.
  • Protected objects are typically region-associated because IP resources (EIP, SLB, etc.) are region-specific.
  • Protection effectiveness can be global in practice (internet attacks originate anywhere), but configuration and resource binding are usually regional.
    Verify the scope model for your specific asset types and region in the official documentation.

How it fits into the Alibaba Cloud ecosystem

Anti-DDoS Origin is usually positioned as: – The DDoS foundation for public-facing cloud workloads (ECS, load balancers, public IP assets). – Complementary to: – Web Application Firewall (WAF) for Layer 7 threats (SQLi, XSS, bot rules). – Cloud Firewall for network access control/policy. – Security Center for host-based threat detection and posture. – ActionTrail for audit logs of administrative actions. – CloudMonitor for metrics/alarms.


3. Why use Anti-DDoS Origin?

Business reasons

  • Reduced downtime risk: DDoS outages directly impact revenue and brand trust.
  • Lower incident cost: mitigations handled by a managed platform reduce time-to-recover and on-call fatigue.
  • Predictable protection strategy: capacity planning for “what if we get attacked” becomes part of a documented architecture.

Technical reasons

  • Upstream mitigation: stopping traffic before it overwhelms origin bandwidth and connection state is more effective than only origin-side filtering.
  • Cloud-scale scrubbing capacity: difficult and expensive to replicate on-prem or self-managed.
  • Better survivability for public endpoints: especially for TCP SYN floods, UDP floods, amplification attacks, and other L3/L4 patterns.

Operational reasons

  • Centralized control for protecting multiple IP assets.
  • Attack visibility (event timelines, top sources/ports/protocols depending on edition).
  • Alerting workflows so operations teams can correlate with application symptoms and autoscaling events.

Security / compliance reasons

  • Defense-in-depth: DDoS controls complement WAF, IAM, patching, and network policy.
  • Auditability: administrative actions can be logged (for example via ActionTrail—verify integration details).

Scalability / performance reasons

  • Mitigation at scale reduces the probability that backend load balancers, NAT devices, or stateful firewalls become bottlenecks under attack.
  • Helps maintain availability (a key pillar of Security).

When teams should choose it

  • You run internet-facing services (APIs, websites, game servers, SaaS endpoints).
  • You have public IP exposure where volumetric attacks are a real risk.
  • You need managed DDoS mitigation without building a scrubbing center.
  • Your availability SLOs require a formal DDoS protection layer.

When teams should not choose it

  • Your workload is not publicly reachable (private VPC-only services).
  • You only need application-layer protection (then WAF/bot protection may be the primary tool; DDoS protection can still be valuable, but it’s not the whole answer).
  • You require full control of mitigation logic (custom appliances, bespoke routing) and accept higher cost/complexity.
  • You’re protecting assets outside Alibaba Cloud where a different topology (such as proxy-based DDoS services) may fit better—verify cross-cloud protection options.

4. Where is Anti-DDoS Origin used?

Industries

  • E-commerce and retail (checkout and product API availability)
  • FinTech and payments (API uptime and transaction processing)
  • Gaming (UDP/TCP floods targeting game servers)
  • Media and streaming (bandwidth-heavy targets)
  • EdTech (traffic spikes and abuse during exams/events)
  • SaaS and B2B platforms (API endpoints and customer portals)
  • Public sector (high-visibility services that are frequent targets)

Team types

  • Platform engineering teams managing shared ingress
  • SRE/operations teams owning uptime
  • Security engineering teams owning threat models and Security controls
  • DevOps teams owning production networking and release reliability

Workloads and architectures

  • Public-facing ECS workloads with EIP
  • Load balancer frontends for web/apps (ALB/CLB/NLB—names vary; verify which types are supported)
  • Internet-facing API endpoints
  • Game services needing low latency but high attack resistance
  • Hybrid architectures where the public ingress is on Alibaba Cloud but backend is mixed

Real-world deployment contexts

  • Production: primary use case; DDoS protection is most important for customer-facing availability.
  • Dev/test: commonly limited, because attacks are usually targeted at production; however, teams may test configuration, alerting, and runbooks in staging (without generating real DDoS traffic).

5. Top Use Cases and Scenarios

Below are realistic scenarios where Anti-DDoS Origin is commonly a fit. For each: problem → why this service → example.

1) Protect a public API endpoint on ECSProblem: API becomes unreachable during TCP SYN floods or UDP floods that exhaust connection tracking. – Why Anti-DDoS Origin fits: Upstream L3/L4 mitigation reduces malicious traffic reaching the ECS public IP/EIP. – Example: A mobile app API on api.example.com backed by ECS instances and a public IP needs availability during promotion days.

2) Reduce blackhole risk for critical IPsProblem: During large attacks, upstream networks may blackhole traffic to protect infrastructure, causing downtime. – Why it fits: Higher protection capacity can reduce the likelihood of blackholing (exact behavior depends on provider/region—verify). – Example: A payment callback IP must remain reachable to complete transactions.

3) Protect game servers (UDP-heavy traffic)Problem: Attackers send UDP floods that saturate bandwidth and disrupt sessions. – Why it fits: DDoS mitigation targets volumetric UDP floods more effectively than host-based filters. – Example: A multiplayer game with regional servers experiences recurring attacks after competitive events.

4) Protect a public load balancer frontendProblem: Load balancer listeners face bursts of malicious connections that degrade service. – Why it fits: Anti-DDoS Origin protection on the public-facing address reduces attack traffic before it hits the listener. – Example: A web platform uses a load balancer to distribute traffic to multiple ECS instances.

5) Protect B2B webhook receiversProblem: Public webhook endpoints are a stable target (always-on, predictable). – Why it fits: Keeps webhook ingestion reachable even under volumetric abuse. – Example: An ERP integration endpoint receives supplier notifications and must remain available.

6) Protect login and authentication endpoints from volumetric floodsProblem: Attackers flood authentication endpoints, impacting all users. – Why it fits: While credential abuse is L7, volumetric floods are L3/L4 and can be mitigated upstream. – Example: SSO gateway sees periodic L4 floods during high-profile campaigns.

7) Improve resilience for marketing campaign landing pagesProblem: DDoS during a product launch causes reputational damage. – Why it fits: Adds DDoS capacity at the edge; complements CDN/WAF strategies. – Example: A brand launch page is fronted by a load balancer and must stay up.

8) Protect “single IP” legacy services you can’t easily redesignProblem: Legacy systems are bound to one IP and one port; redesign is slow. – Why it fits: You can attach DDoS protection to the existing IP rather than refactor architecture. – Example: A manufacturing control portal runs on a fixed IP with strict partner allowlists.

9) Protect public endpoints used by IoT devicesProblem: IoT ingestion endpoints are attacked or abused; device connectivity suffers. – Why it fits: Stabilizes ingress against volumetric floods and malformed traffic spikes. – Example: Telemetry ingestion over TCP is targeted by random internet scanning and floods.

10) Meet contractual uptime commitmentsProblem: Customer SLAs require documented DDoS protection and incident processes. – Why it fits: Provides an explicit Security control that can be referenced in architecture reviews. – Example: A SaaS vendor includes DDoS protection as part of its security addendum.

11) Reduce operational noise during attacksProblem: Attacks trigger cascading alerts (CPU, connection errors, timeouts), overwhelming responders. – Why it fits: Upstream mitigation reduces symptom amplification and helps maintain stable baselines. – Example: An SRE team wants fewer false-positive incident pages during internet turbulence.

12) Protect multi-tenant platforms with shared ingressProblem: One tenant is targeted; shared infrastructure suffers. – Why it fits: Strengthens shared ingress and reduces blast radius from volumetric events. – Example: Multi-tenant API gateway and shared load balancer for multiple customers.


6. Core Features

Feature availability can vary by edition/region. Where specific knobs or dashboards differ, verify in official docs and in the Anti-DDoS console for your account/region.

6.1 Protected asset management (bind IP resources)

  • What it does: Lets you add/select public IP assets to protect under Anti-DDoS Origin.
  • Why it matters: DDoS protection is only effective for the assets actually covered.
  • Practical benefit: Consistent onboarding process for new public endpoints.
  • Caveats: Supported asset types can be limited (for example, EIP vs other public endpoints). Verify supported resources and regions.

6.2 DDoS detection and mitigation (L3/L4)

  • What it does: Detects DDoS patterns and applies mitigation measures in upstream infrastructure.
  • Why it matters: L3/L4 floods can overwhelm bandwidth and connection state before application defenses can react.
  • Practical benefit: Service availability under volumetric/protocol attacks.
  • Caveats: No DDoS solution can guarantee 100% availability for every conceivable attack size; mitigation capacity and upstream conditions matter.

6.3 Attack event visibility and reporting

  • What it does: Provides event records and dashboards (attack time window, traffic peaks, vectors).
  • Why it matters: You need evidence for postmortems, tuning, and communicating with stakeholders.
  • Practical benefit: Faster diagnosis and better incident reports.
  • Caveats: Granularity of reports varies by edition; some deep analytics may require additional services or logs (verify).

6.4 Traffic and baseline monitoring

  • What it does: Shows normal traffic baselines vs suspicious spikes for protected assets.
  • Why it matters: Baselines help you pick thresholds and detect anomalies early.
  • Practical benefit: Better tuning and earlier detection of slow-ramp attacks.
  • Caveats: Metrics can lag; treat dashboards as operational aids, not the sole source of truth.

6.5 Alerting and notifications (operations integration)

  • What it does: Notifies when attacks start/stop or thresholds are exceeded (often via Alibaba Cloud alerting channels).
  • Why it matters: DDoS incidents are time-sensitive; responders need prompt signals.
  • Practical benefit: Reduced MTTA (mean time to acknowledge).
  • Caveats: Confirm which channels are supported (SMS/email/webhook) and whether they require additional configuration.

6.6 Mitigation policy controls (thresholds / modes)

  • What it does: Depending on edition, may allow configuration of mitigation sensitivity, thresholds, or response modes.
  • Why it matters: Overly aggressive settings can block legitimate traffic; overly lax settings can allow attacks through.
  • Practical benefit: Tailor protection to workload patterns (APIs vs gaming vs streaming).
  • Caveats: Exact parameters differ by edition; always test in a safe environment and follow official guidance.

6.7 Blackhole management behavior (service continuity)

  • What it does: Helps manage how traffic is handled when attacks exceed certain capacities (conceptually: minimize time in blackhole).
  • Why it matters: Blackhole filtering is effectively downtime.
  • Practical benefit: Better survivability at higher attack volumes.
  • Caveats: Blackhole policies are influenced by upstream carriers and regional infrastructure—verify behaviors for your region and asset type.

6.8 Multi-IP / multi-asset coverage (edition dependent)

  • What it does: Allows protecting multiple IP assets under one purchased Anti-DDoS Origin instance/plan.
  • Why it matters: Platforms often have multiple public endpoints.
  • Practical benefit: Standardized protection across a fleet.
  • Caveats: There may be a maximum number of protected assets per instance/plan (verify).

6.9 Integrations with Alibaba Cloud governance/security tooling

  • What it does: Works alongside RAM (access control), ActionTrail (auditing), CloudMonitor (metrics/alerts), and other Security services.
  • Why it matters: DDoS protection must be operable and auditable.
  • Practical benefit: Fits enterprise Security and operations requirements.
  • Caveats: Not all integrations are automatic; some require manual setup.

7. Architecture and How It Works

7.1 High-level architecture

At a high level, Anti-DDoS Origin places Alibaba Cloud’s DDoS mitigation capability in front of (or upstream of) your public IP assets. Legitimate traffic is forwarded to the origin, while attack traffic is filtered/scrubbed.

Unlike proxy-based DDoS products (where you typically change DNS to point to a proxy IP), origin-based protection is generally bound to the IP asset itself (exact mechanics depend on product/region—verify).

7.2 Request / data / control flows

  • Data plane (traffic): 1. Internet clients send traffic to your public IP (EIP / public endpoint). 2. Anti-DDoS Origin detects anomalies and applies mitigation upstream. 3. Cleaned/allowed traffic reaches your protected asset and then your workload.

  • Control plane (configuration): 1. Admins configure Anti-DDoS Origin in the console/API. 2. Policies and protected asset bindings are applied to Alibaba Cloud’s mitigation infrastructure. 3. Events and metrics are published for monitoring and incident response.

7.3 Integrations with related services (common patterns)

  • ECS + EIP: Protect public IPs used by ECS workloads.
  • Load balancers: Protect public-facing listener endpoints.
  • WAF: Use WAF for Layer 7 attacks; keep Anti-DDoS Origin for volumetric/protocol attacks.
  • Cloud Firewall / Security Groups: Continue enforcing least privilege; DDoS protection doesn’t replace network policy.
  • CloudMonitor: Alarms on attack events/traffic spikes (verify metric names).
  • ActionTrail: Audit who changed protection settings (verify event sources).
  • Simple Log Service (SLS): Some teams centralize Security events into logs/SIEM (verify native export options for Anti-DDoS).

7.4 Dependency services (what it relies on)

  • Alibaba Cloud’s DDoS mitigation network and scrubbing capacity.
  • Your protected public IP resources (EIP/load balancer/public endpoints).
  • Optional: monitoring/auditing services for alerting and compliance evidence.

7.5 Security / authentication model

  • Access is controlled by RAM (Resource Access Management) policies.
  • Prefer:
  • Dedicated RAM roles/users for Security administration.
  • Least privilege policies (start from read-only for observers).
  • MFA and strong password policies for privileged accounts.

7.6 Networking model

  • Anti-DDoS Origin is designed for internet ingress to protected IPs.
  • It is not a substitute for:
  • Private network isolation (VPC design)
  • East-west microsegmentation
  • Application-layer protection (WAF/bot management)
  • Keep your public endpoints minimal: use load balancers, limit direct-to-ECS exposure when possible.

7.7 Monitoring / logging / governance considerations

  • Define:
  • “Attack detected” = incident? or just an alert?
  • Severity thresholds (bps/pps, duration, affected endpoints).
  • Build dashboards:
  • Attack events over time
  • Peak inbound bps/pps
  • Error rates at application level (APM)
  • Governance:
  • Tag Anti-DDoS instances and protected assets (env, owner, app, cost center).
  • Document runbooks: “What do we do when Anti-DDoS triggers?”

7.8 Simple architecture diagram (Mermaid)

flowchart LR
  U[Internet Users / Attack Traffic] --> P[Protected Public IP Asset]
  P --> A[Anti-DDoS Origin Mitigation]
  A --> O[Origin Workload\n(ECS / Load Balancer)]
  O --> APP[Application]

Conceptual note: actual traffic path representation depends on how Alibaba Cloud applies mitigation for your asset type/region. Use this as a mental model, and verify the exact flow in official docs.

7.9 Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Internet
    Legit[Legitimate Clients]
    Bad[Attack Sources / Botnets]
  end

  Legit --> Edge[Alibaba Cloud Network Edge]
  Bad --> Edge

  subgraph DDoSProtection[Anti-DDoS Origin]
    Detect[Detection & Fingerprinting]
    Scrub[Mitigation / Scrubbing]
    Events[Attack Events & Metrics]
  end

  Edge --> Detect --> Scrub --> PubIP[Protected Public Endpoint\n(EIP / LB Public IP)]
  PubIP --> LB[Load Balancer]
  LB --> ASG[ECS Fleet / Auto Scaling]
  ASG --> App[App Services]
  App --> DB[ApsaraDB / Data Stores]

  Events --> Mon[CloudMonitor Alarms]
  Events --> SOC[SecOps / SIEM\n(Verify export options)]
  Admin[RAM Admins] -->|Config| DDoSProtection
  Admin -->|Audit| Trail[ActionTrail]

8. Prerequisites

Account and billing

  • An Alibaba Cloud account with billing enabled.
  • Ability to purchase Security services (some editions may require real-name verification and/or enterprise verification—verify in your region).

Permissions / IAM (RAM)

You need RAM permissions to: – Manage Anti-DDoS Origin instances and protected assets. – View/modify relevant resources (EIP, ECS, Load Balancer) you intend to protect. – Configure alerts/notifications (if using CloudMonitor).

Practical recommendation – Create: – A SecurityAdmin RAM role/user with Anti-DDoS administrative permissions. – A SecurityObserver RAM role/user with read-only permissions. – Policy names can differ; verify the exact managed policy names in the RAM console (search for Anti-DDoS-related policies).

Regions and availability

  • Anti-DDoS Origin availability varies by region and by protected asset type.
  • Confirm:
  • Your target region supports Anti-DDoS Origin.
  • Your specific IP asset type (EIP vs LB vs other) is supported.
  • Official docs are the source of truth (see resources section).

Tools

  • Alibaba Cloud console access (web).
  • Optional:
  • Alibaba Cloud CLI (aliyun) if you plan to automate provisioning (verify that Anti-DDoS Origin APIs are exposed in your region/account).
  • SSH client for ECS (OpenSSH, PuTTY).

Quotas / limits

Common limits to check (varies by edition/region): – Number of protected IPs per instance/plan. – Maximum mitigation capacity purchased. – Limits on configuration changes (rate limits). – Alert quotas (SMS/notifications).

Prerequisite services for the lab

  • ECS instance (or an existing public endpoint).
  • EIP (Elastic IP Address) associated to ECS (recommended for a clear “public IP asset” example).
  • Security Group rules for inbound HTTP/SSH to validate reachability.

9. Pricing / Cost

Anti-DDoS Origin pricing can be edition-based and capacity-based, and it can vary by region. Alibaba Cloud frequently offers multiple tiers for DDoS protection across its product family, so treat the points below as a cost model guide and verify exact SKUs and prices in official pricing pages.

9.1 Pricing dimensions (typical)

Common dimensions you should expect (verify exact terms): – Edition / plan tier (different mitigation capability and features). – Protection capacity (often in Gbps and/or packets per second; sometimes “mitigation capacity” vs “clean bandwidth”). – Number of protected assets/IPs included. – Subscription duration (monthly/annual) and region. – Add-ons (advanced reporting, extended logs, additional IP slots—if offered).

9.2 Free tier / baseline protection

Alibaba Cloud commonly provides baseline DDoS protection for certain public IP resources (often referred to as Anti-DDoS Basic). Anti-DDoS Origin is typically chosen when baseline protection is insufficient.

  • Do not assume baseline protection levels; they vary by product, region, and time.
  • Confirm your current baseline DDoS coverage in the console and official docs.

9.3 Cost drivers (what makes it more expensive)

  • Higher mitigation/cleaning capacity
  • More protected IP assets
  • Higher-tier editions with richer analytics and controls
  • More regions or more public endpoints

9.4 Hidden or indirect costs

Even if Anti-DDoS Origin itself is a predictable subscription: – Bandwidth costs on your origin (legitimate traffic still reaches you). – Load balancer costs and scaling costs under flash crowds (not DDoS). – Logging/monitoring costs if you export events or keep long retention. – Operational costs: on-call rotations, incident tooling.

9.5 Network / data transfer implications

  • DDoS mitigation aims to reduce malicious traffic reaching your assets, but:
  • Some attack traffic may still reach your origin depending on attack type and mitigation behavior.
  • Your legitimate traffic is unaffected in intent, but latency can vary during mitigation events.

9.6 How to optimize cost

  • Protect only critical ingress IPs (avoid “protect everything” without prioritization).
  • Use load balancers and reduce direct-to-ECS exposure to minimize the number of public IPs.
  • Use CDN + WAF for web apps to offload and reduce exposure (DDoS and L7 controls are complementary).
  • Right-size mitigation capacity based on:
  • Historical attacks
  • Industry norms
  • Business impact analysis

9.7 Example low-cost starter estimate (non-numeric)

A minimal starter footprint usually looks like: – 1 region – 1 protected IP (EIP or LB public IP) – A lower-tier Anti-DDoS Origin plan sufficient for small services

Because prices vary by region/edition and may be promotional or contract-based, verify the exact monthly cost on the official pricing page for your region.

9.8 Example production cost considerations (non-numeric)

For production, cost planning should include: – Multiple protected endpoints (API, web, webhook, admin) – Higher mitigation capacity aligned to your risk profile – Redundancy via multi-zone application design (Anti-DDoS doesn’t replace HA) – Monitoring/alerting integrations and log retention

9.9 Official pricing references

Use official Alibaba Cloud sources to confirm: – Product packaging and editions – Regional price differences – Contract/enterprise pricing options

Start here (verify the exact Anti-DDoS Origin pricing page for your region): – Alibaba Cloud Anti-DDoS product entry: https://www.alibabacloud.com/product/anti-ddos
– Alibaba Cloud Pricing (general): https://www.alibabacloud.com/pricing
– Alibaba Cloud Pricing Calculator: https://www.alibabacloud.com/pricing/calculator

If the Anti-DDoS Origin pricing link in your region differs, use the console “Buy” flow to view the authoritative SKU list.


10. Step-by-Step Hands-On Tutorial

This lab focuses on a realistic, safe workflow: protect a simple public endpoint (ECS + EIP) with Anti-DDoS Origin, verify protection attachment and monitoring, and prepare incident-ready alerting. It does not attempt to generate real DDoS traffic (unsafe and often a policy violation).

Objective

  • Create a small internet-facing service on ECS.
  • Associate an EIP and confirm reachability.
  • Purchase/enable Anti-DDoS Origin.
  • Add the EIP as a protected asset.
  • Configure basic alerting and validate visibility.
  • Document a minimal runbook and clean up resources.

Lab Overview

You will: 1. Provision an ECS instance and EIP, deploy a simple web server. 2. Confirm normal traffic works (curl). 3. Enable Anti-DDoS Origin and bind the EIP. 4. Confirm the protection status and review dashboards. 5. Configure monitoring/notifications for attack events (where supported). 6. Clean up to avoid ongoing charges.

Cost note: ECS, EIP, and Anti-DDoS Origin may all generate costs. Choose the smallest ECS size and shortest Anti-DDoS subscription available in your region, and delete resources after the lab.


Step 1: Create a small ECS instance (public endpoint)

  1. In the Alibaba Cloud console, go to Elastic Compute Service (ECS).
  2. Click Create Instance.
  3. Choose: – Region close to you (and where Anti-DDoS Origin is available). – A low-cost instance type. – An OS you are comfortable with (e.g., Alibaba Cloud Linux / CentOS / Ubuntu).
  4. Configure networking: – Place the instance in a VPC. – Do not assign a public IP during creation (we will attach an EIP for clarity).
  5. Configure Security Group rules: – Allow inbound TCP 22 from your IP (SSH). – Allow inbound TCP 80 from 0.0.0.0/0 (HTTP) for a simple test server.
  6. Create and start the instance.

Expected outcome – An ECS instance is running and reachable via private IP within the VPC. – Security Group allows SSH and HTTP as configured.


Step 2: Allocate and associate an Elastic IP (EIP)

  1. Go to Elastic IP Address (EIP) in the console.
  2. Click Create EIP.
  3. Select: – The same region as ECS. – Bandwidth billing model appropriate for your region (often pay-by-traffic or pay-by-bandwidth—verify).
  4. After allocation, click the EIP and choose Associate.
  5. Associate it with your ECS instance.

Expected outcome – Your ECS instance now has a stable public IP (the EIP).

Verify – From your local machine:

ping -c 3 <YOUR_EIP>

Ping may be blocked by Security Group/ICMP settings; HTTP will be your primary validation.


Step 3: Install a simple web server on ECS

SSH into the instance:

ssh root@<YOUR_EIP>

Install NGINX (commands vary by OS; below are common examples—use the correct one for your distribution).

Ubuntu/Debian:

apt update
apt -y install nginx
systemctl enable --now nginx

RHEL/CentOS/Alibaba Cloud Linux (may vary):

yum -y install nginx
systemctl enable --now nginx

Create a simple landing page:

cat >/usr/share/nginx/html/index.html <<'EOF'
<h1>Anti-DDoS Origin Lab</h1>
<p>If you can read this, HTTP reachability is working.</p>
EOF

Expected outcome – NGINX is running and serving HTTP.

Verify from your local machine

curl -i http://<YOUR_EIP>/

You should see HTTP/1.1 200 OK.


Step 4: Purchase/enable Anti-DDoS Origin

  1. In the Alibaba Cloud console, search for Anti-DDoS and open the Anti-DDoS service console.
  2. Locate Anti-DDoS Origin.
  3. Click Buy (or Upgrade/Enable) and choose: – Region (same as your EIP). – Edition/tier. – Protection capacity and number of protected assets (start minimal). – Subscription term (choose short term for the lab if possible).

Expected outcome – An Anti-DDoS Origin instance/plan is active in your account.

Important – If the console offers multiple products (e.g., Anti-DDoS Proxy vs Origin), ensure you choose Origin as required. – If you do not see Anti-DDoS Origin in your region, verify regional availability and try a supported region.


Step 5: Add the EIP as a protected asset

  1. In the Anti-DDoS Origin console, find the section for Protected Assets (name may vary).
  2. Click Add or Bind Asset.
  3. Select your EIP (or enter the public IP if required).
  4. Confirm and apply.

Expected outcome – The EIP appears in the protected asset list with a protection status such as “Protected/Enabled” (wording varies).

Verify – Re-run:

curl -i http://<YOUR_EIP>/

Your website should still respond normally.

What you’re validating here – Anti-DDoS Origin is not breaking legitimate traffic. – The protected asset binding is active.


Step 6: Review attack visibility dashboards (baseline)

  1. In Anti-DDoS Origin console, open: – OverviewTraffic/MonitoringAttack Events/Reports
  2. Confirm your protected IP is listed.
  3. Note baseline inbound traffic and current status.

Expected outcome – You can view baseline traffic metrics for the protected EIP. – No active attack events (assuming normal conditions).


Step 7: Configure alerting for attack events (recommended)

Alerting configuration differs by Alibaba Cloud region and account setup. Commonly, you will use: – Built-in Anti-DDoS notifications, and/or – CloudMonitor alarms, and/or – Notification contacts/channels.

Proceed as follows:

  1. In Anti-DDoS Origin console, look for Notifications/Alerts settings.
  2. Add at least one notification recipient (email/SMS) if supported.
  3. In CloudMonitor, look for Anti-DDoS-related metrics/events and create an alarm rule (metric names vary—verify).
  4. Set a practical alarm policy: – Attack detected (event-based) – Inbound traffic exceeds baseline by X (metric-based; choose cautiously to avoid false positives)

Expected outcome – Alerts are configured so your team is notified when an attack event occurs.

Verification – If the console provides a “Send test notification” option, use it. – Otherwise, confirm alarm rule is created and in “Enabled” state.


Validation

Use this checklist:

  1. Service reachabilitycurl http://<YOUR_EIP>/ returns 200 OK.
  2. Protected asset status – The EIP shows as protected in Anti-DDoS Origin console.
  3. Visibility – Traffic metrics are visible for the EIP in Anti-DDoS Origin.
  4. Operational readiness – Alerts are configured and enabled. – You documented:
    • Asset list
    • Owner/on-call contact
    • What constitutes an incident
    • Where to check attack reports

Troubleshooting

Issue: I can’t find Anti-DDoS Origin in the console – Confirm you are in the correct region. – Confirm your account has permission to view/purchase Security products. – Check the Anti-DDoS product page for region support. – If your organization uses a reseller/enterprise contract, confirm product enablement with your account team.

Issue: EIP doesn’t appear in protected asset selection – Ensure the EIP is: – In the same region as Anti-DDoS Origin instance/plan – In a supported state (allocated/associated as required) – Verify supported asset types for Anti-DDoS Origin.

Issue: Website stopped working after enabling protection – Re-check: – Security Group inbound rules (TCP 80) – NGINX status on ECS (systemctl status nginx) – Whether you accidentally protected the wrong IP – If Anti-DDoS Origin has policy knobs (threshold/mode), revert to default and verify.

Issue: CloudMonitor doesn’t show Anti-DDoS metrics – Metric availability varies. Verify in official docs: – Whether Anti-DDoS Origin publishes CloudMonitor metrics in your edition/region – Whether you need to enable a setting to export metrics/events

Issue: SSH is blocked – Ensure Security Group allows TCP 22 from your public IP. – Verify you are using the correct username for your OS image.


Cleanup

To avoid charges, clean up in reverse order:

  1. Remove protected asset binding (optional but tidy): – In Anti-DDoS Origin console, remove the EIP from protected assets if your workflow requires explicit unbinding.
  2. Cancel/disable Anti-DDoS Origin subscription – Follow the console billing/subscription cancellation flow (note: refunds and early termination policies vary—verify).
  3. Release EIP – Disassociate the EIP from ECS, then release it.
  4. Delete ECS instance – Ensure disk snapshots or additional disks are handled according to your needs.

11. Best Practices

Architecture best practices

  • Prefer load balancers for public ingress, not direct-to-ECS exposure.
  • Minimize public IP footprint: fewer exposed IPs means fewer assets to protect and less configuration drift.
  • Use multi-zone application design (load balancers, multiple ECS instances, managed databases). DDoS protection is not a substitute for HA.
  • Combine Anti-DDoS Origin (L3/L4) with WAF (L7) for web applications.

IAM / Security best practices

  • Enforce least privilege with RAM:
  • Separate admin and observer roles.
  • Use MFA for privileged users.
  • Use ActionTrail to audit configuration changes.
  • Require change management for:
  • Adding/removing protected assets
  • Changing mitigation settings
  • Altering alerting recipients

Cost best practices

  • Protect critical endpoints first (payment, login, API gateway).
  • Consolidate ingress behind a small set of public IPs (load balancer + domain routing).
  • Regularly review protected asset inventory for stale IPs.

Performance best practices

  • Keep application and infrastructure scalable:
  • Autoscaling where applicable
  • Connection limits tuned
  • Health checks and timeouts set appropriately
  • Ensure your monitoring distinguishes between:
  • Flash crowd (legitimate surge)
  • DDoS (malicious surge)

Reliability best practices

  • Maintain a DDoS runbook:
  • Where to check attack events
  • Who to contact internally
  • How to communicate to customers
  • Define incident severity based on:
  • Duration
  • Impacted endpoints
  • Error budgets/SLOs

Operations best practices

  • Use tags: env=prod, app=api, owner=platform, costcenter=1234.
  • Create dashboards that correlate:
  • Anti-DDoS events
  • Load balancer metrics
  • ECS metrics
  • Application error rate

Governance / naming best practices

  • Naming convention example:
  • addos-origin-prod-core-ingress
  • addos-origin-staging-api
  • Track protected assets in a CMDB or IaC code repository.

12. Security Considerations

Identity and access model

  • Controlled by RAM.
  • Recommended controls:
  • Dedicated Security admin role
  • Read-only role for auditors and on-call engineers
  • MFA on privileged accounts
  • No shared accounts; individual identities only

Encryption

  • Anti-DDoS Origin primarily addresses network-layer availability. Encryption considerations typically apply to:
  • Your application traffic (TLS termination on LB or NGINX)
  • Logs and exports (SLS/SIEM)
  • Ensure TLS is configured end-to-end as appropriate. Anti-DDoS does not replace TLS.

Network exposure

  • DDoS protection reduces risk of availability loss, but you must still:
  • Restrict inbound ports to only what you need
  • Use Security Groups and Cloud Firewall policies
  • Avoid exposing SSH/RDP broadly to the internet

Secrets handling

  • Keep secrets out of user data scripts and public repos.
  • Use Alibaba Cloud secret management approaches where available (service choice depends on your stack—verify current offerings).

Audit / logging

  • Enable ActionTrail for audit logging of configuration changes.
  • Keep logs long enough for:
  • Compliance requirements
  • Post-incident analysis
  • Ensure alert recipients are maintained and reviewed (on-call rotation changes).

Compliance considerations

  • Availability is commonly part of Security frameworks (CIA triad).
  • For regulated workloads, document:
  • DDoS control ownership
  • Monitoring procedures
  • Incident response plan
  • Use official Alibaba Cloud compliance documentation for your region (verify applicable certifications and scope).

Common security mistakes

  • Assuming DDoS protection replaces WAF or Firewall rules.
  • Leaving direct-to-ECS services exposed unnecessarily.
  • No alerting configured; relying only on “someone will notice”.
  • Overprotecting non-critical IPs while underprotecting core ingress.

Secure deployment recommendations

  • Front web workloads with:
  • Load balancer + WAF (for L7) + Anti-DDoS Origin (for L3/L4)
  • Restrict management access:
  • SSH only from bastion/VPN/IP allowlist
  • Maintain tested incident playbooks.

13. Limitations and Gotchas

These are common constraints and operational surprises. Always validate your exact constraints in official docs and in your region.

Known limitations / constraints (typical)

  • Region and asset-type support: not every region or resource type may be supported.
  • Primarily L3/L4 focus: application-layer attacks often require WAF/bot controls.
  • Capacity matters: if attack volume exceeds purchased mitigation capacity (or upstream constraints), service impact can still occur.
  • Visibility granularity varies: deep packet/forensics data may not be available in all tiers.

Quotas (examples to verify)

  • Maximum number of protected IPs per plan/instance.
  • Maximum mitigation capacity you can purchase.
  • Rate limits on API/console changes.

Regional constraints

  • Product availability and editions differ by region.
  • Blackhole policies and thresholds can differ due to upstream carriers and infrastructure—verify.

Pricing surprises

  • Subscription auto-renewal if enabled.
  • EIP and bandwidth charges independent of Anti-DDoS Origin.
  • Additional costs for monitoring/log retention.

Compatibility issues

  • If your architecture depends on third-party DDoS/CDN services, confirm how they interact with your Alibaba Cloud ingress.
  • Some traffic engineering patterns (Anycast, multi-CDN, complex DNS failover) require careful design—verify compatibility.

Operational gotchas

  • Not updating alert recipients after team changes.
  • Not documenting which IPs are protected and why.
  • Treating every attack alert as a Sev-1 incident (alert fatigue).

Migration challenges

  • Moving from direct public IPs to load balancers changes the set of protected assets and may require reconfiguration.
  • If you reassign EIPs, confirm protection bindings follow the correct IP.

Vendor-specific nuances

  • Alibaba Cloud’s DDoS product family includes multiple offerings (Basic, Origin, Proxy). Selecting the wrong one leads to mismatched expectations (proxy vs origin binding).

14. Comparison with Alternatives

Anti-DDoS Origin is one tool in a broader availability and Security strategy. Compare it with nearby Alibaba Cloud services and similar services in other clouds.

Comparison table

Option Best For Strengths Weaknesses When to Choose
Alibaba Cloud Anti-DDoS Origin Protecting Alibaba Cloud public IP assets at L3/L4 Managed upstream mitigation; binds to origin assets; operational visibility Not a full L7 security solution; edition/region constraints You need DDoS protection for public IPs on Alibaba Cloud workloads
Alibaba Cloud Anti-DDoS Basic Baseline protection for many public resources Often enabled by default; no extra setup (varies) Lower protection capability; limited controls/visibility Small workloads and low-risk endpoints; as baseline for all workloads
Alibaba Cloud Anti-DDoS Proxy Proxy-based protection (often for websites/services where traffic can be routed through proxy) Can protect via proxying; may add L7 protections depending on offering Requires traffic redirection (DNS/IP changes); architectural impact You need proxy-based scrubbing and can route traffic through proxy endpoints
Alibaba Cloud WAF Application-layer security (HTTP/HTTPS) L7 protections (OWASP, bots/rules); virtual patching Doesn’t replace upstream L3/L4 DDoS mitigation You need L7 protection; use with Anti-DDoS Origin for defense-in-depth
Alibaba Cloud Cloud Firewall Centralized network access control Unified policy, segmentation, visibility Not a DDoS scrubbing service You need network governance and filtering, not DDoS mitigation
AWS Shield (Standard/Advanced) DDoS protection on AWS Strong integration with AWS edge and services AWS-only; pricing differs Your workloads are on AWS
Azure DDoS Protection DDoS protection on Azure VNets Native Azure integration Azure-only Your workloads are on Azure
Google Cloud Armor Edge security and WAF + some DDoS defenses Integrates with Google edge GCP-only Your workloads are on GCP
Self-managed appliances / iptables Small-scale filtering, custom control Full control; can block some patterns Not effective for large volumetric attacks; costly to scale You only need minor filtering or have upstream scrubbing elsewhere

15. Real-World Example

15.1 Enterprise example (regulated SaaS platform)

Problem A multi-tenant B2B SaaS platform hosts customer portals and APIs on Alibaba Cloud. The platform experienced repeated L4 floods against public API endpoints, causing intermittent timeouts and forcing emergency scaling.

Proposed architecture – Public ingress via a load balancer (single/few public IPs). – Anti-DDoS Origin enabled for the load balancer public endpoint (and any other critical public IPs). – WAF in front of web portals (for L7 threats). – CloudMonitor alarms for attack events + SRE dashboards correlating: – Anti-DDoS events – LB connections – API error rates – ActionTrail enabled for audit and change control.

Why Anti-DDoS Origin was chosen – Native alignment with Alibaba Cloud public IP assets. – Upstream L3/L4 mitigation to reduce impact before the load balancer and ECS fleet. – Centralized visibility suitable for incident postmortems and compliance reporting.

Expected outcomes – Reduced outage frequency during volumetric attacks. – Lower operational overhead during attacks due to clearer event telemetry. – Improved compliance posture by documenting availability controls and auditability.

15.2 Startup / small-team example (gaming backend)

Problem A small game studio runs regional game servers on ECS with EIPs. After release, attackers repeatedly targeted UDP ports to disrupt matches.

Proposed architecture – Keep ECS game servers but reduce exposure: – Only required UDP/TCP ports open. – Add Anti-DDoS Origin for the EIPs used by game servers (or consolidate behind a front door where feasible). – Establish on-call alerts and a simple runbook. – Add rate limiting and protocol hardening at the application level (not a DDoS solution, but reduces resource exhaustion).

Why Anti-DDoS Origin was chosen – Faster than redesigning to a proxy-based architecture. – Provides upstream mitigation without building custom scrubbing. – Small team benefits from managed Security controls.

Expected outcomes – Higher match availability during floods. – Faster triage using attack event dashboards. – More predictable incident response without deep network expertise.


16. FAQ

1) What does Anti-DDoS Origin protect?
It protects eligible public IP assets (such as EIPs or public endpoints of supported Alibaba Cloud resources) against DDoS attacks, primarily at Layer 3/Layer 4. Verify supported asset types and regions in official docs.

2) Is Anti-DDoS Origin the same as Anti-DDoS Proxy?
No. Anti-DDoS Origin is generally bound to origin IP assets. Anti-DDoS Proxy typically involves routing traffic through proxy addresses (often requiring DNS changes). Choose based on your architecture and requirements.

3) Does Anti-DDoS Origin stop all DDoS attacks?
No service can guarantee stopping all attacks under all conditions. Effectiveness depends on attack type, scale, purchased capacity, and upstream conditions. Use defense-in-depth.

4) Will Anti-DDoS Origin protect against application-layer attacks (HTTP floods)?
Anti-DDoS Origin is mainly for L3/L4. Some editions may include additional protections, but for HTTP-layer threats you typically use WAF and bot mitigation. Verify feature scope by edition.

5) Do I need to change DNS to use Anti-DDoS Origin?
Often, origin-bound protection does not require DNS changes because it protects the IP itself. However, exact onboarding depends on resource type and product mechanics—verify in your region.

6) Can I protect multiple IPs with one Anti-DDoS Origin plan?
Many offerings allow multiple protected assets, but limits vary by plan/edition. Check your SKU details.

7) Does Anti-DDoS Origin add latency?
Any mitigation system can add some latency during attack conditions. Under normal traffic, impact is typically minimal, but you should measure and set expectations.

8) How do I know it’s working if I’m not under attack?
You validate configuration (protected asset status), ensure normal traffic works, and verify metrics/alerts are active. You generally should not simulate real DDoS.

9) What happens if an attack exceeds my protection capacity?
Service degradation or blackhole filtering can occur depending on upstream policies and thresholds. Plan capacity based on risk and consider architectural mitigations (CDN, multi-region, etc.).

10) Does Anti-DDoS Origin replace Security Groups or Cloud Firewall?
No. DDoS protection addresses availability under attack traffic. Security Groups/Cloud Firewall enforce access policies and segmentation.

11) How do I grant a SOC team read-only access?
Create a RAM role/user with read-only permissions for Anti-DDoS and relevant monitoring services. Verify the correct managed policies or create a custom least-privilege policy.

12) Can I automate Anti-DDoS Origin configuration with IaC?
Possibly, depending on available APIs and Terraform provider support. Verify current API support and official provider documentation.

13) Is Anti-DDoS Origin regional or global?
Configuration is usually regional because IP assets are regional, but protection operates against global internet threats. Always confirm regional support for your assets.

14) How does Anti-DDoS Origin interact with CDN?
CDN can absorb and distribute traffic for web content, while Anti-DDoS Origin protects the underlying public endpoints. For web apps, CDN + WAF + DDoS protection is a common layered approach.

15) What should I monitor during an attack?
Monitor: – Anti-DDoS attack events (start/stop, peak rates) – Load balancer connection metrics – Application error rate and latency – Backend resource saturation
Correlate to avoid scaling in response to malicious traffic alone.

16) Can I use Anti-DDoS Origin for on-prem servers?
Anti-DDoS Origin is designed for Alibaba Cloud origin assets. For non-Alibaba assets, proxy-based solutions or third-party scrubbing may be required—verify options.

17) How quickly can I enable it in an incident?
Time-to-enable depends on procurement and binding steps. For critical services, enable it proactively rather than waiting for an incident.


17. Top Online Resources to Learn Anti-DDoS Origin

Resource Type Name Why It Is Useful
Official product page Alibaba Cloud Anti-DDoS High-level overview and entry point to documentation: https://www.alibabacloud.com/product/anti-ddos
Official documentation Alibaba Cloud Help Center (Anti-DDoS) Primary source for capabilities, supported assets, regions, and guides (navigate to Anti-DDoS Origin within): https://www.alibabacloud.com/help
Official pricing Alibaba Cloud Pricing Canonical place to confirm pricing model and SKU differences: https://www.alibabacloud.com/pricing
Pricing calculator Alibaba Cloud Pricing Calculator Estimate total cost including dependent services: https://www.alibabacloud.com/pricing/calculator
Console Alibaba Cloud Console Validate actual region availability, editions, and configuration workflow: https://home.console.alibabacloud.com/
Governance ActionTrail documentation Audit who changed Anti-DDoS configurations (verify service event coverage): https://www.alibabacloud.com/help/en/actiontrail
Monitoring CloudMonitor documentation Alarm setup and operational monitoring patterns: https://www.alibabacloud.com/help/en/cloudmonitor
Application security WAF documentation L7 protection to complement Anti-DDoS Origin: https://www.alibabacloud.com/help/en/web-application-firewall
Network policy Cloud Firewall documentation Central network policy management: https://www.alibabacloud.com/help/en/cloud-firewall
Community learning Alibaba Cloud Tech Community Practical posts and operational tips (validate against official docs): https://www.alibabacloud.com/blog

18. Training and Certification Providers

Institute Suitable Audience Likely Learning Focus Mode Website URL
DevOpsSchool.com DevOps, SRE, Cloud engineers, Security practitioners Cloud operations, DevSecOps practices, platform labs (verify course catalog) Check website https://www.devopsschool.com/
ScmGalaxy.com Beginners to intermediate engineers DevOps fundamentals, tooling, process, and practical labs Check website https://www.scmgalaxy.com/
CLoudOpsNow.in Cloud operations teams CloudOps/SRE operations practices and automation Check website https://www.cloudopsnow.in/
SreSchool.com SREs, platform engineers Reliability engineering, monitoring, incident response Check website https://www.sreschool.com/
AiOpsSchool.com Ops teams adopting AIOps AIOps concepts, monitoring automation, incident analytics Check website https://www.aiopsschool.com/

19. Top Trainers

Platform/Site Likely Specialization Suitable Audience Website URL
RajeshKumar.xyz DevOps/cloud training content (verify current offerings) Engineers looking for practical guidance https://rajeshkumar.xyz/
devopstrainer.in DevOps training programs Beginners to working professionals https://www.devopstrainer.in/
devopsfreelancer.com Freelance DevOps enablement and training resources Small teams and startups https://www.devopsfreelancer.com/
devopssupport.in DevOps support/training resources Ops/DevOps teams needing hands-on assistance https://www.devopssupport.in/

20. Top Consulting Companies

Company Likely Service Area Where They May Help Consulting Use Case Examples Website URL
cotocus.com Cloud/DevOps consulting (verify service lines) Architecture reviews, operations improvements, automation DDoS readiness assessment, monitoring/runbook implementation, cloud migration planning https://cotocus.com/
DevOpsSchool.com DevOps and cloud consulting/training DevSecOps pipelines, SRE practices, platform enablement Security controls integration, incident response runbooks, observability rollout https://www.devopsschool.com/
DEVOPSCONSULTING.IN DevOps consulting services Delivery automation, infrastructure operations IaC implementation, CI/CD hardening, production reliability improvements https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Anti-DDoS Origin

  • Networking fundamentals:
  • IP addressing, TCP/UDP, ports, NAT
  • L3 vs L4 vs L7 concepts
  • DDoS basics:
  • Volumetric attacks (UDP floods, amplification)
  • Protocol attacks (SYN floods)
  • Application-layer floods (HTTP)
  • Alibaba Cloud essentials:
  • ECS, VPC, EIP
  • Load balancers
  • Security Groups and RAM

What to learn after Anti-DDoS Origin

  • WAF tuning (rules, bot mitigation, rate limiting)
  • Cloud Firewall policy management and segmentation
  • Observability:
  • CloudMonitor dashboards and alarms
  • Central logging and incident workflows
  • Resilient architectures:
  • Multi-zone deployments
  • Disaster recovery planning
  • Incident management (postmortems, error budgets)

Job roles that use it

  • Cloud Security Engineer
  • SRE / Site Reliability Engineer
  • Cloud/Platform Engineer
  • DevOps Engineer
  • Solutions Architect
  • Security Operations (SecOps) Analyst (visibility and response)

Certification path (if available)

Alibaba Cloud certification tracks and names change over time. If you are pursuing Alibaba Cloud certifications: – Start with foundational cloud certifications. – Add Security-focused learning modules that include network Security, WAF, and DDoS fundamentals.
Verify current Alibaba Cloud certification paths on official Alibaba Cloud training/certification pages.

Project ideas for practice

  • Build a “public API reference architecture”:
  • LB + ECS + WAF + Anti-DDoS Origin + CloudMonitor + ActionTrail
  • Create an incident runbook repository:
  • Alert definitions
  • Triage steps
  • Communication templates
  • Implement least-privilege RAM roles for:
  • Security admin
  • Operator
  • Auditor
  • Cost governance:
  • Tagging policy and monthly protected asset review

22. Glossary

  • DDoS (Distributed Denial of Service): An attack where many sources overwhelm a target with traffic, causing service unavailability.
  • L3 (Layer 3): Network layer (IP routing).
  • L4 (Layer 4): Transport layer (TCP/UDP). Many volumetric and protocol attacks occur here.
  • L7 (Layer 7): Application layer (HTTP/HTTPS). Typically handled by WAF and bot controls.
  • ECS: Elastic Compute Service (Alibaba Cloud virtual machines).
  • EIP: Elastic IP Address (public IP that can be associated to cloud resources).
  • Security Group: Virtual firewall rules attached to ECS/network interfaces controlling inbound/outbound traffic.
  • Mitigation/Scrubbing: Filtering and cleaning malicious traffic so legitimate traffic can pass.
  • Blackhole filtering: Dropping traffic to an IP entirely when attack volume exceeds certain thresholds, effectively causing downtime.
  • RAM: Resource Access Management (Alibaba Cloud IAM).
  • ActionTrail: Service that records API calls and account activity for auditing.
  • CloudMonitor: Alibaba Cloud monitoring and alerting service.
  • WAF: Web Application Firewall; protects web applications from L7 threats.
  • SLO/SLA: Service Level Objective/Agreement; uptime and performance targets/commitments.

23. Summary

Alibaba Cloud Anti-DDoS Origin is a Security service designed to protect public-facing origin IP assets from DDoS attacks, primarily at Layer 3/Layer 4. It matters because DDoS is fundamentally an availability threat, and upstream mitigation is often the difference between a degraded service and a full outage.

In Alibaba Cloud architectures, Anti-DDoS Origin typically sits alongside Security Groups/Cloud Firewall (access control) and WAF (application-layer protection) to form defense-in-depth for internet-facing workloads. Cost is usually driven by edition and protection capacity plus the number of protected assets, and you should always validate region/SKU pricing in the official pricing pages and console.

Use Anti-DDoS Origin when you run critical public endpoints and need managed DDoS mitigation without redesigning traffic to a proxy. Next, strengthen your overall posture by integrating monitoring (CloudMonitor), auditability (ActionTrail), and layered protections (WAF, firewall policy), and by practicing incident runbooks in staging.