Tools: 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 - Expert Insights

Tools: 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 - Expert Insights

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

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 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. ROI: ~$900/giờ effort. 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. 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: 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. → 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õ. 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: Subtle gotcha — sau migrate, nhiều script dùng: 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. 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. Trong session này, NHIỀU lần mình estimate sai trước khi đo: 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: 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. 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: 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: Action chính xác vào contributor đó, bỏ phần đuôi dài. Mình uninstall vài helm release theo thứ tự ngẫu nhiên: Trace nguyên nhân: Kibana có post-delete hook job call ES master để cleanup security token. Trình tự đã xảy ra: Workaround khi đã sai thứ tự: --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. 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). Cost optimization AWS không phải về việc biết hết tricks AWS. Nó về: 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 Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse

Code Block

Copy

Hour trước endpoint: ~14 GB qua NAT Hour ngay sau: ~0.4 GB qua NAT ↑ drop ~97% Hour trước endpoint: ~14 GB qua NAT Hour ngay sau: ~0.4 GB qua NAT ↑ drop ~97% Hour trước endpoint: ~14 GB qua NAT Hour ngay sau: ~0.4 GB qua NAT ↑ drop ~97% for inst in instances_to_migrate: assert inst["EnaSupport"] == True # ENA driver loaded assert inst_ami["VirtualizationType"] == "hvm" # not paravirtual (Xen-only) for inst in instances_to_migrate: assert inst["EnaSupport"] == True # ENA driver loaded assert inst_ami["VirtualizationType"] == "hvm" # not paravirtual (Xen-only) for inst in instances_to_migrate: assert inst["EnaSupport"] == True # ENA driver loaded assert inst_ami["VirtualizationType"] == "hvm" # not paravirtual (Xen-only) aws ec2 wait instance-running # SAI cho gen migration aws ec2 wait instance-running # SAI cho gen migration aws ec2 wait instance-running # SAI cho gen migration aws ec2 wait instance-status-ok # confirm cả system status + instance status aws ec2 wait instance-status-ok # confirm cả system status + instance status aws ec2 wait instance-status-ok # confirm cả system status + instance status NAT Gateway traffic share nat-A ~97% ← 1 NAT này thôi nat-B ~2% các NAT khác <1% NAT Gateway traffic share nat-A ~97% ← 1 NAT này thôi nat-B ~2% các NAT khác <1% NAT Gateway traffic share nat-A ~97% ← 1 NAT này thôi nat-B ~2% các NAT khác <1% apm-server uninstall → OK kibana uninstall → HANG (state "uninstalling") elasticsearch uninstall → OK (đã uninstall trước rồi) apm-server uninstall → OK kibana uninstall → HANG (state "uninstalling") elasticsearch uninstall → OK (đã uninstall trước rồi) apm-server uninstall → OK kibana uninstall → HANG (state "uninstalling") elasticsearch uninstall → OK (đã uninstall trước rồi) WRONG: ES uninstall → Kibana uninstall (hook FAIL) RIGHT: Kibana uninstall trước → ES uninstall sau WRONG: ES uninstall → Kibana uninstall (hook FAIL) RIGHT: Kibana uninstall trước → ES uninstall sau WRONG: ES uninstall → Kibana uninstall (hook FAIL) RIGHT: Kibana uninstall trước → ES uninstall sau # 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 # 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 # 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 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 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 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 - 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. - 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. - Estimate để rank ưu tiên (việc nào làm trước) - Đo CloudWatch/Cost Explorer để claim ROI với stakeholder - 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. - 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. - 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 - App trước Database - Cache trước Storage backend - Sidecar trước main service - Webhook controller trước CRD nó depend - 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ớ. - 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