Использование в #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

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

⁠Поддержка Secrets в Environment для #Fargate появилась в конце 2018-го года (версия Fargate 1.3), но на текущий момент в документации есть только следующее. Получается, это можно реализовать и в #CloudFormation #templates, однако документация, как обычно, отстаёт и хромает, хотя это уже работает.

Предположим, что нужно поднять какой-то Fargate контейнер, создать для него #SSM_Parameters, которые прокидываются в докер Environment, чтобы после можно было поменять нужный параметр без пересоздания всего стэка (для применения, естественно, потребуется пересоздание таски).

Главная часть кода для имплементации такого будет следующая:

...
ssmparamDbEndpoint:
 Type: AWS::SSM::Parameter
 Properties:
   Name:  !Ref ParamNameDbEndpoint
   Type:  String
   Value: !Ref DbEndpoint
   Description: SSM Parameter for DB endpoint
...
fargateTask:
 Type: AWS::ECS::TaskDefinition
 Properties:
   ContainerDefinitions:
   - Name:      !Ref ServiceName
     Image:     !Ref DockerImage
     Essential: true
     Secrets:
       - Name: WORDPRESS_DB_HOST
         ValueFrom: !Join ['',['arn:aws:ssm:', !Ref 'AWS::Region', ':', !Ref 'AWS::AccountId', ':parameter/', !Ref ParamNameDbEndpoint]]
       - Name: WORDPRESS_DB_USER
         ValueFrom: !Join ['',['arn:aws:ssm:', !Ref 'AWS::Region', ':', !Ref 'AWS::AccountId', ':parameter/', !Ref ParamNameDbUser]]
       - Name: WORDPRESS_DB_PASSWORD
         ValueFrom: !Join ['',['arn:aws:ssm:', !Ref 'AWS::Region', ':', !Ref 'AWS::AccountId', ':parameter/', !Ref ParamNameDbPassword]]
     Environment:
       - Name: WORDPRESS_DB_NAME
         Value: wp-db
...

Т.е. добавляется блок Secrets, куда значения из #ParameterStore попадают благодаря такой конструкции:

arn:aws:ssm:YOUR_AWS_REGION:YOUR_AWS_ACCOUNT:parameter/PARAMETER_NAME

Полный (рабочий) пример тут.

На текущий момент параметры из блока Secrets не отображаются в AWS Console (см. картинку внизу - она из примера), однако точно работают (можно попробовать пример). Хотя с некоторыми регионами могут быть вопросы - точно работает (проверено) для Virginia и Ireland.