Google PCA: Ağ, Hibrit Bağlanabilirlik ve Trafik Mimarisi — Çalışma kılavuzu

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Şunun bir parçası: Google Professional Cloud Architect — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Google sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Google Cloud’da ağ, hibrit bağlantı ve trafik mimarisi; güvenli, ölçeklenebilir Virtual Private Cloud (VPC) tasarımı, güvenilir hibrit ara bağlantılar, akıllı trafik yönetimi ve sağlam gözlemlenebilirlik etrafında şekillenir. Amaç, net segmentasyon, kontrollü çıkış (egress) ve öngörülebilir hata modları ile düşük gecikmeli, dayanıklı hizmetler sunmaktır. Bu bölüm, temel Google Cloud ağ hizmetleri genelinde pratik tasarım desenlerini, ödünleşimleri ve operasyonel rehberliği özetlemektedir.

VPC Mimarisi ve Segmentasyon

• Adres planlaması ve alt ağlar

  • Alt ağ oluşturmayı ve IP adreslemeyi kontrol etmek için özel mod (custom-mode) VPC’ler kullanın. Üretimde varsayılan (default) VPC’lerden kaçının.
  • Çakışmayan RFC1918 bloklarını erkenden tahsis edin. Gelecekteki büyümeyi, yüksek erişilebilirlik topolojilerini ve hibrit genişlemeleri göz önünde bulundurun. Hizmetler (örneğin, Private Service Connect uç noktaları) ve peering/Interconnect için aralıklar ayırın.
  • Hata etki alanını (blast radius) en aza indirmek ve güvenlik duvarı yapılandırmasını basitleştirmek için büyük, düz ağlar yerine işlev veya ortam başına daha küçük alt ağları tercih edin.

• Rotalar

  • Her VPC’nin bir sistem rota tablosu vardır; rotalar en uzun ön ek eşleşmesi (longest-prefix match) ve ardından önceliğe göre değerlendirilir. Google tarafından yönetilen rotalar, harici IP’ler varsa varsayılan internet rotasını ve alt ağ rotalarını içerir. Dinamik rotalar, Cloud Router aracılığıyla şirket içi (on-premises) ağlarla değiştirilir.
  • Özel statik rotaları idareli kullanın; dayanıklılık için mümkün olan yerlerde dinamik yönlendirmeye güvenin. Kasıtlı bir kontrol mekanizması olmadıkça kara delik (blackhole) rotalarından kaçının.

• Güvenlik duvarı kuralları

  • VPC güvenlik duvarı durum bilgilidir (stateful) ve önceliğe göre değerlendirilir; sonunda örtük bir reddetme (deny) kuralı bulunur. Hedefleme için ağ etiketleri (network tags) veya hizmet hesapları (service accounts) kullanın; hizmet hesabı hedeflemesi, etiketlere göre daha güçlü kimlik garantileri sunar.
  • İzin (allow) kurallarını amaca göre (sağlık kontrolleri, katman içi, yönetici) ayırın ve bunları kaynak hizmet hesapları veya IP aralıkları ile sınırlandırın.
  • Adli analiz (forensics) ve performans analizine yardımcı olmak için kritik kurallara ilişkin güvenlik duvarı kararlarını Cloud Logging’e kaydedin.

• Hiyerarşik güvenlik duvarı politikaları ve kuruluş politikaları

  • Hiyerarşik güvenlik duvarı politikaları, kuruluş (organization) veya klasör (folder) düzeyinde uygulanır ve VPC düzeyindeki kurallardan önce değerlendirilir. Projelerin geçersiz kılamayacağı küresel koruma mekanizmaları (guardrails) (örneğin, 0.0.0.0/0 SSH’ı reddetme) belirlemek için bunları kullanın. Ön (pre) ve son (post) politikalar esneklik sağlar, ancak daha üst seviyelerdeki reddetmeler geçersiz kılınamaz.
  • Yönetişimi zorunlu kılmak için Kuruluş Politikası (Organization Policy) kısıtlamalarıyla (örneğin, harici IP oluşturmayı kısıtlama, projeler tarafından VPC peering oluşturulmasına izin vermeme) tamamlayın.

