Cloud & IT Cert Prep · Ders

RTO, RPO ve DR Katmanları

Q: “RTO, RPO ve DR Katmanları” dersi ücretsiz mi?

Evet — “RTO, RPO ve DR Katmanları” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve Cloud & IT Cert Prep kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. Cloud & IT Cert Prep kursu toplamda 4 dersten oluşur.

Q: Cloud & IT Cert Prep öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te Cloud & IT Cert Prep, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 1. dersidir.

Q: “RTO, RPO ve DR Katmanları” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Q: Bu Cloud & IT Cert Prep dersinde kod yazıp çalıştırabilir miyim?

Evet. Her Cloud & IT Cert Prep dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Kurtarma Süresi Hedefi ile Kurtarma Noktası Hedefini tanımlayın, bunları maliyet katmanlarıyla eşleyin ve her DR stratejisinin hangi SLA taahhütlerini desteklediğini anlayın.

RTO, RPO ve DR Katmanları, CoddyKit'te ücretsiz bir Cloud & IT Cert Prep dersidir. Bu, 4 dersinin 1. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, Cloud & IT Cert Prep öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. Cloud & IT Cert Prep kursu toplamda 4 dersten oluşur.

RTO ve RPO'yu Anlama

Recovery Time Objective (RTO), bir felaketin gerçekleşmesinden sisteminizin yeniden çalışır duruma getirilmesine kadar kabul edilebilecek en uzun süredir. RTO'nuz 4 saat ise işletmeniz 4 saatlik kesintiyi tolere edebilir. Recovery Point Objective (RPO), zamanla ölçülen kabul edilebilir en yüksek veri kaybıdır; RPO'nuz 1 saat ise felaketten en fazla 1 saat öncesine ait bir noktaya kurtarma yapabilmeniz gerekir. Her iki metrik de teknik tercihlerle değil, iş gereksinimleriyle belirlenir.

# RTO and RPO definitions:
# RTO = max time system can be DOWN
#   Example: RTO=4h means restore within 4 hours
#
# RPO = max data LOSS acceptable
#   Example: RPO=1h means no more than 1 hour of data lost
#
# Lower RTO and RPO = more expensive DR strategy
# Higher RTO and RPO = cheaper but more business impact

Dört DR Katmanı

AWS, en düşük maliyet / en yüksek RTO'dan en yüksek maliyet / en düşük RTO'ya doğru sıralanmış dört temel Disaster Recovery stratejisi tanımlar: 1) Backup and Restore — en ucuz seçenek, saatler mertebesinde RTO. 2) Pilot Light — temel bileşenler sürekli olarak minimum kapasitede çalışır, RTO dakikalar ile saatler arasındadır. 3) Warm Standby — kapasitesi azaltılmış ancak işlevsel sistem, dakikalar mertebesinde RTO. 4) Multi-Site Active-Active — en pahalı seçenek, sıfıra yakın RTO. Seçiminiz, kesintinin işletmeye maliyeti ile DR altyapısının maliyetine bağlıdır.

# DR Strategy comparison:
# Strategy          | RTO      | RPO      | Cost
# Backup & Restore  | Hours    | Hours    | Lowest
# Pilot Light       | Minutes+ | Minutes  | Low
# Warm Standby      | Minutes  | Seconds  | Medium
# Active-Active     | ~0       | ~0       | Highest

Backup and Restore Stratejisi

Backup and Restore stratejisinde verilerinizin düzenli anlık görüntülerini alır ve bunları başka bir konumda (ör. bölgeler arası çoğaltma kullanan S3'te) saklarsınız. Bir felaket durumunda en güncel yedekten geri yüklersiniz. Bekleyen altyapıyı çalıştırmadığınız için bu, en ucuz stratejidir. Bunun karşılığında RTO en uzundur (büyük veritabanlarını anlık görüntülerden geri yüklemek saatler sürebilir) ve RPO en yüksektir (son yedekten bu yana oluşan veriler kaybolur). AWS Backup, EC2, RDS, EFS, DynamoDB ve daha fazlasındaki anlık görüntü zamanlamalarını otomatikleştirir.

# Create AWS Backup plan for RDS
aws backup create-backup-plan \
  --backup-plan '{
    "BackupPlanName": "daily-backup",
    "Rules": [{
      "RuleName": "daily",
      "TargetBackupVaultName": "dr-vault",
      "ScheduleExpression": "cron(0 5 ? * * *)",
      "StartWindowMinutes": 60,
      "CompletionWindowMinutes": 180,
      "Lifecycle": {
        "DeleteAfterDays": 35
      },
      "CopyActions": [{
        "DestinationBackupVaultArn": "arn:aws:backup:us-west-2:123:backup-vault:dr-vault"
      }]
    }]
  }'

Pilot Light Stratejisi

