Архитектура и стоимость простого бессерверного веб-приложения Amazon Web Services

Введение


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



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


Я их понимаю. Толстые железные сервера обеспечат их подразделения ИТ-инфраструктуры хлебом с маслом на долгие годы. Так что, эта история не для них, а для тех, кто еще не потратил на инфраструктуру ЦОДа несколько десятков чемоданов денег и хочет при этом пользоваться всеми благами цивилизации.


Удивительно, но термин «бессерверные» придумали не маркетологи, а деятель по имени Остин Коллин в 2015 году. Идея была проста – зачем каждой организации содержать штат админов? Лучше согнать всех админов в одно место, запастись для них Budweiser и пусть они админят свои сервера где-то далеко под землей. Бизнес должен быть сосредоточен на бизнесе и в плане инфраструктуры ему достаточно ответить на один простой вопрос – как много бабла я готов платить в месяц за используемые мощности. Ведь вся прелесть бессерверных технологий, что горизонтальное масштабирование ограничено только размером кошелька. Причем масштабирование может быть осуществелно в автоматическом режиме. На днях я забыл остановить стресс тест для одного проекта и был неприятно удивлен размером выставленного счета. Это обратная сторона медали, которая, к слову, легко решается сервисом AWS Billing Alert.


Итак, мы решили создать наше первое бессерверное приложение, но не по какому то туториалу, где множество ограничений, а почти по-настоящему. Почти, потому что, кроме «Hello World» это приложение ничего не делает, но зато сколько всего в этом задействовано!


Архитектура приложения



Приложение состоит из четырех основных частей:


  • Хранилище статического контента на базе AWS S3;
  • Авторизация через AWS Cognito User Pool;
  • Обработка динамического вызова API с помощью API Gateway и Lambda Function;
  • Хранилище данных в NoSQL БД DynamoDB.

Статический контент в AWS S3 корзине


AWS S3 – это объектное хранилище данных, ставшее, можно сказать, стандартом в индустрии. Mail.ru, Яндекс, Мегафон – используют устоявшийся термин Simple Object Storage и совместимое с AWS S3 API.


Одна из фишек S3 – это возможность использования корзины в качестве веб-сервера статического контента. То есть мы просто загружаем все наши CSS, JavaScript и HTML в корзину и ставим галку «Static Web Hosting». Но есть одно «Но». Доступ к корзине по HTTP возможен только без шифрования. То есть включил галку хостинг, открыл доступ для всех анонимусов и вот тебе такой открытый всем ветрам веб-сайт. Нам это не подходит. Ничего не могу сказать плохого про анонимусов, но наш «Hello World» должен быть доступен только для авторизированных пользователей и только с использованием SSL, да еще желательно, чтобы прямого доступа к корзине никто, кроме владельца аккаунта, не имел.


И тут нам на помощь приходит сервис дистрибьюции CloudFront, что доставляет контент близко к пользователям по всему миру, за исключением 1/6 части суши. То есть даже в Африке есть edge location, а в России нет. И появится ли не известно. В России, кстати, есть свои сети доставки контента, и я подумываю провести эксперимент по интеграции двух сервисов.


Для возможности использования SSL мы в сервисе Certificate Manager выпускаем бесплатный сертификат по имени нашего домена и привязываем его к нашей CloudFront дистрибьюции, после чего наш контент становится доступен по HTTPS, который терминируется на CloudFront edge location и дальше идет по сети AWS в незашифрованном виде. Но наша корзина S3 надежно защищена политиками и доступ к ней имеет только владелец аккаунта и созданная нами дистрибьюция. Конечно, для параноиков есть возможность зашифровать саму корзину при помощи SSE-KMS и перешифровывать его SSL при помощи Lambda@Edge на edge location. Но сегодня мы не такие параноики и не будем так делать.


Перед CloudFront сидит DNS сервис Route 53, и мудро перенаправляет трафик, направленный в сторону нашего домена к дистрибьюции CloudFront.


Cognito User Pool


