AWS Learning
Migration

AWS Disaster Recovery & Migration - Tổng Quan & Diagrams

Tổng quan DR Patterns, 6Rs, DMS, Snow Family, DataSync, Storage Gateway, Backup (Diagram)

📋 Mục lục

Overview Diagram

Toàn cảnh Disaster Recovery & Migration trong AWS

Bảng so sánh nhanh

ServiceCâu hỏi trả lờiVí dụ
DR PatternsKhôi phục khi sự cố?Backup/Restore → Active-Active
6RsChiến lược migration?Rehost, Replatform, Refactor...
DMSMigrate database?Oracle → Aurora, MySQL → RDS
SCTConvert DB schema?Oracle schema → PostgreSQL
Snow FamilyData lớn, không có mạng?10 TB → Exabyte, ship vật lý
DataSyncSync files qua mạng?On-prem NFS → S3/EFS
Storage GatewayHybrid storage?On-prem app dùng S3 như NFS
Transfer FamilySFTP/FTPS → AWS?Partner upload files qua SFTP
AWS BackupBackup tập trung?Backup RDS, EBS, EFS, DynamoDB

RPO & RTO

Hai khái niệm quan trọng nhất của DR

┌───────────────────────────────────────────────────────────────────────────────┐
│                           RPO vs RTO                                          │
├───────────────────────────────────────────────────────────────────────────────┤
│                                                                               │
│  ⏱️ RPO (Recovery Point Objective)   ⏱️ RTO (Recovery Time Objective)         │
│  ══════════════════════════════════   ══════════════════════════════════      │
│                                                                               │
│  "Mất bao nhiêu DATA?"               "DOWN bao lâu?"                          │
│                                                                               │
│  • Data từ last backup → disaster    • Thời gian từ disaster → recovery       │
│  • RPO = 1h → mất tối đa 1h data     • RTO = 4h → down tối đa 4h              │
│  • RPO nhỏ = backup thường xuyên     • RTO nhỏ = recover nhanh                │
│  • RPO nhỏ = TỐN TIỀN hơn            • RTO nhỏ = TỐN TIỀN hơn                 │
│                                                                               │
│  ┌─────────────────────────────────────────────────────────────┐              │
│  │ Last Backup ◄── RPO ──► DISASTER ◄── RTO ──► Recovery       │              │
│  │             (data loss)           (downtime)                │              │
│  └─────────────────────────────────────────────────────────────┘              │
│                                                                               │
│  Ví dụ:                                                                       │
│  • E-commerce: RPO = 1 min, RTO = 5 min ($$$$)                                │
│  • Dev/Test:   RPO = 24h,  RTO = 24h   ($)                                    │
│  • Banking:    RPO ≈ 0,    RTO ≈ 0     ($$$$$)                                │
│                                                                               │
└───────────────────────────────────────────────────────────────────────────────┘

[!IMPORTANT] Tại sao RPO chỉ tính từ Last Backup → Disaster (không phải → Recovery)?

  • Sau khi disaster xảy ra, hệ thống DOWN → không ai ghi thêm data mới → không mất thêm data
  • RPO = data đã tạo nhưng chưa kịp backup trước khi sự cố
  • RTO = thời gian hệ thống down nhưng không mất thêm data (vì không ai dùng được)

Ví dụ cụ thể:

  • 8:00 AM — Backup xong ✅
  • 8:00 → 10:00 — Users tạo data mới (2 giờ data)
  • 10:00 AM — 💥 Disaster! Hệ thống down
  • 10:00 → 14:00 — Đang recover (4 giờ down, nhưng không ai ghi data)
  • 14:00 PM — ✅ Recovery xong, restore từ backup 8:00
  • → RPO = 2h (mất data 8:00–10:00), RTO = 4h (down 10:00–14:00)

4 DR Patterns

Cost vs Recovery Time

Chi tiết từng Pattern

So sánh chi tiết

