В данный момент я занимаюсь поиском подходящих серверов для инфрастуктуры моего проекта. Я остановился на EC2 и решил проанализировать, какое решение будет наиболее экономически выгодным для меня. Эта статья по сути является продолжением AWS Insight: Резервации в EC2 — как это работает, но приводит анализ для молодого веб-стартапа (24x7).
Проблема
Сервер должен работать 24 часа в сутки напротяжении X месяцев (количество не определено). Какой вариант (On Demand / Light Utilization Reserved / Medium Utilization Reserved / Heavy Utilization Reserved) выбрать для Micro/Small/Medium/Large серверов?
Предисловие
В чем разница между выбором? Только в цене. Вы получаете абсолютно тот же сервер, но по различным ценам в зависимости от срока, в течение которого вы планируете его использовать.
On Demand — оплата полностью почасовая (высокая), никаких предоплат.
Heavy Utilization, Medium Utilization, Light Utilization Reserved — Амазон рекомендует использовать эти типы, если ваш сервер запущен постоянно (100%), достаточно часто (60%) или изредка (40%) соответственно. Чтобы зарезервировать сервер, вы вносите non-refundable предоплату на 1 или 3 года. После этого плата за час значительно снижается. Важно отметить, что в случе Medium и Light оплачиваются только те часы, в которых сервер использовался. Heavy — оплачиваются все часы до конца брони внезависимости от использования сервера.
Анализ
Для краткости я опущу весь анализ, но покажу его принцип. Для каждого из типов (Micro/Small/Medium/Large) я составил таблицу по типу представленной ниже для Large. В ячейке показана полная сумма, которую получит Амазон от вас по прошествию определенного месяца. Зеленым помечена наименьшая сумма. Красным — наибольшая.
Упростить эту картину можно следующей таблицей. В ячейке указан план с наименьшей суммой, которую вы заплатите по прошествию месяца.
Забавно, что выше мы не видим ни одного Medium. Неужели Medium такой лузер для данного Use Case? Нет. Если мы задумаемся на секундочку, то поймем, что выше предоставленные таблицы не отвечают однозначно на поставленный вопрос. Дело в том, что уже было отмечено ранее: Heavy Utilization обязывает вас оплатить все, даже неиспользуемые, часы за весь период брони.
Таким образом, мы заинтересованы не столько в том, сколько мы отдадим амазону после какого-то месяца, а в том, сколько мы всего будем обязаны отдать с учетом того, что сервер не будет использоваться после определенного месяца.
Изменим вспомогательную таблицу таким образом, чтобы она показывала реальную стоимость сервера по истечению конкретного месяца.
Изменились два последних столбца, но заставили достаточно много красных и зеленых ячеек поменять свои позиции. Резюмируем:
Та-дам! А вот и Medium!
Выводы
Итак, теперь самое интересное. Что же мы получили?
Поскольку я заинтересован в Large Instance, от него я и буду отталкиваться. Хотя тенденция для всех типов серверов одинакова (смещение +- 1 месяц).
- Самое, пожалуй, интересное, что Heavy Utilization 1 year не оправдал свои описания. Он бьет конкурентов только в последние два месяца (11 и 12) своего контракта.
- Зато Light Utilization 3 years кажется очень привлекательным, ведь охватывает целых 8 месяцев (4 до Heavy, 4 после), что дает не только возможность продлить экономически выгодное использование до 16 месяцев, но и возможность использовать его по прямому назначению (20-40%) напротяжении следующих 20 месяцев.
- Light Utilization 3 years наиболее выгоден для проектов от 3 до 6 месяцев
- Не удивило, что On Demand решение является наиболее экономически выгодным в первые 3 месяца работы, что в пересчете равно 2200 часам. Цена за месяц фиксирована и равна 190.32$
- За вторую половину таблицы борются Medium Utilization 3 years и Heavy Utilization 3 years. Medium значительно снижает риски расходов, поскольку охватывает 33% (17-28 месяцы) таблицы. И, естественно, гибкость оплаты за час делают его достойным кандидатом для выбора.
- Heavy Utilization 3 years выглядит намного достойнее своего годичного собрата. Если сервер нужен на 28 и более месяцев — тут без вопросов. Сумма вопроса — 2,570.30$
- Medium Utilization 1 year — наибольшее разочарование для данной проблематики. Выйграл одну маленькую номинацию для Micro. К сожалению, не заслуживает рассмотрения. Прости, друг!
Ссылки
Остальные вспомогательные таблицы — на гугле
Автор: ozimyj
