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

1. Introduction

Alibaba Cloud Anti-DDoS Proxy is a managed DDoS mitigation service that helps keep Internet-facing applications online during volumetric and protocol/application-layer distributed denial-of-service (DDoS) attacks by advertising protected IPs, ingesting attack traffic, scrubbing malicious packets/requests, and forwarding clean traffic to your origin.

In simple terms: you place Anti-DDoS Proxy in front of your public service (websites, APIs, game servers, TCP/UDP services). Users connect to an Anti-DDoS Proxy address, and the service relays legitimate traffic to your real servers while absorbing attacks.

Technically, Anti-DDoS Proxy works as a combination of traffic diversion + scrubbing + proxy/forwarding. You bind your asset (IP/port and sometimes domain) to an Anti-DDoS Proxy instance. When attacks occur, Alibaba Cloud’s mitigation network identifies malicious patterns at L3/L4 and (where supported) L7, applies filtering and rate controls, and forwards only validated traffic to your origin via configured forwarding rules.

The problem it solves: DDoS attacks can saturate bandwidth, exhaust connection tables, overwhelm load balancers, or burn CPU with floods of requests—taking services offline. Anti-DDoS Proxy provides specialized capacity and defense logic so you don’t have to build and operate scrubbing infrastructure yourself.

Naming note (verify in official docs): Alibaba Cloud has historically offered DDoS protection under multiple product/edition names (for example “Anti-DDoS Pro” and “Anti-DDoS Premium”). In many regions and documentation sets, these capabilities are now organized under Anti-DDoS Proxy. Always confirm the exact edition names and feature matrix in the current Alibaba Cloud documentation for your region.

2. What is Anti-DDoS Proxy?

Official purpose

Anti-DDoS Proxy is an Alibaba Cloud Security service designed to protect public-facing services from DDoS attacks by providing dedicated mitigation resources and proxy-based forwarding so that your origin IPs can remain stable (and, ideally, less exposed).

Core capabilities (high-level)

Anti-DDoS Proxy typically provides:

DDoS traffic scrubbing for common L3/L4 flood types (for example SYN/ACK floods, UDP floods, ICMP floods) and certain application-layer floods depending on configuration and edition.
Proxy/forwarding so clients connect to protected/proxy IPs (or domain-based routing) and clean traffic is forwarded to your origin server(s).
Configurable forwarding rules for TCP/UDP and (where supported) HTTP/HTTPS.
Monitoring, alerts, and attack reports to understand attack events and mitigation effectiveness.
API/automation (OpenAPI) for some lifecycle and configuration operations (verify the exact API coverage for Anti-DDoS Proxy in your region).

Major components (conceptual)

While UI names vary slightly by edition/region, Anti-DDoS Proxy deployments usually involve:

Anti-DDoS Proxy instance
The subscribed resource container with a defined mitigation capacity/edition.
Protected asset / protected object
The IP address(es) and/or domain(s) you want to protect.
Proxy (protected) IP / CNAME
The public entry point users connect to. You update DNS (or client configuration) to point to this.
Forwarding rule(s)
Port/protocol mapping (and sometimes domain mapping) that defines where clean traffic goes (origin IP, origin port, load balancer, etc.).
Origin
Your actual service endpoints: ECS public IP/EIP, Server Load Balancer, or non-Alibaba Cloud public IP (depending on supported origin types).
Observability & control plane
Console dashboards, attack events, metrics, and configuration APIs.

Service type

Managed security service (DDoS mitigation + proxy forwarding).
Typically subscription-based with edition/capacity SKUs (verify current billing methods available in your region).

Scope (regional/global/account)

This varies by product edition and region. Commonly: – The instance is purchased in a region and managed under your Alibaba Cloud account. – Scrubbing capacity may be delivered through Alibaba Cloud’s mitigation network with multiple scrubbing nodes (implementation detail; verify). – You manage configuration (protected assets, forwarding rules) within the scope of the instance.

Verify in official docs: Whether Anti-DDoS Proxy in your region is best described as regional, global, or “global access with regional purchase,” and what constraints exist around protected IP geographies.

How it fits into the Alibaba Cloud ecosystem

Anti-DDoS Proxy is often deployed alongside: – ECS (Elastic Compute Service) or ACK (Container Service for Kubernetes) as the origin compute – Server Load Balancer (Classic/ALB/NLB depending on workload) – WAF (Web Application Firewall) for OWASP protections and bot management (Anti-DDoS Proxy is not a full WAF) – CloudMonitor for alarms/metrics – ActionTrail for audit logs – Log Service (SLS) if supported for event/log shipping (verify exact integration)

3. Why use Anti-DDoS Proxy?

Business reasons

Reduce downtime risk from DDoS incidents that can cause lost revenue, SLA penalties, and reputational damage.
Predictable preparedness: a subscribed mitigation service is often easier to justify than emergency response during an outage.
Faster incident response with centralized attack visibility and standard mitigation workflows.

Technical reasons

DDoS attacks can exceed the capacity of:
Your upstream ISP links
A single load balancer
Instance connection limits
NAT tables / stateful firewalls
Anti-DDoS Proxy provides specialized filtering and high-capacity mitigation upstream before traffic reaches your origins.

Operational reasons

Avoids building and maintaining:
Anycast/BGP diversion
Scrubbing clusters
DDoS playbooks and tuning at packet scale
Provides consistent controls for forwarding rules, protected objects, and reporting.

Security and compliance reasons

Helps meet organizational requirements for availability controls and resilience.
Provides centralized security telemetry that can support audit narratives (exact compliance attestations vary—verify current Alibaba Cloud compliance documentation).

Scalability and performance reasons

Preserves origin capacity for legitimate users.
Can reduce blast radius by hiding origin IPs (if you restrict origin access to Anti-DDoS Proxy back-to-origin addresses).

When teams should choose Anti-DDoS Proxy

Choose it when: – You run public Internet services with meaningful uptime requirements. – You have experienced DDoS attacks or operate in a high-risk industry (gaming, fintech, e-commerce, crypto, media, public sector). – You need protection for TCP/UDP services (non-HTTP) as well as web workloads. – You want a managed mitigation service integrated with Alibaba Cloud networking and Security tooling.

When teams should not choose it

