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





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

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

Мы в «Битрикс24» очень активно используем Amazon Web Services, и в этой статье я расскажу о нескольких возможностях AWS, которые помогут вам сократить ваши расходы.

«Битрикс24» — глобальный сервис, мы работаем для клиентов по всему миру. С 2015 года, с момента вступления в силу закона 242-ФЗ о локализации персональных данных, данные российских пользователей хранятся на серверах в России. А вот вся инфраструктура сервиса, обслуживающего остальных клиентов по всему миру, развёрнута в Amazon Web Services.

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

В этих условиях, если вы продолжаете размещать ваши ресурсы в AWS, вам, скорее всего, будут интересны приёмы, которые помогут вам сэкономить на аренде инфраструктуры.

Я расскажу об основных из них, которые мы сами уже много лет используем. Если же есть какие-то еще способы, которые используете вы — пожалуйста, делитесь в комментариях.

Итак, поехали.

RI — Reserved Instances


Самый простой и очевидный способ сэкономить в AWS — использовать зарезервированные инстансы EC2. Если вы знаете, что определенные инстансы вы совершенно точно будете использовать, как минимум, в течение года, вы можете внести за них предоплату и получить скидку от 30% до 75%.

Пример расчетов для инстансов c5.xlarge:

image

Все цены и расчеты — здесь.

Иногда выглядит сложно и запутанно, но в целом логика такая:

  • Чем больше срок резервирования — 1 или 3 года — тем больше скидка.
  • Чем больше предоплата сразу — можно вообще без предоплаты, можно использовать all upfront, полную предоплату — тем больше скидка.
  • Если резервируем конкретный тип инстанса, а не используем конвертируемый — больше скидка.

Для себя мы делаем резервирования на 1 год, потому что на 3 года планировать довольно сложно. И это позволяет неплохо экономить на EC2.

Spot Instances


Использование Spot Instances — это по сути некоторая биржа ресурсов. Когда у Amazon есть много простаивающих ресурсов, вы можете для специальных «спотов» (Spot Instances) задать максимальную цену, которую вы готовы за них платить.

Если текущий спрос в определенном регионе и AZ (Availability Zone) мал, то вам предоставят эти ресурсы. При чем по цене в 3-8 раз ниже, чем цена on-demand.

В чем подвох?

Исключительно в том, что если свободной емкости не будет, запрошенные ресурсы вам не дадут. И если спрос резко вырастет, и цена на споты превысит вашу заданную максимальную цену, ваш спот будет удален (terminate).

Естественно, такие инстансы не подойдут, например, для БД в продакшене. Но для каких-то задач, которые связаны, например, с теми или иными расчетами, рендерингом, обсчетом моделей, для тестов — отличный способ сэкономить.

Посмотрим на практике, за какие суммы бьемся. И часто ли споты могут «уходить» по цене.

Вот для примера Spot Instance Pricing History прямо из консоли AWS для региона eu-central-1 (Франкфурт) для инстансов c5.4xlarge:

image

Что мы видим?

  • Цена примерно в 3 раза ниже, чем on-demand.
  • Есть доступные spot instances во всех трех AZ в этом регионе.
  • За три месяца цена ни разу не вырастала. Это значит, что запущенный три месяца назад спот с заданной максимальной ценой, например, $0.3 до сих продолжал бы работать.

Как мы используем споты на практике:

image

— Мы используем споты для серверов приложений.

— Для них мы активно используем связку CloudWatch + Auto Scaling — для автоматического масштабирования в течение дня: нагрузка возрастает — запускаются новые инстансы, нагрузка падает — они гасятся.

— Для подстраховки у нас за балансировщиками работают две Auto Scaling группы — на тот случай, если споты закончатся. Одна AS группа — с обычными (on demand) инстансами, вторая — со спотами. Amazon через CloudWatch Events предупреждает за 2 минуты о том, что spot instance будет удален (terminate). Мы обрабатываем эти события и успеваем расширить основную группу до нужного количества инстансов, если такое происходит.

Подробности вот здесь — Spot Instance Interruption Notices.

— Чтобы эффективнее работать с Auto Scaling и по максимуму использовать именно машины в группе со спотами, мы применяем такой подход:

  1. У spot группы более низкий верхний трешхолд — начинаем раньше масштабироваться «вверх».
  2. И более низкий нижний трешхолд — начинаем позже масштабироваться «вниз».
  3. У обычной группы — наоборот.