• Paylaşılan VPC (Shared VPC) ve segmentasyon

  • İş yüklerini Hizmet Projelerinde (Service Projects) yalıtırken ağ yönetimini Ana Projelerde (Host Projects) merkezileştirmek için Paylaşılan VPC kullanın. Bu desen, yinelenen çıkış (egress) yollarını azaltır, kontrolleri standartlaştırır ve hibrit geçişi (transit) basitleştirir.
  • Üretim (prod) ve üretim dışı (non-prod) ortamları ayrı Ana Projelerde veya klasörlerde yalıtın; hiyerarşik politikalar ve ayrı alt ağlar ile segmentasyonu zorunlu kılın. Yalnızca NetOps ekiplerinin Ana Proje kaynaklarını yönetebilmesi için IAM’i kısıtlayın.

• VPC Ağ Eşlemesi (VPC Network Peering)

  • Peering özel, ölçeklenebilir ve düşük gecikmelidir ancak geçişli (non-transitive) değildir. Otonom ağları veya üçüncü taraf tarafından yönetilen hizmetleri bağlamak için en iyisidir. Peering ile geçiş merkezleri (transit hubs) oluşturmaktan kaçının; geçiş için Network Connectivity Center’ı veya merkezi bir Paylaşılan VPC’yi kullanın.
  • Sınırlamalar: çakışan IP’ler olamaz; belirli rotalar (örneğin, varsayılan internet rotası) ve bazı hizmetler yayılmaz. Tasarım yaparken özel rotaların içe/dışa aktarımını (import/export) anlayın.

Ödünleşimler ve hata modları:

• Çakışan IP aralıkları, peering ve hibrit rota alışverişini engeller; yeniden numaralandırma veya NAT ile çözün.
• Aşırı izin veren güvenlik duvarı kuralları veya eksik sağlık kontrolü kuralları, kesintilere ve teşhis edilmesi zor davranışlara neden olur.
• Statik rotalar kırılgan bağımlılıklar yaratır; yük devretme (failover) için Cloud Router’ı tercih edin.

Trafik Yönetimi, DNS ve Uç Güvenliği

• Cloud Load Balancing Kalıpları

  • External HTTP(S) Load Balancer, tek bir anycast VIP ile global anycast’tir, bölgeler arası yük devretme (cross-region failover), yol ve ana bilgisayar yönlendirme (path and host routing) ve CDN/Armor entegrasyonu özelliklerine sahiptir. İnternete yönelik web ve API iş yükleri için kullanılır.
  • Internal HTTP(S) Load Balancer bölgeseldir ve bir VPC içindeki veya Private Service Connect aracılığıyla hizmetten hizmete (service-to-service) trafik için kullanılır.
  • External/Internal TCP/UDP Network Load Balancer bölgesel bir L4 yük dengeleyicidir; HTTP olmayan protokoller veya kaynak IP’nin korunmasının gerekli olduğu durumlar için kullanılır.
  • Arka uç hizmetleri (Backend services) ve Ağ Uç Noktası Grupları (Network Endpoint Groups - NEG’ler): VM havuzları için zonal örnek grubu (instance group) arka uçlarını; GKE, hibrit arka uçlar veya Cloud Run için zonal, bölgesel veya sunucusuz (serverless) NEG’leri kullanın. Her trafik sınıfı, sağlık profili veya kapasite politikası için ayrı arka uç hizmetleri oluşturun. Örnek: Eski ve yeni API sürümlerini aynı ana bilgisayar adı (hostname) altında, farklı arka uç hizmetlerine yol tabanlı yönlendirme (path routing) yaparak sunun; böylece her ikisi de dağıtılabilir ve bağımsız olarak ölçeklenebilir kalır.

• Sağlık kontrolleri (Health checks) ve sık karşılaşılan tuzaklar

  • Sağlık kontrollerine güvenlik duvarı tarafından izin verilmelidir. Harici HTTP(S) sağlık kontrolleri için arka uçlara 130.211.0.0/22 ve 35.191.0.0/16 aralıklarından gelen trafiğe izin verin. Eksik bir kural, arka uçların sağlıksız olarak işaretlenmesine ve otomatik ölçeklendirmenin (autoscaling) yük dengeleyici sinyallerine tepki vermesi durumunda VM’lerin hızla yeniden başlatılmasına neden olur.
  • Sağlık kontrolü yollarını ve portlarını container hazır olma (readiness) uç noktalarıyla hizalayın; hızlı yük devretme ile yanlış pozitifler (false positives) arasında bir denge kurmak için zaman aşımlarını ve eşikleri ayarlayın.