PatternRPORTOCostDR Region chạy gì?Khi disaster thì làm gì?
Backup & RestoreHours24+ hours$Không có gì chạy, chỉ snapshotsRestore snapshots → Launch infra
Pilot LightMinutes10-30 min$$DB chạy, App OFFStart app servers, promote DB
Warm StandbySecondsMinutes$$$DB + App scaled-down (25%)Scale up app, Route53 failover
Active-Active~0~0$$$$100% full, serving trafficKhông cần làm gì (auto)

💾 Pattern 1: Backup & Restore — Chi tiết

┌──────────────────────────────────────────────────────────────────────────────┐
│  💾 BACKUP & RESTORE          RPO: Hours | RTO: 24+ hours | Cost: $          │
├──────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  PRIMARY REGION                         DR REGION                            │
│  ┌─────────────────────┐                ┌─────────────────────┐              │
│  │ ✅ App Servers      │                │ ❌ KHÔNG CÓ GÌ CHẠY │              │
│  │ ✅ Database         │  ──backup──►   │                     │              │
│  │ ✅ Storage          │                │ 📦 Chỉ lưu:         │              │
│  └─────────────────────┘                │ • AMIs              │              │
│                                         │ • DB Snapshots       │             │
│  AWS Services dùng:                     │ • S3 backups         │             │
│  • S3 Cross-Region Replication          └─────────────────────┘              │
│  • EBS Snapshot cross-region copy                                            │
│  • RDS automated backups                                                     │
│  • AWS Backup (centralized)                                                  │
│                                                                              │
│  🔧 Khi Disaster xảy ra:                                                     │
│  1. Restore DB từ snapshot              (⏱️ 30-60 min)                       │
│  2. Launch EC2 từ AMI                   (⏱️ 10-30 min)                       │
│  3. Deploy application code             (⏱️ 15-30 min)                       │
│  4. Update Route 53 DNS                 (⏱️ 5-15 min)                        │
│  5. Test & validate                     (⏱️ 30+ min)                         │
│  → Tổng: vài giờ đến 1 ngày                                                  │
│                                                                              │
│  ✅ Ưu điểm: Chi phí thấp nhất, đơn giản                                     │
│  ❌ Nhược điểm: Recovery time rất dài                                        │
│  🎯 Use case: Dev/Test, non-critical workloads, archival systems             │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘

🔥 Pattern 2: Pilot Light — Chi tiết

┌──────────────────────────────────────────────────────────────────────────────┐
│  🔥 PILOT LIGHT                RPO: Minutes | RTO: 10-30 min | Cost: $$      │
├──────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  PRIMARY REGION                         DR REGION                            │
│  ┌─────────────────────┐               ┌─────────────────────┐               │
│  │ ✅ App Servers      │               │ ❌ App servers OFF  │               │
│  │ ✅ Database (Write) │ ──replicate─► │ ✅ DB replica (Read)│               │
│  │ ✅ Storage          │               │ 📦 AMIs sẵn sàng    │               │
│  └─────────────────────┘               └─────────────────────┘               │
│                                                                              │
│  📌 "Pilot Light" = ngọn lửa nhỏ trong lò gas                                │
│  → Core (DB) luôn chạy, sẵn sàng "bật cháy" lên                              │
│  → App servers CHỈ start khi có disaster                                     │
│                                                                              │
│  AWS Services dùng:                                                          │
│  • RDS Read Replica cross-region (async)                                     │
│  • Aurora Global Database (< 1s lag)                                         │
│  • AMIs pre-built trong DR region                                            │
│  • Route 53 health checks + failover                                         │
│                                                                              │
│  🔧 Khi Disaster xảy ra:                                                     │
│  1. Promote DB replica → primary        (⏱️ 1-5 min)                         │
│  2. Launch app servers từ AMI           (⏱️ 5-15 min)                        │
│  3. Scale to production size            (⏱️ 5-10 min)                        │
│  4. Route 53 tự failover (health check) (⏱️ auto)                            │
│  → Tổng: 10-30 phút                                                          │
│                                                                              │
│  ✅ Ưu điểm: DB luôn sync, fast DB failover                                  │
│  ❌ Nhược điểm: App servers cần thời gian start & scale                      │
│  🎯 Use case: Core business apps, e-commerce backend                         │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘

