Модуль 10.1: Корпоративні Landing Zones та Vending акаунтів

Складність: [COMPLEX] | Час на виконання: 3 год | Передумови: Основи хмар (AWS/Azure/GCP), Основи Kubernetes, Архітектурні патерни хмар

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

У березні 2023 року велика страхова компанія зі списку Fortune 500 готувалася до запуску нової платформи обробки страхових випадків на базі Kubernetes. Команда розробки будувала її дев’ять місяців. Коли вони попросили продуктовий акаунт AWS, хмарна команда відповіла, що час очікування — чотирнадцять тижнів. Причина: кожен акаунт налаштовувався вручну. Старший архітектор мав створити VPC, налаштувати підключення до Transit Gateway, створити IAM-ролі, налаштувати логування та реєстрацію в CMDB. Він обробляв три акаунти на тиждень, а в черзі було двадцять дві команди.

Платформа пропустила вікно запуску. Конкурент випустив аналогічний продукт раніше. Компанія оцінила збитки від затримки у $8.6 мільйона. Проблема була не в хмарних технологіях. Проблема була в тому, що організація ставилася до створення акаунтів як до ручної ремісничої роботи, а не як до автоматизованої фабрики.

Enterprise Landing Zones вирішують саме цю проблему. Це архітектурний фундамент, який визначає, як організація використовує хмару в масштабі: структура акаунтів, мережева топологія, поручні безпеки (guardrails) та автоматизація, яка створює все це за хвилини замість тижнів. Коли з’являється Kubernetes, Landing Zones стають ще важливішими: кожному кластеру потрібні мережа, ідентичність та логування з першої секунди життя.

У цьому модулі ви вивчите, як працюють AWS Control Tower, Azure Landing Zones та GCP Organization Hierarchy. Ви навчитеся автоматизувати створення акаунтів (Account Vending) разом із базовим налаштуванням Kubernetes, щоб команди могли проходити шлях від “мені потрібен кластер” до “у мене є готовий до продакшну кластер” менш ніж за тридцять хвилин.

Ментальна модель Landing Zone

Landing Zone — це як будівельні норми міста. Перш ніж хтось почне будувати будинок, місто вже визначило зони забудови, підключення до каналізації та електрики, протипожежні норми та процес отримання дозволів. Landing Zone робить те саме для хмарної інфраструктури.

Чотири стовпи:

Identity & Access: Хто і що може робити в усіх акаунтах. Єдиний вхід (SSO) та федерація ідентичності, що безшовно переходять із хмарного IAM у Kubernetes RBAC.
Network Topology: Як акаунти з’єднуються між собою, з офісом та інтернетом. Кожен кластер Kubernetes має отримувати мережу, яка вже інтегрована в цю топологію.
Security & Compliance: Поручні (guardrails), які заважають командам робити небезпечні речі, але дозволяють рухатися швидко в усьому іншому.
Account Vending: Автоматизація (“автомат з продажу”), яка видає нові акаунти (підписки чи проєкти) з уже налаштованими першими трьома стовпами.

AWS Control Tower та Account Factory

Control Tower — це рішення від AWS для створення багатоакаунтного середовища з автоматичними поручнями безпеки (guardrails).

Типова структура:

Security OU: акаунти для архівів логів та аудиту.
Infrastructure OU: центральні мережеві хаби та спільні сервіси.
Workloads OU: окремі папки для Production та Dev акаунтів.

Account Factory for Terraform (AFT) дозволяє реалізувати GitOps-підхід: ви додаєте назву нового акаунта в файл Terraform, робите git push, і система сама створює акаунт, VPC, кластер EKS та реєструє його в моніторингу.

Azure Landing Zones та Subscription Vending

Azure використовує Management Groups для групування підписок.

Platform: управління, ідентичність, мережа (Hub).
Landing Zones: підписки для додатків (Spoke), розділені на Corp (приватні) та Online (публічні).

Завдяки глибокій інтеграції, групи з Azure AD (Entra ID) можуть автоматично ставати адмінами в кластерах AKS без додаткових налаштувань всередині Kubernetes.

Поручні безпеки: Preventive vs Detective

Landing Zone без поручнів — це організований хаос.

Preventive (Запобіжні): Фізично забороняють дію. (напр. SCP в AWS, яка не дає створити бакет S3 без шифрування).
Detective (Детективні): Дозволяють дію, але миттєво піднімають тривогу. (напр. Azure Policy, яка помічає, що в кластері з’явився привілейований контейнер).

Backstage: Єдине вікно для розробника

Професійні Landing Zones використовують Backstage (портал від Spotify) як інтерфейс. Розробник не заходить у консоль AWS. Він заходить у Backstage, обирає шаблон “Новий мікросервіс”, вводить назву — і за лаштунками запускається весь конвеєр Landing Zone, який створює акаунт, кластер та репозиторій.

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

Помилка	Чому це стається	Як виправити
Один гігантський акаунт	Здається простішим на початку	Починайте з мульти-акаунт архітектури з першого дня
LZ без урахування K8s	Мережева команда не спілкується з K8s командою	Включайте вимоги до IP-адрес подів у дизайн мережі Landing Zone
Ручне створення акаунтів	”Ми створюємо їх рідко”	Навіть один акаунт на місяць має бути автоматизований для стабільності налаштувань
Занадто суворі правила	Безпека без консультацій з розробниками	Розробляйте правила разом. Спочатку вмикайте режим аудиту, потім — заборони

Тест

1. Чому для корпоративного Kubernetes важливо мати окремі акаунти для кожної команди?

Це обмежує радіус ураження (blast radius). Якщо команда А випадково видалить усі ресурси або вичерпає ліміти (quotas), команди Б та В цього навіть не помітять. Також це набагато спрощує білінг: ви точно знаєте, скільки грошей витратив конкретний проєкт.

2. У чому різниця між "воротами" (gates) та "поручнями" (guardrails)?

“Ворота” вимагають ручного схвалення (це повільно і створює черги). “Поручні” працюють автоматично: вони дозволяють усе, що не заборонено, і миттєво блокують тільки небезпечні дії. Поручні дозволяють масштабувати компанію без збільшення штату адмінів.

Практична вправа: Дизайн Landing Zone

Спроектуйте ієрархію для компанії з трьома департаментами: Banking, Insurance, Retail.
Визначте, де будуть зберігатися логи з усіх кластерів.
Напишіть список із трьох запобіжних правил (preventive guardrails), які мають бути активні для всіх команд без винятку.

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

Ви заклали фундамент, тепер час розібратися з політиками глибше. Переходьте до Модуля 10.2: Хмарне управління та Політика як код — ми навчимося поєднувати SCP та Azure Policy з внутрішніми правилами Kubernetes (Kyverno/OPA).