Amazon DOP-C02: Yüksek Erişilebilirlik, Dayanıklılık ve Felaket Kurtarma — Çalışma kılavuzu

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Şunun bir parçası: AWS DevOps Engineer Professional DOP-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.

Genel Bakış

AWS’te yüksek erişilebilirlik ve felaket kurtarma, bileşen, Erişilebilirlik Alanı (AZ) veya Bölgesel arızalar durumunda kesinti süresini (RTO) ve veri kaybını (RPO) azaltmaya odaklanır. Çoklu AZ tasarımları, veri kaybı olmadan ve minimum hizmet etkisiyle AZ arızalarını absorbe eder; çoklu Bölge tasarımları ise Bölgesel kesintileri ve büyük ölçekli olayları ele alır. Aktif/aktif, aktif/pasif (warm standby) ve pilot-light stratejileri arasında seçim yapmak, işletmenin RTO/RPO hedefleri, tutarlılık gereksinimleri ve maliyet tarafından belirlenir. Bu hedeflere ulaşmak, DNS yönlendirme, işlem (compute) esnekliği, yük dengeleme, veritabanı replikasyonu/yük devretme, replikasyon/sürümleme özellikli dayanıklı nesne depolama, merkezi yedekleme ve hata enjeksiyonu yoluyla sürekli dayanıklılık doğrulaması genelinde tutarlı bir tasarım gerektirir.

RTO/RPO ve akıllı yönlendirme için mimariler

Çoklu AZ ve Çoklu Bölge:

• Çoklu AZ: Yedekli sunucuları (instance) bir yük dengeleyicinin arkasında, farklı AZ’lerdeki en az iki alt ağa yerleştirin. Senkron replikasyonlu yönetilen veritabanları kullanın (RDS Multi-AZ, Aurora Multi-AZ/cluster). Senkron depolama için RPO genellikle sıfırdır; RTO hedefleri bir dakikanın altından (Aurora) birkaç dakikaya (RDS Single-Instance Multi-AZ yük devretme) kadar değişir.
• Çoklu Bölge: Bölgesel izolasyon ve düşük gecikme süresi ile en düşük RTO için aktif/aktif veya maliyet optimizasyonlu DR için warm standby/pilot light seçin. Veri replikasyonu RPO’yu karşılamalıdır: asenkron DB kopyaları, Aurora Global Database (<1 s tipik RPO), DynamoDB global tables (çoklu Bölge, çoklu aktif) ve SLA destekli replikasyon için isteğe bağlı Replication Time Control (RTC) ile S3 Cross-Region Replication (CRR).

Route 53 yönlendirme politikaları ve sağlık kontrolleri:

• Failover yönlendirme: Aynı ad için iki kayıt oluşturun: Primary (Birincil) ve Secondary (İkincil). Primary kaydıyla bir health check (sağlık kontrolü) ilişkilendirin (veya ALB/NLB’ye yapılan alias kayıtları için “Evaluate Target Health” kullanın). Arıza durumunda trafik Secondary’ye kaydırılır. DNS önbellek gecikmesini azaltmak için TTL’yi düşük tutun (ör. 60 s) ve health check durumunu CloudWatch Alarms ile izleyin.
• Latency-based (Gecikme tabanlı) yönlendirme: Kullanıcıları ölçülen en düşük gecikme süresine sahip Bölgeye yönlendirin. Yalnızca sağlıklı uç noktaların trafik almasını sağlamak için her kayıtla health check’leri ilişkilendirin. Gerektiğinde eventual/strong consistency (nihai/güçlü tutarlılık) destekleyen çoklu Bölge yığınları ve bölgesel veri depolarıyla eşleştirin.
• Weighted (Ağırlıklı) yönlendirme: Canary sürümlerini, A/B testlerini veya “damlama” DR hazırlığını (örneğin, trafiğin %1’ini sürekli olarak ikincil ortama yönlendirme) desteklemek için trafiği yüzdelere göre bölün. Sağlıksız ağırlıkların hariç tutulması için health check’lerle birleştirin. Bölgesel bir tahliye sırasında trafiği taşımak için ağırlıkları kademeli olarak kaydırın.
• Health checks: HTTP(S)/TCP uç noktalarını veya CloudWatch Alarms’ı yoklayın. ALB/NLB alias kayıtları için, hedef grubun sağlık durumunu devralmak üzere “Evaluate Target Health” seçeneğini etkinleştirin. Health check uç noktalarını gerçek hazır olma durumunu yansıtacak şekilde tasarlayın (bağımlılıklara erişilebilir, geçişler uygulanmış). Durum bilgisi tutan (stateful) uygulamalar için, kısmen sağlıklı sunuculara yönlendirmeyi önlemek amacıyla bağımlılık kontrollerini (veritabanı, önbellek) dahil edin.