Consider alternatives when: – Your workload is private/internal-only (no Internet exposure). – You only need basic DDoS defense and can rely on Alibaba Cloud’s baseline protections for certain resources (for example, basic DDoS protection for some public IP services—verify). – Your primary risk is application-layer vulnerabilities (SQL injection, XSS, account takeover). You likely need WAF, bot management, and secure coding; Anti-DDoS Proxy is not a complete application security solution. – Your architecture is best served by CDN edge caching + WAF (for static-heavy web) rather than generic proxying—often you’ll use both, depending on traffic patterns.

4. Where is Anti-DDoS Proxy used?

Industries

Gaming and esports (UDP/TCP game servers, matchmaking)
Financial services and payment gateways
E-commerce and flash sales
Media streaming platforms and ticketing
SaaS platforms and public APIs
Education and online exam platforms
Government/public services portals
Crypto exchanges and wallets (high DDoS frequency)

Team types

Security engineering / SOC
SRE and platform engineering
DevOps teams managing Internet ingress
Network engineering teams
Operations teams responsible for uptime/SLA

Workloads

Public REST/GraphQL APIs
Web frontends (HTTP/HTTPS)
Login/payment flows
TCP services (custom protocols, MQTT over TCP)
UDP services (games, streaming control planes)
DNS-dependent services that can repoint quickly

Architectures

Single-region origin protected by Anti-DDoS Proxy
Multi-region active/active with DNS-based failover
Anti-DDoS Proxy in front of load balancers (ALB/NLB/Classic SLB)
Hybrid: on-prem origin protected via Anti-DDoS Proxy forwarding (if supported)

Production vs dev/test usage

Production: common and recommended where uptime matters.
Dev/test: less common due to subscription cost and because DDoS is not typically tested in dev. However, it can be valuable to validate:
DNS cutover procedure
Back-to-origin allowlisting
TLS/certificate behavior
Observability and alerting

5. Top Use Cases and Scenarios

Below are realistic scenarios where Anti-DDoS Proxy is a strong fit.

1) Protect a public API endpoint (HTTP/HTTPS)

Problem: API is targeted by request floods, causing 5xx errors and timeouts.
Why it fits: Anti-DDoS Proxy provides upstream mitigation and forwarding, keeping origin stable.
Example: A mobile app backend api.example.com routes through Anti-DDoS Proxy, with origin behind an Alibaba Cloud load balancer.

2) Protect a TCP-based service (custom protocol)

Problem: Attackers flood TCP connections to exhaust server resources.
Why it fits: Anti-DDoS Proxy can protect TCP services via port forwarding rules.
Example: A chat service on TCP/5222 is fronted by Anti-DDoS Proxy IPs and forwarded to an origin NLB.

3) Protect UDP game servers

Problem: UDP floods saturate bandwidth and disrupt gameplay.
Why it fits: Anti-DDoS Proxy is commonly used for UDP forwarding (verify UDP feature availability in your edition).
Example: A multiplayer game uses Anti-DDoS Proxy for UDP/27015 traffic into a fleet of ECS servers.

4) Hide origin IPs to reduce direct attack surface

Problem: Attackers target origin IPs directly after discovering them.
Why it fits: With Anti-DDoS Proxy, you can restrict origin access to only the proxy back-to-origin IP ranges.
Example: Security group rules allow only Anti-DDoS Proxy egress ranges to reach the origin ALB.

5) Protect a login page during high-traffic events

Problem: Credential-stuffing bots plus DDoS-like floods cause instability.
Why it fits: Anti-DDoS Proxy helps with volumetric floods; combine with WAF/bot control for credential abuse.
Example: login.example.com is protected; WAF handles L7 rules, Anti-DDoS Proxy handles volumetric events.

6) DDoS resilience for a payment callback endpoint

Problem: Downtime breaks payments and reconciliation.
Why it fits: Keeps callback endpoints reachable even during attacks.
Example: Payment provider callback URL is routed through Anti-DDoS Proxy with strict forwarding rules.

7) Reduce emergency mitigation actions during attacks

Problem: During attacks, teams scramble to change DNS, block IPs, or scale up.
Why it fits: Pre-configured protection reduces manual intervention.
Example: An operations team uses predefined alarms and dashboards to confirm mitigation is active.

8) Protect a multi-tenant SaaS ingress

Problem: One tenant’s attack traffic impacts everyone on shared ingress.
Why it fits: Anti-DDoS Proxy increases ingress headroom and stability; can be paired with per-tenant rate controls at L7/WAF.
Example: app.example.com is protected, origin is an ALB with path-based routing.

9) Protect hybrid origins (on-prem/public IP) during migration

Problem: On-prem service is DDoS targeted; migration to cloud is phased.
Why it fits: Anti-DDoS Proxy can forward to non-cloud public IPs if supported (verify origin type support).
Example: A legacy service stays on-prem but uses Alibaba Cloud Anti-DDoS Proxy as a protective front door.

10) Protect marketing campaign landing pages

Problem: Ad campaigns attract both real traffic and malicious floods.
Why it fits: Anti-DDoS Proxy stabilizes availability; you can still use CDN for caching where appropriate.
Example: A landing page uses Anti-DDoS Proxy + CDN; origin is a static site on OSS behind an origin server.

11) Keep B2B partner integrations alive (IP allowlists)

Problem: Partner integrations break during DDoS; IP allowlists complicate changes.
Why it fits: Anti-DDoS Proxy provides stable endpoints; you can coordinate allowlisting to proxy IPs.
Example: Partners allowlist the Anti-DDoS Proxy IPs rather than your origin EIPs.

12) Improve attack visibility and reporting

Problem: Lack of evidence post-incident (what happened, how big, how long).
Why it fits: Attack event reporting, metrics, and alerts centralize data.
Example: Security team exports attack reports into incident tickets.

6. Core Features

Feature availability can differ by edition, region, and protocol type. Confirm the exact capabilities for your Anti-DDoS Proxy instance in the official Alibaba Cloud documentation.

1) DDoS mitigation (scrubbing)

What it does: Detects and filters malicious traffic patterns upstream.
Why it matters: Prevents bandwidth saturation and state exhaustion at the origin.
Practical benefit: Services remain reachable during large attacks.
Caveats: Mitigation capacity is tied to purchased edition/capacity; exceeding capacity can still impact availability.

2) Protected IPs / proxy access points

What it does: Provides public endpoints clients connect to instead of your origin.
Why it matters: Enables traffic scrubbing and can obscure origin IPs.
Practical benefit: Simplifies DNS cutover and reduces direct-origin exposure.
Caveats: You must update DNS or client configuration; propagation time matters.

