Мережева інфраструктура є фундаментом будь-якого хмарного середовища. Незалежно від того, які обчислювальні ресурси і бази даних використовує організація, — всі вони з’єднані через мережу, і саме мережева конфігурація визначає, хто і як може отримати до них доступ, наскільки надійною та безпечною буде система.
Хмарні провайдери повністю абстрагують фізичну мережеву інфраструктуру, надаючи замість неї програмно-визначені мережі (Software-Defined Networking, SDN). Це надає бездоганну гнучкість: мережу можна конфігурувати через API або консоль, відтворювати кодом, масштабувати за секунди. Але саме тому розуміння хмарного мережевого стеку є критичною компетентністю: помилки у конфігурації мережі призводять або до недоступності сервісів, або до незахищеності даних.
VPC (Virtual Private Cloud) у AWS та VNet (Virtual Network) у Azure — це логічно ізольована мережа всередині хмарної інфраструктури провайдера, яку клієнт повністю контролює.
Аналогія: VPC — це як власний орендований офіс у великому бізнес-центрі (хмарі провайдера). Інші орендарі (клієнти AWS/Azure) — у цьому ж будинку, але перебувають за ізольованими стінами. Ви самі вирішуєте, які двері відчинити (дозволити трафік) і для кого.
Що надає VPC/VNet:
Кожен VPC/VNet визначається через CIDR-блок (Classless Inter-Domain Routing) — запис виду 10.0.0.0/16, де:
10.0.0.0 — базова IP-адреса мережі/16 — маска підмережі (16 фіксованих бітів → 2¹⁶ = 65 536 адрес)Типові CIDR-блоки для VPC:
| CIDR | Кількість IP-адрес | Типове застосування |
|---|---|---|
/16 |
65 536 | Великі корпоративні VPC |
/20 |
4 096 | Середні бізнес-середовища |
/24 |
256 | Маленькі проєкти або окремі підмережі |
/28 |
16 | Дуже маленькі підмережі (напр., для NAT) |
Рекомендації щодо вибору CIDR:
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16┌─────────────────────── AWS Region: eu-central-1 ────────────────────────┐
│ │
│ ┌──────────────────────────── VPC: 10.0.0.0/16 ───────────── ────────┐ │
│ │ │ │
│ │ ┌─── AZ: eu-central-1a ───┐ ┌─── AZ: eu-central-1b ───┐ │ │
│ │ │ │ │ │ │ │
│ │ │ Public Subnet │ │ Public Subnet │ │ │
│ │ │ 10.0.1.0/24 │ │ 10.0.2.0/24 │ │ │
│ │ │ [Web Server, NAT GW] │ │ [Web Server, NAT GW] │ │ │
│ │ │ │ │ │ │ │
│ │ │ Private Subnet │ │ Private Subnet │ │ │
│ │ │ 10.0.3.0/24 │ │ 10.0.4.0/24 │ │ │
│ │ │ [App Server, DB] │ │ [App Server, DB] │ │ │
│ │ └─────────────────────────┘ └─────────────────────────┘ │ │
│ │ │ │
│ │ Internet Gateway (IGW) VPN Gateway │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Azure VNet має схожу концепцію, але з деякими відмінностями:
Підмережа (Subnet) — це сегмент VPC/VNet з підмножиною IP-адрес. Підмережі дозволяють розділяти ресурси за рівнями безпеки та функціональністю.
Публічна підмережа (Public Subnet):
Приватна підмережа (Private Subnet):
Зонна прив’язка підмереж: Кожна підмережа прив’язана до конкретної Зони доступності (Availability Zone). Для відмовостійкості ресурси необхідно розміщувати у підмережах різних AZ.
Приклад трирівневої архітектури з підмережами:
| Рівень | Підмережа | CIDR | AZ |
|---|---|---|---|
| Публічний (Web) | public-subnet-1a | 10.0.1.0/24 | eu-central-1a |
| Публічний (Web) | public-subnet-1b | 10.0.2.0/24 | eu-central-1b |
| Приватний (App) | private-subnet-1a | 10.0.3.0/24 | eu-central-1a |
| Приватний (App) | private-subnet-1b | 10.0.4.0/24 | eu-central-1b |
| Ізольований (DB) | db-subnet-1a | 10.0.5.0/24 | eu-central-1a |
| Ізольований (DB) | db-subnet-1b | 10.0.6.0/24 | eu-central-1b |
Internet Gateway — ресурс AWS, що забезпечує двостороннє з’єднання між VPC та публічним Інтернетом. Властивості:
NAT Gateway дозволяє ресурсам у приватних підмережах ініціювати вихідне з’єднання до Інтернету (для завантаження оновлень, звернення до зовнішніх API), не дозволяючи Інтернету ініціювати вхідні з’єднання до цих ресурсів.
Розміщується у публічній підмережі та потребує Elastic IP-адреси.
Приватна підмережа Публічна підмережа
┌───────────────┐ ──────────► ┌─────────────┐ ──────────► Internet
│ App Server │ вихідний трафік│ NAT Gateway│ (пакети оновлень,
│ 10.0.3.10 │ │ 10.0.1.5 │ зовнішні API)
└───────────────┘ └─────────────┘
◄── відповіді ──────────────────────────────────
Таблиця маршрутизації — набір правил (маршрутів), що визначають, куди направляти мережевий трафік залежно від IP-адреси призначення.
Типова таблиця маршрутизації для публічної підмережі:
| Призначення | Цільовий об’єкт | Опис |
|---|---|---|
10.0.0.0/16 |
local | Трафік всередині VPC — локальний |
0.0.0.0/0 |
igw-xxxxxxxx | Весь інший трафік — через Internet Gateway |
Типова таблиця маршрутизації для приватної підмережі:
| Призначення | Цільовий об’єкт | Опис |
|---|---|---|
10.0.0.0/16 |
local | Трафік всередині VPC — локальний |
0.0.0.0/0 |
nat-xxxxxxxx | Весь інший трафік — через NAT Gateway |
VPC Peering — приватне мережеве з’єднання між двома VPC в одному або різних регіонах/акаунтах. Трафік не проходить через публічний Інтернет.
Обмеження: Пірінг транзитний — не підтримується. Якщо VPC-A з’єднаний з VPC-B, і VPC-B з VPC-C, то VPC-A і VPC-C все одно не мають прямого з’єднання.
Transit Gateway — вирішує проблему транзитності: центральний хаб, до якого підключаються всі VPC та on-premise мережі. Підтримує маршрутизацію між тисячами VPC.
VPC-A ─────┐
VPC-B ─────┤── Transit Gateway ──── On-Premise (VPN/Direct Connect)
VPC-C ─────┘
VPC-D ─────┘
AWS VPN (Site-to-Site VPN):
AWS Direct Connect / Azure ExpressRoute:
Приклад: Банк обробляє фінансові транзакції між on-premise системами та AWS. Для дотримання вимог LatencyLadder SLA та безпеки обирає AWS Direct Connect — 10 Гбіт/с виділений канал через партнера.
Балансувальник навантаження (Load Balancer, LB) — це компонент, що розподіляє вхідний мережевий трафік між кількома екземплярами серверів (або контейнерів), забезпечуючи:
┌───────────┐
Клієнт ────► │ Load │ ──────────────────► Server 1
(100 rps) │ Balancer │ ──── Round Robin ──► Server 2
└───────────┘ ──────────────────► Server 3
Application Load Balancer (ALB) — рівень 7 OSI (HTTP/HTTPS):
Приклад маршрутизації ALB:
api.example.com/users → Target Group: users-service (3 інстанси)
api.example.com/orders → Target Group: orders-service (5 інстансів)
api.example.com/static → Target Group: cdn-service
Network Load Balancer (NLB) — рівень 4 OSI (TCP/UDP):
Gateway Load Balancer (GWLB):
| Тип | AWS | Azure | GCP |
|---|---|---|---|
| HTTP(S) балансувальник | ALB | Application Gateway | Cloud Load Balancing (HTTP) |
| TCP/UDP балансувальник | NLB | Azure Load Balancer | Cloud Load Balancing (TCP) |
| Глобальний LB | Global Accelerator | Azure Front Door | Global Load Balancing |
| WAF | AWS WAF + ALB | Application Gateway WAF | Cloud Armor + LB |
| Алгоритм | Опис | Коли використовувати |
|---|---|---|
| Round Robin | По черзі до кожного сервера | Сервери однорідні, запити рівнозначні |
| Least Connections | До сервера з найменшою кількістю активних з’єднань | Тривалі сесії, нерівномірне навантаження |
| IP Hash | Хеш IP-адреси клієнта → завжди один сервер | Необхідна сесійна прив’язка (session stickiness) |
| Weighted Round Robin | Потужніші сервери отримують більше запитів | Різнорідні сервери |
LB регулярно надсилає перевірочні запити (health checks) до кожного сервера:
Load Balancer → GET /health → Server
← 200 OK ← (сервер healthy)
← timeout ← (сервер unhealthy → виключити з ротації)
Налаштування health check:
/health, /status, /ping (для HTTP)AWS надає два взаємодоповнюючі рівні мережевої безпеки:
Internet
│
▼
Internet Gateway
│
▼
┌─────────────────── VPC ─────────────────────┐
│ NACL (рівень підмережі — stateless) │
│ ┌────────────────────────────────────┐ │
│ │ Публічна підмережа │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ Security Group (рівень VM) │ │ │
│ │ │ ┌─────────────────────────┐ │ │ │
│ │ │ │ EC2 Instance │ │ │ │
│ │ │ └─────────────────────────┘ │ │ │
│ │ └─────────────────────────────┘ │ │
│ └────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
Security Group — stateful міжмережевий екран на рівні окремого EC2-екземпляра (або мережевого інтерфейсу).
Ключові властивості:
Типова конфігурація Security Group для веб-сервера:
| Напрям | Протокол | Порт | Джерело/Призначення | Опис |
|---|---|---|---|---|
| Вхідний | TCP | 443 | 0.0.0.0/0 | HTTPS з будь-якого місця |
| Вхідний | TCP | 80 | 0.0.0.0/0 | HTTP (для редиректу) |
| Вхідний | TCP | 22 | 10.0.0.0/16 | SSH тільки з VPC |
| Вихідний | All | All | 0.0.0.0/0 | Весь вихідний дозволено |
Чому reference на SG є потужним інструментом:
Security Group: sg-database
Вхідний: TCP 5432 Джерело: sg-app-server
# Це означає: PostgreSQL (порт 5432) дозволений ЛИШЕ з екземплярів,
# що мають sg-app-server — незалежно від їхніх IP-адрес
NACL (Network Access Control List) — stateless міжмережевий екран на рівні підмережі.
Відмінності від Security Groups:
| Характеристика | Security Group | NACL |
|---|---|---|
| Рівень | Екземпляр | Підмережа |
| Стан | Stateful | Stateless |
| Тип правил | Тільки дозвіл | Дозвіл та заборона |
| Порядок правил | Всі оцінюються | За номером (перше співпадіння) |
| Застосування | По замовчуванню | Додатковий рівень |
Stateless означає: для NACL потрібно явно дозволити і вхідний, і вихідний трафік. Відповідь на вхідне з’єднання — це окремий трафік, що також повинен відповідати правилам.
Приклад: Атака з конкретної IP-адреси? NACL дозволяє швидко заблокувати 10.1.2.3 на рівні підмережі до того, як трафік дістанеться до Security Groups.
AWS Network Firewall — керований stateful брандмауер для VPC з підтримкою:
AWS WAF (Web Application Firewall) — захист на рівні HTTP(S):
CDN (Content Delivery Network) — географічно розподілена мережа серверів (Points of Presence, PoP), що кешують та доставляють контент з точки, максимально наближеної до кінцевого користувача.
Проблема без CDN:
Користувач (Токіо) ────────────────────────────► Origin Server (Франкфурт)
◄────────────── RTT: ~250 мс ──────────────────────────
Проблема з CDN:
Користувач (Токіо) ──► CDN PoP (Токіо) ──► Origin (Франкфурт)
◄── RTT: ~5 мс (кеш) (тільки для некешованих запитів)
Алгоритм роботи CDN:
image.jpg)Cache-Control заголовки визначають, скільки часу контент залишається в кеші:
Cache-Control: max-age=86400 # кешувати на 24 години
Cache-Control: no-cache # не кешувати
Cache-Control: s-maxage=3600 # для CDN-кешу: 1 година
Amazon CloudFront — CDN від AWS з понад 450 точками присутності у 90+ містах.
Ключові можливості CloudFront:
Типовий сценарій:
Браузер ──► CloudFront ──► Статика: S3 Bucket (кеш 24г)
──► API: ALB + EC2 (кеш відсутній або динамічний)
──► Відео: MediaPackage (адаптивний стримінг)
Azure CDN:
Google Cloud CDN:
Multi-Region Architecture (Активна-Активна):
Розгортання застосунку одночасно у кількох географічних регіонах з активним обслуговуванням трафіку з кожного.
┌─────────────────────┐
│ Global DNS / GTM │
│ (Geo-routing) │
└──────────┬──────────┘
┌──────────────┼──────────────┐
▼ ▼ ▼
Region: EU Region: US Region: APAC
┌──────────┐ ┌──────────┐ ┌──────────┐
│ App + │ │ App + │ │ App + │
│ DB (r/w)│◄──►│ DB (r/w)│◄──►│ DB (r/w)│
└──────────┘ └──────────┘ └──────────┘
Переваги активно-активної архітектури:
Виклики:
AWS Global Accelerator:
Amazon Route 53 / Azure DNS / Cloud DNS — керовані DNS-сервіси з додатковими можливостями:
Routing Policies (Route 53):
| Тип маршрутизації | Опис | Сценарій |
|---|---|---|
| Simple | Один запис → одна відповідь | Простий однорегіональний застосунок |
| Weighted | Відсоток трафіку → кожен endpoint | A/B-тестування, плавна міграція |
| Latency | → до регіону з найменшою затримкою | Глобальні застосунки |
| Geolocation | → залежно від країни/континенту запиту | Контент для конкретних регіонів |
| Failover | Primary → Secondary при відмові Primary | Аварійне відновлення |
| Multivalue | Відповідь кількома IP + health check | Простий балансувальник навантаження |
VPC/VNet — основа хмарної мережевої архітектури. Ізольоване мережеве середовище з повним контролем над адресацією, маршрутизацією та безпекою є обов’язковою умовою для безпечного хмарного розгортання.
Архітектура підмереж (публічні/приватні/ізольовані) у кількох зонах доступності — базова практика для забезпечення відмовостійкості та безпеки. Бази даних та сервери застосунків ніколи не повинні знаходитись у публічній підмережі.
Балансувальники навантаження (ALB для HTTP, NLB для TCP/UDP) забезпечують горизонтальне масштабування, відмовостійкість та SSL-термінацію. Вибір типу LB залежить від протоколу та вимог до продуктивності.
Security Groups та NACL формують дворівневий мережевий захист: SG — stateful захист на рівні екземпляру, NACL — stateless захист на рівні підмережі. Разом вони реалізують принцип Defense in Depth.
CDN (CloudFront, Azure CDN, Cloud CDN) радикально знижує затримку та підвищує масштабованість статичних ресурсів, розвантажуючи origin-сервери. Інтеграція CDN з WAF забезпечує захист на краю мережі.
Глобально розподілені архітектури з Multi-Region розгортанням, Global Accelerator та геомаршрутизацією DNS дозволяють досягти мінімальної затримки та максимальної відмовостійкості для глобальних застосунків.
10.0.0.0/20? Скільки з них доступні для ресурсів в AWS?