🌡️ Pattern 3: Warm Standby — Chi tiết

┌──────────────────────────────────────────────────────────────────────────────┐
│  🌡️ WARM STANDBY             RPO: Seconds | RTO: Minutes | Cost: $$$         │
├──────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  PRIMARY REGION                         DR REGION                            │
│  ┌─────────────────────┐               ┌─────────────────────┐               │
│  │ ✅ App Servers 100% │               │ ✅ App Servers 25%  │               │
│  │ ✅ Database (Write) │ ──replicate─► │ ✅ DB replica (Read)│               │
│  │ ✅ ALB + ASG        │               │ ✅ ALB + ASG (min)  │               │
│  └─────────────────────┘               └─────────────────────┘               │
│                                                                              │
│  📌 Toàn bộ infrastructure CHẠY nhưng SCALED-DOWN                            │
│  → Có thể handle một ít traffic ngay lập tức                                 │
│  → Chỉ cần SCALE UP, không cần START từ đầu                                  │
│                                                                              │
│  AWS Services dùng:                                                          │
│  • RDS Multi-AZ + Read Replica cross-region                                  │
│  • Aurora Global Database                                                    │
│  • ASG với min capacity thấp (1-2 instances)                                 │
│  • ALB đã configured sẵn                                                     │
│  • Route 53 weighted/failover routing                                        │
│                                                                              │
│  🔧 Khi Disaster xảy ra:                                                     │
│  1. Promote DB replica → primary        (⏱️ 1-5 min)                         │
│  2. ASG scale up (25% → 100%)           (⏱️ 3-10 min)                        │
│  3. Route 53 tự failover (health check) (⏱️ auto, < 1 min)                   │
│  → Tổng: vài phút                                                            │
│                                                                              │
│  ✅ Ưu điểm: Recovery nhanh, app đã running sẵn                              │
│  ❌ Nhược điểm: Tốn tiền hơn (25% infra luôn chạy)                           │
│  🎯 Use case: Business-critical apps, SaaS platforms                         │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘

⚡ Pattern 4: Active-Active (Multi-Site) — Chi tiết

┌──────────────────────────────────────────────────────────────────────────────┐
│  ⚡ ACTIVE-ACTIVE              RPO: ~0 | RTO: ~0 | Cost: $$$$                │
├──────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  REGION A (Active)                      REGION B (Active)                    │
│  ┌─────────────────────┐               ┌─────────────────────┐               │
│  │ ✅ App Servers 100% │               │ ✅ App Servers 100% │               │
│  │ ✅ Database (R/W)   │ ◄─replicate─► │ ✅ Database (R/W)   │               │
│  │ ✅ ALB + ASG 100%   │               │ ✅ ALB + ASG 100%   │               │
│  └─────────────────────┘               └─────────────────────┘               │
│           ↑                                      ↑                           │
│           └──── Route 53 (Latency/Weighted) ─────┘                           │
│                        Users                                                 │
│                                                                              │
│  📌 CẢ HAI regions đều SERVE TRAFFIC đồng thời                               │
│  → Không có "primary" hay "secondary"                                        │
│  → Khi 1 region down → traffic tự chuyển sang region còn lại                 │
│  → ZERO downtime                                                             │
│                                                                              │
│  AWS Services dùng:                                                          │
│  • DynamoDB Global Tables (active-active, < 1s sync)                         │
│  • Aurora Global Database (write forwarding)                                 │
│  • Route 53 latency-based / weighted routing                                 │
│  • Global Accelerator (optional, static IPs)                                 │
│  • CloudFormation StackSets (deploy đồng bộ)                                 │
│                                                                              │
│  🔧 Khi Disaster xảy ra:                                                     │
│  1. Route 53 health check phát hiện     (⏱️ auto, seconds)                   │
│  2. Traffic tự route sang region healthy (⏱️ auto, seconds)                  │
│  3. KHÔNG cần action thủ công           (⏱️ 0)                               │
│  → Tổng: gần như 0s                                                          │
│                                                                              │
│  ✅ Ưu điểm: Zero downtime, best user experience                             │
│  ❌ Nhược điểm: Chi phí gấp đôi, phức tạp data consistency                   │
│  ⚠️ Challenge: Conflict resolution (last writer wins - DynamoDB)             │
│  🎯 Use case: Mission-critical (banking, healthcare, global SaaS)            │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘

