Как сократить расходы в AWS

[Dekmabot]

Для совсем маленьких — есть способ экономить, используя tier-режим. Он даёт некоторое количество ресурсов бесплатно на первый год пользования аккаунтом. Изначально доступны только минимальные ресурсы, допустим из ec2 доступен только t2.micro instance, но саппорт охотно разрешает и всё остальное по заявке.

Через год новый email и новый аккаунт. В целом, и для "больших" никто не запрещает перевозить массивы между s3 раз в год.

[adamant]

Да, free tier тоже есть. Но это все-таки для тестов и для каких-то относительно маленьких проектов. Весь текст выше — в основном, для крупных сервисов. С резервированием, масштабированием, бэкапами… Тут о free tier речь уже не идет.

[darken99]

RI уже неактуально

[adamant]

Почему?

Если речь о том, что курс уже вырос, то все равно актуально. Ждать, когда он вернется обратно?

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

[darken99]

Потому что теперь есть Savings Plans

[megareez]

Актуально для non EC2: RDS, Elasticache, etc
А так да Savings plan!

[click0]

Скорее всего у AWS использовались снимки файловой системы (ZFS).
При постоянном добавлении бинарных данных растет общий размер FS со снимками (за прошлую неделю/месяц)

[Stas911]

Он дорогой ровно до того момента, пока не попробуешь построить инфраструктуру сравнимой надежности и масштабируемости сам. Потом внезапно выясняются интересные подробности.

Вот для примера отличное выступление James Hamilton про инфраструктуру: тыц

[Crazyvlad]

Ну так Amazon — это имя, и часто инвесторам проще сказать, что вся инфраструктура на Amazon, чем обьяснять, что это не оптимально.Тем более, что часто и объяснять некому — функции админа выполняет один из разработчиков, а у него и своих задач хватает.

[Stas911]

Кроме того, стартапы часто не знают, когда «выстрелят». Написали, например, про них в HackerNews и на сайт пришел миллион человек разом. Проще уж все держать в облаке сразу, чем судорожно метаться, искать оборудование или срочно мигрировать.

[Crazyvlad]

Введение в статью странное очень.
AWS у вас для зарубежных клиентов. Они платят явно не в рублях. Причем тут курс рубля к доллару?

[adamant]

1. Часть инфраструктуры у нас используется глобально, в том числе для клиентов в России (это не касается перс. данных, поэтому вполне можно и AWS).

2. Знаю много сервисов, которые используют AWS во многом для клиентов в России. Для них введение очень актуальное.

[Crazyvlad]

Это то понятно, просто посыл не ясен — что раньше не нужно было экономить? Только когда курс упал все бросились урезать косты?
Правда на фоне российских хостеров — стоимость AWS не так уж и высока…

[adamant]

И раньше нужно было. Просто раньше чаще забивали на банальную аккуратность в учете ресурсов, на изучение возможностей, которые есть в AWS.

[CherryPah]

AWS у вас для зарубежных клиентов. Они платят явно не в рублях. Причем тут курс рубля к доллару?

Ну доллар это конечно мировая валюта, но если сервис продается за национальные деньги то печаль наступила для половины валют.
И это я сейчас не только про страны СНГ говорю. Фунт на 11% упал, а норвежская крона вполне себе догоняет рубль в крутом пике падения.
А платить все равно в баксах.

[arheops]

Когда в зоне заканчиваются споты, как правило Auto-scaling срабатывает до 30-60 минут.
Потому споты не так хороши, как кажутся.
Если вы можете перенести час отсутствия сервисов — не вопрос.
А вообще EC2 настолько дорого, что при количестве ресурсов больше 4-5 серверов дешевле держать админа+хостинг на vultr, например.
ЕС2 вообще не имеют смысла без других сервисов от Амазон.

[adamant]

Сам по себе auto scaling, конечно, отработает долго. Я поэтому и дал ссылку на Spot Instance Interruption Notices. При «уходе» спотов мы обрабатываем эти события и ресайзим AS группу до нужного количества сразу. Это делается за единицы минут. Дальше уже работает обычный скейлинг.

[arheops]

Да это бы была ерунда.
Проблема в том, что отрубает только тогда, когда уже новые не стартует(в малое время).
Тоесть вы узнали, и ждете… час. В ручную — тоже не стартует.
Справедливости ради, такое происходит два-три раза в год, не чаще.

[gaploid]

Еще пара советов:

1. Если используется API gateway для lambda, что бы выставить ее во вне ввиде http, то можно заменить на новый облегченный HTTP API. latency меньше и цена на ~70% меньше
2. Если большой исходящий траффик до внутренней инфраструктуры то можно сделать direct connect в рамках него биллинг идет по другой логике и получается дешевле.
3. Если используются инстансы для работы в определенное время (ec2 и rds), то посмотрите на auto Instance Scheduler, можно выключать ночью, а так же включить еще Hibernate для ec2 и тогда будет не заметно что машина вообще выключалась.
4. Вот еще штука aws.amazon.com/solutions/cost-optimization-ec2-right-sizing которая анализирует ваши инстанс по логам за последние две недели дают рекомендацию какие инстансы можно уменьшить или убрать совсем исходя из их загрузки
5. static контент лучше раздавать через cloudfront это тоже помогает сократить расходы в различных сценариях. Но лучше это делать если конечные консьюмеры там где есть cloudfront pop точки
6. Цены на виртуалки в разных регионах разные и различаются бывает на десятки процентов. Поэтому если есть не критические ворклоды к latency лучше их поднимать в дешевых регионах
7. Трафик из VPC до S3 и тд лучше пускать через VPC endpoints. Вот статья где сокращают на ~80% тысячи долларов за счет переключения на endpoints bluesentryit.com/gain-real-savings-proper-cloud-setup
8. Не забывайте про inter az трафик он тоже стоит денег и всякие кросс az кластеры могут серьезно добавить в косты, поэтому если не сильна важна отказоустойчивость для некоторых сценариев, то возможно этим можно пожертовать.

[adamant]

Спасибо! Отличное дополнение!

[vitaly_il1]

спасибо, про Incomplete Multipart Uploads не знал!

[john_soft]

Из собственного многолетнего опыта работы с RI, оптимально резервировать convertible типы виртуалок. Часть резервировать на 3 года, а часть на 1 год. Т.к. aws ежегодно выпускают обновленные линейки ec2, которые как правило дешевле и быстрее, переход на которые, например, позволяет уменьшить число узлов в кластере или снизить latency. В случае convertible RI вы можете в любой момент перевести работающую инфраструктуру на новые типы в рамках текущего периода резервирования