Amazon SAP-C02: Ağ ve Hibrit Bağlantı — Çalışma kılavuzu

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Şunun bir parçası: AWS Solutions Architect Professional SAP-C02 — Ç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 segmentasyon desenleri

VPC topolojisi tasarlamak, etki alanı (blast radius) yönetimi ve öngörülebilir yönlendirme ile başlar. Küçük dağıtımlar için birden fazla alt ağa (subnet) ve katı güvenlik gruplarına (security groups) sahip tek bir VPC verimli olabilir, ancak ekipler ve uygulamalar büyüdükçe tek VPC deseni kırılgan hale gelir: kaynak kotaları, ekipler arası yönetişim ve gürültülü komşular (noisy neighbors) operasyonel riski artırır. Ekip başına çoklu VPC veya ekip başına hesap modeli, izolasyonu ve IAM sınırlarını iyileştirir; ekipler için ayrı hesaplar ve DNS, günlükleme (logging) ve kimlik (identity) için paylaşılan hizmetler hesabı ile AWS Organizations kullanın. VPC’ler arası bağlantı için VPC peering basit ve düşük gecikmelidir ancak geçişli değildir (non-transitive) ve büyük ölçekte operasyonel olarak ağırdır. Transit Gateway (TGW), “transit VPC” deseninin yerini alır: binlerce bağlantıyı (attachment) destekler, rota tablolarını merkezileştirir ve çoklu yayın (multicast) veya merkez-uç (hub-and-spoke) desenlerini basitleştirir. PrivateLink (Interface VPC Endpoints), hizmetleri internete açmadan hizmet seviyesinde izolasyon sağlar ve bu, hesaplar arası mikro hizmetler için kritik öneme sahiptir. Yaygın tuzaklar arasında segmentasyon için yalnızca güvenlik gruplarına güvenmek (bunlar durum bilgili (stateful) ve doğu-batı (east-west) filtrelemesi için kabadır), NACL’lerin durumsuz (stateless) davranışını unutmak ve CIDR tahsisini planlamamak (çakışmalar peering ve DX’i engeller) yer alır. Kararlar, maliyet ve yönetilebilirlik arasında bir dengeye dayanır: TGW’nin bağlantı maliyetleri vardır ancak peering başına karmaşıklığı azaltır; çoklu hesap izolasyonu landing zone ek yükünü artırır ancak etki alanını (blast radius) düşürür. Sürüklenmeyi (drift) önlemek için CIDR planını, rota yayılım kurallarını ve paylaşılan hizmetlerin sahipliğini daima belgeleyin.

Hibrit bağlantı, yönlendirme ve esneklik

Hibrit bağlantı seçenekleri; aktarım hızı (throughput), titreşim (jitter), gecikme (latency) ve tutarlı genel çıkış (egress) adreslemesine bağlıdır. AWS Direct Connect (DX) özel VIF’leri, büyük ve sürekli akışlar için İnternet VPN’ine kıyasla belirlenimci (deterministic) bant genişliği ve daha düşük çıkış maliyetleri sağlar; birden fazla Region’ı kapsamak için bir Direct Connect Gateway kullanın veya merkezi yönlendirme için bir Transit Gateway’e bağlayın. Site-to-Site VPN (BGP ile yönetilen IPsec), hızlı kurulum veya DX’e esnek bir yedek olarak kullanılır; asimetrik yönlendirmeyi önlemek için BGP’yi uygun ASN’ler ve rota öncelikleriyle yapılandırın. Temel yönlendirme tuzakları, şirket içi (on-prem) ve bulut CIDR’larının çakışması, TGW’de yanlış rota yayılımı ve eşlenmiş (peered) VPC’ler arasında geçişli (transitive) yönlendirmenin varsayılmasıdır. MTU ve parçalanma (fragmentation) VPN trafiğini bozabilir—yol MTU’sunu (path MTU) test edin ve cihazlarda MSS’i ayarlayın. Çoklu bölge (multi-region) için, birden fazla konumda aktif/aktif DX veya DX ile VPN yük devretme (failover) kombinasyonunu düşünün. Artıları ve eksileri: adanmış DX bağlantıları daha maliyetlidir ancak titreşimi (jitter) ve çıkış ücretlerini azaltır; VPN daha ucuz ve basittir ancak yüksek aktarım hızında daha az kararlıdır. Öngörülebilir yük devretme için iki bağımsız tünel, ayrı konumlarda yedekli DX bağlantıları ve yol seçimini ve limitleri kontrol etmek için açık TGW rota tabloları ile mimari oluşturun.

DNS, PrivateLink ve hizmet bağlantı desenleri

DNS, hibrit ve çoklu hesap ağlarının merkezindedir. VPC kapsamlı çözümleme için Route 53 Private Hosted Zones ve şirket içi (on-prem) ile AWS DNS arasında koşullu yönlendirmeyi (conditional forwarding) etkinleştirmek için Route 53 Resolver inbound/outbound uç noktalarını kullanın. Bu, dahili isimlerin özel IP’lere çözümlendiği, genel kayıtların ise küresel kaldığı bölünmüş ufuk (split-horizon) DNS’i destekler. PrivateLink (interface endpoints), trafiği genel internet üzerinden yönlendirmeden AWS hizmetlerine veya SaaS ortaklarına özel, ENI destekli bağlantı sağlar; bunu, daha ucuz olan ve ENI’lar yerine rota tablolarını kullanan S3 ve DynamoDB için Gateway Endpoints ile karşılaştırın. PrivateLink, hizmetleri VPC CIDR çakışmalarına maruz bırakmaktan kaçınır ve hizmet kabul politikalarıyla hesaplar arası tüketicileri destekler. Yaygın tuzaklar arasında özel barındırılan bölgeleri (private hosted zones) tüm tüketici VPC’leriyle ilişkilendirmeyi unutmak, şirket içi (on-prem) alan adları için Route 53 Resolver kuralları oluşturmamak ve uç nokta başına ENI IP tüketimini hafife almak yer alır. Karar kriterleri: NAT maliyetlerinden kaçınmak için yüksek aktarım hızlı S3/DynamoDB erişimi için Gateway endpoints’i tercih edin; API uç noktalarına veya daha sıkı güvenliğe sahip üçüncü taraf hizmetlere özel erişim gerektiğinde Interface endpoints kullanın. Yük devretme (failover) davranışını yönetmek için DNS gecikmesini izleyin ve TTL’leri değişiklik kontrolü (change control) ile ayarlayın.

