# ⚖️ Right-sizing và chọn tier: cắt phí mà không giảm trải nghiệm

By Better Wise

## Right-size không phải là downgrade mù quáng

Bài trước bạn đã học cách đọc line item, usage và phát hiện dòng phí bất thường. Giờ là bước hành động: hai dòng phí to nhất trong hoá đơn của một app online thường là compute và database, và phần lớn trong số đó là phần bạn thuê nhưng không dùng. Right-sizing là việc chọn lại size và tier dựa trên số liệu usage thật, để tiền giảm mà người dùng không thấy gì khác.

Sau bài này, bạn có thể:

- Đọc đúng các chỉ số usage (p95 CPU, memory peak, IOPS, connection) để chọn size
- Áp dụng quy tắc chọn size theo p95 thay vì theo cảm giác
- Nhận ra ba kiểu tier hay bị trả dư: storage class, database tier, gói dịch vụ
- Đề xuất một bước right-sizing cụ thể kèm số tiền tiết kiệm ước tính

## Đọc usage trước khi chọn size

Nguyên tắc gốc: **trung bình đánh lừa, p95 mới là thứ quyết định**. Một VM 8 vCPU chạy 6% CPU trung bình nghe như rất nhàn, nhưng nếu p95 là 22% thì giờ cao điểm nó đang dùng 1,76 vCPU. Cắt xuống 2 vCPU là p95 chạm 88%, người dùng sẽ thấy chậm vào đúng lúc đông nhất.

Quy tắc thực dụng: chọn size sao cho p95 CPU rơi vào khoảng 50-60%, và p99 không vượt quá 80%. Với RAM thì nhìn **peak**, không nhìn trung bình, vì hết RAM là sự cố (OOM, crash) chứ không phải chỉ chậm.

Ba chỉ số cần lấy từ dashboard trước khi đổi bất cứ thứ gì: CPU p95/p99, memory peak, và một chỉ số đặc thù của workload (IOPS với database, connection count với app server, egress với media server). Lấy cửa sổ 30 ngày, đừng lấy 24 giờ.

## Ba ví dụ right-sizing có số liệu

### Ví dụ 1: compute dư gấp đôi

Một API server thuê `8 vCPU / 32 GB`, giá $280/tháng. Số liệu 30 ngày:

| Chỉ số | Giá trị | Quy đổi theo size hiện tại |
| --- | --- | --- |
| CPU trung bình | 6% | 0,48 vCPU |
| CPU p95 | 22% | 1,76 vCPU |
| CPU p99 | 35% | 2,80 vCPU |
| Memory peak | 3,8 GB | 12% của 32 GB |

Xuống `4 vCPU / 16 GB` ($140/tháng): p95 thành 44%, p99 thành 70%, memory peak còn 24%. Nằm đúng vùng an toàn, tiết kiệm $140/tháng mà không cần đổi gì trong code. Xuống hẳn 2 vCPU thì p99 chạm 140%, không nên, trừ khi bạn bật autoscaling để tự thêm node khi vượt ngưỡng.

### Ví dụ 2: database to vì "ngày xưa sợ"

Một Postgres chạy `db.r5.2xlarge` (8 vCPU / 64 GB), khoảng $350/tháng. Số liệu: CPU p95 = 9% (0,72 vCPU), connection trung bình 12, đỉnh 28, dữ liệu 20 GB, IOPS đọc p95 = 120, memory dùng cho buffer pool 6 GB.

Xuống `db.r5.large` (2 vCPU / 16 GB, khoảng $88/tháng): CPU p95 còn 36%, connection limit vẫn thoải mái, buffer pool 16 GB vẫn chứa trọn 20 GB dữ liệu nóng. Tiết kiệm khoảng $260/tháng. Đây là kiểu khoản phí bị bỏ sót hay gặp nhất: database được tạo một lần lúc mới launch, sau đó không ai xem lại.

### Ví dụ 3: storage tier rẻ hơn 45%

2.048 GB ảnh người dùng upload, nhưng trong 90 ngày gần nhất chỉ 8% dung lượng được đọc lại. Standard storage $0.023/GB, infrequent access $0.0125/GB.

- Giữ nguyên: 2.048 x $0.023 = $47/tháng
- Tách ra: 2.048 x 0.0125 = khoảng $27,8/tháng, tiết kiệm gần $19

Với 2 TB thì $19 nghe nhỏ, nhưng cùng tỉ lệ đó với 20 TB là gần $190/tháng. Đừng chuyển tay: đặt lifecycle rule "sau 90 ngày không truy cập thì chuyển tier" để nó tự chạy mãi. Nhớ đọc phí retrieval trước, nếu ảnh nào cũng bị đọc lại thì tier rẻ thành tier đắt.