Задача этого сервиса – выполнять функции подписки, верификации по е-мейлу или телефону и авторизации для веб пользователей и пользователей мобильных приложений. Amazon Cognito умеет работать с внешними поставщиками удостоверений, которые поддерживают стандарты SAML или OpenID Connect, с социальными платформами (Facebook, Twitter, Amazon) и позволяет использовать собственный поставщик удостоверений.



  1. Клиент запрашивает токен;
  2. Cognito User Pool верифицирует пользователя у поставщика удостоверений либо делает это самостоятельно;
  3. Cognito User Pool возвращает клиенту токен;
  4. Клиент использует токен для доступа к приложению.

Чтобы все это работало с нашим приложением мы используем Cognito SDK для JavaScript. Теперь у нас неавторизованный пользователь переадресуется на созданную нами страницу регистрации и входа в систему. Мы, конечно, можем использовать функцию предоставления пользовательского интерфейса авторизации Cognito Hosted UI, где уже преднастрены страницы входа в систему, восстановления забытого пароля, MFA и интеграции по SAML. Но, на сегодняшний день эта функция доступна только на английском языке, что, честно говоря, меня удивляет и расстраивает. Казалось бы, глобальный сервис…


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


API Gateway и Lambda Function


API Gateway – это высокопроизводительный шлюз для HTTP, Rest API и Web Socket. Мы создаем на шлюзе ресурс и его метод GET перенаправляет запрос к нашей Lambda функции. А чтобы враг не прошел, мы настраиваем на шлюзе Authorizer и без токена в зубах никого к нашей функции не подпускаем. При этом мы наступаем со всей дури на грабли CORS, о которых молчит большинство туториалов, грабли, связанные с интеграцией Lambda proxy и необходимости явно прописывать в API заголовки для каждого HTTP статуса. В свою очередь наша функция при помощи библиотеки boto3 может общаться с любым ресурсом AWS, но только при наличие правильно настроенных разрешений.


Страшилка на ночь
В самом начале я писал, как можно попасть на бабки просто забыв погасить инстанс EC2. Без правильно настроенных разрешений можно попасть по самые помидоры и мир полон страшных историй, как за одну чорную-чорную ночь списалось 10к денег из-за ошибок в настройке разрешений.


Хранилище данных в NoSQL БД DynamoDB


В нашем приложении для полноты картины не хватало внешнего источника данных, и мы создаем таблицу DynamoDB из одного элемента: id = UUID identifier; Text = «Hello World».


И что в итоге:


  • Пользователь отправляет запрос к нашему веб-приложению;
    Route 53 переадресует запрос от нашего домена к сети дистрибьюции CloudFront и находит ближайший к пользователю edge location;
  • CloudFront решает выдавать ли статический контент из кэша или переадресовать запрос в корзину;
  • JavaScript на странице понимает, что пользователь не авторизован и переадресует его на страницу входа в систему;
  • Cogito User Pool верифицирует пользователя и возвращает токен;
  • Этот токен вместе с запросом отправляется в сторону API Gateway, который проверяет наличие токена;
  • Если токен валидный шлюз передает запрос Lambda функции;
  • Та запрашивает БД и возвращает приветствие миру, которое вернувшись в код JavaScript появляется на экране счастливого пользователя.

А теперь о бабках


Джеф Безос все-таки акула бизнеса. И он уже придумал как сортировщикам товаров подавать сигналы прямо в голову, чтобы они сортировали более сортировочно. Так что халявы, казалось бы, не будет. И вообще, сколько может стоить вся эта бессерверная история для стартапа на коворкинге в Бургер Кинг?


К нашему счастью в AWS существует такая фича как «уровень бесплатного пользования». Это как первые 3 дозы хмурого за счет дилера, но рано или поздно придется платить по счетам самому. Но в отличие от диллера, если вы знаете параметры вашего сервиса, то можно оценить его стоимость при помощи инструмента AWS Pricing Calculator.


Базовая тарификация у используемых нами сервисов, следующая:


S 3


  • Уровень бесплатного пользования – 5 Gb.
  • Превышение – $0,02 за Gb в месяц.
  • Исходящий трафик тоже не бесплатен — $0,09 за Gb
  • И запросы PUT, GET и прочие тоже — $0,005 за 1000 запросов

CloudFront


  • Уровень бесплатного пользования – 50 Gb исходящего трафика, трафик внутри сети AWS не оплачивается;
  • Превышение – $0,08 за Gb, то есть распространять трафик через CloudFront немного дешевле, чем напрямую к S3;
  • Дополнительные фичи, типа шифрования полей или выделенного IP адреса, стоят отдельных денег.