[!IMPORTANT] Pilot Light vs Warm Standby — Cách phân biệt dễ nhớ:

  • Pilot Light = chỉ core (DB) chạy, app servers OFF → cần thời gian start
  • Warm Standby = toàn bộ infra chạy nhưng scaled-down → chỉ cần scale up
  • Tên "Pilot Light" từ ngọn lửa nhỏ trong lò gas — luôn cháy để sẵn sàng bật lên
  • Tên "Warm Standby" = hâm nóng sẵn, mọi thứ "ấm" và chạy rồi

6Rs Migration Strategies

Từ dễ đến khó

┌─────────────────────────────────────────────────────────────────────────────┐
│                        6Rs MIGRATION STRATEGIES                             │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  1️⃣  REHOST ("Lift & Shift")                                                │
│     └── Chuyển nguyên xi lên cloud, KHÔNG thay đổi gì                       │
│     └── VD: MySQL on-prem → MySQL trên EC2                                  │
│     └── Dùng AWS Application Migration Service                              │
│                                                                             │
│  2️⃣  REPLATFORM ("Lift & Reshape")                                          │
│     └── Thay đổi NHỎ để dùng managed services                               │
│     └── VD: MySQL on-prem → RDS MySQL (AWS quản lý)                         │
│     └── ⭐ "Reduce operational burden" = REPLATFORM                         │
│                                                                             │
│  3️⃣  REPURCHASE ("Drop & Shop")                                             │
│     └── Mua SaaS thay thế                                                   │
│     └── VD: CRM tự build → Salesforce                                       │
│     └── VD: Email server → Amazon WorkMail                                  │
│                                                                             │
│  4️⃣  REFACTOR ("Re-architect")                                              │
│     └── Viết lại code để cloud-native                                       │
│     └── VD: Monolith → Microservices + Lambda + DynamoDB                    │
│     └── Effort cao nhất, benefit lớn nhất                                   │
│                                                                             │
│  5️⃣  RETIRE                                                                 │
│     └── Không cần nữa → tắt đi, decommission                                │
│     └── Tiết kiệm cost, giảm complexity                                     │
│                                                                             │
│  6️⃣  RETAIN (Revisit)                                                       │
│     └── Chưa migrate, giữ lại on-prem                                       │
│     └── VD: App sắp EOL, compliance yêu cầu on-prem                         │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

So sánh Thời gian & Chi phí 6Rs