Amaca göre dayanıklılık desenleri:

• Düşük RPO, küresel olarak bir dakikanın altında RTO: Route 53 gecikme tabanlı yönlendirme ve health check’ler ile aktif/aktif, bölgeye yerel durum bilgisi tutmayan (stateless) işlem gücü, DynamoDB global tables veya Aurora Global Database, kritik nesneler için RTC ile S3 CRR.
• Orta düzey RPO (≤15 dk), RTO ≤4 saat: Küçültülmüş ikincil ortam ile warm standby, asenkron DB kopyası (RDS bölgeler arası okuma replikası veya Aurora Global), Route 53 failover yönlendirme, yük devretme anında ölçek büyütmek ve birincil yapmak için runbook’lar veya otomasyon.
• Maliyet optimizasyonlu DR: Yalnızca temel veri hizmetleri için pilot light, çağrıldığında uygulama katmanını genişletmek için kod olarak altyapı (infrastructure-as-code), replikasyon sıklığına göre belirlenen RPO, provizyon süresi ve verilerin senkronize olma süresine göre belirlenen RTO.

Elastic Load Balancing ve Auto Scaling

Elastic Load Balancing:

• Application Load Balancer (ALB): Katman 7, ana bilgisayar/yol tabanlı yönlendirme, WebSocket/HTTP/2, entegre WAF, hedef grup çerezleri aracılığıyla oturum kalıcılığı ve istek tabanlı sağlık kontrolleri. Küçülme veya dağıtımlar sırasında hedefleri sorunsuz bir şekilde boşaltmak için bölgeler arası yük dengeleme (cross-zone load balancing) ve kayıt silme gecikmesini (deregistration delay / connection draining) kullanın. Dengesiz arka uç ısınması için yavaş başlatma (slow start) ve aykırı değer tespitini (outlier detection) yapılandırın.
• Network Load Balancer (NLB): Katman 4, ultra düşük gecikme süresi, statik IP’ler/Elastic IP’ler, TLS doğrudan geçişi/sonlandırması, kaynak IP’yi korur ve uzun ömürlü bağlantıları destekler. TCP/UDP protokolleri, yüksek verimli iş yükleri veya istemci IP görünürlüğünün zorunlu olduğu durumlar için kullanın. Sağlık kontrolleri, yapılandırıldığı şekilde Katman 4/7’de TCP/HTTP/HTTPS’dir.
• Bağlantı boşaltma (kayıt silme gecikmesi): Devam eden isteklerin tamamlanmasına izin vermek için uygun bir gecikme (örneğin, 60–300 s) ayarlayın. Kullanıcı kesintisini önlemek için dağıtım ve Auto Scaling sonlandırma olaylarının bu gecikmeye uymasını sağlayın.

Auto Scaling grupları:

• Ölçeklendirme politikaları:
  • Hedef izleme ölçeklendirmesi: Bir metriği (CPUUtilization, ALB RequestCountPerTarget) hedef bir değerde tutun. Bu, web/API filoları için en basit ve en uyarlanabilir politikadır.
  • Adım ölçeklendirmesi: Metrikler eşikleri aştığında tanımlanmış adımlarla ölçeklendirme yapın. Tahmin edilebilir desenlere sahip anlık trafik artışları için kullanışlıdır.
  • Zamanlanmış ölçeklendirme: Bilinen olaylar (satışlar, lansmanlar) için önceden ölçeklendirme yaparak soğuk kapasite sorununu önleyin.
  • Tahmine dayalı ölçeklendirme: İsteğe bağlı olarak, günlük/haftalık desenler için ML kullanarak talebi tahmin edin.
