On-Demand или Always-On: что молчаливо стоит за выбором защиты от DDoS
📊 On-Demand или Always-On: что молчаливо стоит за выбором защиты от DDoS
Первый порыв при аномальном всплеске — врубить фильтры. Ошибка в том, что DDoS-защита начинается не с выбора сервиса, а с диагностики. Маркетинговая акция, наплыв реальных заказов, как у «Тануки» на 8 Марта, или собственный мониторинг, генерирующий тяжёлые запросы, — всё это выглядит как атака. Ключ к различению — анализ логов: однородные запросы, неестественно стабильный уровень RPS и отсутствие загрузки статики отличают ботовую атаку от легитимного всплеска.
По данным habr_infosec, после подтверждения атаки развилка между моделями Always-On и On-Demand становится главным архитектурным решением. Always-On непрерывно прогоняет весь трафик через фильтрующие узлы. Атака нейтрализуется мгновенно, без «окна уязвимости». Плата за это — постоянная, высокая стоимость, но простой в секунду для банка или игровой платформы обходится дороже.
On-Demand дешевле, защита включается по факту атаки. Здесь и зарыт главный риск — задержка активации. На практике система тратит от нескольких секунд до минут на обнаружение, принятие решения и переключение трафика. Для импульсных волновых атак с максимальной мощностью на старте это критично: первая волна кладёт сервер, защита включается, когда атака уже стихла, а вторая волна накрывает после отключения сервиса. Для 70-80% проектов с атаками реже раза в квартал On-Demand остаётся разумным выбором, но только при наличии заранее подготовленных шаблонов фильтрации и резервных каналов.
On-Demand только выглядит дешевле. Для сред с SLA 99.5%+ он обходится на 20-40% дороже Always-On — потому что требует собственной команды, способной зафиксировать, подтвердить и переключить трафик за 5 минут в три часа ночи. Посчитайте не стоимость сервиса, а стоимость содержания такой команды за 5 лет.
#DDoS #AlwaysOn #OnDemand #SOC #FinOps