EC2 Instance Store


Все, кто работает с AWS, знают, что основные диски, которые используются для EC2 инстансов — это EBS (Elastic Block Store). Их можно монтировать к инстансам, отключать, монтировать к другим инстансам, делать с них снэпшоты.

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

При этом для многих типов инстансов при их создании доступно подключение локальных дисков — EC2 Instance Store.

Главная особенность этих дисков — если вы останавливаете (stop) инстанс с таким диском, то потом после старта эти данные теряются.

Но при этом они условно бесплатны — есть плата только за сам инстанс.

Такие диски можно отлично использовать под любые временные данные, которые не требуют постоянного сохранения — свопы, кэш, любые другие временные данные. Производительность Instance Store дисков достаточно высока: кроме уж совсем старых типов инстансов сейчас под них используются либо SSD, либо NVMe SSD.

В итоге: подключаем меньше EBS дисков, меньше платим.

S3 Incomplete Multipart Uploads


Выше речь шла, в основном, о EC2. Дальше опишем несколько приемов, которые позволят сэкономить при использовании S3 (Simple Storage Service).

Если вы активно работаете с S3, то, наверняка, знаете, что и S3, и большинство клиентов для работы с этим хранилищем поддерживают Multipart Upload — большой объект загружается «кусочками», которые затем «собираются» в единый объект.

Это отлично работает, но есть одна засада.

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

И неприятный сюрприз — эти неполные данные никак не видны при работе со стандартными инструментами для S3: ни через «ls» в cli, ни в программах-клиентах. Найти их можно, например, в aws cli с помощью команды list-multipart-uploads.

Но так с ними работать слишком утомительно…

Самым логичным было бы вынести какую-то опцию про хранение Incomplete Multipart Uploads в настройки конкретного бакета. Но почему-то Амазон так не сделал.

Тем не менее, способ облегчить себе жизнь и удалять автоматом Incomplete Multipart Uploads есть. В настройках бакета на вкладке Management есть раздел Lifecycle. Это удобный инструмент, который позволяет настраивать различные автоматические правила для работы с объектами: перемещать их в другие хранилища, удалять через какое-то время (expire) и — в том числе — управлять поведением Incomplete Multipart Uploads.

image

Подробная статья про это есть в блоге AWS — правда, с примерами из старого интерфейса, но там всё довольно понятно.

Важно то, что настроенный на удаление неполных данных Lifecycle сработает не только для новых объектов, но и для уже имеющихся.

За реальным объемом занятого в S3 места можно следить через CloudWatch. Когда мы настроили удаление Incomplete Multipart Uploads, с удивлением обнаружили, что освободили не один десяток терабайт…

S3 Intelligent Tiering


В S3 есть несколько разных классов хранилищ:

  1. Стандартный.
  2. Standard-IA (infrequently accessed) — для объектов, к которым редко обращаются.
  3. One Zone-IA — для относительно некритичных данных. В этом классе объекты реплицируются в меньшее количество точек.
  4. Glacier — очень дешевое хранилище, но из него нельзя получить объект моментально. Нужно сделать специальный запрос и ожидать некоторое время.

Все они имеют разные условия использования и разные цены. Их можно и нужно комбинировать — в зависимости от ваших разных задач.

Но относительно недавно появился еще один очень любопытный тип хранилища — Intelligent Tiering.

Суть его работы в следующем: за небольшую дополнительную плату осуществляется мониторинг и анализ ваших данных в S3, отслеживаются обращения к ним, и, если обращений нет в течение 30 дней, объект автоматически перемещается в хранилище нечастого доступа, которое стоит значительно дешевле стандартного. Если через какое-то время к объекту опять обращаются — никакого снижения производительности при этом не происходит — он опять перемещается в хранилище стандартного доступа.

Самое главное удобство: вам самим не надо ничего делать.

Amazon все сделает «по-умному» сам — разберется, какие объекты куда сложить.

Мы, включив Intelligent Tiering, на некоторых бакетах получили экономию до 10-15%.