• Yaşam döngüsü kancaları: Launching:Wait ve Terminating:Wait, örneklerin hazır olmasını ve sonlandırılmasını yönetmenize olanak tanır. Kancaları şu amaçlarla kullanın:
  • Örnekleri hizmete girmeden önce bootstrap etmek (SSM Automation, kullanıcı verilerinin tamamlanması, AMI hidrasyonu).
  • Kök neden analizi için sonlandırmadan önce logları ve yapıtları toplamak.
  • Hazır olma sinyallerini (ör. cfn-signal) doğrulaması gereken mavi/yeşil veya yerinde dağıtımları koordine etmek.
• Sıcak havuzlar (Warm pools): Büyüme (scale-out) gecikmesini önemli ölçüde azaltmak için örnekleri ASG’ye bağlı Durdurulmuş (Stopped) veya Çalışıyor (Running) durumunda önceden başlatılmış olarak tutun. Sıcak havuzlar, uzun bootstrap adımları (büyük paket kurulumu, model indirmeleri) ile iyi bir ikili oluşturur. Minimum ısıtılmış kapasite ve yeniden kullanım politikalarını yapılandırın. Tutarlı geçiş süreleri sağlamak için yalnızca uygulama hazır olma kontrolleri geçtiğinde kancayı tamamlamak üzere yaşam döngüsü Launching:Wait ile birleştirin.
• Dayanıklılık ayarları: Spot için Kapasite Yeniden Dengeleme’yi (Capacity Rebalance), çoklu örnek türlerini/tahsislerini, hedef grup sağlığına bağlı sağlık kontrollerini ve sağlık koruma mekanizmalarıyla güvenli kademeli güncellemeler için örnek yenilemeyi (instance refresh) etkinleştirin.

Veri katmanı dayanıklılığı, replikasyonu ve yedeklemeleri

İlişkisel veritabanları:

• RDS Multi-AZ: Farklı bir AZ’deki beklemedeki bir kopyaya (standby) senkron replikasyon; otomatik yük devretme (failover), DNS uç noktasını beklemedeki kopyaya günceller. Bu, RPO ≈ 0 ve RTO’su genellikle Multi-AZ yedeği olan Single-AZ DB örnekleri için birkaç dakika olan AZ ve örnek arızalarına karşı koruma sağlar. MySQL/PostgreSQL için daha yeni olan Multi-AZ DB kümesi, birden çok okunabilir yedek kopya ile daha hızlı yük devretme sunar.
• Okuma replikaları: Okuma ölçeklendirme ve Olağanüstü Durum Kurtarma (DR) için asenkron replikasyon. DR için Bölgeler Arası okuma replikalarını kullanın; yükseltme (promotion) manueldir (veya runbook’lar/Sunucusuz işlevlerle otomatiktir) ve RPO > 0’a neden olur. Binlog veya mantıksal replikasyonun doğru yapılandırıldığından ve replikasyon gecikmesinin (replication lag) izlendiğinden emin olun.
• Aurora: Aurora Multi-AZ (küme), birden çok AZ’deki replikalarla paylaşılan depolama kullanır; yük devretme genellikle bir dakikanın altındadır. Aurora Global Database, ikincil Bölgelere tipik olarak RPO < 1 s ve RTO < 1 dk olan depolama tabanlı fiziksel replikasyon sağlar. Sıfır veri kaybıyla geçişler için yönetilen planlı yük devretmeyi (managed planned failover) veya felaket olayları için plansız yük devretmeyi (unplanned failover) kullanın. Yazıcı/okuyucu (Writer/reader) uç noktaları topolojiyi soyutlar; uygulamalar üstel geri çekilme ile yeniden deneme (retry with backoff) mekanizmasını uygulamalıdır.

