При использовании #ELB (созданного через #CloudFormation) с большим количеством инстансов, стоит помнить про фичу Cross-Zone Load Balancing, которая отключена по умолчанию (при создании балансера через консоль - включена по умолчанию).
Итого: для #ELB её нужно включать для более гладкого распределения трафика. У #ALB всегда включена, у #NLB - нужно включать самому.

#EC2 #network #performance cheat-sheet.

#info

Пример использования Amazon #Connect + #Lambda +Amazon #Lex для реализации #ASR (Automatic #Speech_Recognition).

Ещё один #tutorial для #serverless #chatbot на Amazon #Lex + #Lambda + Amazon #Aurora

Для #ECS наконец появились образы на базе #AMILinux2 - ECS-Optimized Amazon Linux 2 AMI. Для автоматического получения добавляем '-2' в конце. Или скрипт для #CloudFormation #templates:

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-2/recommended/image_id \
--query 'Parameters[0].[Value]' --output text --region $region)\n" ; done

Операции, требующие root-логина. #root

Использование #Lambda в #VPC сильно замедляет её старт, точней очень сильно (10 секунд плюс). #issue

И ещё про такую же #issue — #API_Gateway + #lambda + #vpc #performance.

Используя какую-то #IAM роль для переключения в другую роль, нужно не забывать про role chaining:
Using the credentials for one role to assume a different role is called role chaining. When you use role chaining, your new credentials are limited to a maximum duration of one hour.
Это в, в частности, объясняет раздражающую всех проблему при использовании AWS #SSO - когда через час сбразывается сессия.

Cloud Custodian https://capitalone.github.io/cloud-custodian/docs/index.html подойдёт для реализации #compliance, проверки #policy и всевозможных требований к различным #environment. При этом #serverless и помимо #AWS поддерживает также #Azure и #google #GCP.

В общем случае (99%) лучше не использовать #NACL (Network ACL), т.к. их использование в дополнение к #security_group сильно запутывает будущую поддержку (можно забыть и долго после вспоминать, почему не работает, хотя доступ стоит), однако они могут выручить, если нужно:
—быстро/просто забанить внейшний айпишник (а нет возможности-желания лезть в инстанс и делать это через #iptables)
— разграничить доступ (изолировать) между подсетями внутри одной #VPC

Чтобы ограничить доступ на отдельный #Region, то в #IAM с середины 2018-го года имеется специальный #condition aws:RequestedRegion:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllRegionsExceptFrankfurt",
"Effect": "Deny",
"NotAction": [
"iam:*",
"organizations:*",
"support:*",
"aws-portal:*",
"route53:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"eu-central-1"
]
}
}
}
]
}

Блок "NotAction" добавлен для регионов, которые глобальные (чтобы к ним не применялось это правило).

В погоне за #kubernetes в #ECS добавили #Service_Discovery.

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html

Исправление "раздражающей всех проблемы" — у #SSO появилась возможность установить Session Duration.

Чтобы узнать #instance_type из #metadata на самой #ec2 виртуалке:

wget -T 10 -O- https://169.254.169.254/latest/meta-data/instance-type 2>/dev/null

https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-instance-metadata.html

Когда нужно подобрать/оценить нужный тип #EC2 инстанса по требованиям типа "ходовые и только самые современные с 4 или 8 процессорами в Лондоне", то можно использовать regex ((c|m)5|t3).*(4|8) vCPUs на https://ec2instances.info/?filter=((c%7Cm)5%7Ct3).*(4%7C8).vCPUs&region=eu-west-2 — #info.

#recommendation — для имён переменных в #CloudFormation #templates лучше не использовать имена переменных, начинающихся с имени стэка, т.к. в Physical ID добавляется имя стэка и возникает визуальная путаница (особенно при использовании #nested_stacks):
jdot-St1IAM-16Z64H1UDUQF3-jdotInstanceProfile-WJ74BPFLW925

#recommendation Используемая практика именования переменных в #CloudFormation #templates у самого Амазана весьма ущербная - параметры начинаются с маленькой буквы p, а ресурсы начинаются с маленькой r:

pDMZSubnetA
rDMZSubnetA

Ущербность выявляется, когда выходишь за пределы одного стэка (особенно явно в #nested_stacks) — приходится переименовывать "бывшие" в одном стэке ресурсы в параметры в другом, что приводит при такой схеме к смене имени и сильно затрудняет сопровождение, а также плодит ошибки при переиспользование кода.

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

Кроме того, в имени ресурса почти всегда принципиально видеть тип, потому пример выше преобразуется в:

SubnetDmzA
subnetDmzA

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

#note При копировании #s3_cp или синхронизации #s3_sync пустые каталоги не создаются, т.к. #S3 работает с объектами (файлами) и не в курсе про каталоги (это лишь путь к объекту).
Если нужно с пустыми - используем сторонние утилиты (например, S3cmd).
При особо страстном желании, можно добавить энный плюсик в просьбу добавления такого функционала в официальную версию.

#note После применения (изменения) #IAM_role на инстанс, права изменяются (обновляются) где-то через 30 секунд, а после добавления в #role новой #policy — где-то 2-3 минуты.
При проблемах на амазоне максимальное время применения #IAM — 5-6 минут. Если прошло больше и всё равно не работает, то "проблема на вашей стороне".