Чтобы в #ECS скопировать #task_definition через JSON и потом вставить это при создании другой #task_definition (т.е. сделать условный экспорт-импорт в консоли) - нужно удалить в полученном (скопированном) JSON следующие переменные:

compatibilities
requiresAttributes
taskDefinitionArn
revision
status

Иначе #error: Should only contain "family", "containerDefinitions", "volumes", "taskRoleArn", "networkMode", "placementConstraints", "requiresCompatibilities", "cpu", "memory", "executionRoleArn".

Для #vpc_endpoint типа Gateway не требуется PrivateDnsEnabled, его указывать не нужно (иначе будет #error).

vpcEndpointDynamoDb:
Type: AWS::EC2::VPCEndpoint
Properties:
VpcId: !ImportValue vpc4
ServiceName: !Sub 'com.amazonaws.${AWS::Region}.dynamodb'
RouteTableIds:
- !ImportValue rtbVpc4Dmz
- !ImportValue rtbVpc4Private

Также #vpc_endpoint типа Gateway требует RouteTableIds и работает лишь с ним (указание SubnetIds и/или SecurityGroupIds даст #error). В то время как для #vpc_endpoint типа Interface, наоборот, требуется SubnetIds и/или SecurityGroupIds:

vpcEndpointEc2Messages:
Type: AWS::EC2::VPCEndpoint
Properties:
VpcId: !ImportValue vpc4
ServiceName: !Sub 'com.amazonaws.${AWS::Region}.ec2messages'
PrivateDnsEnabled: true
VpcEndpointType: Interface
SubnetIds:
- !ImportValue subnetVpc4PrivateAppA
- !ImportValue subnetVpc4PrivateAppB
SecurityGroupIds:
- !ImportValue sgVpc4Dummy

