alizar сегодня в 10:45

«Плати сколько скажут». Вопрос по ограничению счёта AWS остаётся неотвеченным 10 лет

Когда пользователь попросил отменить платёж

На Хабре публиковались истории пользователей AWS, которые случайно «влетали» на тысячи долларов. Грубо говоря, просыпаешься на утро — а за ночь виртуальные машины масштабировались и накрутили сумасшедшие деньги. Или по итогам месяца неожиданно приходит дикий счёт.

По этой причине пользоваться облачными сервисами немного страшновато: вы не можете спрогнозировать нагрузку и расходы.

Казалось бы, ситуацию можно легко исправить, если установить лимит на максимальный бюджет или твёрдый лимит на ресурсы.

Но Amazon специально этого не делает, несмотря на жалобы клиентов. Проблема отслеживается ещё с 2011 года.

13 января 2011 года на форумах AWS пользователь задал вопрос о том, каков текущий статус по разработке функции ограничения на максимальный размер счёта:

Дорогой Amazon,

Вы делаете отличный сервис S3, он позволяет небольшим разработчикам использовать хранение мирового класса с оплатой по мере использования. Единственная часть, которой, на мой взгляд, не хватает, — это функции ограничения на максимальный размер счёта.

Сообщество просило об этом много раз, и вы обещали эту функцию, но она застряла на много лет. Я знаю, что ограничение счетов можно сделать путём программирования на нашей стороне (через проверку логов и/или подписанные URL), но я не считаю это подходящим решением. Это должна быть нативная функция.

Лимит на счета снизит риск для небольших разработчиков, которых хостинг S3 может буквально разорить. Такой контроль над счётом замкнёт логический цикл, и после этого я даже не могу придумать причину, почему кто-то откажется от использования S3.

Итак, мой вопрос сводится к следующему. Если функция запланирована, то когда она появится? Если она никогда не появится, мне очень жаль, но, пожалуйста, официально подтвердите это.

Заранее спасибо за любой ответ. Кстати, вот как эта функция может работать, на мой взгляд:

Лимит устанавливается на максимальную сумму в месяц для бакета

Когда достигается лимит, объекты из бакета прекращают выдаваться

При первом достижении лимита в течение месяца пользователь получает уведомление

Хотя объекты не выдаются, но входящие запросы всё равно генерируют трафик сами по себе. Поэтому вполне нормально продолжать взимать плату за каждую 1000 запросов.

Вопрос не отвечен до сих пор, то есть более десяти лет…

Очевидно, Amazon или не может, или не хочет разрабатывать эту функцию. С одной стороны, разработать биллинг в реальном времени практически невозможно. Биллинг всегда работает с опозданием.

С другой стороны, можно притвориться, что биллинг в реальном времени существует, внедрить функцию и решать все спорные вопросы в пользу клиента. То есть когда биллинг с опозданием регистрирует нагрузку сверх лимита, с клиента не возьмут лишних денег.

К чему приводит отсутствие лимита и как можно влететь на деньги — например, рассказывалось в статье «Как мы случайно сожгли $72 000 за два часа в Google Cloud Platform и чуть не обанкротились». Это типичная история, а не какой-то редкий случай. Google Cloud тут ничем не отличается от AWS в смысле отсутствия лимитов.

Вот как это было у автора:

И вдруг мы узнали о системе Cloud Run, у которой тогда был большой лимит бесплатного использования! Не разобравшись полностью, я попросил команду развернуть «тестовую» функцию Announce-AI в Cloud Run и оценить её производительность. Цель состояла в том, чтобы поиграться с Cloud Run для накопления опыта.

Поскольку у нас очень маленький сайт, то для простоты мы использовали БД Firebase, так как у Cloud Run нет никакого хранилища, а деплой SQL Server или другую БД слишком чрезмерен для теста.

Я создал новый проект GCP ANC-AI Dev, настроил бюджет облачного биллинга на 7 долларов, сохранил проект Firebase по бесплатному плану (Spark). Худший вариант, который мы представляли, — это превышение ежедневного лимита Firebase.

После некоторых модификаций мы подготовили код, сделали несколько запросов вручную, а затем оставили его работать.