StrategyThời gian MigrationChi phí MigrationEffortLong-term CostLong-term Benefit
Rehost⏱️ Ngắn (days-weeks)💰 Thấp★☆☆☆☆Cao (chạy EC2 raw)Nhanh lên cloud
Replatform⏱️ Trung bình (weeks)💰 Thấp-TB★★☆☆☆TB (managed svc)Giảm ops burden
Repurchase⏱️ Trung bình (weeks)💰 TB (license SaaS)★★☆☆☆TB (subscription)Zero maintenance
Refactor⏱️ Dài (months)💰 Cao (dev cost)★★★★★Thấp nhấtCloud-native, scale tốt
Retire⏱️ Ngắn (days)💰 Không tốn★☆☆☆☆💲0Giảm complexity
Retain⏱️ Không migrate💰 Không tốn★☆☆☆☆Giữ nguyênChờ plan sau
┌─────────────────────────────────────────────────────────────────────────────┐
│          6Rs: Trade-off Migration Effort vs Long-term Benefit               │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  Migration    │                                                             │
│  Effort ▲     │                                                             │
│  (time+cost)  │                                                             │
│         5 ────│──────────────────────── ⭐ REFACTOR ──────────────── max    │
│               │                        (months, high dev cost)              │
│         4 ────│                                                             │
│               │                                                             │
│         3 ────│                                                             │
│               │                                                             │
│         2 ────│──── REPLATFORM ──── REPURCHASE                              │
│               │    (weeks, low)     (weeks, license)                        │
│         1 ────│── REHOST ──────────────────────────────────── min           │
│               │  (days, lowest)   RETIRE     RETAIN                         │
│         0 ────┼─────────┬─────────┬─────────┬─────────┬──────► Long-term    │
│               │  Thấp   │   TB    │   Cao   │ Rất cao │        Benefit      │
│                                                                             │
│  📌 REHOST  = nhanh nhất, rẻ nhất lúc migrate, nhưng chưa optimize          │
│  📌 REFACTOR = lâu nhất, đắt nhất lúc migrate, nhưng benefit lâu dài tốt    │
│  📌 RETIRE/RETAIN = không tốn effort migrate, nhưng lý do khác nhau         │
│     → Retire = không cần nữa, tắt đi tiết kiệm                              │
│     → Retain = chưa migrate được, giữ lại on-prem chờ plan sau              │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

[!TIP] Exam key: Nếu đề nói "reduce operational burden" hoặc "move to managed service" → Replatform (KHÔNG phải Rehost!)

Data Transfer & Migration Services

Chọn service nào để chuyển data?

So sánh Data Transfer Services

ServiceLoại dataCách chuyểnSpeedUse case
DMSDatabaseOnline, CDCNetwork-depDB migration, continuous replication
DataSyncFiles (NFS/SMB)Online, agentUp to 10GbpsOne-time or scheduled sync
Snow FamilyAny dataPhysical shipDays (shipping)Massive data 10TB+, no/slow network
Storage GatewayFiles/Blocks/TapesHybrid bridgeNetwork-depOngoing hybrid access
Transfer FamilyFiles (SFTP/FTPS)Online, managedNetwork-depB2B file exchange
S3 Transfer AccelS3 objectsCloudFront EdgeFaster uploadLarge uploads cross-region

Snow Family: Chọn device nào?

Storage Gateway: 3 loại Gateway

[!NOTE] Storage Gateway vs DataSync:

  • Storage Gateway = hybrid bridge, on-prem apps liên tục dùng S3/FSx qua NFS/SMB (ongoing access)
  • DataSync = chuyển data một lần hoặc scheduled sync (migration/sync job)
  • Storage Gateway KHÔNG migrate data cũ — cần DataSync hoặc Snow Family cho initial migration

DMS - Database Migration Service

Architecture & Flow

Khi nào cần SCT (Schema Conversion Tool)?

┌──────────────────────────────────────────────────────────────────────────────┐
│                   DMS: Homogeneous vs Heterogeneous                          │
├──────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  ✅ HOMOGENEOUS (same engine) → KHÔNG cần SCT                                │
│  ═══════════════════════════════════════════                                 │
│  MySQL → RDS MySQL                                                           │
│  PostgreSQL → Aurora PostgreSQL                                              │
│  Oracle → RDS Oracle                                                         │
│                                                                              │
│  ⚠️ HETEROGENEOUS (khác engine) → CẦN SCT trước                              │
│  ═══════════════════════════════════════════                                 │
│  Oracle → Aurora PostgreSQL     (SCT convert schema trước)                   │
│  SQL Server → Aurora MySQL      (SCT convert schema trước)                   │
│  Oracle → DynamoDB              (SCT convert schema trước)                   │
│                                                                              │
│  📌 SCT Workflow:                                                            │
│  Source Schema → SCT convert → Target Schema → DMS migrate data              │
│                                                                              │
│  📌 DMS Features:                                                            │
│  • Source DB KHÔNG bị downtime trong migration                               │
│  • CDC (Change Data Capture) = continuous replication                        │
│  • Full load + CDC = initial migration + ongoing sync                        │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘

