Hiểu Rõ Burstable T3 Instances: CPU Credits Là Gì Và Tại Sao Server Đột Ngột Chậm Lại?

Bạn đang chạy một EC2 T3 instance, mọi thứ hoạt động bình thường, rồi đột nhiên sau một đợt tải cao kéo dài vài giờ, server bắt đầu phản hồi chậm như đang bò — CPU usage nhìn vào chỉ còn 5-10% nhưng latency tăng vọt. Đây không phải lỗi ứng dụng, không phải network issue. Đây là cơ chế CPU Credits của burstable T3 instances đang hoạt động đúng như thiết kế, và nếu bạn chưa hiểu nó, bạn sẽ mất hàng giờ debug sai hướng.

TL;DR — Tóm Tắt Nhanh

Khái niệmGiải thích ngắn
CPU CreditĐơn vị tích lũy cho phép T3 instance burst vượt baseline CPU
Baseline CPUMức CPU được phân bổ liên tục, tùy theo loại instance (ví dụ: t3.micro = 10%)
Credit tích lũyKhi CPU dùng dưới baseline, credits được tích lũy theo thời gian
Credit tiêu haoKhi CPU vượt baseline, credits bị tiêu thụ để duy trì hiệu năng
Credit cạn kiệtInstance bị throttle về đúng mức baseline — đây là lý do server chậm đột ngột
Unlimited modeCho phép burst không giới hạn nhưng phát sinh chi phí khi vượt baseline tích lũy

Cơ Chế CPU Credits Trong T3 Instances Hoạt Động Như Thế Nào

T3 instances thuộc dòng burstable performance instances của AWS. Khác với M5 hay C5 — những loại instance cung cấp CPU cố định liên tục — T3 được thiết kế cho workload có tính chất spiky: phần lớn thời gian idle hoặc tải thấp, thỉnh thoảng cần burst ngắn lên cao.

Cơ chế hoạt động dựa trên một tài khoản credits ảo gắn với mỗi instance:

  • Tích lũy (Earn): Mỗi giờ, instance tự động nhận một lượng CPU credits tương ứng với loại instance. Ví dụ, t3.micro nhận 6 credits/giờ. Credits tích lũy tối đa đến một ngưỡng nhất định (t3.micro tối đa 144 credits).
  • Tiêu thụ (Spend): Mỗi CPU credit cho phép instance chạy ở mức 1 vCPU với 100% utilization trong 1 phút. Khi CPU vượt baseline, credits bị tiêu thụ theo tỷ lệ tương ứng.
  • Throttle khi cạn: Trong chế độ mặc định (standard mode), khi credits về 0, instance bị giới hạn cứng về mức baseline CPU. Không có cảnh báo trước — hiệu năng giảm đột ngột.
