Я довольно новичок в инфраструктурах облачных платформ. Для простоты обсуждения предположим, что единственные две платформы, которые я обсуждаю, это AWS и Google Cloud.
Теперь предположим, что у меня есть HTTP-сервер, который в основном обрабатывает HTTP-ответы через открытый API для онлайн-игры. Допустим, средний размер ответа составляет 10 КБ, и в день будет отправляться около миллиона ответов.
Исходя из моего понимания, ежемесячная цена зависит от объема переданных данных в ГБ. Теперь моя проблема в том, что если кто-то напишет скрипт, который будет постоянно получать ответ от моего сервера, цена просто вырастет до небес.
Я уверен, что любой хороший сервер избегает этой проблемы, но я не уверен, как именно эта проблема избегается. По моим наблюдениям, многие реальные большие серверы API онлайн-игр не оптимизируют размер своего ответа, когда он составляет всего несколько КБ. Должно быть, есть что-то вроде "фиксированная ежемесячная оплата или оплата на основе объема переданных данных в секунду"происходит нечто, не зависящее от объема переданных данных.
Однако я просто не смог найти никаких ссылок на сайты платформ о таких вариантах.
Любая помощь будет оценена по достоинству.
решение1
Облачные сервисы предоставляют потрясающие преимущества для проектов, которые специально созданы для их использования. Если мы говорим о хостинге приложений/веб-сайтов, то облачные модели ценообразования подходят для бизнеса, который получает свой основной доход от пользователей, которые используют это приложение/веб-сайт.
Если это не ваш основной источник дохода (в этом случае вы легко сможете конвертировать сырой веб-трафик в прибыль), то облачный хостинг может вам вообще не подойти.
Помните, что если ваше приложение не было создано для облачной инфраструктуры (как упомянутый игровой сервер), у вас не будет никаких преимуществ по сравнению с одноэкземплярным VPS/выделенным хостингом, если только вы не потратили некоторое время на работу devops. Та же работа devops необходима для эффективного предотвращения атак на вашу пропускную способность, которую вы описали.
Поскольку этот тип атаки уже имеет название, вы можете найти более или менее действенные советы, выполнив поиск по запросу "Отказ от кошелька"
решение2
Ни один из поставщиков облачных услуг не предлагает XX пропускной способности по фиксированной цене. Цены устанавливаются на основе потребления.
Вы несете ответственность за контроль доступа клиентов к вашим ресурсам.
Это означает развертывание аутентификации, регулирования или других технологий, но вы сами выбираете, как и с какими продуктами это сделать.
Облачные сервисы очень похожи на строительство дома. Home Depot не дает вам неограниченное количество гвоздей и пиломатериалов. Вы покупаете то, что вам нужно для строительства дома. Затем вы покупаете топливо для отопления дома.
Я работаю в облаке с нулевого дня. До этого были частные центры обработки данных. Ваше беспокойство возможно, но в реальном мире этого не происходит достаточно, чтобы остановить большинство из нас от развертывания в облаке. Чтобы потреблять вашу пропускную способность, мне нужно потреблять мою доступную пропускную способность сети. Если хакер хочет вас уничтожить, есть много более болезненных методов, которые они могут применить, которые намного дешевле для них и которые сложнее отследить, кто/где они находятся.
решение3
На стороне сервера этого можно избежать следующими способами:
- Требовать аутентификацию для запросов. IOW, сделайте так, чтобы можно было отслеживатьВОЗделает такие атаки, и делает такие атаки нарушением, за которое можно получить бан. Затем должным образом заблокируйте создание учетной записи, чтобы было нелегко получить новые учетные данные после того, как вас забанят.
- Реализуйте ограничение скорости. Обычно это делается в несколько этапов, часто ограничивая скорость для каждой аутентифицированной учетной записи (чтобы у любого пользователя был предел скорости), для каждой конечной точки API (чтобы вычислительно затратные конечные точки, которые не вызываются очень часто, не могли быть легко использованы для DoS-атак) и, возможно, для каждого IP-адреса в целом. Вы должны делать это по другим причинам (в первую очередь для защиты от интеллектуальных DoS-атак и возможности атак на основе времени на игровую логику).
- Используйте хорошее сжатие в протоколе. Для вашего заявленного размера ответа, вероятно, стоит рассмотреть Brotli (или, возможно, snappy или LZ4), он должен быть достаточно быстрым, чтобы удовлетворить ваши потребности в производительности, но все же сократить несколько килобайт размера ответа, и в момент обработки миллионов запросов в месяц это нетривиальный объем сохраненных данных.
Что касается смягчения его в других местах, это не так просто сделать. Поставщики полного облака, о которых вы говорите, часто предоставляют некий минимальный «бесплатный уровень», чтобы разработчики могли легко экспериментировать, не тратя при этом ни руки, ни ноги. Я думаю, что для AWS это 5 ГБ в месяц исходящих данных (они вообще не взимают плату за входящие данные), например. Это самое близкое, что вы можете получить в такой полной облачной настройке, чтобы заблокировать использование, о которой вы говорите, потому что большинство пользователей выиграют от того, что будут иметьточныйпропорциональное использование в отличие от покупки «по частям».
Если вы действительно хотите большой кусок, посмотрите на AWS Lightsail. Там вы покупаете пакетную сделку виртуального узла, который включает некоторое фиксированное количество ЦП, фиксированный объем ОЗУ и интегрированного хранилища, а также указанный лимит использования сети. Использование сети ниже этого лимита в платежном цикле ничего не стоит, тогда как выше пропорционально распределяется, как в полной облачной настройке. Я не знаю, есть ли у GCP эквивалент, но большинство поставщиков VPS (таких как Vultr, Linode или Digital Ocean) работают так же для своих основных предложений, и я бы на самом деле рекомендовал поискать их вместо этого, если вы пойдете по этому пути. Лимиты сети на них обычно находятся в диапазоне нескольких терабайт, и нормой является то, что для учета отслеживается только направление с более высоким использованием.