ECR image layers thực ra lưu trên S3 — và 4 bài học khác từ buổi audit AWS cắt $4,440/năm

TAI THANH — Tue, 28 Apr 2026 04:54:02 +0000

Cắt ~$4,440/năm chi phí AWS — 5 bài học từ 1 buổi audit

Mình vừa làm xong, thấy có vài thứ hay mà AWS docs không nói rõ. Share lại đầy đủ context để ai gặp tình huống tương tự đỡ phải mò như mình. Kết quả: ~$374/tháng tiết kiệm = ~$4,440/năm, hết khoảng 5 giờ làm việc.

TL;DR

Optimization	Saving/tháng	Effort
Tạo S3 Gateway Endpoint cắt NAT data	~$196	5 phút
Migrate EC2 c3 → c7i (gen upgrade)	~$156	1 giờ
Release EIP idle	~$22	5 phút
TỔNG	~$374/tháng	~5 giờ

ROI: ~$900/giờ effort.

Bối cảnh

Tuần trước team đã làm 1 đợt optimize Karpenter + right-size pod, giảm 15%. Nhưng cost vẫn cao. Câu hỏi: có còn dư địa nào không?

Mình nhận task audit + thực hiện. Spoiler: nhiều thứ tưởng đã optimize hết hóa ra mới chỉ động được vào tảng băng trên.

Bài học #1 — ECR image layers thực ra lưu trên S3

S3 Gateway Endpoint (free, setup 5 phút) — bật thử cho VPC chạy K8s. Theory bảo cắt 50-80% NAT data. Đo CloudWatch ngay sau bật:

Hour trước endpoint:    ~14 GB qua NAT
Hour ngay sau:          ~0.4 GB qua NAT
                        ↑ drop ~97%

Drop sâu hơn theory tận này — mình tò mò trace lại, thì ra: ECR API endpoint serve metadata thôi (manifest, tags), còn binary layers thì redirect về S3 presigned URL. Mỗi pod scaling/restart → docker daemon pull layers → traffic đến S3 ngầm.

Người chỉ tính traffic "S3 trực tiếp" (app gọi S3 SDK trong code) sẽ underestimate massively. ECR pull traffic không hiển thị trong S3 metric thông thường vì client là docker daemon, không phải app code.

Mình rút ra: action nào reversible + cost thấp thì cứ thử + đo, đừng paralyze-by-analysis. Endpoint free, có thể delete ngay.

Vài cái đáng note:

Gateway Endpoint chỉ free cho S3 và DynamoDB. Các service khác (ECR API, STS, SSM, KMS...) phải dùng Interface Endpoint ($0.01/giờ/AZ + $0.01/GB) → tính lại ROI cho từng case.
Nếu app dùng S3 cross-region (vd VPC ap-southeast-1, bucket us-east-1), Gateway Endpoint không apply — vẫn qua NAT.
ECR Pull Through Cache (feature mới) thay đổi pattern này — layers cache local trong region, giảm cross-region pull nhưng không thay được nhu cầu cho S3 endpoint.

→ Anh em chạy K8s/EKS với image lớn + autoscale nhiều, S3 Gateway Endpoint nên làm trước cả khi audit kỹ. Quick win quá rõ.

Bài học #2 — Pre-flight check trước cross-generation EC2 migration

c3.large → c7i.large = Xen-based → Nitro hypervisor, gap price/performance ~15-20%. Nghe free lunch nhưng có catch: Nitro yêu cầu ENA driver (network) + NVMe driver (storage) trong kernel của AMI.

Nếu AMI thiếu driver → instance "running" theo EC2 API nhưng OS không boot được. Cluster brick. Worse: rollback phải stop + change type lại + restart, prod thì là incident.

Pre-flight check 3 phút mình dùng:

for inst in instances_to_migrate:
    assert inst["EnaSupport"] == True              # ENA driver loaded
    assert inst_ami["VirtualizationType"] == "hvm" # not paravirtual (Xen-only)

Subtle gotcha — sau migrate, nhiều script dùng:

aws ec2 wait instance-running  # SAI cho gen migration

running chỉ confirm hypervisor đã boot hardware, không confirm OS responding. Nếu thiếu driver, instance sẽ stuck "running" forever, OS không up — silent failure.

Đúng phải là:

aws ec2 wait instance-status-ok  # confirm cả system status + instance status

