Когда сервис начинает отдавать 5xx, растёт latency, а CDN показывает аномальный трафик, первая ошибка — включать (или наоборот, выключать) всё подряд. Один и тот же симптом “сервис недоступен” может означать разные проблемы: забитый канал, перегрузку HTTP-слоя, атаку на API, credential stuffing или прямой обход CDN на origin.
DDoS-защита в облаке работает как система слоёв:
- L3/L4-защита нужна против volumetric-атак, SYN/UDP/TCP flood и перегруза сетевого периметра;
- Anycast и сеть провайдера помогают распределить входящий поток, но сами по себе не заменяют фильтрацию;
- CDN снижает нагрузку на origin за счёт кэша и проксирования, если origin не доступен напрямую;
- WAF и bot protection работают с HTTP/S-запросами, поведением клиентов, URI, методами и подозрительными шаблонами;
- Rate limiting и квоты помогают при L7-давлении, API abuse, credential stuffing и дорогих операциях;
- Runbook реагирования заранее фиксирует роли, пороги, права на жёсткие меры и порядок эскалации провайдеру.
Главная логика простая: сначала определить, где возникает давление, затем выбрать слой контроля. Если забит канал, лимиты внутри приложения уже не помогут. Если дорогой API метод перегружает базу, одной сетевой фильтрации недостаточно. Если атака идёт в обход CDN на origin IP, нужно закрывать прямой доступ к origin.
Практическая готовность к DDoS — это не только включённая защита у провайдера. Это понятная цепочка решений: какие метрики смотрим, где останавливаем трафик, кто может включить ограничения, как не заблокировать легитимных пользователей и когда подключать облачного, CDN- или антиDDoS-провайдера.
Сначала определить уровень атаки: L3/L4, L7 или API abuse
Первый диагностический вопрос — не “какую защиту включить”, а “где именно возникает давление”. 5xx, рост latency и жалобы пользователей выглядят одинаково на статусной панели, но технически могут означать разные вещи: забитый сетевой периметр, перегруженное приложение, исчерпанные соединения к базе данных, массовые попытки входа или обход CDN на origin.
L3/L4: давление на сеть и транспорт
Если приложение не видит заметного роста RPS, но резко выросли pps, SYN/UDP/TCP-пакеты, bps, dropped packets и нагрузка на сетевой периметр, атака, скорее всего, находится на L3/L4. В этом случае значимая часть трафика может отбрасываться или деградировать ещё до приложения.
Здесь не помогут лимиты внутри backend-кода: запросы могут просто не доходить до HTTP-уровня. Нужна фильтрация у облачного или антиDDoS-провайдера, отсечение мусорного трафика до инфраструктуры клиента и проверка состояния балансировщика, каналов и сетевых интерфейсов.
L7: давление на HTTP/S и приложение
Если RPS растёт, канал не забит, а CPU, память, latency и 4xx/5xx растут вместе с числом HTTP/S-запросов, это ближе к L7 HTTP flood. Такие запросы могут выглядеть почти как нормальный пользовательский трафик: открывают страницы, дергают поиск, ходят по URI, используют допустимые методы.
Здесь работают другие меры: WAF, bot protection, правила по URI и методам, challenge для подозрительных клиентов, ограничения частоты запросов и защита origin. Главная задача — остановить трафик до того, как он перегрузит приложение и серверную часть.
API abuse: давление на дорогие операции
Отдельный сценарий — API abuse или resource exhaustion. Запросы формально легитимны, но бьют по дорогим операциям: отчётам, поиску, выгрузкам, оплате, внешним API, очередям или базе данных.
Признаки обычно видны не только в RPS, а в конкретных ресурсах: растут DB connections, queue depth, время ответа внешних API, 429/5xx и задержка по отдельной точке API. В таких случаях нужна не только фильтрация, а квоты, лимиты по пользователям/API-ключам, очереди, кэширование и аварийные предохранители для тяжёлых операций.
Отдельно проверить обход CDN
Иногда CDN выглядит стабильным, но origin перегружен напрямую. Это может означать, что атакующий знает публичный IP исходного сервера и обходит CDN/WAF.
Проверить стоит трафик на origin IP, соединения вне CDN, сетевые логи и 5xx от приложения. Базовая мера — закрыть origin от прямого доступа и разрешить трафик только от доверенных сетей CDN, прокси или DDoS-провайдера.
Короткая диагностика выглядит так:
- Если растут bps/pps/SYN/UDP/TCP и пакеты отбрасываются до приложения — сначала сетевой уровень и провайдер;
- Если растут RPS, latency и 4xx/5xx на HTTP/S — CDN, WAF, bot protection и L7-правила;
- Если перегружается конкретная точка API, база, очередь или внешний сервис — лимиты, квоты и защита дорогих операций;
- Если CDN спокоен, а origin страдает — проверить прямой доступ к origin IP.
Такое разделение снижает риск первой ошибки. Rate limiting не поможет, если уже забит канал, а сетевая фильтрация сама по себе не остановит дорогие API-вызовы, которые выглядят допустимыми для периметра.
После диагностики нужно перейти к архитектуре защиты и понять, где останавливать трафик до того, как он достигнет origin-сервера.
Слои облачной защиты: где останавливать трафик до origin
Сетевой периметр и Anycast
Anycast распределяет входящий поток по нескольким точкам сети провайдера. Это не один вход в здание, а несколько входов в разных местах: удар не концентрируется в одной двери. Но распределение трафика не равно его очистка. У каждого входа всё равно нужны фильтры.
На этом уровне должны гаситься L3/L4 volumetric-атаки и protocol floods: большие объёмы пакетов, SYN/UDP/TCP-всплески и транспортное давление. Такой трафик нужно отбрасывать до того, как он упрётся в канал клиента, балансировщик или виртуальные машины.
CDN, WAF и защита от ботов
CDN снижает нагрузку на origin за счёт распределения и кэша. Статический контент и часть повторяемых запросов не доходят до исходного сервера. Но если origin доступен напрямую по IP, атакующий может обойти CDN полностью. Тогда защита формально включена, а нагрузка всё равно приходит в приложение.
WAF и bot protection работают уже с HTTP/S: URI, методами, заголовками, поведением клиента, подозрительными шаблонами и автоматизированным трафиком. Здесь уместны challenge-механизмы, правила по маршрутам и ограничения подозрительной активности. Но WAF не должен первым встречать объёмный UDP- или SYN-поток — это задача сетевой DDoS-фильтрации.
Приложение, API и origin
Rate limiting, квоты и правила для API нужны ближе к бизнес-логике: по пользователям, API-ключам, маршрутам, методам и дорогим операциям. Они помогают при L7-давлении и API abuse, но должны срабатывать до перегруза базы, очередей и внешних сервисов.
Балансировщик и origin — уже поздний рубеж. Балансировщик может распределить допустимую нагрузку, но не должен быть основным DDoS-фильтром. Origin лучше держать закрытым от прямого доступа, разрешая трафик только от CDN, прокси или сетей DDoS-провайдера.
Каждый слой должен снижать нагрузку на следующий. Если origin остаётся публично доступным или правила включаются только внутри приложения, часть облачной защиты фактически обходится: атакующий не обязан идти через CDN и WAF, если знает реальный IP исходного сервера.
Автомасштабирование в этой схеме — вспомогательный механизм, а не DDoS-защита. Оно может выдержать часть легитимного всплеска или сгладить L7-нагрузку, но не решает забитый канал и при атаке способно быстро увеличить расходы. Поэтому масштабирование должно дополнять фильтрацию, а не заменять её.
Отдельно нужна наблюдаемость. Команда должна видеть, где именно сработала защита: сколько трафика отброшено у провайдера, что прошло до CDN/WAF, какие запросы дошли до балансировщика, как ведут себя origin/API и база данных. Без этого архитектура превращается в набор “чёрных ящиков”, а во время инцидента непонятно, какой слой усиливать.
Rate limiting для L7 и API: когда помогает и где опасен
Когда трафик уже прошёл сетевые фильтры, CDN и WAF и выглядит частично легитимным, rate limiting становится не общей “кнопкой от DDoS”, а точечным ограничителем. Его применяют по признаку или их комбинации: IP, пользователю, сессии, API-ключу, endpoint, HTTP-методу, ASN, географии, устройству или учётной записи при входе.
Один лимит на весь сервис почти всегда слишком грубый. Он может помочь при HTTP flood, credential stuffing, массовых API-вызовах и дорогих операциях вроде поиска, отчётов, выгрузок, оплаты заказа или логина. Но тот же лимит способен отрезать нормальный спрос во время распродажи, релиза или маркетинговой кампании.
Где rate limiting помогает
Лимиты полезны там, где есть понятная точка перегруза и измеримый профиль нормального поведения. Например:
- /login — лимиты на попытки входа, ошибки авторизации и частоту запросов на аккаунт;
- Поиск и каталог — защита от слишком быстрого обхода выдачи и scraping;
- Отчёты и выгрузки — квоты, очередь, кэш и ограничение периода выборки;
- Checkout — защита от повторных подозрительных операций с оплатой;
- Партнёрские API — лимиты по API-ключам, tenant и типу операции;
- Внешние интеграции — ограничения для вызовов, которые могут перегрузить сторонний сервис.
Главный критерий — не сам высокий RPS, а сочетание отклонения от нормы, точки перегруза и контекста. Один и тот же трафик может быть атакой в обычный день и нормой во время распродажи.
Где лимиты опасны
Rate limiting нельзя включать “по ощущению”. Слишком грубое правило может задеть корпоративные NAT-сети, мобильных операторов, партнёрские интеграции, поисковых роботов и легитимных пользователей. NAT здесь важен потому, что множество реальных клиентов могут выходить в интернет через один или несколько публичных IP.
Практический пример: точка API для генерации отчётов вызывается корректно, но каждый запрос строит тяжёлую выборку и держит соединения к базе. Лимит только по IP здесь слаб: крупный клиент или партнёр может идти через общий NAT. Безопаснее ограничить именно отчёты, ввести очередь, кэшировать результат, сузить период выгрузки и включить аварийный предохранитель для защиты базы.
Так сервис не “падает целиком”, а деградирует управляемо: пользователи могут продолжать работать с основными функциями, пока тяжёлая операция ограничена.
Мягкие и жёсткие меры
Реакции должны отличаться по жёсткости. Мягкие меры подходят для раннего давления: замедление, challenge, временное снижение частоты, отдельные квоты для дорогих операций, ограничение повторных ошибок входа.
Жёсткие меры нужны, когда есть подтверждённая деградация: растут 5xx или latency, перегружается база данных, очередь или внешняя интеграция, а мягкие ограничения не снижают нагрузку достаточно быстро. Сюда относятся массовые ответы 429, блокировки диапазонов, строгие лимиты на методы API, временное отключение ресурсоёмких функций и принудительная проверка клиента.
Право на такие ограничения должно быть заранее закреплено. Обычно дежурный инженер может включать только разрешённые мягкие лимиты и предохранители. Жёсткие меры утверждает менеджер инцидента вместе с владельцем сервиса или продукта, если есть риск повлиять на вход, оплату, партнёрские API или другие критичные сценарии.
По итогу можно сказать, что rate limiting полезен не как единое глобальное правило, а как набор заранее подготовленных сценариев с порогами, владельцами и планом отката. Поэтому следующий слой защиты — не новая технология, а runbook, который определяет, кто принимает решение, какие метрики подтверждают атаку и когда команда может перейти от мягких мер к жёстким.
Runbook реагирования: роли, метрики, решения и провайдер
Если жёсткие лимиты могут задеть клиентов, партнёров и выручку, решение о них нельзя оставлять дежурному инженеру “по ситуации”. Нужен runbook, подготовленный до атаки: роли, каналы связи, доступы, пороги, список разрешённых мер и условия эскалации.
Во время инцидента важно заранее понимать, кто за что отвечает. Менеджер инцидента координирует решения, команда сети/CDN/WAF управляет периметром, владелец приложения и API оценивает влияние на бизнес-сценарии, SRE следит за устойчивостью платформы, безопасность анализирует источники, поддержка передаёт сигналы от пользователей, а отдельный контакт общается с облачным, CDN- или DDoS-провайдером.
Рабочая последовательность должна быть короткой:
- Подтвердить инцидент. Исключить плановый пик, релиз, маркетинговую кампанию, внутренний сбой или ошибку конфигурации.
- Классифицировать давление по метрикам. Проверить bps/pps, SYN/UDP/TCP-индикаторы, dropped/blocked traffic, RPS, 4xx/5xx, latency, CPU/RAM origin, соединения к базе, длину очередей, статистику по endpoint, IP, ASN, географии и user-agent.
- Включить только разрешённые меры. Например, временные лимиты, challenge, блокировки очевидных источников или аварийные предохранители для дорогих операций — в пределах заранее утверждённых прав.
- Следить за легитимным трафиком. Проверять, не выросли ли ложные 429/403, не сломались ли партнёрские интеграции, вход, оплата заказа или критичные API.
- Эскалировать провайдеру. Делать это при L3/L4-давлении, обходе CDN на origin, росте отброшенного трафика, нехватке видимости или если текущие правила не снижают деградацию.
Провайдеру лучше сразу передавать время начала, затронутые сервисы, симптомы, примеры источников/ASN/URI, графики трафика, уже включённые правила и влияние на пользователей. Это ускоряет фильтрацию и снижает риск длинных уточнений в момент, когда каждая минута влияет на доступность.
После атаки нужен разбор: временная шкала, что сработало, что не сработало, где были ложные блокировки, сколько стоила деградация и какие решения запоздали. Runbook снижает не сам объём атаки, а хаос в принятии решений. При этом атака может быть нацелена как раз на это - хаотические решения приводят к ненужным даунтаймам, потерям уровня сервиса, прямым финансовым и репутационным потерям. Поэтому после инцидента важно проводить postmortem-анализ, по результатам которого runbook нужно при необходимости актуализировать: пороги, правила, контакты, права на жёсткие меры и порядок эскалации.
Краткий чек-лист готовности
До атаки команда должна знать нормальные пики трафика, иметь метрики по сети, CDN/WAF, приложению, API и базе, закрытый от прямого доступа origin, контакты провайдера и согласованные права на включение жёстких мер.
Во время атаки важно быстро отличить сетевое давление от HTTP- и API-нагрузки, включать только утверждённые ограничения, следить за ложными 403/429 и отдельно контролировать критичные сценарии: вход, оплату и партнёрские API.
После атаки нужно обновить пороги, правила фильтрации, списки разрешённых сетей, лимиты для дорогих операций, контакты провайдера и сам runbook.
Главный признак готовности — не “включена DDoS-защита”, а понятная цепочка решений: где возникло давление, какой слой его останавливает, кто имеет право усилить меры и как команда возвращает сервис к нормальной работе без лишних блокировок легитимных пользователей.
Заключение
Облачная DDoS-защита должна быть не набором включённых сервисов, а управляемой схемой принятия решений. L3/L4-давление нужно останавливать до инфраструктуры клиента, L7 — фильтровать на уровне HTTP/S, API abuse — ограничивать через квоты, лимиты и защиту дорогих операций.
Runbook связывает эти меры с людьми, метриками, порогами и эскалацией провайдеру. Именно это снижает риск двух крайностей: не успеть остановить атаку или, наоборот, заблокировать собственных пользователей.
FAQ
Чем L3/L4 DDoS отличается от L7 HTTP flood?
L3/L4-атаки давят на сеть и транспортный уровень: растут bps, pps, SYN/UDP/TCP-пакеты, может забиваться канал или сетевой периметр. L7 HTTP flood выглядит как множество HTTP/S-запросов и перегружает уже приложение, backend, CPU, память, соединения или отдельные маршруты.
Почему rate limiting не помогает против всех DDoS-атак?
Rate limiting работает там, где трафик дошёл до HTTP/API-уровня и его можно ограничить по IP, пользователю, ключу, endpoint или сессии. Если канал уже забит UDP- или SYN-потоком, лимиты приложения не сработают вовремя — нужна фильтрация у облачного или DDoS-провайдера.
Нужно ли использовать Anycast, если уже есть CDN?
Anycast и CDN часто работают вместе, но решают разные задачи. Anycast распределяет входящий поток по сети провайдера, а CDN кэширует и проксирует контент. Но ни Anycast, ни CDN не заменяют WAF, защиту origin и отдельные правила для API.
Какие метрики важнее всего смотреть во время атаки?
Минимальный набор: bps, pps, SYN/UDP/TCP-индикаторы, dropped/blocked traffic, RPS, 4xx/5xx, latency, CPU/RAM origin, соединения к базе данных, длина очередей и всплески по endpoint. Дополнительно полезны ASN, география, user-agent и статистика по IP или API-ключам.
Когда стоит эскалировать инцидент провайдеру?
Эскалация нужна при L3/L4-давлении, обходе CDN на origin IP, росте отброшенных пакетов, нехватке видимости, неэффективности текущих правил или угрозе недоступности критичных сервисов. Провайдеру лучше сразу передавать время начала, симптомы, графики, затронутые сервисы и уже включённые меры.
Что делать после завершения атаки?
Нужно разобрать временную шкалу, проверить эффективность фильтрации и лимитов, найти ложные блокировки, оценить влияние на пользователей и бизнес-процессы. После этого обновляют пороги, правила WAF/rate limiting, списки разрешённых сетей, контакты провайдера и runbook.
Список источников
1. AWS — “Best Practices for DDoS Resiliency”
2. Cloudflare Developers — “DDoS Protection: Attack coverage”
3. Microsoft Learn — “Azure DDoS Protection fundamental best practices”
4. OWASP — “API Security Top 10 2023: API4 Unrestricted Resource Consumption”