Nesne depolama ve DR:

• S3 Sürüm Oluşturma (Versioning): Üzerine yazma/silmelere karşı koruma sağlamak ve CRR’yi desteklemek için sürüm oluşturmayı etkinleştirin. Eski sürümleri daha ucuz depolamaya taşımak için yaşam döngüsü politikalarını yapılandırın ve uygun saklama sürelerini ayarlayın.
• S3 Bölgeler Arası Replikasyon (CRR): Kaynak ve hedefte sürüm oluşturma gerektirir. Bir replikasyon IAM rolü kullanın; bucket’lar hesaplar arası ise, kaynak rolüne s3:ObjectOwnerOverrideToBucketOwner ve put izinleri veren bir hedef bucket politikası ekleyin. KMS ile şifrelenmiş nesneler için, role kaynak anahtar üzerinde kms:Decrypt ve hedef anahtar üzerinde kms:Encrypt izni verin. Şunları göz önünde bulundurun:
  • Metrikler/uyarılar ile nesnelerin %99,9’unun 15 dakika içinde replike edilmesi için Replikasyon Zaman Kontrolü (RTC).
  • Gerektiğinde silme işaretçilerinin (delete markers) ve sahiplik kontrollerinin replikasyonu.
  • Mevcut nesneler için S3 Toplu Replikasyon (S3 Batch Replication).
  • SLA’lar için replikasyon metrikleri ve bildirimleri.
• DynamoDB: Çok Bölgeli/çok yazıcılı (multi-Region/multi-writer) düşük gecikme süresi ve yüksek erişilebilirlik (HA) için global tabloları kullanın. Alternatif olarak, kurtarma için Zamana Bağlı Kurtarma’yı (PITR) ve isteğe bağlı yedeklemeleri etkinleştirin.

AWS Backup ile merkezi yedeklemeler:

• Yedekleme planları: Zamanlamaları (CRON), yedekleme pencerelerini, yaşam döngüsünü (soğuk depolamaya geçiş, saklama süresi) ve diğer Bölgelere/hesaplara kopyalama eylemlerini tanımlayın. Politika tabanlı kapsama için kaynakları etikete veya ARN’ye göre atayın.
• Yedekleme kasaları (Backup vaults): Bağımsız KMS şifreleme anahtarlarına ve erişim politikalarına sahip mantıksal kapsayıcılar. WORM (Write Once, Read Many) değişmezliği ve fidye yazılımlarına karşı dayanıklı bir duruş için AWS Backup Vault Lock’u etkinleştirin. Etki alanı daraltma (blast-radius reduction) için hesaplar arası kasa kopyalarını kullanın.
• Hesaplar arası yedekleme: Organizations’da, tutarlı yönetişim için üye hesaplara yedekleme politikaları uygulayın. Merkezi bir yedekleme hesabından kopyalama/geri yüklemeye izin vermek için kasa erişim politikalarını yapılandırın. RTO’yu ölçmek ve runbook’ları doğrulamak için düzenli olarak otomatik geri yükleme tatbikatları yapın.
• Entegrasyonlar: EBS, EC2, RDS/Aurora, DynamoDB, EFS, FSx ve daha fazlasını koruyun. Zamanlamayı ve saklama süresini yasal RPO/RTO ile uyumlu hale getirin ve gerektiğinde uygulama tutarlı hareketsizleştirme (SSM öncesi/sonrası betikleri) ile koordine edin.

Kaos mühendisliği ve AWS Fault Injection Simulator (FIS)

Kaos deneyleri, HA (yüksek erişilebilirlik) ve DR (olağanüstü durum kurtarma) mekanizmalarının tasarlandığı gibi davrandığını doğrular. AWS FIS, koruma mekanizmaları (guardrails) ile kontrollü hatalar düzenler:

• Deney şablonları, eylemleri (örneğin, bir ASG’deki EC2 bulut sunucularının bir yüzdesini durdurma veya yeniden başlatma, SSM aracılığıyla CPU veya bellek stresi enjekte etme, bulut sunucularına ağ gecikmesi/paket kaybı ekleme, EKS pod’larını sonlandırma, ECS görevlerini durdurma, RDS/Aurora yük devretmeyi tetikleme) ve hedefleri (kaynak etiketleri, ARN’ler) tanımlar.
• Güvenlik kontrolleri: CloudWatch alarmı durdurma koşullarını, zaman sınırlarını, etiketler/filtreler aracılığıyla etki yarıçapı kısıtlamalarını ve ön kontrolleri belirtin. Önce üretim dışı (non-prod) ortamda, ardından sıkı koruma mekanizmaları ve iş onayı ile üretimde çalıştırın.
• Gözlemlenebilirlik: KPI’ları (hata oranı, kuyruk gecikmesi, kuyruk yaşı, replika gecikmesi) izleyin ve Auto Scaling reaksiyonları, yük dengeleyici sağlık durumu yakınsaması, Route 53 yük devretme, veritabanı yükseltme ve devre kesici (circuit breaker) davranışı dahil olmak üzere otomatik yanıtları doğrulayın.
• Sürekli dayanıklılık: Yapılandırma kaymasının (configuration drift) dayanıklılığı aşındırmasını önlemek için deneyleri işlem hatlarına (pipelines)/gameday’lere entegre edin. Geçiş anahtarları (toggles) ve güvenli dağıtımları koordine etmek için Parameter Store veya AppConfig kullanın.

Pratik Problem Senaryosu

Expedia Group, kritik rezervasyon verileri için 60 saniyenin altında RTO ve sıfıra yakın RPO sağlaması gereken, aynı zamanda Kuzey Amerika ve Avrupa’daki kullanıcılar için düşük gecikmeyi sürdürmesi gereken küresel bir seyahat arama API’si işletmektedir. Ekip, zaman zaman Bölgesel kısmi kesintiler (brownout) ve dağıtım kaynaklı istikrarsızlıklar yaşamakta ve denetçiler hesaplar arası (cross-account) değiştirilemez yedeklemeler ve belgelenmiş DR tatbikatları talep etmektedir.

Adım adım yaklaşım:

1. Çok Bölgeli, aktif/aktif yığınlar oluşturun

• ALB’lerin arkasında birden çok AZ’ye yayılan, us-east-1 ve eu-west-1’de durum bilgisi olmayan (stateless) API yığınları dağıtın. Düşük gecikmeli yönlendirme ve bir uç nokta sağlıksızsa otomatik Bölgesel kaçınma sağlamak için Route 53 gecikme tabanlı yönlendirmeyi (latency-based routing) sağlık kontrolleri ve takma ad kayıtlarında (alias records) Evaluate Target Health ile kullanın.

2. Küresel, düşük RPO’lu veri deposu

• Rezervasyon ve oturum verilerini, birincil olarak us-east-1 ve ikincil olarak eu-west-1 ile Amazon Aurora Global Database’e (MySQL uyumlu) taşıyın. Tipik RPO <1 sn ve RTO <1 dk, kesinti hedefini karşılar. Yük devretmelere tolerans göstermek için uygulama yapılandırmasında küme (cluster) ve okuyucu (reader) uç noktalarını yeniden deneme/geri çekilme (retry/backoff) ile kullanın.

3. Dayanıklı ölçeklendirme ve sorunsuz geçişler

• Her iki Bölgede de minimum kapasite ile ALB RequestCountPerTarget üzerinde Auto Scaling hedef takibini (target tracking) yapılandırın. Büyük olaylar sırasında 10 kat trafik artışını karşılamak için boyutlandırılmış warm pool’lar ve uygulama hazır olma kontrolleri geçene kadar kaydı geciktirmek için lifecycle Launching:Wait kancaları ekleyin. Ölçek küçültme (scale-in) ve dağıtımlar sırasında devam eden istekleri korumak için ALB kayıt silme gecikmesini (deregistration delay) 120 saniyeye ayarlayın.

4. Dayanıklı nesne DR’ı

