Bỏ qua để đến nội dung

Amazon EC2 – Lưu trữ cho instance

EBS (Elastic Block Store) Volume là một ổ đĩa mạng (network drive) mà bạn gắn vào instance trong lúc chúng đang chạy. Cách ví von dễ nhớ nhất từ slide: hãy nghĩ về nó như một “chiếc USB qua mạng”.

Lợi ích cốt lõi, cùng hai ràng buộc đi kèm:

  • Nó cho phép instance của bạn lưu dữ liệu bền vững, kể cả sau khi instance bị terminate.
  • chỉ mount được vào một instance tại một thời điểm (ngoại lệ duy nhất là EBS Multi-Attach ở mục 7).
  • bị ràng buộc vào một Availability Zone cụ thể.

Bản chất “ổ đĩa mạng” dẫn tới điều gì

Phần tiêu đề “Bản chất “ổ đĩa mạng” dẫn tới điều gì”

Vì đây là ổ đĩa mạng, không phải ổ đĩa vật lý, mọi đặc tính của nó đều xuất phát từ đó:

  • dùng mạng để nói chuyện với instance, nghĩa là có thể có một chút độ trễ.
  • tháo khỏi một EC2 instance và gắn sang instance khác rất nhanh.
  • bị khóa vào một AZ: một EBS Volume ở us-east-1a không gắn được vào instance ở us-east-1b. Muốn chuyển volume sang AZ khác, bạn phải snapshot nó trước.
  • Nó có capacity được provision trước — cả dung lượng (GB) và IOPS.
  • Bạn bị tính tiền cho toàn bộ capacity đã provision, không phải cho phần thực dùng.
  • Bạn tăng được capacity của ổ đĩa theo thời gian.

Trong ví dụ của slide: ở us-east-1a có các volume 10 GB, 100 GB, 50 GB đang gắn vào instance; ở us-east-1b có một volume 50 GB đang gắn và một volume 10 GB ở trạng thái unattached — volume vẫn tồn tại và vẫn bị tính tiền dù chưa gắn vào máy nào.

Thuộc tính Delete on Termination quyết định EBS hành xử thế nào khi EC2 instance bị terminate, và mặc định của nó khác nhau giữa root volume và các volume khác — đây chính là chỗ gây bất ngờ trong thực tế:

Loại volume Mặc định
Root EBS volume Bị xóa (thuộc tính được bật)
Mọi EBS volume khác đang gắn Không bị xóa (thuộc tính bị tắt)

Bạn điều khiển thuộc tính này qua AWS console hoặc AWS CLI. Use case rõ ràng nhất: giữ lại root volume khi instance bị terminate — ví dụ để điều tra log sau sự cố.

Snapshotbản backup của EBS volume tại một thời điểm. Ba điều cần nhớ:

  • Không bắt buộc phải detach volume để snapshot, nhưng nên làm vậy.
  • Bạn copy được snapshot qua AZ hoặc qua Region khác.
  • Đây chính là con đường để di chuyển dữ liệu ra khỏi AZ mà EBS volume bị khóa vào: snapshot ở us-east-1a → restore thành volume mới ở us-east-1b.
Tính năng Nó làm gì
EBS Snapshot Archive Chuyển snapshot sang một “archive tier” rẻ hơn 75%; nhưng mất 24 đến 72 giờ để restore khỏi archive
Recycle Bin for EBS Snapshots Đặt rule giữ lại các snapshot đã bị xóa để bạn khôi phục được sau khi xóa nhầm; thời gian giữ (retention) từ 1 ngày tới 1 năm
Fast Snapshot Restore (FSR) Buộc khởi tạo đầy đủ (full initialization) snapshot để không có độ trễ ở lần dùng đầu tiên — nhưng rất đắt

AMI = Amazon Machine Image, và định nghĩa gọn nhất là: AMI là một bản tùy biến của một EC2 instance.

  • Bạn thêm vào đó phần mềm, cấu hình, hệ điều hành, hệ thống giám sát… của riêng bạn.
  • Lợi ích: thời gian boot và cấu hình nhanh hơn, vì mọi phần mềm đã được đóng gói sẵn.
  • AMI được build cho một Region cụ thể (và copy được qua các Region khác).

Bạn khởi tạo EC2 instance từ ba nguồn AMI:

  • Public AMI — do AWS cung cấp.
  • AMI của riêng bạn — bạn tự tạo và tự bảo trì.
  • AWS Marketplace AMI — một AMI do người khác tạo (và có thể đang bán).

Bốn bước, và bước thứ hai là chỗ hay bị bỏ qua:

  • Khởi tạo một EC2 instance và tùy biến nó theo ý bạn.
  • Stop instance — để đảm bảo toàn vẹn dữ liệu (data integrity).
  • Build AMI — việc này cũng tạo ra các EBS snapshot.
  • Khởi tạo instance từ các AMI đó.

