⁠Минимальная схема не является рекомендованной, т.к. поднятие ресурсов в мастер-аккаунте не есть #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).

Мало кто задумывается, что не все сервисы Амазона имеют #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

Использование AWS Config + SSM для автоматизации закрытия открытых портов (например, для соблюдения compliance требований):

https://aws.amazon.com/blogs/security/how-to-auto-remediate-internet-accessible-ports-with-aws-config-and-aws-system-manager/

#Config #SSM #security #compliance

Запрет публичного SSH-доступа с помощью AWS Config:

https://github.com/adhorn/ssh-restricted

#Config

🆕 AWS Config + daily recording

https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html#select-resources-recording-frequency

Наконец-то решение для аккаунтов с автоскелингом и с прочими постоянно изменяющимися сущностями. А также отлично подойдёт для личных аккаунтов, чтобы было дешевле.

Хотя с последним есть вопросы, т.к. стоимость периодических в 4 раза выше:

Continuous Recording $0.003
Periodic Recording $0.012

▪️ Periodic recording delivers configuration data once every 24 hours, only if a change has occurred, which may be useful for use cases such as operational planning or audit.
▪️ Continuous recording delivers configuration items whenever a change occurs. It helps you meet security and compliance requirements to track all configuration changes.

#Config