Amazon ANS-C01: DNS ve Route 53 — Ç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.

Temel kavram

DNS, insan dostu isimler ile dağıtık uç noktalar arasındaki yapıştırıcıdır, ancak AWS’te gecikme tabanlı yönlendirme, sağlık durumuna duyarlı yük devretme ve çoklu hesap özel ad çözümlemesi için aktif bir kontrol düzlemi haline gelir. Amazon Route 53, public hosted zone’lar aracılığıyla yetkili genel DNS’i ve private hosted zone’lar aracılığıyla VPC kapsamlı çözümleme için özel DNS’i destekler. Private hosted zone’lar bir veya daha fazla VPC ile ilişkilendirilir ve yalnızca bu VPC’lerden veya Route 53 Resolver inbound endpoint’leri aracılığıyla gelen sorgulara yanıt verir. Bu split-horizon (ayrık ufuk) davranışı—kaynağa bağlı olarak aynı ad için farklı yanıtlar verme—VPC’leriniz içinde aynı adı özel IP’lere çözerken internet istemcileri için genel bir uç nokta açmanıza olanak tanır.

Route 53 ayrıca yönlendirme karar mantığını ve aktif sağlık kontrollerini DNS’e entegre eder. Yönlendirme politikaları arasında Simple, Weighted, Latency, Failover (birincil/ikincil), Geolocation ve Multi-Value Answer ile Traffic Flow (coğrafi yakınlık ve karmaşık akışlar) bulunur. CreateHealthCheck ile oluşturulan sağlık kontrolleri, Route 53’ün sağlıksız uç noktaları DNS yanıtlarından kaldırmasına veya yük devretme kayıt setlerini yönlendirmesine olanak tanır; sağlık kontrolleri Type, FullyQualifiedDomainName, IPAddress, Port, ResourcePath, RequestInterval ve FailureThreshold gibi HealthCheckConfig alanlarıyla yapılandırılabilir. DNS, çözümleyiciler ve istemciler tarafından önbelleğe alındığından, Route 53’ün TTL’i ve sık sağlık kontrolü yoklaması (belirli ayarlarda minimum 10 saniye), yük devretme ve ağırlıklı yönlendirme değişiklikleri için DNS yayılma davranışına karşı dengelenmelidir.

Kilit hizmetler ve yapılandırma

AWS kaynaklarını dışa açarken, ek atlamalardan veya CNAME’lerden kaçınarak, desteklendiği yerlerde DNS’i doğrudan AWS kaynaklarına yönlendirmek için Alias kayıtlarını kullanın. Alias kayıtları, AWS kaynağının hosted zone ID’sine ve DNS adına (örneğin, bir Elastic Load Balancer, API Gateway özel alan adı, CloudFront dağıtımı veya S3 web sitesi uç noktası) referans veren bir AliasTarget kullanır. Kayıt oluşturma veya değiştirme ChangeResourceRecordSets API’si aracılığıyla yapılır; programatik iş akışları için UPSERT/DELETE eylemleriyle ChangeBatch ve yönlendirme politikası tanımlaması için SetIdentifier kullanın. Yük devretme için, aynı ada sahip ve Failover ayarı PRIMARY ve SECONDARY olarak belirlenmiş iki kayıt oluşturursunuz; her biri CreateHealthCheck ile oluşturduğunuz bir sağlık kontrolüne HealthCheckId aracılığıyla referans verir.

Hesaplar arası ve hibrit DNS çözümlemesi için Route 53 Resolver, CreateResolverEndpoint ile oluşturulan inbound ve outbound endpoint’ler sağlar. Bir inbound endpoint, şirket içi çözümleyicilerin sorguları VPC’lere iletmesine olanak tanırken (private hosted zone’ları çözümlemek için kullanışlıdır), bir outbound endpoint ise VPC kaynaklarının sorguları şirket içi DNS sunucularına veya diğer çözümleyicilere iletmesini sağlar. Resolver kuralları (CreateResolverRule), belirli alan adları için sorguları IP adreslerine iletmenize olanak tanır ve AssociateResolverRule kullanarak kuralları VPC’lerle ilişkilendirirsiniz. Merkezi bir DNS mimarisi için, merkezi bir hesapta yönlendirme kuralları oluşturabilir ve diğer hesaplardaki VPC’lerle AssociateResolverRule yapabilirsiniz; isteğe bağlı olarak ilişkilendirmeleri kontrol etmek için AWS Resource Access Manager (RAM) ve PutResolverRulePolicy kullanabilirsiniz.

Route 53 Resolver DNS Firewall, alan adı tabanlı filtreleme ve günlükleme sağlar. Alan adı listelerini CreateFirewallDomainList ile, kural gruplarını CreateFirewallRuleGroup ile oluşturur ve ardından kuralları uygulamak için VPC’lere AssociateFirewallRuleGroup yaparsınız. Firewall kuralları yanıtları BLOCK, ALLOW veya OVERWRITE edebilir ve değerlendirmeleri CloudWatch Logs veya S3’e kaydedebilirsiniz. Yönetim ve öncelikli kuralları uygulamak için, özellikle DNS yoluyla veri sızmasını sınırlamak veya VPC’ye bağlı kaynaklardan kötü amaçlı alan adlarını engellemek için CreateFirewallRule ve PutFirewallRuleGroupPolicy kullanın.