Pilot Light stratejisi, sisteminizin temel bileşenlerini bir DR bölgesinde minimum kapasitede çalışır durumda tutar; bu, tam alevi hızla tutuşturabilecek bir pilot ışığına benzer. Genellikle bu, veritabanınızı DR bölgesine sürekli olarak çoğaltmak ve temel ağ altyapısını (VPC, alt ağlar, güvenlik grupları) korumak anlamına gelir. Uygulama sunucuları çalışmaz; ancak önceden oluşturulmuş AMI'lerden veya başlatma şablonlarından hızla başlatılabilir. RTO, gereken manuel iş miktarına bağlı olarak genellikle 30 Minutes ile birkaç saat arasındadır.

# Pilot Light: what runs in DR region at all times
# - RDS Read Replica (continuously replicated)
# - Core VPC/networking infrastructure
# - Route 53 DNS (inactive until failover)

# What is NOT running (launched during failover):
# - EC2 application servers
# - ELB (or dormant)

# Failover steps:
# 1. Promote RDS Read Replica to standalone
# 2. Scale up EC2 instances from launch template
# 3. Update Route 53 to point to DR region

Warm Standby Stratejisi

Warm Standby stratejisi, üretim ortamınızın tamamen işlevsel ancak kapasitesi azaltılmış bir kopyasını DR bölgesinde çalıştırır. Pilot Light'ın aksine uygulama katmanı çalışır durumdadır (20 yerine belki 1-2 instance) ve veritabanı bir Aurora Global Database ikincil veritabanı veya RDS Read Replica'dır. Failover sırasında DR ortamının kapasitesini üretim kapasitesiyle eşleşecek şekilde artırırsınız. RTO genellikle 15 dakikanın altındadır. Bu, orta ve yüksek kritiklikteki iş yükleri için en yaygın DR stratejisidir.

# Warm Standby: DR region runs scaled-down version
# Production:  10 EC2 instances (ASG min=10, max=50)
# DR Standby:  2 EC2 instances  (ASG min=2,  max=50)

# During failover:
# 1. Route 53 health check fails for primary
# 2. DNS switches to DR ALB
# 3. ASG in DR scales up from 2 to 10+
# 4. Promote Aurora Global DB secondary
# Total failover time: ~5-15 minutes

Multi-Site Active-Active Stratejisi

Multi-Site Active-Active, tam üretim kapasitesini aynı anda iki veya daha fazla bölgede çalıştırır. Tüm bölgeler canlı trafiğe hizmet verir ve veriler neredeyse gerçek zamanlı olarak (veya çoklu ana düzeninde) çoğaltılır. Failover gecikmesi yoktur; bir bölge başarısız olduğunda Route 53 veya Global Accelerator tüm trafiği hemen kalan sağlıklı bölgelere yönlendirir. Bu yaklaşım en düşük RTO ve RPO'yu sağlar; ancak her zaman tüm bölgelerde tam üretim kapasitesi için ödeme yaptığınızdan maliyeti de en yüksektir.

# Active-Active: full capacity in both regions
# us-east-1:  ASG 10 instances (serving ~50% traffic)
# eu-west-1:  ASG 10 instances (serving ~50% traffic)

# Route 53 weighted routing:
# us-east-1: weight=50
# eu-west-1: weight=50
# Both records have health checks

# On us-east-1 failure:
# Health check fails -> Route 53 removes us-east-1
# eu-west-1 receives 100% traffic
# ASG in eu-west-1 scales up automatically

RPO ve Veri Çoğaltma Teknolojisi

RPO'nuz, hangi çoğaltma teknolojisine ihtiyaç duyduğunuzu doğrudan belirler. RPO = 0 eşzamanlı çoğaltma gerektirir; hiçbir veri kaybolmaz. Saniyeler cinsinden RPO, Aurora Global Database gibi neredeyse gerçek zamanlı eşzamansız çoğaltma gerektirir (<1s gecikme). Minutes cinsinden RPO, küçük gecikmeli eşzamansız çoğaltmaya (DynamoDB Streams, RDS Read Replicas) olanak tanır. Hours cinsinden RPO, dönemsel anlık görüntülerle (AWS Backup saatlik zamanlaması) elde edilebilir. Bir teknoloji seçmeden önce iş gereksiniminizdeki RPO'yu açıkça belirleyin.

# RPO requirements mapped to replication technology:
# RPO = 0:        RDS Multi-AZ (synchronous)
# RPO < 1 second: Aurora Global Database
# RPO < 1 minute: DynamoDB Global Tables
# RPO < 15 min:   RDS Read Replica
# RPO < 1 hour:   AWS Backup hourly schedule
# RPO < 24 hours: AWS Backup daily schedule

Sunucusuz Mimariler için DR