Sơ đồ của slide cho thấy giá trị thực sự: bạn tạo Custom AMI từ một instance ở us-east-1a, rồi launch instance mới từ AMI đó ở us-east-1b — AMI là cách nhân bản một cấu hình máy sang AZ khác.

EBS volume là ổ đĩa mạng với hiệu năng tốt nhưng “có giới hạn”. Nếu bạn cần một ổ đĩa phần cứng hiệu năng cao, hãy dùng EC2 Instance Store — ổ đĩa gắn trực tiếp vào phần cứng của máy chủ vật lý, cho IOPS rất cao.

Cái được và cái mất:

  • Hiệu năng I/O tốt hơn.
  • EC2 Instance Store mất toàn bộ dữ liệu nếu instance bị stop — nó là ephemeral (tạm thời).
  • Vì vậy nó chỉ phù hợp cho buffer / cache / scratch data / nội dung tạm.
  • Có rủi ro mất dữ liệu nếu phần cứng gặp sự cố.
  • Việc backup và replication là trách nhiệm của bạn.

EBS Volume có 6 loại, và chúng được đặc trưng bởi ba thông số: Size | Throughput | IOPS (I/O Ops Per Sec).

  • gp2 / gp3 (SSD): General purpose SSD, cân bằng giữa giá và hiệu năng cho nhiều loại tải công việc.
  • io1 / io2 Block Express (SSD): SSD hiệu năng cao nhất, cho tải công việc trọng yếu, độ trễ thấp hoặc throughput cao.
  • st1 (HDD): HDD giá thấp, thiết kế cho tải công việc được truy cập thường xuyên, nặng về throughput.
  • sc1 (HDD): HDD giá thấp nhất, thiết kế cho tải công việc ít được truy cập.

Và một quy tắc rất hay ra đề: chỉ gp2/gp3 và io1/io2 Block Express dùng được làm boot volume.

Lưu trữ tiết kiệm chi phí, độ trễ thấp. Use case: system boot volume, virtual desktop, môi trường development và test. Dung lượng 1 GiB – 16 TiB.

Khác biệt then chốt giữa hai thế hệ:

gp3 gp2
Mức nền 3.000 IOPS và throughput 125 MiB/s Volume gp2 nhỏ burst được IOPS lên 3.000
Cách tăng Tăng IOPS lên tới 16.000 và throughput lên tới 1000 MiB/s một cách độc lập với nhau Dung lượng volume và IOPS gắn liền nhau; IOPS tối đa là 16.000
Tỉ lệ 3 IOPS mỗi GB, nghĩa là ở 5.334 GB thì đạt IOPS tối đa

Provisioned IOPS (PIOPS) SSD (io1 / io2 Block Express)

Phần tiêu đề “Provisioned IOPS (PIOPS) SSD (io1 / io2 Block Express)”

Dành cho ứng dụng kinh doanh trọng yếu cần hiệu năng IOPS duy trì ổn định, hoặc ứng dụng cần hơn 16.000 IOPS. Rất tốt cho tải công việc database — loại tải nhạy cảm với hiệu năng và tính nhất quán của storage.

io1 io2 Block Express
Dung lượng 4 GiB – 16 TiB 4 GiB – 64 TiB
PIOPS tối đa 64.000 cho Nitro EC2 instance, 32.000 cho các loại khác 256.000, với tỉ lệ IOPS:GiB là 1.000:1
Đặc điểm Tăng PIOPS độc lập với dung lượng storage Độ trễ dưới một phần nghìn giây (sub-millisecond); hỗ trợ EBS Multi-attach

Hai loại HDD có hai giới hạn chung: không dùng được làm boot volume, và dung lượng 125 GiB tới 16 TiB.

Throughput Optimized HDD (st1) Cold HDD (sc1)
Dùng cho Big Data, Data Warehouses, Log Processing Dữ liệu ít được truy cập; tình huống giá thấp nhất là điều quan trọng
Throughput tối đa 500 MiB/s 250 MiB/s
IOPS tối đa 500 250

EBS Multi-Attach cho phép gắn cùng một EBS volume vào nhiều EC2 instance trong cùng một AZ. Đây là ngoại lệ duy nhất của quy tắc “một volume một instance” ở mục 1.

  • Mỗi instance có toàn quyền đọc và ghi lên volume hiệu năng cao đó.
  • Tối đa 16 EC2 instance tại một thời điểm.
  • Bắt buộc phải dùng file system nhận biết cluster (cluster-aware)không phải XFS, EXT4
  • Use case: đạt tính sẵn sàng cao hơn cho các ứng dụng Linux dạng cluster (ví dụ Teradata); và ứng dụng phải tự quản lý các thao tác ghi đồng thời (concurrent write).

