將最近帮一台湾客户在 AWS 上的 NAT Instance 換成 NAT Gateway，事前評估、驗證、溝通與執行紀錄。

現況

• VPC 的機器大部份都透過 NAT Instance 出去，內部機器上百台
• 機器等級為 m3.medium，擔心 Network Throughput 不夠。
• 這是一台三不管地帶的機器。

問題

• 單點: 使用 EC2 Instance 做 NAT
  • 不定時炸彈 → AWS EC2 Maintenance
  • 無法停機維護: 無法更新 OS Security Patch
  • 如果出現異常，AWS 所有走 NAT 出去的機器，對外連線都會影響
  • AWS 不定期會有維護通知，不知道哪一天會中標
• 頻寬: m3.medium 大約實測有 400Mbps 的頻寬，當整個 VPC 對外流量一大的時候，會造成 bottleneck。
• 資安
  • 資安漏洞
  • 對外開放的位置 – 水桶的裂縫

吞吐量 (Network Throughput)

我們使用的 NAT instance type 是 m3.medium，從 CloudWatch 就可以發現 Network Out 已經達到頂點，實際使用狀況大約在 280Mpbs，如下圖：

其他單位測試 m3.medium 的數據參考，如下圖：

Source: Benchmarking: Network Performance of m1 and m3 instances using iperf tool 

NAT Gateway 評估

以官方這篇比較為參考：Comparison of NAT Instances and NAT Gateways 

有好有壞，以 NAT Gateway 來看，比較如下：

優點：

• 解決 NAT Instance 頻寬不足問題: 10Gbps x 2
• 解決 NAT Instance 資安問題，現在系統更新會有 Downtime
• 沒有維運問題 (人力、Security、溝通協調)

缺點：

• 兩者都沒有 HA，所以規劃時都要考慮進去。NAT Gateway HA 的說明參閱官方文件 NAT Gateway Basics
• NAT Gateway 沒有網路流量分析可以看，要透過 VPC Flo Log + CloudWatch Custom Metric 看。
• 會增加 VPC Route Table 的複雜度，如果 VPC 沒規劃好，會不好切換。

成本：

• NAT Gateway x 2: 44.64 x 2 = 89.28USD / month
• NAT Instance (m3.medium) x 1: 70.28 USD / month
• NAT Gateway 的流量另外計費 (缺點)

事前準備：實驗

NAT 網路架構分析

切換前的網路架構，圖中 ap-northeast-1c 裡的 NAT Instance 就是現況，也就是不管是在 ap-northeast-1a or 1c 對外的流量，全部都會走 NAT Instance。

註：實際上圖中的 public and private subnets 都有數十個。主要是規劃給不同 layers 使用的，像是 DB, Web 分屬不同 layers

預計切換後的網路架構：

1. 在兩個 AZ 各開一個 NAT Gateway
2. 開兩張 Route Table
3. 保留 NAT Instance 的 EIP

切換流程

切換過程必要的考慮因素：不能有 Downtime。基於這樣的考量，以及現況網路架構的複雜程度，規劃三個步驟。剛開始所有的 traffic 都走 Route Table A，接下來步驟：

步棸ㄧ：建立另一張 Route Table B 和新的 NAT Gateway B，並且讓往 0.0.0.0/0 透過 NAT Gateway B 出去。

步驟二：讓所有 Subnets 的 traffic 都走 Route Table B，維持沒有 Downtime

步驟三：

1. 移除 NAT Instance 上的 EIP
2. 建立新的 NAT Gateway A，並且 attach 原本的 EIP
3. 設定 Route Table A 上的 0.0.0.0/0，透過 NAT Gateway A
4. 把 Subnets A 切回 Route Table A

圖檔來源：VPC Route Table 

監控網路流量

原本使用 EC2 Instance 做 NAT 有 CloudWatch 提供的 Network In/Out 可以知道資料流量，但是 NAT Gateway 並沒有 (目前) 提供相關資訊，所以我用 VPC Flow Log + CloudWatch Log + CloudWatch Dashboard 來解這問題。

