建立 Amazon VPC 的 High Availability NAT 架構

Amazon VPC 的架構裡最讓人碎碎唸的一個架構:NAT instance。

Amazon VPC 分成 Public Network 與 Private Network。

前者的 Public Network,裡面的機器除了會有 Private IP 外,需要申請 Public IP (可以是隨機分配,也可以是 Elastic IP) 透過 Intenet Gateway (沒有 NAT 功能) 連外,這邊問題比較小,因為 Routing Table 設一下就好了,High Availability 以及 Scalablility 的問題 AWS 會自己解決掉。

後者 Private Network 因為需要自己架設 NAT instance,所以要自己處理 High Availability 以及 Scalability 問題,由於把機器丟在後面,前面用 ELB 是蠻常見的架構,AWS 一直沒推出 NAT service 讓人感覺很疑惑...

目前一般在處理 Private Network 的 HA NAT 架構是參考「High Availability for Amazon VPC NAT Instances: An Example」這篇文章,但這篇文章的作法有點複雜。

我可以接受有一些 downtime 時間以及一些小狀況,相對的,我想要換取極低的管理成本。

研究了一陣子,最後決定的作法是受到「An Alternative Approach to “HA” NAT on AWS」這篇的啟發,這篇也只講了很簡單的概念,實際上還是要自己研究。

目前是做在 us-west-2 (Oregon) 的 1b 與 1c 兩個 AZ 上。下面討論時就不說明這點了。

規劃的想法是 1b 與 1c 兩個 AZ 各建立一個 auto scaling group,透過 auto scaling 各跑一台 NAT instance 處理自己 AZ 的 NAT traffic (所以不是手動跑)。然後我不想要自己建 image 寫太多 hard code 進去,最好是現成的用一用就好 XD

所以有幾個重點:

  • NAT instance 拿現成的 amzn-ami-vpc-nat 使用,寫這篇文章時是用 2014.09 版。
  • 由於官方的 NAT instance 支援 userdata 在開機時執行指令,所以完全透過 userdata 指定需要的做動就好。
  • 由於 Amazon 官方給的 instance 有 aws 這隻工具 (aws-cli),而這隻工具在有掛上 IAM Role 時會去 http://169.254.169.254/ 上取得對應的 IAM Role 權限,所以都不需要寫太多 hard code 的東西進去。

機器開起來以後希望做幾件事情:

  • 把自己的 Source/Destination IP check 關閉。
  • 把傳進來的 Route Table 的 0.0.0.0/8 設成自己。這邊需要傳進來是由於 NAT instance 是跑在 Public Network 裡,我不會知道要改哪個 Route Table。

所以就有兩個重點,一個是 userdata,其中粗體是要修改的 route table id:

#!/bin/bash
ROUTE_TABLE_ID=rtb-1a2b3c4d
INSTANCE_ID=$(curl http://169.254.169.254/latest/meta-data/instance-id)
aws ec2 modify-instance-attribute \
    --region us-west-2 \
    --instance-id "${INSTANCE_ID}" \
    --no-source-dest-check
aws ec2 replace-route \
    --region us-west-2 \
    --route-table-id "${ROUTE_TABLE_ID}" \
    --destination-cidr-block 0.0.0.0/0 \
    --instance-id "${INSTANCE_ID}" || \
aws ec2 create-route \
    --region us-west-2 \
    --route-table-id "${ROUTE_TABLE_ID}" \
    --destination-cidr-block 0.0.0.0/0 \
    --instance-id "${INSTANCE_ID}"

最前面事先抓 instance_id,然後修改 Source/Destination 檢查,最後面的指令是先試著 ReplaceRoute,如果失敗就 CreateRoute (注意到 shell 的 || 操作)。

另外的重點是 IAM Role,這台機器對應的 IAM Role 權限要開三個:

{
  "Statement": [
    {
      "Action": [
        "ec2:CreateRoute",
        "ec2:ReplaceRoute",
        "ec2:ModifyInstanceAttribute"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

拿 t2.medium 測試,burst 可以到 200Mbps 左右,應該還算夠用?反正不夠用就自己挑其他機器開吧 XD

最後討論一下 Availability 的情況。這樣的架構可能會有七八分鐘的 downtime,也就是當 instance 掛了,被 auto scaling 重新拉一台新的起來。這邊不做 cross-zone NAT 是因為這樣比較簡單,這邊的 downtime 我還可以接受。

至於某個 zone 掛掉,應該 cross-zone NAT 趕快導到另外一區的問題... 整個 zone 都滅了就沒有這個問題啊 XDDD

This entry was posted in AWS, Cloud, Computer, Murmuring, Network and tagged , , , , , , , , , , . Bookmark the permalink.

2 Responses to 建立 Amazon VPC 的 High Availability NAT 架構

  1. Pjack says:

    我覺得是因為 NAT 作法會造成網路流量集中, 不存在很漂亮的 scale-out 方式, 對網路流量很大的 Service 來說, NAT 甚至可能會變成 SPOF 或是 bottleneck, 所以不會是 AWS 所提供的 solution. 另外以我自己使用 AWS 的經驗來看, 在 Private VPC 內幾乎都不需要連外, 唯一在架構上無法避免的是 S3, 而我打聽到的消息是 AWS 即將會推出在 Private VPC 內也可以連到 S3 的 solution, 這可能就可以解決很大部份的問題了.

  2. duyhsieh says:

    AWS現在有出一個NAT Gateway,效能跟管理上應該比自己建NAT instance好很多;而且這樣全部的APserver都不需要public IP了,跟ELB串接也很方便

Leave a Reply

Your email address will not be published. Required fields are marked *