Góc nhìn về Nat Instance >< Nat Gateway

Đây là bài mình viết cũng đã trình bày trên blog kaopiz.kipalog của công ty.

Bài viết hôm nay mình xin nói về sử dụng Nat Instance và Nat Gateway lúc nào thì hợp lý. Tiết kiệm chi phí phù hợp với từng bài toán. Nat Gateway là tốt nhưng không phải lúc nào cũng tuân theo usecase của AWS là luôn dùng Nat Gateway.

Đầu tiên nói đến bài toán vì sao phải sử dụng Nat Instance hay Nat Gateway. Nếu ai chúng ta làm quen với AWS đều biết tới khái niệm Private Subnet. Và những resources đặt trong nó mục đích đảm bảo bảo mật cho hệ thống. Nếu ở các resource đó, muốn kết nối với internet (ví dụ download software chẳng hạn) thì cần có 1 cầu nối ra ngoài. Từ đó chúng ta phải sử dụng Nat Instance/Nat Gateway. Nhiều dự án ở Kaopiz vì không có nhiều chi phí để tạo thêm Nat nên không tuân theo usecase của AWS, chấp nhận đặt tất cả resources trong Public Subnet và giới hạn bằng cách sử dụng security group. Từ đó, mình thiết nghĩ nên tìm hiểu sâu hơn về cách áp dụng và chi phí để vẫn áp dụng được usecase của AWS và sắm sửa cho hệ thống 1 infra có tâm hồn đẹp :)).

Vào năm 2015, AWS ra mắt Nat Gateway được coi là 1 service tốt hơn Nat Instance. Quả thực, Nat Gateway có nhiều lợi thế hơn Nat Instance. Bạn có thểm tham khảo bản so sánh từ đây

1. Tại sao không đặt mọi thứ trong Public Subnet

Việc này chúng ta thường xuyên nghe rằng không nên đặt trong public, rằng nên đặt trong private subnet như mình nói ở trên. Nếu chúng ta đặt trong Public Subnet thì đã không có cái vấn đề Nat Gateway hay Nat Instance rồi. Có 2 lý do chính quyết định là:

• Security nên là nhiều layer. Chúng ta không muốn chỉ có 1 cấu hình của 1 layer bị lỗi dẫn tới mọi thứ bị public. Usecase sẽ là perfect Security Group và NACL để đạt được mục đích. Cái này sẽ là tốt nếu tất cả các resource được tách biệt khỏi internet và được bảo mật qua Security Group và NACL.
• Nếu chúng ta hướng tới cấu hình 1 infrastructure as code, ví dụ như sử dụng Terraform, Cloudformation. Các mô hình template đều tuân thủ Usecase của AWS. Chúng ta sẽ dễ dàng viết template và nó mang tính đồng bộ với cộng đồng hơn. Thay vì với kiến trúc đặt tất cả ở Public subnet

2. Nat Gateway và Nat Instance trong hệ thống

Cả Nat Gateway và Instance thường dùng để cung cấp truy cập internet tới các resources trong private subnet (cách thức mà không phải đi trực tiếp từ Internet Gateway tới Resoures và phải qua Nat).
Với 1 private subnet sẽ có Route Table như dưới :

Nghĩa là mọi service sử dụng route table sẽ không thể pull update từ internet, hoặc không thể call API từ tới hệ thống ngoài internet. Với 1 số hệ thống chúng ta chỉ cần connect internet lúc đầu, với 1 số hệ thống thì phải làm nó thường xuyên, như 1 job luôn vậy. Lược đồ sẽ kiểu như thế này :

Kịch bản như trên là tất cả connect từ bên ngoài tới server đều phải đi qua load balancer. RDS thì chỉ connect được tới các server. Bên ngoài cũng không connect tới được. Từ đó như đã nói ở trên. Ví dụ các server có yêu cầu pull update từ internet. Chúng ta cần sinh ra Nat Gateway/Instance.

3. Nat Instance

Nếu sử dụng Nat Instance chúng ta cần có Route Table như sau:

Với ENI là Elastic Network Interface của Nat Instance. 1 Nat Instance thì không khác gì 1 EC2 bình thường, và nó được tạo từ NAT AMI. Mục đích như cái tên của nó NAT (Network Address Translation).

4. Nat Gateway

