Bulut Ağ Tasarımı: Google Cloud VPC, AWS VPC ve Azure VNet
Adres planı, platform sınırları, routing, private erişim, firewall ve hibrit bağlantıların tasarımı ve hata teşhisi.
İçerik güncellemesi:
Mimari ve çalışma modeli
Bulut ağı fiziksel VLAN tasarımının birebir kopyası değildir. Google Cloud VPC global kapsamlıdır ve subnetleri bölgeseldir. AWS VPC bölgeseldir; subnet bir Availability Zone içinde yer alır. Azure VNet bölgeseldir ve subnetleri VNet kapsamındadır. Bu farklar zone yerleşimi, IP planı ve çok-bölge tasarımını etkiler; aynı isimli subnet çizimini üç platforma körlemesine taşımayın.
Route bir yol sunar, firewall izin verir; biri diğerinin yerine geçmez. AWS security group stateful, network ACL stateless davranır. Google Cloud VPC firewall kuralları ve Azure NSGler stateful kontrollerdir, fakat hedefleme, öncelik ve varsayılanları farklıdır. Dönüş yolunu, NATı, portları ve uygulamanın dinlediği arayüzü aynı testte doğrulayın.
Private endpoint veya private API erişimi yalnız özel IP almak değildir. DNS cevabı, kaynak ağ, yetki ve public erişimin kapanışı birlikte kontrol edilir. Peering tek başına tüm transit yolları açmaz. Hibrit VPN veya özel bağlantıda çakışan CIDRler, BGP, MTU ve failover işletim kapsamındadır.
Merkezi inspection tasarımında simetrik trafik, ölçekleme ve arıza etkisi ölçülür. NAT internetten gelen tüm erişimi denetleyen firewall değildir. Yönetim trafiğini uygulama trafiğinden ayırın; akış loglarını kimlik ve uygulama kayıtlarıyla ilişkilendirin.
- 1CIDR ve kapsam
- 2DNS ve route
- 3Firewall ve private servis
- 4Uygulama işlemi
Tasarım parametreleri
- Adres ve büyüme
- On-premises, cloud, container ve DR CIDRlarını çakışmayacak şekilde ayırın.
- Route ve dönüş
- Effective route, NAT ve kaynak IP davranışını iki yönde kaydedin.
- DNS ve private erişim
- Resolver, zone ve public/private cevapları gerçek istemciden doğrulayın.
- Arıza kabulü
- Tünel veya yol kaybında mevcut oturum ve yeni işlemi ayrı ölçün.
Platformlardaki uygulama karşılıkları
Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.
| Konu | Google Cloud | Amazon Web Services (AWS) | Microsoft Azure |
|---|---|---|---|
| Ağ ve subnet | Global VPC / regional subnet | Regional VPC / zonal subnet | Regional VNet / VNet subnet |
| Trafik kontrolü | VPC firewall rules ve firewall policy seçenekleri | Security groups; gerektiğinde network ACL | Network Security Groups; ihtiyaç halinde Azure Firewall |
| Hibrit bağlantı | Cloud VPN / Cloud Interconnect | Site-to-Site VPN / Direct Connect | VPN Gateway / ExpressRoute |
| Private servis erişimi | Private Service Connect ve servise uygun erişim yöntemi | VPC endpoints / AWS PrivateLink; endpoint türü önemlidir. | Private Endpoint / Azure Private Link |
Hesap ve uygulama örneği
Örnek yerel ağ 10.20.0.0/16 kullanırken üç aday cloud ortamı için çakışmayan aralıklar seçin. Uygulama sadece özel veritabanına erişsin; web girişini load balancer üzerinden sonlandırın. Yetkili yönetim ayrı yol kullansın. Planı çizdikten sonra gerçek istemciden DNS, route ve TCP/TLS bağlantısını doğrulayın.
Private database adı public IP çözülüyorsa sadece firewall kuralı eklemek sorunu açıklamaz. Private DNS görünürlüğünü ve resolver forwardingini kontrol edin. Failover testinde tünel kaybını ve uygulamanın ilk başarılı transactionını aynı saatle kaydedin.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| DNS doğru, TCP kurulamadı | Route, dönüş, firewall veya listener farklı olabilir. | Effective route ve iki uç akış kaydını port dinlemesiyle karşılaştırın. |
| Private endpoint public çözülüyor | İstemci ilgili private zoneu görmüyor olabilir. | Yetkili DNS ve istemci resolverını aynı isim için karşılaştırın. |
| Küçük paket çalışıyor, büyük aktarım duruyor | MTU veya path-MTU discovery sorunu olabilir. | Paket boyutu, retransmission ve ICMP davranışını kontrollü ölçün. |
Kabul ve doğrulama kontrolleri
- Erişimi DNS, route, güvenlik ve uygulama katmanında birlikte doğrulayın.
- CIDR çakışmasını normal ve DR yollarında kontrol edin.
- İzinli ve engelli kaynak/hedef matrisi test edin.
- Private servis adını gerçek istemciden çözümleyin.
- Yol kaybında yeni ve mevcut oturumu ölçün.
- Yönetim erişimini ve akış kaydını doğrulayın.
İlgili kavramlar
Katman 2 ve Katman 3 sınırları
VLAN ayrı bir yayın alanı oluşturur; VLANlar arası iletişimi yönlendirme ve erişim politikası belirler. Bir trunk üzerindeki VLAN listesi, access port ataması ve gateway konumu birlikte incelenmelidir. Ağ çiziminde yalnız kablo bağlantısını değil, paketlerin nerede yönlendirildiğini ve nerede filtrelendiğini gösterin. Aynı switchte bulunmak aynı yetkiye sahip olmayı gerektirmez. Bir erişimin çalışmaması halinde önce doğru VLAN ve adresi, ardından gateway, route ve politika eşleşmesini doğrulayın.
DNS önbelleği ve bağımlılık
DNS cevabı yalnız kaydın authoritative sunucudaki değerine bağlı değildir; istemci ve recursive resolver önbellekleri de sonucu etkiler. TTL değişikliği daha önce önbelleğe alınmış yanıtların ömrünü geriye dönük kısaltmaz. A/AAAA, CNAME, MX ve TXT kayıtları farklı işlevlere sahiptir. İç ve dış görünümü ayrı test edin; split DNS nedeniyle cevapların farklı olması tasarlanmış olabilir. Arıza araştırmasında kullanılan resolver, yanıt türü, TTL ve sorgu zamanını kaydedin. IP ile erişimin çalışması tek başına DNS yapılandırmasının doğru olduğunu göstermez.
MTU ve yol boyunca paket boyutu
MTU bir bağlantının taşıyabildiği paket boyutuyla ilgilidir; tünel ve kapsülleme başlıkları yararlı yük için kalan alanı azaltabilir. Küçük istekler çalışırken büyük aktarımların durması MTU sorunu gösterebilir; fakat tek başına kanıt değildir. TCP MSS ile arayüz MTU aynı kavram değildir. Yolun iki ucunu ve tünel arayüzlerini karşılaştırın. Değişikliği bütün cihazlara rastgele uygulamak yerine kontrollü testle sorunlu segmenti belirleyin; ICMP hata mesajlarının engellenmesi keşfi zorlaştırabilir.
Güven sınırı ve hata alanı
Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci sırası ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve backup birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Birincil teknik dokümantasyon
İçeriğin hazırlanması
Doz Teknoloji Teknik Ekibi. Açıklamalar ilgili sağlayıcıların teknik dokümantasyonu, ortak mimari ilkeler ve açık varsayımlı örneklerle hazırlanmıştır. Hesap ve senaryolar açıklama amaçlıdır; müşteri ortamında yapılmış test veya sonuç iddiası taşımaz. Uygulamada sürüm, bölge, servis kapsamı ve destek koşulları yeniden doğrulanmalıdır.
İlgili bulut rehberleri
Google Cloud, AWS ve Azure: Bulut Platformu Nasıl Seçilir?
İş yükü, servis modeli, veri yerleşimi, güvenlik, kurtarma ve toplam maliyet üzerinden Google Cloud, AWS ve Azure değerlendirmesi.
Bulut Kimlik ve Yetki Yönetimi: Google Cloud, AWS, Azure
İnsan ve uygulama kimlikleri, kısa ömürlü erişim, en az yetki, kaynak sınırları ve erişim doğrulaması için üç platformlu teknik rehber.
Bulut Geçişi: Google Cloud, AWS ve Azure Migration Planı
Keşif, bağımlılık analizi, servis seçimi, veri eşitleme, cutover ve rollback adımlarıyla kontrollü bulut geçişi.
Bulut Maliyeti ve FinOps: Google Cloud, AWS, Azure
Compute, storage, veri çıkışı, log ve lisans maliyetini; bütçe, rightsizing ve taahhütlerle birlikte yönetin.
Bulut Yedekleme ve Disaster Recovery: Google Cloud, AWS, Azure
Backup, replication ve HA ayrımı; bağımsız kurtarma erişimi, RPO/RTO, region kaybı ve failback testleri.
Bulut kurulum, işletim ve destek hizmetleri
Platform seçimini mevcut ürünleriniz, iş yükünüz ve işletim ihtiyaçlarınızla birlikte değerlendiriyoruz.