AWS Disaster Recovery & Migration: Backup, DRS, DMS, MGN, DataSync & Snow Family
Hãy tưởng tượng bạn là Solutions Architect, và trong cùng một quý có hai bài toán lớn đáp xuống bàn làm việc:
- Thảm họa ập đến. Một sáng, toàn bộ data center on-premises (hoặc một region AWS) sập. CEO hỏi đúng hai câu: “Chúng ta mất bao nhiêu dữ liệu?” và “Bao lâu thì hệ thống chạy lại?”.
- Cả công ty dọn nhà lên cloud. Ban lãnh đạo quyết định trong 6 tháng phải đưa toàn bộ on-premises lên AWS: hàng trăm server, một mớ database đủ thể loại, và hàng trăm TB file. “Làm sao chuyển hết mà downtime tối thiểu?”.
Hai bài toán này được AWS gom vào cùng một chương không phải ngẫu nhiên — chúng chia sẻ chung “DNA”. Ví dụ rõ nhất: dịch vụ phục hồi thảm họa (DRS) và dịch vụ di chuyển server (MGN) thực ra dùng chung một engine nhân bản bên dưới, chỉ khác mục đích. Và đây cũng chính là cái bẫy yêu thích của đề thi SAA: nó tả một tình huống rồi hỏi bạn chọn service nào — trong khi ba đáp án còn lại đều “nghe có vẻ đúng”.
Bài viết này là tấm bản đồ giúp bạn vẽ ranh giới rõ ràng giữa các service trong hai “họ”: Disaster Recovery (phục hồi một hệ thống đang chạy sau thảm họa) và Migration (đưa workload/dữ liệu vào AWS). Với mỗi service ta sẽ đi qua: nó làm gì, tính năng cốt lõi, use case thực tế, và — quan trọng nhất cho phòng thi — những keyword “tố cáo” nó trong câu hỏi.
Note: Đây là bài tổng quan để dựng mental model và giúp bạn nhận ra đáp án đúng thật nhanh trong phòng thi. Mỗi service ở đây xứng đáng có một bài deep-dive riêng; bài này tập trung vào ranh giới giữa chúng và những con số hay bị hỏi.
1. Bức tranh lớn: hai “họ” và hai thước đo trị vì DR (RPO & RTO)
Trước khi vào chi tiết, hãy ghim hai ý.
Ý thứ nhất — phân biệt hai họ:
- Disaster Recovery (DR): hệ thống của bạn đang chạy trên AWS thì thảm họa xảy ra (region/AZ sập, dữ liệu hỏng, bị ransomware…). Câu hỏi là: phục hồi nhanh đến đâu và mất bao nhiêu dữ liệu.
- Migration: workload của bạn đang ở ngoài AWS (on-premises, cloud khác) và bạn muốn đưa nó vào AWS. Câu hỏi là: di chuyển cái gì (server, database, file) và downtime bao lâu.
Ý thứ hai — hai thước đo quyết định mọi chiến lược DR. Bất kỳ câu hỏi DR nào cũng xoay quanh hai con số này:
- RPO là lượng dữ liệu tối đa bạn chấp nhận mất. Nó là khoảng thời gian giữa bản backup/replica gần nhất và thời điểm thảm họa. RPO = 1 giờ nghĩa là bạn chấp nhận mất tối đa 1 giờ dữ liệu. Con số này thể hiện tần suất backup.
- RTO là thời gian downtime tối đa chấp nhận được để đưa hệ thống chạy lại. RTO = 10 phút nghĩa là sau thảm họa, trong vòng 10 phút hệ thống phải hoạt động. con số này quyết định chiến lược DR bạn chọn.
RPO trả lời cho câu hỏi “Mình sẽ mất bao nhiêu dữ liệu sau khi recovery?”.
RTO trả lời cho câu hỏi “Mình sẽ mất bao lâu để recovery thành công/ Downtime là bao nhiêu?”.
Quy luật vàng: RPO/RTO càng nhỏ thì càng tốn tiền. Muốn “không mất dữ liệu, không downtime” thì phải trả giá bằng hạ tầng luôn chạy song song. Cả phần DR của bài này thực chất là tìm điểm cân bằng giữa tiền và RPO/RTO.
2. Bốn chiến lược Disaster Recovery
Đây là phần “khái niệm” quan trọng nhất của cả chương, và đề thi hỏi rất nhiều. AWS không có một “nút DR” — thay vào đó có 4 chiến lược, xếp từ rẻ-chậm đến đắt-nhanh. Bạn chọn chiến lược dựa trên RPO/RTO mục tiêu.
1. Backup & Restore (RPO/RTO cao, rẻ nhất). Bạn chỉ backup dữ liệu định kỳ (EBS snapshot, RDS snapshot, đẩy lên S3, hoặc dùng AWS Backup) và cất ở nơi an toàn. Khi thảm họa xảy ra, bạn mới dựng lại hạ tầng từ con số 0 rồi restore dữ liệu vào. Vì không có gì chạy sẵn nên cực rẻ, phần lớn thuộc về chi phí lưu trữ, nhưng RTO tính bằng giờ. Phù hợp khi hệ thống chấp nhận chết vài giờ.
2. Pilot Light (RPO/RTO thấp hơn, vẫn rẻ). Hình dung ngọn lửa nhỏ (“đèn báo”) luôn cháy âm ỉ: bạn giữ cho phần lõi quan trọng nhất — thường là database — luôn chạy và liên tục replicate sang region DR, còn phần application/web thì tắt (chỉ chuẩn bị sẵn AMI/cấu hình). Khi thảm họa xảy ra, bạn chỉ cần “thắp” phần còn lại lên (bật server app, đấu vào database đã có sẵn dữ liệu). Nhanh hơn Backup & Restore nhiều vì dữ liệu đã nóng sẵn.
3. Warm Standby (RPO/RTO thấp). Một bản sao đầy đủ của hệ thống đã chạy ở region DR nhưng ở quy mô tối thiểu (instance nhỏ, ít node). Khi thảm họa xảy ra, bạn chỉ việc scale up lên kích thước production và chuyển traffic sang. Vì mọi thành phần đã chạy sẵn (chỉ là nhỏ), RTO rất ngắn — chỉ tốn thời gian phóng to.
4. Multi-Site / Hot Site (RPO/RTO gần 0, đắt nhất). Chạy hệ thống full-scale ở cả hai (hoặc nhiều) nơi cùng lúc theo kiểu active-active. Traffic được chia cho cả hai; nếu một site chết, site kia gánh toàn bộ gần như tức thì. RPO/RTO gần như bằng 0, nhưng bạn trả tiền cho hai hệ thống production song song.
Exam tip: Đề sẽ cho bạn một ràng buộc về RTO/RPO và ngân sách, rồi hỏi chọn chiến lược nào. Quy tắc: thấy “rẻ nhất / chấp nhận downtime nhiều giờ” → Backup & Restore; thấy “giữ database luôn sẵn sàng nhưng tắt phần còn lại” → Pilot Light; thấy “chạy bản thu nhỏ rồi scale up” → Warm Standby; thấy “không downtime / active-active / RTO gần 0” → Multi-Site.
Keyword: RPO, RTO, backup and restore, pilot light, warm standby, multi-site, active-active, cheapest DR, lowest RTO.
3. AWS Backup — backup tập trung, có quản trị
AWS Backup là dịch vụ backup tập trung, được quản lý hoàn toàn (fully managed), cho phép bạn tạo, quản lý và tự động hóa backup cho rất nhiều service từ một nơi duy nhất — thay vì phải tự viết script snapshot riêng cho từng service.
Nó hỗ trợ một danh sách dài: EC2, EBS, EFS, FSx, RDS, Aurora, DynamoDB, DocumentDB, Neptune, S3, Storage Gateway, và cả workload VMware on-premises… Điểm hay là bạn có một bảng điều khiển cho toàn bộ backup, thay vì mỗi service một kiểu.
Các thành phần và tính năng cần nhớ:
- Backup Plan: “công thức” backup — định nghĩa tần suất (theo cron/rate), cửa sổ backup (backup window), thời gian giữ (retention), và lifecycle tự động chuyển backup cũ sang cold storage cho rẻ. Bạn cũng có thể backup on-demand thủ công bất cứ lúc nào.
- Tag-based selection: chọn tài nguyên cần backup theo tag, nên khi tạo resource mới có đúng tag là nó tự được đưa vào lịch backup.
- Backup Vault: “két” chứa các bản backup (recovery point). Bạn quản lý quyền truy cập trên vault này.
- Cross-Region backup: sao backup sang region khác — nền tảng cho DR cấp region.
- Cross-Account backup: sao backup sang account khác (thông qua AWS Organizations) — để cô lập backup khỏi account production, phòng khi account đó bị xâm nhập.
- PITR cho các service hỗ trợ (như RDS, Aurora, S3…).
Tính năng “ăn điểm” nhất trong đề thi là AWS Backup Vault Lock:
- Nó áp mô hình WORM lên vault: backup trở thành bất biến (immutable) — không ai xóa hay sửa được trong thời gian giữ, kể cả khi tài khoản bị chiếm. Đây là lá chắn kinh điển chống ransomware và xóa nhầm/xóa ác ý.
- Có hai chế độ:
- Governance mode: khóa backup, nhưng user có quyền IAM đặc biệt vẫn được phép bỏ qua khóa (override). Phù hợp khi muốn kỷ luật nội bộ nhưng vẫn chừa “cửa thoát” cho admin.
- Compliance mode: khóa cứng. Sau khi qua thời gian “cooling-off”, không ai xóa hay đổi cấu hình khóa được nữa — kể cả root user lẫn AWS Support. Dùng cho yêu cầu tuân thủ pháp lý nghiêm ngặt.
Trap: Câu hỏi nhắc đến “backup không thể bị xóa kể cả bởi root / chống ransomware / yêu cầu tuân thủ bất biến” → đáp án là AWS Backup Vault Lock (Compliance mode), không phải IAM policy thông thường (IAM có thể bị chính kẻ tấn công thay đổi).
Use case: thống nhất chính sách backup cho toàn tổ chức, đáp ứng audit/tuân thủ, backup chéo region/account cho DR, và bảo vệ backup khỏi bị xóa bằng Vault Lock.
Keyword: centralized backup, manage backups across services, backup plan, cross-region / cross-account backup, PITR, immutable backup, WORM, ransomware protection, Vault Lock.
4. AWS Elastic Disaster Recovery (DRS) — nhân bản liên tục để failover
AWS Elastic Disaster Recovery (DRS) — tên cũ là CloudEndure Disaster Recovery — là dịch vụ DR cấp toàn bộ server. Thay vì chỉ backup dữ liệu, DRS liên tục nhân bản (replicate) ở mức block toàn bộ server của bạn — cả hệ điều hành, ứng dụng, lẫn dữ liệu — vào một vùng staging chi phí thấp trong AWS.
Cơ chế “liên tục nhân bản ở mức block” này cho RPO rất nhỏ (tính bằng giây) vì mọi thay đổi trên đĩa được sao gần như tức thì. Vùng staging chỉ tốn tài nguyên tối thiểu (đĩa lưu bản nhân + vài instance nhỏ), nên rẻ. Khi thảm họa xảy ra, DRS phóng các server đầy đủ kích thước từ bản nhân và bạn failover sang — RTO tính bằng phút.
Điểm mạnh:
- Nguồn có thể là server vật lý, ảo, hoặc trên cloud khác — không chỉ EC2.
- Hỗ trợ failover và failback (quay về sau khi sự cố qua đi).
- Cho phép drill (diễn tập DR) mà không ảnh hưởng production.
Use case: DR cho server on-premises hoặc giữa các region AWS với RPO/RTO thấp mà không phải trả tiền cho một bản sao full-scale luôn chạy (rẻ hơn Multi-Site nhưng vẫn nhanh).
Keyword: continuous block-level replication, disaster recovery for servers, fast failover, low RPO/RTO DR, CloudEndure Disaster Recovery.
5. AWS Application Migration Service (MGN) — lift-and-shift lên AWS
AWS Application Migration Service (MGN) là dịch vụ di chuyển (migration) chủ lực của AWS theo kiểu lift-and-shift. Nó thay thế dịch vụ cũ AWS Server Migration Service (SMS) đã ngừng.
Và đây là chỗ “aha”: MGN dùng đúng cơ chế nhân bản block liên tục giống DRS. Nó liên tục sao server nguồn (vật lý/ảo/cloud) vào vùng staging trong AWS; đến khi bạn sẵn sàng thì thực hiện cutover — MGN tự chuyển đổi bản nhân thành EC2 instance chạy native và bật lên. Vì nhân bản chạy ngầm từ trước, downtime lúc cutover cực ngắn.
Vậy DRS và MGN khác gì nhau? Cùng một engine, khác mục đích:
| Tiêu chí | DRS (Disaster Recovery) | MGN (Migration) |
|---|---|---|
| Mục đích | Phòng thảm họa cho hệ thống đang chạy | Dọn server lên AWS một lần |
| Tính liên tục | Nhân bản mãi mãi, chỉ failover khi có sự cố | Nhân bản đến khi cutover rồi dừng |
| Sau khi xong | Server nguồn vẫn là production, AWS là DR | Server nguồn được gỡ bỏ (decommission), AWS là production |
| Câu hỏi gợi ý | ”failover”, “recovery”, “DR" | "migrate”, “lift-and-shift”, “rehost” |
Exam tip: Thấy “di chuyển/lift-and-shift hàng loạt server lên AWS” → MGN. Thấy “liên tục nhân bản để phòng thảm họa / failover” → DRS. Cùng công nghệ, đừng để đề lừa.
Use case: di chuyển hàng loạt server on-premises (hoặc từ cloud khác) lên EC2 với downtime tối thiểu, không phải cài lại ứng dụng từ đầu.
Keyword: lift-and-shift, rehost, migrate servers to AWS, minimal downtime cutover, replaces Server Migration Service (SMS).
6. AWS Database Migration Service (DMS) — di chuyển database, nguồn vẫn chạy
AWS Database Migration Service (DMS) chuyên di chuyển database vào AWS. Điểm bán hàng cốt lõi: trong suốt quá trình di chuyển, database nguồn vẫn hoạt động bình thường — ứng dụng không phải tắt.
DMS là một server do AWS quản lý chạy phần mềm replication: bạn khai báo cho nó biết lấy dữ liệu từ đâu, ghi vào đâu, rồi tạo một task để chuyển dữ liệu. Cụ thể, một migration với DMS xoay quanh ba thành phần sau.
6.1. Ba thành phần của DMS
- Replication instance: một EC2 instance do DMS quản lý, đứng giữa nguồn và đích — mọi công việc đọc, chuyển đổi và ghi dữ liệu đều diễn ra trên instance này. Một replication instance có thể chạy nhiều task cùng lúc. Nó hỗ trợ Multi-AZ: DMS duy trì một bản standby ở Availability Zone khác, instance chính gặp sự cố thì bản standby tiếp quản task đang chạy — nhờ vậy DMS kháng lỗi (resilient). Nếu không muốn tự chọn và quản lý instance, có thể dùng DMS Serverless để AWS tự cấp phát và co giãn tài nguyên replication.
- Endpoint (nguồn và đích): nơi khai báo thông tin kết nối tới mỗi database — loại engine (Oracle, PostgreSQL…), địa chỉ server, port, SSL, và tài khoản có quyền truy cập. DMS bắt buộc test kết nối thành công trước khi endpoint được dùng trong task; khi test thành công, nó còn tải sẵn thông tin schema (định nghĩa bảng, khóa chính…) để phục vụ bước cấu hình task. Một endpoint có thể được nhiều task dùng chung.
- Replication task: định nghĩa “chuyển cái gì và chuyển như thế nào” — chọn bảng/schema cần chuyển (table mapping), quy tắc biến đổi nếu cần (ví dụ đổi tên schema trên đích), và quan trọng nhất là kiểu migration.
6.2. Ba kiểu migration và flow thực tế
Khi tạo task, bạn chọn một trong ba kiểu:
- Full load (migrate existing data): copy toàn bộ dữ liệu hiện có từ nguồn sang đích một lần. Phù hợp khi bạn chấp nhận được một khoảng downtime đủ dài để copy xong.
- Full load + CDC (migrate existing data and replicate ongoing changes): vừa bulk copy dữ liệu có sẵn, vừa bắt các thay đổi phát sinh trên nguồn trong lúc copy. Full load xong, DMS áp các thay đổi đã gom được sang đích rồi tiếp tục replicate liên tục. Đây chính là kiểu làm nên điểm bán hàng của DMS: nguồn không phải dừng.
- CDC only (replicate data changes only): chỉ replicate thay đổi. Dùng khi phần dữ liệu có sẵn được chuyển bằng công cụ khác hiệu quả hơn (ví dụ native export/import của engine), còn DMS lo phần giữ hai bên đồng bộ từ thời điểm bắt đầu bulk load.
CDC (change data capture) là kỹ thuật bắt thay đổi dữ liệu bằng cách đọc transaction log của database — nơi engine ghi lại mọi thao tác ghi (với MySQL là binlog, với Oracle là redo log). DMS đọc log này qua API riêng của từng engine, nên nó thấy được mọi INSERT/UPDATE/DELETE mà không phải quét bảng hay chen vào các query đang chạy trên nguồn.
Ghép ba thành phần và kiểu migration lại, một migration điển hình với DMS diễn ra như sau:
- Tạo replication instance (hoặc dùng DMS Serverless).
- Tạo source endpoint và target endpoint, test kết nối cả hai.
- Tạo task kiểu full load + CDC rồi chạy: task bulk copy dữ liệu có sẵn, đồng thời CDC gom các thay đổi phát sinh.
- Full load xong, DMS áp các thay đổi đã gom rồi replicate liên tục; độ trễ replication giảm dần về gần 0.
- Cutover: dừng ứng dụng một nhịp ngắn, chờ các thay đổi cuối cùng chảy sang đích, rồi trỏ ứng dụng vào database mới.
Exam tip: Thấy “migrate database với downtime gần bằng 0” hoặc “nguồn vẫn phục vụ ứng dụng trong lúc migrate” là dấu hiệu của DMS với full load + CDC.
Có hai kiểu di chuyển xét theo engine, và đây là phần đề thi hay xoáy:
6.3. Homogeneous vs Heterogeneous + Schema Conversion Tool
- Homogeneous migration — cùng một loại engine (ví dụ Oracle → Oracle, PostgreSQL → PostgreSQL). Vì cấu trúc schema tương thích, bạn chỉ cần DMS để chuyển dữ liệu.
- Heterogeneous migration — khác loại engine (ví dụ Microsoft SQL Server → Aurora, Oracle → PostgreSQL). Lúc này schema và mã (stored procedure, kiểu dữ liệu…) không tương thích, nên cần bước chuyển đổi schema trước: dùng DMS Schema Conversion (bản managed chạy ngay trong console) hoặc AWS Schema Conversion Tool (SCT — bản tải về máy) để chuyển schema sang engine đích, rồi mới dùng DMS để chuyển dữ liệu.
DMS hỗ trợ rất nhiều nguồn và đích: nguồn có thể là database on-premises, trên EC2, RDS, Aurora, S3, Azure SQL…; đích có thể là RDS, Aurora, Redshift, DynamoDB, S3, OpenSearch, Kinesis, Kafka…
6.4. Di chuyển RDS & Aurora
Khi câu hỏi xoay quanh chuyển dữ liệu giữa các database AWS, có vài đường quen thuộc ngoài DMS:
- Snapshot & restore: chụp snapshot rồi restore sang instance mới — đơn giản nhưng có downtime.
- DMS: khi cần di chuyển không/ít downtime (điều kiện là cả instance mới và cũ chạy đồng thời).
- MySQL/MariaDB: dùng Percona XtraBackup đẩy file backup lên S3 rồi restore vào RDS/Aurora MySQL — nhanh hơn
mysqldumpvới khối dữ liệu lớn. - RDS → Aurora: tạo Aurora Read Replica từ RDS instance rồi promote nó thành cluster Aurora độc lập khi
replication lag = 0, hoặc restore từ snapshot. - Cross-region: copy snapshot sang region khác, hoặc dùng read replica xuyên region.
Use case: di chuyển database lên AWS hoặc đổi engine với downtime tối thiểu; đồng bộ liên tục giữa hai database; gom dữ liệu nhiều nguồn về một kho phân tích.
Keyword: migrate database, source database stays available, replication instance, full load + CDC, CDC only, near-zero downtime cutover, homogeneous vs heterogeneous, different database engine → SCT, Oracle to Aurora / SQL Server to PostgreSQL.
7. Chiến lược di chuyển từ On-Premises
Khi đề nói về việc đưa cả một data center on-premises lên AWS, ngoài MGN và DMS ở trên, có thêm vài công cụ trong “bộ đồ nghề” cần biết:
- AWS Application Discovery Service: thu thập thông tin về server on-premises trước khi di chuyển — cấu hình, mức sử dụng, và mối phụ thuộc (dependency) giữa các server — để lập kế hoạch migration. Có hai kiểu: Agentless Discovery (dành cho môi trường VMware vCenter) và Agent-based Discovery (cài agent để lấy chi tiết hơn). Dữ liệu thu được hiển thị trong AWS Migration Hub — nơi theo dõi tiến độ di chuyển tập trung.
- VM Import/Export: import image của máy ảo on-premises hiện có thành EC2 AMI/instance (và export ngược lại nếu cần). Hữu ích khi bạn đã có sẵn VM được “đóng băng” theo chuẩn nội bộ.
- Tải Amazon Linux 2 dưới dạng VM: AWS cho phép tải Amazon Linux 2 (và các bản mới hơn) dưới dạng image VM để chạy on-premises (trên VMware, VirtualBox, Hyper-V, KVM) — tiện cho việc phát triển/kiểm thử cho môi trường giống AWS ngay tại chỗ.
- AWS Storage Gateway (đề cập nhanh): cây cầu hybrid nối hạ tầng on-premises với storage trên AWS — cho phép ứng dụng on-premises dùng S3/cloud storage như storage cục bộ, thường xuất hiện trong các kiến trúc lai trong lúc chuyển đổi dần lên cloud.
Use case: giai đoạn đánh giá & lập kế hoạch trước khi di chuyển (Discovery + Migration Hub), import VM có sẵn, và duy trì mô hình hybrid trong lúc chuyển dịch.
Keyword: discover on-premises servers and dependencies, plan migration, Migration Hub, import existing VM to EC2, VM Import/Export, hybrid (Storage Gateway).
8. Chuyển khối dữ liệu lớn vào AWS — online vs offline
Khi cần đưa một khối dữ liệu lớn (file/object) vào AWS, lựa chọn cốt lõi là online (qua mạng) hay offline (gửi thiết bị vật lý).
8.1. AWS DataSync — chuyển online, theo lịch
AWS DataSync là dịch vụ chuyển dữ liệu online ở quy mô lớn: di chuyển file/object giữa on-premises ↔ AWS và cả AWS ↔ AWS.
- Để chuyển từ on-premises, bạn cài một DataSync Agent (một VM) tại chỗ; nó đọc dữ liệu rồi đẩy lên AWS.
- Nguồn rất đa dạng: NFS, SMB, HDFS, self-managed object storage (và cả cloud khác như Azure, Google Cloud). Đích phía AWS: S3, EFS, và các loại FSx (Windows File Server, Lustre, OpenZFS, NetApp ONTAP).
- Chạy theo lịch (giờ/ngày/tuần) và incremental — chỉ chuyển phần thay đổi sau lần đầu.
- Bảo toàn metadata (quyền, timestamp…) — quan trọng khi di chuyển file system.
Hiệu năng nằm ở Agent. Throughput (tốc độ truyền) của DataSync phụ thuộc rất nhiều vào tài nguyên bạn cấp cho Agent — phần mềm chạy ở phía on-premises, thường được triển khai trên một hypervisor. Agent thiếu tài nguyên thì việc truyền vẫn chậm dù đường mạng có rộng đến đâu. Ba thứ cần cấp đủ:
- CPU: lo việc nén, mã hóa và điều phối quá trình truyền.
- RAM (memory): xử lý nhiều file song song.
- Network I/O: băng thông mạng đủ lớn để đẩy dữ liệu đi nhanh.
Ngoài tài nguyên cho Agent, có hai cấu hình ở cấp task (tác vụ) hay xuất hiện trong đề:
- Bandwidth throttling: giới hạn lượng băng thông DataSync được phép dùng, để nó không “nuốt” hết đường mạng và làm ảnh hưởng các ứng dụng khác đang chạy.
- Data verification: kiểm tra tính toàn vẹn (integrity) — đảm bảo dữ liệu ở đích (destination) khớp đúng với nguồn (source), không bị lỗi/hỏng trong quá trình truyền.
Exam tip: “DataSync chạy chậm / cần tăng tốc độ truyền” → cấp thêm tài nguyên (CPU/RAM/network) cho Agent. “Không được làm nghẽn mạng của ứng dụng khác” → bandwidth throttling. “Đảm bảo dữ liệu ở đích khớp nguồn, không sai lệch” → bật data verification.
Note: DataSync không đồng bộ thời gian thực liên tục; nó chạy theo lịch. Nếu cần cầu nối hybrid thường trực giữa on-premises và cloud thì đó là việc của Storage Gateway, không phải DataSync.
8.2. AWS Snow Family — chuyển offline bằng thiết bị vật lý
Khi mạng quá chậm hoặc quá đắt để đẩy hàng chục TB/PB qua đường truyền, AWS gửi cho bạn thiết bị vật lý để bạn chép dữ liệu vào rồi gửi trả — gọi là Snow Family. Theo cách kỳ thi SAA quen mô tả, họ này gồm:
- AWS Snowcone: thiết bị nhỏ nhất, di động (vài TB), hợp với môi trường khắc nghiệt/không gian hẹp; có thể chạy DataSync sẵn để đẩy dữ liệu khi có mạng.
- AWS Snowball Edge: thiết bị cỡ vali, quy mô tới hàng petabyte (gom nhiều thiết bị). Có hai biến thể: Storage Optimized (thiên về dung lượng) và Compute Optimized (thiên về tính toán). Snowball Edge còn chạy được edge computing (EC2/Lambda) ngay trên thiết bị khi ở nơi không có mạng.
- AWS Snowmobile: xe container chở dữ liệu quy mô exabyte (tới ~100PB mỗi xe) — dành cho việc dọn cả data center khổng lồ.
Trap (cập nhật thực tế): Đề thi vẫn có thể nhắc tới cả ba, nhưng ngoài đời AWS đã khai tử Snowmobile (2024) và ngừng cả hai dòng Snowcone (HDD & SSD) từ 11/2024 (hỗ trợ khách cũ đến 11/2025). Nên Snow Family hiện tại thực chất chỉ còn Snowball Edge thế hệ mới. Trong phòng thi cứ chọn theo mô tả kinh điển; ngoài đời thì nhớ thực tế này.
8.3. Chọn cái nào?
Quy tắc ngón tay cái của AWS: ước lượng thời gian chuyển qua mạng — nếu mất hơn ~1 tuần thì dùng Snow Family sẽ nhanh hơn là đẩy online.
| Tiêu chí | DataSync | Snow Family |
|---|---|---|
| Kênh | Online (qua mạng) | Offline (thiết bị vật lý) |
| Quy mô hợp lý | Khi đường truyền đủ tốt | Khi mạng chậm/đắt, hoặc dữ liệu rất lớn |
| Cách chạy | Theo lịch, incremental | Chép vào thiết bị rồi gửi về AWS |
| Đích AWS | S3, EFS, FSx | Chủ yếu vào S3 |
| Điểm cộng | Tự động, bảo toàn metadata | Không phụ thuộc băng thông; có edge compute |
Keyword: transfer large data online / scheduled → DataSync; network too slow / petabytes / offline → Snowball Edge; exabyte / 100PB → Snowmobile (theo đề kinh điển).
9. VMware Cloud on AWS
VMware Cloud on AWS cho phép bạn chạy môi trường VMware vSphere (một SDDC đầy đủ: vSphere, vSAN, NSX) trên hạ tầng bare-metal của AWS.
Đối tượng của nó rất cụ thể: các doanh nghiệp đang dùng VMware on-premises và muốn mở rộng hoặc di chuyển lên AWS mà không phải refactor/đổi nền tảng ứng dụng. Họ giữ nguyên công cụ, kỹ năng và quy trình VMware quen thuộc, nhưng chạy trên cloud.
Use case: di chuyển workload VMware vSphere lên AWS theo kiểu “y nguyên”; dùng on-premises làm site chính và VMware Cloud on AWS làm site DR; hoặc mở rộng dung lượng data center on-premises ra cloud khi cần.
Keyword: run VMware vSphere on AWS, migrate VMware workloads without re-platforming, vSphere / vSAN / NSX on AWS, extend on-premises VMware to cloud.