基本步驟如下：

1. 找到 NAT Gateway 的 ENI: 在 EC2 Console -> ENI
2. 針對這張 ENI 設定 Flow Logs: 要先有 IAM Role，然後指定 CloudWatch Log Groups
3. 上述設定好之後，去上個廁所後，到 CloudWatch Log 後，找到 Log Groups，點選上面藍色的 Create Metric Filter
4. 在 Define Logs Metric Filter 頁面, 設定 Filter Pattern ，如下：
   • Filter Pattern: [version, accountid, interfaceid, srcaddr=<ENI-Private-IP>, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action, log_status]
   • 點選 Test Pattern 是否有找到對應的資料
5. 在 Create Metric Filter and Assign a Metric 頁面的 Metric Details，指定以下：
   • Metric Namespace: NAT-Gateway
   • Metric Name: Network-Out_Bytes
   • Metric Value: $bytes

以上設定好之後，在 CloudWatch Metric 的 Custom Metric 就會出現新的 Metric Namespace，這邊的例子叫做 NAT-Gateway，點進去就可以找到 Metric Name，然後顯示成圖，也可以放在 CloudWatch Dashboard 上，下圖是我做的例子。

如果沒有圖出來，檢查 Graphed metric 裡的 statistic 與 period 設定。

實驗切換

主要要確認 切換流程 的過程中，Subnet 裡的機器對外的 traffic 是不會受到影響的，也就是如果有些應用是會主動去打外面的服務，像是 兩階段驗證、別人家的認證服務 (SSO)、取資料 … 等，就會受到影響。

因為 VPC 裡 subnets 數量非常的多、且上面跑的服務很複雜，沒有人知道切換過程是否會有什麼狀況。

這個實驗是模擬切換 Route Table 過程，持續性的連線從 VPC 裡面連出去外面，是否會受到影響？測試驗證點有兩個：

1. 裡面的機器往外丟大檔案，用 scp 複製 2GiB 的大檔案
2. 裡面的機器持續 ping 外面的機器

持續傳輸或者送 ICMP，過程中切換 Route Table 不會受到影響。

這個實驗可以確認：VPC Route Table 的狀態是持續性的 (Stateful)，跟 Security Group 一樣，不同於 Network ACLs。SGs 跟 Network ACLs 參見 Security Groups and Network ACLs 說明。

事前準備：溝通與協調

• 跟相關單位介紹啥是 NAT (這很重要，大部份的人不會知道 NAT 是做啥的)
• 整理 Subnets 裡有哪一些機器，他們的用途，然後跟相關單位確認，是否有對外連線，連線單位是哪裡？這步驟最辛苦。
  • 同時 NAT 的 EIP 發放要管制，不可以讓其他單位隨意給出去，不然以後會很難調整。
• 協調相關單位，通知外部單位的 IT，增加防火牆白名單規則。這需要一點時間確認

溝通協調這部分，是整個切換過程中，最花費心力的。

後續的問題

• SLA: 目前沒有提供 SLA，參見 NAT Gateway FAQ 
• 監控 NAT Gateway 流量：VPC Flow Log + CloudWatch Log  + CloudWatch Dashboard
  • 設定的時候，直接到 ENI 找到 NAT Gateway 的，然後針對他建立 Flow Log
• 分流：如果未來 Throughput 不夠用，可以另外建立 Route Table + NAT Gateway，就可以達到分流的效果。像是 DB 通常需要做備份，需要大的頻寬，可以給他獨立的。
• Updated 2016/11/13: NAT Traffic 費用很驚人，如果有大量資料備份到外面，像是 DB Fully backup to S3，可以利用 VPC Endpoint 解掉這部分。

參考資料

• Managed NAT (Network Address Translation) Gateway for AWS 
• Migrating to AWS NAT Gateway 
• Comparison of NAT Instances and NAT Gateways 
• Benchmarking: Network Performance of m1 and m3 instances using iperf tool 
• CloudWatch Log – Flow Logs