Bill AWS tháng rồi của team mình tăng 40% so với tháng trước. Không phải vì traffic tăng — mà vì không ai để ý một đống EC2 đang chạy idle suốt 3 tuần. Khổ nỗi là với hệ thống enterprise nhiều tài khoản, chuyện này xảy ra thường xuyên hơn bạn nghĩ.

FinOps không phải là cắt giảm tùy tiện. Đó là văn hóa vận hành cloud có trách nhiệm tài chính — biết mình đang tiêu gì, tiêu cho ai, và tiêu có đáng không.

Tại sao FinOps quan trọng với hệ thống Enterprise?

Với startup 1-2 người, bạn nhìn bill là biết ngay vấn đề. Nhưng với enterprise có 10, 20, thậm chí 50 AWS account — mỗi team tự quản lý resource riêng — chi phí trở thành "hố đen" nếu không có hệ thống quản trị bài bản.

Nghiên cứu từ Gartner cho thấy trung bình 30% chi phí cloud bị lãng phí do resource không sử dụng, over-provisioning và thiếu visibility. Với một hệ thống tiêu 500,000 USD/tháng, đó là 150,000 USD đốt đi mỗi tháng.

FinOps giải quyết vấn đề này bằng ba trụ cột: Inform (biết mình tiêu gì), Optimize (tối ưu có cơ sở) và Operate (vận hành nhất quán theo thời gian).

Chiến lược 1: Làm chủ AWS Cost Explorer trước khi làm bất cứ thứ gì khác

Cost Explorer là điểm khởi đầu bắt buộc. Trước khi tối ưu, bạn phải biết mình đang tốn tiền ở đâu.

Cách dùng hiệu quả: bật Cost Allocation Tags ngay từ đầu — tag theo Environment, Team, Project, CostCenter. Không có tag, Cost Explorer chỉ cho bạn thấy con số tổng vô nghĩa.

Tiếp theo, tạo Budget Alert theo từng dimension: alert khi EC2 của team Backend vượt 20,000 USD/tháng, alert khi S3 của team Data tăng đột biến hơn 50% so với tháng trước. Cụ thể, không phải chung chung.

Một tính năng ít người dùng: Cost Anomaly Detection. AWS dùng ML để phát hiện chi phí bất thường và gửi alert trước khi bạn nhận bill cuối tháng. Bật nó lên, cấu hình threshold 10-15%, và để nó lo phần còn lại.

Chiến lược 2: Rightsizing — Đừng trả tiền cho CPU mà bạn không dùng

Over-provisioning là lỗi phổ biến nhất. Team provision EC2 m5.2xlarge vì "cho chắc", nhưng CPU utilization trung bình chỉ 8-12%. Đó là tiền đốt thẳng.

AWS Compute Optimizer phân tích metric 14 ngày gần nhất và recommend instance type phù hợp hơn. Mình từng dùng tool này và tìm ra 40 EC2 instance có thể downsize, tiết kiệm khoảng 8,000 USD/tháng chỉ từ việc đổi instance type.

Lưu ý: đừng rightsizing dựa trên average utilization — nhìn vào peak utilization. Nếu CPU peak 90% trong 5% thời gian còn lại 95% thời gian chỉ 15%, bạn vẫn cần instance đủ mạnh để xử lý peak đó.

# Kiểm tra utilization EC2 qua CLI
aws cloudwatch get-metric-statistics   --namespace AWS/EC2   --metric-name CPUUtilization   --dimensions Name=InstanceId,Value=i-1234567890abcdef0   --start-time 2024-01-01T00:00:00Z   --end-time 2024-01-31T23:59:59Z   --period 86400   --statistics Average Maximum   --query 'sort_by(Datapoints, &Timestamp)'

Chiến lược 3: Reserved Instances và Savings Plans — Cam kết để tiết kiệm

On-Demand pricing đắt vì tính phí cho sự linh hoạt. Nếu bạn biết mình sẽ dùng một lượng compute nhất định trong 1-3 năm tới, cam kết trước để được giảm giá 40-72%.

