Hub-and-Spoke Ağ Topolojisi: Azure ve AWS Diyagramları

İlk bulut ağı kolaydır. Onuncusuna gelindiğinde bir peering bağlantıları ağı, ofise giden ve her biri biraz farklı yapılandırılmış üç VPN tüneli, her ağa kopyalanmış bir güvenlik duvarı vardır ve kimse neyin neye erişebildiğini güvenle söyleyemez. Hub-and-spoke bundan çıkmanın standart yoludur: paylaşılan bağlantı ve inceleme için tek bir merkezi ağ, iş yükleri için de yalnızca onun üzerinden bağlanan yalıtılmış spoke'lar.

Bu yazı topolojiyi açıklıyor ve ardından onu diyagramlarla iki kez kuruyor: Azure'da bir hub sanal ağı ve peering ile, AWS'de Transit Gateway ile. Yönlendirme ve segmentasyonu, trafik incelemeyi, merkezi çıkışı, ekipleri şaşırtan maliyetleri ve yönetilen bir hub'ın ne zaman daha iyi bir seçim olduğunu ele alıyor.

Mesh neden işe yaramaz hâle gelir

Her ağı diğer her ağa doğrudan bağlamak n(n−1)/2 bağlantı gerektirir. On ağ için 45, elli ağ için 1.225 bağlantı gerekir ve her birinin kendi yolları ve güvenlik kuralları olur. Peering ayrıca iki bulutta da geçişli değildir: A, B ile, B de C ile eşlenmişse A yine de B üzerinden C'ye ulaşamaz. Hub-and-spoke tasarımı spoke başına tek bir bağlantı gerektirir ve hub, yönlendirme ile güvenlik politikasının yaşadığı tek yer olur.

Hub'a neler konur

İş yükleri hub'a ait değildir. Spoke'lar uygulamaları tutar, genellikle uygulama, ekip ya da ortam başına bir tane; böylece birindeki hata diğerlerine yayılamaz.

Azure'da hub-and-spoke

Microsoft'un hub-spoke referans mimarisi, Azure Firewall'u, bir VPN ya da ExpressRoute ağ geçidini ve Azure Bastion'ı her biri kendine ayrılmış bir alt ağda olmak üzere bir hub sanal ağına koyar. Azure Firewall en az /26 boyutunda bir alt ağ ister. Spoke'lar hub'a sanal ağ peering ile bağlanır ve Microsoft bunu geçişsiz olarak tanımlar: Eşlenmiş ağlar birbirleriyle konuşur, birbirlerinin üzerinden değil.

Bunun iki sonucu var:

• Ağ geçidi paylaşımı açıkça yapılır. Hub peering'i ağ geçidi geçişine izin verir ve her spoke uzak ağ geçidini kullanır; böylece spoke'lar şirket içine hub'ın ağ geçidi üzerinden ulaşır.
• Spoke'tan spoke'a trafik yol ister. Her spoke'taki kullanıcı tanımlı yollar diğer spoke'lara giden trafiği, genellikle de varsayılan yolu, güvenlik duvarının özel IP'sine gönderir. Güvenlik duvarı politikanın izin verdiği trafiği iletir. Alternatif olarak Azure Virtual Network Manager peering'leri ve bağlı grupları ölçekli yönetebilir; özel durumlar için iki spoke arasında doğrudan peering de bir seçenek olarak kalır.

Microsoft tarafından yönetilen bir hub için Azure Virtual WAN; yerleşik yönlendirme, ağ geçitleri ve isteğe bağlı güvenlik duvarları olan hub'lar sunar, karşılığında ayrıntılar üzerinde daha az kontrol bırakır.

AWS'de hub-and-spoke

AWS'de hub genellikle bir Transit Gateway'dir: VPC'lerin, VPN bağlantılarının ve Direct Connect ağ geçitlerinin bağlandığı bölgesel bir yönlendirici.

