VPC Peering і маршрутизація

1) Навіщо Peering і коли він доречний

• поділ середовищ і доменів (prod/stage/dev) при загальній приватній зв'язності;
• винесення загальних платформ (логування, KMS/Vault, артефакти) в shared-мережі;
• доступ з додатків до керованих PaaS приватними шляхами (через хаби/endpoint'и).

Коли краще не peering, а хаб: більше 10-20 мереж, необхідність транзитної маршрутизації, централізований egress, міжхмарні зв'язки → використовуйте Transit Gateway/Virtual WAN/Cloud Router.

2) Моделі та обмеження

2. 1 Види пірингу

Intra-region peering - всередині регіону, мінімальні затримки і вартість.
Inter-region peering - між регіонами, зазвичай оплачується міжрегіональний трафік.
Cross-project/account - піринг між різними акаунтами/проектами (з делегуванням).

2. 2 Транзит і NAT

Класичний VPC/VNet Peering не транзитивний: мережа A↔B і B↔C не означає A↔C.
NAT через проміжну мережу для транзиту - анти-патерн (ламає вихідні IP, складний аудит).
Для транзиту - хаб-шина: AWS Transit Gateway (TGW), Azure Virtual WAN/Hub, GCP Cloud Router/HA VPN/Peering Router.

2. 3 Overlapping CIDR

• Переплан адрес (кращий варіант);
• NAT-домени/Proxy VPC з односторонніми схемами (з урахуванням аудиту та логування);
• Для специфічних PaaS - PrivateLink/PSC без L3-доступу.

3) Дизайн адресації та маршрутів

3. 1 Планування CIDR

Єдиний супернет (наприклад,'10. 0. 0. 0/8') → ділимо по'region/env/vpc'.
Резервуйте діапазони під майбутні VPC/тенанти (growth-buffers).
IPv6 - план заздалегідь: '/56'на VPC, '/64'на підмережі.

3. 2 Маршрутизація

Route tables: на кожному VPC/підмережі явні маршрути на peer/hub.
Пріоритети: більш специфічний префікс виграє; уникайте catch-all через піринг.
Blackhole-захист: дублюючі/застарілі маршрути позначайте і чистіть.

3. 3 Домени і ролі

Spoke (додатки) ↔ Hub (загальні сервіси, egress, інспекція).
Бенкети тільки spoke↔hub; spoke↔spoke - через хаб (сегментація і контроль).

4) Патерни топологій

4. 1 «Простий» mesh (≤5 VPC)

Прямі пін-ту-пін бенкети (A↔B, A↔C...). Плюси: мінімум компонентів; мінуси: O (N ²) зв'язків і правил.

4. 2 Hub-and-Spoke

Всі spoke пиряться з Hub VPC/VNet; в хабі - TGW/Virtual WAN/Cloud Router, NAT/egress, інспекція. Масштабовано, просто управляти.

4. 3 Мульти-регіон

Локальні хаби в кожному регіоні; між хабами - inter-region peering або магістраль (TGW-to-TGW/VWAN-to-VWAN).

5) Безпека та сегментація

Stateful на хості: SG/NSG - основний бар'єр; NACL/підмережеві ACL - грубе огородження/deny-листи.
L7 політики в mesh/proxy (Istio/Envoy/NGINX) - авторизація по mTLS/JWT/claims.
Egress-контроль: spoke не повинен «бачити» інтернет безпосередньо - тільки через egress-шлюз/PrivateLink.
Flow Logs і інспекція в хабі (GWLB, IDS/IPS) для міжVPC трафіку.

6) DNS и split-horizon