AWS Backup

Backup tập trung cho nhiều services

┌──────────────────────────────────────────────────────────────────────────────┐
│                         AWS BACKUP                                           │
├──────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  📋 Backup Plan:                                                             │
│  • Schedule: Hourly / Daily / Weekly / Monthly / Custom cron                 │
│  • Retention: 1 day → Forever                                                │
│  • Lifecycle: Move to cold storage sau X ngày                                │
│  • Cross-Region Copy: Tự động copy backup sang DR region                     │
│  • Cross-Account Copy: Copy sang account khác (security)                     │
│                                                                              │
│  🗃️ Backup Vault:                                                            │
│  • Encrypted với KMS                                                         │
│  • Vault Lock: WORM (Write Once Read Many) — không xóa được                  │
│  • Resource-based access policies                                            │
│                                                                              │
│  ✅ PITR (Point-in-Time Recovery):                                           │
│  • RDS, Aurora, DynamoDB                                                     │
│  • Restore DB đến bất kỳ thời điểm nào trong retention window                │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘

Tổng hợp: Khi nào dùng service nào?

Decision Tree chi tiết

Câu hỏi thường gặp trong exam

Câu hỏiĐáp án
"Minimal downtime DB migration?"DMS (CDC mode)
"Oracle → Aurora PostgreSQL?"SCT + DMS
"MySQL → RDS MySQL?"DMS only (homogeneous)
"100 TB data, no internet?"Snowball Edge
"10 PB data center migration?"Snowmobile
"Sync on-prem NFS to S3?"DataSync
"On-prem app dùng S3 như NFS?"S3 File Gateway
"Replace physical tape backup?"Tape Gateway
"Partner upload files qua SFTP?"Transfer Family
"Centralized backup, cross-region?"AWS Backup
"RPO ~0, RTO ~0?"Active-Active (Multi-Site)
"Lowest cost DR?"Backup & Restore
"DB replicate, app OFF?"Pilot Light
"Full infra nhưng scaled-down?"Warm Standby
"Reduce operational burden?"Replatform (6Rs)
"Viết lại code cloud-native?"Refactor (6Rs)
"Chuyển nguyên xi lên cloud?"Rehost / Lift & Shift (6Rs)

Replication Services cho DR

AWS services hỗ trợ cross-region replication

Best Practices

┌─────────────────────────────────────────────────────────────────────────────┐
│                     DR & MIGRATION BEST PRACTICES                           │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  1️⃣  DISASTER RECOVERY                                                      │
│  ├── ✅ Xác định RPO/RTO TRƯỚC KHI chọn DR pattern                          │
│  ├── ✅ Dùng AWS Backup cho centralized, cross-region backup                │
│  ├── ✅ Test DR plan định kỳ (quarterly DR drills)                          │
│  ├── ✅ Automate failover với Route53 + Lambda                              │
│  └── ✅ Dùng Infrastructure as Code (CloudFormation) cho DR region          │
│                                                                             │
│  2️⃣  MIGRATION (6Rs)                                                        │
│  ├── ✅ Assessment phase: xác định workloads + dependencies                 │
│  ├── ✅ Bắt đầu với Rehost (nhanh), optimize sau                            │
│  ├── ✅ Dùng DMS + CDC cho zero-downtime DB migration                       │
│  ├── ✅ Retire 10-20% workloads không cần thiết                             │
│  └── ✅ Dùng AWS Migration Hub để track progress                            │
│                                                                             │
│  3️⃣  DATA TRANSFER                                                          │
│  ├── ✅ > 10 TB offline → Snow Family                                       │
│  ├── ✅ < 10 TB online → DataSync                                           │
│  ├── ✅ Hybrid ongoing → Storage Gateway                                    │
│  ├── ✅ Enable versioning trước khi replicate S3                            │
│  └── ✅ Encrypt data in transit + at rest                                   │
│                                                                             │
│  4️⃣  MONITORING                                                             │
│  ├── ✅ Route 53 health checks cho failover                                 │
│  ├── ✅ CloudWatch alarms cho replication lag                               │
│  ├── ✅ AWS Config rules cho backup compliance                              │
│  └── ✅ EventBridge alerts cho DMS task failures                            │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