Cognito User Pool


  • Уровень бесплатного пользования – 50к MAU (активных пользователей в месяц) для пользователей Cognito User Pool и всего 50 MAU для пользователей, авторизирующихся через SAML;
  • Превышение — $0,005 за MAU;
  • За SMS верификацию платить нужно отдельно.

API Gateway


  • Уровень бесплатного пользования – 1кк запросов в месяц;
  • Превышение — $3,5 за 1кк запросов.

Lambda


  • Уровень бесплатного пользования – 1кк запросов в месяц, 400к Гб-секунд (Без паники. Всего лишь время выполнения умноженное на объем используемой памяти)
  • Превышение — $0,0000166667 за Гб-секунду.

Секрет мастерства:
Тарифицируемый минимум – это 100 миллисекунд. Наша функция выполняется за 2. То есть можно 50 раз запросить «Hello World» за эти же деньги или нагрузить ее другим, не менее полезным функционалом. Так что обязательно смотрим в CloudWatch Logs Insights и оцениваем, что почем.


DynamoDB


В DynamoDB с расчетами все не совсем просто и стоимость зависит от выбора модели согласованности данных. Условно – чем ниже согласованность, тем больше данных в одном юните 1-4-8 Кб.


  • Уровень бесплатного пользования – нет;
  • RCU (чтение) – $0,25 за 1кк юнитов;
  • WCU (запись) – $1,25 за 1кк юнитов;
  • За хранение данных и непрерывное резервное копирование (да-да, есть и такая фича), глобальные таблицы и прочие плюшки придется платить отдельно;
  • И за трафик тоже.

Вместо заключения


В нашем тестовом приложении мы уместились в уровень бесплатного пользования за исключением таблицы DynamoDB. Ее существование встало нам в круглую сумму $0,59 в месяц, что при нынешнем курсе доллара вполне приемлемо.


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


