Получаем последние версии AMI ID с помощью SSM Parameter Store.
Amazon Linux 2:

LatestAmiId:
Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
Description: Latest Amazon Linux 2 AMI ID
Default: /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2
...
ImageId: !Ref LatestAmiId

ECS-optimized:
LatestEcsAmiId:
Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
Description: Latest ECS-optimized 2 AMI ID
Default: /aws/service/ecs/optimized-ami/amazon-linux/recommended/image_id

#CloudFormation #ami #ami_id #ssm #ssm_parameter

#recommendation - периодически обновлять #AMI (в т.ч. докерных образов, как минимум сервисного) - раз в квартал (так обычно выходят обновления Amazon Linux).
Для срочных патчей (очередная критическая уязвимость чего бы то ни было) - отработать процедуру запуска критических обновлений.

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

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

Если добавлять #vpc_endpoints на что-то (с политиками), например, лишь для загрузки пакетов для обновления #AMI (), то вид следующий:

vpcEndpointS3:
Type: AWS::EC2::VPCEndpoint
Properties:
VpcId: !ImportValue vpc4
ServiceName: !Sub 'com.amazonaws.${AWS::Region}.s3'
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal: '*'
Action:
- 's3:GetObject'
Resource:
- 'arn:aws:s3:::packages.*.amazonaws.com/*'
- 'arn:aws:s3:::repo.*.amazonaws.com/*'
RouteTableIds:
- !ImportValue rtbVpc4Dmz
- !ImportValue rtbVpc4Private

#CloudFormation #templates

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

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

Для решения такой проблемы можно использовать специально обученную #Lambda, которая триггерится перед удалением инстанс в #ECS cluster, когда обновляется #AMI инстанса:

https://aws.amazon.com/blogs/compute/how-to-automate-container-instance-draining-in-amazon-ecs/

Встроенный SSM-агент для ECS-Optimized Amazon Linux 2 AMI:

https://aws.amazon.com/about-aws/whats-new/2020/02/amazon-ecs-optimized-linux-2-amis-come-pre-installed-aws-systems-manager-agent/

Теперь можно будет убрать из скриптов ставшую лишней строчку yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm (т.к. теперь SSM-агент идёт из коробки).

#SSM #ECS #AMI

Когда нужно в каком-то аккаунте почистить орды кем-то наделанных EBS снэпшотов и AMI-образов, то вручную кликать можно устать. Для автоматизации процесса подойдёт простая утилитка:

https://github.com/bonclay7/aws-amicleaner

#EBS #AMI

​​Weekly Summary on AWS (March 6 - 12)

🔸 Amplify iOS Library + Swift
🔸 Aurora PostgreSQL + Multi Major Version Upgrade
🔸 Braket + OpenQASM 3.0
🔸 Chime SDK + live transcription with automatic language identification
🔸 Comprehend + Targeted Sentiment
🔸 DevOps Guru + CodeGuru Profiler for Lambda
🔸 DynamoDB
➖ Limit request option for PartiQL
➖ Tables Per Account 256 → 2,500
➖ Еnable management operations 50 → 500
🔸 EC2 AMI + LastLaunchedTime
🔸 EC2 + X2idn/X2iedn instances 💥
🔸 ECS Update Service API + loadBalancers, propagateTags, enableECSManagedTags, and serviceRegistries 👀
🔸 Glue DataBrew + cross-account Glue Data Catalog S3 access
🔸 Lambda + PrincipalOrgID 💪
🔸 Lightsail + S3 block public access 🎉
🔸 MSK Connect + Secrets Manager
🔸 Personalize + CloudFormation
🔸 QuickSight + auto refresh
🔸 SSM Change Manager + approve/reject multiple change requests together

🔹 Bottlerocket + NVIDIA GPUs 👍
🔹 Genomics CLI + Snakemake
🔹 RDS for MySQL + 5.7.37 and 8.0.28
🔹 RDS for Oracle + Oracle Database 21c
🔹 RDS for PostgreSQL + 14.2, 👈 13.6, 12.10, 11.15, and 10.20
🔹 RDS for SQL Server + M6i/R6i instances

#AWS_week

​​Analysis of 3 million public AMIs for leaked secrets.

https://securitycafe.ro/2024/05/08/aws-cloudquarry-digging-for-secrets-in-public-amis/

#AMI #security

aws-amicleaner — a cost-saving tool for deleting unused AMIs and EBS snapshots.

https://github.com/widdix/aws-amicleaner

#EC2 #AMI #cost_optimization