Tasarım desenleri ve ödünler

Yüksek erişilebilirliğe sahip, küresel olarak dağıtılmış hizmetler için, istemcileri en yakın sağlıklı uç noktaya yönlendirmek amacıyla gecikme tabanlı veya coğrafi tabanlı yönlendirme kullanın ve sağlıksız bölgesel uç noktaları kaldırmak için bunu sağlık kontrolleriyle eşleştirin. Gecikme tabanlı yönlendirme, Route 53’ün bölgesel gecikme tablolarına bağlıdır ve çok bölgeli aktif-aktif tasarımlar için uygundur; yük devretme yönlendirmesi ise aynı anda yalnızca bir bölgenin trafik alması gereken aktif-pasif felaket kurtarma senaryoları için daha iyidir. Ağırlıklı yönlendirme, kayıtlara ağırlık değerleri atayarak ve bunları ChangeResourceRecordSets ile değiştirerek kademeli trafik kaydırmalarını (mavi-yeşil veya kanarya dağıtımları) destekler. Çok değerli yanıt yönlendirmesi, istemci tarafında yük dağıtımı için birden fazla IP döndürebilir ve yalnızca sağlıklı IP’lerin döndürülmesini sağlamak için sağlık kontrolleri gerektirir.

Private hosted zone’lar ve resolver endpoint’ler, çoklu hesap, çoklu VPC ad çözümlemesi için kanonik desenlerdir. Birçok iş birimi için, private hosted zone’ları veya resolver endpoint’leri barındıran merkezi bir paylaşılan hizmetler VPC’si yönetimi basitleştirir: bir private hosted zone oluşturun ve hizmet VPC’lerini eklemek için AssociateVPCWithHostedZone kullanın veya her hesabın merkezi DNS politikasına dayanırken kendi VPC izolasyonunu koruması için Route 53 Resolver outbound/inbound endpoint’leri ve yönlendirme kuralları çalıştırın. Bunun ödünü, birçok VPC ile ilişkilendirilmiş private hosted zone’ların IAM ve değişiklik kontrolünü karmaşıklaştırması ve hesaplar arası ilişkilendirmelerin bir yetkilendirme adımı gerektirmesidir. Resolver yönlendirmesi merkezi bir operasyonel yük getirir ancak ölçeklenir, çünkü her VPC’yi doğrudan her hosted zone ile ilişkilendirmeniz gerekmez; bunun yerine resolver kurallarını ilişkilendirirsiniz.

Yalnızca Global Accelerator üzerinden trafik akışını gerektirmek gibi katı erişim yollarını zorunlu kılarken, güvenlik grubu ve ağ kontrollerini DNS ile eşleşecek şekilde tasarlamanız gerekir. Route 53, hızlandırıcının statik IP adresleriyle A kayıtları oluşturarak veya hızlandırıcı tarafından yönetilen bir alan adına CNAME’ler kullanarak Global Accelerator’ı işaret edebilir, ancak zorlama ALB güvenlik grubu ve ağ ACL katmanında yapılır. ALB güvenlik grubu, yalnızca Global Accelerator statik IP adreslerinden gelen trafiğe izin vermelidir; Global Accelerator, gelen trafiğin kaynağının bu statik IP’ler olacağını garanti eder, bu nedenle gelen trafiği sınırlamak, yalnızca hızlandırıcı üzerinden erişim gereksinimini korur.

Sık karşılaşılan tuzaklar ve karar kriterleri

Tipik bir tuzak, Route 53 sağlık kontrollerinin uç noktaları anında kaldırdığını varsaymaktır; DNS önbelleğe alma (TTL) ve istemci çözümleyici davranışı, yük devretmenin anlık olmadığı anlamına gelir. Kritik yük devretme adları için TTL’leri düşük tutun, ancak daha düşük TTL’lerin sorgu hacmini ve maliyeti artırdığını unutmayın. Diğer bir yaygın hata, VPC ilişkilendirmelerini anlamadan adları genel ve özel barındırılan alanlar (hosted zone) arasında çoğaltmaktır: genel bir barındırılan alanla aynı ada sahip özel bir barındırılan alan, ilişkili VPC’lerden kaynaklanan sorgular için genel yanıtları gölgeleyecektir; bu durum genellikle split-horizon (ayrık ufuk) için arzu edilir ancak belgelenmemişse şaşırtıcı olabilir.

