So sánh EBS gp2 và gp3: Cách chọn đúng loại ổ đĩa cho workload AWS của bạn

Khi provision một EC2 instance mới, bạn sẽ thấy hai lựa chọn General Purpose SSD: gp2 và gp3. Câu hỏi thực tế không phải là 'cái nào tốt hơn' mà là 'cái nào phù hợp với workload của tôi và không lãng phí tiền' — đặc biệt khi bạn đang chạy database hoặc ứng dụng cần IOPS cao nhưng không cần volume lớn.

TL;DR: So sánh nhanh EBS gp2 và gp3

Tiêu chí gp2 gp3
IOPS baseline 3 IOPS/GB, tối đa 16.000 IOPS 3.000 IOPS cố định (bất kể dung lượng)
Scale IOPS độc lập với dung lượng Không — IOPS gắn liền với GB Có — tối đa 16.000 IOPS độc lập
Throughput tối đa 250 MiB/s 1.000 MiB/s
Chi phí tổng thể Cao hơn với volume nhỏ cần IOPS cao Thấp hơn trong hầu hết trường hợp
Burst IOPS Có (credit-based, tối đa 3.000 IOPS) Không cần — baseline đã là 3.000 IOPS
Phù hợp nhất Workload legacy, volume lớn ổn định Hầu hết workload mới, database, production

Cơ chế hoạt động của EBS gp2 và gp3

Trước khi quyết định, bạn cần hiểu tại sao hai loại này lại khác nhau về mặt kiến trúc — không chỉ về con số trên paper.

gp2: IOPS gắn chặt với dung lượng

gp2 sử dụng mô hình burst credit. Mỗi GB dung lượng tạo ra 3 IOPS baseline, và volume tích lũy I/O credit khi không dùng hết baseline. Khi workload spike, volume dùng credit đó để burst lên tối đa 3.000 IOPS (với volume nhỏ hơn 1 TB). Volume từ 1 TB trở lên đạt baseline 3.000 IOPS mà không cần burst.

Vấn đề thực tế: nếu bạn cần 6.000 IOPS ổn định nhưng chỉ cần 50 GB storage, bạn buộc phải provision 2.000 GB để đạt đủ IOPS baseline. Đây là lãng phí chi phí điển hình với gp2.

gp3: IOPS và throughput độc lập

gp3 tách biệt hoàn toàn ba chiều: dung lượng, IOPS, và throughput. Mọi volume gp3 đều có 3.000 IOPS và 125 MiB/s throughput mặc định — bất kể bạn provision 1 GB hay 1 TB. Bạn có thể tăng IOPS lên tối đa 16.000 và throughput lên tối đa 1.000 MiB/s mà không cần thay đổi dung lượng.