3) Forwarding rules (protocol/port mapping)

What it does: Maps inbound traffic on a proxy IP + port to origin IP + port.
Why it matters: Enables protection for non-HTTP services and custom ports.
Practical benefit: Protects TCP/UDP services without changing application logic.
Caveats: Port/protocol limits and supported ranges depend on edition; verify.

4) Website/domain-based forwarding (where supported)

What it does: Allows HTTP/HTTPS protection using domain routing.
Why it matters: Web traffic is a common DDoS target (HTTP floods, CC attacks).
Practical benefit: Can protect multiple domains and simplify TLS handling (depending on features).
Caveats: Not a full WAF; for OWASP protections and bot management, integrate Alibaba Cloud WAF.

5) Back-to-origin protection via allowlisting

What it does: Lets you restrict origin access so only Anti-DDoS Proxy can reach it (using documented back-to-origin IP ranges).
Why it matters: Prevents attackers from bypassing the proxy and hitting your origin directly.
Practical benefit: Strong security hardening with minimal cost.
Caveats: You must maintain allowlists accurately; changes to egress IP ranges require updates (follow official announcements/docs).

6) Health checks / origin availability logic (where supported)

What it does: Detects origin reachability to avoid forwarding to dead endpoints (feature name varies).
Why it matters: Reduces false positives where “protection is up but origin is down.”
Practical benefit: Faster detection of origin misconfigurations.
Caveats: Health check behavior differs by protocol; verify supported checks and intervals.

7) Attack event dashboards and reports

What it does: Shows attack times, types, and mitigation actions.
Why it matters: Supports incident response and capacity planning.
Practical benefit: Faster triage and better postmortems.
Caveats: Data retention and granularity vary; verify.

8) Alerts and notifications

What it does: Sends notifications when attacks occur or thresholds are crossed.
Why it matters: Reduces mean time to detect (MTTD).
Practical benefit: On-call teams get actionable signals.
Caveats: Integrations (SMS/email/webhook) depend on account settings and region.

9) API and automation (OpenAPI)

What it does: Enables programmatic management of certain configurations.
Why it matters: Infrastructure-as-code and repeatable deployments.
Practical benefit: Standardize protection onboarding across many services.
Caveats: API coverage may not match console 1:1; verify Anti-DDoS Proxy OpenAPI docs.

10) Multi-origin / layered ingress (architectural pattern)

What it does: Supports forwarding to load balancers, which then distribute to multiple origins.
Why it matters: Adds resilience and elasticity behind the protected entry point.
Practical benefit: Rolling deployments and scaling without changing Anti-DDoS Proxy config.
Caveats: Your load balancer and origins must be sized for clean traffic peaks.

7. Architecture and How It Works

High-level service architecture

Anti-DDoS Proxy sits at the edge of your Internet ingress:

Clients connect to a protected/proxy IP (or domain pointing to it).
Traffic enters Alibaba Cloud’s mitigation network.
Malicious traffic is detected and scrubbed (filtered, rate-limited, challenged depending on attack type and features).
Clean traffic is proxied/forwarded to the configured origin endpoint(s).
Metrics and events are surfaced to console/APIs for monitoring and operations.

Request/data/control flow

Data plane:
Client → Anti-DDoS Proxy protected endpoint → scrubbing → forwarding → origin
Origin responses return through the proxy to the client (typical proxy pattern).
Control plane:
Admin uses Alibaba Cloud Console/OpenAPI to create instances, bind protected assets, create forwarding rules, and view events/metrics.
IAM (RAM) controls who can perform these operations.

Integrations with related services

Common integration points: – ECS / ACK as origins – Server Load Balancer (SLB/ALB/NLB) as origin to distribute traffic – WAF for application-layer security (SQLi/XSS/bots) – CloudMonitor for alarms and dashboards – ActionTrail for auditing configuration changes – Log Service (SLS) if Anti-DDoS logs can be delivered (verify)

Dependency services

DNS is central: you usually repoint A/AAAA (or CNAME) records to Anti-DDoS Proxy endpoints.
Networking and security groups: to restrict origin access and allow proxy back-to-origin traffic.
Certificates (for HTTPS) if L7/TLS termination is used (verify exact TLS handling model for your edition).

Security/authentication model

Controlled by Alibaba Cloud RAM:
Users/roles need permissions to manage Anti-DDoS Proxy instances and configurations.
Admin actions should be audited via ActionTrail (and optionally exported to SLS).

Networking model

Public ingress through protected endpoints.
Forwarding to origin uses public routing; you typically secure the origin by:
Allowlisting proxy egress ranges
Using a load balancer with restricted listener ACLs (if available)
Avoiding direct exposure of origin IPs in DNS or public configs

Monitoring/logging/governance considerations

Monitor:
Attack events and peak Mbps/pps (as shown in Anti-DDoS Proxy console)
Origin health and response codes (through application monitoring)
DNS status and TTL
Governance:
Use tags and naming conventions for instances and protected assets.
Use least privilege RAM policies.
Centralize alert routing (email/SMS/IM integrations as supported).

Simple architecture diagram

flowchart LR
  U[Internet Users] --> DNS[DNS: app.example.com]
  DNS --> P[Anti-DDoS Proxy Protected IP/CNAME]
  P --> S[Scrubbing & Filtering]
  S --> F[Forwarding Rule]
  F --> O[Origin Service\n(ECS/SLB/Public IP)]

Production-style architecture diagram

flowchart TB
  subgraph Internet["Internet"]
    Users[Users/Bots]
  end

  subgraph AlibabaCloud["Alibaba Cloud"]
    DNS[Alibaba Cloud DNS / External DNS]
    ADP[Anti-DDoS Proxy\n(Protected IPs / Domains)]
    WAF[Web Application Firewall (optional)]
    ALB[Load Balancer (ALB/NLB/SLB)]
    APP[App Tier\n(ECS/ACK)]
    DB[(Database)]
    CM[CloudMonitor]
    AT[ActionTrail]
    SLS[Log Service (SLS)\n(optional/verify)]
  end

  Users --> DNS
  DNS --> ADP
  ADP -->|Clean traffic| WAF
  WAF --> ALB
  ALB --> APP
  APP --> DB

  ADP --> CM
  WAF --> CM
  ALB --> CM
  AT --> SLS
  ADP -.->|events/logs (verify)| SLS

