Блог

ТРЕБОВАНИЯ: у меня есть 1 m5.xlarge экземпляр EC2. Время от времени я увеличиваю масштаб до в m5.2xlarge течение короткого периода времени, затем уменьшаю до m5.xlarge . Я не масштабирую по горизонтали, поэтому не могу использовать более 1 экземпляра.
В течение 6 месяцев я мог бы значительно увеличить свой трафик, поэтому мне, возможно, придется перейти на m5.2xlarge основу и, возможно, время от времени m5.4xlarge увеличивать.
У меня также есть 1 cache.r5.large (Redis Elasticache) и 1 db.r5.large (aurora) с теми же ограничениями, что и выше.

ВОПРОСЫ: Давайте начнем с экземпляров EC2.
Я хочу сэкономить и оценить стандарт RI, включая возможность:

1. время от времени увеличивать / уменьшать масштаб m5.xlarge/m5.2xlarge и
2. возможно, перейти к m5.2xlarge использованию в качестве основы

Допустим, я резервирую 1 m5.xlarge . Что касается

1. Я могу временно увеличить масштаб до m5.2xlarge . Я применю экономию до 50%. остальные 50% я оплачу по требованию. имеет смысл. Что касается
2. Мне нужно было бы изменить мое резервирование RI на m5.2xlarge , но я думаю, я не могу, потому что я прочитал: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-modifying.html#ri-modification-instancemove

Исходный и новый зарезервированные экземпляры должны иметь одинаковый размер экземпляра.

m5.2xlarge и m5.xlarge у меня другая площадь, поэтому я не могу этого сделать.
Есть альтернатива?
например, я могу понять, что мне нужно купить еще m5.xlarge один, поэтому у меня есть 2 m5.xlarge , которые будут применяться на 100% для моего m5.2xlarge ?
Единственной потенциальной проблемой является дата истечения срока действия, у 2 RI будет 2 разных срока действия.
Чтобы решить эту проблему, у меня есть возможность объединить 2 RIS, верно? итак, я объединю свои 2 m5.xlarge RI в 1 m5.2xlarge (и, конечно, срок действия будет самым длинным)?

Надеюсь, я правильно понял. Я хочу дважды уточнить у вас, прежде чем продолжить.

теперь о RDS: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithReservedDBInstances.html Кажется, то же самое для 1) и 2)

а что касается Elasticache, документ легкий: https://aws.amazon.com/elasticache/reserved-cache-nodes / Я понимаю, что 1) то же самое, но понятия не имею о 2), поскольку они не упоминают о расширении RI

RI увеличивают объем планирования и мониторинга, чем мы предполагали изначально.

При планировании экономии затрат на EC2 я бы рекомендовал выбрать «План экономии», а не RI. Сберегательные планы гораздо более гибкие, чем РИС.

В тех случаях, когда нам приходится покупать RIS, всегда покупайте несколько самых маленьких отпечатков семейства, которые мы хотим. Поэтому, когда вы планируете масштабирование, всегда старайтесь приобретать самую маленькую единицу измерения (m5.large).

Теперь перейдем к вопросу о слиянии. Если запрос на изменение проходит, то рассматривается более длительное время. Ниже приведен фрагмент из блога AWS:

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

Ссылка здесь

И все остальные ваши понимания и предположения верны.