Всё звучит слишком хорошо и волшебно. Но не может же не быть каких-то подводных камней? Они есть, и их, конечно, надо учитывать.

  • Есть дополнительная плата за мониторинг объектов. В нашем случае она полностью покрывается полученной экономией.
  • Можно использовать Intelligent Tiering для любых объектов. Однако объекты менее 128 Кб никогда не будут переведены на уровень нечастого доступа и всегда будут оплачиваться по обычной цене.
  • Не подходит для объектов, которые хранятся менее 30 дней. Такие объекты все равно будут оплачиваться, как минимум, за 30 дней.

Как включить Intelligent Tiering?

Можно в явном виде указать класс хранения INTELLIGENT_TIERING в S3 API или CLI.

А можно настроить правило Lifecycle, по которому, например, все объекты после определенного времени хранения будут автоматически перемещаться в Intelligent Tiering.

image

Подробнее — в том же блоге AWS.

Glacier


Если уж мы заговорили о разных классах хранилищ в S3, то, конечно же, стоит упомянуть и Glacier.

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

Для удобной работы с Glacier можно использовать все те же правила Lifecycle.

Например, можно задать правило, по которому объект будет какое-то время храниться в обычном хранилище, например, 30-60 дней (обычно доступ нужен к наиболее близким по времени логам или бэкапам, если мы говорим об их хранении), затем будет перемещаться в Glacier, а по истечение 1-2-3… лет — полностью удаляться.

Это будет в разы дешевле, чем хранение просто в S3.

* * *