• DNS mimarisi

  • Yetkili bölgeler (authoritative zones) için Cloud DNS kullanın. Dahili isimler için özel bölgeler (private zones); internet isimleri için genel bölgeler (public zones) oluşturun.
  • Split-horizon DNS: Aynı isimlere sahip ayrı genel ve özel bölgeler oluşturarak dahili ve harici olarak farklı yanıtlar sunun. Bu, özel hizmet ana bilgisayar adlarını (private service hostnames) ve halka açık kayıtları güvenli bir şekilde destekler.
  • Yönlendirme (Forwarding) ve eşleme (peering) bölgeleri: Belirli alan adları için sorguları yönlendirmek üzere DNS politikaları ve sunucu politikaları kullanarak şirket içi (on-premises) DNS ile entegre olun; tekrarlama döngülerinden (recursion loops) kaçınmak için koşullu yönlendirme (conditional forwarding) kullanın.
  • Hizmet keşfi (Service discovery): Ortam ve hizmet başına tutarlı adlandırma kuralları benimseyin. GKE için, Cloud DNS ile headless hizmetleri veya Internal HTTP(S) Load Balancer ve özel DNS adları aracılığıyla hizmet uç noktalarını eşlemeyi düşünün.

• Uç önbellekleme (Edge caching) ve koruma

  • Cloud CDN, önbelleğe alınabilir içeriği uç noktalarda (edge) sunarak kaynak (origin) gecikmesini ve giden trafik (egress) maliyetini azaltır. Önbellek anahtarlarını (cache keys), TTL’leri ve negatif önbelleklemeyi (negative caching) dikkatli bir şekilde ayarlayın; kişiselleştirilmiş veya dinamik uç noktalar için önbelleklemeyi atlayın.
  • Cloud Armor, WAF, hız sınırlama (rate limiting) ve coğrafi/IP tabanlı erişim kontrolü sağlar. Güvenlik politikalarını yük dengeleyicilere ekleyin; kural isabet günlüklerini (rule hit logs) izleyin. Yaygın CVE’ler için önceden yapılandırılmış kuralları ve uygulamaya özgü tehditler için özel imzaları kullanın.
  • Yük dengeleyicide TLS sonlandırması, sertifika yönetimini merkezileştirir; mümkün olan yerlerde otomatik sertifika tedariğini ve yönetilen yenilemeleri etkinleştirin.

Operasyonel rehber:

• Sürümlenmiş API’ler: Her sürümün mavi-yeşil (blue-green) veya kanarya (canary) desenleriyle bağımsız olarak dağıtılabilmesi için ayrı arka uç hizmetlerine yol veya ana bilgisayar tabanlı yönlendirme uygulayın.
• Trafik yönlendirme politikaları aracılığıyla A/B testi için istek başlıklarını (request headers) ve çerezleri (cookies) kullanın; günlüklerin/metriklerin doğru arka uç kimliğiyle ilişkili olduğunu her zaman doğrulayın.

Hibrit Bağlantı, Özel Erişim ve Transit

• Cloud Router ve BGP

  • Cloud Router, Cloud VPN tünelleri ve Interconnect ekleri için BGP aracılığıyla şirket içi (on-premises) ağlarla dinamik olarak rota alışverişi yapar. Çok bölgeli spoke bağlantısı gerektiğinde VPC’de global dinamik yönlendirme modunu kullanın.
  • Yalnızca gerekli ön ekleri (prefix) anons edin; rota sızıntılarını (route leak) önlemek için filtreleme yapın. Birincil/yedek yolları tasarlarken MED ve öncelik etkileşimlerini anlayın.