graph LR subgraph gp2["gp2: IOPS phụ thuộc dung lượng"] G2S["Storage: 100 GB"] -->|"3 IOPS/GB"| G2I["Baseline: 300 IOPS"] G2S2["Storage: 2.000 GB"] -->|"3 IOPS/GB"| G2I2["Baseline: 6.000 IOPS"] G2I -->|"Burst credit"| G2B["Burst: tối đa 3.000 IOPS"] end subgraph gp3["gp3: Ba chiều độc lập"] G3S["Storage: 100 GB"] --> G3BASE["Baseline: 3.000 IOPS
125 MiB/s throughput"] G3BASE -->|"Tăng độc lập"| G3I["IOPS: tối đa 16.000"] G3BASE -->|"Tăng độc lập"| G3T["Throughput: tối đa 1.000 MiB/s"] end
  1. gp2 (trái): IOPS tăng tuyến tính theo GB — muốn nhiều IOPS phải mua nhiều storage, dù không cần.
  2. gp3 (phải): Ba chiều độc lập — bạn chỉ trả tiền cho những gì thực sự cần.
  3. Điểm giao nhau: Với volume lớn (thường trên 1 TB) và IOPS vừa phải, gp2 có thể đủ dùng mà không cần tăng thêm chi phí IOPS.

Tại sao gp3 thường rẻ hơn khi chọn EBS gp2 và gp3

Pricing thay đổi theo region và thời gian — luôn kiểm tra trang pricing chính thức của AWS. Tuy nhiên, về mặt cấu trúc chi phí, gp3 có lợi thế rõ ràng trong hầu hết tình huống:

  • gp3 có giá per-GB thấp hơn gp2 (theo AWS documentation tại thời điểm ra mắt gp3).
  • 3.000 IOPS và 125 MiB/s throughput đã được bao gồm trong giá base — không tính thêm.
  • Bạn chỉ trả thêm khi cần IOPS hoặc throughput vượt mức baseline.

Trường hợp gp2 có thể rẻ hơn: volume rất lớn (nhiều TB) với IOPS yêu cầu thấp, nơi baseline gp2 đã đủ và bạn không cần tăng thêm. Nhưng trong thực tế, đây là trường hợp hiếm gặp với workload production hiện đại.

gp3 giống như thuê văn phòng theo diện tích thực dùng, còn gp2 buộc bạn thuê cả tầng chỉ để có đủ số ổ cắm điện.

Khi nào nên chọn gp3 — và khi nào gp2 vẫn hợp lý

Chọn gp3 khi:

  • Bạn đang provision volume mới — không có lý do kỹ thuật nào để chọn gp2 cho workload mới.
  • Workload cần IOPS cao nhưng dung lượng nhỏ (database OLTP, Redis, Elasticsearch).
  • Bạn muốn kiểm soát chi phí chính xác: chỉ trả cho IOPS và throughput thực sự cần.
  • Throughput quan trọng — gp3 hỗ trợ tối đa 1.000 MiB/s so với 250 MiB/s của gp2.

gp2 vẫn có thể giữ nguyên khi:

  • Volume đang chạy ổn định trong production và migration có rủi ro downtime không chấp nhận được.
  • Volume rất lớn với IOPS yêu cầu thấp — baseline gp2 đã đủ và chi phí migration không justify.
  • Bạn đang dùng snapshot/AMI cũ và chưa có kế hoạch rebuild.

Migrate từ gp2 sang gp3 không cần downtime

AWS hỗ trợ thay đổi volume type trong khi volume đang được attach và sử dụng — thông qua tính năng Elastic Volumes. Quá trình này không yêu cầu detach volume hay restart instance.

stateDiagram-v2 [*] --> Available : Volume gp2 đang chạy Available --> Modifying : aws ec2 modify-volume Modifying --> Optimizing : Thay đổi type được chấp nhận Optimizing --> Completed : Migration hoàn tất Completed --> [*] : Volume là gp3 note right of Modifying : I/O không bị gián đoạn note right of Optimizing : Performance có thể giảm nhẹ
  1. Khởi tạo modification: Gọi modify-volume với type mới và các tham số IOPS/throughput mong muốn.
  2. Trạng thái 'modifying': Volume vẫn hoạt động bình thường. I/O không bị gián đoạn.
  3. Trạng thái 'optimizing': AWS đang migrate data nội bộ. Performance có thể giảm nhẹ.
  4. Trạng thái 'completed': Volume đã là gp3 với cấu hình mới.

CLI: Kiểm tra volume hiện tại

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].{VolumeId:VolumeId,Size:Size,Iops:Iops,Type:VolumeType}' \
  --output table \
  --region us-east-1

CLI: Migrate một volume từ gp2 sang gp3

aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type gp3 \
  --iops 3000 \
  --throughput 125 \
  --region us-east-1

Lệnh trên migrate volume sang gp3 với baseline mặc định (3.000 IOPS, 125 MiB/s). Nếu workload của bạn cần nhiều hơn, điều chỉnh --iops và --throughput theo nhu cầu thực tế.

CLI: Theo dõi trạng thái migration

aws ec2 describe-volumes-modifications \
  --volume-ids vol-0123456789abcdef0 \
  --query 'VolumesModifications[*].{VolumeId:VolumeId,ModificationState:ModificationState,Progress:Progress}' \
  --output table \
  --region us-east-1

IAM: Quyền tối thiểu để thực hiện migration

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeVolumes",
        "ec2:ModifyVolume",
        "ec2:DescribeVolumesModifications"
      ],
      "Resource": "*"
    }
  ]
}

Lưu ý: ec2:DescribeVolumes và ec2:DescribeVolumesModifications là List/Read actions — theo AWS Service Authorization Reference, các action này yêu cầu "Resource": "*". ec2:ModifyVolume hỗ trợ resource-level permission với ARN volume cụ thể nếu bạn muốn giới hạn phạm vi.

Tình huống thực tế: Sai lầm phổ biến khi chọn EBS gp2 và gp3

Đây là pattern hay gặp: team provision RDS instance với storage 100 GB gp2, sau đó thắc mắc tại sao database chậm dù CPU và RAM còn dư nhiều. CloudWatch metric VolumeQueueLength liên tục cao, nhưng không ai nhìn vào IOPS.

Chẩn đoán ban đầu thường là 'cần nâng instance type' — sai. 100 GB gp2 chỉ cho 300 IOPS baseline. Khi credit burst cạn kiệt (thường sau vài giờ với workload liên tục), database throttle xuống 300 IOPS và mọi query bắt đầu queue.

Fix đúng: migrate sang gp3 với 3.000 IOPS baseline — không cần tăng storage, không cần tăng instance. Chi phí thực tế giảm vì gp3 per-GB rẻ hơn gp2, và 3.000 IOPS đã bao gồm trong giá base.

Đây là điểm mấu chốt: gp2 burst credit cạn kiệt im lặng — không có alarm mặc định, không có log rõ ràng. Bạn chỉ thấy latency tăng dần và queue length cao.

CLI: Kiểm tra BurstBalance của volume gp2

aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name BurstBalance \
  --dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-02T00:00:00Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

Nếu BurstBalance liên tục dưới 20%, đây là dấu hiệu rõ ràng rằng workload đang vượt baseline và cần migrate sang gp3 hoặc tăng IOPS.

