Lưu trữ cho EC2: EBS, AMI, Instance Store, EFS, FSx

1. EBS Volume là gì?

Khi bạn tạo một EC2 instance, bản thân "máy tính ảo" đó cần một nơi để lưu dữ liệu — hệ điều hành, file cài đặt, dữ liệu ứng dụng. Cách phổ biến nhất để làm điều này là dùng EBS (Elastic Block Store) Volume — một loại ổ đĩa mạng mà bạn có thể gắn (attach) vào EC2 instance trong khi nó đang chạy.

Cách dễ nhớ nhất: hãy nghĩ về EBS Volume như một "cái USB gắn qua mạng". Giống như bạn có thể rút một chiếc USB ra khỏi máy tính này và cắm vào máy tính khác, một EBS Volume có thể được gỡ (detach) khỏi một EC2 instance và gắn (attach) sang một instance khác một cách nhanh chóng — chỉ khác là việc "cắm/rút" này diễn ra qua mạng nội bộ của AWS, không phải qua cổng USB vật lý.

Một vài đặc điểm quan trọng của EBS Volume:

• Giữ dữ liệu lâu dài (persist): Cho phép dữ liệu tồn tại độc lập, ngay cả sau khi instance gắn với nó đã bị chấm dứt (terminate) — miễn là bạn cấu hình đúng (xem phần "Delete on Termination" bên dưới).
• Chỉ gắn vào một instance tại một thời điểm (ở trình độ kiến thức Cloud Practitioner — trên thực tế AWS có loại Multi-Attach cho một số trường hợp đặc biệt, nhưng nội dung thi CLF-C02 coi EBS Volume là "1-1" với instance).
• Bị ràng buộc vào một Availability Zone (AZ) cụ thể — đây là điểm rất quan trọng cần nhớ.

2. Delete on Termination & EBS Snapshot

Chi tiết hoạt động của EBS Volume

Vì là một ổ đĩa mạng (không phải vật lý), EBS Volume giao tiếp với instance qua kết nối mạng nội bộ, nên đôi khi có thể có một chút độ trễ (latency) so với ổ đĩa vật lý gắn trực tiếp. Đổi lại, tính linh hoạt rất cao: bạn có thể gỡ EBS Volume khỏi một EC2 instance và gắn sang một instance khác trong vài giây.

Điểm cần nhớ kỹ: EBS Volume bị khóa vào một AZ cụ thể. Ví dụ, một EBS Volume được tạo ở AZ us-east-1a thì không thể gắn trực tiếp vào một EC2 instance đang chạy ở AZ us-east-1b. Nếu bạn muốn "di chuyển" dữ liệu của volume đó sang AZ khác (hoặc region khác), bạn phải tạo một snapshot trước, rồi từ snapshot đó tạo ra volume mới ở AZ/Region đích.

Về giá: EBS Volume có dung lượng được cấp phát trước (provisioned capacity) — nghĩa là bạn phải chọn trước kích thước (số GB) và mức IOPS (số lượng thao tác đọc/ghi mỗi giây) bạn cần, và bạn bị tính tiền theo toàn bộ dung lượng đã cấp phát, bất kể bạn dùng hết hay không. Bạn có thể tăng dung lượng của volume theo thời gian khi nhu cầu tăng lên.

Delete on Termination

Đây là một thuộc tính (attribute) kiểm soát điều gì xảy ra với EBS Volume khi EC2 instance gắn với nó bị chấm dứt (terminate):

• Với root volume (ổ đĩa chứa hệ điều hành, gắn mặc định khi tạo instance): thuộc tính này được kích hoạt theo mặc định — nghĩa là khi instance bị terminate, root volume cũng bị xóa theo.
• Với các volume khác mà bạn gắn thêm vào instance: thuộc tính này bị tắt theo mặc định — nghĩa là dù instance bị terminate, các volume phụ này vẫn còn tồn tại (không tự động bị xóa).

Bạn có thể chủ động thay đổi thuộc tính này qua Console hoặc CLI. Một tình huống sử dụng thực tế: bạn muốn giữ lại dữ liệu trên root volume dù instance đã bị xóa (ví dụ để phân tích lại sau) — bạn chỉ cần tắt thuộc tính Delete on Termination cho root volume đó trước khi terminate instance.

EBS Snapshot

EBS Snapshot là một bản sao lưu (backup) của EBS Volume tại một thời điểm cụ thể — giống như bạn chụp ảnh "trạng thái hiện tại" của cái USB, để nếu sau này ổ đĩa gốc có vấn đề, bạn vẫn có thể khôi phục lại từ đó. Về kỹ thuật, không bắt buộc phải gỡ (detach) volume ra khỏi instance trước khi tạo snapshot, nhưng AWS khuyến nghị nên làm vậy để đảm bảo tính toàn vẹn dữ liệu (data integrity) — tránh trường hợp có dữ liệu đang được viết vào đĩa ngay lúc snapshot được chụp.

