⁠Тэги для 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

Современные способы создания сетевой инфраструктуры AWS:

https://d1.awsstatic.com/whitepapers/building-a-scalable-and-secure-multi-vpc-aws-network-infrastructure.pdf

От VPC Peering и Transit VPC к Transit Gateway и Shared VPC. А также PrivateLink, Direct Connect и другие Networking возможности AWS, в том числе с учётом #multi_account_strategy.

#networking #best_practices

​​Использование Control Tower для управления организацией в мульти-аккаунт схеме:

https://aws.amazon.com/blogs/apn/reducing-the-cost-of-managing-multiple-aws-accounts-using-aws-control-tower/

Расписаны отличия Control Tower от AWS Landing Zone и что в нём было урезано в последней версии для упрощения развёртывания.

#ControlTower #multi_account_strategy

Когда у вас больше, чем один Transit Gateway (TGW) и постоянно растущее кол-во VPC, то подключение очередной в общую сеть становится весьма непростой задачей.

Это (подключение TGW аттачментов вместе с настройкой route tables для TGW) можно автоматизировать, чтобы было досточно добавить тэг к VPC, а Лямбды уже подхватят и сделают нужное за вас.

Называется эта штука STNO (Serverless Transit Network Orchestrator solution) :

https://aws.amazon.com/blogs/mt/serverless-transit-network-orchestrator-stno-in-control-tower/

Актуально для тех, кто работает с TGW и имеет распределённую по многим аккаунтам инфраструктуру, которую нужно связывать в единую сеть.

Детали по работе STNO есть в великолепном видео по работе TGW:

https://www.youtube.com/watch?v=9Nikqn_02Oc

#TransitGateway #multi_account_strategy

Лучшие практики использования OU (Organizational Units) в мульти-аккаунтах:

https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/

#best_practices #multi_account_strategy #Organizations

Утилита для работы в мульти-аккаунтной среде от Netflix:

https://github.com/Netflix/consoleme

#multi_account_strategy

​​Superwerker

Кто про что, а в̶ш̶и̶в̶ы̶й̶ ̶п̶р̶о̶ ̶б̶а̶н̶ю̶ я про AWS Organizations. Которой в этом году исполнится пять лет. И, значит, уже пятый год мы живём без гуманной процедуры удаления аккаунта, без временных аккаунтов.

За это время использование #multi_account_strategy стало обязательной практикой, в помощь чему появился сервис Control Tower, который в прошлом году обзавёлся возможностью работать в том числе и в существующей организации.

Однако порог входа для начала работы с лучшими практиками, которые даёт Organizations, пока по-прежнему высок. В попытке его снизить, намедни появился новый open source инструмент – superwerker:

https://github.com/superwerker/superwerker

Хороший набор #security #best_practices, правда, хороший – самое основное, что нужно иметь. Идеи по управлению аккаунтами в том числе позаимстованы из AWS Account Controller от Ian Mckay. Модный event-driven подход, (практически) бесплатные Лямбды.

Если бы хотел начать – точно бы обратил внимание. Заявленные фичи действительно самые нужные-востребованные:

▪️ Control Tower
▪️ AWS SSO
▪️ GuardDuty+dashboards
▪️ Security Hub+dashboards
▪️ AWS Backup
▪️ AWS Budgets
▪️ SCP guardrails
▪️ SSM+OpsCenter
▪️ CloudWatch dashboard

То, что (в первой версии) нет сетевой части, по мне так это и к лучшему. Система расширяемая и новые фичи вскоре наверняка будут с излишком.

Установка Superwerker официально доступна в качестве AWS Quick Start:

https://aws.amazon.com/quickstart/architecture/superwerker/

Хорошая штука, в общем. Можно рекомендовать.

#Organizations

AWS User Group Netherlands Meetup 2021.05.20 по теме Landing Zones:

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

4:00 Why do you need a "Landing Zone"?
27:30 «Superwerker — open-source jump-start to a well-architected AWS setup»
58:00 «Managing your AWS Organization with org-formation»
1:32:20 «From ALZ to Control Tower: building a managed landing zone service at AWS»
2:07:00 «A hitchhikers guide to landing zones, using undocumented APIs»

Для тех, кто сильно связан с #multi_account_strategy этот митап суть просто концентрированный набор лучших (и разных) подходов к тому, чтобы управляться с мульти-аккаунтами.

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

Также отдельно стоит выделить доклад про Control Tower (плюс там много про Service Catalog) от Matt Yanhyshyn из AWS (General Manager of AWS Control Services). Качественный материал от первоисточника во всех смыслах, с инсайдом по фичам Control Tower в роадмэпе (например, поддержка Nested OU).

Реально круто, хотя, предположу, что не всем понятно. Всё равно, рекомендую. 😀

#Control_Tower