Exam Tips

[!TIP] Ghi nhớ nhanh:

  • RPO = bao nhiêu DATA mất (Recovery Point) → liên quan đến backup frequency
  • RTO = bao lâu DOWN (Recovery Time) → liên quan đến infra sẵn sàng
  • Backup/Restore = rẻ nhất, chậm nhất
  • Active-Active = đắt nhất, nhanh nhất (RTO ≈ 0)
  • Pilot Light = chỉ DB chạy (ngọn lửa nhỏ)
  • Warm Standby = toàn bộ chạy nhưng scaled-down
  • DMS = database migration, KHÔNG downtime
  • SCT = cần khi khác engine (heterogeneous)
  • Snow Family = physical data transfer, > 10 TB
  • DataSync = online file sync (NFS/SMB → AWS)
  • Storage Gateway = hybrid bridge (ONGOING access)

[!CAUTION] Dễ nhầm lẫn:

  • Pilot Light vs Warm Standby? → PL = chỉ DB chạy / WS = cả app chạy (scaled-down)
  • DataSync vs Storage Gateway? → DataSync = migration/sync job / SGW = ongoing hybrid access
  • DataSync vs Snow? → DataSync = qua mạng / Snow = physical ship (> 10 TB)
  • DMS vs SCT? → DMS = migrate data / SCT = convert schema (dùng khi khác engine)
  • Rehost vs Replatform? → Rehost = nguyên xi / Replatform = dùng managed service (reduce operational burden)
  • S3 File Gateway vs FSx File Gateway? → S3 FG = NFS/SMB→S3 / FSx FG = SMB→FSx Windows
  • Storage Gateway KHÔNG migrate data cũ — cần DataSync/Snow cho initial migration

Liên kết tài liệu

Previous

Amazon QuickSight

Next

AWS Database Migration Service (DMS)

On this page

📋 Mục lụcOverview DiagramToàn cảnh Disaster Recovery & Migration trong AWSBảng so sánh nhanhRPO & RTOHai khái niệm quan trọng nhất của DR4 DR PatternsCost vs Recovery TimeChi tiết từng PatternSo sánh chi tiết💾 Pattern 1: Backup & Restore — Chi tiết🔥 Pattern 2: Pilot Light — Chi tiết🌡️ Pattern 3: Warm Standby — Chi tiết⚡ Pattern 4: Active-Active (Multi-Site) — Chi tiết6Rs Migration StrategiesTừ dễ đến khóSo sánh Thời gian & Chi phí 6RsData Transfer & Migration ServicesChọn service nào để chuyển data?So sánh Data Transfer ServicesSnow Family: Chọn device nào?Storage Gateway: 3 loại GatewayDMS - Database Migration ServiceArchitecture & FlowKhi nào cần SCT (Schema Conversion Tool)?AWS BackupBackup tập trung cho nhiều servicesTổng hợp: Khi nào dùng service nào?Decision Tree chi tiếtCâu hỏi thường gặp trong examReplication Services cho DRAWS services hỗ trợ cross-region replicationBest PracticesExam TipsLiên kết tài liệu