Хотя в тестовый день система работала нормально, но Announce-AI продолжала генерировать запросы. Впоследствии было обнаружено много архитектурных изъянов в коде, из-за чего система начала быстро масштабироваться из-за экспоненциальной рекурсии в создании инстансов Cloud Run.

В общем, на следующий день произошёл автоматический апгрейд аккаунта Firebase на платный аккаунт. В сумме по итогу экспериментальная версия приложения на Cloud Run сделала 116 миллиардов операций чтения и 33 миллиона записей в Firestore. Стоимость операций чтения в Firebase: $0,06 за 100 000, так что получается $69 600 за операции чтения. Всё честно.

То же самое происходит на AWS с некоторыми сервисами — автоматический апгрейд на платный аккаунт. Для многих пользователей это происходит неожиданно. Добавьте экспоненциальный рост нагрузки — и вот результат.

Самое главное, что на AWS биллинговых лимитов не существует. Для сравнения, в Google Cloud они есть, на Azure тоже есть (не для всех аккаунтов). Хотя лимит срабатывает с опозданием примерно в сутки. Имеется в виду лаг между дорогой нагрузкой и записью её стоимости. Зачастую это критический лаг, потому что десятки тысяч долларов можно «спалить» за несколько часов, как в истории выше. Ну, а на AWS нет вообще никаких лимитов, даже с опозданием в сутки. Есть только лимиты по умолчанию на максимальное использование ресурсов, но они довольно большие и не спасут от тысячных счетов.

Можно, конечно, как-то защититься. Например, ограничить максимальный размер платежа по кредитной карте в банке. Но это не снимет с вас огромный долг перед AWS, см. обсуждение «Что будет, если не оплатить счет AWS?» в разделе вопросов и ответов на Хабре. Человек открыл бесплатный аккаунт, привязал карту с 1 долларом на счету, а вскоре обнаружил, что с него пытаются снять $1500.

В принципе, это хороший сценарий. Если такое произошло — закрываем аккаунт, блокируем карту и навсегда забываем об этой истории. Amazon точно не обратится в российский суд (или украинский, а тем более белорусский). А вот у резидентов западных стран могут возникнуть проблемы, наверное.

Таким образом, когда регистрируемся на AWS или Google Cloud, сразу предполагаем произвольный биллинг. Счёт может прийти совершенно дикий даже на бесплатном аккаунте. Лучше заранее подстраховаться от такого развития событий — см. выше про карту с 1 долларом.

Кроме того, полезно использовать мониторинг с оповещениями: у них задержка в пару минут, так что вы успеете среагировать на экстренное увеличение нагрузки.

По теме:
«Как я умудрился за 1 день задолжать Amazon 12000$»
«Как защититься от неожиданных счетов за AWS»
«Почему не следует пользоваться Google Cloud»

На правах рекламы

Подыскиваете VDS с прозрачной и понятной тарификацией для разработки и размещения своих проектов? Вы точно наш клиент :) Посуточная тарификация серверов, создавайте собственную конфигурацию в несколько кликов, антиDDoS включен в стоимость.

Подписывайтесь на наш чат в Telegram.

Теги:

Хабы:

Комментарии 19