Ba con số trên đều là ví dụ minh hoạ theo mức giá phổ biến, hãy thay bằng giá thật trong hoá đơn của bạn.

## Chọn tier: cùng workload, nhiều mức giá

- **Storage class**: standard, infrequent access, archive. Rẻ hơn đi kèm phí lấy dữ liệu ra và độ trễ cao hơn.
- **Database tier**: nếu database im lặng nhiều giờ trong ngày (tool nội bộ, staging), serverless/auto-pause tính theo giờ hoạt động có thể rẻ hơn instance chạy 24/7 rất nhiều.
- **Commitment**: workload chạy ổn định 12 tháng thì reserved instance hoặc savings plan giảm 30-40%. Chỉ commit phần **baseline**, phần spike giữ on-demand.
- **Gói dịch vụ**: gói $99/tháng cho 10 seat nhưng chỉ 4 người đăng nhập thật thì nên chuyển sang gói tính theo seat hoặc theo usage.

```mermaid
flowchart TD
    A["📊<br/>Đọc usage 30 ngày"] --> B{"📉<br/>p95 CPU dưới 40%?"}
    B -- Có --> C["⬇️<br/>Giảm một bậc size"]
    B -- Không --> D["✅<br/>Giữ size, xem lại tier"]
    C --> E["⏱️<br/>Đo lại sau 14 ngày"]
    D --> E
    E --> F{"🔁<br/>Ổn định 12 tháng?"}
    F -- Có --> G["💰<br/>Commit baseline"]
    F -- Không --> H["🔄<br/>Lặp lại hàng quý"]
```

Ôn nhanh vài con số vừa dùng: quy tắc chọn size dựa trên _____ của CPU, giữ p95 quanh _____%, và với RAM thì so bằng _____ chứ không so trung bình.

Right-sizing không phải là giảm size một lần rồi thôi, mà là việc _____ khi usage thay đổi.
Database bị bỏ sót nhiều nhất vì nó được tạo lúc launch và sau đó _____.
Commitment (reserved instance, savings plan) chỉ nên áp cho phần _____ ổn định, phần spike giữ on-demand.
Storage tier rẻ hơn chỉ có lợi nếu bạn đọc phí _____ trước khi chuyển.

## Những cái bẫy khiến bạn trả tiền cho phần không dùng

- **Chỉ nhìn trung bình.** Đây là lỗi số một. Luôn mở p95 và p99 trước khi quyết định.
- **Right-size cả cụm vì một node nóng.** Nếu chỉ 1 trong 5 node quá tải, hãy xem autoscaling group hoặc tách workload, đừng nâng size toàn bộ.
- **Quên phí đi kèm.** Giảm size instance nhưng tăng số replica, hoặc chuyển storage tier rẻ rồi trả phí retrieval gấp ba. Luôn tính tổng, không tính một dòng.
- **Đổi rồi không đo lại.** Đặt reminder 14 ngày và so p95 trước/sau. Không đo thì bạn chỉ đang tin vào cảm giác.
- **Sợ lock-in nên không commit gì cả.** Chỉ commit phần baseline, phần còn lại giữ linh hoạt. Không commit gì cũng là một dạng trả dư.
- **Đổi cả production trong một lần.** Đổi trên staging trước, giữ đường rollback, rồi mới áp cho production.

## Chốt lại và bước tiếp theo

- Chọn size theo p95 (mục tiêu 50-60%) và theo memory peak, không theo trung bình.
- Database và storage tier là hai chỗ hay bị trả dư nhất, và cả hai đều sửa được mà không đổi code.
- Mỗi lần right-size phải có số tiền tiết kiệm ước tính và một mốc đo lại.
- Right-sizing là việc định kỳ hàng quý, không phải chiến dịch một lần.

Bài tiếp theo là checkpoint của module: bạn sẽ đọc một hoá đơn có sẵn, chỉ ra khoản phí bị bỏ sót và viết ra một bước right-sizing hoặc đổi tier cụ thể kèm con số.

Front: Vì sao không nên chọn instance size theo CPU trung bình?
Back: Trung bình che mất giờ cao điểm; p95 và p99 mới cho biết lúc app căng nhất cần bao nhiêu.

Front: Mục tiêu p95 CPU khi chọn size là bao nhiêu?
Back: Khoảng 50-60%, để còn headroom cho spike và p99 không vượt quá 80%.

Front: Với RAM thì so bằng chỉ số nào?
Back: Memory peak, vì hết RAM gây OOM hoặc crash chứ không chỉ làm chậm.

Front: Cửa sổ dữ liệu nên lấy khi right-size là bao lâu?
Back: 30 ngày, đủ để bắt được chu kỳ tuần và các đợt tăng tải lặp lại.