Một tính năng cực kỳ hữu ích: bạn có thể copy snapshot sang một AZ khác hoặc một Region khác — đây chính là cách để "di chuyển" một EBS Volume vượt ra khỏi ranh giới AZ ban đầu của nó.

Các tính năng mở rộng của EBS Snapshot

• EBS Snapshot Archive: cho phép chuyển snapshot sang một "tầng lưu trữ lưu trữ" (archive tier) với giá rẻ hơn tới 75% so với tầng thông thường. Đánh đổi là khi cần khôi phục lại từ tầng archive, quá trình này mất khoảng 24 đến 72 giờ — phù hợp cho các snapshot bạn cần giữ lâu dài nhưng hiếm khi cần dùng ngay.
• Recycle Bin cho EBS Snapshots: cho phép bạn thiết lập các quy tắc để giữ lại các snapshot đã bị xóa trong một khoảng thời gian nhất định (từ 1 ngày đến 1 năm), giúp bạn khôi phục lại nếu vô tình xóa nhầm snapshot quan trọng — giống như "thùng rác" trên máy tính cá nhân.

3. AMI – Amazon Machine Image

AMI (Amazon Machine Image) là một "bản chụp" hoàn chỉnh của một EC2 instance đã được tùy chỉnh — bao gồm hệ điều hành, các phần mềm đã cài, các file cấu hình, các công cụ giám sát... đóng gói lại thành một khuôn mẫu (template) để bạn có thể dùng nó khởi tạo ra các instance mới giống hệt, nhanh hơn nhiều so với việc cài đặt lại từ đầu mỗi lần.

Lợi ích chính của AMI:

• Tùy chỉnh EC2 instance: đóng gói sẵn phần mềm, cấu hình, hệ điều hành, công cụ giám sát riêng của bạn.
• Khởi động nhanh hơn: vì phần mềm đã được cài đặt sẵn trong image, thời gian khởi động và cấu hình instance mới được rút ngắn đáng kể so với chạy User Data từ đầu.
• Gắn với một Region cụ thể — nhưng bạn hoàn toàn có thể copy AMI sang Region khác khi cần triển khai đa vùng.

Bạn có thể khởi tạo instance từ 3 nguồn AMI khác nhau:

• Public AMI: do AWS cung cấp sẵn (ví dụ Amazon Linux 2, Ubuntu chính thức...).
• AMI của riêng bạn: do bạn tự tạo và tự duy trì, dựa theo nhu cầu cụ thể của tổ chức.
• AMI từ AWS Marketplace: do một bên thứ ba tạo ra, có thể được bán (có phí) — ví dụ AMI đã cài sẵn một phần mềm thương mại nào đó.

Quy trình tạo AMI từ một EC2 instance

1. Khởi động một EC2 instance và tùy chỉnh nó theo ý muốn (cài phần mềm, cấu hình...).
2. Dừng (Stop) instance đó lại — bước này quan trọng để đảm bảo tính toàn vẹn dữ liệu (data integrity) trước khi chụp AMI.
3. Xây dựng AMI từ instance đã dừng — quá trình này cũng sẽ tự động tạo ra các EBS Snapshot tương ứng cho các volume gắn với instance đó.
4. Từ AMI này, bạn có thể khởi tạo các instance khác — thậm chí ở các AZ hoặc Region khác nhau.

4. EC2 Image Builder

Nếu công ty của bạn cần cập nhật AMI thường xuyên (ví dụ mỗi tuần, mỗi khi có bản vá bảo mật mới), việc tạo AMI bằng tay lặp đi lặp lại sẽ rất tốn công. EC2 Image Builder là dịch vụ giúp tự động hóa toàn bộ quá trình tạo, duy trì, kiểm thử (validate/test) các AMI (hoặc image container).

• Có thể chạy theo lịch định kỳ (ví dụ hàng tuần), hoặc mỗi khi có gói phần mềm nào đó được cập nhật.
• Đây là một dịch vụ miễn phí — bạn chỉ phải trả tiền cho các tài nguyên bên dưới được dùng trong quá trình build (ví dụ EC2 instance tạm thời dùng để build và test).

Quy trình hoạt động của EC2 Image Builder gồm các bước:

1. EC2 Image Builder tự động tạo ra một Builder EC2 Instance tạm thời.
2. Áp dụng các Build Component lên instance đó (các bước tùy chỉnh phần mềm, cấu hình theo yêu cầu của bạn).
3. Từ đó tạo ra một AMI mới.
4. Một Test EC2 Instance được khởi tạo từ AMI mới này để chạy bộ kiểm thử (test suite), xác nhận AMI hoạt động đúng và đảm bảo an toàn (secure).
5. Cuối cùng, AMI được phân phối (distribute) — có thể phân phối tới nhiều Region khác nhau cùng lúc.

