«Плати сколько скажут». Вопрос по ограничению счёта 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.

    VDSina.ru
    Серверы в Москве и Амстердаме

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

      +26

      Все просто. Эта фича уменьшит прибыли и поэтому нет смысла ее реализовывать

        +2

        В очередной раз обсасывается эта тема. Да, если настроить неограниченное масштабирование можно попасть на деньги. Но даже в статье написана правда: практически невозможно сделать биллинг в реальном времени.
        Вот у вас один маленький аккаунт S3, который стоит положим 0.001 цента за операцию и ваше маленькое приложение делает всего 100 операций в минуту. Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга, пересчитать сколько вы потратили и проверить ваши лимиты. То есть автоматом, ваш аккаунт начинает работать в среднем в два раза медленее (ведь надо и в аккаунт записать и в биллинг) и так во всех сервисах.
        А теперь прикинем, что есть премиум аккаунты, которые должны уметь выдавать 100к операций в секунду. Физически невозможно, чтобы такие аккаунты выдавали метрику по цене на каждый запрос и чтобы эта метрика в реальном времени проверялась против лимита расходов.
        Не знаю как в AWS, Azure для всех автомасштабирований требует указать лимит в единицах измерения сервиса. То есть для виртуальной машины в количестве ядер, для базы данных в гигабайтах и так далее. Может показаться, что это не столь удобно как в деньгах. Но это недоубно, только если вы пришли первый раз и хотите просто поиграться и сами не особо понимаете чего конкретно хотите. Если же вы создаёте даже маленькое, но приложение с конкретной целью, то вы более или менее представляете какие ресурсы будут нужны вашему приложению и наоборот удобнее указать лимиты в ресурсах. Azure вам сразу покажет сколько это примерно будет стоить в деньгах и будет списывать эту сумму равномерными долями

          +14
          Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга
          Да хотя бы раз в минуту проверяли состояния счета и блокировали если нет средств. Счета на десятки тысяч долларов все-таки на за 1 минуту обычно набегают.
            0

            На сколько я знаю, работа в этом направлении идёт и уже есть сервисы с поминутным биллингом

              +4
              Так ведь одна из веток поста о том, что у них уже лет 10, как идёт. Но для клиента воз и ныне там. Если не напутал ничего.
                0
                Есть сервисы и с посекундным биллингом, только что толку, если этот самый биллинг станет доступен спустя сутки? Об этом статья.
              +4

              Нужна защита от дурака. Если я заказываю себе поменять дверь или окно за 200$ это не должно приводить к убыткам в десятки тысяч долларов из-за какой-то опечатки или непонимания. Пусть даже почасовая оплата будет. Даже так нельзя десятки тысяч долларов убытков получить. И должны быть вменчемые лимиты. А снятие лимитов должно происходить только после подписания договора с клиентом, а не для любого пользователя . Почему-то Амазон может выводить поминутную статистику использования лимитов. А вот умножить число инстансов на тариф не может. Как и все западные сервисы он оптимизирован для вытягивания денег, а не для удобства пользователя, поэтому описанные выше фичи не будут реализованы никогда

                +1

                Amazon, как и другие облачные сервисы оптимизирован для больших клиентов, у которых траты в месяц тысячи долларов. Мелкие разработчики, с бюджетами в 10$ в месяц не дают никакой значительной прибыли. Не надо облака сравнивать с мобильными донат играми

                  +1

                  Однако многие будут внедрять в стартапы именно те облака, с которыми они знакомы.
                  Хоть месячные счета в таких кампаниях будут небольшими, в среднем в пару тысяч долларов, но их достаточно много.

                  +2

                  Чтобы получить у Амазон виртуальную машину с 4TB+ оперативки надо писать в поддержку и пояснять, для чего потребовалось. Чтобы получить у Гугл больше 12 ядер на их бесплатном пакете в 300$ надо тоже писать… и все равно лимит не увеличат, даже если деньги на счету есть и этот стартовый пакет все равно не используется:) и так далее.

                    0
                    Да, но и на 3.99ТБ RAM можно быстро разориться.
                      0
                      А что бы при масштабировании получить сотню виртуальных машин с 64 гб оперативки, ничего не надо.
                        0

                        Насколько я помню вы и одну машину на 64гб оперативки без поднятия лимита не запустите, что как раз и сделано для того, чтобы вы имея 2 бакса на карте не попали на пару десятков тысяч.

                      –1
                      Если я заказываю себе поменять дверь или окно за 200$ это не должно приводить к убыткам в десятки тысяч долларов из-за какой-то опечатки или непонимания.

                      Если вас выпустить из автошколы без инструктора, то вы можете устроить аварию или даже кого-то убить. Но это же не значит, что отныне вы должны всегда ездить с инструктором, и жить с мамой. Пора учиться брать ответственность на себя и решать проблему лавинообразного нарастания запросов на СВОЕЙ стороне — ежеминутно наблюдать за приложением, трафиком и балансом счёта, и немедленно исправлять обнаруженные ошибки. AWS за всеми вами тяжело уследить.
                        +2
                        Пора учиться брать ответственность на себя и решать проблему лавинообразного нарастания запросов на СВОЕЙ стороне — ежеминутно наблюдать за приложением, трафиком и балансом счёта, и немедленно исправлять обнаруженные ошибки.

                        это чушь. Потому что входящий трафик вы не контролируете. Можно представить себе ситуацию, что конкуренты решили дешевыми инстансами нагенерить на своей стороне трафика и пустить его на ваш сервис — и ничего вас не спасет. Либо ваш сервис ляжет, либо Амазон вас отскалирует верх. Самый плохой сценарий — когда будет и то, и то (клиенты все равно будут недовольны, а Амазон срубит кучу денег). Вставать за защиту — вариант, но не абсолютный, увы.

                      +3
                      Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга

                      Так он это и так делает — счета то выставляются.
                      Тут надо не делать запись, а делать проверку, и ее можно делать даже не на каждое действие, а раз в 10 запросов, раз в 100 запросов, раз в час.
                        0

                        Как все быстро забыли, что еще 15-20 лет назад у всех или почти всех местечковых провайдеров интернет биллинг вообще раз в месяц считался. И если среди месяца провайдер звонил — значит, мы опять выбрали весь его лимит у вышестоящего провайдера и дело плохо. Впрочем, это обычно решалось балансировкой трафика — надо было восстановить нужное соотношение входящего к исходящему для обнуления тарифа. Так все мои друзья-админы тех времен сейчас облака манной небесной по удобству тарификации считают:) И я с ними согласен.

                          0
                          Вот у вас один маленький аккаунт S3, который стоит положим 0.001 цента за операцию и ваше маленькое приложение делает всего 100 операций в минуту. Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга, пересчитать сколько вы потратили и проверить ваши лимиты.

                          При наличии желания это решается очень просто. Например, на ресурс задаётся предел темпа потребления в деньгах или пропорциональных им условных попугаях. Дальше производится локальный для ресурса учёт, который проверяется по базе и сливается в неё раз в K минут. И опять же делается остановка потребления при снижении общего акаунта ниже некоторой предельной суммы (причём по умолчанию я бы вообще ставил ноль, и давал минус только при показе платёжеспособности...)


                          А теперь прикинем, что есть премиум аккаунты, которые должны уметь выдавать 100к операций в секунду.

                          Да. Посмотрели на счёт — есть на ближайшие 5 минут ещё 300$? разрешили на такой темп. Есть только 20$? Разрешили только 20000 операций, а дальше стоп. Раз в 5 минут выдержит любой подобный биллинг.


                          Тут, конечно, интересный вопрос — что, если даже типов таких ресурсов штук 20 и проверка на каждом будет независимой. Но если дать ставить галочку "допускать только если денег есть на все ресурсы с гарантией" или "можно опускать с учётом всех запасов до -200$" — уже все пострадавшие и потенциально пострадавшие будут благодарны.


                          Если это не делают — как сказано в статье — причина одна: явное нежелание делать то, на чём потеряют возможность дрючить "лохов" (термин, увы, адекватный тут).

                          +5
                          И повышает репутационные издержки, мотивирует разработчиков меньше пробовать продукты AWS. Я, например, прочитав много таких историй, никогда не пробую продукты которых не знаю, и большую часть времени работы с AWS пытаюсь понять сколько это будет стоить и где могу влететь на деньги.
                            0
                            Да такое много где есть, просто где-то больше, где-то меньше.
                            Я как-то влетел на деньги в GCP. Создал небольшой инстанс, всё было хорошо.
                            Потом пришли люди (боты?) из Китая, и внезапно оказалось, что с ВМ идёт трафик («в комплекте»), но у этого «в комплекте»* есть звездочка. И там, помимо прочих условий, указывались регионы, откуда (и куда) трафик всегда платный. Независимо от его количества. Китай, Океания, еще кто-то там…
                              0

                              Там есть подводный камень с тем, что истории обычно "хорошо" заканчиваются, поддержка amazon идет на встречу, причем не только к хардкорным компаниям, но даже разработчикам-одиночкам. В моем опыте прощали даже откровенно и точно пожранные нами ресурсы, в следствии ошибок devops или вовсе забытые.


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


                              Вот ценообразование и "калькулятор стоимости" жуть

                            0

                            На генерируемое уведомление о превышении бюджета можно назначить произвольные обработчики, которые удалят или остановят что требуется, или даже заблокируют биллинг для проекта, что автоматически приведет к удалению всех платных ресурсов. Например, для облака гугл первая же ссылка в их поисковике выдает исчерпывающие инструкции: How do I set a cost limit in Google Developers Console Аналогично у всех облачных провайдеров делается.

                              –2

                              Уведомления поступают с задержкой и счет выставляется по факту. Ребятам из процитированной статьи этого хватило чтобы попасть на десятки тысяч долларов.

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

                                +17

                                Почему-то убогие хостинги из нулевых умели работать по предоплате. И текущий баланс там было видно из любой страницы. А великий и ужасный Амазон не умеет

                                  +1
                                  Потому что они… убогие? Без возможности развертывания сотни инстансов в секунду в автоматическом режиме и прочими возможностями облака.

                                  И сейчас есть много хостингов с балансом в реальном времени. Вот только инстанс нужно руками из админки создавать + подниматься он будет в течении часа-двух.
                                    +4
                                    Есть так называемые гибридные модели, где уже есть API, но тем не менее есть лимиты на вычислительные ресурсы.
                                    К примеру, у Digital Ocean было 25 машин лимитом по-умолчанию. Скейлимся в лимит — упираемся — дальше лимита ресурсов не скейлимся — счёт на больше, чем лимит ресурсов * на их цену не придёт.
                                      +2
                                      Почему Digital Ocean показывает цену инстанса при создании.

                                      А у амазон эту цену надо фиг знает где искать:

                                      По поводу урока. Как-то создал инстанс на амазоне чтобы потренировать нейронную сеть. И то-ли я не выключил то ли был какой-то глюк и не выключился но в итоге в конце месяца мне пришел счет на 600$. Это очень неприятный урок, в то время, когда я рассчитывал на 10$
                                        +1

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

                                          0
                                          По поводу урока. Как-то создал инстанс на амазоне чтобы потренировать нейронную сеть. И то-ли я не выключил то ли был какой-то глюк и не выключился но в итоге в конце месяца мне пришел счет на 600$. Это очень неприятный урок, в то время, когда я рассчитывал на 10$

                                          я тоже так случайно влетел на фритир гугла и бонусными 300$. Кто ж знал, что айпишники платные и при удалении ресурсов, ты за айпишник все равно "платишь". Благо сумма была небольшая, но осадочек остался

                                            0
                                            А у амазон эту цену надо фиг знает где искать

                                            потому что у амазон цена зависит от региона размещения. нормальный вариант, когда Орегон ~в два раза дешевле Франкфурта.

                                              0
                                              Когда я открываю это окно, то регион у меня уже выбран
                                        0

                                        Огромная задержка оповещений именно у Амазона, насколько я понимаю. Мне от них оповещения вообще как-то рандомно приходили. У других провайдеров попроще. А еще можно выставить кучу лимитов вроде доступных вычислительных ядер и прочее, чтобы оставаться в разумных пределах. Не знаю, как насчет сложных сервисов типа BigQuery AutoML, где заранее вычислить затраты не получится и с лимитами может быть сложно разобраться, но с базовыми сервисами задача вполне решаема.

                                          0
                                          Если пообещать жесткие лимиты в пользу клиента, то это не только станет поощрением халатности новичков, но и откроет большой простор для злоупотреблений.

                                          Microsoft Azure имеет жесткие лимиты. В том числе именно так работают «виртуальные» 120$ в месяц для MSDN-подписчиков.
                                          Немного неудобно, что оно не восстанавливается само в начале нового периода а надо вручную перестартовать-передеплоить… вот это плата за обучение.
                                            +5

                                            Уверен, что все резко стало бы возможным, появись правильный закон или прецендент в суде против скотов. Вспомнилось, как американские авиапроизводители обещали космические удорожания и утяжеления самолётов при добавлении регулировок в сидения и органы управления в истребители, чтобы удобно было большинству пилотов. Но, когда минобороны безальтернативно потребовало это, как условие для контракта, вдруг, все производители нашли способ решить вопрос дешево и без особого доп веса.

                                            Технически реально сделать достаточно точный биллинг, если резервировать деньги чуть с запасом. Условно, есть глобальный сервис, который резервирует деньги, попутно проверяя лимит + даёт грубый прогноз по использованию на, например, минуту вперед.

                                            Каждый сервис синхронно берет себе среднеминутный лимит, локально его уменьшает, и при окончании берет ещё. Тогда нетфликс будет откусывать на свои S3 по $1000 за раз, а стартапер Вася по $0.001

                                              +4
                                              Уверен, что все резко стало бы возможным, появись правильный закон или прецендент в суде против скотов.

                                              Да уже сейчас всё возможно, если это нужно сервису. На любом бесплатном, условно-бесплатном или триальном плане умеют точный биллинг и ни байта сверху не подарят. А когда можно выставить счёт — так уже разучились.
                                                +2

                                                А ещё вспомнилось как заставляли операторов делать входящие бесплатными. И там тоже все кричали про сложность. Когда-то посекундная тарификация звонков была фичей а стала стандартом. Кстати тот же Амазон умеет прекрасно считать CPU юниты для инстансов. С достаточно высокой точностью.

                                                  0

                                                  Все можно.
                                                  И есть широко известный пример.
                                                  Сотовая телефония.
                                                  Был постоплатный биллинг раз в месяц.
                                                  Но сейчас имеем как норму — посекундную тарификацию.
                                                  Просто оказалось выгодно найти решение.


                                                  А насчет облачных сервисов — у Selectel'а ж было облако и с посекундной тарификаций cpu и (насколько помню) учетом операций ввода-вывода с диском по одному запросу.

                                                  0

                                                  Вот и сотовые операторы утверждали, что "нельзя сделать". А после прецедента с Мегафоном как-то исхитрились и биллинг стал обновляться почаще, чем раз в неделю.
                                                  Наказание рублем почему-то сразу открывает новые технические возможности.

                                                +1

                                                А в РФ амазон работал бы иначе, судя по https://gazeta.ru/business/2011/02/24/3535105.shtml

                                                  +1

                                                  Интересно, есть ли уже какие-то решения, которые отслеживают биллинг/провиженинг в реальном времени, чтобы если не остановить сервисы, то хотя бы уведомить клиента?


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


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


                                                  Те же кубы и виртуалки вполне себе легко посчитать + явно задаются лимиты автоскейлинга. А вот эти модно-молодежные лямбды и фаербейзы — работа "по волшебству" имеет две стороны медали — нужно меньше Ops, но и не понятно, когда сколько реального потребления и сколько придется заплатить.

                                                    0

                                                    Вопрос: а почему бы не подключить тариф с безлимитной или пакетной лимитной нагрузкой, а не с оплатой за операции поштучно?

                                                      0
                                                      Интересно, есть ли уже какие-то решения, которые отслеживают биллинг/провиженинг в реальном времени, чтобы если не остановить сервисы, то хотя бы уведомить клиента?

                                                      Насколько понимаю, все внешние решения пользуются billing data от хостера, то есть быстрее не получится.

                                                      А вот эти модно-молодежные лямбды и фаербейзы — работа «по волшебству» имеет две стороны медали — нужно меньше Ops, но и не понятно, когда сколько реального потребления и сколько придется заплатить.

                                                      +1
                                                        0

                                                        Да, конечно есть. Наша компания как раз этим и занимается. Одним из первых фичеров который зашёл нашим клиентам был как раз «риал-тайм» биллинг. Мы динамически опрашивали прайсинг амазона и считали на нашей стороне сколько сжигает клиент и оповещали об аномалиях. Название компании публиковать не буду, чтобы не подумали что это реклама

                                                        –8
                                                        Мне жаль, но читайте документацию, ограничивайте autoscaling, настройте оповещение. Хотя бы пройдите базовый курс по AWS где об этом расскажут и покажут. Сам однажды налетел на 5000$, затем быстро изучил billing, autoscaling и т.д. затем прошел курсы :)
                                                          –1
                                                          Это всё ради одной поля с суммой ограничений на траты? Не слишком ли мало AWS думает о своих клиентах?
                                                          +7
                                                          Открыл когда-то AWS аккаунт поиграться. Через год он стал биллить по 80 центов. Ну я решил его закрыть. Оказалось, что мой имеил привязан к двум аккаунтам — AWS и потребительский. И при попытке залогиниться используя имеил AWS предлагает создать новый аккаунт. То есть на старый AWS аккаунт попасть нельзя.
                                                          Переписка с саппортом успехом не увенчалась. Вариантов решения от них всего два. Либо потанцевать со сменой имейла на потребительском аккаунте, что б получить доступ к оригинальному AWS. Либо заблокировать платежи в банке, типа аккаунт автоматически закроется. С аккаунтом что-либо делать на своей стороне они наотрез отказались. Видите ли требования безопасности такие. *тут меня уже трясти начинает*
                                                          Но вскоре банковскую карту пришлось заблокировать по другому поводу. И вот тут началось самое интересное. Амазон исправно каждый месяц шлет, что я им должен 80 центов. И если я не оплачу, то аккаунт закроется. А аккаунт не закрывается. После переписки с саппортом, в которой они опять мне предлагали потанцевать со ссменой имейла, до них таки дошло, что у них система сбоит. Пообещали исправить, но опять пришли письма об оплате. Я их переслал саппорту. Но надежды нет. Скорее всего поставлю спам фильтр.
                                                          Тех. поддержка некоторых корпораций просто ужасна. С одной стороны у вас товар примут обратно без вопросов, без чека, в любом состоянии, даже если возврату не подлежит. А с другой стороны «Компьютер говорит нет».
                                                            0
                                                            В чем проблема-то? Не используйте AWS.
                                                              0
                                                              Спам о проблеме с аккаунтом напрягает.
                                                            –1
                                                            Интересный вопрос — насколько использование облаков выгодно для среднего (и тем более малого) бизнеса?
                                                            С корпорациями всё понятно — штат разработчиков и админов, которые и посчитают, и настроят, и код напишут без ошибок, приводящих к увеличению биллинга (на самом деле нет). Но главное — $70k для них мелочь, заплатят ни не поперхнутся, ну разве что лишат премии виновника.
                                                            А вот у середнячков и мелочи все иначе — задачи, требования и возможности там иные. Во многих случаях хватило бы и On-Premise и VDS. К тому же экономическая выгода и окупаемость для небольших проектов, мягко говоря, не очевидны. Но реклама настаивает, что весь цивилизованный мир давно в облаках, открой бесплатный аккаунт, мол не пожалеешь.
                                                            В общем, смысл такой — нужно определиться заранее где облако необходимо, а где без него можно (и нужно) обойтись.
                                                              –2

                                                              Нет, это НЕ интересный вопрос. Какой-то странный образ у вас "облаков". Вы вообще с ними работали?

                                                                0
                                                                Да. Писал для Azure. Serverless на .Net + API Gateway + Cosmos DB (Gremlin). Плюс разбирался с кучей других технологий. Разбирался с AWS, смотрел в чем там отличия.
                                                                Суть моего поста — есть некий проект Х, что для него выгоднее — использовать инфраструктуру On-Premise, либо развернуть VDI с необходимой инфраструктурой у хостера с фиксированной оплатой, либо развернуть тот же VDI в Azure/AWS, либо использовать специфические облачные механизмы (типа того же Serverless/Lambda), которые вне облака уже использовать невозможно.
                                                                Готовы сходу дать такую экспертизу по любому проекту?
                                                                  –1
                                                                  Суть вашего поста пойти к облачному провайдеру и своими силами или с помощью менеджера (или даже архитектора) посчитать, что вам надо, а чего не надо. Очевидно, что тут никто вам экспертизу не будет делать в принципе.
                                                                  Подобные заявления были бы к месту 10-20 лет назад, но не когда этот вопрос обсосан со всех сторон и с позиции практически каждого провайдера. Не знаю кому и что вы там писали, но вопрос даже близко не от человека который хотя бы просто знаком с этой сферой.
                                                                    +1

                                                                    VDI своими силами точно будет разворачивать сильно дороже.

                                                                0
                                                                а что будет если ктото привяжет к сервису виртуалку на которой 5 копеек и использует быстро много ресурсов?
                                                                  0

                                                                  Ничего ему не будет

                                                                  0
                                                                  У амазона есть оповещалка о том, что биллинг выполз за определенный порог — письма вполне себе приходят. Прикрутить автоматику, которая по таким письмам попришибает все инстансы нафиг — задача вполне себе решаемая.
                                                                    0
                                                                    Так «не ходите дети в африку гулять...»
                                                                    Это взрослые штуки для взрослых компаний, с юристами бухгалтериами кучей спецов и тд. например нетфликс.
                                                                    Конечно это крайне неудобно и несправедливо!!! А кто обещал справедливость?
                                                                    Куча бизнесов работаю по схемам похлеще этой, продажа бутилированной воды из под крана например.
                                                                    Реклама, в том числе и проф кругах сделала свое дело все считают амаон = дешево… =)))))))))
                                                                    Ник то же не хочет платить деньги(например админу, не говоря уже о том что бы сервер купить), вот вас и разводят на деньги супер професионалы, акулы бизнеса.
                                                                      –1
                                                                      Левацкая какая-то статья. Не хотите — не пользуйтесь. В чем проблема? Не понимаю.

                                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                      Самое читаемое