EC2 Instance Storage
EBS, Instance Store và EFS — ba cách lưu dữ liệu cho EC2, mỗi cái giải một bài toán khác nhau. Đề thi hỏi bằng cách mô tả yêu cầu rồi bắt bạn chọn đúng loại, và thường gài con số IOPS để loại trừ.
EBS Overview
EBS = Elastic Block Store. Đây là ổ đĩa mạng gắn vào instance khi nó đang chạy. Cách hình dung của bài giảng: một chiếc USB qua mạng — cắm vào máy này, rút ra cắm sang máy khác được.
Năm tính chất cốt lõi
- Dữ liệu tồn tại sau khi instance bị terminate — đây là lý do EBS có mặt.
- Là ổ mạng, không phải ổ vật lý — nên có độ trễ mạng, nhưng tháo lắp giữa các instance rất nhanh.
- Khóa trong một Availability Zone. Volume ở
us-east-1akhông gắn được vào instance ởus-east-1b. Muốn chuyển AZ phải đi qua snapshot. - Mỗi lúc gắn vào một instance (ngoại lệ duy nhất: Multi-Attach ở mục 7.6).
- Dung lượng và IOPS được provision trước — bạn trả tiền theo mức đã đặt, không phải theo mức thực dùng.
Câu hỏi rất hay gặp: "volume ở AZ này không gắn được vào instance ở AZ kia, vì sao?" Đáp án là EBS bị khóa theo AZ — không phải thiếu quyền IAM, cũng không phải khóa theo region.
Delete on Termination — thuộc tính hay bị hỏi nhất
| Loại volume | Mặc định khi terminate instance |
|---|---|
| Root volume | BỊ XÓA (thuộc tính bật sẵn) |
| Volume gắn thêm | ĐƯỢC GIỮ LẠI (thuộc tính tắt sẵn) |
Cả hai đều đổi được qua console hoặc CLI. Trường hợp dùng thực tế: tắt thuộc tính này trên root volume khi bạn muốn giữ lại toàn bộ dữ liệu hệ điều hành sau khi instance biến mất.
30 GB EBS mỗi tháng (gp2/gp3 hoặc magnetic) trong 12 tháng đầu.
Database PostgreSQL chạy trên EC2, dữ liệu đặt trên một EBS volume riêng chứ không phải root volume. Khi cần nâng cấp máy từ m5.large lên m5.2xlarge: stop máy cũ, detach volume dữ liệu, launch máy mới rồi attach volume sang. Dữ liệu nguyên vẹn, downtime chỉ vài phút. Đây cũng là lý do nên tách dữ liệu ra khỏi root volume — root mặc định bị xóa khi terminate.
EBS Snapshots
Snapshot là bản sao lưu của volume tại một thời điểm. Không bắt buộc phải detach volume trước khi chụp, nhưng bài giảng khuyên nên làm vậy để đảm bảo dữ liệu toàn vẹn.
Công dụng quan trọng nhất: snapshot copy được sang AZ khác hoặc region khác — đây chính là cách di chuyển dữ liệu EBS vượt qua giới hạn AZ, và là nền của kiến trúc disaster recovery.
Ba tính năng đi kèm
| Tính năng | Làm gì | Con số cần nhớ |
|---|---|---|
| EBS Snapshot Archive | Chuyển snapshot sang tầng lưu trữ lạnh | Rẻ hơn ~75%, khôi phục mất 24–72 giờ |
| Recycle Bin | Giữ lại snapshot đã xóa để khôi phục khi lỡ tay | Thời gian giữ từ 1 ngày đến 1 năm |
| Fast Snapshot Restore (FSR) | Khởi tạo trước toàn bộ snapshot để lần đọc đầu không bị chậm | Rất đắt — chỉ dùng khi thật cần |
Snapshot có tính tăng dần (incremental): lần đầu chụp toàn bộ, các lần sau chỉ lưu những block đã thay đổi. Nhờ vậy chụp thường xuyên không tốn nhiều tiền như tưởng. Dữ liệu được AWS lưu trên S3 nhưng bạn không nhìn thấy bucket đó.
"Chuyển volume sang AZ khác" → snapshot rồi tạo volume mới từ snapshot. "Sao lưu sang region khác cho DR" → copy snapshot sang region. "Snapshot cũ ít dùng, muốn giảm chi phí" → Snapshot Archive.
Chính sách sao lưu điển hình: snapshot tự động lúc 2h sáng mỗi ngày (qua Data Lifecycle Manager), giữ 7 bản gần nhất; mỗi Chủ nhật copy một bản sang region Tokyo cho tình huống thảm họa. Khi có người xóa nhầm dữ liệu lúc 10h sáng, bạn khôi phục về bản 2h — mất tối đa 8 tiếng dữ liệu. Con số 8 tiếng đó chính là RPO, khái niệm sẽ học kỹ ở Section 28.
AMI — Amazon Machine Image
AMI là bản chụp toàn bộ một instance đã được tùy biến: hệ điều hành, phần mềm đã cài, cấu hình, công cụ giám sát. Launch instance từ AMI riêng thì máy lên là dùng được ngay, không phải chờ User Data cài từ đầu.
AMI gắn với một region cụ thể. Không thể dùng AMI ở us-east-1 để launch instance ở region khác. Cách xử lý: copy AMI sang region đích rồi mới dùng.
Ba nguồn AMI
- Public AMI — do AWS cung cấp (Amazon Linux, Ubuntu…)
- AMI của bạn — tự tạo và tự bảo trì
- AWS Marketplace AMI — do bên thứ ba tạo, có thể mất phí
Quy trình tạo AMI
- Launch một instance và tùy biến nó theo ý muốn
- Stop instance — để đảm bảo dữ liệu trên đĩa toàn vẹn
- Tạo AMI (thao tác này tự động sinh ra các EBS snapshot)
- Dùng AMI đó launch bao nhiêu instance cũng được
Ở Section 8, AMI là thành phần của Launch Template trong Auto Scaling Group. Kết hợp AMI dựng sẵn + User Data cho phần cấu hình riêng là mô hình chuẩn để instance mới lên nhanh nhất.
Golden image: mỗi tháng đội hạ tầng dựng một AMI chuẩn gồm OS đã vá lỗi bảo mật, agent giám sát, cấu hình log và múi giờ. Instance mới lên trong khoảng 40 giây thay vì 4 phút chờ User Data cài từ đầu, và quan trọng hơn là mọi máy trong đội giống hệt nhau — không còn cảnh máy này chạy được máy kia thì không.
EC2 Instance Store
EBS là ổ mạng nên hiệu năng bị giới hạn bởi đường truyền. Khi cần I/O thật sự nhanh, dùng Instance Store — ổ đĩa gắn vật lý vào máy chủ đang chạy instance của bạn.
| Ưu | Nhược |
|---|---|
| Hiệu năng I/O tốt nhất trong mọi lựa chọn — có thể đạt hàng trăm nghìn tới hàng triệu IOPS | Mất dữ liệu khi stop, hibernate hoặc terminate (ephemeral). Chỉ sống qua reboot. |
| Không tốn băng thông mạng | Hỏng phần cứng là mất dữ liệu — sao lưu và nhân bản là trách nhiệm của bạn |
Dùng khi: buffer, cache, dữ liệu tạm, scratch data — những thứ mất đi cũng tạo lại được.
1. "Cần cache cục bộ hiệu năng cao, chấp nhận mất khi instance terminate" → Instance Store.
2. "Database cần 310.000 IOPS" → cũng là Instance Store, vì con số này vượt mọi loại EBS (io2 Block Express tối đa 256.000).
Cụm Elasticsearch xử lý log: index nằm trên NVMe cục bộ của dòng i4i để đạt tốc độ ghi cao nhất, và mỗi shard có bản sao trên node khác. Một node chết thì dữ liệu tự dựng lại từ bản sao — đúng tinh thần Instance Store là bạn tự lo độ bền.
Encode video 4K: file trung gian hàng trăm GB ghi vào Instance Store, xong việc thì bỏ. Dùng EBS cho việc này vừa chậm hơn vừa tốn tiền vô ích.
EBS Volume Types
Sáu loại, chia hai nhóm SSD và HDD. Mỗi volume được đặc trưng bởi ba thứ: dung lượng · throughput · IOPS.
Chỉ SSD làm được boot volume: gp2, gp3, io1, io2 (cùng loại Magnetic cũ). HDD (st1, sc1) KHÔNG thể làm boot volume. Đây là câu hỏi xuất hiện gần như chắc chắn.
Nhóm SSD — cho workload cần IOPS
| Loại | Dung lượng | IOPS tối đa | Đặc điểm |
|---|---|---|---|
| gp2 | 1 GiB – 16 TiB | 16.000 | IOPS gắn với dung lượng (3 IOPS/GB); volume nhỏ burst được lên 3.000 |
| gp3 | 1 GiB – 16 TiB | 16.000 | Nền 3.000 IOPS + 125 MiB/s; tăng IOPS và throughput độc lập với dung lượng |
| io1 | 4 GiB – 16 TiB | 64.000 (Nitro) / 32.000 (khác) | Provisioned IOPS, tăng độc lập với dung lượng |
| io2 | 4 GiB – 16 TiB | 64.000 | Bền hơn io1, nhiều IOPS/GiB hơn, cùng giá io1 |
| io2 Block Express | 4 GiB – 64 TiB | 256.000 | Độ trễ dưới một mili giây; tỷ lệ IOPS:GiB tới 1.000:1 |
Khi nào io1/io2 thay vì gp3: ứng dụng nghiệp vụ quan trọng cần IOPS ổn định, hoặc cần hơn 16.000 IOPS — đặc biệt là database nhạy cảm với hiệu năng lưu trữ.
Nhóm HDD — cho workload cần throughput, giá rẻ
| Loại | Dung lượng | Giới hạn | Dùng khi |
|---|---|---|---|
| st1 (Throughput Optimized) | 125 GiB – 16 TiB | Throughput tối đa 500 MiB/s, IOPS tối đa 500 | Big Data, data warehouse, xử lý log — truy cập thường xuyên, nặng throughput |
| sc1 (Cold HDD) | 125 GiB – 16 TiB | Throughput tối đa 250 MiB/s, IOPS tối đa 250 | Dữ liệu ít truy cập, ưu tiên giá rẻ nhất |
gp3 hơn gp2 ở chỗ tách IOPS/throughput khỏi dung lượng — với gp2 muốn nhiều IOPS phải mua volume to hơn mức cần. Đề hỏi "giảm chi phí mà vẫn giữ IOPS" thì gp3 là đáp án hay gặp.
st1 = throughput, sc1 = siêu rẻ (cold). Cả hai đều không boot được.
Cùng một hệ thống thường dùng nhiều loại volume cho nhiều việc: root volume gp3 30 GB cho hệ điều hành; database MySQL dùng io2 provision 20.000 IOPS; kho log Elasticsearch dùng st1 4 TB vì ghi tuần tự và cần throughput chứ không cần IOPS; bản lưu trữ tuân thủ giữ 7 năm dùng sc1 cho rẻ. Chọn đúng loại cho từng vai trò là cách tiết kiệm dễ thấy nhất trong hóa đơn EBS.
EBS Multi-Attach
Ngoại lệ duy nhất của quy tắc "một volume — một instance": Multi-Attach cho phép gắn cùng một volume vào nhiều EC2 instance, mỗi máy đều có toàn quyền đọc và ghi.
| Ràng buộc | Chi tiết |
|---|---|
| Loại volume | Chỉ io1 / io2 |
| Phạm vi | Các instance phải nằm trong CÙNG một AZ |
| Số lượng | Tối đa 16 instance cùng lúc |
| Hệ thống file | Bắt buộc dùng cluster-aware file system — không dùng được XFS hay EXT4 thông thường |
Dùng khi: tăng tính sẵn sàng cho ứng dụng Linux dạng cluster (ví dụ Teradata). Ứng dụng phải tự quản lý việc ghi đồng thời.
Multi-Attach chia sẻ được nhưng chỉ trong một AZ và tối đa 16 máy. Nếu đề nói "nhiều AZ" hoặc "hàng trăm instance" thì đáp án là EFS, không phải Multi-Attach.
EBS Encryption
Khi một volume được mã hóa, bốn thứ tự động được mã hóa theo:
- Dữ liệu nằm yên trong volume (at rest)
- Dữ liệu truyền giữa instance và volume (in flight)
- Mọi snapshot tạo ra từ volume đó
- Mọi volume tạo ra từ những snapshot đó
Mã hóa và giải mã diễn ra trong suốt — bạn không phải làm gì thêm, và tác động tới độ trễ là không đáng kể. Khóa lấy từ KMS, thuật toán AES-256.
Mã hóa một volume đang KHÔNG được mã hóa
Không có nút "bật mã hóa" cho volume đã tồn tại. Quy trình bốn bước là câu hỏi ra thi:
- Tạo snapshot của volume chưa mã hóa
- Copy snapshot đó và tick tùy chọn mã hóa cho bản copy
- Tạo volume mới từ snapshot đã mã hóa
- Gắn volume mới vào instance
Có thể bật Encryption by default ở mức tài khoản cho từng region — từ đó mọi volume mới đều được mã hóa tự động, khỏi phải nhớ tick.
Một bệnh viện lưu hồ sơ bệnh án trên EC2 và phải chứng minh với đoàn kiểm toán rằng dữ liệu được mã hóa at-rest. Sau khi bật Encryption by default ở mức tài khoản cho region đang dùng, mọi volume và snapshot mới sinh ra đều tự động được mã hóa — đội kiểm toán chỉ cần xem một cấu hình thay vì đi kiểm từng volume một.
Amazon EFS
EFS = Elastic File System, một NFS được quản lý mà bạn mount lên nhiều EC2 instance cùng lúc, ở nhiều AZ khác nhau. Đây là điểm khác biệt cốt lõi so với EBS.
Đặc điểm
- Tính sẵn sàng cao, tự động co giãn — không cần dự trù dung lượng, trả tiền theo mức dùng thật.
- Đắt — khoảng gấp 3 lần gp2.
- Dùng giao thức NFSv4.1, kiểm soát truy cập bằng Security Group.
- Chỉ tương thích AMI Linux (hệ thống file POSIX) — không dùng được với Windows.
- Mã hóa at rest bằng KMS.
- Quy mô: hàng nghìn client NFS đồng thời, throughput trên 10 GB/s, mở rộng tới petabyte.
Dùng khi: quản trị nội dung, web serving, chia sẻ dữ liệu giữa nhiều máy, WordPress nhiều instance.
Performance mode — chọn lúc tạo, không đổi được
| Mode | Đặc điểm | Dùng cho |
|---|---|---|
| General Purpose (mặc định) | Độ trễ thấp | Web server, CMS — nhạy cảm với độ trễ |
| Max I/O | Độ trễ cao hơn nhưng throughput lớn hơn | Big data, xử lý media — song song cao |
Throughput mode
| Mode | Cách hoạt động |
|---|---|
| Bursting | Throughput tỷ lệ với dung lượng: 1 TB ≈ 50 MiB/s, burst lên tới 100 MiB/s |
| Provisioned | Tự đặt throughput bất kể dung lượng — ví dụ 1 GiB/s cho 1 TB dữ liệu |
| Elastic | Tự co giãn theo tải, tới 3 GiB/s đọc và 1 GiB/s ghi — dành cho workload khó dự đoán |
Storage class & lifecycle
| Tầng | Dành cho |
|---|---|
| Standard | File truy cập thường xuyên |
| EFS-IA (Infrequent Access) | Lưu rẻ hơn nhiều nhưng tính phí khi đọc lại |
| Archive | File chỉ đụng tới vài lần mỗi năm — rẻ hơn ~50% |
Chuyển file giữa các tầng bằng Lifecycle Policy (ví dụ: không truy cập 60 ngày thì đẩy sang IA).
Standard vs One Zone
| EFS Standard | EFS One Zone | |
|---|---|---|
| Phạm vi | Nhiều AZ | Một AZ duy nhất |
| Dùng cho | Production | Dev, test |
| Backup | Tùy chọn | Bật sẵn theo mặc định |
| Chi phí | Cao | Ghép với IA (One Zone-IA) tiết kiệm trên 90% |
WordPress chạy 6 instance sau ALB: nếu mỗi máy dùng EBS riêng, khách upload ảnh rơi vào máy số 1 thì lần sau request vào máy số 2 sẽ trả về 404. Mount chung một EFS vào /wp-content/uploads là hết vấn đề — đây là ca dùng EFS kinh điển nhất.
Trường hợp khác cùng bản chất: thư mục chung cho render farm, hoặc cache build dùng chung giữa nhiều CI runner.
EBS vs EFS vs Instance Store
| EBS | EFS | Instance Store | |
|---|---|---|---|
| Bản chất | Ổ mạng (block) | Hệ thống file mạng (NFS) | Ổ vật lý gắn vào host |
| Số instance | 1 (Multi-Attach io1/io2: tối đa 16, cùng AZ) | Hàng trăm, nhiều AZ | 1 |
| Phạm vi | Khóa theo AZ | Nhiều AZ | Gắn cứng vào một máy |
| Độ bền | Bền, sống sau terminate | Bền | Mất khi stop/terminate |
| Hiệu năng | Tốt, giới hạn theo loại | Tốt, mở rộng theo quy mô | Cao nhất |
| Hệ điều hành | Linux & Windows | Chỉ Linux | Linux & Windows |
| Chi phí | Trung bình | Cao (~3× gp2) | Đã gộp trong giá instance |
| Chuyển AZ | Qua snapshot | Không cần — vốn đã đa AZ | Không chuyển được |
1. Nhiều máy cùng đọc ghi một tập dữ liệu? → EFS.
2. Cần I/O cao nhất và chấp nhận mất dữ liệu? → Instance Store.
3. Còn lại → EBS.
Map từ khóa & cheat sheet
| Đề nhắc đến… | Nghĩ ngay tới |
|---|---|
| "NFS drive dùng chung cho nhiều instance ở nhiều AZ" | EFS |
| "cache cục bộ hiệu năng cao, mất cũng được" | Instance Store |
| "cần 310.000 IOPS" | Instance Store (vượt trần mọi loại EBS) |
| "cần hơn 16.000 IOPS, database quan trọng" | io1 / io2 |
| "muốn tăng IOPS mà không phải tăng dung lượng" | gp3 |
| "big data, xử lý log, throughput cao, giá rẻ" | st1 |
| "dữ liệu ít truy cập, rẻ nhất có thể" | sc1 |
| "boot volume dùng loại nào" | gp2, gp3, io1, io2 — không phải HDD |
| "mã hóa volume đang chưa mã hóa" | Snapshot → copy có mã hóa → tạo volume mới |
| "volume không gắn được sang instance ở AZ khác" | EBS khóa theo AZ; chuyển bằng snapshot |
| "terminate instance, dữ liệu còn không" | Root xóa, volume gắn thêm giữ lại |
| "dùng AMI ở region khác" | Phải copy AMI sang region đó trước |
| "nhiều instance ghi chung một volume trong cùng AZ" | EBS Multi-Attach (io1/io2, tối đa 16) |
| "file system cho Windows" | Không phải EFS — sẽ học FSx ở Section 16 |
Cheat sheet 60 giây
- EBS = ổ mạng, khóa theo AZ, 1 instance, dữ liệu sống sau terminate.
- Terminate: root bị xóa, volume gắn thêm được giữ.
- Chuyển AZ hoặc region → snapshot. Snapshot Archive rẻ hơn 75%, khôi phục 24–72 giờ.
- AMI gắn với region — muốn dùng nơi khác phải copy.
- Instance Store = nhanh nhất, mất khi stop. Dùng cho cache, buffer, dữ liệu tạm.
- IOPS trần: gp2/gp3 16.000 · io1/io2 64.000 · io2 Block Express 256.000 · trên nữa → Instance Store.
- Boot volume: chỉ gp2, gp3, io1, io2.
- Multi-Attach: io1/io2, cùng AZ, tối đa 16 instance, cần cluster-aware file system.
- Mã hóa: at rest + in flight + snapshot + volume phái sinh, dùng KMS AES-256.
- EFS: NFS, nhiều AZ, chỉ Linux, đắt gấp ~3 gp2, dùng Security Group để kiểm soát.
- EFS One Zone + IA tiết kiệm trên 90%, hợp cho môi trường dev.
Sáu câu tự kiểm tra trước khi qua file quiz
1. Volume gắn thêm (không phải root) sẽ ra sao khi terminate instance?
2. Database cần 40.000 IOPS ổn định. Chọn loại volume nào?
3. Ứng dụng WordPress chạy trên 6 instance ở 3 AZ, cần chung thư mục upload. Dùng gì?
4. Muốn mã hóa một volume đang chạy chưa mã hóa. Làm thế nào?
5. st1 có làm boot volume được không?
6. AMI tạo ở Singapore, muốn launch instance ở Tokyo. Làm sao?
Đáp án: (1) Được giữ lại — chỉ root volume mới bị xóa theo mặc định. (2) io1 hoặc io2 (trần 64.000 IOPS); gp2/gp3 chỉ tới 16.000 nên không đủ. (3) EFS — nhiều instance, nhiều AZ, dùng chung file system. (4) Snapshot → copy snapshot có bật mã hóa → tạo volume mới từ snapshot đó → gắn vào instance. (5) Không — HDD không dùng làm boot volume, chỉ gp2/gp3/io1/io2. (6) Copy AMI sang region Tokyo rồi launch từ bản copy.