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

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Şunun bir parçası: AWS SAA-C03 — Eksiksiz ç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.

Multi-AZ Dağıtımları ve Replikasyon

Multi-AZ mimarileri, tek bir veri merkezinin veya Erişilebilirlik Alanının (AZ) arızasını ele alır — daha fazlasını değil. Bu ayrım, yüksek erişilebilirlik tasarımında en yanlış anlaşılan noktadır. Bir Multi-AZ dağıtımı, bir Bölge (Region) içindeki bir AZ’nin kaybını tolere eder; ancak Bölge çapında bir kesintiyi, bölgesel bir hizmet bozulmasını veya bir kaynağın yanlışlıkla silinip bu silme işleminin anında yedeğe (standby) replike edilmesini tolere etmez. Replikasyon, hatalı verileri — mantıksal bozulma, şema hataları, fidye yazılımı yazmaları — sadakatle yayar. Bu nedenle replikasyon ve yedekleme birbirinin yerine geçmez, birbirini tamamlar.

Amazon RDS için Multi-AZ, farklı bir AZ’de senkron bir yedek (standby) replika sağlar. Yazma işlemleri, onaylanmadan önce her iki örnekte (instance) de işlenir (commit), bu da RPO’yu etkin bir şekilde sıfıra ve otomatik yük devretme sırasında RTO’yu genellikle 60-120 saniyeye indirir. Klasik Multi-AZ örnek (instance) dağıtımında yedek okunamaz — tamamen dayanıklılık ve yük devretme için mevcuttur. Multi-AZ küme (cluster) dağıtımları (iki okunabilir yedek) yük devretme süresini daha da azaltır ve bir miktar okuma ölçeklendirmesi sağlar, ancak yine de kendilerini tek bir Bölge ile sınırlar.

Okuma ölçeklendirmesi için okuma replikaları (read replicas) ekleyin. Okuma replikaları asenkron replikasyon kullanır ve raporlama, analiz ve pano sorgularının yükünü hafifletmek için vardır. Bir okuma replikasını bir HA yük devretme mekanizması olarak görmek üç açıdan yanlıştır: replikasyon asenkrondur (yükseltme sırasında veri kaybı), yükseltme manuel veya betiklenmiştir (otomatik değildir) ve birincil uç nokta (endpoint) korunmaz. Büyüyen bir iş yükü yeni bir karmaşıklık olmadan daha fazla okuma kapasitesine ihtiyaç duyduğunda bir okuma replikası ekleyin; gereksinim sıfır veri kaybıyla otomatik yük devretme olduğunda Multi-AZ kullanın. İlişkisel bir motor için RPO/RTO’nun bir Bölge arızasından kurtulması gerektiğinde, Aurora Global Database saniyenin altında bölgeler arası replikasyon gecikmesi ve bir dakikanın altında yönetilen yük devretme RTO’su sağlar.

Amazon ElastiCache, replikasyon gruplarıyla aynı modeli izler. Multi-AZ etkinleştirilmiş bir Redis replikasyon grubu, AZ’ler arasında bir birincil (primary) ve bir veya daha fazla replika tutar; birincil başarısız olursa, ElastiCache bir replikayı yükseltir ve birincil uç noktayı günceller. Yatay ölçeklendirme için Redis (küme modu etkin), verileri her biri kendi replikasyon grubu olan shard’lar arasında bölümler. Buna karşılık Memcached, replikasyon yapmaz — düğüm kaybı, o bölüm için veri kaybı anlamına gelir.

Amazon FSx, tercih edilen ve yedek bir dosya sunucusu arasında senkron replikasyon kullanarak FSx for Windows File Server ve FSx for ONTAP için Multi-AZ dağıtım türleri sunar. FSx for Lustre genellikle tek AZ’lidir (scratch veya persistent); Lustre için dayanıklılık, AZ replikasyonundan değil, S3 veri deposu ilişkilendirmelerinden gelir.