Khi bạn tạo một EBS volume đã được mã hóa, bạn nhận được trọn bộ:

  • Dữ liệu at rest được mã hóa bên trong volume.
  • Toàn bộ dữ liệu in flight di chuyển giữa instance và volume được mã hóa.
  • Toàn bộ snapshot được mã hóa.
  • Toàn bộ volume được tạo ra từ snapshot đó cũng được mã hóa.

Về vận hành:

  • Việc mã hóa và giải mã diễn ra trong suốt (transparently) — bạn không phải làm gì cả.
  • Mã hóa gây ảnh hưởng tối thiểu tới độ trễ.
  • EBS Encryption dùng key từ KMS (AES-256).
  • Copy một snapshot chưa mã hóa cho phép bật mã hóa.
  • Snapshot của volume đã mã hóa thì cũng được mã hóa.

Bạn không “bật mã hóa” trực tiếp trên một volume đang tồn tại. Trình tự bốn bước là:

  • Tạo một EBS snapshot của volume đó.
  • Mã hóa snapshot đó (bằng cách copy).
  • Tạo EBS volume mới từ snapshot — volume này sẽ được mã hóa.
  • Gắn volume đã mã hóa vào instance ban đầu.

Chi tiết về KMS và quản lý khóa nằm ở chương Security & Encryption.

Amazon EFS là một NFS (network file system) được quản lý, mount được lên nhiều EC2 cùng lúc. Đây là khác biệt lớn nhất so với EBS:

  • EFS hoạt động với các EC2 instance nằm ở nhiều AZ (multi-AZ).
  • Tính sẵn sàng cao, có khả năng mở rộng, đắt (3 lần gp2), trả tiền theo mức dùng (pay per use).

Sơ đồ của slide minh họa đúng ý đó: các EC2 instance ở us-east-1a, us-east-1bus-east-1c đều mount vào cùng một EFS FileSystem, và việc truy cập được kiểm soát bởi một Security Group.

  • Use case: content management, web serving, data sharing, WordPress.
  • Dùng giao thức NFSv4.1.
  • Dùng security group để kiểm soát truy cập vào EFS.
  • Chỉ tương thích với AMI dựa trên Linux (không hỗ trợ Windows).
  • Mã hóa at rest bằng KMS.
  • POSIX file system (tương tự Linux) với file API chuẩn.
  • File system tự động scale, trả tiền theo mức dùng, không cần capacity planning!

Quy mô của EFS: hàng nghìn NFS client đồng thời, throughput hơn 10 GB/s, và tự động lớn lên tới quy mô petabyte.

Performance Mode — phải chọn lúc tạo EFS:

  • General Purpose (mặc định) — cho các use case nhạy cảm với độ trễ (web server, CMS…).
  • Max I/Ođộ trễ cao hơn, throughput cao hơn, song song cao (big data, media processing).

Throughput Mode:

Mode Cơ chế
Bursting 1 TB = 50 MiB/s, cộng thêm burst lên tới 100 MiB/s
Provisioned Đặt throughput bất chấp dung lượng storage, ví dụ 1 GiB/s cho 1 TB storage
Elastic Tự động scale throughput lên/xuống theo tải; tới 3 GiB/s cho đọc và 1 GiB/s cho ghi; dùng cho tải công việc không đoán trước được

EFS có tính năng lifecycle managementchuyển file sang tier khác sau N ngày:

  • Standard: cho file được truy cập thường xuyên.
  • Infrequent access (EFS-IA): có phí khi lấy file ra, nhưng giá lưu trữ thấp hơn.
  • Archive: cho dữ liệu rất ít được truy cập (vài lần mỗi năm), rẻ hơn 50%.
  • Bạn cài lifecycle policy để chuyển file giữa các storage tier.

Về tính sẵn sàng và độ bền (availability & durability):

  • Standard: Multi-AZ, rất tốt cho production.
  • One Zone: một AZ duy nhất, rất tốt cho dev; backup được bật mặc định; tương thích với IA (EFS One Zone-IA) và cho tiết kiệm hơn 90% chi phí.

Ví dụ lifecycle policy trong slide: một file không được truy cập trong 60 ngày thì tự động được chuyển từ EFS Standard sang EFS IA.