8. Prerequisites

Account and billing

An active Alibaba Cloud account with a valid payment method.
Ability to purchase Anti-DDoS Proxy (subscription/edition availability varies).
If you will create origin infrastructure for the lab: budget for ECS, public IP/EIP, and bandwidth.

Permissions / IAM (RAM)

You need permissions to: – Purchase and manage Anti-DDoS Proxy instances – Configure protected objects and forwarding rules – View monitoring/attack events

Practical guidance: – Use a RAM user/role for day-to-day operations. – Keep purchasing and billing permissions restricted.

Verify in official docs: The exact RAM actions for Anti-DDoS Proxy (service namespace and API actions), as they can differ across Alibaba Cloud products.

Tools

A terminal with:
curl
dig or nslookup
Optional:
Alibaba Cloud CLI (if you plan to use APIs; verify Anti-DDoS Proxy CLI coverage)
hey or ab for light load testing (do not generate abusive traffic)

Region availability

Anti-DDoS Proxy availability is region-dependent.
Confirm supported regions and editions in official docs/product pages.

Quotas/limits (examples to verify)

Common limits you should confirm: – Number of protected IPs per instance – Number of forwarding rules – Supported protocols/ports – Maximum number of protected domains (for website protection) – TLS/certificate limits (if applicable)

Prerequisite services

For the hands-on tutorial you’ll need: – An origin service reachable on the Internet (ECS with a public IP, or a load balancer) – A domain name you control (recommended for realistic testing)

9. Pricing / Cost

Anti-DDoS Proxy pricing can be edition-based, capacity-based, and region-specific, and some customers may use negotiated enterprise pricing. Do not rely on third-party price lists; always confirm in official Alibaba Cloud pricing pages.

Pricing dimensions (typical model)

Anti-DDoS Proxy is commonly priced based on some combination of:

Edition / instance type (feature set and mitigation level)
Mitigation capacity (e.g., protected bandwidth/clean traffic capacity, depending on SKU)
Number of protected IPs and/or protected domains
Forwarding specifications (ports/rules; sometimes included up to limits)
Additional value-added features (where offered)

Verify in official docs: Whether “clean traffic” (legitimate traffic) is metered separately for your edition, and how burst scenarios are billed.

Free tier

Typically no universal free tier for dedicated DDoS proxy services, but Alibaba Cloud may offer trials or promotions in some regions.
Verify in official promotions/free trial pages.

Main cost drivers

Choosing higher mitigation capacity than needed (or underbuying and suffering downtime).
Number of protected assets (IPs/domains) onboarded.
Origin infrastructure costs (ALB/NLB, ECS scaling, bandwidth).
Data transfer charges on the origin side:
Ingress/egress bandwidth for ECS or load balancers
Inter-region traffic if origins are cross-region

Hidden/indirect costs

Origin bandwidth: even scrubbed traffic must reach the origin; during legitimate traffic surges, origin egress/ingress costs can rise.
TLS certificates and management (if you terminate TLS at the proxy or WAF; depends on architecture).
Operational tooling: log storage in SLS, alerting tools, and incident response time.

Network/data transfer implications

Client-to-proxy traffic is handled at the Anti-DDoS layer.
Proxy-to-origin traffic still traverses networks and is subject to origin-side billing rules.
If your origin is outside Alibaba Cloud, public Internet egress costs and latency can apply.

How to optimize cost

Right-size mitigation capacity based on:
Historical traffic peaks
Known attack sizes in your industry
Business impact of downtime
Put a load balancer behind Anti-DDoS Proxy to avoid frequent rule edits and allow elastic scaling.
Use CDN caching for static-heavy sites to reduce origin load (CDN is not a replacement for DDoS protection but can reduce origin pressure).
Minimize number of protected assets by consolidating entry points (when appropriate).
Keep DNS TTL reasonably low for failover planning, but not so low that it causes operational overhead.

Example low-cost starter estimate (no fabricated numbers)

A realistic starter environment often includes: – 1 Anti-DDoS Proxy instance (entry-level edition/capacity) – 1 origin ECS instance with a public IP (or 1 load balancer + small ECS pool) – DNS hosted zone (could be Alibaba Cloud DNS or external)

Because SKUs and unit prices vary by region and edition, calculate using the official pricing page and/or calculator for: – Anti-DDoS Proxy instance subscription – ECS instance (compute + system disk) – Public bandwidth package / pay-by-traffic

Example production cost considerations

In production, budget for: – Higher mitigation capacity instance(s) – Multi-origin/load-balanced architecture – WAF (if handling web applications) – Monitoring/logging retention (SLS) – Additional IPs/domains as your services expand – Incident response and operational readiness (runbooks, drills)

Official pricing resources (start here; verify latest URLs and region context): – Alibaba Cloud product pages and pricing entry points:
https://www.alibabacloud.com/products
– Alibaba Cloud pricing (general):
https://www.alibabacloud.com/pricing
– Anti-DDoS documentation hub (use it to find “Billing” for Anti-DDoS Proxy):
https://www.alibabacloud.com/help/en/anti-ddos-proxy

10. Step-by-Step Hands-On Tutorial

This lab walks you through placing a simple HTTP service behind Alibaba Cloud Anti-DDoS Proxy and validating that DNS now routes through the protected endpoint.

Because generating DDoS traffic is unsafe and can violate policies, this tutorial focuses on correct onboarding, verification, and safe functional testing.

Objective

Deploy a basic origin web server (Nginx) on ECS.
Purchase/configure Anti-DDoS Proxy.
Create a forwarding rule to the origin.
Update DNS to route user traffic through Anti-DDoS Proxy.
Validate traffic flow and lock down the origin to accept traffic only from Anti-DDoS Proxy (where possible).

Lab Overview

You will build:

Origin: ECS + Nginx on port 80
Protection: Anti-DDoS Proxy protected IP/domain
Routing: DNS A record points your domain to the Anti-DDoS Proxy endpoint
Security hardening: Origin security group restricts inbound to Anti-DDoS Proxy back-to-origin IP ranges (verify ranges in official docs/console)

Step 1: Create an origin ECS web server (Nginx)

In the Alibaba Cloud console, create an ECS instance in a region where Anti-DDoS Proxy is available.
Assign a public IPv4 address (or attach an EIP) so the instance can be reached for initial testing.
Configure the ECS security group to allow inbound TCP/80 temporarily from your IP (or 0.0.0.0/0 for short lab purposes, then restrict later).