# RDS Multi-AZ with cross-Region read replica for DR
DBInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    Engine: sqlserver-ee
    MultiAZ: true              # AZ-level HA (synchronous)
    BackupRetentionPeriod: 35
    CopyTagsToSnapshot: true
    DeletionProtection: true

RDS Otomatik Yedeklemeleri ve Belirli Bir Zamana Kurtarma

RDS otomatik yedeklemeleri, günlük bir snapshot’ı S3’e sürekli 5 dakikalık işlem günlüğü (transaction log) yüklemeleriyle birleştirerek, 1-35 günlük saklama penceresi içinde herhangi bir saniyeye belirli bir zamana kurtarma (PITR) imkanı sunar. RPO’nuz 2 saat ise, RDS’in yerel yedeklemeleri bunu zaten karşılar — ek bir snapshot zamanlaması gerekmez ve RDS snapshot kopyalamanın sağladığının ötesinde bölgeler arası kopyalara, hesaplar arası izolasyona veya Vault Lock semantiğine ihtiyacınız yoksa, üzerine AWS Backup katmanı eklemek gereksizdir. Varsayılan otomatik yedekleme, mütevazı RPO gereksinimleri için genellikle en ucuz doğru cevaptır.

Merkezi Kontrol Düzlemi Olarak AWS Backup

AWS Backup; EBS, EC2 (AMI olarak), RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway, S3 ve daha fazlası için yedeklemeyi yöneten, ilke tabanlı kontrol düzlemidir. Hizmete özgü snapshot mantığını betiklemek yerine, sıklığı, yedekleme penceresini, başlama/tamamlanma pencerelerini, soğuk depolamaya yaşam döngüsü geçişlerini, saklama süresini ve hedef kasaları (vault) tanımlayan kuralları gruplayan yedekleme planları (backup plans) tanımlarsınız. Kaynaklar, etiket veya ARN aracılığıyla kaynak atamaları (resource assignments) ile kaydedilir, böylece Backup=Daily gibi bir etiketleme kuralı, kapsamı yöneten operasyonel sözleşme haline gelir. Yüzlerce EC2 örneğinden oluşan filolar için, etiket tabanlı seçim en az çaba gerektiren yaklaşımdır — örnek başına zamanlama yazmak yerine etiketi uygulayın ve AWS Backup’ın listelemesine izin verin.

Bir yedekleme kasası (backup vault), kurtarma noktalarının yaşadığı KMS ile şifrelenmiş kapsayıcıdır. Erişim, kasa üzerindeki kaynak ilkeleriyle (resource policies) kontrol edilir.

BackupPlan:
  BackupPlanName: tier1-daily
  Rules:
    - RuleName: daily-35day
      TargetBackupVault: vault-locked-compliance
      ScheduleExpression: cron(0 5 ? * * *)
      StartWindowMinutes: 60
      CompletionWindowMinutes: 180
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:us-west-2:111122223333:backup-vault:dr-vault
          Lifecycle: { DeleteAfterDays: 365 }

Bölgeler Arası ve Hesaplar Arası Kopyalar

CopyActions bloğu, bölgeler arası (cross-Region) DR kopyaları için mekanizmadır. AWS Backup, snapshot kopyasını yönetir, hedef Bölgedeki bir KMS anahtarıyla yeniden şifreler (hedef kasanın o Bölgedeki bir anahtara referans vermesi gerekir) ve bağımsız bir yaşam döngüsü uygular. EBS ve RDS snapshot’ları varsayılan olarak kaynak Bölgede bulunur — eğer tüm Bölge bozulursa, snapshot’lar da bozulur. Bölgesel dayanıklılıktan bahseden herhangi bir düzenleyici veya iş gereksinimi, ister AWS Backup kopyalama eylemleri, ister RDS otomatik snapshot bölgeler arası kopyalama, isterse bölgeler arası hedeflere sahip DLM ilkeleri aracılığıyla olsun, açık bir bölgeler arası kopyalama adımı içermelidir.

