Bulutta VPC tasarımı: adres planından alt ağ mimarisine

VPC nedir ve neden tasarım gerektirir?

VPC (sanal özel bulut), bulut sağlayıcısının ortak altyapısı içinde yalnızca size ait, mantıksal olarak yalıtılmış bir ağ alanıdır. Kendi IP adres aralığınızı seçer, alt ağlar oluşturur, trafiğin hangi yoldan geçeceğini ve kimin kime erişeceğini siz belirlersiniz. AWS bunu VPC, Azure Virtual Network, Google Cloud ise VPC olarak sunar; kavramlar benzer, adlar ve bazı varsayılanlar farklıdır.

Tasarım önemlidir, çünkü ağın temelindeki kararlar sonradan değiştirmesi en zor olanlardır: adres planı ve bölümleme. Çakışan adres aralıkları ileride ağları birbirine bağlamayı imkânsız kılar; fazla küçük seçilen aralık büyümeyi engeller. Sonradan düzeltmek çoğu zaman kaynakları yeniden kurmak demektir.

Adım adım: adres planından alt ağlara

Tasarım şu sırayla ilerler.

Birinci adım adres planıdır. Kurumun şirket içi ağlarında, diğer bulut hesaplarında ve ileride bağlanabilecek iş ortağı ağlarında kullanılan aralıklar listelenir; yeni VPC bunlarla çakışmayacak biçimde ve büyüme payı bırakılarak seçilir. Kurum genelinde merkezi bir adres yönetimi tablosu tutmak bu işi kolaylaştırır.

İkinci adım alt ağlardır. Alt ağlar işlev ve erişim düzeyine göre ayrılır: internete doğrudan açılan genel alt ağlar (yük dengeleyici gibi bileşenler için), uygulama sunucularının bulunduğu özel alt ağlar, veritabanları gibi hiç dışarıya açılmayan yalıtılmış alt ağlar. Her katman birden fazla erişilebilirlik alanına yayılırsa tek bir veri merkezi sorunu uygulamayı düşürmez.

Üçüncü adım yönlendirmedir: yol tablosu, internet çıkışı için ağ geçidi ve özel alt ağların dışarıya çıkması gerekiyorsa NAT çözümü. Dördüncü adım güvenliktir: güvenlik grupları, ağ erişim listeleri ve gerekirse merkezi güvenlik duvarı. Son adım izlemedir: akış günlükleri ile trafik kaydı tutulur.

Ağ geçitleri, uç noktalar ve özel servis erişimi

Özel alt ağdaki bir sunucunun depolama ya da kuyruk gibi sağlayıcı hizmetlerine erişmesi gerekir. Bunu internet üzerinden NAT ile yapmak hem ek maliyet hem de gereksiz maruz kalmadır. Daha temiz yöntem, özel uç noktalardır (AWS'de VPC endpoint, Azure'da Private Endpoint, Google Cloud'da Private Service Connect ve Private Google Access): trafik sağlayıcının ağı içinde kalır ve internete hiç çıkmaz.

Çıkış mimarisi de ayrı bir karardır. Hangi alt ağların internete çıkabileceği, çıkışın merkezi bir denetim noktasından geçip geçmeyeceği ve gerekli alan adlarına filtreleme uygulanıp uygulanmayacağı kurumun güvenlik duruşunu belirler. Çıkışı kısıtlanmamış bir ağda, ele geçirilen bir sunucu veriyi serbestçe dışarı taşıyabilir.

Çoklu hesap ve hibrit bağlantı topolojileri

Kurumsal ortamlar tek VPC ile yetinmez. Üretim, test ve ortak hizmetler ayrı hesaplarda ya da aboneliklerde tutulur ve bu ağlar birbirine bağlanır. Basit durumlarda ağlar arası eşleme (peering) yeterlidir; çok sayıda ağ olduğunda her biri diğerine bağlanmak yönetilemez hale gelir. Bu noktada merkezi bir geçiş ağı ya da hub-spoke topolojisi kurulur: ortak hizmetler ve güvenlik denetimi merkezde, iş yükü ağları kenarda yer alır.

Şirket içi ağ ile bulut arasındaki bağlantı için ise şu yollar vardır: internet üzerinden şifreli VPN ya da sağlayıcıyla doğrudan özel hat. İkisi de adres planının tutarlı olmasına bağımlıdır; bu yüzden ilk adımdaki planlama tüm yapıyı belirler. Özel hat konusu ayrı bir becerinin konusu olarak ele alınır.

Örnek senaryo: katmanlı bir web uygulaması

Örneğin bir sipariş uygulaması düşünelim. Genel alt ağlarda yalnızca yük dengeleyici bulunur. Uygulama sunucuları özel alt ağlardadır ve yalnızca yük dengeleyiciden gelen trafiği kabul eder. Veritabanı yalıtılmış alt ağdadır; yalnızca uygulama katmanından erişilebilir ve internete çıkışı yoktur. Sunucuların güncelleme alması gerekiyorsa kontrollü bir çıkış noktası kullanılır.

Güvenlik grupları katmanlar arasında zincir kurar: veritabanı grubu "yalnızca uygulama grubundan gelene izin ver" der, IP aralığı yazmaz. Böylece sunucu sayısı değişse de kural geçerli kalır. Bütün bu yapı bir altyapı-kod şablonuyla tanımlanır; böylece test ortamı üretimin birebir kopyası olarak kurulabilir ve değişiklikler gözden geçirilebilir.

Sık yapılan hatalar

• Varsayılan VPC ile üretime çıkmak: varsayılan ağlar hızlı başlamak için tasarlanmıştır, kurumsal gereksinimleri karşılamaz.
• Adres aralığını sonradan çakışacağını düşünmeden seçmek.
• Tüm kaynakları genel alt ağlara koymak; veritabanı ve uygulama sunucuları doğrudan internete bakar.
• Güvenlik gruplarında "her yerden gelen her trafiğe izin ver" kuralıyla ilerleyip sonra daraltmayı unutmak.
• Akış günlüğü açmamak; bir olay olduğunda neyin nereye bağlandığı bilinemez.
• Bulut ağ tasarımını el ile konsoldan yapmak; değişiklik geçmişi kaybolur, ortam kopyalanamaz.
• Sağlayıcıların adlarını eşdeğer sanmak: hizmetler birbirine benzer ama varsayılan davranışları, kapsamları ve sınırları farklıdır.

Nasıl öğrenilir, nereden başlanır?

Klasik ağ bilgisi (IP adresleme, alt ağ maskesi, yönlendirme, güvenlik duvarı mantığı) temeldir; bulutun getirdiği şey yeni bir ağ kavramı değil, aynı kavramların yazılımla tanımlanmasıdır. Önce bir sağlayıcıda küçük bir VPC kurup genel ve özel alt ağ oluşturun, bir sunucuya yalnızca yük dengeleyiciden erişilmesini sağlayın. Ardından ikinci bir ağla eşleme deneyin.

Mindset kataloğunda sağlayıcıya göre ayrışan programlar var. Amazon VPC ile Bulut Ağ Mimarisi programı VPC temelleri, adres planlama ve alt ağ tasarımı, çıkış mimarisi, özel servis erişimi, çoklu hesap topolojileri ve hibrit bağlantıyı işliyor. Azure Virtual Network ve Hub-Spoke Ağ Topolojileri programı NSG, VNet peering, hub-spoke ve Azure Firewall konularına odaklanıyor. Google Cloud VPC ve Ağ Mimarisi programında ise alt ağ tasarımı, güvenlik duvarı kuralları, paylaşımlı VPC ve hibrit bağlantı yer alıyor.