On the ECS instance, install and start Nginx (Ubuntu/Debian example):

sudo apt-get update
sudo apt-get install -y nginx
sudo systemctl enable nginx
sudo systemctl start nginx

Create a simple page:

echo "origin: $(hostname) - $(date -Is)" | sudo tee /var/www/html/index.html

Expected outcome – Visiting http://<your-ecs-public-ip>/ returns a page containing origin:.

Verify from your laptop:

curl -i http://<your-ecs-public-ip>/

Step 2: Purchase an Anti-DDoS Proxy instance

In Alibaba Cloud console, navigate to Security products and locate Anti-DDoS Proxy.
Purchase an instance: – Select the region (if applicable). – Select an edition/capacity aligned with your needs (for lab, choose the smallest available). – Confirm included quotas (protected IP count, forwarding rules, domains).

Expected outcome – An Anti-DDoS Proxy instance appears in the console with a status indicating it is active/available.

If you cannot find Anti-DDoS Proxy in your console, verify: – Your account region settings – Product availability in your country/region – Whether the service is listed under a related Anti-DDoS product name in that region (verify in official docs)

Step 3: Add a protected asset and create a forwarding rule

Anti-DDoS Proxy onboarding typically requires: – A proxy/protected endpoint (IP or domain-based) – A forwarding rule mapping inbound to origin

In the Anti-DDoS Proxy console:

Find your instance and choose Protected Objects/Assets (name varies).
Add an asset: – Protocol: HTTP (TCP/80) for this lab – Public IP / origin address: your ECS public IP (or your load balancer IP)
Create a forwarding rule: – Inbound: proxy IP + port 80 – Outbound: origin IP + port 80

Expected outcome – The console shows: – A created protected object – A proxy/protected IP assigned (or a domain access method) – A forwarding rule in “enabled” state

If the console provides a CNAME instead of an IP (common in some web protection models), note it—you’ll use it in DNS in Step 4.

Step 4: Update DNS to route traffic through Anti-DDoS Proxy

You need a domain name you control (e.g., lab-ddos.example.com).

Depending on the onboarding model you see:

Case A: You are given a protected IPv4 address – Create/modify an A record: – lab-ddos.example.com → <Anti-DDoS Proxy protected IPv4>

Case B: You are given a CNAME target – Create/modify a CNAME record: – lab-ddos.example.com → <Anti-DDoS Proxy CNAME>

Set a low TTL for lab testing (for example 60–300 seconds) if your DNS provider supports it.

Expected outcome – DNS resolves lab-ddos.example.com to the Anti-DDoS Proxy endpoint, not the origin IP.

Verify:

dig +short lab-ddos.example.com

nslookup lab-ddos.example.com

Step 5: Validate end-to-end traffic through Anti-DDoS Proxy

From your laptop, request the domain:

curl -i http://lab-ddos.example.com/

Expected outcome – You get HTTP 200 (or expected status) and the content from your origin (origin: ...). – In the Anti-DDoS Proxy console, you should see traffic metrics increment (may take a short delay).

Optional: confirm origin logs show requests arriving (Nginx access log):

sudo tail -n 50 /var/log/nginx/access.log

Step 6: Lock down the origin (recommended hardening)

After confirming functionality, reduce the risk of origin bypass.

Identify the back-to-origin IP ranges used by Anti-DDoS Proxy for your region/edition. – These ranges are usually documented in Anti-DDoS Proxy docs or shown in console guidance. – Do not guess IP ranges; use official sources.
Update the ECS security group inbound rules: – Allow TCP/80 only from the Anti-DDoS Proxy back-to-origin IP ranges. – Remove broad 0.0.0.0/0 rules.
(Optional) If you use a load balancer as origin, apply similar restrictions: – Listener ACLs (if supported) – Security group rules on ALB/NLB backends

Expected outcome – Direct access to http://<ecs-public-ip>/ from your laptop should now be blocked (timeout/refused). – Access to http://lab-ddos.example.com/ should still work (traffic comes through Anti-DDoS Proxy).

Validation

Use this checklist:

DNS points to Anti-DDoS Proxy – dig +short lab-ddos.example.com returns proxy IP or CNAME resolution chain.
HTTP works through the proxy – curl -i http://lab-ddos.example.com/ returns expected content.
Origin is not directly exposed (after hardening) – curl -i http://<origin-public-ip>/ fails (expected)
– curl -i http://lab-ddos.example.com/ succeeds (expected)
Console visibility – Anti-DDoS Proxy dashboard shows traffic/requests and no obvious configuration errors.

Troubleshooting

Common issues and fixes:

DNS updated but traffic still goes to old endpoint – Cause: DNS caching/TTL. – Fix: wait TTL duration; flush local resolver cache; check authoritative DNS.
502/504 or connection failures through Anti-DDoS Proxy – Cause: wrong origin IP/port in forwarding rule; origin firewall blocks proxy; origin service not running. – Fix: verify origin service: curl http://<origin-ip>/ from a network that is allowed; confirm Nginx is listening: sudo ss -lntp | grep :80.
Access works directly to origin but not via Anti-DDoS Proxy – Cause: forwarding rule not enabled, wrong protocol, wrong port mapping. – Fix: re-check forwarding rule configuration; verify protocol (TCP vs HTTP model) matches the service.
After locking down origin, everything breaks – Cause: incorrect back-to-origin allowlist ranges. – Fix: revert temporarily, fetch correct ranges from official docs/console, then re-apply.
HTTPS issues (certificate mismatch, TLS handshake failures) – Cause: certificate not configured in the layer terminating TLS. – Fix: determine whether TLS terminates at Anti-DDoS Proxy, WAF, or origin; configure certificates accordingly (verify your edition’s TLS model).

Cleanup

To avoid ongoing charges:

Revert DNS record (lab-ddos.example.com) back to the origin or remove it.
Delete Anti-DDoS Proxy forwarding rules and protected objects (if required before release).
Release/unsubscribe the Anti-DDoS Proxy instance (billing rules vary—verify refund/cycle behavior).
Terminate the ECS instance and release public IP/EIP.
Remove security group rules created for the lab.

11. Best Practices

Architecture best practices