5. EC2 Instance Store

EBS Volume có hiệu năng khá tốt, nhưng vì là ổ đĩa mạng, nó vẫn có một giới hạn nhất định về độ trễ và tốc độ so với một ổ đĩa vật lý gắn trực tiếp. Khi bạn cần hiệu năng đọc/ghi (I/O) cực cao, vượt trên khả năng của EBS, AWS có EC2 Instance Store — đây là ổ đĩa phần cứng vật lý, gắn trực tiếp vào máy chủ vật lý đang chạy EC2 instance của bạn.

• Hiệu năng I/O tốt hơn nhiều so với EBS, vì không phải đi qua mạng.
• Dữ liệu là tạm thời (ephemeral): nếu instance bị Stop (hoặc terminate), toàn bộ dữ liệu trên Instance Store sẽ bị mất — vì dữ liệu gắn chặt với phần cứng vật lý cụ thể đó, khi instance dừng lại, AWS có thể chuyển instance của bạn sang một phần cứng vật lý khác khi khởi động lại.
• Phù hợp cho: bộ đệm (buffer), bộ nhớ cache, dữ liệu tạm (scratch data), hoặc nội dung tạm thời không cần giữ lâu dài.
• Có rủi ro mất dữ liệu nếu phần cứng vật lý bị lỗi — vì đây là một ổ đĩa vật lý đơn lẻ, không có tính năng tự động nhân bản như EBS.
• Việc backup và replication (nhân bản) hoàn toàn là trách nhiệm của bạn — AWS không tự động sao lưu dữ liệu trên Instance Store.

6. Amazon EFS – Elastic File System

Tất cả các loại lưu trữ đã nói ở trên (EBS, Instance Store) đều chỉ gắn được vào một instance duy nhất tại một thời điểm. Nhưng nếu bạn có hàng trăm EC2 instance và muốn tất cả chúng cùng đọc/viết vào một hệ thống file dùng chung — giống như một "ổ đĩa mạng chia sẻ" trong văn phòng — bạn cần đến Amazon EFS (Elastic File System).

EFS là một dịch vụ NFS (Network File System) được AWS quản lý hoàn toàn (managed), có thể được mount (gắn) đồng thời trên hàng trăm EC2 instance cùng lúc.

• Hoạt động với các EC2 instance chạy Linux (EFS không hỗ trợ Windows — đó là lý do FSx for Windows ra đời, xem phần 9).
• Hoạt động đa AZ (multi-AZ) một cách tự nhiên — các instance ở nhiều Availability Zone khác nhau trong cùng một Region có thể cùng mount vào một EFS file system.
• Tính khả dụng cao (highly available) và khả năng mở rộng (scalable) rất tốt.
• Chi phí cao hơn so với EBS — khoảng gấp 3 lần so với EBS loại gp2 (mức phổ biến), nhưng đổi lại bạn trả tiền theo dung lượng thực tế sử dụng (pay per use), và không cần lo lập kế hoạch dung lượng trước (no capacity planning) như EBS.

Về mặt hình ảnh, hãy tưởng tượng: bạn có các EC2 instance nằm rải rác ở us-east-1a, us-east-1b, us-east-1c, và tất cả chúng đều kết nối tới cùng một EFS File System thông qua các mount target được đặt trong từng AZ (được bảo vệ bởi Security Group).

7. So sánh EBS và EFS

Đây là một trong những so sánh hay bị hỏi nhất trong đề thi CLF-C02, vì hai dịch vụ này rất dễ nhầm lẫn (cả hai đều là "lưu trữ gắn với EC2"). Bảng dưới đây tổng hợp sự khác biệt cốt lõi:

Tóm lại: nếu bạn cần một ổ đĩa riêng cho một máy chủ, gắn liền với nó suốt vòng đời — EBS là lựa chọn hợp lý và tiết kiệm hơn. Nhưng nếu bạn cần nhiều máy chủ cùng chia sẻ, cùng đọc/viết vào một nơi lưu trữ — EFS là câu trả lời đúng.

8. EFS Infrequent Access (EFS-IA)

Không phải toàn bộ file trong hệ thống EFS của bạn đều được truy cập thường xuyên — có những file cũ, ít ai đụng tới, nhưng bạn vẫn phải trả tiền lưu trữ cho chúng ở mức giá tiêu chuẩn. EFS-IA (Infrequent Access) là một storage class (tầng lưu trữ) được tối ưu về chi phí cho các file không được truy cập hàng ngày.