Я рассказал о некоторых приемах, которые мы сами активно используем. AWS — огромная инфраструктурная платформа. Наверняка, мы не рассказали о каких-то сервисах, которые используете именно вы. Если есть какие-то еще способы экономии в AWS, которые пригодились именно вам — пожалуйста, делитесь в комментариях.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (28):

  1. Dekmabot
    /#21426822

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


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

    • adamant
      /#21426978

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

  2. darken99
    /#21426828

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

    • adamant
      /#21426980

      Почему?

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

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

      • darken99
        /#21427256

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

    • megareez
      /#21426984

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

  3. eumorozov
    /#21427254

    По моему личному опыту, AWS вообще не для экономных. Любой другой вариант окажется дешевле. Мой опыт не такой большой (хотя согласуется с этим наблюдением тоже), но также читал не одну статью на различных ресурсах (например, Hacker News), о том, что почти любая альтернатива намного дешевле AWS. Например, более скромные провайдеры или свое железо.


    У меня была вообще странная ситуация год назад. Работал в компании, в которой всю инфраструктуру подняли на AWS до меня. В т.ч. все базы перенесли на RDS. Потом начались загадочные проблемы: база растет как на дрожжах (причем объем хранимых данных не растет, если смотреть размер таблиц), приходится постоянно увеличивать для RDS доступное место. За счет чего растет — не узнать, т.к. RDS, в отличие от собственного инстанса, чёрный ящик. Мне не удалось выяснить, во всяком случае. Была масса другой работы, бился над этим несколько часов, гуглил, ничего понять не удалось, пришлось вернуться к более приоритетным задачам. А ведь RDS как раз и продается, как решение любых проблем: типа, вы отдаете все задачи администрирования нам на откуп, и больше у вас не болит голова. Оказалось, что к сожалению болит. Возможно, надо было обратиться в поддержку.


    Точно такая же staging конфигурация, как production, но поднятая на DigitalOcean, работала как часы, размер базы не рос. Размер таблиц одинаковый, если сравнивать. После нескольких увеличений объема платить за эту RDS пришлось столько, что владелец бизнеса стал биться в истерике.


    Я закатал рукава, и перенес всю инфраструктуру в DigitalOcean (благо, она достаточно простая, и это заняло всего несколько дней). Счета за хостинг уменьшились на порядки, и более не было никаких проблем с необъяснимым ростом базы — она живет на диске, который раз в 10 меньше, чем тот, что был на RDS, уже больше года. До сих пор никаких проблем, а общий счет за хостинг сократился с десятков тысяч $$$ до десятков, может быть сотен, $$. За год экономия вышла такая, что можно собственный небольшой дата-центр построить.


    P.S. Часто рекламируют преимущество облаков как перевес OPEX над CAPEX. Но reserved instances — это как раз и получается почти что CAPEX, нет? Если платить за год вперед, то возможно купить свое железо можно будет за те же деньги.


    P.P.S. Задолго до этого, на другой работе, перенесли всю инфраструктуру в AWS. Производительность сервисов ощутимо упала. Пришлось тратить время разработчиков на переделывание архитектуры под горизонтальное масштабирование: шардирование и т.п. В итоге, не знаю, стоило ли оно того. Один железный сервер с легкостью бы для того сервиса выдержал любую нагрузку без изменения кода. И стоил бы дешевле, чем зарплаты нескольких человек на изменение архитектуры в течение нескольких месяцев.

    • click0
      /#21427660

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

    • eugene08
      /#21428022 / +1

      Непонятно, что за проблема была в рдс, зря не обратились в тех поддержку. Но факт что рдс сильно уменьшает головную боль поддержки бд — уже много лет не чинил сломанную репликацию в мускуле среди ночи, чему очень рад.
      Ну и помимо рдс, есть много сервисов которые очень сложно (по факту, невозможно, сделать на таком же уровне и по такой цене) например, S3. Напомню, durability 99.999999999, Intelligent tiering, события, lifecycle, SQL и все это за 1-2 цента за гиг. Условному вендору вы занесете не один чемодан денег и в лучшем случае там будет только durability.
      Автоскейлинг и лб — сколько стоит парочка F5 думаю сможете сами найти :) Ну или пилите самостоятельно keepalived/haproxy…
      Обойтись конечно же можно, но учитывая возможности и отличную сертифицированную инфраструктуру, прибыльные проекты часто идут в амазон — сменил уже 3 больших компании которые в итоге перенесли все в амазон, отказавшись от собственных ДЦ и прошлого века вроде ракспейс.

      • eumorozov
        /#21428036

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


        Ну, и в изначальном сообщении я забыл сказать, что с AWS уехало все, кроме S3.


        У всех разные масштабы и требования. Для относительно небольшого проекта (ну, меньше уровня Google/Facebook) идти в AWS — выбрасывать кучу денег на ветер.


        Мой посыл прежде всего не то, что AWS плохой, а то, что он очень дорогой. Реально дорогой, почему-то многие этого не понимают. Когда есть инвесторы, которые не считая вваливают мешки денег, это наверное не проблема.


        В моей конкретной ситуации, как я уже говорю, месячный счет за хостинг уменьшился с 5-значных цифр до суммы не более $300-400 в месяц. И для компании это была большая разница (не знаю, почему, я не бухгалтер, и никто меня в детали финансирования не посвящал).

        • eugene08
          /#21428062

          > меньше уровня Google/Facebook
          имхо таким как раз в амазон можно не идти, делать свои дц под себя будет дешевле.
          А вот средним проектам как раз и есть смысл смотреть и считать.

          > месячный счет за хостинг уменьшился с 5-значных цифр до суммы не более $300-400 в месяц
          охотно верю, что то некритичное и не завязанное плотно на другие сервисы можно вынести.

          > идти в AWS — выбрасывать кучу денег на ветер
          ой
          у меня сейчас в одном из прод окружений количество нод в сутки прыгает от 2 до 15, не прод окружения (а их много) когда не используются — выключаются. Если выносить это на железо — надо закупать по верхней планке использования и с запасом.

        • Stas911
          /#21428336

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

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

          • eumorozov
            /#21428402

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


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


            И таких ситуаций видел много. Вместо того, чтобы идти в AWS, когда это действительно нужно, идут сразу, потому что модно. Переплачивают в 10 раз, потому что не из своего кармана, а «дурные» деньги инвесторов. Хотя и те имеют свойство рано или поздно заканчиваться. К сожалению, тоже имел такой опыт, тоже работая в стартапе, который простое приложение хостил на AWS, переплачивая в десятки раз за то, с чем легко справился бы дроплет за $5 на DigitalOcean. Если бы не это, кто знает, может дотянул бы до первых прибылей...

            • Crazyvlad
              /#21428646

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

            • Stas911
              /#21431030

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

  4. Crazyvlad
    /#21427388 / +1

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

    • adamant
      /#21427644

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

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

      • Crazyvlad
        /#21428664

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

        • adamant
          /#21428682

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

    • CherryPah
      /#21427738 / +2

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

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

  5. arheops
    /#21427442

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

    • adamant
      /#21427650

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

      • arheops
        /#21427726

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

  6. gaploid
    /#21427558 / +4

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

    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
      /#21427652 / +1

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

  7. vitaly_il1
    /#21428648

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

  8. gipox
    /#21432484

    о будете делать при курсе доллара 140 р?

  9. john_soft
    /#21432486 / +1

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