Put a load balancer (ALB/NLB/SLB) behind Anti-DDoS Proxy:
Makes scaling and blue/green deployments easier
Reduces frequent Anti-DDoS rule updates
Use multi-zone origins where possible; Anti-DDoS Proxy protects ingress, but your origin must still be resilient.
Consider multi-region DR with DNS failover for business-critical services (Anti-DDoS is not a DR substitute).

IAM/security best practices

Use least privilege RAM policies for:
Security operations (manage Anti-DDoS config)
Read-only monitoring
Require MFA for privileged users.
Separate duties: purchasing/billing vs security operations.

Cost best practices

Right-size capacity using:
Baseline legitimate traffic peaks
Expected attack profile
Consolidate protected entry points where possible.
Use caching/CDN to reduce origin cost (especially for static content).

Performance best practices

Keep origin response times low; scrubbing helps availability, not application latency.
Use keep-alive and connection tuning on origins/load balancers.
Ensure DNS TTL strategy matches your failover goals.

Reliability best practices

Maintain runbooks for:
DNS cutover and rollback
Origin allowlisting updates
Incident communication and escalation
Test configuration changes in a staging environment where feasible.

Operations best practices

Set alerts for:
Attack detection events
Unusual traffic spikes
Origin error rate increase (via application monitoring)
Track config drift:
Use ActionTrail for auditing
Document protected assets and owners

Governance/tagging/naming best practices

Tag resources with:
env (prod/stage/dev)
app
owner
cost-center
Use consistent naming:
adp-prod-api-gateway
adp-prod-game-udp

12. Security Considerations

Identity and access model

Managed with Alibaba Cloud RAM.
Recommendations:
Create a dedicated RAM role for automation (CI/CD) if you manage config via API.
Use read-only roles for dashboards and reports.

Encryption

In transit:
For HTTPS, ensure TLS is terminated in the correct layer (Anti-DDoS Proxy vs WAF vs origin) based on your chosen architecture and supported features.
At rest:
Configuration metadata is managed by Alibaba Cloud; verify what encryption and compliance statements apply in official docs.

Network exposure

The most common security mistake is leaving the origin publicly reachable even after onboarding to Anti-DDoS Proxy.
Use:
Security groups and ACLs
Back-to-origin IP allowlists (from official docs)
Private networking patterns where applicable (for internal components)

Secrets handling

If TLS certificates/keys are uploaded to a managed layer:
Restrict access to certificate management
Track certificate rotation dates
Prefer centralized certificate management if available (verify Alibaba Cloud certificate service options)

Audit/logging

Enable and review:
ActionTrail for configuration changes
Anti-DDoS Proxy attack events and reports
If log export to SLS is supported, enable it and set retention policies (verify).

Compliance considerations

Anti-DDoS Proxy can support availability and resilience controls, but compliance depends on: – Region – Data handling requirements – Service attestations and certifications

Always validate against Alibaba Cloud compliance documentation for your region and your internal policies.

Common security mistakes

Not restricting origin access after onboarding.
Forgetting to update DNS for all relevant subdomains/ports.
Treating Anti-DDoS Proxy as a full WAF and skipping application-layer protections.
Over-permissioning RAM users who can change forwarding rules (risk of misrouting traffic).

Secure deployment recommendations

Place WAF behind Anti-DDoS Proxy for web apps needing OWASP protection.
Use origin allowlisting and eliminate direct-origin DNS records.
Keep a documented and rehearsed rollback plan for DNS changes.

13. Limitations and Gotchas

Confirm the exact limits for your edition/region in official docs. The items below are common in DDoS proxy designs.

Known limitations (typical)

Edition-specific features: Some protocols, L7 features, or advanced controls may only exist in higher editions.
Protocol constraints: Certain combinations of TCP/UDP ports, health checks, or forwarding modes may be restricted.
TLS handling differences: Whether TLS is terminated at the proxy, passed through, or requires additional configuration depends on product features.

Quotas

Maximum number of protected IPs/domains per instance
Maximum number of forwarding rules/ports
Maximum bandwidth/pps mitigation as per purchased capacity

Regional constraints

Not all regions offer the same Anti-DDoS Proxy editions.
Latency to origin increases if your origin is far from scrubbing/proxy entry nodes (depends on routing).

Pricing surprises

Underestimating origin bandwidth costs during legitimate spikes.
Buying multiple instances for separate apps when a shared design could work (trade off against blast radius).
Subscription commitment terms (monthly/annual) affecting cancellation/refunds (verify).

Compatibility issues

Some applications embed origin IPs in responses or use strict IP allowlists, complicating proxying.
Protocols sensitive to source IP changes may require application adjustments (depending on whether original client IP is preserved via headers or proxy protocol—verify support).

Operational gotchas

DNS propagation delays during cutovers.
Origin allowlisting must stay updated with the correct Anti-DDoS back-to-origin ranges.
If you rotate origins (autoscaling), ensure forwarding still targets stable entry points (load balancer recommended).

Migration challenges

Migrating from direct-to-origin to proxy can break:
Webhooks and partner allowlists (need proxy IP allowlisting)
Certificate management (where TLS terminates changes)
Logging (client IP visibility changes)

Vendor-specific nuances

Alibaba Cloud product naming and console navigation can differ by locale/region. Use the official docs for your region’s UI paths.

14. Comparison with Alternatives

Anti-DDoS Proxy is one part of a broader DDoS and application protection toolkit.

In Alibaba Cloud

Basic DDoS protection (often included for certain public IP services): good baseline, but not enough for serious attacks.
Other Anti-DDoS offerings (naming varies): some services protect EIPs/SLB directly rather than proxy-based onboarding.
WAF: application-layer security (OWASP, bot control) rather than volumetric mitigation.

In other clouds

AWS Shield Standard/Advanced: DDoS protection tightly integrated with CloudFront, Route 53, ALB/NLB, and AWS edge.
Azure DDoS Protection: for resources in Azure VNets, focused on protecting public IPs.
Google Cloud Armor: DDoS + WAF-like policies integrated with Google’s edge.

Open-source/self-managed alternatives

