#issue При обновлении #AMI для #ECS Autoscaling group через шаблон - есть проблема для действующих #prod систем. #CloudFormation не учитывает скорости деплоя убиваемых докеров (#task_definition) - новые инстансы (с обновлённым AMI) поднимаются очень быстро и как только они становятся доступными, предыдущие (ещё работающие с набитыми докерами) тупо терминируются. В результате появляется #downtime - пока на поднявшиеся новые инстансы задеплоятся убитые вместе с инстансами докеры.

Обсуждение этой проблемы на Reddit.

Использование в #CloudFormation #templates автоматического получения самого нового #AMI_ID через #ssm_parameters, что было описано в посте и как это рекомендовано в блоге амазона - весьма опасная практика для #prod систем.
Дело в том, что в таком случае вы не контролируете все параметры и когда обновляете прод можете получить нежелательное обновление #AMI. Теоретически процессы должны быть выстроены так, чтобы это не влияло и где-то даже было желательным сценарием (т.к. всегда самый последний - самый защищённый), однако может привести к нежелательным задержкам просто на само обновление. Но страшней, когда порушатся временные костыли.
Потому лучше использовать #mappings для этого - пусть ручное обновление, но контролируемое. А чтобы #по-быстрому получить #latest_ami_id - можно использовать скрипты.

#AmiLinux2:

for region in $(aws ec2 describe-regions --region us-east-1 --query 'Regions[].[RegionName]' --output text | sort); \
do printf "    ${region}:\n      AmiId: $(aws ssm get-parameters --names /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 --query 'Parameters[0].[Value]' --output text --region $region)\n" ; done

#ECS_optimized:

for region in $(aws ec2 describe-regions --region us-east-1 --query 'Regions[].[RegionName]' --output text | sort); \
do printf "    ${region}:\n      AmiId: $(aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux/recommended/image_id --query 'Parameters[0].[Value]' --output text --region $region)\n" ; done

Примеры кода.

Использование T2/T3 инстансов в проде

Можно ли использовать T2/T3 для #EC2, #RDS и прочих сервисов в продовских окружениях? Запросто. Нужно лишь помнить и учитывать моменты, которые отличают их от "полноценных" инстансов. Это baseline (нагрузка) и сеть (задержки).

Baseline (нагрузка)

Если у вас постоянная/долговременная нагрузка на проде выше #baseline (правая колонка):

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html

То он будет тормозить. Что плохо, точней, обычно недопустимо, потому ставим "полные" c4/c5/m4/m5 и т.д.

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

Сеть (задержки)

Если с первым (загрузкой) более-менее всем понятно, то вот второй фактор многие не учитывают - скорость сети у T2/T3 инстансов не только ниже, а временами хромает, ковыляет, страдает и даже просто, бывает, лежит. Дипломатично в документации это называется "не гарантирована".

Для каких-то сервисов это может быть не столь критично, а вот лаги RDS на T2/T3 могут стать неприятным откровением. В таком случае активно используйте кэширование, мониторинг и здравый смысл.

Реальную скорость сетевого интерфейса и её катастрофу, когда кончаются бурсты - можно посмотреть по следующей полезной ссылке:

https://cloudonaut.io/ec2-network-performance-cheat-sheet/

Итого

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

Хочешь (нужно) сэкономить, протестировано, мониторинг, кэширование и прочий фарш помноженный на рассудок - смело используем T2/T3, в том числе на проде.

#t2 #t3 #prod