Amazon SOA-C02: Yüksek Erişilebilirlik, Hata Toleransı ve Felaket Kurtarma — Çalışma kılavuzu

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Şunun bir parçası: AWS SysOps Administrator Associate SOA-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.

Bu alan, bileşenler, servisler veya tüm bölgeler arızalandığında kullanılabilir ve kurtarılabilir kalan sistemlerin tasarlanmasını kapsar. Yedekleme ve anlık görüntü (snapshot) stratejilerini, replikasyon ve yük devretme (failover) desenlerini ve işletmenin RTO (Kurtarma Süresi Hedefi) ile RPO (Kurtarma Noktası Hedefi) hedeflerini karşılamak için gereken operasyonel testleri içerir. Operasyonel önemi yüksektir: kesintiler ve veri kaybı, SLA’ları, geliri ve uyumluluğu doğrudan etkiler. Etkili tasarımlar; maliyet, karmaşıklık ve kabul edilebilir veri kaybı ile kesinti riskini dengeler.

Yedekleme stratejileri, anlık görüntüler ve saklama

Yedeklemeler otomatikleştirilmeli, uygulama durumuyla tutarlı olmalı ve politikaya göre saklanmalıdır. Planları, saklama sürelerini ve yaşam döngüsü kurallarını merkezileştirmek için AWS Backup kullanın (bir vault ile yedekleme planı oluşturun, kaynak kimliği ARN’lerini veya etiketleri atayın). EBS birimleri için anlık görüntüleri zamanlamak üzere Data Lifecycle Manager (DLM) kullanın (konsol veya

undefined

); CLI ile anlık görüntü oluşturma örneği:

undefined

. RDS için otomatik anlık görüntüleri veya manuel DB anlık görüntülerini kullanın (

undefined

). Belirli bir zamana kurtarma (point-in-time recovery) için RDS otomatik yedeklemelerini etkinleştirin; saklama SLA’larını karşılamak için gelişmiş izlemeyi ve anlık görüntü saklamayı etkinleştirin.

Saklama süresi, değişmezlik ve bölgeler arası kopyalar kritik kararlardır:

Kısa RPO/RTO, sık anlık görüntüler ve kısa saklama silme pencereleri gerektirir; bu da maliyeti artırır.
Yasal düzenlemelere uygun değişmezlik için, yasal saklama (legal hold) amacıyla AWS Backup Vault Lock veya S3 Object Lock kullanın.
Bölgeler arası dayanıklılık için anlık görüntüleri kopyalayın (

undefined

) ve bölgeler arası replikasyondan önce S3 sürüm oluşturmayı (versioning) etkinleştirin.

Her zaman uygulama tutarlı bir durum yakalayın: EC2 için, anlık görüntü oluşturmadan önce dosya sistemlerini temizlemek/kilitlemek (flush/lock) için AWS Systems Manager Run Command veya betikler kullanın; veritabanları için belirli bir zaman doğrulaması (point-in-time validation) amacıyla altyapıya özgü anlık görüntüleri (RDS/Aurora) veya mantıksal yedekleri (mysqldump, pg_dump) tercih edin.

Bölgeler arası replikasyon ve felaket kurtarma desenleri

Bölgeler arası stratejiler, bölgesel bir arızanın etki alanını (blast radius) azaltır. S3 Bölgeler Arası Replikasyon (CRR), sürüm oluşturma (versioning), bir IAM replikasyon rolü ve bir replikasyon yapılandırması gerektirir (konsol veya

undefined

). RDS, bölgeler arası okuma replikalarını (read replicas) (

undefined

) ve kontrollü yük devretme ile düşük gecikmeli bölgeler arası okuma/yazma mimarileri için Aurora Global Database’i destekler. DynamoDB Global Tables, verileri bölgeler arasında eşzamansız olarak çoğaltır ve nihai tutarlılık (eventual consistency) hususları göz önünde bulundurularak çok bölgeli okumalar için uygundur.

RTO/RPO ve maliyete göre bir DR (Felaket Kurtarma) deseni seçin:

Pilot Light: Kritik verileri ikincil bir bölgeye (S3, anlık görüntüler, DB replikaları) çoğaltın ancak minimum düzeyde çalışan altyapı bulundurun; IaC şablonları aracılığıyla hızlı ölçeklendirme yapın.
Warm Standby: İkincil bölgede sürekli çoğaltılan veriler ve otomatik olarak artırılabilen küçültülmüş servislerle daha küçük bir aktif ayak izi.
Multi-Region Active-Active: Trafik yönlendirme ve çakışma çözümü ile birden çok bölgede tam yığınları (full stack) çalıştırın; küresel replikasyon gerektirir (DynamoDB global tables, Aurora Global DB, uygulama düzeyinde çakışma yönetimi).