• Giúp giảm chi phí lưu trữ tới 92% so với EFS Standard.
• EFS tự động di chuyển các file sang tầng EFS-IA dựa trên thời điểm truy cập gần nhất (last access time) của mỗi file.
• Kích hoạt bằng cách thiết lập một Lifecycle Policy — ví dụ, thiết lập quy tắc: các file không được truy cập trong 60 ngày sẽ tự động chuyển sang EFS-IA.
• Quá trình này hoàn toàn trong suốt (transparent) với ứng dụng của bạn — ứng dụng vẫn đọc/viết file bình thường, không cần biết file đang nằm ở tầng nào.

9. Amazon FSx: Windows File Server & Lustre

EFS rất mạnh, nhưng nó chỉ hỗ trợ Linux và dùng giao thức NFS. Nếu bạn cần một hệ thống file dùng chung cho Windows, hoặc cần hiệu năng siêu cao cho các tác vụ tính toán khoa học, AWS cung cấp Amazon FSx — dịch vụ cho phép bạn khởi chạy các hệ thống file bên thứ ba hiệu năng cao, được AWS quản lý hoàn toàn (fully managed).

FSx có 3 biến thể chính:

• FSx for Lustre
• FSx for Windows File Server
• FSx for NetApp ONTAP

Amazon FSx for Windows File Server

Đây là một hệ thống file được quản lý hoàn toàn, đáng tin cậy và có khả năng mở rộng, được xây dựng dựa trên nền tảng Windows File Server — tức là dành riêng cho các workload của Windows. Nó hỗ trợ giao thức SMB và hệ thống file Windows NTFS — hai công nghệ chuẩn mà mọi máy Windows đều hiểu.

• Tích hợp với Microsoft Active Directory — cho phép quản lý quyền truy cập file theo user/group giống hệt như trong hệ thống Windows doanh nghiệp truyền thống.
• Có thể được truy cập từ cả hạ tầng AWS lẫn hạ tầng on-premise (tại chỗ, trong trung tâm dữ liệu riêng của công ty) — rất hữu ích cho các công ty đang trong giai đoạn chuyển đổi dần lên Cloud (hybrid).

Ví dụ minh họa: một FSx for Windows File Server được đặt trải trên 2 Availability Zone trong một Region, có thể được một EC2 instance trên AWS truy cập, và đồng thời được một máy Windows client trong trung tâm dữ liệu của công ty truy cập qua giao thức SMB, dùng đường dẫn dạng \\fs-xxxx.example.com\share — giống hoàn toàn cách nhân viên vẫn quen dùng để mở "ổ đĩa chia sẻ" trên Windows.

Amazon FSx for Lustre

Cái tên "Lustre" được ghép từ hai từ "Linux" và "cluster" — cho thấy rõ mục đích: đây là hệ thống file được thiết kế cho các bài toán tính toán hiệu năng cao (High Performance Computing - HPC).

• Là dịch vụ được quản lý hoàn toàn, cho khả năng lưu trữ file hiệu năng rất cao, có thể mở rộng linh hoạt.
• Các trường hợp sử dụng điển hình: Machine Learning, phân tích dữ liệu (Analytics), xử lý video (Video Processing), mô hình hóa tài chính (Financial Modeling).
• Khả năng mở rộng lên tới hàng trăm GB/giây thông lượng, hàng triệu IOPS, với độ trễ ở mức dưới một milli-giây (sub-ms).
• Có thể liên kết trực tiếp với dữ liệu trong Amazon S3 — cho phép các tác vụ tính toán HPC xử lý trực tiếp dữ liệu vốn đang nằm trên S3 mà không cần copy thủ công.

10. Mô hình trách nhiệm chung với lưu trữ EC2

Cũng như với EC2 nói chung, việc lưu trữ dữ liệu cho EC2 cũng tuân theo mô hình trách nhiệm chung:

AWS chịu trách nhiệm

• Hạ tầng vật lý bên dưới các dịch vụ lưu trữ.
• Nhân bản (replication) dữ liệu cho các EBS Volume và EFS.
• Thay thế phần cứng bị lỗi.
• Đảm bảo nhân viên AWS không thể truy cập vào dữ liệu của bạn.

Bạn chịu trách nhiệm

• Thiết lập quy trình backup/snapshot cho dữ liệu của mình.
• Thiết lập mã hóa (encryption) cho dữ liệu.
• Chịu trách nhiệm về nội dung dữ liệu nằm trên các ổ đĩa.
• Hiểu rõ rủi ro khi sử dụng EC2 Instance Store (dữ liệu tạm thời, có thể mất).

Nói cách khác: AWS đảm bảo "hạ tầng lưu trữ bên dưới hoạt động ổn định và an toàn về mặt vật lý", còn bạn phải tự lo "chiến lược backup, mã hóa, và hiểu đúng bản chất của từng loại lưu trữ" để tránh mất dữ liệu ngoài ý muốn.