Как снизить нагрузку на серверную часть, вызванную вредоносным трафиком

Я хочу уменьшить или смягчить последствия вредоносного трафика уровня 7 (целевые атаки, стандартное злонамеренное автоматическое сканирование), который достигает моего бэкэнда, что делает его очень медленным и даже недоступным. Это касается атак на основе нагрузки, как описано в https://serverfault.com/a/531942/1816

Предположим, что:

1. Я использую не очень быстрый бэкэнд / CMS (например, TTFB ~ 1500 мс для каждой динамически генерируемой страницы). Оптимизировать это невозможно или просто очень дорого с точки зрения усилий.
2. Я полностью увеличил масштаб, то есть я использую максимально быстрое H / W.
3. Я не могу масштабироваться, т.е. CMS не поддерживает репликацию master-to-master, поэтому она обслуживается только одним узлом.
4. Я использую CDN перед серверной частью, достаточно мощный, чтобы обрабатывать любой трафик, который кэширует ответы на долгое время (например, 10 дней). Кешированные ответы (обращения) бывают быстрыми и больше не касаются моего серверного интерфейса. Промахи, очевидно, дойдут до моего бэкэнда.
5. IP моего бэкэнда неизвестен злоумышленникам / ботам.
6. Некоторые варианты использования, например запросы POST или зарегистрированные пользователи (небольшая часть от общего использования сайта), настроены на обход кеша CDN, поэтому они всегда попадают в серверную часть.
7. Изменение чего-либо в URL таким образом, чтобы сделать его новым / уникальным для CDN (например, добавление &_foo=1247895239) всегда будет попадать в бэкэнд.
8. Злоумышленник, который сначала изучил систему, очень легко найдет очень медленные варианты использования (например, страницы с разбивкой на страницы до 10.000-го результата), которыми он сможет злоупотребить вместе со случайными параметрами # 7, чтобы поставить серверную часть на колени.
9. Я не могу предсказать все известные и действительные URL-адреса и допустимые параметры моего бэкэнда в данный момент времени, чтобы каким-то образом внести запросы в белый список или очистить URL-адрес в CDN, чтобы уменьшить количество ненужных запросов, достигающих бэкэнда. например /search?q=whatever и /search?foo=bar&q=whatever на 100% даст тот же результат, потому что foo=bar это не то, что использует мой бэкэнд, но я не могу очистить его на уровне CDN.
10. Некоторые атаки происходят с одного IP-адреса, другие - со многих IP-адресов (например, 2000 или более), которые невозможно угадать или легко отфильтровать по диапазонам IP-адресов.
11. И провайдер CDN, и провайдер серверного хоста предлагают какую-то функцию DDoS-атак, но атаки, которые могут вывести из строя мою бэкэнд, очень малы (например, всего 10 запросов в секунду) и никогда не рассматриваются как DDoS-атаки со стороны этих провайдеров.
12. У меня есть мониторинг, и я мгновенно получаю уведомления, когда серверная часть подвергается стрессу, но я не хочу вручную запрещать IP-адреса, потому что это нежизнеспособно (я могу спать, работать над чем-то еще, в отпуске или атака может быть со многих разных IP-адресов).
13. Я не решаюсь вводить ограничение на количество подключений в секунду для каждого IP-адреса на серверной части, поскольку в какой-то момент я откажу в доступе законным пользователям. Например, представьте себе презентацию / семинар о моем сервисе, проходящую в университете или крупной компании, где десятки или сотни браузеров почти одновременно будут использовать сервис с одного IP-адреса. Если они вошли в систему, то они всегда будут доходить до моего сервера и не будут обслуживаться CDN. Другой случай - пользователи государственного сектора, которые получают доступ к услуге с очень ограниченного количества IP-адресов (предоставленных государством). Таким образом, это откажет в доступе законным пользователям и совсем не поможет атакам со многих IP-адресов, каждый из которых выполняет только пару запросов.
14. Я не хочу постоянно заносить в черный список определенные большие диапазоны IP-адресов стран, которые иногда являются источниками атак (например, Китай, Восточная Европа), потому что это несправедливо, неправильно, откажет в доступе законным пользователям из этих регионов, а атаки из других мест не будут подвержен влиянию.

Итак, что я могу сделать, чтобы справиться с этой ситуацией? Есть ли решение, которое я не учел в своих предположениях, которое могло бы помочь?