API Gateway Private Endpoint


在整理 Overview API Gateway 一開始就提到關於 架構的可視性 (Visibility) 的問題,討論了可能的應用場景與實務架構問題。當時 AWS 的 API Gateway 並沒有 Private 的概念,預設只有 RegionalEdge 兩種類型,而且都是 Public。跟同事討論架構時,大家提出內部服務也需要 Gateway 達到類似限速、安全性控管的功能。

今天一早起來看到 API Gateway Private Endpoint 終於發佈了!期待已久,簡單整理筆記與心得!


實作概念

Private API Gateway 底層主要是利用 AWS PrivateLink 實作與 VPC 的對串實作,底下是官方文件的架構圖:


圖片來源:Create a Private API in Amazon API Gateway

概念如下:

  1. 左邊的 Customer VPC 透過 VPC Endpoint 建立的 EndpointNetworkInterface 跟 API Gateway 介接
  2. 同時利用 Private DNS Name 找到 API Gateway 的 Endpoint
  3. PrivateLink 本身也是有 SecurityGroup 可以管控
  4. API Gateway 本身則透過 Resource Policy 管控


圖片來源:Introducing Amazon API Gateway Private Endpoints


配置步驟

配置

  • 建立 VPC Endpoint:
    • AWS Service Name: com.amazonaws.us-west-2.execute-api
    • 選擇 VPC 和 Subnets: 建議選 Private Subnet
    • Enable Private DNS Name: 這一定要選,不然會找不到 Endpoint
    • Security Group: 注意 outbound 要開 0.0.0.0/0
    • 把 VPC Endpoint ID 記下來,長得這樣:vpce-xxxxxxx
  • 建立一個簡單的 Rest API,注意 Endpoint Type 選擇 Private
  • 配置 Resource Policy,選擇 Source VPC Whitelist,填入 VPC Endpoint ID
  • 部署一個版本,這邊的例子是:wertv1jfp2.execute-api.us-west-2.amazonaws.com

測試

在 EC2 裡面,沒有建立 VPC Endpoint 時直接反查 API Gateway Endpoint 的結果:找不到 DNS

1
2
3
~$ nslookup wertv1jfp2.execute-api.us-west-2.amazonaws.com
Server: 172.31.0.2
Address: 172.31.0.2#53

從 WAN 用 Public DNS 查,查不到:

1
2
3
4
5
~$ nslookup wertv1jfp2.execute-api.us-west-2.amazonaws.com
Server: 8.8.8.8
Address: 8.8.8.8#53

** server can't find wertv1jfp2.execute-api.us-west-2.amazonaws.com: NXDOMAIN

設定好 VPC Endpoint 之後反查的結果:

1
2
3
4
5
6
7
8
9
10
~$ nslookup wertv1jfp2.execute-api.us-west-2.amazonaws.com
Server: 172.31.0.2
Address: 172.31.0.2#53

Non-authoritative answer:
wertv1jfp2.execute-api.us-west-2.amazonaws.com canonical name = execute-api.us-west-2.amazonaws.com.
Name: execute-api.us-west-2.amazonaws.com
Address: 172.31.5.61
Name: execute-api.us-west-2.amazonaws.com
Address: 172.31.10.251

配置 Resource Policy 之前送 request:

1
2
~$ curl https://wertv1jfp2.execute-api.us-west-2.amazonaws.com/v1/
{"message":"Forbidden"}

配置 Resource Policy 之後送 request:

1
2
~$ curl https://wertv1jfp2.execute-api.us-west-2.amazonaws.com/v1/
{"version":"LATEST","funcName":"OpsAPI-Releng","build":{"id":"20180201-1200","hash":"12345","timestampe":"1529035390196"}}

注意事項與問題

  • Resource Policy 的異動需要重新部署
  • Private API Gateway 的 Endpoint 看不出 visiable
    • 所以有很多同時在進行時,要注意團隊能否意會到這是 Private or Regional, or Edge. 建議把這三個字放到 DNS or Rest API Name 的 Prefix
    • 建議用另一個 DNS 可以識別 visiable 的 CName 指向 Endpoint
  • 潛在問題:VPC Endpoint 串接 API Gateway,所以實際上 API Gateway 是放在另一個由 AWS 管理的 VPC 裡面,他的 CIDR 也有可能會跟使用者的 CIDR 碰撞,造成路由混亂的問題。

Microservice 架構的實踐

底下這張圖是規劃 Microservices 的架構圖,搭配 Public / Private API Gateway,還有 Service Discovery、CDN、Message Queue … 最後的圖,整個架構的概念不外乎 OOD、Design Pattern、Cloud Native、CI/CD 相關概念,也包含很多 Designing Distributed Systems 的概念。

圖中的顏色代表以下:

  • 綠色:VPC 內部使用
  • 橘色:允許 Public Sunbet or AWS Service 呼叫,像是 ALB
  • 黃色:直接暴露在 WAN 的 Endpoint


結論

整理 Service Mesh 的過程中,就一直不斷思考他跟 API Gateway 的關係與概念,功能上可能類似,都有共同的特性。目前 Service Mesh 則比較適合配合 k8s 跟著 Service 一起帶著跑,而 API Gateway 我是選擇 Managed Service,所以就無法跟著 k8s 跑 XD

實際上兩者的差異,我還要多思考該怎麼分別,因為功能上真的越來越像了~也許一個是門、一個是窗戶?也許吧 XD

延伸閱讀

參考資料


Comments