⁠#single_account vs #multi_account_strategy

Споры о преимуществах той или иной стратегии ("всё/все в одном" или #мультиаккаунт) бессмысленны. Не буду хохмить про то, что они очень часто ведутся между теми, кто уже давно ест апельсины и теми, кто никогда их не пробовал, но не одобряет. Если максимально коротко - у каждого способа есть набор очевидных и неочевидных плюсов и минусов, однако #multi_account_strategy — суть современный способ работы современного проекта, а потому ориентироваться нужно именно на него.

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

===
Минимальная схема
===

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

По принципу разбиения схему можно назвать "мухи и котлеты". Всё, что не относится к поднимаемым окружениям - это условный Devops аккаунт. Окружения dev-stg-prod (test, etc) поднимаются единым образом, т.е. условно из одного шаблона и лишь с разными настройками.

Окружения живут в своих VPC и соединяются с Management VPC с помощью VPC peering. Доступ к закрытым ресурсам (без внешних айпишников) происходит через промежуточный Bastion инстанс.

Всё необходимое для поднятия окружений, различные ресурсы и настройки - всё лежит в Devops аккаунте, куда может иметь доступ лишь девопс, а разработчики ходят в dev-окружение и им выделяется доступ (временно, для деплоя) в stage-prod-etc.

Это (относительно) просто в реализации и поддержке, схема удовлетворяет требованиям различных #compliance (например, #NIST) и наверняка подойдёт для многих проектов, особенно тех, кто хочет начать использовать мультиаккаунты.

В пандан к предыдущему посту - заслуживающая внимания утилита для вычисления минимально нужных #IAM привилегий посредством сравнения имеющихся политик у юзера/роли и тех, что реально запрашиваются через AWS API (определяется с помощью #CloudTrail логов).

Может особенно может быть полезной для адептов #single_account, где такое весьма актуально в каждодневной борьбе с желающими урвать себе прав и побольше.

С помощью утилиты CloudTracker можно чётко контролировать используемое: кто не оценил вашу доброту - отобрать лишнее, а всем остальным выдавать доступ строго по талонам.

https://github.com/duo-labs/cloudtracker

​​BLEA (Baseline Environment on AWS) или японский мульти-аккаунт:

https://github.com/aws-samples/baseline-environment-on-aws

Полностью разворачивается с помощью AWS CDK, одинаково работает и с Single Account и в Multi Account среде. То есть ставится и на просто один аккаунт, и на Organizations, и на Organizations с Control Tower.

Выглядит очень круто. Гугло-перевод статьи про BLEA из японского AWS блога:

https://aws-amazon-com.translate.goog/jp/blogs/news/announcing-baseline-environment-on-aws/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=be&_x_tr_pto=nui

Картинки и набор сервисов впечатляют, особенно с учётом того, что благодаря использованию CDK, функционал может расширяться очень быстро.

Однозначно стоит ознакомиться поближе и наверняка увидим подробности на re:Invent.

#CDK #multi_account_strategy #single_account_strategy #security