Модуль 8.1: Мульти-акаунт архітектура та дизайн оргструктури

Складність: [COMPLEX] | Час на виконання: 2.5 год | Передумови: Архітектурні патерни хмар, знайомство хоча б з одним гіперскейлером (AWS, GCP або Azure)

Чому цей модуль важливий

Березень 2019 року. Середня фінтех-компанія. 42 інженери. Один акаунт AWS.

Усе жило разом: продуктові бази даних, тестові середовища, конвеєри CI/CD, пісочниці розробників та спільні сервіси. Одного п’ятничного дня молодший розробник, запускаючи навантажувальні тести в тому, що він вважав тестовим середовищем, випадково перевантажив NAT Gateway, від якого також залежав продуктовий трафік. Обробка платежів зупинилася на 93 хвилини. Інцидент коштував $2.1 мільйона у вигляді невдалих транзакцій та спричинив аудит PCI-DSS, який забрав два місяці інженерного часу.

Першопричиною був не навантажувальний тест. Це була архітектура — точніше, її відсутність. Коли все живе в одному акаунті, немає меж радіусу ураження. Політики IAM стають неймовірно складними. Визначення витрат перетворюється на вгадування. Логи аудиту — це заплутане мереживо продуктової та тестової активності. І одна помилка в будь-якому середовищі може каскадом поширитися на всі інші.

Цей модуль навчить вас проєктувати мульти-акаунт архітектури в AWS, GCP та Azure. Ви навчитеся будувати організаційні ієрархії, які забезпечують ізоляцію за замовчуванням, централізувати те, що має бути спільним (логи, безпека, мережі), і тримати те, що має бути окремим, справді окремим. Що ще важливіше, ви зрозумієте, як ці рішення безпосередньо впливають на ваші кластери Kubernetes — де вони живуть, як спілкуються і хто контролює їхній життєвий цикл.

Пастка одного акаунта

Перш ніж проєктувати мульти-акаунт архітектури, давайте зрозуміємо, чому команди опиняються в хаосі одного акаунта. Сценарій завжди однаковий:

Починаємо проєкт. Створюємо один акаунт. Деплоїмо все.
Команда росте. Додаємо більше навантажень. Все ще один акаунт.
Потрібен staging. Створюємо неймспейс або тег. Все ще один акаунт.
Потрібен комплаєнс. Розуміємо, що політики IAM — це спагеті. Паніка.

Модель одного акаунта працює для соло-розробника. Вона перестає працювати в той момент, коли вам потрібні: ізоляція середовищ, видимість витрат, межі комплаєнсу або автономія команд.

Організаційні ієрархії в різних хмарах

Кожен гіперскейлер надає ієрархію для організації акаунтів. Термінологія різна, але концепція однакова: вкладати акаунти в групи, які успадковують політики зверху вниз.

Порівняння організаційних структур

AWS (Organizations)	GCP (Resource Manager)	Azure (Management Groups)
Organization	Organization	Tenant (Entra ID)
Root OU	Folder	Management Group
OU	Sub-Folder	Sub-Management Group
Account	Project	Subscription

Механізм політик:

AWS: Service Control Policies (SCPs) — тільки заборона.
GCP: Organization Policies — обмеження конфігурацій.
Azure: Azure Policy — заборона та аудит.

Проєктування структури OU (Organizational Units)

Структура OU — це скелет вашої хмарної архітектури. Зробите помилку тут — і будете боротися з нею роками. Зробите правильно — і вона стане невидимим фундаментом безпеки.

Централізоване логування та аудит

У мульти-акаунт світі логування стає складнішим, але й важливішим. Вам потрібне “єдине вікно” для подій безпеки.

Патерн незмінного архіву:

Усі акаунти надсилають логи (CloudTrail, VPC Flow Logs, EKS Audit) в один захищений бакет у Security Account.
Цей бакет має Object Lock: навіть адміністратор (root) не може видалити логи протягом встановленого терміну (напр. 1 рік).
Це гарантує, що якщо зловмисник зламає робочий акаунт і спробує замести сліди, оригінальні логи залишаться в безпеці.

Типові помилки

Помилка	Чому це стається	Як виправити
OU за командами, а не середовищами	Здається логічним для власності	Діліть за середовищами (Prod/Dev), щоб SCP були однаковими для всіх команд у цьому середовищі
Робота в Management (Payer) акаунті	”Це ж перший акаунт, що був”	Management акаунт має бути порожнім. Тільки білінг та управління організацією. Жодних подів!
Спільні VPC між Prod та Dev	Спроба зекономити на NAT Gateway	Ізолюйте мережі повністю. Економія $30 не варта ризику збою продукту через тест
Ручне створення акаунтів	”Нам треба лише три”	Автоматизуйте через Terraform або Account Factory. Стабільність налаштувань важливіша за час створення

Тест

1. Чому Management (Payer) акаунт в AWS не підпадає під дію SCP?

Це архітектурне обмеження AWS. Оскільки цей акаунт є джерелом усіх політик, він має мати повний доступ, щоб не “заблокувати самого себе”. Саме тому в ньому не можна запускати жодні робочі навантаження — будь-яка помилка там не буде зупинена вашими guardrails.

2. У чому різниця між AWS SCP та політиками IAM?

IAM каже, що користувач МОЖЕ робити. SCP каже, що в цьому акаунті МОЖНА робити в принципі. Навіть якщо IAM дає права адміністратора, але SCP забороняє видаляти логи — видалити логи буде неможливо. SCP — це фільтр, через який проходять усі запити IAM.

Практична вправа: Дизайн організації

Спроектуйте ієрархію для компанії з трьома відділами: FinTech, Retail, Data Science.
Визначте, де будуть жити центральні бази даних, до яких мають доступ усі.
Напишіть SCP, яка забороняє створювати будь-які ресурси за межами регіону eu-central-1 (Франкфурт) для всіх акаунтів, крім команди Data Science.

Наступний модуль

Ви розділили акаунти, тепер час їх з’єднати. Переходьте до Модуля 8.2: Просунуті хмарні мережі та транзитні хаби — ми навчимося будувати топології hub-and-spoke та керувати трафіком між десятками мереж без хаосу.