Говоря о фундаменте, будь то первичное проектирование (что бывает перед запуском проекта или миграцией) или повторное (как в моем случае), важно учитывать важность так называемого MultiAccount Strategy (MAS).

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

Идея разбивать структуру по определенным группам или OU далеко не нова и пришла к нам еще во времена зарождения LDAP, получив полноценное развитие в Active Directory.

Реализация MAS в AWS подразумевает то, что мы создаем иерархию OU, создаем необходимые аккаунты и прикрепляем их к OU.

На данный момент существует две основной модели внедрения MAS:
- По окружению (prod, test, staging, dev)
- По проектам/отделам (Project A, Project B, Sales, Marketing, etc)

Обе модели можно комбинировать. Например у нас может быть OU на каждый проект, а в нем будут аккаунты по окружениям.

Для чего используются разные аккаунты? В основном для двух целей: безопасность и биллинг. Так же можно «обходить» лимиты или наслаждаться халявой Free Tier.

По биллингу все просто - если у вас один аккаунт, то довольно сложно разобраться, какое приложение или проект «тратит» больше денег, и нужно анализировать это с помощью resource tags и resource groups, в то время как MAS предоставляет консолидированный биллинг, и можно посмотреть, какой аккаунт обходится вам во сколько денег.

Что касается безопасности, то MAS создает дополнительный барьер. Если вы по невнимательности дали права IAM пользователю ec2:*, то эти права будут распространяться только на конкретный аккаунт и не затронут «соседний».

Это только вводная информация по MAS, эта тема довольно большая и сложная в реализации, так что если у вас есть вопросы по различным use case’ам - вы знаете, куда писать.