Hesaplar arası (cross-account) kopyalar için, AWS Organizations, AWS Backup için bir yönetici hesabı atar; kaynak kasanın ilkesi hedef hesaba izin verir ve hedef kasa kaynaktan kopyalara izin verir. Bu, DR’yi merkezileştirmenin uygun maliyetli yoludur: bir yönetim hesabı, birçok iş yükü hesabından kurtarma noktalarını tutar ve her iki Bölgeye de geri yükleyebilir. EC2 için, ikinci bir Bölgeye AMI kopyası ve snapshot paylaşımı, orada sıcak altyapı olmadan örnekleri başlatmanıza olanak tanır. Şifrelenmiş snapshot’lar CMK’nin paylaşılmasını gerektirir — hedef hesabın veya Bölgenin kms:CreateGrant iznine ve anahtara erişimine ihtiyacı vardır. Bunu gözden kaçırmak, hesaplar arası geri yüklemelerin sessizce başarısız olmasının nedenidir.

24 saatlik bir RPO, bölgeler arası kopyalanan günlük otomatik bir snapshot ile ucuza karşılanır — bu, bölgeler arası bir okuma replikasından veya sıcak bir yedek kümeden çok daha az maliyetlidir. Sürekli replikasyona yalnızca RPO, snapshot sıklığının sunabileceğinden daha düşük seviyelere indiğinde geçin.

AMI Yaşam Döngüsü ve EC2 Yedeklemeleri

EC2 yedeklemelerini otomatikleştiren iki mekanizma vardır: Data Lifecycle Manager (DLM) ve AWS Backup. DLM, AWS Backup’tan daha eskidir ve Bölgeler arası ve hesaplar arası kopyalama eylemleriyle zamanlanmış olarak ilke tabanlı EBS anlık görüntüleri veya AMI’ler oluşturur. AWS Backup bunu kapsar ve merkezi ilke, Vault Lock ve çoklu hizmet kapsamı ekler. Diğer hizmetler için zaten çalıştırıyorsanız AWS Backup’ı tercih edin; kasa özelliklerine ihtiyaç duymadığınız saf EBS/AMI senaryoları için DLM’yi kullanın.

Kalıcı yerel verisi olmayan bir Auto Scaling grubunun arkasındaki durum bilgisi tutmayan web katmanları için, çalışan EC2 bulut sunucularını yedeklemek israftır. Doğru yaklaşım, güvenliği sıkılaştırılmış bir AMI oluşturmak (EC2 Image Builder veya bir CI ardışık düzeni aracılığıyla), bunu başlatma şablonunda referans göstermek ve ASG’nin bulut sunucusu değişimini yönetmesine izin vermektir. Yedekleme çabası, yerel otomatik yedeklemeleri RPO’yu karşılayan durum bilgisi tutan katmanlara yoğunlaşır.

Değişmezlik: Vault Lock ve Object Lock

Hesabınızdaki basit bir anlık görüntü, doğru IAM iznine sahip herkes tarafından silinebilir — anlık görüntüler tek başına değişmezlik gereksinimlerini karşılamaz. Yasal düzenlemeler (SEC 17a-4, FINRA, HIPAA, GDPR) sıklıkla yöneticilerin bile aşamayacağı, bir kez yaz-çok kez oku (write-once-read-many) saklama talep eder. İki AWS mekanizması bunu sağlar.

AWS Backup Vault Lock, bir yedekleme kasasında WORM’u (bir kez yaz, çok kez oku) zorunlu kılar:

Uyumluluk modunda, bekleme süresi dolduğunda, kök hesap da dahil olmak üzere hiçbir kullanıcı saklama süresini kısaltamaz, kurtarma noktalarını süresi dolmadan silemez veya kilidin kendisini kaldıramaz. Bu, hem içeriden silmeyi hem de hesabı tamamen ele geçirmiş bir fidye yazılımı operatörünü engeller.

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name ComplianceVault \
  --changeable-for-days 3 \
  --min-retention-days 2555 \
  --max-retention-days 2920