status-ok confirm 2/2 checks: system (hypervisor) + instance (OS responding). Thiếu driver → status stuck "initializing" → wait timeout → biết có vấn đề ngay.

Vài cái đáng note:

AMI build trước 2017 rất khả năng thiếu ENA. Amazon Linux 2 / Ubuntu 18.04+ thường OK nhưng vẫn nên check.
Custom AMI nội bộ là rủi ro cao nhất — đặc biệt nếu base từ snapshot cũ.
ENA có thể modprobe runtime, nhưng nếu init không có driver, network sẽ down trong giai đoạn boot — SSH vào fix là không khả thi.

Bài học #3 — Estimate ban đầu sai 30-100% là chuyện thường

Trong session này, NHIỀU lần mình estimate sai trước khi đo:

Item	Estimate ban đầu	Thực tế	Lý do sai
EIP idle	overcounted ~3x	thực tế ít hơn nhiều	Đếm cả EIP gắn vào EC2 stopped (intentionally reserved)
c3 → c7 saving	"~40%"	"~15%"	Confused giá c3 với t2/m4 đời cũ
NAT data nguồn	"Phân bố nhiều VPC"	gần như 1 NAT duy nhất	Không đo trước khi giả định
DynamoDB endpoint	"Nên làm vì FREE"	KHÔNG cần	0 K8s pod gọi DynamoDB

Pattern: cả 4 lần đều suy luận từ mental model thay vì đo data thực.

Mình rút ra: estimate sai không phải vấn đề. Estimate sai mà không đo lại trước khi report ra mới là vấn đề. Mình từng nhiều lần ngại đo lại vì lỡ thừa nhận estimate ban đầu sai — bài học là phải tách rõ 2 việc:

Estimate để rank ưu tiên (việc nào làm trước)
Đo CloudWatch/Cost Explorer để claim ROI với stakeholder

Skip step 2 = báo cáo "$400/tháng" rồi thực tế delivery $110 = lose credibility với stakeholder mãi mãi.

Bài học #4 — Pareto cực mạnh trong AWS cost (drill-down 3 tầng)

Pareto trong AWS cost extreme hơn 80/20 thông thường — thường gặp 95/5 hoặc 99/1. Lý do: pricing model AWS + scale infrastructure tạo concentration tự nhiên.

Khi audit NAT data charge:

NAT Gateway     traffic share
nat-A           ~97%  ← 1 NAT này thôi
nat-B            ~2%
các NAT khác    <1%

1 NAT chiếm ~97% cost. Phân bổ effort đều cho mọi NAT (audit từng cái 30 phút × 8 NAT = 4 giờ) = waste 8x effort cho 3% ROI.

Drill-down framework mình dùng:

Service breakdown — Cost Explorer → Group by Service. Top 3 service thường > 80% bill.
usage_type breakdown trong service — vd EC2 có BoxUsage:t3.medium, EBS:VolumeUsage.gp3, DataTransfer-Out-Bytes. Cost Explorer cho group by usage_type → thấy cụ thể chi phí đến từ compute hay storage hay transfer.
resource_id breakdown trong usage_type — cần tagging strategy tốt (Project, Environment, Owner tags), hoặc dùng Cost & Usage Report (CUR) export → query Athena.

Action chính xác vào contributor đó, bỏ phần đuôi dài.

Vài cái đáng note:

Reserved Instance / Savings Plan discount apply theo proportional logic, có thể distort breakdown — phải look at "unblended cost" nếu muốn thấy real consumption.
Cross-account org thì Pareto apply ở account level trước (account nào dominant), rồi xuống service trong account đó.
CUR query qua Athena là endgame — nếu audit > 5 lần/năm, đáng setup.

Bài học #5 — Helm uninstall order: dependent trước, dependency sau

Mình uninstall vài helm release theo thứ tự ngẫu nhiên:

apm-server uninstall → OK
kibana uninstall     → HANG (state "uninstalling")
elasticsearch uninstall → OK (đã uninstall trước rồi)

Trace nguyên nhân: Kibana có post-delete hook job call ES master để cleanup security token. Trình tự đã xảy ra:

ES master helm uninstall trước → ES pod deleted, Service elasticsearch-master deleted
Kibana helm uninstall chạy → trigger post-delete hook
Hook job pod start, gọi elasticsearch-master.namespace.svc.cluster.local
K8s DNS không resolve được (Service đã chết) → connection refused
Hook retry vài lần → fail → kibana stuck "uninstalling" forever

