Amazon ANS-C01: VPC Tasarımı ve Gelişmiş Ağ — Çalışma kılavuzu

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Şunun bir parçası: AWS Advanced Networking Specialty ANS-C01 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Amazon sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

VPC mimarisi ve alt ağ oluşturmanın temelleri

VPC, AWS’teki temel ağ sınırıdır ve CIDR tahsislerinizin yapısı, ardından gelen her şeyi belirler. CIDR bloklarını gelecekteki büyümeyi ve hesaplar arası bağlantıyı göz önünde bulundurarak planlayın: her hesap/bölge için büyük, çakışmayan adres alanları (örneğin her ortam için bir /16) ayırın ve iş yüklerini işleve ve kullanılabilirlik alanına göre izole etmek için /20–/24 alt ağlara bölün. EKS ve diğer konteyner platformlarının, pod ENI’leri veya ikincil IP’ler için IP adresleri tükettiğini unutmayın; AWS VPC CNI, pod IP’lerini VPC alt ağından atar ve EC2 başına ENI/IP limitleri (DescribeInstanceTypes) maksimum pod yoğunluğunu kısıtlar. IPv6’ya geçiş için, eski sistemlerle entegrasyon için IPv4’ü korurken halka açık hizmetleri IPv6’ya aktarmak amacıyla çift yığınlı (dual-stack) tasarımı tercih edin;

undefined

API çağrısıyla Amazon tarafından sağlanan bir IPv6 CIDR bloğunu ilişkilendirin ve create-subnet ile --ipv6-cidr-block seçeneğini kullanarak alt ağ düzeyinde IPv6 atamasını etkinleştirin. IPv4 çıkış (egress) trafiği için NAT kaynaklarını planlayın ve IPv6 için

undefined

ile oluşturulup VPC’ye eklenen bir Egress-Only Internet Gateway kullanın.

Rota tabloları ve alt ağ yerleşimi, topolojiyi ve dayanıklılığı zorunlu kılma yönteminizdir.

undefined

kullanarak her alt ağ amacına (genel, NAT’lı özel, Direct Connect’li özel ve yalıtılmış) göre ayrı rota tabloları oluşturun. Tek bir AZ’deki çıkış trafiği hatasını önlemek için AZ’ler arasında birden fazla NAT Gateway (veya otomatik ölçeklendirmeli NAT örnekleri) kullanın; bir Transit Gateway (

undefined

) kullanırken, şirket içi (on-premises) öneklerin yalnızca hedeflenen yerlere enjekte edilmesi için yayılan (propagated) rotalar konusunda net olun. Hesap içi hizmet keşfi için Route 53 özel barındırılan alanlarını (private hosted zones) kullanın ve sınırlar arasında DNS sızıntısını önlemek için kayıtlara ihtiyaç duyan VPC’lerle ilişkilendirin.

Anahtar hizmetler ve yapılandırma ayrıntıları

Özel bağlantı için anlaşılması gereken üç baskın yapı vardır: VPC Peering, AWS Transit Gateway ve AWS PrivateLink (arabirim VPC uç noktaları). VPC Peering (

undefined

), rota tablosu girişleri gerektiren ve geçişli yönlendirmeyi (transitive routing) desteklemeyen basit, düşük maliyetli, noktadan noktaya bir bağlantıdır. Transit Gateway (

undefined

), binlerce VPC’yi, merkezi rota kontrolünü ve hibrit bağlantı için Direct Connect Gateway ile entegrasyonu destekleyen ölçeklenebilir bir merkezdir (hub); doğu-batı (east-west) akışını kontrol etmek için Transit Gateway’deki rota tablosu yayılımını (propagation) ve rota tablosu ilişkilendirmelerini (associations) kullanın. PrivateLink (NLB destekli bir hizmeti kaydetmek için

undefined

ve arabirim uç noktaları oluşturmak için

undefined

), bir VPC’yi yönlendirmeye maruz bırakmadan hizmetleri hesaplar arasında kullanıma sunar, hizmet başına ayrıntılı güvenlik ve basitleştirilmiş güvenlik grubu kontrolleri sağlar; tüketiciler arabirim uç noktaları oluşturduğu ve trafik NIC seviyesinde kaldığı için iyi ölçeklenir.

Yük dengeleme ve istemci IP’sinin korunması, doğru yapılması gereken yaygın tasarım tercihleridir. Application Load Balancer (ALB), TLS’i sonlandırır, L7’de yönlendirme yapar (

undefined

Türü application) ve arka uçların (backend) istemci IP’sini kaydetmek için güvenmesi gereken

undefined

başlıklarını ekler. Network Load Balancer (NLB), hedef grupları için kaynak IP’leri korur ve milyonlarca bağlantıyı destekler; arka uçlara gerçek TLS geçişi (pass-through) için TCP dinleyicili (

undefined

Protokolü TCP) bir NLB kullanın ve hedefleri IP’ye göre kaydedin, böylece şifreli oturumlar pod’lara veya EC2’lere bozulmadan ulaşır. gRPC ve çok yüksek bağlantı sayıları için, pod IP’lerini doğrudan kaydetmek amacıyla hedef türü ip olan ve