• Seyahat planı belgeleri için us-east-1’den eu-west-1’e RTC ile S3 Sürüm Oluşturma (Versioning) ve CRR’yi (Bölgeler Arası Çoğaltma) etkinleştirin. Her iki Bölgede de özel bir çoğaltma IAM rolü ve KMS anahtarları kullanın; kaynakta kms:Decrypt ve hedefte kms:Encrypt izni verin. RTC metrikleri ve uyarıları, çoğaltma SLA’larına güven sağlar.

5. Kanarya (canary) ve yük devretme için DNS kontrolleri

• İkincil yolu sürekli olarak test etmek için ağırlıklı Route 53 kayıtları (eu-west-1’e %1 sabit akış) ekleyin. Sağlık kontrolleriyle birleştirildiğinde bu, beklemedeki (standby) ortamın üretime hazır olmasını sağlar ve bir krizden önce yapılandırma kaymasını yakalar.

6. Merkezi, değiştirilemez yedeklemeler

• Güvenlik ekibine ait bir yedekleme hesabında, Vault Lock ve KMS CMK’leri ile AWS Backup kasaları oluşturun. RDS, DynamoDB, EFS ve EBS için günlük yedeklemeleri ve hesaplar arası kopyaları zamanlamak üzere kuruluş düzeyinde yedekleme politikaları tanımlayın. Kaynakları Backup_Frequency etiketine göre atayın. Bu, fidye yazılımlarına karşı direnç ve görevler ayrılığı (separation of duties) sağlar.

7. Otomatik yük devretme orkestrasyonu

• Aurora birincil hata sinyallerini algılamak ve ikincil Bölgeyi yükselten ve Parameter Store’da saklanan bir uygulama uç noktasını güncelleyen bir Lambda işlevini çağırmak için bir EventBridge kuralı uygulayın. Uygulamalar, başlangıçta uç noktayı yükler ve bağlantı hatalarında yeniler, böylece manuel adımları en aza indirir.

8. AWS FIS ile kaos doğrulaması

• Şunları yapmak için FIS deney şablonları oluşturun: ASG bulut sunucularının %10’unu sonlandırmak, SSM aracılığıyla EC2’ye 150 ms gecikme ve %1 paket kaybı enjekte etmek ve Aurora yük devretmeyi tetiklemek. p95 gecikme ve hata oranı üzerindeki CloudWatch alarmı durdurma koşullarıyla koruma sağlayın. Route 53 yük devretme hızını, ASG kurtarmayı, ALB sağlık durumu yakınsamasını ve Aurora yükseltme RTO’sunu doğrulamak için aylık gameday’ler düzenleyin.

Neden bu hizmetler:

• Route 53 gecikme tabanlı ve ağırlıklı yönlendirme, hem optimum kullanıcı gecikmesi hem de DR hazırlığı için kontrollü trafik şekillendirme sağlar.
• Warm pool’lar ve lifecycle kancaları ile ALB artı ASG, soğuk başlatma cezaları veya kullanıcı kesintisi olmadan hızlı, sorunsuz ölçeklendirme sağlar.
• Aurora Global Database, minimum uygulama değişikliğiyle Bölgeler arasında sıfıra yakın RPO ve bir dakikanın altında RTO’yu benzersiz bir şekilde karşılar.
• RTC ile S3 Sürüm Oluşturma ve CRR, kritik yapılar (artifacts) için denetlenebilir, SLA destekli çoğaltma sunar.
• Hesaplar arası kasalar ve Vault Lock ile AWS Backup, uyumluluk ihtiyaçlarına uygun, değiştirilemez, merkezi olarak yönetilen yedeklemeler oluşturur.
• AWS FIS, dayanıklılık duruşunu sürekli olarak kanıtlamak ve yapılandırma kaymasının DR planını baltalamasını önlemek için güvenli, otomatik hata enjeksiyonu sağlar.

← Konteynerler ve Sunucusuz Operasyonlar · Tüm alanlar · Olay Güdümlü Mimariler ve Otomasyon →

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

Amazon'a göz atın →