Sunucusuz mimariler (Lambda, DynamoDB, API Gateway) doğaları gereği daha dayanıklıdır; ancak yine de DR planlamasına ihtiyaç duyar. DynamoDB Global Tables, veritabanı katmanı için aktif-aktif çok bölgeli yapı sağlar. Lambda, aynı CI/CD pipeline'ından ikinci bir bölgeye dağıtılabilir. API Gateway, DR bölgesinde sağlanmalıdır. Temel risk, bölgeler arasındaki yapılandırma farklılaşmasıdır; her iki bölgeye de aynı altyapıyı aynı kod tabanından dağıtmak için AWS CDK veya Terraform kullanın.

# Deploy Lambda to multiple regions with CDK
# cdk.json environment configuration:
{
  'primary': {
    'account': '123456789',
    'region': 'us-east-1'
  },
  'dr': {
    'account': '123456789',
    'region': 'us-west-2'
  }
}

# Deploy to both:
# cdk deploy --context env=primary
# cdk deploy --context env=dr

RTO ve Maliyet Dengesi Örnekleri

Yıllık geliri 10M$ olan bir şirketi ele alalım. Kesinti dakikada 1.000$ maliyet oluşturuyorsa 8 saatlik bir kesinti (RTO=8h) 480.000$'a mal olur. RTO=15 dakika olan aktif-pasif Warm Standby, olay başına olası kaybı 15.000$'a düşürür. Bekleyen sistem ayda 5.000$'a (yılda 60.000$) mal oluyorsa, bu yatırım yalnızca yılda birden fazla önemli kesinti yaşanıyorsa ekonomik açıdan anlamlıdır. Bu maliyet gerekçelendirme analizi, DR stratejilerini seçerken SAA-C03 sınavının sizden yapmanızı istediği değerlendirmedir.

# DR cost justification formula:
# Annual cost of DR infrastructure
# vs
# Expected annual outage cost
#   = P(outage) x downtime_duration x cost_per_minute
#
# Example:
# P(annual outage) = 0.1 (10% chance per year)
# downtime = 8 hours = 480 minutes
# cost = $1000/min
# Expected loss = 0.1 x 480 x $1000 = $48,000/year
#
# If warm standby costs $30,000/year -> worth it

DR Testleri ve Belgeleri

Hiç test edilmemiş bir DR planı yalnızca bir belgeden ibarettir. AWS, düzenli DR tatbikatlarını önemle önerir: failover prosedürlerini uygulayın, gerçek RTO ve RPO'yu ölçün ve eksiklikleri belirleyin. Bölgesel bozulmayı kontrollü bir şekilde simüle etmek için AWS Fault Injection Simulator (FIS) kullanın. Gerçek bir olayın stresi altında nöbetçi ekibin doğaçlama yapmak yerine açık ve test edilmiş bir prosedürü izlemesi için failover adımlarını açıklayan işletim kılavuzları hazırlayın.

# DR drill checklist:
# 1. Notify stakeholders (planned drill)
# 2. Initiate failover (Route 53 health check override)
# 3. Measure time from trigger to traffic in DR region (RTO)
# 4. Measure data consistency between regions (RPO)
# 5. Test all critical application functions in DR
# 6. Failback to primary region
# 7. Document actual RTO/RPO vs target
# 8. Update runbooks with lessons learned

Uyumluluk ve DR Gereksinimleri

Birçok sektörde DR için düzenleyici gereksinimler vardır. PCI DSS, belgelenmiş DR planlarını ve testleri zorunlu kılar. HIPAA, veri yedekleme ve felaket kurtarma prosedürlerini zorunlu kılar. SOC 2, DR dahil olmak üzere kullanılabilirlik kontrollerini değerlendirir. DR kaynaklarınızın (yedekler, replikalar, sağlık kontrolleri) doğru yapılandırıldığını sürekli olarak değerlendirmek ve belgelemek için AWS Config ve AWS Audit Manager kullanın. Bu, manuel veri toplamaya gerek kalmadan uyumluluk denetimleri için kanıt sağlar.

# AWS Config rule to check RDS backup retention
aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "rds-backup-enabled",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "DB_INSTANCE_BACKUP_ENABLED"
    },
    "InputParameters": "{\"backupRetentionMinimum\":\"7\"}"
  }'

Kısa Kontrol

Bu dersteki AWS Çözüm Mimarı (SAA-C03) kavramlarını anlayıp anlamadığınızı test edin.

Ders Özeti

Bu derste şunları öğrendiniz: RTO kabul edilebilir en uzun kesinti süresidir ve RPO kabul edilebilir en fazla veri kaybıdır, dört DR katmanı maliyet ile kurtarma hızını dengeler ve RPO gereksiniminiz hangi çoğaltma teknolojisini kullanacağınızı belirler. Gerçek RTO ve RPO değerlerini doğrulamak için DR planınızı her zaman test edin. Sırada Backup and Restore stratejisini ayrıntılı olarak inceleyeceğiz.

Sıkça Sorulan Sorular