Google PCNE: VPC Mimarisi, Alt Ağlar ve Adres Planlaması — Çalışma kılavuzu

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Şunun bir parçası: Google Professional Cloud Network Engineer — Ç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ış

Virtual Private Cloud (VPC), tüm Google Cloud bölgelerine yayılan, global ve mantıksal olarak yalıtılmış bir ağdır. Alt ağlar, bir VPC içindeki bölgesel yapılardır ve Compute Engine, GKE ve diğer kaynakları destekleyen IP aralıklarını barındırır. Sağlam bir VPC mimarisi; adres verimliliğini, büyümeyi ve operasyonel kontrolü dengelerken, proje içi ve projeler arası iş yükleri ile Google API’lerine yönelik düşük gecikmeli ve uygun maliyetli bağlantı sağlar.

VPC kapsamı, alt ağ mimarisi ve modlar

Global VPC, bölgesel alt ağlar
- Tek bir VPC tüm bölgelere yayılır. Alt ağlar bölge başına oluşturulur ve birincil IPv4 CIDR’larını ve isteğe bağlı ikincil aralıkları tanımlar. Sanal makineler (instance) IP’lerini bölgesel alt ağlardan alır ancak varsayılan olarak aynı VPC içinde bölgeler arasında özel olarak iletişim kurabilir.
- Dinamik yönlendirme modu
  - Bölgesel: Cloud Routers, yalnızca kendi bölgelerindeki alt ağlarla rota alışverişi yapar.
  - Global: Bir bölgedeki Cloud Routers, öğrenilen rotaları tüm bölgelere duyurur. Çok bölgeli iş yükleri veya yüksek erişilebilirlikli (HA) egress gerektiğinde global mod tercih edilir.
Otomatik mod ve özel mod karşılaştırması
- Otomatik mod, her bölge için önceden atanmış CIDR’lara sahip bir alt ağ oluşturur. Hızlı başlangıçlar için kullanışlıdır ancak büyük ölçekte esnek değildir. Özel moda dönüştürülebilir; bu dönüşüm tek yönlüdür.
- Özel mod, alt ağ oluşturma ve CIDR seçimleri üzerinde tam kontrol sağlar. Üretim ortamı adres planlaması, Shared VPC, peering ve büyüme için önerilen model budur.
- Geçiş notu: Otomatik moddan özel moda geçtikten sonra, otomatik alt ağları varsayan yapılar (artifact) veya şablonlar, özel alt ağlara referans verecek şekilde açıkça güncellenene kadar genellikle başarısız olur.
Alt ağların değişmezliği ve büyümesi
- Alt ağın bölgesi değiştirilemez; bir alt ağı bölgeler arasında taşıyamazsınız.
- Birincil IPv4 aralıkları yerinde genişletilebilir (ön ek genişletilerek), daraltılamaz ve VPC ile bağlı tüm ağlarda çakışmamalıdır.
- İkincil aralıklar eklenebilir veya kaldırılabilir (kullanımda olmamaları koşuluyla), ancak bunlar da çakışmamalıdır.

Adres planlaması: birincil/ikincil aralıklar, takma ad (alias) IP’ler, IPv6 ve özel adres alanı