• Cloud VPN, Dedicated ve Partner Interconnect

  • HA VPN, IPsec üzerinden SLA destekli, yedekli tüneller sağlar, Cloud Router aracılığıyla dinamik yönlendirmeyi destekler ve orta düzeyde bant genişliği ihtiyacı olan üretim (production) hibrit ortamları için uygundur.
  • Dedicated Interconnect, bir veya daha fazla konumda fiziksel 10/100 Gbps bağlantılar sağlar; Partner Interconnect ise bir servis sağlayıcı aracılığıyla benzer bir hizmet sunar. Yüksek erişilebilirlik için ayrı metro konumlarında veya ayrı uç (edge) bölgelerinde en az iki farklı interconnect kullanın.
  • Yedekli yollar ve yük devretme (failover): bölge başına iki Cloud Router ve iki şirket içi yönlendirici (router) arasında BGP ile aktif/aktif bir tasarım yapın; asimetrik yönlendirme toleransını doğrulayın.
  • Yük devretmeyi düzenli olarak test edin; istenen yakınsama (convergence) süresi için BFD zamanlayıcılarını ve sağlık eşiklerini ayarlayın.
  • Hata modları: MTU uyuşmazlığı parçalanmaya (fragmentation) ve performans cezalarına neden olur; Interconnect için uçtan uca jumbo frame’leri etkinleştirin. Yanlış yapılandırılmış rota filtreleri alt ağları kara deliğe (blackhole) çevirebilir. Tek bir bağlantı noktasına sahip (single-homed) partner devreleri yaygın bir tekil hata noktasıdır (single point of failure).

• Cloud NAT, Private Google Access ve Private Service Connect

  • Cloud NAT, harici IP’leri olmayan özel VM’lerin internete çıkış (egress) yapmasını sağlar. Port tükenmesini (port exhaustion) önlemek için en yoğun bağlantı sayılarına göre NAT IP’lerini ve port atamalarını boyutlandırın; sorun giderme için günlük kaydını (logging) etkinleştirin.
  • Private Google Access, özel VM’lerin dahili IP’ler kullanarak Google API’lerine ulaşmasını sağlar; VM erişimi için alt ağlarda ve düğüm yerel (node-local) API erişimi için GKE düğümlerinde etkinleştirin. Şirket içi istemciler için, Google API’lerinin önünde duran özel VIP’leri kullanıma sunmak amacıyla Private Service Connect for Google APIs’ı kullanın.
  • Private Service Connect for producer/consumer services, projeler arası veya kuruluşlar arası hizmet yayınlama için özel, dahili IP uç noktaları sağlar; ağları dışarıya açmadan trafiği yönlendirmek için özel DNS ile birleştirin.

• Network Connectivity Center (NCC) ve transit

  • NCC, spoke’ların VPC’ler, HA VPN’ler veya Interconnect ekleri olduğu hub-and-spoke topolojilerini mümkün kılar. Rota dağıtımını ve çoklu VPC transitini, özellikle projeler veya kuruluşlar arasında basitleştirmek için merkezi bir hub kullanın.
  • Yönetişim (governance) izin verdiğinde kuruluş içi transit için Shared VPC’yi tercih edin; esnek, çok alanlı (multi-domain) transit veya SD-WAN entegrasyonuna ihtiyacınız olduğunda NCC kullanın.
  • VPC Peering’in geçişli olmadığını (non-transitive) anlayın; transit için ona güvenmeyin. NCC veya merkezi bir güvenlik duvarı/yük dengeleyici VPC’si, transit çekirdeğini oluşturur.

Çok bölgeli seçimler, gecikme ve çıkış (egress) maliyetleri:

