В общем случае (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 минут. Если прошло больше и всё равно не работает, то "проблема на вашей стороне".

#note Чтобы задать #json-запрос для #aws_cli со своими параметрами:

aws --region=eu-west-2 deploy create-deployment --cli-input-json "file://create-deployment.json"

Чтобы получить структуру параметров - используем ключик --generate-cli-skeleton.

#note Чтобы обработать что-то в #s3 бакете без сохранения на диск:

aws s3 cp s3://mybucket/file ‐ | bzip2 -best | aws s3 cp ‐ s3://mybucket/file.bz2

В общем случае стоит избегать использования #IAM #ManagedPolicy, т.к. граждане в Амазоне не утруждают себя использованием ограниченных #permissions в них и запросто ставят "жирные" #policy.

Например, в AmazonEC2RoleforSSM, которое рекомендуется для работы с #SSM #Session_Manager, имеется правило на работу #s3 с любыми ресурсами:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetBucketLocation",
    "s3:PutObject",
    "s3:GetObject",
    "s3:GetEncryptionConfiguration",
    "s3:AbortMultipartUpload",
    "s3:ListMultipartUploadParts",
    "s3:ListBucket",
    "s3:ListBucketMultipartUploads"
  ],
  "Resource": "*"
}

#ужас #сколькоможнотерпеть

#info #inter_region #latency #performance #AWS #Azure #GCP
https://marketo-web.thousandeyes.com/rs/thousandeyes/images/ThousandEyes-2018-Public-Cloud-Performance-Benchmark-Report.pdf

При изменении #EBS с обычного на #iops, нужно учитывать, что эта операция может занять некоторое время (до 40 минут для 200ГБ), а вернуть обратно (на обычный) можно будет лишь через шесть часов, иначе #error:

Wait at least 6 hours between modifications per EBS volume.

Кроме того, операция возвращения будет ещё более длительной (раза в два дольше - до двух часов на 200ГБ).

Пример реализации #bucket_policy для нескольких #OriginAccessIdentity в одном #s3 бакете.

policyBucketFiles:
Type: AWS::S3::BucketPolicy
Properties:
Bucket: !Ref bucketFiles
PolicyDocument:
Statement:
- Sid: Access for Cloudfront-files
Effect: Allow
Principal:
CanonicalUser: !GetAtt [originAccessIdentityBucketFiles, 'S3CanonicalUserId']
Action:
- 's3:GetObject'
Resource:
- !Join ['',['arn:aws:s3:::', !Ref bucketFiles, '/files/*']]
- !Join ['',['arn:aws:s3:::', !Ref bucketFiles, '/files_public/*']]
- Sid: Access for SwitchOver Cloudfront-files
Effect: Allow
Principal:
CanonicalUser: !Ref CanonicalUserFilesSwitchOver
Action:
- 's3:GetObject'
Resource:
- !Join ['',['arn:aws:s3:::', !Ref bucketFiles, '/files/*']]
- !Join ['',['arn:aws:s3:::', !Ref bucketFiles, '/files_public/*']]
- Sid: Access for replication account
Effect: Allow
Principal:
AWS: !Join ['',['arn:aws:iam::', !Ref AccountReplication, ':root']]
Action:
- 's3:*'
Resource:
- !Join ['',['arn:aws:s3:::', !Ref bucketFiles ]]
- !Join ['',['arn:aws:s3:::', !Ref bucketFiles, '/*']]

#CloudFormation #templates #examples

Бывает, что, казалось бы, банальное копирование файлов в #s3 бакет:

aws s3 cp ./ s3://some-bucket/files --recursive

Когда это происходит из другого аккаунта, когда бакет расположен в другом регионе или с локального компьютера (между бакетами и т.п. не самые ординарные случаи), даёт странный эффект (#issue) — всё благополучно копируется, но после сам владелец бакета с админскими правами не может получить скопированное, получая #error:

An error occurred (AccessDenied) when calling the GetObject operation: Access Denied

И даже через консоль получаем ошибку доступа к файлам:

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<Error> <Code>AccessDenied</Code> <Message>Access Denied</Message>...

Причина - у Owner-а бакета нет никаких прав на записанное (картинка ниже).
Чтобы исправить — повторяем копирование на источнике с добавлением нужных #ACL #permissions с помощью ключика --acl bucket-owner-full-control, который сразу обеспечит каждому объекту нужные права.

aws s3 cp ./ s3://some-bucket/files --recursive --acl bucket-owner-full-control

Картинка к посту выше.

Бывает нужно узнать, когда была добавлена фича в #CloudFormation - для этого есть #history (или просто можно подписаться на обновления).

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/ReleaseHistory.html