Replikasyon tutarlılığını göz önünde bulundurun: senkron replikasyon RPO’yu en aza indirir ancak gecikmeyi artırır ve bölgeler arasında desteklenmeyebilir; çoğu bölgeler arası seçenek eşzamansızdır ve gerçekçi RPO’yu tanımlayan replikasyon gecikmesi (replication lag) yaratır.

Multi-AZ ve Multi-Region mimari seçimleri

Multi-AZ, bir bölge içinde yüksek erişilebilirlik için varsayılan yöntemdir; birçok yönetilen servis için minimum RTO ile otomatik yük devretme (failover) sağlar. RDS Multi-AZ ve Aurora, depolamayı AZ’ler arasında çoğaltır—yük devretme genellikle otomatiktir ve DNS geçişi (switch-over) kullanır. EC2 için, bulut sunucularını (instance) bir Application Load Balancer ve Auto Scaling gruplarının arkasında birden çok AZ’ye yerleştirin; sağlıksız hedefleri tespit etmek ve değiştirmek için AZ’ler arası sağlık kontrollerini (cross-AZ health checks) kullanın.

Multi-Region, bölge çapındaki arızalara karşı dayanıklılık ekler ancak karmaşıklığı artırır (veri replikasyonu, küresel yönlendirme, uyumluluk). Karar kriterleri:

Bir bölge içinde düşük gecikmeyle yüksek erişilebilirliğe ihtiyacınız olduğunda ve daha düşük maliyetle yönetilen otomatik yük devretme istediğinizde Multi-AZ kullanın.
Bölge kaybına karşı felaket kurtarma veya küresel aktif-aktif gecikme azaltma için Multi-Region kullanın.

Tasarım hususları:

DNS TTL’leri: Hızlı DNS tabanlı yük devretme için düşük TTL’ler (ör. 60s) gereklidir ancak DNS sorgu yükünü artırır.
Veri yerelliği ve uyumluluk: bazı veriler bir bölgede kalmalıdır; replikasyonu ve şifrelemeyi buna göre tasarlayın.
Maliyet vs RTO/RPO: Multi-Region aktif-aktif maliyeti artırır ancak RTO’yu en aza indirir.

Yük devretme mekanizmaları (Route53 durum denetimleri, otomatik)

Otomatik yük devretme; durum denetimleri, yönlendirme politikaları ve orkestrasyon kullanır. Route53, durum denetimlerini ve yük devretme/ağırlıklı/gecikme tabanlı yönlendirmeyi destekler. Uç noktaları (HTTP, TCP veya CloudWatch alarmları) yoklamak için Route53 durum denetimlerini ve birincil kaynak başarısız olduğunda ikincil bir kaynağa geçiş yapan bir yük devretme kayıt kümesini yapılandırın. CLI güncelleme örneği:

undefined

. DNS dışı eylemler için yük devretmeyi yönetmek (orkestrasyon) amacıyla CloudWatch alarmlarını (alarm eylemleri AWS Lambda’yı tetikler) kullanın.

Load Balancer’ları ve Auto Scaling’i Entegre Edin: ALB/NLB hedef grubu durum denetimleri sağlıksız sunucuları kaldırırken, Auto Scaling bunları otomatik olarak değiştirir. Veritabanı yük devretme için hizmet seviyesindeki mekanizmalara güvenin: RDS Multi-AZ veya Aurora otomatik yük devretme ve bölgeler arası yükseltme için okuma replikaları veya Aurora Global DB kontrollü yükseltme kullanın.

İki operasyonel model:

DNS ile yük devretme (Route53): uygulaması hızlıdır, ancak DNS TTL’sine ve istemci önbelleğine bağlıdır.
Kontrol düzlemi ile yük devretme (Lambda/Step Functions + API çağrıları): karmaşık uygulamalar için yükseltme, IP/EIP yeniden atama ve Route53 güncellemelerini öngörülebilir bir sırada yönetir.

RTO/RPO planlaması, testi ve doğrulaması

RTO, kabul edilebilir maksimum kesinti süresidir; RPO ise kabul edilebilir maksimum veri kaybıdır. Her iş yükü için ölçülebilir hedefler belirleyin ve mimari seçimlerinizi buna göre yapın: senkron replikasyon RPO’yu azaltır ancak gecikmeyi artırabilir; asenkron replikasyon maliyeti düşürür ancak potansiyel veri kaybı aralığını artırır. İş SLA’larını saklama (retention) ve replikasyon sıklığına dönüştürün: RPO = replikasyon gecikmesi + yedekleme aralığı; RTO = tespit süresi + yük devretme orkestrasyon süresi + kurtarma doğrulama süresi.