• RTT’yi en aza indirmek için işlem (compute) kaynaklarını kullanıcılara ve durum bilgisi olan (stateful) arka uçlara (backend) yakın yerleştirin. External HTTP(S) Load Balancing, akıllı yönlendirme ile global giriş (ingress) sağlar, ancak veritabanı replikasyon gecikmesi ve tutarlılığı uygulama kısıtlamaları olarak kalır.
• Bölgeler arası (cross-zone) trafik bir bölge içinde maliyete neden olur; bölgeler arası (cross-region) replikasyon ise çıkış (egress) ücretleri ve gecikme ekler. İnternet çıkışını ve kaynak (origin) yükünü azaltmak için Cloud CDN kullanın ve yoğun iletişim kuran (chatty) servisleri aynı yerde (co-located) tutun.
• Felaket kurtarma (disaster recovery) için, başka bir bölgedeki bir warm standby’ı, çıkış (egress) maliyetleri ve operasyonel karmaşıklığa karşı değerlendirin. Bölgeleri kapsayan yük devretme (failover) politikaları ve sağlık kontrolleri ile global yük dengelemeyi yalnızca veri düzlemi (data plane) ve kontrol düzlemi (control plane) bölgesel izolasyonu tolere edebildiğinde kullanın.

Gözlemlenebilirlik, Güvenilirlik Operasyonları ve Kontroller

• Ağ gözlemlenebilirliği

  • VPC Flow Logs: alt ağ seviyesinde etkinleştirin ve örnekleme ile meta veri seçeneklerini ayarlayın. Trafik temel çizgisi oluşturma, giden trafik analizi ve tehdit avı için kullanın. Uzun vadeli analizler için BigQuery’ye aktarın.
  • Güvenlik duvarı kurallarının günlüğe kaydedilmesi: izin verilen ve reddedilen trafiği yakalamak için kritik kurallarda etkinleştirin; yanlış yapılandırmaları tespit etmek için akış günlükleriyle ilişkilendirin.
  • Connectivity Tests: ulaşılabilirliği, rota seçimini ve güvenlik duvarı değerlendirmesini doğrulamak için kaynak-hedef yollarını modelleyin. Dağıtımdan önce yapılandırma sapmalarını tespit etmek için CI/CD’ye entegre edin.
  • Sağlık panoları: yük dengeleyici arka uç (backend) sağlığını, Cloud NAT bağlantı noktası kullanımını, Cloud Router BGP oturum durumunu ve Interconnect kullanımını izleyin. Sapmalar için uyarılar ayarlayın.

• Güvenilirlik kalıpları ve yaygın hata modları

  • Bölgesel (zonal) dayanıklılık: arka uçları en az iki bölgeye (zone) dağıtın; yönetilen örnek grupları (managed instance groups) veya çok bölgeli GKE düğüm havuzları (node pools) kullanın. Sağlık kontrollerinin ve güvenlik duvarı etiketlerinin tüm bölgelere uygulandığını doğrulayın.
  • Yönlendirme dayanıklılığı: bölgeleri aşan bağlantı için küresel dinamik yönlendirme (global dynamic routing) ve birden fazla Cloud Router kullanın. Kara delik (blackhole) senaryolarını test edin ve izlemenin rota geri çekilmelerini kapsadığından emin olun.
  • DNS dayanıklılığı: Cloud DNS ile varsayılan olarak birden fazla ad sunucusu (name server) dağıtın; hibrit ortamlar için, yönlendiricilerin (forwarders) yedekli olduğundan emin olun ve şirket içi çözümleyicilerde (on-prem resolvers) tek hata noktalarından kaçının. Yanlış taraftan yönlendirilemeyen yanıtlar döndüren bölünmüş ufuk (split-horizon) yanlış yapılandırmalarını önleyin.
  • Uç noktada güvenlik (security at the edge): kaynak (origin) sunucuları sel (flood) saldırılarından korumak için Cloud Armor hız limitleri (rate limits) uygulayın; bunun yapılmaması, otomatik ölçeklendirme fırtınalarını ve maliyet artışlarını tetikleyebilir.

• Maliyet kontrolleri

  • Bölgeler arası (cross-region) çağrıları en aza indirin, VPC içi trafik için dahili yük dengelemeyi (internal load balancing) tercih edin ve NAT giden trafik maliyetinden kaçınmak için üretici-tüketici (producer-consumer) trafiği için PSC’yi (Private Service Connect) değerlendirin.
  • Statik ve yarı statik varlıklar için Cloud CDN kullanın; önbelleğe alınabilirliği (cacheability) ayarlayın. Boşta kalan kapasite için fazla ödeme yapmaktan kaçınmak üzere Interconnect kapasitesini boyutlandırın; taahhütleri doğru boyutlandırmak için trafik verilerini kullanın.