Tối ưu chi phí: Script tìm tất cả volume gp2 trong account

🔽 Click để xem script tìm và báo cáo volume gp2 
#!/bin/bash
# Liệt kê tất cả volume gp2 trong một region
# Mục đích: xác định candidate để migrate sang gp3

REGION=${1:-us-east-1}

echo "=== Tìm volume gp2 trong region: $REGION ==="

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].{
    VolumeId:VolumeId,
    SizeGB:Size,
    IOPS:Iops,
    State:State,
    AvailabilityZone:AvailabilityZone,
    Attachments:Attachments[0].InstanceId
  }' \
  --output table \
  --region "$REGION"

echo ""
echo "Tổng số volume gp2:"
aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'length(Volumes)' \
  --output text \
  --region "$REGION"

Wrap-up: Kết luận về EBS gp2 và gp3

Với workload mới, gp3 là lựa chọn mặc định hợp lý. Khả năng scale IOPS và throughput độc lập với dung lượng giải quyết trực tiếp vấn đề lớn nhất của gp2 — buộc bạn mua storage không cần thiết chỉ để đạt IOPS mong muốn. Chi phí thấp hơn chỉ là thêm lý do.

Với volume gp2 đang chạy, đánh giá BurstBalance metric trước. Nếu credit liên tục cạn kiệt hoặc bạn đang over-provision storage để đạt IOPS, migration sang gp3 thường payback ngay trong tháng đầu tiên.

Bước tiếp theo:

Glossary

Thuật ngữ Giải thích
IOPS Input/Output Operations Per Second — số lượng thao tác đọc/ghi mỗi giây mà volume có thể xử lý.
Burst Credit (gp2) Credit tích lũy khi volume dùng ít hơn baseline IOPS. Dùng để xử lý spike ngắn hạn vượt baseline.
Throughput Lượng data truyền qua volume mỗi giây, đo bằng MiB/s. Khác với IOPS — quan trọng với sequential I/O lớn.
Elastic Volumes Tính năng AWS cho phép thay đổi volume type, size, IOPS, throughput mà không cần detach hoặc restart.
BurstBalance CloudWatch metric của gp2 — phần trăm I/O credit còn lại. Khi về 0, volume throttle xuống baseline IOPS.

Nhận xét

Đăng nhận xét

Bài đăng phổ biến từ blog này

EC2 Không Có Internet Trong Custom VPC: Cách Gắn Internet Gateway và Cập Nhật Route Table

Bạn tạo một custom VPC, launch EC2 instance vào public subnet, SSH vào được — nhưng ping google.com trả về timeout hoàn toàn. Đây là một trong những lỗi phổ biến nhất khi làm việc với EC2 không có internet trong custom VPC, và nguyên nhân gần như luôn nằm ở một trong ba lớp: thiếu Internet Gateway, route table chưa có default route, hoặc Security Group/NACL chặn traffic ra ngoài. TL;DR — EC2 Không Có Internet Trong Custom VPC Lớp kiểm tra Triệu chứng Fix Internet Gateway Không có IGW hoặc IGW chưa attach vào VPC Tạo IGW, attach vào VPC Route Table Không có route 0.0.0.0/0 → igw-xxx Thêm default route trỏ vào IGW Subnet Association Subnet dùng main route table không có IGW route Associate subnet với route table đúng Public IP EC2 không có public IP hoặc Elastic IP Enable auto-assign public IP hoặc gắn EIP Security Group Outbound rule bị xóa hoặc quá hạn chế Thêm outbound rule cho port 80/443 hoặc all...
Đọc thêm

Route 53 Alias vs CNAME: Khi Nào Dùng Alias Record Cho Zone Apex?

Bạn vừa tạo xong một Application Load Balancer và cần trỏ domain về đó — nhưng Route 53 hiện ra hai lựa chọn: CNAME và Alias. Nếu domain là example.com (zone apex), CNAME sẽ không hoạt động theo đúng nghĩa bạn mong đợi, và đây là lý do nhiều kỹ sư mất thời gian debug một vấn đề tưởng như đơn giản. TL;DR — Route 53 Alias vs CNAME Tiêu chí CNAME Alias Record Dùng được ở zone apex ( example.com ) ❌ Không ✅ Có Phí DNS query Tính phí Miễn phí (với AWS targets) Trả về IP hay hostname Hostname IP trực tiếp (resolved nội bộ) Tích hợp health check Route 53 Hạn chế Tích hợp native TTL do người dùng kiểm soát ✅ Có ❌ AWS quản lý Targets hỗ trợ Bất kỳ hostname nào Chỉ AWS resources được liệt kê Cơ Chế Hoạt Động: Route 53 Alias Record Là Gì? Alias record là một extension độc quyền của Route 53, không phải một loại DNS record chuẩn trong RFC. Về mặt kỹ thuật, nó hoạt động như một CNAME nội bộ được Rout...
Đọc thêm