Указывать несколько SubnetIds из одной подзоны нельзя (иначе будет #error), потому можно указать лишь Security Group (например, пустую - заглушку). Хотя можно и то, и другое.

#CloudFormation #templates

Разложенные по применению бакет или /* #s3 операции.
То есть, чтобы не ошибиться и не получить #error "Action does not apply to any resource(s) in statement", которая появляется из-за того, что требуется операция к чисто бакету, а не /*, лучше всегда использовать в ресурсах:

            "Resource": [
                "arn:aws:s3:::some-bucket/*",
                "arn:aws:s3:::some-bucket"
            ]

Из рубрик #error + #issue. Пренеприятная проблема была получена при попытке срочного разворота важного окружения. В процессе подъёма #autoscaling_group для #ecs_cluster с несколькими рабочими нодами и сервисами на них с важным моментом - docker image лежит не в ECR, а в #private_docker_hub, то на давно отрепетированном сценарии (правда лишь с одной нодой) вылезла страннейшая ошибка - вторая (!) нода не могла загрузить контейнер. Т.е. первая грузила и успешно работала, а вторая (такая же, этот же образ) - зависала на ошибке:

STOPPED (CannotPullContainerError: API error (404): pull ac)

Не получив образ по таймауту срабатывал откат. Ошибка нерегулярная, т.к. с энной попытки получалось задеплоить и успешно работать. Либо поставить одну ноду - и тогда ни разу не было такой ошибки.
Гуглинг показал, что у такой же ошибки есть братья по разуму, где, судя по всему, такая ситуация возникала именно в связке докерхаб + новый #ecs_agent. И в данном случае он как раз был обновлён. потому наверняка это одна из причин.
После детального изучения выяснилось, что в результате, видимо, каких-то неадекватных лагов с отдачей второго образа, амазоновская команда для подключения в #autoscalig_group:

/opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource autoscalingGroup --region ${AWS::Region}

вылетала в ошибку и расположенный за ней код не исполнялся! И если, как в моём случае, именно после этой команды задавалась переменная ECS_ENGINE_AUTH_DATA для авторизации на докере, то, получается, она не попадала в ecs.config и агент после никак не мог получить доступ к приватному репозиторию.
Изменения последовательности команд - решило проблему. При чём важно учесть, что есть и другие команды, которые обладают таким поведением, потому важный код помещаем в начало #UserData, а проблемные - в самый конец и с учётом важности:
/opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource autoscalingGroup --region ${AWS::Region}
stop ecs
start ecs

При конструировании DNS для #s3 бакет нужно быть максимально внимательным - неоднозначное толкование официальной документации, где говорится про «you can use either of these endpoints» в реальности может давать различные проблемы.
С одной стороны, используя вариант с

.s3.amazonaws.com

даёт в результате перенаправление, а значит изначально #error #307 и лишь потом нужный файл/страницу. Это может приводить к некорректной работе критическим к такому поведению вещей. Например, когда через s3 бакеты подтягиваются конфиг-файлы #nginx, то такое поведение даст ошибку «unexpected end of file, expecting ";" or "}" in /etc/nginx/conf.d/...», т.к. получив 307 он не будет делать ещё один запрос по новому location из ответа. Потому правильно использовать именно вариант типа:

!Join ['',[!Ref Bucket, '.s3-', !Ref 'AWS::Region' , '.amazonaws.com' ]]

Однако бывает и противоположная ситуация, например, с регионом N.Virginia. Для #CloudFront #Origin (в том числе для Logging бакета) DomainName вариант bucket.s3-us-east-1.amazonaws.com даёт стабильные #error 502 для #distribution. Правильный вариант с bucket.s3.amazonaws.com:

Origins:
  - DomainName: !Join ['',[!Ref Bucket, '.s3.amazonaws.com' ]]

#issue

Если при использовании #pg_dump получаем #error схемы #topology

pg_dump: [archiver (db)] query failed: ERROR: permission denied for schema topology

или другого #PostGIS расширения для #Postgres #RDS, то нужно выполнить следующие спеллы:
1. Сменить владельца расширения #rdsadmin на #rds_superuser.
2. Сменить владельца объектов с помощью функции.
alter schema topology owner to rds_superuser;
CREATE FUNCTION exec(text) returns text language plpgsql volatile AS $f$ BEGIN EXECUTE $1; RETURN $1; END; $f$;
SELECT exec('ALTER TABLE ' || quote_ident(s.nspname) || '.' || quote_ident(s.relname) || ' OWNER TO rds_superuser;')
FROM (
SELECT nspname, relname
FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid)
WHERE nspname in ('tiger','topology') AND
relkind IN ('r','S','v') ORDER BY relkind = 'S')
s;

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

Wait at least 6 hours between modifications per EBS volume.

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

Бывает, что, казалось бы, банальное копирование файлов в #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

Если свежесозданный #CloudFront отдаёт #error 307 при доступе в (также свежесозданный) бакет, находящийся не в дефолтном регионе (N.Virginia), то не стоит искать ошибку в вашем шаблоне — это лаг самого Амазона на создание DNS бакета в своём в регионе и тут придётся просто ждать (5-45 минут, в зависимости от текущего здоровья Амазона).
Когда он разродится, ошибка исчезнет сама (чтобы это увидеть быстрей - потребуется инвалидация кэша).

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

Спасительный флажок bucket-owner-full-control, решающий вопросы доступа в #s3 бакет для двух аккаунтов, не поможет для ситуации с тремя и более аккаунтами. Это когда файл копируется из аккаунта A в бакет аккаунта B, а после нужно расшарить это для аккаунта C (также имеющего доступ в бакет аккаунта B).
Использование --acl bucket-owner-full-control не поможет и получим #error:

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

Хотя точно у всех есть нужные #IAM #permissions и прописаны правильные #bucket_policy в #shared_bucket.

Дело в тех же owner-ах, как и для "двух-аккаунтной" схемы, только решается много сложней. Объекты в shared-bucket имеют лишь права для этих двух аккаутов A и B, аккаунт C имеет доступ в бакет, но его нет среди owner-ов объектов, потому ничего с ними сделать не может.

Решается ситуация лишь из аккаута owner-а, т.е. из аккаунта A — при копировании нужно добавить в список owner-ов сразу все аккаунты (т.е. в т.ч. C). Обычная #aws_cli команда s3 cp так не умеет — нужно использовать #s3api:

aws --region=us-east-1 s3api put-object --bucket my-shared-bucket --key my-bucket-dir/conf.tar.gz --body my-local-dir/conf.tar.gz --grant-full-control id=d0cecf42b8a1bed065b8a1b2fdbf76c1b6acda99e0338822e3cece21a8c71058,id=1208ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb11a9338a60609ee5f9,id=780e8bdf2b68d6cc2da2cfcaa6192fac4f437190322277db24ce81ce9aa698f9

Очень непростая и плохо документированная, но рабочая конструкция.
my-shared-bucket — бакет в аккаунте B
--key — путь к файлу в этом бакете
--body — локальный путь к файлу (на виртуалке)
--grant-full-control id=s3-canonical-A,id=s3-canonical-B,id=s3-canonical-C — #s3_canonical аккаунтов A, B и C (именно в таком виде - через запятую без пробела, чего нет в доке, враги)

Не нужно путать S3 Сanonical ID с тем, что используется для CloudFront при доступе в непубличный бакет (S3 canonical user ID). Это уникальный ID для аккаунта, который идёт в паре с AWS ID и может быть получен с помощью aws s3api list-buckets
{
"Owner": {
"DisplayName": "my-account-A",
"ID": "d0cecf42b8a1bed065b8a1b2fdbf76c1b6acda99e0338822e3cece21a8c71058"
},
"Buckets": []
...

Это ID значение получаем для каждого аккаунта, который должен иметь доступ к данному файлу в shared-bucket. Если потребуется расшарить к новому аккаунту - придётся повторить процедуру для каждого файла (объекта).

Потому если нужно раздавать (непубличные) файлы для переменного количества аккаунтов, то #s3 не лучший способ при таком сценарии. В рекомендациях от Амазона это решается с помощью роли в аккаунте A или B, в которую должен переключиться юзер из аккаунта C для получения файла, однако такое (переключение в роль) не всегда возможно сделать в уже имеющемся ПО и библиотеках.