Hãy hình dung CPU credits như một bình xăng dự phòng. Xe chạy bình thường dùng xăng chính (baseline). Khi cần tăng tốc, bạn dùng bình dự phòng. Khi bình dự phòng cạn, xe tự động giới hạn tốc độ về mức tiết kiệm nhiên liệu — dù bạn đạp ga đến đâu cũng không ăn thua.
graph LR A["CPU < Baseline"] -->|"Credits tích lũy"| B["Credit Balance tăng"] B --> C{"CPU vượt Baseline?"} C -->|"Có"| D["Credits bị tiêu thụ"] C -->|"Không"| A D --> E{"Balance = 0?"} E -->|"Standard Mode"| F["Throttle về Baseline
Hiệu năng giảm đột ngột"] E -->|"Unlimited Mode"| G["Tiếp tục Burst
Phát sinh Surplus Cost"] F --> H["CPU giảm → Credits phục hồi dần"] H --> A
  1. Earn Phase: CPU dùng dưới baseline → credits tích lũy liên tục theo thời gian thực.
  2. Burst Phase: CPU vượt baseline → credits bị tiêu thụ để duy trì hiệu năng cao hơn mức được cấp phát.
  3. Depletion: Credit balance về 0 → instance bị throttle cứng về đúng mức baseline.
  4. Recovery: Sau khi throttle, nếu CPU giảm xuống dưới baseline, credits bắt đầu tích lũy trở lại — nhưng cần thời gian để phục hồi đủ để burst tiếp.

Baseline CPU Theo Từng Loại T3 Instance

Mỗi loại T3 instance có baseline CPU khác nhau. Đây là thông số quan trọng nhất cần nắm khi chọn instance size cho workload của bạn. Số liệu cụ thể thay đổi theo thời gian — luôn kiểm tra tại tài liệu chính thức của AWS.

Điểm cần lưu ý: baseline được tính theo vCPU. Một t3.large có 2 vCPU với baseline 30% mỗi vCPU — tức là tổng baseline CPU capacity là 60% của 1 vCPU, không phải 60% của 2 vCPU cộng lại. Hiểu sai điểm này dẫn đến việc chọn instance size không phù hợp.

Standard Mode Và Unlimited Mode — Chọn Cái Nào?

T3 instances hỗ trợ hai chế độ hoạt động, và đây là quyết định kiến trúc quan trọng cần đưa ra trước khi deploy.

graph TD A["T3 Instance"] --> B{"Credit Mode"} B -->|"Standard"| C["Credits cạn → Throttle cứng"] B -->|"Unlimited (mặc định T3)"| D["Credits cạn → Tiếp tục Burst"] C --> E["Không phát sinh chi phí thêm"] C --> F["Hiệu năng giới hạn ở Baseline"] D --> G["Surplus Credits bị tính phí"] D --> H["Hiệu năng duy trì nhưng tốn tiền"]
  1. Standard Mode: Instance bị throttle khi credits cạn. Không phát sinh chi phí thêm ngoài giá instance. Phù hợp cho workload thực sự spiky với thời gian idle dài.
  2. Unlimited Mode: Instance có thể burst vượt credit balance. AWS tính phí thêm cho lượng CPU vượt mức baseline tích lũy. T3 instances mặc định chạy ở Unlimited mode kể từ khi ra mắt.
  3. Chi phí Unlimited: Khi credit balance âm, bạn bị tính phí theo mức surplus credits. Pricing thay đổi theo region và instance type — kiểm tra AWS pricing page.
  4. Rủi ro Unlimited: Một instance chạy sustained high CPU trong Unlimited mode có thể phát sinh hóa đơn bất ngờ đáng kể.

T3 instances được tạo mới mặc định ở Unlimited mode. Đây là điểm khác biệt so với T2 — và là nguồn gốc của nhiều hóa đơn bất ngờ khi migration từ T2 lên T3 mà không kiểm tra lại cấu hình.

Chẩn Đoán Vấn Đề: Tại Sao Server Đột Ngột Chậm Lại

Đây là pattern điển hình mà nhiều người gặp phải nhưng debug sai hướng trong nhiều giờ.

Triệu chứng quan sát được

  • CPU utilization trong CloudWatch nhìn bình thường (thậm chí thấp)
  • Application latency tăng đột biến
  • Không có error log rõ ràng từ ứng dụng
  • Reboot instance thì mọi thứ lại bình thường trong vài giờ đầu

Lý do reboot giúp ích: khi instance khởi động lại, credit balance được reset về mức khởi đầu (không phải về 0 — AWS cấp một lượng credits ban đầu). Nhưng đây chỉ là giải pháp tạm thời, không phải fix thực sự.

Chẩn đoán đúng hướng

Metric cần xem đầu tiên không phải CPUUtilization mà là CPUCreditBalance và CPUSurplusCreditsCharged. Nếu CPUCreditBalance về 0 đúng vào thời điểm latency tăng vọt, bạn đã tìm ra nguyên nhân.

# Kiểm tra CPUCreditBalance của instance trong 24 giờ qua
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-16T00:00:00Z \
  --period 3600 \
  --statistics Minimum \
  --region us-east-1
# Kiểm tra CPUSurplusCreditsCharged để xác định có đang ở Unlimited mode không
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUSurplusCreditsCharged \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-16T00:00:00Z \
  --period 3600 \
  --statistics Sum \
  --region us-east-1
# Kiểm tra chế độ credit hiện tại của instance
aws ec2 describe-instance-credit-specifications \
  --instance-ids i-1234567890abcdef0 \
  --region us-east-1
graph TD A["Triệu chứng: Latency tăng
không có error log"] --> B["Kiểm tra CPUCreditBalance"] B --> C{"Balance về 0
đúng thời điểm sự cố?"} C -->|"Có"| D["Xác nhận: Credit Depletion"] C -->|"Không"| E["Tìm nguyên nhân khác
(memory, disk, network)"] D --> F["Kiểm tra Credit Mode"] F --> G{"Standard hay Unlimited?"} G -->|"Standard"| H["Instance bị Throttle
Đánh giá lại instance type"] G -->|"Unlimited"| I["Kiểm tra CPUSurplusCreditsCharged
Đánh giá chi phí vs hiệu năng"]
  1. Bắt đầu từ triệu chứng: latency tăng bất thường mà không có error log rõ ràng.
  2. Kiểm tra CPUCreditBalance — nếu về 0 đúng thời điểm sự cố, đây là nguyên nhân.
  3. Xác định instance đang ở Standard hay Unlimited mode.
  4. Nếu Standard: instance đang bị throttle — cần đánh giá lại workload hoặc upgrade instance type.
  5. Nếu Unlimited: instance đang burst nhưng phát sinh chi phí — kiểm tra CPUSurplusCreditsCharged.
  6. Quyết định: chuyển sang instance type phù hợp hơn, hoặc điều chỉnh credit mode.

Thay Đổi Credit Mode Trên Instance Đang Chạy

Bạn có thể thay đổi credit mode mà không cần stop instance — thay đổi có hiệu lực ngay lập tức.

# Chuyển instance về Standard mode (tắt Unlimited)
aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications InstanceId=i-1234567890abcdef0,CpuCredits=standard \
  --region us-east-1
# Chuyển instance sang Unlimited mode
aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications InstanceId=i-1234567890abcdef0,CpuCredits=unlimited \
  --region us-east-1
# Kiểm tra lại sau khi thay đổi
aws ec2 describe-instance-credit-specifications \
  --instance-ids i-1234567890abcdef0 \
  --region us-east-1

Thiết Lập CloudWatch Alarm Để Phát Hiện Sớm

Đừng để đến khi người dùng báo cáo chậm mới biết credits cạn. Thiết lập alarm trước khi credit balance về 0 để có thời gian phản ứng.

# Tạo alarm cảnh báo khi CPUCreditBalance xuống dưới ngưỡng cảnh báo
aws cloudwatch put-metric-alarm \
  --alarm-name 'T3-LowCPUCreditBalance-i-1234567890abcdef0' \
  --alarm-description 'CPU Credit Balance thap - nguy co bi throttle' \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --statistic Minimum \
  --period 300 \
  --evaluation-periods 3 \
  --threshold 30 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:ops-alerts \
  --region us-east-1

Ngưỡng 30 credits là ví dụ — bạn cần điều chỉnh dựa trên baseline rate của instance type cụ thể và thời gian phản ứng mong muốn của team.

IAM Policy Tối Thiểu Để Giám Sát T3 Credits

Nếu bạn cần cấp quyền cho một role monitoring hoặc script tự động hóa để đọc thông tin credit và điều chỉnh cấu hình:

🔽 Xem IAM Policy mẫu 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadCreditMetrics",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:GetMetricData",
        "cloudwatch:PutMetricAlarm"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DescribeCreditSpec",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstanceCreditSpecifications",
        "ec2:DescribeInstances"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ModifyCreditSpec",
      "Effect": "Allow",
      "Action": [
        "ec2:ModifyInstanceCreditSpecification"
      ],
      "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*"
    }
  ]
}