S3 Object Lock, Yönetişim modunda (ayrıcalıklı kullanıcılar s3:BypassGovernanceRetention ile geçersiz kılabilir) veya Uyumluluk modunda (kök hesap dahil hiç kimse saklama süresini silemez veya kısaltamaz) nesne düzeyinde WORM sağlar. Yasal Saklama, saklama sürelerinden bağımsızdır. Object Lock, sürüm oluşturmayı gerektirir ve tam koruma için kova oluşturulurken etkinleştirilmelidir.

Yük Devretme Bölgesi için Kapasite Rezervasyonları

Yük devretme Bölgesinin büyük ölçekli bir olay gününde EC2 kapasitesine sahip olacağını varsayan bir DR planı, plan değildir. Bir Bölge çöktüğünde, herkes aynı anda yük devretme yapar ve bulut sunucusu türleri — özellikle büyük, GPU’lu veya özel şekiller — tükenebilir. Hedef Bölgedeki İsteğe Bağlı Kapasite Rezervasyonları (ODCR’ler), belirli bir bulut sunucusu türü, platform ve AZ için kapasiteyi garanti eder ve kullanılsın ya da kullanılmasın faturalandırılır. Maliyeti dengelemek için bir Savings Plan ile eşleştirin. Uzun vadeli GPU/ML taahhütleri için Kapasite Blokları uygulanır; aile esnekliği için bir Kapasite Rezervasyon Filosu birden fazla bulut sunucusu ailesini kapsar. Prensip şudur: İşletme DR Bölgesinde garantili işlem gücü gerektiriyorsa, bunu rezerve edin — en iyi çaba ilkesine dayalı İsteğe Bağlı kullanılabilirliğe güvenmeyin.

DR Stratejisi Seçimi

AWS, her biri farklı bir maliyet/kurtarma dengesine sahip dört DR katmanını standartlaştırır:

Doğru katman, mimari tercihe göre değil, işletmenin RPO ve RTO’su tarafından belirlenir. 24 saatlik bir RPO, günlük Bölgeler arası anlık görüntü kopyalarını (Yedekleme ve Geri Yükleme) tolere eder. Saniyeler mertebesinde bir RPO, sürekli çoğaltma gerektirir — Bölgeler arası okuma replikaları, Aurora Global Database, DynamoDB Global Tables veya S3 Cross-Region Replication. Gecelik anlık görüntülerle 5 dakikalık bir RPO’ya ulaşmaya çalışmak, bütçeden bağımsız olarak mimari olarak imkansızdır. Tersine, her iş yükü için varsayılan olarak aktif-aktif kullanmak bir maliyet anti-desenidir: küresel olarak tutarlı veri (DynamoDB Global Tables veya yazma yönlendirmeli Aurora Global), tam ölçekte yinelenen işlem gücü ve Route 53 veya Global Accelerator aracılığıyla karmaşık trafik yönlendirmesi gerektirir. Belirtilen RPO/RTO’yu karşılayan en ucuz deseni seçin — 2 saatlik bir RPO için, yedekleme ve geri yükleme veya pilot ışık genellikle yeterlidir ve ılık bekleme aşırı mühendisliktir.

Silme Koruması ve Katmanlı Korumalar

Dayanıklılık sadece “yedeklerimiz var mı” demek değildir — “herhangi bir tek aktör, hata veya saldırı onları silebilir mi” demektir. Katmanlı kontroller tek bir yanlış tıklama felaketini önler:

• RDS: DeletionProtection‘ı etkinleştirin ve silme sırasında son bir anlık görüntü alınmasını zorunlu kılın.
• EC2: Kritik bulut sunucularında DisableApiTermination ve DisableApiStop‘ı etkinleştirin.
• DynamoDB: Silme korumasını ve anlık zaman kurtarmayı etkinleştirin.
• S3: Değişmezlik için Sürüm Oluşturma + MFA Delete + Object Lock.
• CloudFormation: Durum bilgisi tutan kaynaklarda DeletionPolicy: Retain ve yığın sonlandırma koruması.
• IAM SCPs: backup:DeleteRecoveryPoint, backup:DeleteBackupVault, rds:DeleteDBInstance ve ec2:DeleteSnapshot işlemlerini acil durum rolleri dışında reddedin.

aws rds modify-db-instance \
  --db-instance-identifier prod-pg \
  --deletion-protection \
  --backup-retention-period 35 \
  --apply-immediately

Uyumluluk modundaki Vault Lock ile birleştirildiğinde, bunlar derinlemesine savunma sağlar: ele geçirilmiş bir yönetici kimlik bilgisi bile son savunma hattı olan kurtarma noktalarını yok edemez.

Sık Karşılaşılan Tuzaklar

Multi-AZ’yi DR Olarak Görmek. RDS Multi-AZ, ElastiCache Multi-AZ ve FSx Multi-AZ’nin tamamı tek bir Region içinde yer alır. Bölgesel bir API kesintisi, yanlışlıkla bir tablonun silinmesi veya hatalı uygulanan bir şema migrasyonu her iki düğümü de etkiler. “Başka bir Region”, “bölgesel arıza” veya “Bölgeler arası RPO” gibi ifadeler içeren herhangi bir gereksinim, Bölgeler arası replikasyon veya kopyalama gerektirir. Multi-AZ tek başına bu gereksinimi karşılamaz.

Read Replica’ları HA ile Karıştırmak. Read replica’lar asenkrondur, manuel olarak promote edilir ve endpoint’leri değişir. Otomatik failover’ı değil, okuma ölçeklendirmesini çözerler.

Snapshot’ların Uyumluluğa Eşit Olduğunu Varsaymak. Vault Lock (uyumluluk modu) veya Object Lock olmayan snapshot’lar, doğru IAM iznine sahip herhangi bir principal ve root hesabı tarafından silinebilir. WORM düzenleyici saklama politikaları, kilitli bir bekleme süresinin dolduğu, açık bir değiştirilemezlik yapılandırması gerektirir.

Bölgesel Bir RPO için Yalnızca Yerel Snapshot’lar Kullanmak. EBS ve RDS snapshot’ları varsayılan olarak kaynak Region’da tutulur. Bölgesel dayanıklılık, açık bir Bölgeler arası kopyalama eylemi gerektirir.

Test Edilmiş Geri Yüklemeler veya Rezerve Kapasite Olmadan Yedekleme Yapmak. Hiç geri yüklemediğiniz bir snapshot, bir yedek değil, bir hipotezdir. Geri yükleme tatbikatları; eksik IAM rollerini, hedef Region ve hesaptaki KMS anahtar erişim sorunlarını ve mevcut olmayan instance tiplerini ortaya çıkarır. Kritik iş yükleri için Kapasite Rezervasyonları olmadan, herkes aynı anda failover yaptığında DR Region’ı ihtiyacınız olan instance tipine sahip olmayabilir ve RTO süresi belirsiz hale gelir.

Active-Active için Aşırı Mühendislik Yapmak. Yinelenen global işlem gücü, global olarak tutarlı veri replikasyonu ve karmaşık trafik yönlendirme maliyetlidir. Eğer RPO/RTO bunu gerektirmiyorsa, pilot light veya warm standby doğru mimaridir.

Stateless Katmanları Yedeklemek. Bir ASG arkasındaki geçici (ephemeral) web sunucularının snapshot’ını almak parayı boşa harcar ve kurtarma işlemini karmaşıklaştırır. AMI’lar oluşturun, bunları launch template’lerde referans gösterin ve yedekleme yatırımınızı stateful (durum bilgisi tutan) veriler üzerinde yoğunlaştırın.

← Yönetim · Tüm alanlar

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

Amazon'a göz atın →