Birincil ve ikincil IPv4 aralıkları
- Birincil aralık: VM arayüz adreslerini (varsayılan olarak nic0) atar. Sistem tarafından oluşturulan bir alt ağ rotası yaratır ve çoğu dahili iletişim için kullanılır.
- İkincil aralıklar: Alt ağ ile ek CIDR’ları ilişkilendirir ve VPC-native GKE kümeleri için gereklidir. İkincil aralıklar için sistem tarafından oluşturulan rotalar, Pod’lar ve Service’ler için doğu-batı bağlantısına olanak tanır.
Takma Ad (Alias) IP’ler
- Takma ad (Alias) IP’ler, bir VM NIC’inin alt ağın birincil veya ikincil aralıklarından birden fazla IP’ye sahip olmasını sağlar. Bu, sıkı IP tabanlı politika uygulanmasına, VPC-native GKE için Pod IP’leri atanmasına ve verimli IP kullanımına olanak tanır.
- GKE için, parçalanmayı en aza indirmek ve gelecekteki yeniden boyutlandırma ihtiyacını azaltmak amacıyla geniş ve kesintisiz ikincil CIDR’lar planlayın. Örnek: Düğüm başına 200 Pod’a sahip 100 düğüm ve 1500 Service için, büyüme payı bırakmak amacıyla Pod’lar için en az /17 ve Service’ler için /21’lik ikincil aralıklar ayırın.
Özel RFC 1918 tasarımı ve IP yönetimi
- Mevcut ve planlanan tüm VPC’ler, şirket içi (on-premises) ağlar ve iş ortağı ağları arasında çakışmayan bloklar seçin. Her ortam için büyük ana bloklar ayırın, ardından bölge ve işlev başına öngörülebilir alt bloklar oluşturun.
- Büyüme, ikincil aralıklar, geçiş arabellekleri (geçici çift yığın/çift NAT) ve altyapı uç noktaları (ILB VIP’leri, PSC uç noktaları) için kapasite ayırın.
- İş ortağı bağlantısı olasılığı varsa en yaygın kurumsal bloklardan kaçının; veya çakışmayı gidermek için NAT ile segmentasyon yapın.
IPv6 planlaması
- Harici IPv6: İstemci erişimi ve anycast erişilebilirliği için global load balancer’larda global harici IPv6 adresleri kullanın.
- Dahili IPv6: Mümkün olan yerlerde, VM’lere dahili IPv6 atamak için çift yığınlı (dual-stack) alt ağları etkinleştirin ve güvenlik duvarı kurallarını buna göre ayarlayın. DNS AAAA kayıtlarını planlayın ve IPv4 politikasıyla eşdeğerliği sağlayın.
- Bulut içi kontroller ve üçüncü taraf entegrasyonları için IPv4’ü koruyun; IPv6’yı load balancer’lar ve çift yığınlı (dual-stack) alt ağlar aracılığıyla kademeli olarak kullanıma alın.

Yönlendirme: örtük rotalar, özel rotalar, öncelikler, etiketler ve sonraki atlamalar

Örtük (sistem tarafından oluşturulan) rotalar
- Alt ağ rotaları: birincil alt ağ ve ikincil aralık başına bir tane, hedef CIDR’a eşittir, sonraki atlama alt ağın kendisidir.
- Varsayılan rota: varsayılan olarak varsayılan internet ağ geçidine giden 0.0.0.0/0 rotası oluşturulur; internete çıkış (egress) için harici bir IP veya NAT gerekir.
Özel rotalar ve seçim mantığı
- En uzun ön ek eşleşmesi kazanır. Birden fazla rota aynı ön ek uzunluğuna sahipse, en düşük öncelik numarasına sahip olan kazanır (varsayılan öncelik 1000).
- Etiketler ve hizmet hesapları
  - Etiketleri olmayan rotalar tüm VM’lere uygulanır. Etiket kapsamlı rotalar yalnızca eşleşen ağ etiketlerine sahip örneklere (instance) uygulanır.
  - Kimlik tabanlı güvenlik duvarı kuralları hizmet hesaplarıyla eşleşebilir; mümkün olan yerlerde etiketlerden daha hassas kontrol için bunları kullanın.
Sonraki atlamalar (Next hops)
- Özel rotalar için desteklenen sonraki atlamalar şunları içerir:
  - Varsayılan internet ağ geçidi (0.0.0.0/0 veya daha spesifik çıkış ön ekleri)
  - Örnek (Instance) (başkaları için trafiği yönlendirmek üzere IP iletimi gerektirir; sanal cihazlar için kullanılır)
  - Cloud VPN tüneli (statik rotalar)
  - Sonraki atlama olarak bölgesel dahili yük dengeleyici (ölçeklenebilir cihaz desenleri için)
- Sonraki atlamayı bir VPC eşlemesi bağlantısı olarak ayarlayamazsınız; eşleme kendi rota değişimini yönetir.
Trafik yönlendirme örneği (sanal cihaz)
- Kaynak VM’lerdeki etiketlerle kapsamı belirlenmiş, IP iletimi etkin bir örneğe (instance) sonraki atlama olarak ayarlanmış, alt ağ rotasından daha spesifik bir rota oluşturun.
- Örnek:

undefined