Operasyonel kod parçacıkları:

• Yük dengeleyici sağlık kontrollerinin özel (private) arka uçlara erişimine izin verin:

undefined

• Bir alt ağda Private Google Access’i etkinleştirin:

undefined

• HA VPN için bir Cloud Router oluşturun:

undefined

Pratik Problem Senaryosu

Contoso Retail, sıfır kesintiyle sürüm yükseltme, arka ofis sistemlerine sıkı özel bağlantı ve uygulama VM’lerinde genel IP adresi olmaması özelliklerine sahip küresel bir e-ticaret API’si başlatmayı planlıyor. Çözüm, DDoS koruması, uç nokta önbellekleme (edge caching) ve iki veri merkezinden güvenilir hibrit erişim sağlamalıdır.

Yaklaşım:

1. VPC ve segmentasyonun tasarlanması

• İki bölgeye yayılmış, katman başına (web, api, veri) adanmış alt ağlara sahip, özel modda (custom-mode) bir Shared VPC Ana Projesi (Host Project) oluşturun. Gerekçe: Shared VPC, kontrolleri merkezileştirirken hizmet projeleri (service projects) ekipleri izole eder. Katman başına alt ağlar, en az ayrıcalıkla (least-privilege) güvenlik duvarı yapılandırmasına ve daha küçük hata etki alanlarına (failure domains) olanak tanır.
• İnternetten gelen SSH bağlantısını reddetmek ve giden trafiği izin verilen hedeflerle kısıtlamak için kuruluş (org) düzeyinde hiyerarşik güvenlik duvarı politikaları uygulayın. Gerekçe: Küresel koruma kalkanları (guardrails), projelerdeki yanlış yapılandırma riskini azaltır.

2. Yol tabanlı (path-based) küresel giriş (ingress) ve API sürümlemenin uygulanması

