# DDoS Protection Overview

DDoS Protection is a multi-layer defense system that detects and mitigates distributed denial-of-service attacks in real time. It is deployed in select regions where dedicated mitigation infrastructure is available.

## Key Capabilities

* **Traffic cleaning:** Diverts suspicious traffic to a scrubbing center via BGP, filters it, and redelivers clean packets to your instance — without interrupting legitimate traffic.
* **Protocol filtering:** Validates traffic at the protocol level (TCP, UDP, ICMP) and drops malformed or suspicious packets before they reach your instance.
* **Fingerprint detection:** Matches traffic against known attack signatures — specific payload patterns, port ranges, and packet sizes — to block attacks that evade simple rate limits.
* **Geographic filtering:** Block inbound traffic by country. Useful for services that don't operate in certain regions and want to reduce exposure without managing individual IPs.
* **IP allow/block lists:** Explicitly permit or deny traffic from specific source addresses. Useful for protecting APIs that only serve known partners.
* **Blackhole routing:** Under extreme volumetric attacks that exceed cleaning capacity, all traffic to the affected EIP is blackholed as a last resort to protect the broader infrastructure.

> For step-by-step instructions on configuring these capabilities, see the [DDoS Protection Configuration Guide](/welcome/elastic-compute/01-overview/09-configuration-guide.md).

## Regional Availability

DDoS Protection is currently available in the following regions. In regions where it isn't deployed, EIP Blocked Rules provide threshold-based protection for all EIPs.

| Availability Zone | Location         | DDoS Protection |
| ----------------- | ---------------- | --------------- |
| asia-southeast-5a | Hanoi            | Available       |
| asia-southwest-1a | Singapore        | Available       |
| asia-southeast-2a | Jakarta          | Available       |
| sa-south-1a       | Santiago         | Available       |
| asia-southeast-4a | Ho Chi Minh City | Available       |
| asia-southeast-1a | Hong Kong        | Coming soon     |
| asia-southeast-3a | Kuala Lumpur     | Coming soon     |
| asia-southeast-6a | Manila           | Coming soon     |
| na-central-2a     | Dallas           | Coming soon     |
| na-east-1a        | Washington, D.C. | Coming soon     |
| na-south-1a       | Miami            | Coming soon     |
| na-west-1a        | Los Angeles      | Coming soon     |
| sa-east-1a        | São Paulo        | Coming soon     |
| sa-north-1a       | Bogota           | Coming soon     |
| sa-south-2a       | Buenos Aires     | Coming soon     |
| sa-west-1a        | Lima             | Coming soon     |
| europe-central-1a | Frankfurt        | Coming soon     |
| europe-east-1a    | Istanbul         | Coming soon     |
| europe-south-1a   | Marseille        | Coming soon     |
| me-central-1a     | Riyadh           | Coming soon     |

*This list is updated as new regions come online.*

## How Cleaning Is Triggered

When the analysis system determines that an EIP is under attack, traffic is automatically rerouted to a cleaning center, scrubbed, and redelivered to your instance. The entire process completes within seconds and requires no action on your part.

For a detailed walkthrough of the cleaning pipeline — including detection, BGP diversion, scrubbing stages, and re-injection — see [How Traffic Cleaning Works](/welcome/elastic-compute/01-overview/03-cleaning-deep-dive.md).

## Cleaning Event Lifecycle

Each cleaning event goes through a defined set of states. Understanding this lifecycle helps you interpret notifications and plan your response:

| State             | Description                                                             | What Happens Next                                                                  |
| ----------------- | ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| **Cleaning**      | Attack detected; traffic diverted to cleaning center.                   | If attack subsides → End Cleaning. If it exceeds cleaning capacity → Blackhole.    |
| **End Cleaning**  | Attack mitigated; traffic returns to normal path.                       | Normal operation resumes. No action needed.                                        |
| **Blackhole**     | Attack exceeds cleaning capacity. All traffic to the EIP is blackholed. | Auto-expires after block duration (default: 2 hours), or can be manually released. |
| **End Blackhole** | Blackhole released. Traffic restored.                                   | Normal operation resumes.                                                          |

*To manually release a blackhole before it expires, use the DDoS Protection page in the* [*management console*](https://console.zenlayer.com/zec/ddos/policy)*.*

**Notifications:** Event notifications are delivered via email and the management console. To configure notification preferences or add additional recipients, see the [Notification Settings](https://console.zenlayer.com/notification/) page in the console.

## Relationship to EIP Blocked Rules

If your region has DDoS Protection, you get everything EIP Blocked Rules offers — threshold-based blocking — plus traffic cleaning, fingerprint detection, protocol filtering, and geo-blocking. EIP Blocked Rules are always active as a second layer, even when DDoS Protection is running.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.console.zenlayer.com/welcome/elastic-compute/01-overview/02-ddos-protection.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.