Çok hesaplı / çok VPC–VNet’li yapılarda hub‑spoke veya Transit Gateway konuşmak kolaydır; zor olan kısmı, bunun güvenli varsayılanlarla ve işletilebilir bir şekilde tasarlamaktır. Çünkü gerçek hayatta sorun “bağlanamadım” değildir; sorun şudur:
- Yanlış rota propagasyonu ile istenmeyen doğu‑batı erişim
- Inspection (firewall/NVA) baypas’ı
- Bir değişiklikten sonra “hangi akış nereden gidiyor?” sorusunun cevapsız kalması
Bu yazıda Transit Gateway (veya eşdeğer hub‑spoke bileşenleri) için sahada işleyen bir yönetişim yaklaşımını toparlıyorum.
1) Önce sınırları çiz: hangi trafik hangi sınıfa giriyor?
Transit katmanını tasarlamadan önce trafiği sınıflandırın:
- North‑South: internet / SaaS / dış dünya
- East‑West: VPC–VNet’ler arası servis çağrıları
- Shared Services: DNS, logging, CI runner, artifact, registry gibi ortak servisler
- On‑prem: veri merkezi, MPLS, legacy segmentler
Her sınıf için üç soru:
- Inspection zorunlu mu? (FW, DLP, IDS, proxy)
- Kimlik kontrolü nerede? (IAM, mTLS, proxy auth)
- Gözlem sinyali nerede? (flow log, firewall log, NDR)
2) Güvenli varsayılan: “propagation kapalı, association bilinçli”
En sık gördüğüm hata: Transit route table’larda otomatik propagasyonla büyüyen “gizli mesh”.
Benim pratik kuralım:
- Route propagation: varsayılan kapalı
- Association: her attachment (spoke) bilinçli olarak bir tabloya bağlanır
- Egress / inspection: ayrı tablo ve ayrı “gate” noktaları
3) Referans desen: 4 bölümlü mimari
Sade ama güçlü bir başlangıç deseni:
A) Spoke’lar (Uygulama VPC/VNet)
- Uygulama subnetleri
- Minimum egress (NAT yoksa bile kontrol var)
- Spoke’lar birbirini default’ta görmez
B) Shared Services (Ortak servisler)
- DNS forwarder/resolver
- Logging/telemetry collector
- Artifact/registry
- Yönetim bastion/SSO proxy (mümkünse “jump host’suz” model)
C) Inspection VPC/VNet (Güvenlik kapısı)
- Firewall/NVA/IDS
- Proxy / TLS inspection gerekiyorsa burada
- “Bypass”ı engelleyecek route ve guardrail’ler
D) Egress VPC/VNet (İnternet çıkışı)
- NAT, egress firewall, allowlist/denylist
- SaaS çıkışları için merkezi kontrol
Bu ayrım, “yönetişim” kelimesini pratik hale getirir: kim nereden çıkar, kim kimle konuşur, nereden ölçülür.
4) Guardrail’ler: yanlış değişikliği pahalı olmaktan çıkar
Transit katmanında küçük bir hata, büyük etki üretir. Guardrail’ler bu yüzden “nice to have” değil.
Benim minimum setim:
- Route table değişiklikleri için onay kapısı (PR / IaC)
- Prefix‑list / route‑map benzeri kısıtlar (platforma göre)
- “Inspection bypass” için otomatik kontrol (reachability analizi)
- Flow log zorunluluğu + retention politikası
- Tag/label standardı (attachment owner, env, criticality)
5) Operasyon: “hangi akış nereden gidiyor?” sorusuna 5 dakikada cevap
Transit tasarımında hedef sadece bağlantı değil; incident anında hızlı teşhistir.
Benim sahada işime yarayan yaklaşım:
- Her kritik spoke için “golden path” akış listesi (ör. app→db, app→shared‑dns, app→internet)
- Bu akışlar için:
- Flow log query şablonları
- Firewall log korelasyon noktaları
- Route table snapshot ve diff
6) Değişiklik disiplini: transit için “küçük dalga” şart
Transit route değişiklikleri, uygulama deploy’u gibi “gün içinde 20 kere” yapılmamalı.
Pratik politika:
- Değişiklik penceresi + pre‑mortem (kritikse)
- Canary spoke (önce non‑prod veya düşük risk)
- Rollback planı (eski route setine geri dönmek)
7) Runbook: “Spoke diğer spoke’a erişemiyor”
Triage sırası:
- Spoke route table: hedef prefix route’u var mı?
- Transit association: doğru tabloya mı bağlı?
- Propagation: yanlış tablodan route sızmış mı / hiç gelmemiş mi?
- Inspection: firewall log’da akış görünüyor mu? (görünmüyorsa bypass veya route yok)
- NACL/SG: transit doğru olsa bile L4 engel var mı?
Kapanış
Transit Gateway/hub‑spoke; doğru tasarlanırsa segmentasyonu sadeleştirir, inspection’ı merkezileştirir ve operasyonel teşhisi hızlandırır. Yanlış tasarlanırsa, “gizli mesh” üretir ve riskleri görünmez kılar.
Benim hedefim şu: Transit, bağlantı sağlayan bir kutu değil; güvenlik ve operasyon için kontrol düzlemidir.