Alias ve CNAME kayıtları arasında dikkatli seçim yapın: ELB ve CloudFront için Alias kayıtları tercih edilir çünkü ekstra DNS aramalarını önlerler ve Route 53’ün değişiklik yayma mantığı tarafından desteklenirler, ancak AWS kaynaklarının barındırılan alan kimliklerine (hosted zone ID) bağlıdırlar ve rastgele harici uç noktalar için kullanılamazlar. Hesaplar arası DNS tasarlarken, ölçek veya idari sınırlar söz konusu olduğunda, birçok VPC’yi tek bir özel barındırılan alana doğrudan bağlamak yerine çözümleyici kurallarını (resolver rules) ve uç noktalarını (endpoints) tercih edin; çözümleyici kuralları daha ayrıntılı kontrol sağlar ve CloudTrail ile denetlenmesi daha kolaydır.

Pratik Problem: Kullanım Senaryosu

Şirket: NimbusPay — problem: Bir EKS arka ucuna (backend) karşılıklı TLS (mutual TLS) ile TLS üzerinden güvenli, düşük gecikmeli gRPC hizmetleri sağlamak, web ön yüzüne (front-end) erişimi yalnızca Global Accelerator üzerinden zorunlu kılmak ve hesaplar arası birden fazla iş birimi VPC’sinin merkezi DNS kontrolleriyle paylaşılan veri hizmetlerini kullanmasına izin vermek.

Uçtan uca TLS ile karşılıklı kimlik doğrulama ve binlerce eş zamanlı bağlantı gerektiren gRPC hizmeti için, pod IP’lerinin doğrudan kaydedilmesi amacıyla hedef türü (target type) ip kullanarak 443 numaralı bağlantı noktasında TCP dinleyicileri (listener) olan bir Network Load Balancer (NLB) dağıtın. AWS Load Balancer Controller ek açıklamalarını (annotations)

undefined

olarak yapılandırın ve hedef grup (target group) protokolünü TCP olarak ayarlayın; karşılıklı TLS’nin (mutual TLS), sunucu sertifikalarının ve istemci sertifikası doğrulamasının zorunlu kılındığı pod konteynerlerine iletilmesi için TLS’yi NLB’de sonlandırmayın (TLS dinleyicisi olmasın).

undefined

aracılığıyla NLB’ye işaret eden Route 53 A kayıtlarını (Alias) kullanın; yalnızca hızlı yük devretmeye ihtiyacınız varsa düşük TTL’leri tercih edin, aksi takdirde DNS kararlılığı için muhafazakar bir TTL tutun.

Web ön yüzü ALB’sinin yalnızca Global Accelerator’dan gelen trafiği kabul etmesini sağlamak için bir accelerator oluşturun ve iki statik IP adresini NimbusPay’e atayın. Genel adı accelerator IP’lerine çözümlemek için Route 53 genel kayıtlarını yapılandırın (statik IP’lerle A kayıtları). ALB’de, güvenlik grubu giriş (ingress) kurallarını yalnızca bu statik IP adreslerine izin verecek şekilde ayarlayın ve

undefined

adresini kapatın. Bu, ALB’ye yalnızca accelerator statik IP’lerinden gelen trafiğin ulaşabilmesini zorunlu kılar. Gelen kaynak IP’lerini doğrulamak ve accelerator dışı trafiğin engellendiğini denetlemek için CloudWatch Logs ve VPC Flow Logs’u kullanın.

Paylaşılan hizmetlere erişmesi gereken hesaplar arası birden fazla iş birimi VPC’si için, paylaşılan hizmetler hesabında

undefined

kullanarak merkezi bir Route 53 Resolver giden/gelen (outbound/inbound) uç nokta çifti dağıtın ve uç noktaları özel alt ağlara (private subnets) yerleştirin. Paylaşılan hizmet alan adları (domain) için paylaşılan hesapta yönlendirme kuralları (

undefined

) oluşturun ve kuralları AWS RAM kullanarak paylaşın veya ilişkilendirmelere izin vermek için

undefined

kullanın. Her iş birimi, çözümleyici kuralını kendi VPC’leriyle ilişkilendirir (

undefined

), bu da tüm VPC’leri doğrudan özel barındırılan alanlara (private hosted zones) bağlamadan ad çözümlemesini mümkün kılar. Hassas kontroller için, istenmeyen veri sızıntısını engellemek veya alan adı izin listelerini (domain allowlists) zorunlu kılmak amacıyla paylaşılan VPC’ye Route 53 Resolver DNS Firewall kural grupları (

undefined

) ekleyin. Gerekçe: NLB TCP geçişi (passthrough), karşılıklı TLS’yi korur ve çok sayıda eş zamanlı bağlantıya ölçeklenir; ALB girişini Global Accelerator statik IP’leriyle sınırlamak, yalnızca accelerator üzerinden erişimi zorunlu kılar; ve merkezi olarak yönetilen kurallara sahip çözümleyici uç noktaları, hesap başına IAM sınırlarını ve denetimi korurken hesaplar arası DNS çözümlemesini ölçeklendirir.

← Transit Gateway ve Ağ Topolojisi · Tüm alanlar · Yük Dengeleme ve Trafik Yönetimi →

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