Кожній приватній зоні - видимість на потрібних VPC (Private Hosted Zones/Private DNS/Zones).
Для PaaS через PrivateLink/PSC - приватні записи на приватні IP endpoint'ів.
Conditional forwarding между on-prem ↔ cloud и region ↔ region.
Іменування: `svc. env. region. internal. corp'- без PII; фіксуйте TTL (30-120с) під фейловер.

7) Спостережуваність і тестування

Метрики: accepted/denied на SG/NSG, bytes per peer, RTT/jitter між регіонами, top-talkers.
Логи: VPC Flow Logs/NSG Flow Logs в SIEM, трасування з'trace _ id'для кореляції L7↔L3.
Тести досяжності: синтетика TCP/443/DB-порти з різних підмереж/AZ/регіонів; reachability analyzer.
Chaos-мережа: затримки/втрати між peer/hub; перевірка таймаутів/ретраїв/ідемпотентності.

8) Продуктивність і вартість

Inter-region майже завжди тарифікується; рахуйте egress заздалегідь (дорожчає при логах/бекапах).
MTU/PMTUD: в межах провайдера стандартна MTU, але на кордонах (VPN, FW, NAT-T) враховуйте MSS-clamp.
Горизонтальне масштабування інспекції (GWLB/scale sets) без вузьких місць; ECMP для хабів.
Кеш/edge і SWR зменшують міжрегіональний трафік.

9) Хмарні особливості та приклади

9. 1 AWS (VPC Peering / Transit Gateway)

VPC Peering: створюємо peering connection, додаємо маршрути в таблицях підмереж.
Немає транзиту через звичайний peering. Для транзиту і централізованої моделі - Transit Gateway.

hcl resource "aws_vpc_peering_connection" "a_b" {
vpc_id    = aws_vpc. a. id peer_vpc_id  = aws_vpc. b. id peer_owner_id = var. peer_account_id auto_accept  = false tags = { Name = "a-b", env = var. env }
}

resource "aws_route" "a_to_b" {
route_table_id     = aws_route_table. a_rt. id destination_cidr_block = aws_vpc. b. cidr_block vpc_peering_connection_id = aws_vpc_peering_connection. a_b. id
}

9. 2 Azure (VNet Peering / Virtual WAN)

VNet Peering (включаючи глобальний): прапори Allow forwarded traffic, Use remote gateway для хаб-схем.
Для хабів і транзиту - Virtual WAN/Hub c Route Tables і Policies.

bash az network vnet peering create \
--name spokeA-to-hub --vnet-name spokeA --remote-vnet hub \
--resource-group rg --allow-vnet-access --allow-forwarded-traffic

9. 3 GCP (VPC Peering / Cloud Router)

VPC Peering без транзиту; для центру - Cloud Router + HA VPN/Peering Router.
Hierarchical FW для org-guardrails.

10) Kubernetes в пірингових мережах

Кластер в spoke, загальні сервіси (логування/сховище/артефакти) - в hub; доступ за приватними адресами.
NetworkPolicy «deny-all» і явні egress на хаб/PrivateLink.
Не «тягайте» Pod CIDR між VPC; маршрутизуйте Node CIDR і користуйтеся Ingress/Gateway.

11) Траблшутінг (шпаргалка)

1. CIDR не перетинаються? Перевірити суперсети/старі підмережі.
2. Таблиці маршрутів: чи є шлях в обидві сторони? Чи немає більш специфічного маршруту, що перехоплює трафік?
3. SG/NSG/NACL: stateful-ін/аут відповідають? Чи не блокує ACL зворотний трафік?
4. DNS: правильні приватні записи/forwarders? Перевірити'dig + short'з обох мереж.
5. MTU/MSS/PMTUD: чи немає фрагментації і «мовчазних» таймаутів?
6. Перевірка flow logs: чи є SYN/SYN-ACK/ACK? Хто дропає?
7. Inter-region: квоти/ліміти пірингу/політики організації/теги маршрутизації.

12) Антипатерни

«Випадковий» mesh з десятків бенкетів без хаба → вибух складнощів і пропусків ACL.
Overlapping CIDR «як-небудь пережмем NAT'ом» → ламається аудит/наскрізна ідентифікація.
Публічні egress в кожному spoke → неконтрольована поверхня і вартість.
Відсутність split-horizon DNS → витоку імен/биті резолви.
Широкі маршрути'0. 0. 0. 0/0'через peer → несподівана асиметрія трафіку.
Ручні правки в консолі без IaC і ревізії.

13) Специфіка iGaming/фінансів

PCI CDE і платіжні контури - тільки через хаб з інспекцією; ніякого spoke↔spoke в обхід.
Data residency: PII/транзакційні логи - всередині юрисдикцій; міжрегіонально - агрегати/анонім.
Multi-PSP: PrivateLink/приватні канали до PSP, централізований egress-проксі по allowlist FQDN і mTLS/HMAC.
Аудит/WORM: flow-логи та зміни маршрутів у незмінному сховищі, ретеншн за нормами.
SLO розрізи: per region/VPC/tenant; альберти на «витік egress» і деградацію міжрегіональних RTT.

14) Чек-лист prod-готовності

• План CIDR без перетинів (IPv4/IPv6), зарезервовані пули зростання.
• Топологія hub-and-spoke; бенкети - тільки spoke↔hub; транзит через TGW/VWAN/Cloud Router.
• Route tables: явні шляхи, немає catch-all через peer, контроль blackhole.
• SG/NSG/NACL застосовані; L7-політики в mesh; egress тільки через хаб/PrivateLink.
• Private DNS/PHZ налаштовані; conditional-forwarders между on-prem/cloud/regions.
• Flow Logs включені; дашборди за peer/region; синтетика досяжності та PMTUD-тести.
• IaC (Terraform/CLI) і Policy-as-Code (OPA/Conftest) для правил/маршрутів/DNS.
• Документовані runbook'і (додати peer, розкатати маршрути, відключити spoke).
• Навчання: відключення хаба/бенкету, вимірювання фактичних RTO/RPO мережевих шляхів.
• Для iGaming/фінансів: ізоляція PCI, PrivateLink до PSP, WORM-аудит, SLO/алерти за юрисдикціями.

15) TL; DR

Використовуйте VPC/VNet Peering для простої приватної зв'язності «точка-к-точці», але не покладайтеся на нього для транзиту - для цього потрібен хаб (TGW/VWAN/Cloud Router). Плануйте CIDR без перетинів, тримайте маршрути явними і специфічними, застосовуйте stateful SG/NSG і L7-політики в mesh, DNS - split-horizon. Увімкніть flow-логи, синтетику та PMTUD-перевірки. Для iGaming/фінансів - ізоляція PCI, приватні канали до PSP і незмінний аудит.