Test yapmak esastır: geri yükleme prosedürlerini, DNS ile yük devretmeyi ve uygulama bütünlüğünü doğrulayan planlı DR tatbikatları yapın. Yedeklemeleri, izole bir hesaba veya VPC’ye geri yükleyerek doğrulayın (yeniden oluşturmayı otomatikleştirmek için CloudFormation/CloudFormation StackSets veya Terraform kullanın). Testler sırasında metrikleri (DNS yayılma süresi, kurtarma noktası, uygulama seviyesi kontroller) yakalayın ve RTO’yu azaltmak için otomasyonu yineleyin.

Yaygın Hatalar ve Karar Kriterleri

Snapshot’ların kurtarılabilirlik anlamına geldiğini varsaymak: her zaman ayrı bir ortama geri yükleme yapın ve uygulama tutarlılığını doğrulayın; snapshot almadan önce veritabanı motoruna özgü snapshot’ları kullanın veya uygulamaları hareketsiz duruma getirin (quiesce).
Küresel kritik iş yükleri için tek bölgeli sistemler tasarlamak: bölgesel bir arıza müşterileri etkilediğinde Çoklu Bölge (Multi-Region) desenlerini veya ılık bekleme (warm standby) modelini seçin; veri egemenliğini (data sovereignty) göz önünde bulundurun.
Tasarımda RTO/RPO’yu göz ardı etmek: her iş yükü için RTO/RPO’yu belirleyin ve replikasyon/yedeklemeleri buna göre seçin; RPO’yu replikasyon sıklığıyla ve RTO’yu orkestrasyon otomasyonuyla eşleştirin.
Hızlı yük devretmeyi engelleyen uzun DNS TTL’leri: kritik yük devretme kayıtları için düşük TTL’ler ayarlayın ve yalnızca kararlı yönlendirme gerektiğinde küresel hızlandırma kullanın.
Bölgeler arası replikasyon için IAM/izinleri ihmal etmek: CRR, snapshot kopyalama ve yedek kasası (backup vault) erişimi doğru roller ve kaynak politikaları gerektirir; replikasyon IAM yollarını test edin.
Replikasyon gecikmesini ve durumunu izlememek: CloudWatch Metriklerini (ReplicaLag, CPU, ağ) izleyin ve eşikler RPO sınırlarına yaklaştığında uyarı ayarlayın.

Pratik Problem: Kullanım Senaryosu

AcmePayments, us-east-1 bölgesinde PCI kapsamındaki bir işlem API’sini çalıştırmaktadır ve bölgesel bir kesinti sırasında temel işlem verileri için 5 dakikadan az RTO ve sıfıra yakın RPO’ya ihtiyaç duymaktadır.

Hızlı bölgeler arası replikasyon için yazılabilir birincil veritabanı us-east-1’de ve ikincil veritabanı eu-west-1’de olacak şekilde Aurora Global Database seçerek RTO=5 dk ve RPO≈0 olarak tanımlayın.
Bölge içi yüksek erişilebilirlik (HA) için senkron/bölge başına Multi-AZ’yi (Aurora replikaları + Multi-AZ) etkinleştirin ve yük devretme yönlendirmesi için Route53 aracılığıyla durum denetimleri ve düşük TTL (60sn) ile DNS yayınlayın.
Saklama (retention) ve kasa kilidi (vault lock) ile ek bir değişmez kopya olarak bölgeler arası otomatik snapshot’ları ve AWS Backup kasa kopyalarını kullanın.
Replika yükseltmesini doğrulamak, Route53 kayıtlarını güncellemek (

undefined

), basit testler (smoke tests) çalıştırmak ve hata tespit edilirse geri almak için Step Functions ve Lambda ile yük devretme senaryosunu (playbook) otomatikleştirin. 5. Üç ayda bir, yedekleri izole bir VPC’ye geri yükleyen DR tatbikatları planlayın ve gerçek RTO ve RPO’yu ölçün, ardından otomasyon ve ölçeklendirme politikalarını iyileştirin.

Gerekçe: Düşük gecikmeli küresel bir veritabanı ürününü (Aurora Global) DNS tabanlı yönlendirme ve otomatik orkestrasyon ile birleştirmek, operasyonel adımları tekrarlanabilir ve test edilebilir tutarken katı RTO/RPO gereksinimlerini karşılar. Düzenli doğrulama, yedeklerin ve replikaların gerçekten kurtarılabilir olmasını sağlar.

← İzleme · Tüm alanlar · Dağıtım →

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