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

Лучшие из известных мне мест для обсуждения темы #AWS (по условному личному рейтингу предпочтения):

===

og-aws (Slack) — инвайт можно получить на https://og-aws-slack.lexikon.io/

Хорошие каналы:
#announcements
#awsannoyances
#cloudformation
#ecs
#general
#mistakes
#security
и другие (#terraform #kubernetes и т.д.)

===

Reddit - https://www.reddit.com

Хорошие комьюнити:
https://www.reddit.com/r/AWS_cloud/
https://www.reddit.com/r/aws/
https://www.reddit.com/r/AWS_Certified_Experts/

===

hangops (Slack) — инвайт можно получить на https://signup.hangops.com/

Хорошие каналы:
#aws
плюс также, конечно, #kubernetes, #terraform, #docker и т.д.

===
===

Русскоязычные:
AWS_ru
AWS Minsk Community

Ну, и данный канал aws_notes (срочно подписываемся, если ещё нет), который веду я, Roman Sevko — пытаясь каталогизировать собственные заметки по Амазону, чтобы и самому не забыть, и другим полезно.

#info

Если у вас активно используется #AWS_Organizations, то стоит задуматься над тем, чтобы прописать пароли у root-юзеров в созданных суб-аккаунтах (что не часто делается, особенно если они создаются автоматически).

Указание фейковой почты для #root_user уязвимо с точки зрения безопасности. Лучшей практикой является установка пароля для рута и включение #MFA на какое-то условно защищённое устройство (и, к примеру, помещённое в сейф).

Кроме того не стоит забывать, что Амазон шлёт некоторые важные (в т.ч. критические - взлом и т.п.) #notifications на почту root-юзера. Это можно в некоторой мере решить, указав Alternate Contacts в настройках аккаунта, однако некоторые сервисы (если не ошибаюсь, #SES), могут слать notifications лишь на рут-почту.

#security #best_practices

В продолжение темы защиты #root_user — для особо опасливых можно посоветовать накрыть всё это дело сверху #SCP политикой для #AWS_Organizations, запрещающей работу из-под рута.

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "aws:PrincipalARN": "arn:aws:iam::*:root"
    }
  }
}

Правда некоторые сервисы под капотом используют (требуют) рута, потому стоит протестировать на чём-то неважном (возможно разбанить нужные сервисы, требующие root).

#paranoid #security

Чтобы узнать (убедиться) какую #IAM роль имеет виртуалка, на которой вы сейчас что-то делаете — используем команду #aws_cli #sts для получения её #ARN #iam_role:

aws sts get-caller-identity

{
    "Account": "123456789012",
    "UserId": "AROAJDDFOVZHPIQJWHGGG:i-012cf7e6be9a23bec",
    "Arn": "arn:aws:sts::123456789012:assumed-role/main-roleEc2-12DC86Q5A4VNV/i-012cf7e6be9a23bec"
}

Тут же и #AWS_ID аккаунта.

Хороший пример оформления #documentation для #kubernetes на #AWS (и просто полезно как краткая документация):

https://kubernetes-on-aws.readthedocs.io/en/latest/index.html

При ошибках в работе с #S3 бакетами есть некоторый набор вещей, что требуется проверить, чтобы найти причину и всё исправить. Очевидные проблемы доступа (не настроенные права) не в счёт, как и вопросы шифрования (это отдельная тема). Далее выстраданные болью и болью вещи.

===
Некоторые достаточно очевидные, что нужно перебрать и проверить.
===

• регион бакета - он может отличаться от того, из которого идёт доступ

• в современных регионах - только Signature Version 4

• популярные ошибки в #IAM: не стоит политика на бакет без * (звёздочки, wildcard):

"Action": [
    "s3:GetObject",
    "s3:ListBucket",
],
"Resource": [
    "arn:aws:s3:::my-bucket",
]

... или наоборот (только с *)

"Action": [
    "s3:GetObject",
    "s3:ListBucket",
],
"Resource": [
    "arn:aws:s3:::my-bucket/*",
]

• есть операция с каталогом, а нет политики 's3:ListBucket'

===
Некоторые не самые и совсем неочевидные (из серии #magic).
===

• сильно отличается время на инстансе (в любую сторону - несколько минут и больше), что часто даёт #error:

A client error (403) occurred when calling the HeadObject operation: Forbidden

• версия #aws_cli старая (локально на старых виртуалках)

• стоит флажок --recursive, а работа идёт с файлом (может возникнуть после копипаста в скриптах) — в результате ничего не будет - ни ошибки (что самое противное), ни копирования файла

• при операциях с https - нужно учитывать заголовки в CORS (что есть HEAD среди них, который часто по дефолту не стоит)

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

• проверяем доступ на конкретный файл с помощью

aws s3api get-object-acl --bucket my-bucket --key my-path/some.file

... если получаем ошибку:

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

... хотя точно есть все права/роли для бакета (на другой аккаунт, нужные операции и путь), то значит файлы в бакете имеют хозяина, недоступного запрашиваемому — см. выше про #shared_bucket
В нормальной ситуации был бы ответ типа:

{
"Owner": {
"DisplayName": "my-dev",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Grants": [
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "my-dev",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Permission": "FULL_CONTROL"
},
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "jenkins",
"ID": "8933ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb82a9338a60609ee5f9"
},
"Permission": "FULL_CONTROL"
}
]
}

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

#s3_debug

Если вы используете #SES, то проконтролируйте, чтобы email для рутов/админов не был фейковый, иначе сообщения об ошибках и прочая информация, которая стандартно отправляется на такую почту, будет постоянно попадать в недоставленные, увеличивая #bounce_rate, в результате чего SES-аккаунт могут забанить.

https://docs.aws.amazon.com/ses/latest/DeveloperGuide/e-faq.html#e-faq-bn

Пинги между регионами #AWS - https://www.cloudping.co/

#info #aws_region

Большинство сервисов для #IAM #policy не допускает использовать пробелы в "Sid", однако #s3 их разрешает, а потому можно (нужно) писать человеческие комментарии к используемым #bucket_policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Full access for Blue, Green",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:root",
"arn:aws:iam::234567890123:root"
]
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
]
},
{
"Sid": "ReadOnly access for Dev, Stage",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::345678901234:root",
"arn:aws:iam::456789012345:root"
]
},
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
]
}
]
}

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

И вот ты такой довольный собой, что потушил всё лишнее (где моя медаль за экономию??), через месячишко-полгодика заходишь в облагороженный аккаунт — опа, что за враги снова запустили остановленные RDS без спросу?!? И давай устраивать допрос с пристрастием. Но после безуспешных пыток девелоперов установкой им новых строгих паролей начинаешь подозревать неладное...

Читайте написанное мелким текстом перед подписанием договора:

You can stop a DB instance for up to seven days. If you don't manually start your DB instance after seven days, your DB instance is automatically started.