Self-managed DDoS defense is usually limited to:
Rate limiting (nginx/Envoy)
Firewall rules (iptables/nftables)
Anycast requires deep networking expertise and contracts
These do not replace a large-scale scrubbing network.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Alibaba Cloud Anti-DDoS Proxy	Internet-facing apps/services needing dedicated DDoS mitigation with proxy forwarding	Managed scrubbing + forwarding; integrates with Alibaba Cloud ecosystem	Subscription cost; DNS/proxy migration complexity; feature matrix varies by edition	You need strong DDoS resilience for web/TCP/UDP services on or reachable from Alibaba Cloud
Alibaba Cloud baseline/basic DDoS protections	Low-risk workloads, small sites	Included/low cost; minimal setup	Limited capacity and controls	Small workloads where downtime impact is low
Alibaba Cloud WAF	Web apps needing OWASP protections and bot controls	Strong L7 security controls (WAF scope)	Not designed to absorb very large volumetric floods alone	Pair with Anti-DDoS Proxy when L7 threats and DDoS both matter
AWS Shield Advanced	Workloads on AWS edge stack	Deep AWS integration; DRT support (plan-dependent)	Best value when heavily invested in AWS edge	You’re on AWS and need advanced DDoS protection
Azure DDoS Protection	Azure public IP resources	Native protection for Azure networking	Azure-centric; less relevant cross-cloud	Your origins are in Azure VNets
Cloudflare (DDoS/WAF)	Internet-facing web apps needing edge protection and caching	Global edge; WAF/bot; CDN	TCP/UDP support depends on plan; vendor dependency	You want a unified edge platform and can route traffic via Cloudflare
Self-managed rate limiting (nginx/iptables)	Very small services, internal labs	Low direct cost	Not effective for large volumetric attacks; ops burden	Only for basic protection and learning—not for serious DDoS risk

15. Real-World Example

Enterprise example: Fintech API and login protection

Problem: A fintech company experiences repeated DDoS attacks targeting api.company.com and login.company.com, causing intermittent outages and failed transactions.
Proposed architecture:
DNS → Anti-DDoS Proxy → (optional) WAF → ALB → ECS/ACK microservices
Strict origin allowlisting to Anti-DDoS Proxy back-to-origin IP ranges
CloudMonitor alarms for attack events and origin error rate
ActionTrail auditing for configuration changes
Why Anti-DDoS Proxy was chosen:
Dedicated mitigation capacity required by risk assessments
Needs protection not only for web pages but also for API endpoints with predictable routing
Expected outcomes:
Reduced downtime during volumetric floods
Clearer attack visibility for incident reports
Improved security posture by hiding origin IPs

Startup/small-team example: Game backend (UDP/TCP)

Problem: A small game studio is targeted by UDP floods during tournaments, taking match servers offline.
Proposed architecture:
DNS/Client config → Anti-DDoS Proxy (UDP/TCP forwarding) → NLB → ECS game server fleet
Autoscaling for legitimate spikes; runbooks for fast tournament changes
Why Anti-DDoS Proxy was chosen:
Managed DDoS mitigation without building custom network defenses
Supports non-HTTP services (key requirement)
Expected outcomes:
Better tournament uptime
Reduced operational firefighting
More predictable capacity planning

16. FAQ

Is Anti-DDoS Proxy the same as a WAF?
No. Anti-DDoS Proxy focuses on DDoS mitigation and proxy forwarding. A WAF focuses on application-layer protections (OWASP attacks, bot management). Many production setups use both.
Do I have to change my application code to use Anti-DDoS Proxy?
Usually no. Most changes are at DNS/routing and network policy (security group allowlists). Some applications may require adjustments for client IP handling (verify headers/proxy protocol support).
How do users reach my service after enabling Anti-DDoS Proxy?
Typically by DNS pointing your domain to the Anti-DDoS Proxy protected IP or CNAME. For non-HTTP services, clients may connect directly to the protected IP/port.
Can Anti-DDoS Proxy protect TCP and UDP services?
It is commonly used for TCP/UDP forwarding, but exact protocol support depends on edition/region—verify in official docs.
Can I protect an origin outside Alibaba Cloud?
Some DDoS proxy products support forwarding to any public IP. Verify whether Anti-DDoS Proxy supports non-Alibaba Cloud origins in your region and what latency/cost implications apply.
Will Anti-DDoS Proxy hide my origin IP?
It can, but only if you avoid exposing origin IPs elsewhere and restrict origin access to Anti-DDoS Proxy back-to-origin IP ranges.
Does it support HTTPS?
Many deployments protect HTTPS, but TLS termination/management varies by product model. Verify how your edition handles certificates and whether TLS is terminated at the proxy, WAF, or origin.
How do I restrict origin access safely?
Use ECS security groups or load balancer ACLs to allow inbound only from Anti-DDoS Proxy back-to-origin IP ranges published by Alibaba Cloud (do not guess; use official sources).
What happens if an attack exceeds my purchased mitigation capacity?
Behavior depends on the service/edition. It may degrade, trigger blackhole routing, or require emergency scaling. Confirm SLA and overflow behavior in official docs and consider sizing with margin.
Can I use Anti-DDoS Proxy with a load balancer?
Yes, this is a common best practice: Anti-DDoS Proxy → ALB/NLB/SLB → origins.
How quickly can I onboard a new domain/service?
Technically minutes, but DNS propagation can take longer depending on TTL and caching. Plan migrations with rollback steps.
Does Anti-DDoS Proxy preserve the original client IP?
Often proxies add headers (for HTTP) or use proxy protocol (for TCP) to pass client IP, but this is edition/protocol dependent—verify and update application logging accordingly.
What monitoring should I set up?
Use Anti-DDoS Proxy dashboards/alerts for attack events and CloudMonitor (and your APM) for origin latency, error rates, and saturation signals.
Can I test DDoS protection safely?
You can validate routing, health, and basic rate limiting in a controlled manner. Do not run high-volume floods. For formal testing, follow Alibaba Cloud guidance and get approval.
How do I roll back if something breaks?
Revert DNS to the origin (or previous front door), restore origin security group rules if you restricted them, and disable/remove forwarding rules as needed.
Is Anti-DDoS Proxy suitable for dev/test environments?
Usually not necessary, but it can be useful for staging rehearsals of DNS cutover, certificate flow, and origin allowlisting.
Does Anti-DDoS Proxy replace CDN?
No. CDN is for caching and accelerating content; Anti-DDoS Proxy is for DDoS mitigation and proxy forwarding. They can be complementary.

17. Top Online Resources to Learn Anti-DDoS Proxy

URLs can change over time. If a link redirects, navigate via the Alibaba Cloud Help Center and search for “Anti-DDoS Proxy”.