Reserved Instances (RI) phù hợp khi bạn biết chính xác instance type và region sẽ dùng. Standard RI 1 năm full upfront giảm ~40%, 3 năm giảm ~60%.

Savings Plans linh hoạt hơn — cam kết mức spend theo giờ (ví dụ 10 USD/giờ) thay vì cam kết instance cụ thể. Compute Savings Plans apply cho EC2, Fargate, Lambda và cho phép đổi instance family thoải mái.

Chiến lược kết hợp thực tế: dùng Savings Plans cho baseline workload (70-80% resource), On-Demand cho phần còn lại và spike traffic. Đừng mua RI/SP quá nhiều — nếu workload giảm, bạn vẫn phải trả tiền cam kết đó.

Mẹo xương máu: Dùng Cost Explorer's RI/SP recommendation để xem AWS tự tính toán breakeven point. Nếu breakeven dưới 7-8 tháng, mua ngay. Nếu trên 12 tháng, cân nhắc lại.

Chiến lược 4: Spot Instances cho Workload Fault-Tolerant

Spot Instances là EC2 capacity dư của AWS, bán với giá thấp hơn On-Demand 70-90%. Đổi lại, AWS có thể thu hồi instance với 2 phút báo trước.

Workload phù hợp với Spot: batch processing, ML training, CI/CD pipeline, rendering, test environment. Workload KHÔNG phù hợp: database primary, stateful application, production API cần uptime cao.

Dùng Spot Fleet hoặc EC2 Auto Scaling với mixed instance policy để tự động fallback sang On-Demand khi Spot bị thu hồi. Kết hợp với Instance Diversification — dùng nhiều instance type và AZ khác nhau để giảm xác suất bị thu hồi đồng loạt.

# Mixed instance policy trong Auto Scaling
{
  "MixedInstancesPolicy": {
    "InstancesDistribution": {
      "OnDemandBaseCapacity": 2,
      "OnDemandPercentageAboveBaseCapacity": 20,
      "SpotAllocationStrategy": "capacity-optimized"
    },
    "LaunchTemplate": {
      "Overrides": [
        {"InstanceType": "m5.xlarge"},
        {"InstanceType": "m5a.xlarge"},
        {"InstanceType": "m4.xlarge"}
      ]
    }
  }
}

Chiến lược 5: Tối ưu Storage — S3, EBS và Data Transfer

Storage thường bị bỏ qua nhưng tích lũy chi phí đáng kể theo thời gian.

S3 Intelligent-Tiering tự động di chuyển object giữa các tier (Frequent Access → Infrequent Access → Archive) dựa trên access pattern. Không cần config gì thêm, tiết kiệm được 40-68% với data ít truy cập.

EBS Volume: audit snapshot định kỳ — snapshot cũ từ instance đã terminate vẫn tốn tiền. Dùng AWS Data Lifecycle Manager để tự động xóa snapshot theo policy. Cũng nên review xem có volume gp2 nào có thể migrate sang gp3 không — gp3 rẻ hơn 20% và hiệu năng tốt hơn.

Data Transfer là khoản chi phí ẩn khó đoán. Traffic ra internet tốn tiền, traffic giữa AZ cũng tốn tiền. Đặt resource cùng AZ khi có thể, dùng VPC Endpoint thay vì đi qua internet gateway để truy cập S3 và DynamoDB.

Chiến lược 6: Tagging Strategy và Cost Governance Đa Tài Khoản

Không có tagging nghiêm túc, mọi nỗ lực FinOps đều vô nghĩa. Bạn không thể tối ưu thứ bạn không đo được.

Implement AWS Tag Policy qua Organizations để enforce tag bắt buộc. Ví dụ: mọi resource phải có tag CostCenter, Environment, Owner. Resource không có tag đủ → tự động gắn flag hoặc block creation qua SCP (Service Control Policy).