Egress, NAT tasarımı, güvenlik kontrolleri ve operasyonel pratikler

Egress mimarisi maliyeti, denetlenebilirliği ve üçüncü taraf entegrasyonlarını etkiler. NAT Gateway, özel subnet’ler için AZ başına otomatik ölçeklendirme ile yönetilen, yüksek erişilebilirliğe sahip IPv4 egress’i sağlar; NAT Instance’lar düşük verim gerektiren kullanımlar için daha ucuzdur ancak operasyonel bakım ve yük devretme (failover) betikleri gerektirir. Egress’i bir Transit Gateway’e bağlı özel bir egress VPC aracılığıyla merkezileştirmek, tutarlı giden IP’ler, denetim noktaları ve basitleştirilmiş politikalar sağlar, ancak “hairpin routing” ve potansiyel bant genişliği darboğazları yaratır. IPv6 için Egress-Only Internet Gateway kullanın. Denetim ve genel gelen kimlik bilgilerini ortadan kaldırmak için SSH bastion’ları AWS Systems Manager Session Manager ile değiştirin; Session Manager, SSH portlarını açmadan SSM agent üzerinden çalışır. Gelişmiş filtreleme ve DPI için TGW’nin arkasına AWS Network Firewall veya üçüncü taraf cihazlar (appliance) dağıtın. Maliyet ve performans arasındaki denge: NAT Gateway’ler kolaydır ancak GB başına ücret ekler—S3 egress ve NAT maliyetlerini azaltmak için VPC endpoint’lerini kullanın. Operasyonel tuzaklar arasında trafik sorunlarını gidermek için VPC Flow Logs’u etkinleştirmemek, veri sızıntısına (data exfil) olanak tanıyan geniş egress kuralları bırakmak ve yaşam döngüsü (lifecycle) operasyonlarını istemeden engelleyen SCP’ler veya IAM politikaları kullanmak yer alır; en az ayrıcalık ilkesini (least privilege) uygulayın ve analiz için her şeyi merkezi bir hesapta günlüğe kaydedin.

Pratik Problem: Acme Finansal Hizmetler — Üçüncü Taraf Beyaz Listeye Alınması (Whitelisting) için Merkezi ve Öngörülebilir Egress

Senaryo: Acme Finansal Hizmetler, iki AWS Region’da birden fazla uygulama VPC’si çalıştırmaktadır. Bu VPC’ler bir Transit Gateway ile birbirine ve Direct Connect ile VPN üzerinden şirket içi (on-premises) veri merkezlerine bağlıdır. Ayrı hesaplardaki birkaç uygulamanın, yalnızca tek bir genel CIDR bloğundan gelen istekleri kabul eden bir iş ortağı API’sini çağırması gerekmektedir.

Zorluk: Tüm Region’lardaki uygulama VPC’leri için, gecikmeyi ve operasyonel yükü en aza indirirken, öngörülebilir tek bir genel CIDR bloğuna sahip, yüksek erişilebilirliğe sahip ve denetlenebilir bir egress yolu sağlayın.

Önerilen Yaklaşım:

1. BYOIP (Bring Your Own IP) kullanarak AWS’e genel bir IPv4 CIDR’ı getirin ve bu CIDR’dan egress adresleri olarak kullanılmak üzere Elastic IP’ler tahsis edin.
2. Her Region’da, birden fazla AZ’de NAT Gateway’ler içeren merkezi bir egress VPC oluşturun; BYOIP Elastic IP’lerini bu NAT Gateway’lerle ilişkilendirin ve egress VPC’lerini Transit Gateway’e bağlayın.
3. TGW yönlendirme tablolarını, tüm uygulama VPC’lerinin 0.0.0.0/0 trafiğini egress VPC bağlantısına yönlendirecek şekilde güncelleyin, rota yayılımını (route propagation) ve AZ’ler arasında sağlık kontrolü yapılan yük devretmeyi (failover) etkinleştirin; gerektiğinde yerel egress’i tercih etmek için şirket içi (on-prem) yönlendirmeyi yapılandırın.
4. Giden trafiği filtrelemek için egress VPC’de Network Firewall veya yönetilen bir IDS dağıtın, VPC Flow Logs ve CloudWatch alarmlarını etkinleştirin ve herhangi bir DNS yönlendirme ihtiyacı için Route 53 Resolver’ı kullanın.

Gerekçe: Egress’i TGW ve BYOIP ile sağlanan IP alanına sahip NAT Gateway’ler aracılığıyla merkezileştirmek, beyaz listeye alma (whitelisting) için öngörülebilir bir CIDR sağlarken yüksek erişilebilirliği ve merkezi izlemeyi korur. Bu yaklaşım, operasyonel basitliği, güvenlik kontrollerini ve iş ortağının tek bir genel CIDR gereksinimini dengeler.

← Organizasyonel Karmaşıklık ve Çoklu Hesap Stratejisi · Tüm alanlar · Güvenlik →

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

Amazon'a göz atın →