Чтобы использовать безопасные #iam_policy для #SSM #Session_Manager, придётся использовать длинную простыню правил:

https://github.com/applerom/cloudformation-examples/blob/master/ssm/ssm-manager-policy.yml

#security

Очень полезный и детальный список #best_practices и #worst_practices или паттернов и анти-паттернов для современного #CI_CD.

https://www.gronau-it-cloud-computing.de/pattern-and-anti-pattern-cicd/

#design

Если вы умеете работать в #AWS_Console, но не умеете или лишь осваиваете #CloudFormation, то для вас #AWSConsoleRecorder может быть бесценной находкой.

https://github.com/iann0036/AWSConsoleRecorder

Вы делаете всё нужное в браузере с помощью плагина, а на выходе получаете готовый сценарий в виде команд, CloudFormation шаблона или других вещей, в частности #Terraform.

Добавление в #ECR возможности тэгировать репозитории может поломать ваши сценарии, т.к. в #IAM добавилось новое #policy 'ecr:ListTagsForResource':

... error getting ECR repository tags: AccessDeniedException: User: ... is not authorized to perform: ecr:ListTagsForResource ...

В прошлом году под Рождество выкатили AWS SSO, в этот раз таким подарком для меня может оказаться AWS Client VPN.

В частности, про #SSO — небольшая утилитка на Go для аутентификации с использованием #Shibboleth Identity Provider.

https://github.com/CUBoulder-OIT/aws-shib

Список всех AWS сервисов, имеющих #SLA:

https://aws.amazon.com/legal/service-level-agreements/

Отличный онлайн-хелпер по #aws_cli:

https://awsclibuilder.com/home

Локальный хелпер по #aws_cli:

https://github.com/awslabs/aws-shell

Использование секции #Rules в #CloudFormation #templates для дополнительной валидации входных параметров (например, чтобы проверить, что один параметр равен другому).

https://www.cloudar.be/awsblog/undocumented-feature-using-template-constraint-rules-in-cloudformation/

Rules:
  ValidateEqual:
    Assertions:
      - AssertDescription: Both parameters must be the same
        Assert:
          "Fn::Equals":
            - !Ref CanBeAnything
            - !Ref MustBeTheSame

Работает лишь в консоли, но для случаев её использования может быть крайне удобным.

Если вы шарите в контейнерах (но при этом вы не бомж), то хронологию новостей по теме #containers можно отслеживать тут:

https://aws.amazon.com/containers/new/

Бывает нужно найти "похожий сервис" в разных облаках. Соответствие сервисов #AWS и #Azure - официальный список от последней:

https://docs.microsoft.com/en-us/azure/architecture/aws-professional/services

Получить объём #s3 бакета:

aws s3api list-objects --bucket my-analytics-logs --output json --query "[sum(Contents[].Size), length(Contents[])]"

[
136474715550,
24283
]
Первое число - объём в байтах, второе - количество файлов.

Посмотреть с помощью #aws_cli объекты в папке s3 бакета и узнать её объём:

aws s3 ls --summarize --human-readable --recursive s3://my-analytics-logs/indices/

Чтобы прокинуть #IAM роль (инстанса) внутрь докера (актуально, например, при запуске тестов в докере на #CodeBuild), нужно использовать переменную AWS_CONTAINER_CREDENTIALS_RELATIVE_URI:

docker-compose run --name MS -e AWS_CONTAINER_CREDENTIALS_RELATIVE_URI app bash -c "python manage.py test -v --junit-report=/report.xml"

→ https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html#troubleshooting-versions
→ https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html

В дефолтной #aws_cli #s3 cp нет возможности скопировать несколько файлов или указать *-wildcard для источника. Для этого используем sync, где можно добавить маски:

aws s3 sync --exclude=* --include=some_files* . s3://mybucket/

При монтировании #EFS через #VPC_peering нужно учитывать, что не все инстансы это позволяют, а лишь современные:
· T3
· C5
· C5d
· I3.metal
· M5
· M5d
· R5
· R5d
· z1d

Иначе (как я последние два дня с T2) получаем ошибку по таймауту: mount.nfs4: Connection timed out.

https://docs.aws.amazon.com/efs/latest/ug/manage-fs-access-vpc-peering.html

Как говорится, «запомните этот пост» — открывается первый фронт будущей широкомасштабной войны. AWS добавил в #SMS поддержку миграции виртуалок с #Azure.

https://aws.amazon.com/about-aws/whats-new/2019/04/announcing_azure_awsmigration_servermigrationservice/

#cloud_war

Чтобы следить за утечкой в общий доступ важных параметров (например, AWS ID) — можно использовать Google Alerts, настроив слежение за свежепроидексированным Google на эти значения.

Узнавать постфактум не лучшая практика, конечно, но лучше уж позже и вы, чем раньше и враги.

#security

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

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

По умолчанию доступ к биллингу аккаунта имеет лишь root-юзер. Добавление другому юзеру (даже с админскими правами) в #IAM политики #Billing не даст доступ к биллингу.

Для этого нужно предварительно активировать IAM User and Role Access to Billing Information (залогившись под рутом). После этого политика Billing будет работать как положено для любого юзера/роли.

https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_billing.html?icmpid=docs_iam_console#tutorial-billing-step2

Спасительный флажок 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 для получения файла, однако такое (переключение в роль) не всегда возможно сделать в уже имеющемся ПО и библиотеках.