WRONG: ES uninstall → Kibana uninstall (hook FAIL)
RIGHT: Kibana uninstall trước → ES uninstall sau

Workaround khi đã sai thứ tự:

# Option 1: Force delete hook job + uninstall không hook
kubectl delete job post-delete-kibana-kibana
helm uninstall kibana --no-hooks

# Option 2: Patch finalizers nếu Helm release stuck
kubectl patch helmrelease kibana -p '{"metadata":{"finalizers":[]}}' --type=merge

--no-hooks skip toàn bộ hook → uninstall xong nhưng có thể leave orphan resource. Acceptable cho destructive cleanup vì dependency đã chết rồi anyway.

Mình rút ra: stateful chart có dependency chain → uninstall theo thứ tự DEPENDENT trước, DEPENDENCY sau.

Áp dụng cho:

App trước Database
Cache trước Storage backend
Sidecar trước main service
Webhook controller trước CRD nó depend

Vài cái đáng note:

Operator (CRD-based) thì khác — uninstall Operator trước CRD instance → orphan custom resource. Phải uninstall CRD instance trước, Operator sau.
helm uninstall --wait flag confirm tất cả resource deleted trước khi return — chậm hơn nhưng catch hang state sớm.
Production: nên có runbook cho từng helm release stack ghi rõ uninstall order. Đừng assume team member nhớ.

Pattern playbook (reusable cho lần sau)

1. Get cost trend (Cost Explorer) → identify magnitude
2. Group-by service → find Pareto concentration
3. Drill usage_type/resource_id → find specific contributor
4. Pre-flight check before destructive action
5. Confirm explicit với stakeholder (đặc biệt prod)
6. Execute với reversibility in mind
7. MEASURE actual impact (CloudWatch metrics, không chỉ Cost Explorer)
8. Build verification command để re-check trong tương lai
9. Document findings + remaining TODOs in source repo

Số liệu tổng hợp

Sau ~5 giờ work:

Category	Saving/tháng
Network (S3 Gateway Endpoint)	~$196
Compute (EC2 generation upgrade)	~$156
Public IPv4 idle	~$22
TỔNG	~$374/tháng
TỔNG/năm	~$4,488

Vẫn còn dư địa đáng kể trong các TODO chưa làm (RDS right-sizing, EBS audit, ECR Interface Endpoint, Spot ratio increase).

Lời kết

Cost optimization AWS không phải về việc biết hết tricks AWS. Nó về:

Audit có hệ thống (top-down, Pareto)
Đo thực tế (CloudWatch, Cost Explorer)
Action reversible (thử + đo > paralysis-by-analysis)
Pre-flight check trước destructive action

Cuối session, mình bỏ thêm 30 phút build 1 Python script aws-cost-check.py chạy 1 command → dump 5 sections (cost trend, top services, NAT trend, endpoint state, legacy instance remaining). Lần sau câu hỏi "endpoint còn hiệu quả không?" trả lời trong 5 giây thay vì repeat 30 phút audit. Đầu tư 30 phút này compounding rất nhanh — recommend mọi optimization session đều kết thúc bằng tool verification.

Pattern này apply cho bất kỳ AWS account nào. Lần sau apply cho account khác chắc chắn cũng sẽ tìm thấy 5-15% saving giấu đâu đó.

Account AWS của ae lần cuối được audit khi nào? Pattern nào ae dùng? Comment chia sẻ với mình ↓

Tags: #aws #devops #costoptimization #kubernetes #vpc #ec2

DEV Community: TAI THANH

ECR image layers thực ra lưu trên S3 — và 4 bài học khác từ buổi audit AWS cắt $4,440/năm

Cắt ~$4,440/năm chi phí AWS — 5 bài học từ 1 buổi audit

TL;DR

Bối cảnh

Bài học #1 — ECR image layers thực ra lưu trên S3

Bài học #2 — Pre-flight check trước cross-generation EC2 migration

Bài học #3 — Estimate ban đầu sai 30-100% là chuyện thường

Bài học #4 — Pareto cực mạnh trong AWS cost (drill-down 3 tầng)

Bài học #5 — Helm uninstall order: dependent trước, dependency sau

Pattern playbook (reusable cho lần sau)

Số liệu tổng hợp

Lời kết