Harici IP’ler olmadan Google API’lerine çıkış (Egress)
- Seçenek 1: Alt ağlarda Private Google Access’i (PGA) etkinleştirin, ardından gerekirse üçüncü taraf varsayılan çıkış yolunu atlamak için Google API VIP’leri için varsayılan internet ağ geçidine özel rotalar ekleyin.
- Seçenek 2: Özel VM’lerin Google hizmetlerine çıkış yapmasını sağlamak için PGA ile birlikte Cloud NAT kullanın.
- Seçenek 3: İnternetsiz kullanım için Google API’lerine Private Service Connect kullanın; trafik Google’ın ağında kalır ve VPC’nizde özel bir RFC1918 uç noktası kullanır.
- Kısıtlı erişim için, istemcileri kısıtlı Google API VIP’lerine yönlendirin ve çıkış kontrollerini uygulayın.

Shared VPC, eşleme, yetkilendirilmiş yönetim ve hizmet hesapları

Shared VPC
- Ana proje (Host project), merkezi olarak yönetilen bir veya daha fazla VPC’ye ve alt ağa sahiptir. Hizmet projeleri (Service project), iş yüklerini seçilen paylaşılan alt ağlara bağlar.
- Yetkilendirilmiş yönetim
  - Shared VPC Yöneticisi, bağlantıları ve alt ağ paylaşımını yapılandırır.
  - Ağ Yöneticileri, ana projedeki (host project) rotaları, alt ağları ve güvenlik duvarını yönetir.
  - Hizmet projelerindeki (service project) proje düzeyinde IAM, iş yükü dağıtımını kontrol eder; etki alanını (blast radius) ve rota görünürlüğünü kısıtlamak için yalnızca gerekli alt ağları paylaşabilirsiniz.
- Hizmet hesapları
  - Ekipler arasında deterministik, kimlik odaklı kontrol için hizmet hesabı tabanlı güvenlik duvarı politikalarını tercih edin.
  - Veri erişimi için en az ayrıcalık ilkesine sahip rollerle (örneğin, Cloud Storage’dan okuma yapan bir hizmet hesabına Storage Object Viewer rolü vermek gibi) her katman ve ortam için özel hizmet hesapları kullanın.
VPC Network Peering
- Kısıtlamalar
  - Geçişli değil (Non-transitive): A↔B ve B↔C, A↔C anlamına gelmez. Gerekirse tam bir ağ (full mesh) oluşturun.
  - Eşlenen ağlar arasında çakışan IP aralıkları olamaz.
  - Değişim, alt ağ rotalarıyla (ikincil aralıklar dahil) sınırlıdır; eşleme üzerinden sonraki atlama yönlendirmesi desteklenmez.
- Ayrı VPC’lerin idari olarak farklı kalması gerektiğinde, düşük gecikmeli, özel, kurum içi bağlantı için minimum operasyonel yük ile eşlemeyi kullanın.
Hibrit bağlantı
- Departmanların hizmet projeleriyle (service project) yüksek kapasiteli bağlantıyı paylaşmak için Dedicated Interconnect ve Cloud Router’ı bir Shared VPC ana projesinde (host project) merkezileştirin.
- Dayanıklılık ve gerekli tüm bölgelere yayılım için HA VLAN eklerini, çeşitli uç konumları (edge locations), çift Cloud Router’ı ve küresel dinamik yönlendirmeyi kullanın.

Operasyonlar: genişletme, HA, özel erişim, doğrulama ve sorun giderme

Alt ağ genişletme ve taşıma kısıtlamaları
- Bir alt ağ kapasitesine yaklaştığında yerinde genişletin; çakışma olmaması için tüm bağlı ağları doğrulayın ve bağımlı GKE ikincil aralıklarının yeterli kaldığından emin olun.
- Aralıklar kuruluşlar veya iş ortakları arasında çakışıyorsa, NAT veya aşamalı yeniden numaralandırma kullanın. Çakışan VPC’leri eşleyemez (peer) veya çakışan dinamik rotaları yükleyemezsiniz.
Bölgesel yerleşim ve yüksek erişilebilirlik (HA)
- Alt ağları kullanıcılara ve verilere en yakın bölgelere yerleştirin. Atlantik ötesi kullanıcı tabanları için, us-east1 ve europe-west1’de bölgesel alt ağlara sahip tek bir VPC, VPC içinde optimum gecikme süresi ve sıfır çıkış (egress) ücreti ile doğrudan özel bağlantı sağlar.
- İş yüklerini zone’lar (bölgeler) arasında dağıtın; zone arızalarına karşı tolerans için bölgesel yönetilen örnek grupları (managed instance groups) ve bölgesel dahili/harici yük dengeleyiciler kullanın.
- Hibrit ortamlar için, her bölge veya uç konum (edge location) başına çift Cloud Router ve bağlantı (attachment) dağıtın; desteklendiği yerlerde BFD’yi etkinleştirin; yük devretme (failover) için küresel dinamik yönlendirmeyi kullanın.
Özel Google Erişimi (PGA) ve kısıtlanmış uç noktalar
- Harici IP’leri olmayan örnekleri (instance) barındıran alt ağlarda PGA’yı etkinleştirin.
- Google API’lerine izin verirken genel internet çıkışını (egress) önlemek için:
  - Varsayılan trafiği NGFW’nize (Yeni Nesil Güvenlik Duvarı) yönlendirin.
  - Google API VIP’leri için varsayılan internet ağ geçidine daha spesifik statik rotalar ekleyin veya Google API’lerine PSC uç noktaları dağıtın.