• Spoke'lar VPC ekleridir (attachment). Transit Gateway kotalarına göre bir Transit Gateway varsayılan olarak 5.000 eki destekler; yani peering mesh'lerinin çok ötesine ölçeklenir.
• Segmentasyon Transit Gateway yol tablolarından gelir. Üretim ekleri bir yol tablosuyla, geliştirme ekleri başka biriyle ilişkilendirilir; böylece ikisi birbirinin yollarını hiç öğrenmez, ama ikisi de paylaşılan servisler VPC'sine ulaşabilir.
• İnceleme, AWS Network Firewall ya da bir Gateway Load Balancer arkasındaki üçüncü taraf cihazlar çalıştıran ayrı bir inceleme VPC'sinde yapılır. Spoke yol tabloları Transit Gateway'i gösterir; Transit Gateway yolları da trafiği inceleme VPC'sinden geçirir.
• İnceleme VPC'sinin ekindeki appliance mode, bir akışın iki yönünü aynı Availability Zone'da tutar; durum bilgili güvenlik duvarları bunu gerektirir.
• Merkezi çıkış: Her VPC'de NAT ağ geçidi yerine, NAT ağ geçitleri olan bir çıkış VPC'si bütün spoke'lara hizmet eder.

Pek çok bölgeye yayılan küresel ağlar için AWS Cloud WAN, Azure'da Virtual WAN'ın oynadığı rolü üstlenir: politika tabanlı segmentleri olan yönetilen bir çekirdek ağ.

İki bulut yan yana

Yönlendirme, segmentasyon ve simetri

Üç kural bir hub-and-spoke ağını öngörülebilir tutar:

1. Varsayılan yollar hub'ı gösterir. Spoke'lar yerel olmayan her şeyi hub'a gönderir; böylece hiçbir şey yanlışlıkla incelemeyi atlamaz.
2. Segmentler açıktır. Hangi spoke'ların hangileriyle konuşabileceğine karar verin: Üretim ve geliştirme genellikle konuşamaz, paylaşılan servislere genellikle her yerden ulaşılabilir ve şirket içi erişim güvenlik duvarından geçer.
3. Dönüş trafiği aynı yolu izlemelidir. Durum bilgili bir güvenlik duvarı, çıkışını görmediği yanıtları düşürür. Asimetrik yollar, “güvenlik duvarı kuralı orada ama hiçbir şey çalışmıyor” durumunun en yaygın nedenidir.

Adres planını ilk spoke var olmadan önce yazın. Spoke'lar arasında ya da şirket içiyle çakışan CIDR aralıkları bir hub üzerinden yönlendirilemez ve sonradan düzeltmek zahmetlidir.

Maliyeti

Hub'ı geçen her bayt bir yerde faturalanır. AWS'de, bu yazının yazıldığı tarihte (Kasım 2026), US East (N. Virginia) için Transit Gateway fiyatlandırması ek başına saatlik 0,05 USD ve işlenen veri için GB başına 0,02 USD'dir. On spoke eki, daha hiç trafik olmadan, yaklaşık 10 × 0,05 USD × 730 saat, yani ayda kabaca 365 USD tutar. On TB spoke'tan spoke'a trafik, yaklaşık 10.240 GB × 0,02 USD ile kabaca 205 USD işleme ücreti ekler; buna güvenlik duvarının kendi işleme ücretleri de eklenir. Azure'da eşlenmiş trafik, peering'in iki ucunda da GB başına ücretlendirilir ve Azure Firewall kendi işleme ücretini ekler.

Olağan optimizasyon hedeflidir: Hub'ı politika için tutun, çok yüksek hacim alışverişi yapan ve incelemeye ihtiyaç duymayan belirli bir spoke çifti için doğrudan peering ekleyin.

Hub-and-spoke ne zaman kullanılmamalı

• İki ya da üç ağın hub'a ihtiyacı yoktur; doğrudan peering daha basittir.
• Gecikmeye duyarlı doğu-batı trafiği her pakette fazladan bir sekme ve bir güvenlik duvarı bedeli öder. Konuşkan bir servis çiftini incelemeden geçirmeden önce ölçün.
• Çok büyük iç hacimler, GB başına işleme ücretini en büyük ağ maliyeti yapabilir. O akışlar için doğrudan peering çoğu zaman haklıdır.
• Çok büyük, çok bölgeli yapılar, elle kurulmuş yol tabloları yerine yönetilen bir hub'la, Virtual WAN ya da Cloud WAN ile daha iyi hizmet alabilir.

Hub-and-spoke diyagramı

Nasıl okunur:

• Üstteki şirket içi ağ her buluta bir kez bağlanır: Azure hub'ının ağ geçidine ve AWS Transit Gateway'e.
• Azure çerçevesi, güvenlik duvarı ve VPN ağ geçidiyle hub sanal ağını ve ona eşlenmiş iki spoke'u gösterir. Spoke'tan spoke'a trafik güvenlik duvarından geçer.
• AWS çerçevesi ortada Transit Gateway'i, güvenlik duvarıyla inceleme VPC'sini ve ona bağlı iki spoke VPC'yi gösterir.
• Kenar etiketleri bağlantı türünü adlandırır: peering, ek, VPN ya da özel devre.
• Markdown bloğu yönlendirme kurallarını ve yukarıdaki maliyet rakamlarını listeler.

İncelemeden geçen ağ topolojileri çizmek

• Her ağın üzerine CIDR aralığını yazın. Çakışmalar, inceleyenin ilk baktığı şeydir.
• Güvenlik duvarını trafiğin gerçekten geçtiği yere çizin ve varsayılan yolun onu gösterdiğini belirtin.
• Her bağlantıyı türüyle etiketleyin. Peering, ek ve VPN farklı davranır ve farklı ücretlendirilir.
• Bölge başına bir diyagram tutun. Tek bir tuvale çizilmiş çok bölgeli ağlar genellikle asıl önemli olan bölgeler arası bağlantıları gizler.

Tek bir ağın içi için AWS VPC diyagramına bakın. Ağ topolojisi diyagramı fiziksel ve mantıksal topolojileri genel olarak ele alır; sıfır güven mimari diyagramı ise ağdaki konumun neden tek başına erişim vermemesi gerektiğini açıklar. Çok bölgeli tasarımlar AWS çok bölgeli mimari diyagramında anlatılıyor.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Üste şirket içi ağ için bir Temel Kutu ekleyin.
3. Azure için bir Temel Çerçeve ekleyin. İçine hub sanal ağı için Ağ paketinden bir VPC düğümü, onun içine de bir Güvenlik duvarı ve VPN ağ geçidi için bir Cihaz düğümü koyun; spoke'lar için de her biri kendi CIDR'ıyla iki VPC düğümü daha ekleyin.
4. AWS için bir Temel Çerçeve ekleyin. İçine Transit Gateway için Ağ paketinden bir Yönlendirici, içinde bir Güvenlik duvarı olan inceleme VPC'si için bir VPC düğümü ve spoke'lar için iki VPC düğümü ekleyin.
5. Şirket içini Azure ağ geçidine ve Transit Gateway'e, spoke'ları kendi hub'larına bağlayın ve her kenarı bağlantı türüyle etiketleyin.
6. Yönlendirme kuralları ve maliyetlerle Temel paketinden bir Markdown bloğu ekleyin.

Örnek 14 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

Hub-and-spoke ağ topolojisi nedir? Merkezi bir ağın, yani hub'ın, paylaşılan bağlantıyı, güvenliği ve servisleri tuttuğu; her iş yükü ağının, yani spoke'un, yalnızca hub'a bağlandığı bir tasarım. Spoke'lar arasındaki ve şirket içine giden trafik hub'dan geçer.

Sanal ağ peering geçişli midir? Hayır, ne Azure'da ne AWS'de. Aynı hub ile eşlenmiş iki spoke, yollar trafiklerini hub'daki bir güvenlik duvarına ya da yönlendiriciye göndermedikçe hub üzerinden birbirine ulaşamaz.

Transit Gateway ile VPC peering arasındaki fark nedir? VPC peering iki VPC'yi doğrudan bağlar ve geçişli değildir. Transit Gateway ise pek çok VPC'nin ve şirket içi bağlantının bağlandığı, segmentasyon için yol tabloları olan bölgesel bir yönlendiricidir.

Hub sanal ağı yerine Azure Virtual WAN mı kullanmalıyım? Virtual WAN, hub yönlendirmesini ve ağ geçitlerini Microsoft'un yönetmesini isteyen büyük ya da çok bölgeli yapılara uyar. Kendi yönettiğiniz bir hub daha fazla kontrol verir ve bir ya da iki bölgede birkaç spoke için yaygındır.

Hub-and-spoke'un maliyeti nedir? Hub bağlantıları ve işlenen trafik saat ve GB başına faturalanır; buna güvenlik duvarı işleme ücreti eklenir. AWS'de, bu yazının yazıldığı tarihte, US East'te bir Transit Gateway eki saatlik 0,05 USD, veri işleme ise GB başına 0,02 USD tutuyor.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.