Представьте, что вы создали пустую, приватную корзину (их ещё называют «бакетами» — от «bucket») AWS S3 в выбранном вами регионе. Каким будет счёт за услуги AWS на следующее утро?
Несколько недель назад я начал работу над прототипом системы индексирования документов для моего клиента. Я создал одну корзину S3 в регионе eu-west-1 и загрузил туда несколько файлов для тестирования. Через два дня я проверил мою страницу выставления счетов AWS, заглянув туда, преимущественно, для того, чтобы проверить, что то, чем я занимаюсь, нормально укладывается в лимиты бесплатного тарифного плана. Но, судя по тому, что я там увидел, ни о какой нормальности речи не шло. Мой счёт превышал $1300, а в консоли выставления счетов были видны сто миллионов PUT-запросов к корзине S3, выполненных всего за один день!
Откуда приходят эти запросы?
AWS, по умолчанию, не логирует запросы, выполняемые к корзинам S3. Но их логирование можно включить, используя AWS CloudTrail или S3 Server Access Logging. После включения логов CloudTrail я сразу же обнаружил тысячи запросов на запись, исходящих как от множества аккаунтов AWS, так и из-за пределов этой платформы.
Но почему посторонние заваливают мою корзину S3 неавторизованными запросами?
Может, это было что-то вроде DDoS-атаки на мой аккаунт? Или — это была атака на AWS? Как оказалось — один из популярных опенсорсных инструментов по умолчанию настроен на сохранение бэкапов в S3. И разработчики этого инструмента использовали в виде текстовой заглушки для имени корзины… то же имя, которым я назвал свою корзину. Это значит, что любой установленный экземпляр инструмента, в котором применяется его стандартная конфигурация, пытается сохранить бэкап в мою корзину S3!
Обратите внимание на то, что я не могу раскрыть название инструмента, о котором рассказываю, так как это подвергнет компании, затронутые проблемой, угрозе утечки данных (позже я к этому вернусь).
В результате получается, что полчища неправильно настроенных систем пытаются сохранить свои данные в моей приватной корзине S3. Но почему кто-то должен платить за эту ошибку? А вот почему.
S3 берёт деньги за неавторизованные входящие запросы
Это подтверждает общение с поддержкой AWS. Вот что они написали:
Да, S3 берёт плату и за неавторизованные запросы (4xx) [1]. Это — ожидаемое поведение системы.
Предположим, я сейчас открою терминал и введу команду такого вида:
aws s3 cp ./file.txt s3://your-bucket-name/random_keyМне достанется сообщение об ошибке AccessDenied, а владелец корзины будет тем самым человеком, который заплатит за этот запрос. И мне, чтобы это сделать, даже не нужна учётная запись AWS.
Меня беспокоил ещё один вопрос: почему запросы, оплата которых составляет большую часть счёта, поступили из региона us-east-1? У меня нет ни единой корзины в этом регионе! Ответ на этот вопрос заключается в том, что S3-запросы без указанного региона, по умолчанию, считаются относящимися к региону us-east-1, и, при необходимости, перенаправляются. А владелец корзины доплачивает и за эти перенаправленные запросы.
Вопрос безопасности
Теперь мы разобрались с тем, почему мою корзину S3 заваливали миллионами запросов, и с тем, почему, в итоге, это привело к огромному счёту. В этот момент у меня появилась ещё одна идея, которую мне захотелось исследовать. Если все эти неправильно настроенные системы попытаются отправить бэкапы своих данных в мою корзину S3 — почему бы мне просто не позволить им это сделать? Я открыл свою корзину для публичного доступа на запись и, менее чем за 30 секунд, собрал более 10 Гб данных. Конечно, я не могу рассказать о том, чьи это были данные. Но меня прямо-таки поразило то, как невинный недосмотр в настройках может привести к опасной утечке данных!
Какие уроки я из всего этого вынес?
Урок 1: кто угодно, знающий имя любой из ваших корзин S3, может задрать ваши счета в AWS до какого угодно уровня.
Единственный способ этому помешать — удалить корзину. Если к корзине обращаются напрямую через API S3 — её нельзя защитить с помощью служб наподобие CloudFront или WAF. Стоимость стандартных PUT-запросов S3 составляет $0,005 за 1,000 запросов, но всего один компьютер легко способен выполнить тысячи подобных запросов в секунду.
Урок 2: добавление случайного суффикса к именам корзин может улучшить безопасность.
Этот подход позволяет снизить риск обращений к корзинам, исходящих от неправильно настроенных систем, а так же — риск целенаправленных атак. Давая имена корзинам S3, стоит, как минимум, избегать использования коротких, распространённых слов.
Урок 3: если требуется выполнять много запросов к S3 — стоит проверить, задан ли явным образом нужный регион AWS.
Это позволит избежать дополнительных расходов на перенаправление запросов API S3.
Итоги
Я сообщил о результатах моих изысканий тем, кто поддерживает уязвимый опенсорсный инструмент. Они быстро исправили стандартную конфигурацию, но внести исправления в уже установленные копии инструмента они не могут.
Я уведомил о произошедшем команду безопасности AWS. Я предложил ей ограничить возможность использования несчастного имени корзины S3 для того, чтобы, во-первых — оградить их пользователей от неожиданных трат, и во-вторых — чтобы защитить компании, на которые подействовала эта проблема, от утечек данных. Но команда безопасности не расположена решать проблемы настроек сторонних продуктов.
Я сообщил о проблеме двум компаниям, данные которых нашёл в своей корзине. Они не ответили на мои электронные письма, возможно, сочтя их спамом.
Сотрудники платформы AWS были так добры, что аннулировали мой счёт. Правда, они особо отметили, что сделано это было в порядке исключения.
Спасибо, что нашли время и прочли мой материал. Надеюсь, он поможет вам держаться подальше от неожиданных расходов в AWS.
О, а приходите к нам работать? ? ?
Мы в wunderfund.io занимаемся высокочастотной алготорговлей с 2014 года. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.
Мы предлагаем интересные и сложные задачи по анализу данных и low latency разработке для увлеченных исследователей и программистов. Гибкий график и никакой бюрократии, решения быстро принимаются и воплощаются в жизнь.
Сейчас мы ищем плюсовиков, питонистов, дата-инженеров и мл-рисерчеров.
Комментарии (99)
vdudouyt
10.02.2025 09:35Тем не менее, самый главный урок так и не был усвоен: хотя нафталиновые dedicated-сервера и не очень-то стильно смотрятся со стаканом смузи из сельдерея, они не так уж и плохи.
gun_dose
10.02.2025 09:35Если вам нужно хранить сотни гигабайт файлов, что s3 будет сильно дешевле выделенного сервера с таким объёмом хранилища. Одному клиенту перенесли файлы на s3, только не Амазон, а на местного провайдера. В итоге его затраты на инфраструктуру уменьшились на 3000$ в год. Это более, чем в два раза.
Но если такие объёмы хранилища не нужны, то безусловно дедик или VPS будет сильно дешевле, тут вы правы.
Goron_Dekar
10.02.2025 09:35Вы тоже не усвоили этот урок.
Скажите, как вы в вашем кейсе "затраты на инфраструктуру уменьшились на 3000$" учли непредсказуемость ценообразования и риски от возможных санкционных/политических проблем? Каково матожидание того, что этот s3 будет работать для этого клиента весь год? Каков ущерб потери этих данных?
Нет, пока у вас сотни гигабайт, а не сотни террабайт, пока всё это влезает в стандартные блейды дедик всё-таки дешевле.
gun_dose
10.02.2025 09:35Я же написал "перенесли файлы на s3, только не Амазон, а на местного провайдера". Местный означает, что офис клиента и сервер с файлами географически находятся в одной стране. И даже в одном городе.
Риск непредсказуемости ценообразования решён был тем, что сайты наших клиентов уже много лет хостятся у этого провайдера, поэтому у нас был персональный менеджер, с которым можно было решить все проблемы.
Итого, на сегодняшний день клиент суммарно сэкономил порядка 15 тысяч долларов. И никаких непредсказуемых вещей за 5 лет не произошло, что говорит о том, что расчёт был сделан верно.
PS: на всякий случай поясню, если вдруг кто не знает, что есть такое понятие как "S3-совместимое хранилище", которое предоставляют большинство крупных хостинг-провайдеров по всему миру. В том числе и в странах СНГ. Все CLI-инструменты, библиотеки, интеграции с операционными системами и прочее с этими провайдерами работает абсолютно так же, как с Амазоном.
Goron_Dekar
10.02.2025 09:35Хорошо. $15k сэкономленных на хранилище наводят меня на мысль, что изначально там всё было не на дедиках, а на не-S3 облаках. Как можно сэкономить на одном-двух блейдах такую сумму ума не приложу. Однако верю, что всё так и было. Просто меня обилие этих вот статей про непрозрачность современных S3-like облаков изрядно напрягает. И кажется, что актуальность таких решений работает только начиная с масштаба "нас был персональный менеджер, с которым можно было решить все проблемы".
gun_dose
10.02.2025 09:3515 тысяч - это 300 долларов в месяц в течение 5 лет. Там обычный VPS хостинг. Вот прямо сейчас смотрю разницу между VPS на 30ГБ и на 510ГБ (это максимальный объём, который можно у них сейчас взять). В зависимости от остальных параметров разница 100-150 долларов в месяц. Но там речь шла о цифрах 600-800ГБ с возможностью расширения. При этом хранить на s3 1 терабайт данных обходится всего в порядка 40 долларов в месяц. Сейчас вижу, что цифра в 300 долларов в месяц, вероятно, завышена (это наши маркетологи считали 5 лет назад). Но очевидно, что это минимум 100$ в месяц, что для того клиента уже двукратная экономия.
Вообще, S3 - это реально выгодная штука. Даже для обычного магазина на 30 тысяч товаров это уже выгодно. Единственный минус - время ответа сервера на отдачу файла будет минимум 150мс. Но скорее всего будет ближе к 300мс.
А вот где начинается жесть - это другие сервисы Амазон: EC2, RDS и т.д. Они заманивают маленькой стоимостью простых инстансов, но оказывается, что самый маленький EC2 вообще ничего не тянет, и надо брать побольше. А если у тебя 100% загрузка ЦП в течение 10 секунд и более, то тебе делают 10-кратный троттлинг процессора, в результате чего все твои приложения зависают намертво, помогает только рестарт инстанса. Чтобы этого избежать, надо брать инстансы чуть пожирнее, но всё равно 10 человек (да, всего десять) могут сговориться и зайти на твой сайт одновременно, из-за чего он опять зависнет. Поэтому нужно настраивать автомасштабирование. Для этого нужен хороший спец, а у них расценки от 50$ в час. И вот как раз из-за множественных прецедентов разбухания счетов за AWS тебе надо будет, чтобы этот спец не только всё хорошо настроил, но и посидел, помониторил нагрузки, многократно всё проверил. А там глядишь, неделя прошла - 2000$ только за настройку. А потом ты наймёшь сеошника, он скажет, надо просканировать сайт сеошной тулзой, чтобы проверить ошибки, и у тебя опять всё висит, опять вызывай девопса за 50$ в час и потом ещё отслюнявь Безосу пару косарей сверх обычного счёта.
У коллеги с бывшей работы есть клиент, который за хостинг AWS платит 2-3 тысячи $ в месяц и постоянно какие-то траблы. При том, что всё это можно было бы развернуть на Digital Ocean на дроплете за 300 долларов и всё бы просто летало. Но клиент ни в какую не хочет на обычный сервер, хочет по-модному. Я уже даже предлагал перенести всё тайком на DigitalOcean и сделать фэйковую админку облачного сервиса, чтобы просто рандомные графики ползли, чтобы клиент смотрел на графики, платил коллеге 2000$, а тот бы 1700 оставлял себе :D
А сколько стартапов загнулось просто из-за таких оверпрайсов за инфраструктуру, не счесть...
N-Cube
10.02.2025 09:35Вы что-то не то рассказываете. К примеру, если вам надо сложную обработку терабайтов геоданных за день выполнить, разворачиваете пачку инстансов RDS и один EC2 для загрузки и выгрузки данных, все делаете и удаляете все ресурсы. Вместо этого, вы хотите за сотню инстансов Digital Ocean минимум месяц платить?.. Аналогично с server-less functions - в облаке сотня тысяч запусков в сутки бесплатно, а с учетом неравномерности нагрузки на Digital Ocean вы будете немало за VPS платить, чтобы выдержать аналогичный трафик в пиковое время (скажем, тысячи обращений в секунду к разным ресурсам).
gun_dose
10.02.2025 09:35Во-первых, на DO тарификация почасовая, поэтому сразу за месяц платить совсем не обязательно.
Во-вторых, на DO и других подобных провайдерах есть автоматизация балансировщика нагрузки, чтобы увеличивать пропускную способность в пиковое время.
Ну и в-третьих, вы как раз привели пример, когда структура AWS даёт реальные преимущества. На деле же люди слушают всё это про терабайты, масштабирование, гибкость и т.д. и тоже думают, что им всё это надо, потому что у них "тоже микросервисы", а на деле там обычный фронт на нексте и бэк на пыхе и всё это разворачивается элементарно на чём угодно в 10 раз дешевле и проще, чем на амазоне.
N-Cube
10.02.2025 09:35Если тарификация почасовая, то чем оно отличается от амазоновского EC2 инстанса?
Это если пиковое время предсказать можно. Вот десяток или сотня студентов по команде преподавателя запускают мой софт, и за несколько секунд тысячи или десятки тысяч разных запросов к серверам отправляются. Ща один день это может произойти много раз или ни разу. Некогда тут масштабированием заниматься, а облачные функции легко справляются.
Насчет сценариев использования - практически всегда можно построить архитектуру, которая оптимальна для облаков. Другой вопрос, что это может быть не оправдано, когда уже есть рабочее решение. Попытка же перенести старый и часто «кривой» софт в облако это проблема квалификации, а вовсе не недостаток облачных сервисов.
vmarunin
10.02.2025 09:35А если вам надо обработку петабайтов данных, вы разворачиваете пачку инстансов и вам говорят "а нету" (квота превышена). И всё. Надо просить повысить квоту. А с той стороны логично говорят, что надо бы поучаствовать финансово. Так как простаивающие 75% времени сервера никому не нужны.
Облако имеет ещё и ограничение сверху, это тоже надо не забывать. Такое большое облако как AWS имеет большое ограничение, но не бесконечное.N-Cube
10.02.2025 09:35Как будто вы в М-Видео просто зайдете и купите хранилище на петабайты, без предзаказа и прочих согласований. Помнится, как-то нужен был сервер с 6 TB RAM в облаке амазон, за несколько часов по заявке квоту повысили и за час меньше чем за 30$ я все вычисления выполнил (на меньших инстансах было на порядки дольше считать, а заказчик хотел оперативно получить результат). Сколько времени вам такой сервер по предзаказу везти будут и во что вам он обойдется?..
Goron_Dekar
10.02.2025 09:3515 тысяч - это 300 долларов в месяц в течение 5 лет. Там обычный VPS хостинг.
Как я и говорил, это не дедикейтед
Беглый поиск нашел дедик в ниделандах с 22TB HDD за $70-80 в мес.
N-Cube
10.02.2025 09:35А если почитать условия https://www.digitalocean.com/community/tools/bandwidth, то уже за 10TB трафика в месяц еще столько же получится:
Estimated consumption: 10,000 GiB
Estimated overage: $80 (8,000 GiB @ $0.01 / GiB)При сотне терабайт платного трафика за килобакс, возможно, до вас таки дойдет мысль, что что-то идет не так :)
Goron_Dekar
10.02.2025 09:35А вот это вот факт! Ок, убедили. S3 может быть существеннее дешевле дедика для маленькой конторы с 20TB объёма в закрытом рынке за стеной от РКН.
gun_dose
10.02.2025 09:35То есть сначала вы пишете:
Скажите, как вы в вашем кейсе "затраты на инфраструктуру уменьшились на 3000$" учли непредсказуемость ценообразования и риски от возможных санкционных/политических проблем? Каково матожидание того, что этот s3 будет работать для этого клиента весь год? Каков ущерб потери этих данных?
А потом:
Беглый поиск нашел дедик в ниделандах с 22TB HDD за $70-80 в мес.
Даже не верится, что один пользователь мог написать два настолько противоречащих комментария. Надеюсь вы понимаете, что дедик с 22тб за 70 долларов происходит не от слова dedicated, а от слова dead?
Для справки дедик у приличного провайдера в СНГ с 1ТБ ssd обходится в 200-300$ в месяц. Что приблизительно на 30% дороже, чем VPS.
Goron_Dekar
10.02.2025 09:35Ok,ok!
Я российских реалий знаю очень плохо.
Нидерландский дедик за $80/month нормально работает, слова dead там не встречалось. Но, да, если пользователь за РКН-стеной, то надо рассматривать хостинг в рф, тут ничего не попишешь. И приходится платить x3 от рынка.
gun_dose
10.02.2025 09:35Например, у Hetzner или OVH цены значительно выше тех, что вы привели. А платить втрое дешевле рынка за железо со свалки - ну такое. Даже если оно "нормально работает". Соглашусь, что для некоммерческого или низкомаржинального проекта, где никто тебя не засудит за потерю данных, это вполне себе рабочий вариант. Но напомню, что это не я завёл разговор про риски, санкции и SLA.
N-Cube
10.02.2025 09:35Не на те цифирки смотрите, вестимо. Сколько вам будет стоить резервирование, выделенный канал, трафик и срочная техподдержка, доступная 24/7? А просто железка без какой-либо гарантии работоспособности и доступности это не сервер.
gun_dose
10.02.2025 09:35Ладно, берём :D Не сразу увидел опцию добавления дополнительного диска. Но опять же надо учитывать, что S3 подразумевает репликацию данных, что даёт достаточно высокую отказоустойчивость. И уж тем более по сравнению с одним HDD. Понятно, что можно и самому на дедиках настроить репликацию, но это будет уже не 78 долларов.
santjagocorkez
10.02.2025 09:35А почему ты рассматриваешь дедик именно под данные, а сравниваешь с s3, который имеет oversubscription, shared compute и прочие прелести?
Ну закидай свой дедик дополнительной нагрузкой: веб-сайтик там, СУБД, балансировщик, мониторинг, что там ещё тебе нужно. В общем, примени к дедику те же низкие требования по SLA, на которые ты соглашаешься в случае с s3, и считай на круг.
@N-Cube: кстати, да, сколько там в Амазоне стоит поддержка 24/7?
shornikov
10.02.2025 09:35сидел на микро. С посещаемостью по гугль-аналитике >20К "сейчас на сайте". Только пришлось своп добавить.
Driver86
10.02.2025 09:35Если вы крупная компания, ваши расходы - это не только железо, но и человеко-часы, то конечно s3 вам обойдется дешевле выделенного сервера, т.к. s3 упрощает очень многие административные задачи, т.е. платить программистам придётся намного меньше.
В моем проекте сотни миллионов файлов, терабайты данных, и выделенный сервер оказался дешевле. Но там только я один, конечно пришлось хорошо "попрограммировать", что бы хранить это всё эффективно, но время не жалко, ведь это хобби, которое приносит деньги.
Такие дела...gun_dose
10.02.2025 09:35Если вы работаете один, то та крупная компания, о которой я рассказывал, была в три раза больше вас.
santjagocorkez
10.02.2025 09:35Чтобы эти два решения вообще можно было сравнивать, приведи, пожалуйста, SLA для обоих. Ну, чтобы не получилось, например, что к дедикам выставлялась нулевая терпимость к потере данных, а «местный s3 за сохранность ответственности не несет».
gun_dose
10.02.2025 09:35Не выдумывай глупостей. Возьми провайдера, SLA которого тебе по душе и сравни в рамках этого провайдера цену гигабайта на дедике и цену гигабайта на S3. Там в 5-10 раз будет разница.
santjagocorkez
10.02.2025 09:35То есть, SLA в барметале и в облаке (местном или глобальном) отличаются. Вот отсюда и разница в цене. Амазон с теми же SLA, что в барметале, был бы ещё дороже, чем барметал.
shornikov
10.02.2025 09:35Хранить и смотреть - наверное. Но, если вдруг вам понадобятся все эти данные...
N-Cube
10.02.2025 09:35Мои опенсорс проекты терабайт десять трафика в месяц создают, и все это бесплатно крутится в «облаках». Просто, удобно, надежно, и бесплатно - а вы что можете предложить взамен? Касаемо AWS, так они давно известны тем, что то ненужные бэкапы делают и берут деньги за хранение, то другими способами денег сдирают, все это при фактическом отсутствии лимитов (которые вроде бы есть, но применяются очень запоздало) может дорого обойтись. Давно удалил там учетную запись, во избежание.
kisskin
10.02.2025 09:35у меня тройка Тб трафика, средняя нагрузка на проц в 70-90% (i5-13600K), ~6ТБ SSD, ~30 ТБ HDD, я даже не хочу знать, сколько бы мне это обошлось в облаке, а сейчас это обходится в 2 провайдера на 2тр/месяц и периодические расходы на аккумуляторы для UPS.
N-Cube
10.02.2025 09:35Вы утверждаете, что у вас распределенные по всей планете сотни серверов с резервированием, высокоскоростным интернет каналом и дисками на ~6ТБ SSD, ~30 ТБ HDD каждый стоят в сумме 20 баксов в месяц? Или вы системник с помойки в бабушкиной тумбочке сравниваете с CDN? Будьте любезны привести пруф на такой тарифный план, а то ваша адекватность вызывает сомнения.
CherryPah
10.02.2025 09:35Вы утверждаете, что у вас распределенные по всей планете сотни серверов с резервированием, высокоскоростным интернет каналом и дисками на ~6ТБ SSD, ~30 ТБ HDD каждый стоят в сумме 20 баксов в месяц? Или вы системник с помойки в бабушкиной тумбочке сравниваете с CDN?
Нет не утверждаю. Просто для перелива бэкапов бэкапов фотографий меня и моей
сранойлюбимой кошки CDN как бы не особо и нужен.Если у бизнеса 90% клиентов находится в ДС, его не особо волнует время отклика из префектуры Хиросима
N-Cube
10.02.2025 09:35Выше речь про проекты (спутниковой интерферометрии) с множеством пользователей, распределенных по всей планете, притом, с бесплатной работой в облаке. Вы же сопоставили это со своим домашним хранилищем под кроватью, да еще и не бесплатным, потому что за интернет канал вы платите.
vdudouyt
10.02.2025 09:353 Тб трафика в месяц это совсем немного. Давайте зайдем на сайт Amazon и посчитаем.
Согласно информации указанной в разделе S3 -> Data Transfer, на момент создания данного комментария первые 10 Тб трафика в месяц в локации us-east-1 стоят $0.09 за Гб. Путем нехитрых арифметических вычислений получаем 3*1024*$0.09 = $276.48 в месяц (и это только за трафик). Вот такой вот "pay for what you use".
О чем действительно страшно подумать так это о том, сколько согласно этим тарифам должен был бы платить тот же Github. Хотя, наверняка к ним прикреплен свой личный менеджер по VIP-клиентам с членством в местном гольф-клубе. Да и уверен, что маркетинговая повесточка для Amazon тоже роляет.upd. Хотя нет, только что проверил - Github уже свинтил обратно на бренную землю.
N-Cube
10.02.2025 09:35Трафик это ерунда, а вот GitHub Action Runners позволяют огромное количество работы выполнять бесплатно. Во многих проектах на каждый коммит запускаются тесты, собираются докер образы и так далее. А теперь у них еще и arm64 инстансы есть!
QuarkDoe
10.02.2025 09:35Т.е. получается, что зная имя чьего-то существующего бакета я могу тупо его заддосить и подставить владельца на серьёзные траты?
Б - безопасность.
Tsimur_S
10.02.2025 09:35Забавный факт №2 - получается что те компании которые неправильно настроили stress load и нанесли 1300$ ущерба они не виноваты, у них лапки.
Но при этом если ты откроешь возможность записи и попытаешься монетизировать то что они туда пишут то это уже уголовная статья, по версии автора.
SemenMartynov
10.02.2025 09:35Автор оригинального поста так же сообщает, что команда S3 уведомлена о проблеме и работает над её исправлением.
sberoneshot
10.02.2025 09:35Т.е. теперь можно написать ПО, которое вместо 200 будет отдавать 3хх/4хх и вообще все запросы (даже ваши собственные) станут бесплатными?
korzhkov
10.02.2025 09:35Более того, амазон уже давно пофиксил это, почти год назад https://aws.amazon.com/ru/about-aws/whats-new/2024/05/amazon-s3-no-charge-http-error-codes/
hogstaberg
10.02.2025 09:35Ну так оригинальная статья и была больше года назад. В ответ на неё и пофиксили)
Iv38
10.02.2025 09:35Посмотрел документацию Yandex Cloud Object Storage:
Примечание
Операции GET, HEAD, OPTIONS, PATCH, POST и PUT, закончившиеся с ошибками 403 или 404, тарифицируются. При расчете стоимости применяются тарифы для стандартного хранилища.
Страшно жить!
xSVPx
10.02.2025 09:35Так любой ддос тарифицируется, работа то сделана. Я этого всего уже лет десять боюсь :), ну т.е. боялся, с asw пришлось съехать на vpsы и как-то даже "выдохнул".
Еще хуже с email. Если у вас есть любая форма подтверждения подписки скажем, то если спамить в неё чужие адреса, то жертвам приходит письмо типа "подтвердите что это вы регистрируетесь там то" и они начинают это все помечать спамом для гугла итп. И как эту коллизию разрешить совершенно непонятно.
Iv38
10.02.2025 09:35Понятно, что у них есть основания тарифицировать этот трафик. Но это ведёт к тому, что он может использоваться для атак. И с одной стороны владельцу сервиса как бы всё равно, он деньги получит, даже избыточные. Но это и привлекательности для клиентов угрожает. Наверное, лучше эти запросы не тарифицировать, а компенсировать их стоимость чуть более высокой стоимостью остальных запросов. Тогда не будет стимула использовать их для атак на кошелёк клиентов сервиса. Тогда появляется возможность атаки на сам сервис. Но у них и возможности для борьбы с этим больше, чем у клиентов.
xSVPx
10.02.2025 09:35У них до сих пор же кредитная система оплаты услуг и до сих пор нет возможности ставить лимиты на этот кредит ? (оповещения можно было подключить)
Некоторые вещи сделаны очень печально, и есть четкое ощущение, что специально. Кто-то считает, что так и должно быть...
KivApple
10.02.2025 09:35Капча на такие операции (отправка емейла на произвольный адрес) должна потенциально снижать риски. Как минимум будет выше стоимость атаки.
K0styan
10.02.2025 09:35Форма восстановления пароля!
Двойной эффект: если угадал с адресом, то у пользователя растёт тревожность и опосредованно недоверие к сервису. Не угадал - просто раздражение и в каком-то проценте случаев пометка спама.
morijndael
10.02.2025 09:35Так если не угадал, то никакого емейла не вышлется. Как вы будете сбрасывать пароль пользователю, которого у вас нет?
Soarerru
10.02.2025 09:35И как эту коллизию разрешить совершенно непонятно.
Да, именно так. Вся надежда на то, что всякие гуглы таки обучаются в процессе отличать злоумышленников, даже таких, которые маскируются за "нормальными" пользаками.
А так - лет 10 назад или около того случай был: mail.ru блокировал почтовый траффик с одной электронной торговой площадки, который она была обязана рассылать по 44-ФЗ (уведомления всякие). И никакие обращения в суппорт не действовали - "вы шлёте слишком много". Чуть ли не до Усманова тогда дошли.
SerjioValentes
10.02.2025 09:35Посмотрел на своем хостинге, s3 стал недавно тарифицироваться по гб трафику. Спасибо за статью, пока сделал лимит по трафику у себя.
ArtificialSun
10.02.2025 09:35Статья говорит о том чего нет. Уде не берут денег за не авторизованные запросы https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorCodeBilling.html
tuxi
10.02.2025 09:35Годы идут, а косяки остаются. Мне где-то в 2018 или 2019 году AWS выкатило счет за S3, стал смотреть, активного хранилища нет, было когда-то, когда сделал один раз бекап сервера. Потом сервер был удален, бекап тоже. Но где-то в недрах S3 остался. В ответе пишут, у вас есть живое S3 хранилище, там бекап лежит. За это деньги просим. Я в ответ - а где в моей панели управления этот бекап? В лучших традициях райкинского "грузите апельсины бочками" две недели общался, пока тикет не попал видать куда-то выше. И о чудо, долг исчез. И тикет сам закрылся.
N-Cube
10.02.2025 09:35У меня было аналогично с бэкапом каких-то давно не существующих данных, который нигде не отображался, кроме биллинга. И даже после удаления всех русурсов во всех регионах AWS, деньги продолжали списываться. Помогло только закрытие аккаунта.
VFaland
10.02.2025 09:35Увы... Закрытие аккаунта не гарантия остановки списывания денег, AWS явно об этом предупреждает. Надо все ресурсы вычищать
Nansch
10.02.2025 09:35Пользуйтесь пэйпалом и предоплатными дебетовыми картами. Палка не спишется, если удалить клиента из автоплатежа, а карта не уйдёт в овердрафт.
xenon
10.02.2025 09:35а такие карты там прожуются? у меня препейды не везде в "облаках" принимали.
RichardMerlock
10.02.2025 09:35Hetzner прожевал мастеркард препейд от авиакомпании, снимает каждый месяц.
N-Cube
10.02.2025 09:35Вычистить как раз не мог, не было доступа из консоли управления. Удаление аккаунта прекратило все безобразия. Странные вы вещи говорите - на каком вообще основании они могут списывать оплату с не-клиентов?
Groosha
10.02.2025 09:35Как-то вы припозднились с переводом. Оригинал вышел в конце апреля 2024 года, а спустя две недели Amazon перестали брать плату за обращения к S3, на которые ответ HTTP 403
https://aws.amazon.com/about-aws/whats-new/2024/05/amazon-s3-no-charge-http-error-codes/
aelaa
10.02.2025 09:35У них этот "порядок исключения" действует буквально для всех при определенных обстоятельствах
mysherocker
10.02.2025 09:35добавление случайного суффикса к именам корзин
Обычно всё-таки префикса, и это делается примерно всеми и всегда.
И это явно указано в best praсtices, покуда у бакетов пространство глобальное имён.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html
Choose a bucket naming scheme that's unlikely to cause naming conflicts
Iv38
10.02.2025 09:35Там явно написано, что это следует делать, если ваш софт сам создаёт бакеты, чтобы избежать конфликта имён. Если ты создаёшь фиксированные бакеты, это не является необходимым. Это не делается, чтобы скрыть имя бакета.
Если на клиенте используются подписанные короткоживущие ссылки для получения или загрузки файлов, то кто угодно может узнать из таких ссылок имя бакета.
mysherocker
10.02.2025 09:35чтобы избежать конфликта имён
Могу лишь ещё раз повторить широко известный факт: бакеты находятся в глобальном пространстве имён. То есть, два клиента AWS не могут создать бакет с одинаковым именем. Поэтому, чтобы не налетать на конфликты, все сколь-либо опытные известные мне люди работают с префиксами. Часто вида "<company_name>-<env_name>-"
И проблема, описанная в посте, произошла ровно по причине попытки создать бакет с именем, которое кто-то мог переиспользовать. Если бы там был префикс с именем компании/проекта, вероятность такого исхода была бы куда ниже.
В общем виде эта проблема существовала ещё задолго то появления AWS и S3-совместимых хранилищ. Кто-то завязывает свой софт на доменное имя, которое перестают поддерживать, а потом его кто-то посторонний регистрирует заново и получает много обращений. Иногда с заведомо злыми намерениями.
Недавно на hacker news обсуждали эту проблему в контексте Google Workspaces и их работы с OAuth2/OIDC: https://news.ycombinator.com/item?id=42699099
iiwabor
10.02.2025 09:35Я помню историю, когда где-то в Америке чувак решил повыделываться и заказал себе автомобильный номер "Номер не определен" - и ему автоматом пришли все штрафы, в которых был не определен номер нарушителя)
mysherocker
10.02.2025 09:35То ли дело коварный "Prawo Jazdy", который бесцеремонно и серийно нарушает ПДД в Ирландии https://medium.com/@aydin.j.zubair/the-curious-case-of-prawo-jazdy-irelands-elusive-serial-traffic-offender-4c63f1150ac7
Ravius
10.02.2025 09:35Чёт я не пойму, а white-list по ip к бакету? Или как это работает?
FlashHaos
10.02.2025 09:35Если не ошибаюсь. S3 в Амазоне - глобальный сервис, он живет вне virtual private cloud, в котором ты мог бы сам настраивать сетевые правила и файрволл. В s3 ты можешь регулировать доступ через ACL в том числе по айпи, но ACL работают на уровне самого S3 и в описанной истории они как раз тарифицировались.
selivanov_pavel
10.02.2025 09:35ИМХО достаточно очевидно, что банкеты на aws надо называть в духе human-readable-name-XXXXX. Если не из неочевидной экономии, то хотя бы из соображений безопасности. Публично доступный интерфейс же.
Iv38
10.02.2025 09:35А как быть с публичными ссылками? В них есть имя бакета.
selivanov_pavel
10.02.2025 09:35Да, с бакетом для публичной раздачи чего-то не прокатит. Но для внутреннего использования - вполне.
outlingo
10.02.2025 09:35Правило номер 1 - если вы примерно представляете нагрузку и она тянется на одном барметале - то взять два барметала и натянуть на них HA, и это гарантирует вам что вы а) не придете к вендорлоку б) не получите ВНЕЗАПНО (с) счетов на сотни и тысячи баксов.
Облако должно быть приватным, либо с фиксированным прайсом не зависящим от нагрузки.
А цена "per request" включающая неаутентифицированные запросы это примерно то же, что платные входящие звонки.
N-Cube
10.02.2025 09:35Для глобальных проектов пара серверов это так себе идея, межрегиональный трафик стоит немало и задержки существенные. А локальные проекты типа интранета компании можно и вовсе в интернет не выставлять, vpn давно придумали.
Yeah
10.02.2025 09:35d) будете платить НЕВНЕЗАПНО эти самые тысячи баксов адмиину/девопсу, который это всё поддерживает e) будете лежать на выходных и в праздники и немного по ночам, потому что админ/девопс у вас один и некому кроме него нажать на кнопку reboot, когда что-то зависнет
outlingo
10.02.2025 09:35будете платить НЕВНЕЗАПНО эти самые тысячи баксов адмиину/девопсу, который это всё поддерживает
Вы, конечно, "забыли" что этот админ/девопс уже есть, поскольку раздеплоить типичную нынешнюю развесистую лапшу из сервисов и поддерживать ее в публичном облаке все равно кто-то должен.
удете лежать на выходных и в праздники и немного по ночам, потому что админ/девопс у вас один и некому кроме него нажать на кнопку reboot, когда что-то зависнет
Если ваша реализация такова, что у вас нет фейловера и вам нужно нажимать кнопку reboot когда что-то зависнет, то у меня для вас плохие новости...
mysherocker
10.02.2025 09:35"забыли" что этот админ/девопс уже есть, поскольку раздеплоить типичную нынешнюю развесистую лапшу
Чем больше инфраструктурного управления берёт на себя команда, тем больше придётся трудозатрат вкладывать для достижения заданных показателей надёжности и скорости разработки. И лапша самоуправляемого кубернетеса с двумя десятками компонент будет куда больше, чем описание аналогичных облачных ресурсов в терраформе.
Как человек, который делает и то и другое, я, конечно, буду всегда рекомендовать начинать с максимально высокоуровневых абстракций и брать максимально serverless зависимости, насколько это возможно для заданного проекта и опускаться на нижние уровни абстракции только имея конкретные соображения и расчёты.
Проблема в том, что мало кто умеет хорошо расчитывать непрямые расходы на инфраструктуру. Вот как раз в виде дополнительных человекочасов, рисков и замедления цикла разработки. Отсюда часто возникают мысли, что публичные облака -- это дорого, когда только вершина айсберга видна.
Frankenstine
10.02.2025 09:35Облако должно быть приватным, либо с фиксированным прайсом не зависящим от нагрузки
В таком случае облако без нагрузки будет стоить те же пару килобаксов в месяц, что и облако с большой нагрузкой... Вы так весь смысл облаков перечеркнули)
outlingo
10.02.2025 09:35Если вам нужно "поиграться" - это с лихвой перекроет минимальная виртуалка за копейки с фиксированной ценой, и вы не увидите прайса в $1300 как в статье. Если у вас есть продуктив - то скорее всего, ваша нагрузка уже достигла того уровня, когда дедикейты экономически выгодней, просто потому что те же ресурсы в облаке двукратно дороже.
Ну и внимание, вопрос - если посмотреть на то, как поступают маркетплейсы и вообще любые не-наколеночные проекты, то выясняется, что у них у всех есть свои ресурсовы с запасом (а порой и с двух-трехкратным) - и они считают, что это выгодней чем любое чужое облако (и часто пилят своё). Как вы предполагаете, у них какая-то тайная арифметика - или они все же что-то посчитали и поняли, что создать или даже вести разработатку своего облака оправданнее, чем использовать чужое?
N-Cube
10.02.2025 09:35Маркетплейсы это амазон что ли?:) Так они в облаке. Алиэкспресс тоже в облаке(алибаба клауд). НАСА пробовали свои датацентры и в итоге ушли на AWS, хотя у них объемы данных и трафик безумные. Они посчитали, хоть и постфактум.
N-Cube
10.02.2025 09:35Маркетплейсы это амазон что ли?:) Так они в облаке. Алиэкспресс тоже в облаке(алибаба клауд). НАСА пробовали свои датацентры и в итоге ушли на AWS, хотя у них объемы данных и трафик безумные. Они посчитали, хоть и постфактум.
Frankenstine
10.02.2025 09:35Если вам нужно "поиграться" - это с лихвой перекроет минимальная виртуалка за копейки с фиксированной ценой,
Это не облако же, а виртуалка. Облако как раз когда оно "резиновое", и ты платишь за то, что потребил, и не нужно париться с "ой, нагрузка подросла и всё упало". Ну или за воздух, если как обсуждаемой статье, плата взимается за провал авторизации.
FlashHaos
10.02.2025 09:35Строго говоря, в описанной ситуации никакого вендорлока нет - довольно легко перейти с aws s3 на тот же s3 от другого провайдера
sberoneshot
Есть три правила: не дарить, не играть в азартные игры, не выкидывать их
Девопс: А AWS можно использовать?
Джинн: 4 правила.
pae174
Напомнило комедию Brewster's Millions 1985 года. Там бедолага, для которого 300К это огромные деньги, тратит за месяц 30М что бы получить наследство в 300М :-)
redfox0
Напомнило Kui Cheng Shoufu Cong Youxi Kaishi, где человек мог получить процент как от заработанных, так и от потраченных денег. Курс у потраченных денег был выгоднее, так что он просто решил потратить все деньги на разработку игр, как наиболее вероятный вариант потерять всё.
alienator