Migrate to AWS NAT Gateway


將公司在 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,或者我整理的 Study Notes - VPC
  • 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 裡的 statisticperiod 設定。

實驗切換

主要要確認 切換流程 的過程中,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 解掉這部分。

延伸閱讀 (站內)

參考資料


Comments