- Örnek:
  - gcloud compute networks subnets update app-subnet –region=us-central1 –enable-private-ip-google-access
Topoloji doğrulaması ve sorun giderme
- Network Intelligence Center’ı kullanın:
  - Erişilebilirliği doğrulamak ve yönlendirme, güvenlik duvarı ve ağ geçidi kararlarını simüle etmek için Bağlantı Testleri’ni (Connectivity Tests) kullanın.
  - Yolları ve sağlık durumunu görselleştirmek için Performans Panosu (Performance Dashboard) ve Topoloji’yi (Topology) kullanın.
- Günlükler ve telemetri:
  - Arayüz başına izin/red (allow/deny) durumlarını ve gecikmeyi gözlemlemek için VPC Akış Günlükleri’ni (VPC Flow Logs) kullanın.
  - Kural eşleşmelerini doğrulamak için Güvenlik Duvarı Kuralları Günlüğü’nü (Firewall Rules Logging) kullanın.
  - Harici IP’ler olmadan yaşanan çıkış (egress) sorunları için Cloud NAT günlüklerini ve sağlık durumunu kontrol edin.
  - Arka uç (backend) hazır olma durumunu kontrol etmek için yük dengeleyici ve sağlık kontrolü (health-check) günlüklerini kullanın.
- CLI kontrolleri:
  - Geçerli ilkeyi doğrulamak için gcloud compute routes list ve gcloud compute firewall-rules list komutlarını kullanın.
  - Test VM’lerinden traceroute ve curl komutlarını çalıştırın; gerektiğinde derinlemesine inceleme için paket yansıtma (packet mirroring) kullanın.

Pratik Problem Senaryosu

Acme Retail Group’un; merkezi kontrole sahip, özel örnekler (private instance) için Google API’lerine internetsiz erişim sağlayan, iletişim kurması gerekmeyen departmanlar arasında sıkı bir izolasyon sunan, çok bölgeli ve düşük gecikme süreli bir Google Cloud ağına ihtiyacı var. Bazı ekipler, yüksek Pod yoğunluğuna sahip GKE kullanıyor. Acme ayrıca genel çıkış (egress) trafiğini üçüncü taraf bir güvenlik duvarı üzerinden yönlendiriyor ancak Google API trafiğinin bu güvenlik duvarını atlamasını istiyor.

Bir ana makine projesinde (host project), küresel dinamik yönlendirme (global dynamic routing) ile özel modda (custom mode) tek bir Shared VPC oluşturun ve GKE için ayrılmış ikincil aralıklara sahip us-east1 ve europe-west1 bölgelerinde bölgesel alt ağlar yaratın.

Gerekçe: Tek bir VPC, optimum verimlilik için RFC1918 adresleri üzerinden özel, sıfır maliyetli, bölgeler arası bağlantı sağlar. Özel mod ve küresel dinamik yönlendirme, hassas IP planlamasını ve çok bölgeli rota yayılımını destekler.

Her departmanın hizmet projesi (service project) ile yalnızca ihtiyaç duyulan belirli alt ağları paylaşın; üç hizmet projesi (Satış, Finans, Pazarlama) oluşturun ve her birine yalnızca gerekli alt ağları sunun.