numitus2 сегодня в 10:59
+17
Все просто. Эта фича уменьшит прибыли и поэтому нет смысла ее реализовывать
- maxbl4 сегодня в 18:46
  0
  В очередной раз обсасывается эта тема. Да, если настроить неограниченное масштабирование можно попасть на деньги. Но даже в статье написана правда: практически невозможно сделать биллинг в реальном времени.
  Вот у вас один маленький аккаунт S3, который стоит положим 0.001 цента за операцию и ваше маленькое приложение делает всего 100 операций в минуту. Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга, пересчитать сколько вы потратили и проверить ваши лимиты. То есть автоматом, ваш аккаунт начинает работать в среднем в два раза медленее (ведь надо и в аккаунт записать и в биллинг) и так во всех сервисах.
  А теперь прикинем, что есть премиум аккаунты, которые должны уметь выдавать 100к операций в секунду. Физически невозможно, чтобы такие аккаунты выдавали метрику по цене на каждый запрос и чтобы эта метрика в реальном времени проверялась против лимита расходов.
  Не знаю как в AWS, Azure для всех автомасштабирований требует указать лимит в единицах измерения сервиса. То есть для виртуальной машины в количестве ядер, для базы данных в гигабайтах и так далее. Может показаться, что это не столь удобно как в деньгах. Но это недоубно, только если вы пришли первый раз и хотите просто поиграться и сами не особо понимаете чего конкретно хотите. Если же вы создаёте даже маленькое, но приложение с конкретной целью, то вы более или менее представляете какие ресурсы будут нужны вашему приложению и наоборот удобнее указать лимиты в ресурсах. Azure вам сразу покажет сколько это примерно будет стоить в деньгах и будет списывать эту сумму равномерными долями
  - DaneSoul сегодня в 19:05
    
    +3
    Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга
    Да хотя бы раз в минуту проверяли состояния счета и блокировали если нет средств. Счета на десятки тысяч долларов все-таки на за 1 минуту обычно набегают.
    - maxbl4 сегодня в 19:17
      
      0
      
      На сколько я знаю, работа в этом направлении идёт и уже есть сервисы с поминутным биллингом
N-Cube сегодня в 11:09
0
На генерируемое уведомление о превышении бюджета можно назначить произвольные обработчики, которые удалят или остановят что требуется, или даже заблокируют биллинг для проекта, что автоматически приведет к удалению всех платных ресурсов. Например, для облака гугл первая же ссылка в их поисковике выдает исчерпывающие инструкции: How do I set a cost limit in Google Developers Console Аналогично у всех облачных провайдеров делается.
- funca сегодня в 12:01
  –1
  Уведомления поступают с задержкой и счет выставляется по факту. Ребятам из процитированной статьи этого хватило чтобы попасть на десятки тысяч долларов.
  Билинг в реальном времени нельзя сделать по вполне объективным причинам. Если пообещать жесткие лимиты в пользу клиента, то это не только станет поощрением халатности новичков, но и откроет большой простор для злоупотреблений. Поэтому в текущем виде решение выглядит как некий консенсус. Можно сказать это плата за обучение.
  - numitus2 сегодня в 12:31
    
    +12
    Почему-то убогие хостинги из нулевых умели работать по предоплате. И текущий баланс там было видно из любой страницы. А великий и ужасный Амазон не умеет
    - ITurchenko сегодня в 12:58
      
      +1
      
      Потому что они… убогие? Без возможности развертывания сотни инстансов в секунду в автоматическом режиме и прочими возможностями облака.
      
      И сейчас есть много хостингов с балансом в реальном времени. Вот только инстанс нужно руками из админки создавать + подниматься он будет в течении часа-двух.
      - Areso сегодня в 13:28
        
        +3
        
        Есть так называемые гибридные модели, где уже есть API, но тем не менее есть лимиты на вычислительные ресурсы.
        К примеру, у Digital Ocean было 25 машин лимитом по-умолчанию. Скейлимся в лимит — упираемся — дальше лимита ресурсов не скейлимся — счёт на больше, чем лимит ресурсов * на их цену не придёт.
      - numitus2 сегодня в 13:34
        
        +1
        
        Почему Digital Ocean показывает цену инстанса при создании.
        
        А у амазон эту цену надо фиг знает где искать:
        
        По поводу урока. Как-то создал инстанс на амазоне чтобы потренировать нейронную сеть. И то-ли я не выключил то ли был какой-то глюк и не выключился но в итоге в конце месяца мне пришел счет на 600$. Это очень неприятный урок, в то время, когда я рассчитывал на 10$
        
        N-Cube сегодня в 13:38
        
        0
        
        В Gcloud тоже сразу показывается. И хотя и у гугла и у амазона я наизусть помню цены нужных мне инстансов и намного чаще из консоли скриптом их запускаю, но все равно приятно, что не надо на каждый чих прайс гуглить.
  - N-Cube сегодня в 13:35
    
    0
    Огромная задержка оповещений именно у Амазона, насколько я понимаю. Мне от них оповещения вообще как-то рандомно приходили. У других провайдеров попроще. А еще можно выставить кучу лимитов вроде доступных вычислительных ядер и прочее, чтобы оставаться в разумных пределах. Не знаю, как насчет сложных сервисов типа BigQuery AutoML, где заранее вычислить затраты не получится и с лимитами может быть сложно разобраться, но с базовыми сервисами задача вполне решаема.
  - Lissov сегодня в 14:46
    
    0
    Если пообещать жесткие лимиты в пользу клиента, то это не только станет поощрением халатности новичков, но и откроет большой простор для злоупотреблений.
    
    Microsoft Azure имеет жесткие лимиты. В том числе именно так работают «виртуальные» 120$ в месяц для MSDN-подписчиков.
    Немного неудобно, что оно не восстанавливается само в начале нового периода а надо вручную перестартовать-передеплоить… вот это плата за обучение.
  - algotrader2013 сегодня в 19:33
    
    +1
    Уверен, что все резко стало бы возможным, появись правильный закон или прецендент в суде против скотов. Вспомнилось, как американские авиапроизводители обещали космические удорожания и утяжеления самолётов при добавлении регулировок в сидения и органы управления в истребители, чтобы удобно было большинству пилотов. Но, когда минобороны безальтернативно потребовало это, как условие для контракта, вдруг, все производители нашли способ решить вопрос дешево и без особого доп веса.
    Технически реально сделать достаточно точный биллинг, если резервировать деньги чуть с запасом. Условно, есть глобальный сервис, который резервирует деньги, попутно проверяя лимит + даёт грубый прогноз по использованию на, например, минуту вперед.
    Каждый сервис синхронно берет себе среднеминутный лимит, локально его уменьшает, и при окончании берет ещё. Тогда нетфликс будет откусывать на свои S3 по $1000 за раз, а стартапер Вася по $0.001
