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

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

#best_practices #multi_account_strategy #Organizations

​​SCP и мастер (root) AWS-аккаунт

Стоит помнить, что "всемогущие" политики SCP, которые так удобно можно применять ко всей организации — не применяются к юзерам и ролям мастер аккаунта (root-аккаунта):

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

Потому, если, например, думаете, включать или не включать CloudTrail в регионах, что планируете запретить через SCP — однозначно стоит включать. Уже лишь как раз по причине того, что в мастере SCP не сработает, а две защиты лучше, чем одна (в подаккаунтах).

#SCP #Organizations

Советы по работе с AWS Organizations от производителя:

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html

Рекомендации для мастер-аккаунта и для подаккаунтов.
Основные:
▪️ не используйте публичные почтовые сервисы (бо̀льшая вероятность взлома)
▪️ обязательно включайте MFA
▪️ блокируйте root-юзеров в подаккаунтах с помощью SCP
▪️ периодически проверяйте процесс восстановления доступа к аккаунту (чтобы проверить, что всё нужное для этого есть у нужных людей)
▪️ создайте/обновляйте документацию по процессу восстановления доступа

#best_practices #Organizations

Master-аккаунт #Organizations переименовали в Management-аккаунт.

https://docs.aws.amazon.com/organizations/latest/userguide/document-history.html

Как несложно догадаться — в рамках борьбы с master ветками и прочими нетолерантными терминами.

===

В связи с этим интересно узнать, что вы думаете по этому поводу.

Стоит избавляться от подобных названий?
(master → main или как в данном случае master → management)

#опрос

​​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

Простая и действенная Лямбда для того, чтобы получать отчёт по биллиннгу по аккаунтам в Organizations, где можно увидеть номера аккаунтов и их тэги:

https://aws.amazon.com/blogs/aws-cost-management/cost-reporting-based-on-aws-organizations-account-id-tags/

Добавляем тэги на аккаунты (EDIT TAGS на AWS аккаунте в консоли Organizations) и после с помощью Лямбды, которую можно легко задеплоить из готового CloudFormation шаблона по ссылке из статьи выше, получаем в бакет csv файл со списком аккаунтов, их почтами, тэгами и расходами.

В общем, не стоит пытаться засунуть в название аккаунта всевозможные его характеристики лишь для того, чтобы после видеть в биллинге разбиение исходя из такого примитивного подхода – ведь для этого есть и правильно использовать тэги.

#Organizations

Рекомендации по мульти-аккаунт стратегии от первоисточника:

https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html

Целый раздел документации по лучшим практикам в организации #Organizations организации. 😄

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

#multi_account_strategy

​​В новых иконках от AWS добавили AWS Account:

https://aws.amazon.com/architecture/icons/

#Organizations #design

Серьёзные подвижки для работы в мульти-аккаунт окружении — возможность программно изменять почту для billing/operations/security в под-аккаунтах:

https://aws.amazon.com/blogs/mt/programmatically-managing-alternate-contacts-on-member-accounts-with-aws-organizations/

По умолчанию все сообщения по поводу AWS аккаунта — биллинг, проблемы безопасности (например, вас поломали и/или ваши виртуалки рассылают спам) — шлются на почту root-юзера. Однако можно задать альтернативные контакты - отдельные почты для billing/operations/security.

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

Теперь же можно запустить баш-скрипт (в AWS огромное Bash-лобби 😁) из статьи и назначить всем подаккаунтам нужные почты (или одну на всех). Что реально круто. Обязательно воспользуйтесь!

#Organizations #security #multi_account_strategy

​​DevOps Guru для всей организации:

https://aws.amazon.com/ru/about-aws/whats-new/2021/11/amazon-devops-guru-multi-account-insight-aws-organizations/

Теперь можно выдать в девопс-аккаунте права для работы DevOps Guru со всей организацией (Delegated Administrator). С учётом того, что DevOps Guru стал поддерживать ещё больше EKS Insights метрик, то получается солидный инструмент.

Не вместо девопса, понятно – это больше для броского словца, но весьма полезный инструмент для девопса. Может быть дорогой, но хипстерский крутой и полезный. 😀

#DevOpsGuru #Organizations #devops

Закрытие AWS account через AWS SDK & AWS CLI:

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_close.html#aws-cli-&-aws-sdks

aws organizations close-account --account-id 123456789012

Не прошло и пять лет. Ан нет, прошло.

Нужно учитывать следующие особенности закрытия (на самом деле сначала приостановки - SUSPENDED) AWS аккаунтов в Organizations:

▫️ Закрыть можно любой аккаунт (member account, иногда называются как sub-account) кроме главного (management account, ранее master account).
▫️ Пока команда выполнения закрытия аккаунта находится в процессе (обычно несколько минут), аккаунт будет в состоянии PENDING_CLOSURE. По её отработке он переходит в состояние SUSPENDED, в котором будет висеть ещё три месяца, прежде, чем окончательно удалится.
▫️ Закрыть сразу все аккаунты не получится. Можно закрыть лишь 10% от общего количества в течение месяца.
▫️ Случайно закрытый нужный аккаунт можно восстановить в течение 90 дней через Support (пока аккаунт находится в состоянии SUSPENDED).

Подробности API для Organizations - CloseAccount:

https://docs.aws.amazon.com/organizations/latest/APIReference/API_CloseAccount.html

Особенности закрытия аккаунтов для AWS GovCloud (US):

https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/Closing-govcloud-account.html

⚠️ На момент публикации документация на команду AWS CLI close-account пока ещё не доступна.

#Organizations