Gerekçe: Alt ağ bazında paylaşım, etki alanını (blast radius) ve rota maruziyetini sınırlar, böylece merkezi operasyonları mümkün kılarken izolasyonu zorunlu kılar. Devredilmiş IAM (Delegated IAM), merkezi ağ yöneticilerinin güvenlik duvarlarını ve rotaları yönetmesine olanak tanırken, uygulama ekiplerinin iş yüklerini bağımsız olarak dağıtmasını sağlar.

İletişim kurması gereken departmanlar için, adanmış VPC’lerini eşleyin (peer) veya onları aynı Shared VPC alt ağlarına yerleştirin; izole kalması gereken departmanlar için eşlemeden kaçının ve çakışan alt ağları paylaşmayın.

Gerekçe: VPC Eşleme (Peering), minimum operasyonel yük ile düşük gecikmeli özel bağlantı sağlar. Geçişsizlik (Non-transitivity) özelliği, yalnızca gerektiği yerlerde açık örgü (mesh) bağlantıları gerektirir, bu da varsayılan olarak izolasyonu korur.

Tüm paylaşılan alt ağlarda Özel Google Erişimi’ni (Private Google Access) etkinleştirin ve Google API’leri için Private Service Connect (PSC) uç noktaları dağıtın; üçüncü taraf bir güvenlik duvarına giden varsayılan rotayı koruyun, ayrıca Google API VIP’leri için varsayılan internet ağ geçidine daha spesifik statik rotalar ekleyin.

Gerekçe: PGA ve PSC, özel VM’lerden internetsiz API tüketimi sağlar. Daha spesifik rotalar, Google dışı internet çıkış (egress) trafiği denetim yolundan geçmeye devam ederken, API trafiğinin NGFW’yi atlamasını sağlar.

Büyüme payı bırakarak birincil ve ikincil CIDR’lar ayırın: GKE için, yoğun olan her bölge başına bir Pod ikincil aralığı (örneğin, /17) ve bir Servisler ikincil aralığı (/21) boyutlandırın; Pod’lar ve Servisler için takma ad IP’leri (alias IPs) kullanın ve bu aralıklara bağlı VPC yerel (VPC-native) kümeler oluşturun.

Gerekçe: İkincil aralıklar ve takma ad IP’leri, düğüm (node) IP’lerinin tükenmesini önler ve yoğun zamanlamaya (dense scheduling) olanak tanır. Gelecekteki talep için boyutlandırma yapmak, kesintiye neden olan yeniden boyutlandırma ve ikincil aralıkların yeniden numaralandırılması işlemlerini önler.

Hibrit ve cihaz (appliance) trafiği için Yüksek Erişilebilirlik (HA) uygulayın: Gerektiğinde çift Cloud Router ve HA VPN veya Interconnect dağıtın; trafiğin bir sanal cihaz (virtual appliance) üzerinden yönlendirilmesi gereken durumlarda, sonraki atlama noktası (next hop) olarak bölgesel bir dahili yük dengeleyiciye veya IP yönlendirme (IP forwarding) özelliği etkinleştirilmiş ve etiket kapsamlı uygulanabilirliğe sahip bir örneğe (instance) ayarlanmış daha spesifik bir özel rota kullanın.

Gerekçe: Uç noktada (edge) HA, arızalar sırasında sürekliliği sağlar. Rotaları etiketlere göre kapsamlama, yanlışlıkla trafik geri dönüşünü (hairpinning) önler ve yalnızca seçili örneklerin (instance) cihaz yolundan geçmesine izin verir.

Network Intelligence Center Bağlantı Testleri (Connectivity Tests), VPC Akış Günlükleri (VPC Flow Logs) ve Güvenlik Duvarı Kuralları Günlüğü (Firewall Rules Logging) ile doğrulama ve operasyon yapın; hizmet hesaplarını (service accounts) kullanarak kimlik tabanlı güvenlik duvarı ilkeleri uygulayın ve bölge ve işlev başına ayrılmış arabelleklerle IPAM (IP Adres Yönetimi) kayıtlarını sürdürün.

Gerekçe: Proaktif doğrulama, değişiklikler sırasında kesintileri önler. Kimlik tabanlı ilkeler, yalnızca etiket tabanlı yaklaşımlardan daha sağlamdır. IPAM disiplini, eşlemeyi (peering) engelleyecek veya öğrenilen rotaları bastıracak çakışmaları önler.

Tüm alanlar · Güvenlik Duvarı Politikası →

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