Đây là mục tổng hợp mà slide nói thẳng là phải nhớ: EFS vs EBS vs Instance Store.

  • Gắn cho một instance (ngoại lệ: multi-attach io1/io2).
  • Bị khóa ở mức Availability Zone.
  • gp2: IO tăng khi dung lượng đĩa tăng.
  • gp3 và io1: tăng IO độc lập với dung lượng.
  • Để chuyển một EBS volume qua AZ khác: snapshot nó, rồi restore snapshot sang AZ kia.
  • Backup của EBS tiêu tốn IO, nên không nên chạy backup khi ứng dụng đang xử lý nhiều traffic.
  • Root EBS Volume mặc định bị terminate theo instance (bạn tắt được hành vi này).
  • Mount được lên hàng trăm instance, trải nhiều AZ.
  • EFS chia sẻ file website (WordPress).
  • Chỉ dành cho Linux instance (POSIX).
  • EFS có giá cao hơn EBS.
  • Dùng được Storage Tiers để tiết kiệm chi phí.
EBS EFS EC2 Instance Store
Loại Ổ đĩa mạng (block) NFS file system được quản lý Ổ đĩa phần cứng gắn trực tiếp
Số instance gắn được 1 (trừ Multi-Attach io1/io2, tối đa 16 trong cùng AZ) Hàng trăm, trải nhiều AZ 1 (chính máy đó)
Phạm vi Khóa vào một AZ Multi-AZ Gắn với máy chủ vật lý
Hệ điều hành Linux và Windows Chỉ Linux (POSIX) Linux và Windows
Dữ liệu sau khi stop Còn Còn Mất (ephemeral)
Chi phí Thấp hơn EFS Cao hơn EBS (3× gp2), có storage tier để giảm
Hiệu năng Tốt nhưng có giới hạn Tới 10 GB+/s throughput IOPS rất cao
Chủ đề Cần nhớ
EBS Volume Ổ đĩa mạng, “USB qua mạng”; dữ liệu còn sau khi instance terminate; một instance tại một thời điểm; khóa vào một AZ; capacity được provisionbị tính tiền theo mức provision
Chuyển volume qua AZ Snapshot rồi restore ở AZ hoặc Region khác
Delete on Termination Root volume bị xóa mặc định, các volume khác thì không; đổi được qua Console hoặc CLI
EBS Snapshot Backup theo thời điểm, không cần detach (nhưng nên), copy được qua AZ và Region
Tính năng snapshot Archive (rẻ hơn 75%, restore 24–72 giờ) · Recycle Bin (retention 1 ngày – 1 năm) · Fast Snapshot Restore (không trễ ở lần dùng đầu, rất đắt)
AMI Bản tùy biến của một instance, build theo Region và copy được qua Region; nguồn Public / của bạn / Marketplace; quy trình: customize → stop (toàn vẹn dữ liệu) → build AMI → launch
EC2 Instance Store Ổ đĩa vật lý, IOPS rất cao, nhưng ephemeral — stop là mất dữ liệu; backup/replication là việc của bạn
6 loại EBS gp2/gp3 và io1/io2 Block Express (SSD, boot được); st1 và sc1 (HDD, không boot được)
gp3 vs gp2 gp3: nền 3.000 IOPS / 125 MiB/s, tăng độc lập tới 16.000 IOPS / 1000 MiB/s. gp2: 3 IOPS/GB, tối đa 16.0005.334 GB
io1 / io2 io1 4 GiB–16 TiB, PIOPS tối đa 64.000 (Nitro) / 32.000 (khác); io2 Block Express 4 GiB–64 TiB, 256.000 PIOPS, tỉ lệ 1.000:1, độ trễ dưới 1 ms, hỗ trợ Multi-Attach
st1 / sc1 st1 500 MiB/s, 500 IOPS (big data, log); sc1 250 MiB/s, 250 IOPS (giá thấp nhất); cả hai 125 GiB–16 TiB
EBS Multi-Attach Chỉ io1/io2, cùng một AZ, tối đa 16 instance, cần file system cluster-aware, ứng dụng tự lo ghi đồng thời
EBS Encryption KMS (AES-256): at rest + in flight + snapshot + volume tạo từ snapshot; mã hóa volume cũ bằng snapshot → copy có mã hóa → tạo volume mới → gắn lại
EFS NFS được quản lý, multi-AZ, NFSv4.1, chỉ Linux/POSIX, dùng security group, mã hóa KMS, tự scale không cần capacity planning, đắt gấp 3 gp2
EFS mode Performance Mode (General Purpose / Max I/O, chọn lúc tạo) · Throughput Mode (Bursting / Provisioned / Elastic, Elastic tới 3 GiB/s đọc và 1 GiB/s ghi)
EFS storage class Standard, EFS-IA, Archive (rẻ hơn 50%) qua lifecycle policy; Standard = Multi-AZ cho prod, One Zone = một AZ cho dev, tiết kiệm trên 90%
Nhớ bộ ba EBS = một instance, một AZ, bền vững · EFS = nhiều instance, nhiều AZ, chỉ Linux, đắt hơn · Instance Store = nhanh nhất, tạm thời