Модуль 8.2: Просунуті хмарні мережі та транзитні хаби

Складність: [COMPLEX] | Час на виконання: 3 год | Передумови: Мульти-акаунт архітектура (Модуль 8.1), основи VPC/VNet та CIDR

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

Листопад 2020 року. Велика європейська компанія напередодні Чорної п’ятниці.

Їхня мережева команда побудувала топологію hub-and-spoke за допомогою VPC Peering — 23 робочі мережі (VPC) були з’єднані з центральним хабом. Все працювало, доки за три тижні до розпродажу не знадобилося підключити нову аналітичну мережу. З’ясувалося, що вони вперлися в ліміти VPC Peering: не через кількість з’єднань, а через розмір таблиць маршрутизації. Додавання всього одного з’єднання вимагало повної перебудови маршрутів для 16 продуктових VPC.

Міграція на AWS Transit Gateway тривала 11 днів у самий пік святкового трафіку. Генеральний директор особисто скасував заборону на зміни в інфраструктурі, бо іншого виходу не було. Компанія вижила, але 14 хвилин нестабільності під час міграції коштували мільйони в недоотриманому доході.

Урок не в тому, щоб “завжди використовувати Transit Gateway” (хоча зазвичай це так). Урок у тому, що рішення щодо мережевої топології, прийняті на старті, стають фундаментом, який надзвичайно дорого і боляче міняти пізніше. Цей модуль навчить вас обирати правильну топологію з першого дня, ви дізнаєтеся, як три великі хмари реалізують транзитні мережі, та як вирішувати проблеми масштабу: накладання IP-адрес (overlapping CIDRs) та оптимізацію витрат на трафік.

Патерни мережевих топологій

Кожна корпоративна хмара потребує плану зв’язку між мережами (VPC/VNet), офісом та інтернетом. Є три основні патерни:

1. Full Mesh (VPC Peering)

Кожна мережа з’єднана з кожною іншою напряму.

Плюси: Мінімальна затримка, немає плати за обробку даних (в AWS).
Мінуси: Складність росте експоненціально (N*(N-1)/2 з’єднань). Немає транзитивності (А бачить Б, Б бачить В, але А НЕ бачить В).
Коли використовувати: До 10 мереж, прості вимоги.

2. Hub-and-Spoke (Transit Gateway / Virtual WAN)

Центральний “хаб” (віртуальний роутер) з’єднує всі мережі.

Плюси: Лінійне масштабування (одне з’єднання на мережу). Єдина точка контролю безпеки та виходу в інтернет. Повна транзитивність.
Мінуси: Додаткова плата за кожен ГБ трафіку ($0.02/ГБ).
Коли використовувати: 10+ мереж, складні корпоративні правила, гібридна хмара.

3. Hybrid (Hub + Direct Peering)

Ви використовуєте хаб для загального зв’язку, але з’єднуєте найбільш “балакучі” мережі (напр. додаток та базу даних) напряму через піринг, щоб зекономити на трафіку.

Реалізація в різних хмарах

AWS Transit Gateway (TGW)

Це хмарний роутер. Головна перевага — Route Table Segmentation. Ви можете мати різні таблиці маршрутів для Prod та Dev, щоб вони фізично не могли надіслати пакет один одному, навіть через спільний хаб.

GCP Shared VPC та NCC

Google Cloud працює інакше. Замість з’єднання багатьох VPC, ви зазвичай створюєте одну велику Shared VPC і ділите її підмережі між проєктами. Network Connectivity Center (NCC) використовується переважно для зв’язку з офісом та іншими хмарами.

Azure Virtual WAN

Це повністю керований хаб, який автоматично з’єднує всі ваші регіони в єдину глобальну мережу. Ідеально, якщо у вас кластери AKS розкидані по всій планеті.

Проблема накладання IP (Overlapping CIDRs)

Це найпоширеніша помилка. Дві команди незалежно обрали 10.0.0.0/16. Ви не зможете з’єднати ці мережі, поки одна з них не переїде на нові адреси. Рішення: Централізований IPAM (IP Address Manager). Тільки одна команда видає діапазони адрес для всієї компанії.

Оптимізація витрат: NAT та Cross-AZ

Вихідний трафік (Egress) — це найдорожча частина хмари.

Централізований NAT: Замість 20 шлюзів NAT у кожній мережі, поставте 2 великих у центральній мережі. Це заощаджує тисячі доларів на абонплаті.
Cross-AZ трафік: В AWS трафік між зонами доступності (AZ) платний ($0.01/ГБ). Якщо ваш Kubernetes розкиданий по зонах, ви платите за кожен запит між мікросервісами. Вихід: Використовуйте Topology-aware routing у Kubernetes, щоб поди шукали “сусідів” у тій же самій зоні.

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

Помилка	Чому це стається	Як виправити
Піринг замість TGW	”Нам поки вистачає трьох”	Переходьте на TGW, як тільки бачите, що мереж стає більше п’яти
Однакові IP адреси	Відсутність координації	Створіть глобальну карту IP-адрес для всієї організації
Відсутність фільтрації	”Ми довіряємо своїм подам”	Використовуйте центральний Cloud Firewall на виході в інтернет
Ігнорування ціни TGW	Сприйняття як “безкоштовного роутера”	Пам’ятайте про $0.02 за кожен ГБ. Використовуйте Endpoints для сервісів AWS

Тест

1. Чому AWS Transit Gateway вважається кращим за VPC Peering для великих компаній?

Тому що він дозволяє будувати транзитивні мережі (A->TGW->B) та централізовано керувати безпекою. Замість сотень окремих з’єднань ви керуєте одним хабом і кількома таблицями маршрутизації.

2. Як заощадити гроші на трафіку до S3 всередині корпоративної мережі?

Використовуйте Gateway VPC Endpoints. Вони безкоштовні і направляють трафік до S3 напряму через внутрішню мережу AWS, минаючи як Transit Gateway, так і NAT Gateway.

Практична вправа: Дизайн транзитної мережі

Розрахуйте бюджет на трафік: скільки коштуватиме передача 100 ТБ даних на місяць через Transit Gateway?
Спроектуйте схему hub-and-spoke для трьох регіонів: США, Європа, Азія.
Напишіть правило, яке забороняє трафік з мережі dev-vpc у мережу prod-vpc на рівні Transit Gateway.

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

Ви побудували хмарні магістралі, тепер час навчити поди Kubernetes спілкуватися між регіонами. Переходьте до Модуля 8.3: Мережева взаємодія між кластерами та регіонами — ми вивчимо Cilium ClusterMesh та Multi-Cluster Services (MCS).