前言

寫到這裡，終於要開始動手建立我們整個基礎設施的第一塊積木 —— VPC (Virtual Private Cloud)。雖然 AWS 在每個 region 都會預設幫我們建好一個 default VPC，但實際上在真實專案裡，大家幾乎不會直接拿 default VPC 來跑服務。原因很簡單：default VPC 雖然能讓你快速起服務，但它的 subnet 配置、routing 規則、甚至是安全性都不符合 production 環境的需求。舉例像是 default VPC 的 CIDR 範圍，預設是會切 172.31.0.0/16，但這不一定會符合企業內部的網路政策；另外，default VPC 裡面的 subnet 切法也不一定會符合使用需求，因此還不如直接重建一套 VPC。

架構設計

這次公司內部建立 EKS 的專案，會需要滿足以下幾項條件：

1. 需要與公司內網的 Gitlab 對接，因此 IP 被限制最多只能切到 /21
2. 所有 workload 都必須放在 Private Subnet 中
3. 因為屬於內部使用的環境，以低成本的方案為優先考量，所以只開一個 NAT gateway
4. RDS 等其他 workload 會需要連線、且需放置於 VPC 內的服務，必須放在無法主動進出的 intra subnet 中

因此這次建立 VPC 的架構圖預計會長得像這樣：

Terraform VPC module

接著就是使用 Terraform 來實作了。要自己一個一個建 VPC / Subnet / Route Table 當然可以，但要建立的資源非常多、盤點起來非常麻煩。好在社群早就有一個成熟的 module 可以直接使用：terraform-aws-vpc。

最基本的配置可以長以下這樣：

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.5.1"

  name = var.vpc_name
  cidr = "10.0.0.0/21"

  azs                 = ["ap-northease-1a", "ap-northease-1c"]
  public_subnets      = ["10.0.0.0/24", "10.0.4.0/24"]
  public_subnet_tags  = { Class = "public" }
  intra_subnets       = ["10.0.1.0/24", "10.0.5.0/24"]
  intra_subnet_tags   = { Class = "intra" }
  private_subnets     = ["10.0.2.0/23", "10.0.6.0/23"]
  private_subnet_tags = { 
    Class = "private"
    "karpenter.sh/discovery" = var.vpc_name # for Karpenter discovery
  }

  enable_nat_gateway     = true
  single_nat_gateway     = true # make the cost cheaper
  # to prevent unexcepted ip change, it's recommended to manage elastic ip out of this module.
  reuse_nat_ips       = true
  external_nat_ip_ids = var.eip_ids
}

這一段 code 幾乎就是最小可用的 VPC module 配置了：

• cidr 是 VPC 的主要網段，這裡我用了 10.0.0.0/21。
• azs 用來指定我們要分散在哪些可用區，這樣才能達到高可用。
• public_subnets 和 private_subnets 對應上面的設計，會各自自動掛上 Internet Gateway / NAT Gateway。
• 在 private subnet 中，我們特意另外掛上了 "karpenter.sh/discovery" = var.vpc_name 的 tag，是為了讓之後部署 Karpenter 時，可以讓 Karpenter controller 可以知道新的 instance 必須要開在哪個 subnet 裡面
• enable_nat_gateway = true 表示我們要讓 private subnet 有辦法安全連外，並且開啟 single_nat_gateway = true 來避免過高的費用（不過會犧牲 NAT 的高可用性）
• 建好 VPC 之後的 Routing
  • Public Subnet：這裡之後會放上 load balancer，目前會直接掛上 Internet Gateway。因此建出來的 Subnet Route Table 會有一條 0.0.0.0/0 → igw-xxxx 的規則。
  • Private Subnet：只允許透過 NAT GW 連外。Route Table 看起來會像 0.0.0.0/0 → nat-xxxx。
  • NAT Gateway：算是 AWS 的「出口閘道器」，避免私有資源暴露在公網。雖然 NAT GW 是要錢的（記得注意帳單 🥲），但任何環境基本上都會需要。

Apply！

當我們 terraform apply 完後，就可以用以下指令驗證 Subnet：

aws ec2 describe-subnets --filters "Name=vpc-id,Values=vpc-xxxx"

或者乾脆打開 AWS Console 的 VPC → Resource map，就能清楚看到 Public / Private Subnet 的區分，以及 NAT Gateway 是否正確掛載。

（擋住的是已建立的 VPC 本名，因為是公司專案所以還是要碼一下 🤫）

延伸經驗補充

在這邊也想分享一個自己遇過的狀況：我們一開始因為沒有考慮到未來需要與內網對接，因此快樂的切了一個 /18 的網段，結果發現要跟內網對接之後，跟 IT 團隊確認了 CIDR 範圍，才發現我們的 CIDR 是真的撞爛，需要重切 CIDR 才有辦法向內網連線，因此才會有這個重建 EKS 的專案產生。這點算是血淋淋的經驗，提醒大家一定要先跟網管 / 資安團隊對齊，確保 CIDR 規劃不會衝突。

註：後來我們在研究 VPC 的進階功能時有發現，VPC 有 secondary CIDR 的概念，有可能這個 feature 就能滿足我們的需求，這個還尚待我們研究確認。

另外，目前這個專案用到的 AWS provider 還停在 5.x，而且 VPC module 也還是 5.x 的版本。老實說我們內部也知道社群和官方 provider 都已經升到 6.x，但實在業務太多，一直沒抽出時間來處理升版。建議大家如果有餘裕，真的可以 經常追 module / provider 更新，因為這不只是新功能問題，還包含安全性修補和可用性提升。等到有一天踩到 bug 或安全警告，才會發現「早知道就該早點升級了」🥲。

外部參考

• terraform-aws-vpc Module Release Page
• Terraform AWS Provider Release Page

建立好我們的 VPC 之後，明天就會來接著建立 EKS 本人了！