⁠Минимальная схема не является рекомендованной, т.к. поднятие ресурсов в мастер-аккаунте не есть #best_practices. Согласно оным мастер-аккаунт должен быть пустым и страшно защищённым.

Правда пока сам Амазон не способствует такой реализации - отдельные сервисы (#CloudTrail, #Config, #SSO и др.) до сих пор завязаны некоторым своим функционалом на использование именно мастера. В результате для соблюдения архитектурной чистоты приходится плодить костыли и с нетерпением ждать, когда же эти косяки будут исправлены.

Однако делать нужно правильно, несмотря на некоторые текущие моменты. Как минимум знать и стремиться.

Здесь и далее всё будет подразумевать использование AWS #Organizations, что и есть реализация #multi_account_strategy.

===
Рекомендуемая схема
===

В рекомендуемой схеме мастер аккаунт пустой (с поправкой на то, что пока ещё требует запуска в нём) - как минимум, никакие виртуалки в нём точно не запускаем, а наш #devops становится суб-аккаунтом и смещается по иерархии ниже.

Для различных функций, в том числе связанных со всей организацией, некоторая часть мух из предыдущей "мухо-котлетной" схемы выделяются в отдельный аккаунт с расплывчатым названием Secure. Туда переезжают ключи шифрования, домены (только регистрации, а не Hosted zones), бэкапы, #CloudTrail-логи и прочие сущности с особой важностью для организации в целом.

Современные фичи Амазона изменяют некоторые архитектурные элементы.

• Bastion выбрасываем - появление #SSM #Session_Manager закрывает его функционал.

• Для #VPC_peering используем #Transit_Gateway.

• В Devops-аккаунте добаляется #Shared_VPC, которая используется для окружений без жёстких требований по безопасности (условно dev-test), хотя, в принципе, можно и для всех окружений.

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

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

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

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

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

Мало кто задумывается, что не все сервисы Амазона имеют #SLA. В частности, его нет у #CloudFormation, так что все ваши претензии, что он "тупит", "тормозит", "зачтомыбабкиплатим" и "вытамсовсемохренели" - можно смело слать в девнулл.

Полный список AWS сервисов с SLA можно глянуть по ссылке:

https://aws.amazon.com/legal/service-level-agreements/

Однако в ходе решения каких-то вопросов (например, по теме #compliance) может потребоваться более детальная информация.

Допустим, у вас активно используется #CloudTrail и #Config и требуется знать, какие сервисы он покрывает (или наоборот). Или ваш проект секретно секретный и нужно максимально использовать те сервисы, что имеют at-rest-encryption.

Для этого вам поможет следующая ссылка:

https://summitroute.github.io/aws_research/service_support.html

#info

​​Набор примеров Athena-запросов для CloudTrail по теме Incident Response:

https://github.com/easttimor/aws-incident-response

#Athena #CloudTrail #security