⁠Тэги для AWS Account

C недавнего времени можно добавить #tags на весь AWS Account - это делается в консоли AWS #Organizations (см. картинку) или через командную строку. Если у вас активно используется #multi_account_strategy, то этим точно стоит воспользоваться.

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_tagging.html

AWS Control Tower

То, о чём так часто тут говорилось - #multi_account_strategy - наконец-то воплотилось в рабочий сервис у амазона. Встречаем AWS #Control_Tower:

https://aws.amazon.com/blogs/aws/aws-control-tower-set-up-govern-a-multi-account-aws-environment/

Однако те, кто уже использует AWS #Organizations будут грустить, ибо получат ошибку:

You tried to use an account that is a member of an organization in AWS Organizations. To set up your AWS Control Tower landing zone, use an account that is not a member of an organization.

Потому воспользоваться AWS Control Tower смогут лишь избранные 90%, кто до этого времени не успел ознакомиться со своим счастьем в виде AWS Organizations.

#строили_строили_и_наконец_построили

Несколько AWS аккаунтов на одну почту

Обычно очень неудобно плодить ящики.

Например, (не)вы (не)удачно закоммитили креды в публичный репозиторий и уже заметили, что кто-то поменял пароль — вы решили быстро удалить (закрыть) AWS аккаунт (будем считать, что он был чисто тестовый), то есть по сути "пересоздать" (закрытие аккаунта - самый быстрый/лучший способ "удалить всё"). Однако Амазон при регистрации нового аккаунт скажет, что почта уже используется.

Или вы захотели попробовать #multi_account_strategy, а для каждого аккаунта ведь нужна почта - снова плодить сущности? А как было бы удобно иметь все аккаунты такой организации на один ящик.

Выход есть. Возможно кто-то пропустил, но уже десять лет как можно добавлять плюсик в почту, получая разные почтовые адресы, при этом имея один ящик. Например, такое точно есть у Google или Яндекс.

Т.е. при регистрации нового аккаунта можно разработать свою схему, к примеру, вот такие варианты:

james.norrington+AWS_ID@gmail.com
james.norrington+123456789012@gmail.com
vasya73+dev_project@yandex.ru
vasya73+test_project@yandex.ru

Таким образом все письма будут приходить в один и тот же ваш ящик, однако для Амазона это будут разные (и он допускает плюсик в адресе).

#хитрости

⁠SSH туннелирование через SSM Sessions Manager

Куда

На виртуалке, куда мы хотим коннектиться должен быть установлен SSM агент. Правильные пацаны юзают Amazon Linux 2, где он стоит по умолчанию на новых версиях. Однако даже на только что поднятых из консоли виртуалках стоит не самая последняя версия (фу, Амазон), потому запускаем стандартный установочный однострочник:

sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm

Для неудачников на своих Убунтах и прочих некошерных линуксах - двигаем по ссылке первоисточника.

Присоединяем к виртуалке нужные #IAM права (было тут и тут), без которых она не имеет права зарегистрироваться в #SSM и вы не сможете использовать #Session_Manager для подключения к ней.

Для всех (т.е. 0.0.0.0/0 - обязательно) открываем порт 22 (укоряюще смотрит на всех безопасников Амазона).

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

Откуда

На виртуалке (компьютере), откуда будем коннектиться на подготовленную ранее виртуалку, требуется #aws_cli (само собой разумеется) и должен быть установлен Session Manager Plugin.

Правим файл SSH-конфига (который в домашнем каталоге ~/.ssh/config), добавляя для хостов, куда хотим коннектиться запуск ProxyCommand - см. официальную ссылку.

Всё, должно работать:

ssh -i /root/.ssh/ttt19 ec2-user@i-016de9a622dfd5430

(см. картинку)

===

#multi_account_strategy

Для случаев, если виртуалка, куда нужно коннектиться, находится в другом аккаунте, то используем описанную схему, т.е. добавляем в ProxyCommand нужный профиль.

Для примера, вот полная версия реального файла /root/.ssh/config:

# CodeCommit
Host git-codecommit.*.amazonaws.com
 User ADDAJA5W7IDY5CHX3YKK
 IdentityFile ~/.ssh/codecommit_devops-user

# SSH over Session Manager
host i-* mi-*
 ## single account
 #ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

 ## multi account (stage account)
 ProxyCommand sh -c "aws --profile=stage ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

#tutorial

⁠Доступ к бакету для всех аккаунтов организации

Бывает нужно быстро и просто расшарить какой-то бакет или его часть для всех, но не "для всех вообще", т.е. в интернете, а только "для своих всех".