• Tek bir anycast IP ve HTTPS sonlandırma ile harici bir HTTP(S) Yük Dengeleyici dağıtın. /v1/* ve /v2/* yollarını, bölgesel zonal NEG’ler (zonal NEGs) tarafından desteklenen ayrı arka uç hizmetlerine (backend services) yönlendirmek için URL haritalarını (URL maps) yapılandırın. Gerekçe: Ayrı arka uç hizmetleri, tek bir ana bilgisayar adı (hostname) ve TLS altında her API sürümü için bağımsız dağıtım ve geri alma (rollback) imkanı sağlar.
• Cloud Armor WAF ve hız limitleri ekleyin; önbelleğe alınabilir uç noktalar (örneğin, ürün resimleri) için Cloud CDN’yi etkinleştirin. Gerekçe: Kaynak sunucuyu korur, gecikmeyi ve giden trafik maliyetlerini azaltır.

3. Arka uç ulaşılabilirliği ve sağlığının sağlanması

• Yük dengeleyici sağlık kontrollerinin beklenen portlarda api örnek gruplarına (instance groups) erişimine izin vermek için bir güvenlik duvarı kuralı oluşturun. Gerekçe: Bu olmadan, sağlık kontrolleri başarısız olur ve örnekler sağlıksız kabul edildiği için otomatik ölçekleyiciler (autoscalers) kararsız çalışabilir (thrash).
• Örnekleri bölge başına iki zone’a dağıtın; kararsız durumları (flapping) önlemek için sağlık kontrolü eşiklerini ihtiyatlı bir şekilde ayarlayın. Gerekçe: Bölgesel (zonal) çeşitlilik ve istikrarlı sağlık politikaları, kullanılabilirliği artırır.

4. Bölünmüş ufuk (split-horizon) ve hizmet keşfi (service discovery) ile DNS oluşturma

• contoso.com için genel (public) bir Cloud DNS bölgesi ve yalnızca dahili kayıtlar (örneğin, db.internal.contoso.com) için aynı adda özel (private) bir bölge oluşturun. Gerekçe: Bölünmüş ufuk, tutarlı adlandırmayı korurken dahili adların sızmasını önler.
• Şirket içi corp.local sorgularını kurumsal DNS’e yönlendirmek ve özel bölgeleri uygulama projelerine aktarmak için DNS politikalarını yapılandırın. Gerekçe: Özyinelemeli döngüler (recursion loops) olmadan hibrit sınırlar arasında sorunsuz çözümleme sağlar.

5. Yedeklilikle hibrit bağlantı kurma

• Her bölgede, her veri merkezine ikişer adet HA VPN tüneli sağlayın; her çift, BGP ile ayrı Cloud Router’lar üzerinde olsun. Kapasite ve SLA ihtiyaçları gerektiriyorsa, ayrı uç bölgelerde (edge zones) yedekli eklentilere (attachments) sahip Partner Interconnect ekleyin. Gerekçe: Birden çok çeşitli yol, yük devretme (failover) sağlar; BGP, hızlı yakınsama (convergence) ve dinamik rota alışverişi sağlar.
• Shared VPC’de küresel dinamik yönlendirme kullanın ve istenmeyen şirket içi öneklerin (prefixes) yayılmasını önlemek için rota filtreleri uygulayın. Gerekçe: Rota sızıntısı riskini azaltırken bölgeler arasında tutarlı yönlendirme sağlar.

6. Google API’lerine ve giden internete özel erişim sağlama

• Uygulama alt ağlarında Private Google Access’i etkinleştirin ve toplu işler (batch jobs) tarafından kullanılan Google API’leri için Private Service Connect uç noktalarını yapılandırın. Gerektiğinde API dışı giden trafik için Cloud NAT kullanın. Gerekçe: Arka uçlar, gerekli hizmetlere ulaşmaya devam ederken genel IP adresleri bulundurmaz; PSC, özel DNS ile ad çözümlemeyi basitleştirir.

7. Transit ve üçüncü taraf bağlantılarını merkezileştirme

• Ana Proje’de (Host Project) bir Network Connectivity Center hub’ı oluşturun; HA VPN’leri, Interconnect eklentilerini ve varsa SD-WAN uçlarını (spokes) bağlayın. Gerekçe: Hub-and-spoke transit modeli, eşleme ağlarına (peering meshes) kıyasla birden çok VPC ve harici ağ arasında rota dağıtımını basitleştirir.

8. Gözlemlenebilirlik ve koruma kalkanlarının (guardrails) uygulanması

• Uygun örnekleme ile tüm alt ağlarda VPC Flow Logs’u etkinleştirin; kritik kurallarda güvenlik duvarı günlüklerini etkinleştirin; BigQuery’ye aktarın. Yeni güvenlik duvarı veya rota değişikliklerini production’a almadan önce CI/CD’de Connectivity Tests’i kullanın. Gerekçe: Derinlemesine görünürlük, sorun giderme, kapasite planlama ve denetlenebilirliği destekler.
• Cloud Router BGP oturum kesintileri, Cloud NAT port tükenmesi, arka uç sağlık düşüşleri ve Cloud Armor kural isabetleri için uyarılar ayarlayın. Gerekçe: Hataların ve saldırıların erken tespiti, MTTR’yi (Ortalama Onarım Süresi) azaltır.

9. Performans ve maliyet için optimizasyon

• Durum bilgisi olan (stateful) hizmetleri, işlem gücüyle (compute) aynı bölgede birlikte konumlandırın; statik içeriği Cloud CDN ile uç noktada önbelleğe alın. Gerekçe: RTT’yi (Gidiş-Dönüş Süresi) ve bölgeler arası giden trafik maliyetini en aza indirir.
• Bölgeler arası (cross-zone) yoğun iletişimi tespit etmek ve yerleşimi veya hizmet sınırlarını ayarlamak için akış günlüklerini periyodik olarak gözden geçirin. Gerekçe: Gereksiz giden trafik maliyetini ve gecikmeyi azaltır.

Bu tasarım, küresel, güvenli ve sürümlenmiş yönlendirmeye sahip bir giriş (ingress), dinamik yük devretme özellikli dayanıklı hibrit bağlantı, gerekli hizmetlere özel erişim ve kapsamlı gözlemlenebilirlik sunarken, gecikme ve giden trafik maliyetlerini kontrol altında tutar.

← Veri Depolama · Tüm alanlar · Güvenlik →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Google'a göz atın →