undefined

AWS Load Balancer Controller ek açıklamasına (annotation) sahip bir NLB’yi EKS’nin önünde tercih edin; bu kombinasyon kaynak IP’yi korur, pod’da mTLS sonlandırmayı destekler ve otomatik ölçekleyicilerle (autoscalers) birlikte ölçeklenir.

VPC uç noktaları, AWS API’leri ve popüler hizmetler için internet çıkışını ortadan kaldırır. S3 ve DynamoDB için ağ geçidi uç noktaları (Gateway endpoints) (

undefined

ile --service-name com.amazonaws.<region>.s3), bir uç nokta önek listesine (prefix list) rotalar ekler ve ücretsizdir. Arabirim uç noktaları (Interface endpoints) (

undefined

ile --vpc-endpoint-type Interface), özel IP’lere ve güvenlik gruplarına sahip elastik ağ arabirimleri (ENI) oluşturur; saatlik ve GB başına ücretlendirilirler ancak NLB destekli bir hizmetle eşleştirildiğinde PrivateLink tarzı tüketimi ve hesaplar arası erişimi mümkün kılarlar.

Tasarım desenleri ve ödünleşimler

Hesaplar arası birçok iş birimi tarafından tüketilen merkezi bir paylaşılan hizmet için, bağlantı başına kontrol ve izolasyon gerektirdiğinizde PrivateLink ve uç nokta hizmetleri en güvenli ve ölçeklenebilir desendir. Hizmeti, paylaşılan hizmetler VPC’sinde bir Network Load Balancer arkasında barındırın, bir VPC uç nokta hizmeti (CreateVpcEndpointServiceConfiguration) oluşturun ve tüketici hesaplarının sizin onaylayacağınız arayüz uç noktaları oluşturmasını sağlayın. Bu, tam bir ağ örgüsünü (full mesh) önler ve geçişli yönlendirmeyi (transitive routing) engeller. Arayüz uç noktalarındaki güvenlik grupları ise hangi tüketicilerin bağlanabileceğini kısıtlamanıza olanak tanır. Bunun ödünleşimi, uç nokta başına maliyet ve uç nokta bağlantılarını kabul etmek ve denetlemek için gereken bir miktar yönetimsel yüktür.

Transit Gateway, geniş bağlantı, merkezi denetim ve Direct Connect üzerinden şirket içi (on-prem) ön ekleri (prefix) duyurmak için tek bir yere ihtiyaç duyan çok sayıda VPC’niz olduğunda öne çıkar (CreateTransitGatewayRoute, CreateTransitGatewayRouteTable). İstenmeyen yanal hareketleri (lateral movement) önlemek için yönlendirme tablosu segmentasyonunu ve yayılım kontrollerini kullanın; Transit Gateway, üretim trafiğini daha az güvenilir ağlardan izole edebilmeniz için rota önceliklendirmeyi ve yönlendirme tablosu ilişkilendirmelerini destekler. Bunun ödünleşimi, Transit Gateway’in trafiği merkezileştirmesi ve normalde yerel olacak VPC’ler arası trafik için maliyete neden olabilmesidir; ayrıca hata etki alanlarını (failure domains) değiştirir ve adres çakışmasını önlemek için dikkatli bir CIDR planlaması gerektirir.

Sınırlı CIDR yeniden kullanımına sahip hibrit mimariler için, sanal arayüz sayısını azaltmak amacıyla Direct Connect’i Transit Gateway ve Direct Connect Gateway (CreateDirectConnectGateway) ile birleştirmeyi düşünün. Paylaşılan fiziksel bağlantı üzerinde iş birimi başına bant genişliği izolasyonuna ihtiyacınız varsa, birden çok özel sanal arayüz (private virtual interface) yerleştirin ve VIF başına CloudWatch metriklerini (AWS/DX: BytesIn, BytesOut gibi metrik adları) izleyin ve VIF seviyesinde CloudWatch alarmları kullanın. Yoğun tüketicileri belirlemek için, S3’e veya CloudWatch Logs’a VPC Flow Logs’u (CreateFlowLogs) etkinleştirin ve Athena veya CloudWatch Logs Insights ile analiz edin; VM başına paket yakalama için, kısa süreliğine Traffic Mirroring (CreateTrafficMirrorSession) kullanın.

IPv6’nın benimsenmesi ve çift yığınlı (dual-stack) tasarımlar, NAT’a olan bağımlılığı azaltır, NAT Gateway veri işleme maliyetlerini düşürür ve istemciye yönelik adreslemeyi basitleştirir. Amazon tarafından sağlanan bir IPv6 ön ekini atamak ve IPv6 CIDR bloklarıyla alt ağlar oluşturmak için aws ec2 associate-vpc-cidr-block API çağrısını kullanın. Bazı hizmetlerin ve üçüncü taraf cihazların IPv6’ya hazır olmayabileceğine dikkat edin; arka uç sistemleri IPv4 olarak kalırken hem IPv4 hem de IPv6 istemcilerini desteklemek için yük dengeleyicilerde çift yığın (IpAddressType dualstack ile CreateLoadBalancer) kullanın.