В случае #multi_account_strategy данная задача преобразуется в "расшарить для всех аккаунтов организации". Для этого существует специальная опция PrincipalOrgID, которую и можно использовать:

{
 "Sid": "Full access to path /some-path for all of organization accounts",
 "Effect": "Allow",
 "Principal": {
   "AWS": "*"
 },
 "Action": "s3:*",
 "Resource": [
   "arn:aws:s3:::my-shared-bucket",
   "arn:aws:s3:::my-shared-bucket/some-path/*"
 ],
 "Condition": {
   "StringEquals": {
     "aws:PrincipalOrgID": "o-dtj1bor777"
   }
 }
}

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

#s3 #organization

IAM + OU Condition

IAM в рамках #multi_account_strategy тренда продолжает обрастать функционалом для #Organizations и теперь позволяет управлять доступом для OU (Organization Unit):

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgpaths

Например, для мультиаккаунтной схемы типа этой, можно сделать общий бакет для проекта Project1 и в него будут иметь доступ все dev-test-stg-prd аккаунты OU Project1:

{
 "Sid": "Full access for Project1 OU",
 "Effect": "Allow",
 "Principal": {
  "AWS": "*"
 },
 "Action": "s3:*",
 "Resource": [
  "arn:aws:s3:::project1-bucket",
  "arn:aws:s3:::project1-bucket/*"
 ],
 "Condition": {
  "ForAnyValue:StringLike": {
    "aws:PrincipalOrgPaths":["o-dtj1bor777/ou-d1n7-h8xzxidp*"]
  }
 }
}

#IAM #S3 #Organizations

​​100 EKS кластеров в одном регионе для тех, кто так и не освоил #multi_account_strategy:

https://aws.amazon.com/about-aws/whats-new/2019/11/amazon-eks-increases-limits-to-100-clusters-per-region/

#EKS

Мульти-аккаунт стратегия: плюсы, минусы, подводные камни

https://www.youtube.com/watch?v=Au1MGWiriGM

#multi_account_strategy #video

Главное на Амазоне за 2017-2018-2019 — AWS Organizations

От денег перейдём к организационной структуре. За это время с "верхнеуровневой" частью управления компанией на Амазоне поменялось ПОЛНОСТЬЮ ВСЁ — три года назад появился сервис AWS Organizations.

https://aws.amazon.com/organizations/

И если про AWS Organizations вы не слышали или если и слышали, то не особо вникали и не пользовались, то знайте — вы совсем не понимаете, как (теперь) работает AWS.

AWS Organizations — базовый элемент для обеспечения безопасности, современный проект вряд ли пройдёт аудит без использования Organizations, а при наличии каких-то Compliance требований вообще просто без шансов. Это опуская все моменты, которые AWS Organizations даёт по работе в увеличению эффективности работы - как на уровне управления командами и проектами, так и по части эффективного использования ресурсов и их оплаты.

Тут часто упоминались и будет упоминаться термин #Multi_Account_Strategy или просто "мульти-аккаунты", который есть немного жаргонное обозначение использования AWS Organizations. Кто не видел — можно посмотреть это видео по мультиаккаунтам.

Если всё равно не ясно, для чего AWS Organizations, то приведу следующую аналогию (для кого-то грубую и спорную). Относиться к использованию мультиаккаунтов (AWS Organizations) — это примерно как многие до сих пор относятся к докерам (правильней — контейнеризации вообще). Называя это "лишним уровнем абстракции", "потерей производительности" и "прочей ленью разработчиков, неспособных разобраться с зависимостями".

Неверующие в докер не заметили, как вся индустрия де-факто переходит/перешла на использование контейнеризации чуть меньше, чем везде. И если для поддержки старых проектов понятно, то для реализации новых, без контейнеризации — это изначально закладывать отставание от других и последующую переделку.

Аналогично и AWS Organizations, не используя мульти-аккаунт подход — вы остаёте. Безопасность, эффективность, управляемость, а точней, их отсутствие (что невозможно на сегодняшнем Амазоне без AWS Organizations) — радикально уменьшают шансы на успех вашего стартапа.

Переход на мульти-аккаунт схему требует времени, ресурсов, знаний. Равно как и, в своё время, требовал затрат переход на Docker, CI/CD, IaC, Kubernetes и другие современные подходы, которые на выходе дают большую гибкость, скорость, эффективность.

Итого по организации. Три года назад завезли совсем другой Амазон. Если вы этого не заметили — разберитесь и используйте AWS Organizations. Без него сейчас никак. Он теперь такой же базовый, как S3.

#главное #Organizations

​​Рекомендации AWS по мульти-аккаунтам:

https://aws.amazon.com/organizations/getting-started/best-practices/

#Organizations #best_practices #multi_account_strategy