Lưu ý: DescribeInstanceCreditSpecifications và DescribeInstances yêu cầu Resource: * vì đây là List/Describe actions không hỗ trợ resource-level restriction. Luôn kiểm tra AWS Service Authorization Reference để xác nhận trước khi áp dụng.

Khi Nào Nên Dùng T3 Và Khi Nào Nên Chuyển Sang Instance Type Khác

T3 không phải lựa chọn tệ — nó chỉ bị dùng sai. Nếu workload của bạn cần CPU cao liên tục (sustained), T3 sẽ luôn là lựa chọn đắt hơn và kém hiệu năng hơn so với M5 hay C5 cùng mức giá.

graph TD A["Phân tích CPU Usage
từ CloudWatch (1-2 tuần)"] --> B{"CPU trung bình vs Baseline"} B -->|"Thường xuyên dưới Baseline"| C["T3 Standard
Tối ưu chi phí"] B -->|"Gần Baseline, có spike ngắn"| D["T3 Unlimited
hoặc tăng instance size"] B -->|"Liên tục vượt Baseline"| E{"Đặc tính Workload"} E -->|"CPU-intensive"| F["Chuyển sang C5/C6i"] E -->|"General Purpose"| G["Chuyển sang M5/M6i"] E -->|"Memory-intensive"| H["Chuyển sang R5/R6i"]
  1. Nếu CPU usage trung bình dưới baseline của instance type đang dùng → T3 Standard là lựa chọn tối ưu về chi phí.
  2. Nếu CPU usage trung bình gần hoặc vượt baseline nhưng có spike ngắn → T3 Unlimited hoặc xem xét upgrade size.
  3. Nếu workload cần CPU cao liên tục (ví dụ: video encoding, ML inference, database nặng) → chuyển sang M5, C5, hoặc R5 tùy đặc tính workload.
  4. Dùng CloudWatch metrics thực tế từ ít nhất 1-2 tuần để đưa ra quyết định, không dựa vào ước tính.

Wrap-Up: Hiểu CPU Credits Để Không Debug Sai Hướng

Cơ chế CPU Credits của T3 instances được thiết kế hợp lý cho đúng loại workload — nhưng nó hoàn toàn vô hình nếu bạn chỉ nhìn vào CPUUtilization. Khi server đột ngột chậm lại mà không có error log rõ ràng, CPUCreditBalance là metric đầu tiên cần kiểm tra, không phải memory hay disk.

Ba hành động cần làm ngay:

  1. Kiểm tra credit mode hiện tại của tất cả T3 instances trong môi trường production.
  2. Thiết lập CloudWatch alarm cho CPUCreditBalance trước khi sự cố xảy ra.
  3. Đánh giá lại instance type nếu workload có CPU usage sustained cao hơn baseline.

Tham khảo thêm tại AWS Burstable Performance Instances documentation để có thông số baseline và credit rate chính xác nhất cho từng instance type.

Glossary — Thuật Ngữ Chính

Thuật ngữĐịnh nghĩa
CPU CreditĐơn vị tích lũy cho phép T3 instance sử dụng CPU vượt mức baseline trong thời gian ngắn
Baseline CPUMức CPU được đảm bảo liên tục cho một instance type cụ thể, tính theo phần trăm vCPU
BurstTrạng thái instance sử dụng CPU vượt baseline bằng cách tiêu thụ credits tích lũy
Standard ModeChế độ hoạt động mặc định của T2 — instance bị throttle về baseline khi credits cạn, không phát sinh chi phí thêm
Unlimited ModeChế độ mặc định của T3 — cho phép burst vượt credit balance nhưng phát sinh chi phí surplus credits
CPUCreditBalanceCloudWatch metric theo dõi số credits còn lại của instance tại thời điểm hiện tại

Nhận xét

Đăng nhận xét

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

AWS KMS: Nên Dùng AWS Managed Key hay Customer Managed Key để Mã Hóa S3?

Bạn vừa được yêu cầu bật mã hóa cho S3 bucket chứa dữ liệu nhạy cảm. Console hiện ra ba lựa chọn: SSE-S3, SSE-KMS với AWS Managed Key, SSE-KMS với Customer Managed Key. Câu hỏi thực tế không phải là 'mã hóa có cần thiết không' mà là 'chọn loại key nào, và cái đó sẽ tốn bao nhiêu tiền mỗi tháng khi traffic tăng lên.' TL;DR — AWS KMS Key Types cho S3 Tiêu chí AWS Managed Key (aws/s3) Customer Managed Key (CMK) Ai quản lý key? AWS tự động quản lý Bạn tự tạo và quản lý Phí lưu trữ key Miễn phí ~$1/tháng/key Phí API call Miễn phí (không tính phí API) $0.03 / 10,000 requests Key rotation Tự động hàng năm, không tắt được Tùy chọn, có thể bật/tắt Key policy tùy chỉnh Không Có Cross-account access Không hỗ trợ Có h...
Đọc thêm

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

Auto Scaling Group Health Check: Tại Sao Instance Bị Terminate Dù Đang Chạy Bình Thường?

Bạn nhìn vào console và thấy ASG liên tục terminate instance — nhưng instance đó rõ ràng đang chạy, SSH được, log không có lỗi. Đây là một trong những tình huống gây bối rối nhất khi vận hành Auto Scaling Group health check , và nguyên nhân thường không nằm ở chỗ bạn đang tìm. TL;DR — Auto Scaling Group Health Check Tình huống Health Check nên dùng Lưu ý quan trọng ASG không gắn Load Balancer EC2 Chỉ kiểm tra trạng thái hypervisor ASG gắn ALB/NLB, app có thể trả lỗi ELB Phải enable ELB health check trên Target Group Instance bị terminate dù EC2 status 'running' Kiểm tra Grace Period trước Grace Period quá ngắn là nguyên nhân phổ biến nhất Instance healthy trên TG nhưng ASG terminate Xác nhận health check type đã set ELB Default vẫn là EC2 dù có attach TG Cơ Chế Hoạt Động Của ASG Health Check ASG không tự kiểm tra ứng dụng của bạn. Nó chỉ hỏi nguồn dữ liệu bên ngoài: 'Instance này có hea...
Đọc thêm