astenix сегодня в 16:48
0
А в РФ амазон работал бы иначе, судя по https://gazeta.ru/business/2011/02/24/3535105.shtml
Color сегодня в 17:10
+1
Интересно, есть ли уже какие-то решения, которые отслеживают биллинг/провиженинг в реальном времени, чтобы если не остановить сервисы, то хотя бы уведомить клиента?

В том же GCP, насколько знаю, биллинговые данные попадают в bigquery, оттуда можно как-то мониторить. Ну и тот же cloud pub/sub с уведомлениями — но опять же, насколько вовремя они туда попадают?

Вообще выглядит все так (особенно после прочтения статьи по ссылке) не стоит пользоваться сервисами, у которых возможности явно указать верхний лимит по апскейлу (если вы не мегакорпорация, которая готова платить миллионы за обработку скачкообразной нагрузки).

Те же кубы и виртуалки вполне себе легко посчитать + явно задаются лимиты автоскейлинга. А вот эти модно-молодежные лямбды и фаербейзы — работа "по волшебству" имеет две стороны медали — нужно меньше Ops, но и не понятно, когда сколько реального потребления и сколько придется заплатить.
- StjarnornasFred сегодня в 19:13
  0
  Вопрос: а почему бы не подключить тариф с безлимитной или пакетной лимитной нагрузкой, а не с оплатой за операции поштучно?
- vitaly_il1 сегодня в 19:26
  0
  Интересно, есть ли уже какие-то решения, которые отслеживают биллинг/провиженинг в реальном времени, чтобы если не остановить сервисы, то хотя бы уведомить клиента?
  
  Насколько понимаю, все внешние решения пользуются billing data от хостера, то есть быстрее не получится.
  
  А вот эти модно-молодежные лямбды и фаербейзы — работа «по волшебству» имеет две стороны медали — нужно меньше Ops, но и не понятно, когда сколько реального потребления и сколько придется заплатить.
  
  +1
ProSerg сегодня в 19:24
–1
Мне жаль, но читайте документацию, ограничивайте autoscaling, настройте оповещение. Хотя бы пройдите базовый курс по AWS где об этом расскажут и покажут. Сам однажды налетел на 5000$, затем быстро изучил billing, autoscaling и т.д. затем прошел курсы :)