Yaygın tuzaklar ve karar kriterleri

Kubernetes pod’larının IP adresi tüketimini göz ardı etmek, sık karşılaşılan bir hizmet kesintisi kaynağıdır. EC2 tipi başına ENI ve ikincil IP limitlerini hesaba katın ve IP kullanılabilirliğini artırmak için WARM_IP_TARGETS veya ön ek delegasyonu (prefix delegation) gibi VPC CNI ayarlarını kullanın. L7’de istemci IP’lerini koruyamamak başka bir yaygın eksikliktir: TLS’in yük dengeleyicide sonlandırılması gerekiyorsa, uygulamanın X-Forwarded-For başlığını okuduğundan ve ALB güvenlik kontrollerinin doğrudan erişimi kısıtlayarak başlıklara güvenilebilmesini sağladığından emin olmalısınız. VPC peering’in süresiz olarak ölçekleneceğini varsaymak genellikle yönetilemez ağ örgülerine yol açar; çoktan-çoğa (many-to-many) bağlantılar için Transit Gateway’i ve ayrıntılı güvenlik ve trafik izolasyonu gerektirdiğiniz yerden-çoğa (one-to-many) hizmet sunumu için PrivateLink’i tercih edin.

Güvenlik politikaları, güvenlik gruplarını ve ağ ACL’lerini ad alanı (namespace) seviyesindeki kontrollerle birlikte kullanmalıdır. Doğrudan ALB URL’leri yerine Global Accelerator üzerinden erişimi sıkı bir şekilde zorunlu kılmak için, Global Accelerator IP aralıklarıyla doldurulan (yayınlanan ip-ranges.json aracılığıyla otomatikleştirilir) AWS WAF IP setlerinin bir kombinasyonuna güvenin veya ALB’yi dahili (internal) olarak tasarlayıp önüne Global Accelerator’ın hedef aldığı bir NLB koyun ve ardından yalnızca Global Accelerator giriş kapısını (front door) dışa açın. IP tabanlı tüm kontrollerin güncellemelerini daima otomatikleştirin ve DescribePrefixLists ve düzenli ip-ranges.json alımı kullanarak doğrulayın.

Pratik Problem: Kullanım Senaryosu

Şirket: Equinox Payments. Zorluk: Equinox, binlerce eş zamanlı bağlantı için uçtan uca mTLS, Cluster Autoscaler ve HPA aracılığıyla otomatik ölçeklendirme ve günlükleme için istemci IP’lerinin korunmasını gerektiren EKS destekli bir gRPC hizmeti çalıştırıyor. Yaklaşım: 1) Pod IP’lerinin hedef olarak kaydedilmesi için service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" anotasyonunu kullanarak AWS Load Balancer Controller aracılığıyla 443 numaralı bağlantı noktasında bir TCP dinleyicisi ile yapılandırılmış bir Network Load Balancer arkasında hizmeti dağıtın; 2) TLS’i NLB’de değil pod’larda sonlandırın ve uygulamada karşılıklı TLS’i (sunucu ve istemci sertifika doğrulaması) uygulayın, sertifikalar için Kubernetes Secrets ve hedef kaydını yönlendirmek için readiness probe’ları kullanın; 3) istemci kaynak IP’lerini korumak için hedef türü olarak ip kullanın, proxy protokolünü yalnızca aracı cihazlar için gerekliyse etkinleştirin ve istemci IP’sini TCP bağlantısından yakalamak için pod tarafı günlüklemeye güvenin; 4) sağlık kontrollerini TCP veya gRPC’ye duyarlı readiness probe’ları olarak yapılandırın ve Cluster Autoscaler politikalarının ve düğüm (node) EC2 tiplerinin yeterli ENI ve IP kapasitesine sahip olduğundan emin olun; 5) bağlantı sayılarını ve VPC seviyesindeki telemetriyi izlemek için CloudWatch Container Insights ve VPC Flow Logs’u (CreateFlowLogs) uygulayın. AWS gerekçesi: TCP dinleyicili NLB, milyonlarca bağlantıya ölçeklenirken şifreli oturumları ve kaynak IP’lerini korur; ip hedef türü, pod’ların kaynak IP’yi NAT olmadan doğrudan almasına olanak tanır; mTLS’in pod’larda sonlandırılması, uçtan uca şifrelemeyi ve iki yönlü kimlik doğrulamayı karşılar; otomatik ölçeklendirme çalışır çünkü pod’un hazır olma durumu (readiness) hedef kaydını doğrudan etkiler ve NLB, bağlantı yüküyle şeffaf bir şekilde ölçeklenir.

Tüm alanlar · Hibrit Bağlantı: VPN ve Direct Connect →

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