Khi hệ thống không chậm, không lỗi nhưng AWS bill tăng 200%: bài học về Cross-AZ traffic trong Kubernetes

Chuyện từ đầu tháng hôm nay gió về mới kể :))

Mình (và các đép ọp/cờ lao trong team) đã trải qua một cú hơi wow đầu tháng. Không phải incident production, không downtime, không alert đỏ. Nhưng Finance gửi vào Slack một screenshot đủ làm anh em có thứ note vào CV: AWS bill của project tăng hơn 200% so với bình thường.

Hệ thống vẫn chạy ổn. Latency ổn định. Error rate thấp. Nhưng chi phí thì tăng theo kiểu không thể chấp nhận được. Đây là một issue (cũng không đúng lắm) về Networking cost trong Distributed System, đặc biệt khi chạy Kubernetes + Service Mesh.

Hệ thống chạy trên EKS, kiến trúc microservices, khoảng 50 service, traffic trung bình ~15k RPS. Toàn bộ workload được deploy trên 3 Availability Zone tại region ap-southeast-1 để đảm bảo High Availability (HA).

Khi soi AWS Cost Explorer, một điều bất thường là: Data Transfer cost vượt cả Compute cost (EC2).

Mục tiêu lúc này không phải tối ưu latency nữa, mà là chặn ngay dòng tiền đang chảy ra mà có thể chưa biết tại sao.

Lúc này, anh em mới đi theo hướng loại trừ:

Cost Explorer/CUR Filter theo Usage Type thấy APN1-DataTransfer-Regional-Bytes tăng vọt => đây là Cross-AZ traffic, không phải Internet Egress. OK loại.
NAT Gateway/Internet Gateway metrics CloudWatch cho thấy ingress/egress ra Internet rất ổn định => loại trừ DDoS, file download, external traffic spike.
Istio/Prometheus dashboard East-West traffic giữa các microservice rất lớn, nhưng điều này vốn bình thường trong kiến trúc microservices.

Câu hỏi thực sự là: Tại sao internal traffic lại bị tính phí nhiều như vậy?

Lần theo traffic flow, dùng kubeshark và Envoy access log để trace một flow cụ thể:

Service A (frontend-bff): 30 Pod, phân bố đều trên 3 AZ.
Service B (core-account): 10 Pod, cũng phân bố đều trên 3 AZ.

Khi phân tích log, một pattern rất rõ:

Pod A ở ap-southeast-1a
Rất thường xuyên được route sang Pod B ở 1b hoặc 1c

Với 3 AZ, xác suất request đi sang AZ khác là 2/3.

Trong AWS:

Traffic giữa EC2 trong cùng AZ (private IP) -> free
Traffic giữa các AZ khác nhau -> $0.01/GB mỗi chiều

Với throughput hàng TB mỗi ngày, chi phí này phình lên cực nhanh mà không hề có alert mặc định.

Dò tìm, nguyên nhân gốc nằm ở cơ chế load balancing mặc định của Kubernetes Service và Istio.

kube-proxy (iptables) và Envoy sidecar load balance dựa trên:
- Round Robin
- Least Request
Không mặc định quan tâm tới topology (AZ).
Pod ở local AZ và remote AZ được coi là ngang nhau nếu đều healthy.

Kết quả: Service Mesh vô tình route traffic cross-AZ liên tục, tạo ra lượng Data Transfer khổng lồ không cần thiết.

Giải pháp là Locality Load Balancing trong Istio.

Nguyên tắc:

Pod gọi service -> ưu tiên endpoint trong cùng AZ
Chỉ khi local AZ không còn endpoint healthy -> mới failover sang AZ khác

Cấu hình global cho mesh:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    localityLbSetting:
      enabled: true
      failover:
      - from: ap-southeast-1a
        to: ap-southeast-1b
      - from: ap-southeast-1b
        to: ap-southeast-1c

Sau khi apply, theo dõi metric:

envoy_cluster_upstream_rq_total

phân theo locality.

Kết quả thực tế:

Hơn 99% traffic được giữ trong local AZ
Cross-AZ traffic gần như bằng 0 trong điều kiện bình thường
AWS Data Transfer cost giảm mạnh chỉ sau vài ngày billing cycle

Khi một AZ gặp sự cố, traffic vẫn failover sang AZ khác -> HA vẫn được đảm bảo, chi phí tăng lại nhưng là trade-off chấp nhận được.

Thế là rút ra được vài thứ

Cost là một metric vận hành
- Đừng chỉ nhìn CPU, memory, latency.
- Networking cost, đặc biệt Data Transfer, là “sát thủ thầm lặng”.
Topology awareness là bắt buộc ở scale lớn
- Data locality giúp giảm cost và giảm latency.
- Intra-AZ latency thường <1ms, cross-AZ có thể 2-3ms.
Default config không tối ưu cho cost
- Kubernetes và Service Mesh ưu tiên connectivity và availability.
- Cost efficiency là trách nhiệm của người thiết kế hệ thống.
Luôn ý thức trade-off
- Locality load balancing có thể tạo hotspot nếu capacity AZ không đều.
- Cần theo dõi resource usage theo AZ và tune HPA cho phù hợp.

Nói chung là một usecase chắc ai làm Kubernetes trên Cloud có thể dính – do trình gà :)), hệ thống không chậm, không lỗi, không downtime… nhưng vẫn có thể đốt tiền rất nhanh nếu routing không kiểm soát theo topology.

Trong Distributed System, performance và cost luôn đi cùng nhau. Tối ưu được traffic locality không chỉ giúp hệ thống “đẹp” hơn về mặt kiến trúc, mà còn giúp Finance ngủ ngon hơn mỗi cuối tháng : D