Được ra mắt cũng được vài năm mang nhiều ưu điểm. Nat Gateway được quản lý hoàn toàn bởi AWS. Tức là chúng ta không cần quan tâm gì thì nó vẫn sống không Nat Instance bản chất chỉ là 1 server, có thể chết bất cứ lúc nào (cái này cũng hiếm thôi :))). Chính vì vậy Nat Gateway luôn available và scalable. 1 EC2 bình thường sẽ có 1 giới hạn về Network capacity, và nó sẽ không thể scale lên khi cần. Tức là nếu ta dùng 1 Nat Instance có giới hạn Network Performance là 1GBs thì nếu chúng ta cần cao hơn thì nó cũng không thể tăng được. Nó sẽ như 1 bottle neck vậy.
Và Nat Gateway thì không thế, nó được tạo dễ dàng và Amazone lo cho chúng ta. 1 Route Table với Nat Gateway sẽ như thế này :

5. Sự khác nhau, bài toán nên dùng

Hầu hết các technical từ AWS đều khuyên sử dụng Nat Gatway vì các lợi điểm đang nói ở trên. Vậy tại sao có nhiều phrase vẫn sử dụng Nat Instance? Đơn giản là vì Cost . Chúng ta sẽ thấy nhiều môi trường như (Development, Test,…) đặt trên AWS, nếu tuân thủ đặt trong private subnet thì tổng chi phí về server khéo còn nhỏ hơn cái tiền bỏ ra cho nat gateway.
Ví dụ Nat Gateway thì chính xác là không được gọi là rẻ. Với region us-east-1 chẳng hạn là 0.048$/hour tức là 35$/month. Gần tương đương con server medium rồi. Mà được mấy server test là medium đâu :))

Chính vì vậy người ta mới đặt ra chỉ chạy Nat Gateway cho môi trường product. Và Nat Instance cho môi trường (Test). Bởi vì với 1 server Nat Instance, bạn chỉ cần chọn 1 server nano hoặc micro thôi, phiên bản thường có bandwidth là 5Gbit/s. Vì nó không cần xử lý gì, nhiệm vụ của nó chỉ là trung gian nhận traffic và route tới internet mà thôi.
Thêm nữa 1 Nat Instance cơ bản là 1 server trung gian, vì thế ta cũng có thể sử dụng nó như 1 Basion Host để có thể ssh tới các server bên trong private subnet. Coi như 1 công đôi việc, tiết kiệm đủ đường.

Nhưng khoan đã, có nhất thiết là chỉ có môi trường Test mới nên sử dụng Nat Instance và Product với Nat Gatway? Thử đánh giá lại xem nhá. Từ giải thích ở trên về Nat Instance, việc download software nhanh hay chậm không phụ thuộc vào server to như thế nào, mà phụ thuộc vào bandwidth của network. Ở đây ví dụ mình dùng server lởm thì là 5Gbit/s. Việc sử dụng Nat Gayway hay Instance sẽ phụ thuộc vào các bài toán như sau:

• Nếu là môi trường Test, trừ phi bạn muốn môi trường giống 100% môi trường product thì mới dùng Nat Gatway, còn không chỉ nên dùng Nat Instance.
• Nếu là môi trường product, nếu bài toán ở đó các server phải thường xuyên hoặc liên tục call API bên ngoài internet, download software, file, v,v,v, thì chúng ta nên sử dụng Nat Gateway. Điểm đặc biệt của nó là scalable và tính ổn đinh. Hơn nữa nếu hệ thống được đặt trên nhiều Availability Zone và thực sự có nhu cầu cao, để tránh hiện tượng bottle neck, tất cả traffic đều đi qua 1 Nat Gateway, thì chúng ta nên tạo cho mỗi zone 1 Nat Gateway nhé.
• Với hệ thống production, bài toán chỉ cần Nat phục vụ cho security. Việc Call API, download … không phải là thường xuyên, hoặc nếu thường xuyên thì nhu cầu đáp ứng về network bandwidth không cần quá cao. Thì hãy nghĩ tới Nat Instance nhé. Và sử dụng nó là Basion Host luôn. Cũng như ý trên thì nếu nhiều zone mà nhu cầu cao trong 1 thời điểm thì nên dùng nhiều Nat Instance. Cân đo đong đếm thì việc dùng nat instance thực sự rẻ hơn nhiều.

Vậy bạn nghĩ sao với các hệ thống ở của công ty đang không tuân thủ Usecase của AWS. Theo cá nhân mình việc mua thêm 1 con nano hoặc micro phục vụ luôn 2 nhiệm vụ Nat và BasionHost để hệ thống có tâm hồn đẹp hơn thì đâu có tiếc gì nhỉ :D

6. Tài liệu tham khảo:

Bạn có thể tạo 1 Nat Instance dựa vào các tài liệu sau nhé.
https://github.com/coopernurse/vpc-nat-cfn/blob/master/vpc-nat-cfn.yml
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html
https://www.theguild.nl/cost-saving-with-nat-instances/
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html
https://www.youtube.com/watch?v=vIGEmrhiuXo

---

• ← Previous Post
• Next Post →

---

---