Зима будет длинной и холодной – самое время начать творить в облаке.

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

    +13
    Но где же само приложение, чтобы мы начали уже вгонять вас в долги? Разрешите проверить, насколько вы учли в расчетах так называемый «хабраэффект».
      +2
      .Net Core в Lambda дюже медленно стартует — даже держать «горячим» с помощью запросов по таймеру почему то не помогает.
        +5

        Получилось переусложненное (надо управлять множеством неподконтрольных отдельных сервисов) и дорогое (сравните с ценой аренды VPS) решение. Если вы не хотите держать админов, то арендовать VPS и один раз настроить деплой будет дешевле и проще, и при этом у вас будет root-доступ к серверу с возможностью ставить любой софт.


        Гораздо проще и дешевле арендовать VPS и захостить там приложение на PHP. Не нужно будет кучи микросервисов, все будет работать просто и надежно. Поменяли строчку в коде, запушили в мастер, оно само задеплоилось. А тут надо что-то поменять — надо лезть в кривые запутанные админки амазона и искать, какую кнопку нажать.


        Или другой пример: надо вам узнать, сколько у вас пользователей в БД. Набираете в mysql SELECT COUNT(*) FROM user и получаете ответ. Надо узнать, сколько пользователей, купивших хоть один товар, но не подписавшихся на рассылку — опять же, несложный запрос и ответ. А что вы будете делать в Амазоне в убогой DynamoDB? Мучительно искать галочку в админке, которой там нету? Руками JSON составлять? Ну-ну, удачи.


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


        Плохо представляю сценарий, когда все это выгодно. Крупным сервисам с огромным трафиком дешевле будет купить свои сервера, маленьким дешевле VPS.

          +5
          Вы полностью правы и спорить с этим нет смысла, если речь идёт про продуктив и такой простой сайт. :)

          Автор у себя в подписи указал, что он является «Архитектором облачных решений», поэтому его статья — это демонстрация возможностей конкретных сервисов в AWS на примере простого Web-сервиса. Это очень полезная информация для тех, кто только начинает знакомиться c возможностями AWS. Когда новичок открывает список сервисов в AWS, то глаза начинают разбегаться и начинается паника, поэтому наличие конкретного примера, который можно самостоятельно повторить, является очень полезным.

          Автору спасибо за статью, прочитал с удовольствием. :)
            +5

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

              +1
              А разве концепция «один раз настроить» работает в современном мире?
                +1
                Не понравилось ваше сравнение DynamoDB с mysql. Надо понимать, что DynamoDB относится к базам NoSQL и никаких SELECT'ов там быть не должно. AWS не позиционирует DynamoDB как базу для крупных сервисов, для этого у них есть RDS (если хотите SQL) или DocumentDB (MongoDB).

                DynamoDB отлично подходит для каких-то маленьких проектов, 25 ГБ + 200 млн запросов у вас всегда бесплатно. USE CASE: маленькое мобильное приложение, Firebase Storage от гугла предлагает за бесплатно только 1 ГБ к сравнению.

                А для управление множеством сервисов DevOps'ы порекомендуют Infra as a Code (Terraform например). Очень удобная штука.

                В любом случае, то что я описал в своем комментарии решают специалисты называющие себя Solutions Architects :)
                  0
                  У вас как-то все перепуталось. DynamoDB — это штука для больших данных/нагрузок, когда вы жертвуете гибкостью схемы ради «бесконечного» скалирования. Посмотрите стримы Rick Houlihan про применение single table design или его доклады на re:invent.
                  0

                  Вендор лок в целом не такая большая проблема как ее описывают и с ним можно жить. Максимально универсальное приложение работающее везде будет сильно ограничено и при этом стоимость поддержки будет заметно дороже. Нужно ли это? Перенос сложных систем между платформами это всегда проблема. Не зависимо от использования лямбд.
                  На счёт count(*) — на мой взгляд для хайлоад такое не очень подходит. Если нагрузка не большая то можно использовать Аврору. Там обычная база. ДинамоДБ это все таки NoSQL и там свои плюсы и минусы как у любого NoSQL

                    0
                    Полностью согласен про «вендор лок».
                    Жизнь в мире без «какой-то лок» невозможна. Лок на «Васю, что написал нам сайт», например, тот еще лок.
                    Просто в этом мире лучше ставить на лидера.
                    0
                    Плохо представляю сценарий, когда все это выгодно. Крупным сервисам с огромным трафиком дешевле будет купить свои сервера, маленьким дешевле VPS.


                    Нестабильный трафик, когда в один день пусто а в другой густо. Либо создавать кластер с автоскейлингом, что требует нормальной такой экспертизы(да и притормаживает обычно скейлинг, хотя это очень редко бывает критично), либо вот эти вот лямбды где уже подумали за вас.
                    По стоимости обработки одного вызова API это будет примерно так:
                    1) Самое дорогое это конечно лямбды.
                    2) Кластер из амазоновских серверов с автоскейлингом
                    3) Кластер где скейлинг происходит за счет спотовых инстансов, которые стоят от 2 до 4 раз дешевле. Недостатки — их может не быть в данный момент времени и это нужно предусмотреть, их могут отобрать с 30секундным уведомлением и ваша архитектура должна это так же предусматривать.

                    По капитальным затратам — то есть стоимость приложения и создания инфраструктуры, все ровно наоборот.
                      0

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

                      +1
                      надо управлять множеством неподконтрольных отдельных сервисов

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

                      Тема стоимости не раскрыта, а она стоит того. EC2 стоит вагон денег, EBS тоже, а трафик в Амазоне стоит столько, что приложение, по факту, нужно специально затачивать под это ограничение. Взамен получаем 100-500 сервисов, которые ещё сильнее прибивают к AWS. И нужно как-то решить, стоит ли оно того. Не на уровне — «aws для растущих компаний», а как-то поподробнее, чтобы понимать как aws экономит деньги. Мой опыт говорит, что aws легко может стоить дороже ценой команды devops, но все ещё требует эту команду, то есть все недостатки и минимум достоинств.

                        0
                        Сравнение стоимости владения EC2 vs корп.дата центр — это, согласен, очень интересная тема. Но, к сожалению, ее в лоб не решить. Все рассчеты TCO для копр.сервисов, что я видел — это так, палкой в небо. Для экономии есть SPOT — инстансы и SAVING PLANS. Сделаю про это отдельный обзор, условно «Когда вам пора старовать в облака»
                        Простейший кейс, что я вижу, это когда нагрузка нужна уже сейчас, а сервера застряли на таможне :))) Т.к. деньги — деньгами, а репутацию никто не отменял.
                          0
                          Для экономии есть SPOT — инстансы и SAVING PLANS

                          Как по мне так это так себе опции. Spot instance исчезает в любой момент и потому требует особой поддержки со стороны кода приложения. Так себе экономия, сначала создаём себе проблему в виде высокой стоимости, а затем героически решаем. Saving Plan это когда комитимся на 3 года чтобы получить стоимость железа аналогичную Digital Ocean или Linode. При этом все ещё платим в 10 раз дороже за трафик.


                          Простейший кейс, что я вижу, это когда нагрузка нужна уже сейчас, а сервера застряли на таможне :)))

                          Это единственный кейс, который я вижу и который постоянно всплывает в маркетинге. А вот на практике так бывает крайне редко, если бывает вообще. Отличный пример — stack overflow и ещё десятки историй о том как крупные компании вроде Dropbox мигрировали из AWS.

                          +1

                          На мой сугубо дилетантский взгляд — AWS это супер дорогая шутка для смузи-стартапов, которым некуда совать деньги. Что она 146% делать не будет — ни защищать от рисков, ни экономить. При этом Amazon гиперориентирован именно на Америку, а если поточнее — куда-то в Калифорнию. Основная проблема — платен каждый чих, при это стоимость часа того же ec2 ничерта не меньше простого и удобного дигитал оушен. Да, есть вагон и маленькая тележка сервисов, но когда я их вижу задаюсь лишь вопросом — ведь кто-то всё это поддерживает и получает за это деньги.


                          К тому же, РФ (и СНГ) находятся в серьёзном продуктовом вакууме в том числе по причине раздутости цен. Хотя тот же Azure мне показался куда более щадящим и понятным. Не без заморочек, но объективно месяц интенсива абсолютно всё оставят без вопросов. При этом ворох сервисов как-то адаптирован под мелкомягкую платформу.


                          Но. Основная проблема клауда — высочайшая сложность объективной оценки. Слышал с десяток баек, как некоторый заказчик сэкономил тонны нефти перенеся существующую (!) инфраструктуру в клауд, в т.ч. в контексте AWS. И пару историй от стартапов, которых похоронили ценники операторов.


                          А почему? Потому что первые обычно оперировали огромными собственными датацентрами, которые не нагружались и на 10% почти всегда, а иногда — нагружались ну на половину. И распродав всю мишуру, сократив половину раздутого персонала, играющего в карты на зп, забыв про многотысячные счета на электричество — можно действительно сэкономить.


                          А вот вторым порой будет намного выгоднее взять пару серваков в стойках и развернуть свой микрокластер. Потому что неаккуратный скейлинг может не просто потопить начинание, а привести к значительным долгам. Тут правда есть один лайфхак — имеет смысл написать в саппорт, мол так и так. Почти всегда идут навстречу и пересчитывают, что сокращает сумму на порядки. И ещё имеет смысла завести в знакомых евангелиста или ментора, которому обычно выделяют сильные квоты и очень часто они не против и поделится.


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

                          +1
                          Автору благодарность за упрощенную концепцию приложения задешево и быстро. После тестирования облачного proof of concept, решение всегда можно перенести on-prem.
                          Не работал через Cognito, но слышал от тебят хорошие отзывы при интеграции.

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

                          Насчет денег — не беспокоит, совсем. Статья же про прототип (простое приложение). Устоявшийся подход прототипировать в облаке, а prod хостить либо в гибриде, либо на своем оборудовании — дешевле выйдет.

                          Кстати, Lambda на Питон можно писать с использованием Chalice: в одной библиотеке решается задача создания Endpoint, Lambda и авто-деплой на AWS.
                          Значительно экономит время.
                            0

                            Также можно использовать expressjs для nodejs

                            +3

                            Latency какой получился? Смотрел на этот стек пару лет назад — у лямбды высокое и нестабильное время ответа, S3 тоже работает существенно медленнее, чем хостинг на EC2 + nginx

                              0
                              Уже разобрал лабу, сорри.
                              По логам выполнение Lambda 2ms, задержка около 150 ms
                              Что касается S3 (без API Gateway + Lambda)
                              time_namelookup: 0.015000s
                              time_connect: 0.078000s
                              time_appconnect: 0.203000s
                              time_pretransfer: 0.203000s
                              time_redirect: 0.000000s
                              time_starttransfer: 0.703000s
                                0
                                чем хостинг на EC2 + nginx

                                в случае перегрузки — тут тоже будет нестабильное время ответа + EC2 может в любой момент времени быть перезагружена, а если спот — и отобрана

                                –1
                                ТОТ КТО НЕ ХОЧЕТ КОРМИТЬ СВОЕГО АДМИНА, БУДЕТ КОРМИТЬ ЧУЖОГО.
                                  +1
                                  Да, и что?
                                    –2
                                    То, что из реальных плюсов AWS и прочих облаков — только горизонтальное масштабирование, и то для определенных условий. А все остальное — шкурки лопнувших сов при попытке натянуть их на плюсы serverless архитектуры. И вместо обычного LAMP админа придется искать AWS-админа, вместо обычного веб-программиста придется нанимать того, кто умеет писать то же самое, но с учетом костылей lambda.
                                      0
                                      придется нанимать того, кто умеет писать то же самое, но с учетом костылей lambda

                                      Не уверен что на .Net Core под Lambda на данный момент можно сделать нормально стартующий сайт. Мне понадобился сайт очень простой из 2 форм и 1 страницы. Задеплоил на Lambda. Вроде нормально, но потом, как выяснилось, стартует очень долго — секунд 5. Попытался держать «горячим» с помощью запросов по таймеру — не помоглось.

                                      Интересно было бы увидеть реально работающий сайт на этом вашем Lambda. Хотя, не исключаю, что на других платформах этой проблемы нет.
                                        0
                                        Очень странная задержка. Могу логи скинуть в личку, но 150-250ms, больше не видел (но это не .NET)
                                          0
                                          Меня интересует только .Net.
                                          0

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

                                  +1

                                  Для справки, небольшой пример неожиданной стоимости.


                                  Если вы хотите использовать VPC (то есть, изолировать свою инфраструктуру от внешнего интернета), и при этом, естественно, захотите получать информацию из внешнего мира, то окажется, что с большой вероятностью вам потребуется NAT. Что же здесь такого, спросит неискушённый читатель? Стоимость сервиса, предлагаемого AWS (NAT Gateway) (в среднем, по регионам отличается):


                                  • $0.05 в час
                                  • $0.05 за Гб трафика.

                                  То есть, если вы собрали Hello World, в котором используется NAT Gateway, то за месяц, даже если приложение не используется, придётся заплатить $36.


                                  Если захотите использовать нормальную базу данных (в терминологии AWS — RDS), то стоимость — $0,07 в час.


                                  Бесплатный сыр, как известно, в мышеловке, и за Free Tier (уровень бесплатного использования) кто-то всё-таки должен заплатить...

                                    +1
                                    Ну NAT нужен только для того чтобы инстансы в приватной подсети могли лазить в инет. Можно запустить Nat-instance на t1.micro за $0,01 в час, можно поднимать его через CloudFormation только на нужно время. А с дуру можно поднять, например, r5dn.16xlarge с 96 vCPU и 768 Гб памяти за ....8 баксов в час.
                                    В этой лавке полно товара на любой кошелек :)))
                                      0

                                      Действительно, можно найти обходной путь. Который, в свою очередь, увеличивает сложность, и на котором тоже сделаны ловушки неожиданных расходов.
                                      Мне всё же кажется, что цена в $36/месяц (=$432/год) несколько неадекватна за такой, в общем-то, несложный сервис как NAT.
                                      Ценовая политика местами выглядит грабительски.

                                        0
                                        Ну смотрите, NAT Gateway стоит $0,045 в час и по большому счету нужен только для обновления ПО инстансов в приватных подсетях.
                                        Создается NAT Gateway за несколко секунд консольной командой «aws ec2 create-nat-gateway» и удаляется с такой же простотой. Даже если дела обстоят так, что он нужен 24/7, то $36 — это стоимость получаса — часа работы технического специалиста средней руки. Не вижу ничего грабительского. Вот Kinesis да, нужно сильно подумать прежде чем его использовать.

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

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