Với multi-account setup, dùng AWS Organizations + Cost and Usage Report (CUR) ghi về S3 central, sau đó dùng Athena query để phân tích. Stack này cho phép bạn group cost theo OU (Organizational Unit), account, team và project.

Nói thật thì việc enforce tagging culture cần sự đồng thuận từ leadership — technical solution không đủ nếu team lead không coi đây là priority.

Chiến lược 7: Tự Động Hóa — Schedule, Clean Up và Policy Enforcement

Resource chạy idle ngoài giờ làm việc là lãng phí dễ thấy nhất. EC2 dev/test chạy 24/7 khi team chỉ làm việc 8-10 tiếng/ngày, 5 ngày/tuần — bạn đang trả tiền cho 70% thời gian không ai dùng.

Dùng AWS Instance Scheduler hoặc Lambda + EventBridge để tự động start/stop EC2 và RDS theo lịch. Environment dev stop lúc 20:00 JST, start lúc 08:00 JST ngày làm việc — tiết kiệm ngay 60% chi phí compute cho non-prod.

Thiết lập automated cleanup cho: EBS snapshot cũ hơn 30 ngày, AMI không dùng, Elastic IP chưa attach, Load Balancer không có target healthy. Những thứ này tích lũy âm thầm và tốn tiền mà không ai để ý.

# Lambda function tắt EC2 dev ngoài giờ
import boto3
from datetime import datetime

def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    # Lấy instance có tag Environment=dev đang running
    instances = ec2.describe_instances(
        Filters=[
            {'Name': 'tag:Environment', 'Values': ['dev', 'test']},
            {'Name': 'instance-state-name', 'Values': ['running']}
        ]
    )
    instance_ids = [
        i['InstanceId']
        for r in instances['Reservations']
        for i in r['Instances']
    ]
    if instance_ids:
        ec2.stop_instances(InstanceIds=instance_ids)
        print(f"Stopped {len(instance_ids)} dev instances")

FAQ

Q: Nên bắt đầu FinOps từ đâu nếu chưa có gì?

A: Bước 1 là bật Cost Allocation Tags và Cost Anomaly Detection — không tốn tiền, không rủi ro. Sau đó nhìn vào Cost Explorer để xác định top 3 service tốn tiền nhất. Từ đó mới biết nên tập trung tối ưu chỗ nào trước.

Q: Reserved Instances hay Savings Plans phù hợp hơn cho workload thay đổi thường xuyên?

A: Savings Plans linh hoạt hơn vì không lock vào instance type cụ thể. Với workload hay thay đổi instance family hoặc có kế hoạch migrate sang container/serverless, Compute Savings Plans là lựa chọn an toàn hơn.

Q: Làm sao thuyết phục team phát triển quan tâm đến chi phí cloud?

A: Showback trước — show cho từng team biết họ đang tiêu bao nhiêu mỗi tháng, so sánh với tháng trước và benchmark với team khác. Khi thấy số cụ thể, người ta mới có động lực thay đổi. Chargeback (tính tiền thật vào budget của team) hiệu quả hơn nhưng cần thời gian để build culture.

Nhìn lại sau 6 tháng thực chiến

Sau 6 tháng áp dụng đủ 7 chiến lược này vào hệ thống 30+ AWS account, team mình cắt được khoảng 35% chi phí cloud — tương đương gần 180,000 USD/năm. Phần lớn đến từ rightsizing (lớn nhất), Savings Plans và schedule automation cho non-prod environment.

Điều mình học được: FinOps không phải việc làm 1 lần rồi thôi. Nó là process liên tục — review hàng tuần, optimize hàng tháng, renegotiate commitment hàng quý. Và quan trọng hơn hết, nó cần sự tham gia của cả engineering lẫn finance — không phải chỉ là việc của infra team.

Nghĩ mà xem — 30% chi phí cloud lãng phí là tiền thật, không phải con số trên giấy. Đủ để hire thêm 2-3 engineer giỏi hay đầu tư vào feature mới. Đáng để bắt đầu ngay hôm nay hơn là chờ đến khi bill tiếp theo đến.