Front: Database trong ví dụ 2 tiết kiệm bao nhiêu khi xuống db.r5.large?
Back: Khoảng 260 USD/tháng (từ khoảng 350 xuống khoảng 88), vì CPU p95 chỉ 9% của 8 vCPU.

Front: Khi nào nên chuyển storage sang infrequent access tier?
Back: Khi phần lớn dữ liệu không được đọc lại trong 90 ngày và phí retrieval vẫn thấp hơn phần tiết kiệm.

Front: Cách bền vững để áp storage tier là gì?
Back: Đặt lifecycle rule tự động, ví dụ sau 90 ngày không truy cập thì chuyển tier, thay vì chuyển tay.

Front: Commitment (reserved instance, savings plan) nên áp cho phần nào?
Back: Chỉ phần baseline ổn định 12 tháng; phần spike giữ on-demand.

Front: Sai lầm khi right-size cả cụm vì một node quá tải là gì?
Back: Nên xem autoscaling group hoặc tách workload thay vì nâng size cho toàn bộ cụm.

Front: Sau khi đổi size phải làm gì?
Back: Đo lại sau khoảng 14 ngày, so p95 và p99 trước/sau, và giữ đường rollback.

Front: Vì sao database hay bị trả dư?
Back: Nó được tạo một lần lúc launch với cấu hình phòng xa, sau đó không ai xem lại usage.

Front: Right-sizing nên lặp lại bao lâu một lần?
Back: Hàng quý, vì usage và số người dùng thay đổi liên tục.

---

## Contents

Part of [🧾 Chi phí hạ tầng cho vibe coder: đọc hoá đơn cloud và giữ ngân sách](https://everwise.study/courses/chi-phi-ha-tang-cho-vibe-coder-doc-hoa-don-cloud-va-giu-ngan-sach.md)

- **🔍 Đọc hoá đơn cloud và tìm khoản phí bị bỏ sót**
  - [🗺️ Bản đồ chi phí: băng thông, egress, storage và database nhàn rỗi](https://everwise.study/courses/chi-phi-ha-tang-cho-vibe-coder-doc-hoa-don-cloud-va-giu-ngan-sach/ban-do-chi-phi-bang-thong-egress-storage-database-nhan-roi.md)
  - [📄 Đọc hoá đơn cloud: line item, usage và phí bất thường](https://everwise.study/courses/chi-phi-ha-tang-cho-vibe-coder-doc-hoa-don-cloud-va-giu-ngan-sach/doc-hoa-don-cloud-line-item-usage-phi-bat-thuong.md) (sign-in required)
  - [⚖️ Right-sizing và chọn tier: cắt phí mà không giảm trải nghiệm](https://everwise.study/courses/chi-phi-ha-tang-cho-vibe-coder-doc-hoa-don-cloud-va-giu-ngan-sach/right-sizing-va-chon-tier-cat-phi.md) — this lesson
  - [✅ Checkpoint: đọc hoá đơn và phát hiện khoản phí bị bỏ sót](https://everwise.study/courses/chi-phi-ha-tang-cho-vibe-coder-doc-hoa-don-cloud-va-giu-ngan-sach/checkpoint-doc-hoa-don-va-phat-hien-phi-bi-bo-sot.md)
- **🎛️ Kiểm soát chủ động: tag, budget alert và chi phí AI**
  - [🏷️ Tag chi phí và budget alert: kiểm soát trước khi hoá đơn về](https://everwise.study/courses/chi-phi-ha-tang-cho-vibe-coder-doc-hoa-don-cloud-va-giu-ngan-sach/tag-chi-phi-va-budget-alert.md)
  - [🤖 Ước lượng chi phí token khi gọi AI API](https://everwise.study/courses/chi-phi-ha-tang-cho-vibe-coder-doc-hoa-don-cloud-va-giu-ngan-sach/uoc-luong-chi-phi-token-ai-api.md)
  - [🧮 Quy tắc tắt tài nguyên không dùng và chi phí mỗi người dùng](https://everwise.study/courses/chi-phi-ha-tang-cho-vibe-coder-doc-hoa-don-cloud-va-giu-ngan-sach/quy-tac-tat-tai-nguyen-khong-dung-va-cost-per-user.md) (premium content)
  - [✅ Checkpoint: kiểm soát chi phí và tính cost per user](https://everwise.study/courses/chi-phi-ha-tang-cho-vibe-coder-doc-hoa-don-cloud-va-giu-ngan-sach/checkpoint-kiem-soat-chi-phi-va-cost-per-user.md) (premium content)
- [Course cheatsheet](https://everwise.study/courses/chi-phi-ha-tang-cho-vibe-coder-doc-hoa-don-cloud-va-giu-ngan-sach/cheatsheet.md) (premium content)