Networking

NAT Gateway hay NAT instance: khi nào nên chuyển

CostKernel Engineering · 8 phút đọc

Trong nhiều hóa đơn AWS chúng tôi xem qua, NAT Gateway là một dòng chi phí lớn nhưng ít được để ý, vì nó không gắn với một service hay một đội cụ thể nào. Bài viết này đi qua cách NAT Gateway tính phí, cách tìm ra traffic nào đang đi qua nó, và khi nào việc chuyển sang NAT instance thực sự đáng cân nhắc.

NAT Gateway tính phí như thế nào

NAT Gateway có hai khoản phí: phí theo giờ cho mỗi gateway, và phí xử lý dữ liệu cho mỗi GB đi qua nó, bất kể dữ liệu đó đi đâu. Tại us-east-1, tại thời điểm viết bài, cả hai khoản đều là $0.045 (theo giờ và theo GB). Giá khác nhau giữa các region, nên bạn nên kiểm tra lại bảng giá của region mình đang dùng.

Khoản phí theo GB mới là phần đáng chú ý. Phí này được cộng thêm vào phí data transfer thông thường, kể cả khi đích đến là một dịch vụ AWS nằm ngay trong cùng region như S3 hay ECR.

Ví dụ giả định

Một hệ thống có 3 NAT Gateway (mỗi AZ một gateway) và 20 TB dữ liệu đi qua mỗi tháng, tại us-east-1:

3 × 730 giờ × $0.045      ≈ $99 / tháng
20.000 GB × $0.045        ≈ $900 / tháng

Phần lớn chi phí đến từ dữ liệu, không phải từ bản thân gateway. Vì vậy việc đầu tiên cần làm là tìm xem dữ liệu đó đi đâu.

Bước 1: đo trước khi thay đổi

Chúng tôi thường bắt đầu từ hai nguồn dữ liệu:

Cost and Usage Report: lọc theo usage type có chứa NatGateway-Bytes để biết tổng chi phí xử lý dữ liệu theo từng tài khoản và từng region.
VPC Flow Logs trên network interface của NAT Gateway: tổng hợp theo địa chỉ đích để biết traffic đang đi tới đâu. Rất thường gặp trường hợp phần lớn traffic đi tới S3, ECR, hoặc các API của AWS.

Bước 2: VPC Endpoint thường giải quyết phần lớn vấn đề

Nếu traffic chủ yếu đi tới các dịch vụ AWS, bạn có thể đưa nó đi thẳng qua VPC Endpoint thay vì qua NAT Gateway:

Gateway Endpoint cho S3 và DynamoDB không tính phí. Đây gần như luôn là thay đổi nên làm đầu tiên.
Interface Endpoint cho ECR, STS, CloudWatch Logs và nhiều dịch vụ khác có tính phí theo giờ cho mỗi AZ và theo GB, nhưng mức phí theo GB thấp hơn đáng kể so với NAT Gateway. Cần tính toán để chắc chắn lượng traffic đủ lớn để bù cho phí theo giờ.
Lưu ý với ECR: các layer của image được lưu trên S3, nên bạn cần cả endpoint ecr.api, ecr.dkr và Gateway Endpoint cho S3.

resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.ap-southeast-1.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.private[*].id
}

resource "aws_vpc_endpoint" "ecr_dkr" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.ap-southeast-1.ecr.dkr"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.endpoints.id]
  private_dns_enabled = true
}

Một điểm khác cũng hay gặp: workload ở AZ này lại đi qua NAT Gateway nằm ở AZ khác, khiến bạn trả thêm phí truyền dữ liệu giữa các AZ. Hãy kiểm tra route table của từng private subnet trỏ đúng tới NAT Gateway cùng AZ.

Bước 3: khi nào NAT instance đáng cân nhắc

Sau khi đã đưa traffic tới dịch vụ AWS qua endpoint, phần còn lại là traffic thực sự cần ra internet. Lúc này NAT instance, tức một EC2 instance tự cấu hình làm NAT, có thể rẻ hơn nhiều vì bạn chỉ trả tiền instance và data transfer, không có phí xử lý theo GB. Các dự án mã nguồn mở như fck-nat giúp việc dựng NAT instance trên ARM khá đơn giản.

Tuy vậy, NAT Gateway là dịch vụ managed với lý do chính đáng. Khi chuyển sang NAT instance, đội của bạn nhận về những trách nhiệm sau:

Độ sẵn sàng: nếu instance gặp sự cố, traffic ra internet bị gián đoạn cho tới khi instance mới được dựng lên. Auto Scaling Group có thể tự thay thế instance, nhưng vẫn mất một khoảng thời gian.
Băng thông: NAT Gateway tự mở rộng tới 100 Gbps. Băng thông của NAT instance phụ thuộc vào loại instance, và các instance nhỏ có băng thông nền thấp.
Vận hành và bảo mật: bạn chịu trách nhiệm cập nhật hệ điều hành, theo dõi và cấu hình mạng cho instance.

NAT instance phù hợp khi

Môi trường dev, staging hoặc batch
Throughput ra internet thấp và ổn định
Có thể chấp nhận gián đoạn vài phút khi failover
Đội đã quen vận hành EC2

Nên giữ NAT Gateway khi

Production có yêu cầu sẵn sàng cao
Throughput lớn hoặc khó dự đoán
Đội nhỏ, không muốn thêm hạ tầng tự vận hành
Phần lớn chi phí đã được giảm nhờ VPC Endpoint

Tóm lại

Thứ tự chúng tôi thường áp dụng là: đo traffic theo đích đến, đưa traffic tới dịch vụ AWS qua VPC Endpoint, sửa route để không đi chéo AZ, rồi mới xét tới NAT instance cho những môi trường phù hợp. Với nhiều hệ thống, hai bước đầu đã giảm được phần lớn chi phí NAT mà không cần thay đổi gì về kiến trúc vận hành.

Đây cũng là một ví dụ cho cách CostKernel làm việc: bắt đầu từ dữ liệu thật, đề xuất thay đổi kèm rủi ro rõ ràng, và để đội của bạn quyết định.