Resource Type	Name	Why It Is Useful
Official documentation	Alibaba Cloud Help Center – Anti-DDoS Proxy	Primary source for concepts, configuration steps, limits, and best practices: https://www.alibabacloud.com/help/en/anti-ddos-proxy
Official product catalog	Alibaba Cloud Products	Entry point to find the Anti-DDoS Proxy product page and related services: https://www.alibabacloud.com/products
Official pricing	Alibaba Cloud Pricing	Starting point to locate Anti-DDoS pricing and calculators (region-dependent): https://www.alibabacloud.com/pricing
Official security docs	Alibaba Cloud Security products docs	Helps you connect Anti-DDoS Proxy with WAF, Cloud Firewall, and monitoring: https://www.alibabacloud.com/help/en/security
Official audit logging	ActionTrail documentation	Audit changes to Anti-DDoS configurations and user actions: https://www.alibabacloud.com/help/en/actiontrail
Official monitoring	CloudMonitor documentation	Set alarms and integrate monitoring signals: https://www.alibabacloud.com/help/en/cloudmonitor
Official DNS	Alibaba Cloud DNS documentation	DNS cutover and record management guidance: https://www.alibabacloud.com/help/en/alibaba-cloud-dns
Official load balancing	Server Load Balancer documentation	Best practices for placing a load balancer behind Anti-DDoS Proxy: https://www.alibabacloud.com/help/en/server-load-balancer
Official API reference	Alibaba Cloud OpenAPI portal	Find Anti-DDoS-related APIs (verify product/namespace for Anti-DDoS Proxy): https://api.alibabacloud.com/
Community learning	Alibaba Cloud Blog (search: Anti-DDoS Proxy)	Practical articles and announcements; validate against docs: https://www.alibabacloud.com/blog

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, cloud engineers	Cloud security basics, DDoS/WAF patterns, operational labs	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate engineers	DevOps/cloud fundamentals and tooling around deployments	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud operations teams	Cloud ops practices, monitoring, reliability and incident response	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, platform teams	Reliability engineering, SLIs/SLOs, incident management	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops/SRE teams exploring automation	AIOps concepts, monitoring automation, event correlation	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training and guidance (verify offerings)	Engineers seeking practical coaching	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training platform (verify course catalog)	Beginners to intermediate DevOps engineers	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps support/training (verify services)	Teams needing short-term help and enablement	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and learning resources (verify scope)	Ops teams needing troubleshooting and operational support	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 portfolio)	Architecture, migration, operational readiness	Designing secure Internet ingress; implementing monitoring and runbooks	https://cotocus.com/
DevOpsSchool.com	DevOps and cloud consulting/training	Enablement, pipeline engineering, operational practices	Security-focused DevOps practices; incident response process setup	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify offerings)	DevOps implementation and support	CI/CD modernization; infrastructure automation; operational best practices	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Anti-DDoS Proxy

Networking fundamentals:
TCP/UDP, ports, DNS, TLS
Load balancing concepts
Alibaba Cloud basics:
ECS, VPC (even if the origin is public-facing), security groups
RAM (users, roles, policies)
Security fundamentals:
Threat modeling for Internet-facing services
Basic incident response and logging

What to learn after Anti-DDoS Proxy

Alibaba Cloud WAF for application security
Observability:
CloudMonitor dashboards and alarms
Log Service (SLS) pipelines and retention
Resilience engineering:
Multi-zone and multi-region patterns
Disaster recovery planning and DNS failover
Automation:
OpenAPI, Terraform (if supported by provider), CI/CD for security configs

Job roles that use it

Cloud Security Engineer
SRE / Reliability Engineer
Cloud Network Engineer
DevOps Engineer (Internet ingress ownership)
Security Operations (SOC) Analyst (monitoring/response)

Certification path (if available)

Alibaba Cloud certifications evolve. For a practical path: – Start with Alibaba Cloud foundational certifications (cloud fundamentals). – Move to security and architecture tracks that cover network security, WAF, and resilience.

Verify in official Alibaba Cloud certification pages for current certification names and objectives.

Project ideas for practice

Build a “protected ingress” reference architecture: Anti-DDoS Proxy → WAF → ALB → ECS.
Implement DNS cutover/rollback runbooks with controlled TTL and monitoring.
Create a least-privilege RAM policy for Anti-DDoS operations and validate with ActionTrail audits.
Build dashboards correlating Anti-DDoS events with application error rates.
Simulate safe traffic surges (not DDoS) and confirm scaling behind the proxy.

22. Glossary

DDoS (Distributed Denial of Service): An attack that floods a target with traffic from many sources to degrade or stop service.
L3/L4 attack: Network/transport-layer attacks such as SYN floods, UDP floods, ICMP floods.
L7 attack: Application-layer attacks such as HTTP request floods (sometimes called CC attacks).
Scrubbing: Filtering malicious traffic and allowing clean traffic through.
Protected IP / Proxy IP: The public endpoint exposed by Anti-DDoS Proxy that clients connect to.
Origin: The real backend service receiving clean traffic (ECS, SLB/ALB/NLB, or public IP).
Forwarding rule: A mapping of inbound proxy protocol/port (or domain) to the origin protocol/port.
DNS TTL: Time-to-live; how long resolvers cache DNS answers, affecting cutover speed.
Allowlisting: Restricting inbound access to only approved IP ranges (for example, proxy back-to-origin addresses).
RAM: Resource Access Management; Alibaba Cloud IAM service.
ActionTrail: Alibaba Cloud service to audit account activity and API calls.

23. Summary

Alibaba Cloud Anti-DDoS Proxy is a managed Security service that protects Internet-facing applications by absorbing and scrubbing DDoS traffic and forwarding clean traffic to your origin through configurable rules. It fits best as a front door for public web, API, and TCP/UDP services that need higher availability under attack than baseline protections can provide.

Cost is primarily driven by edition/capacity selection and the number of protected assets, while indirect costs often come from origin bandwidth and scaling. Security success depends on correct operations: DNS cutover, forwarding rule accuracy, and especially locking down the origin to prevent bypass.

Use Anti-DDoS Proxy when you need dedicated DDoS resilience for critical services; pair it with WAF for application-layer protection and with robust monitoring for operational readiness. Next, deepen your skills by implementing a production ingress pattern (Anti-DDoS Proxy → WAF → Load Balancer → App) and validating auditing/alerting with CloudMonitor and ActionTrail.

Category