VPC Secondary CIDR or 重建

Secondary CIDR or 重建 VPC 情境判斷

1. **IP 耗盡 vs. **網路設計複雜度
   • 僅因主 CIDR 主機數量用盡
     • 如果原本的 /24（256 個地址）子網幾乎耗盡，且其他子網或可用區還有空間，只需要再增加地址池，就可考慮 新增 secondary CIDR。其主要設計目的就是在原 VPC 不停機的情況下，按需擴充容量 stackoverflow.com。
   • 網路拓撲架構已極度混亂
     • 若路由表、NACL、TGW 附加、跨帳號 Peering、VPN/Direct Connect 等設定交錯，已難以維護或易出錯，重建一個結構清晰、CIDR 設計合理的新 VPC，往往能長期降低運維成本。
2. CIDR 範圍與相依性
   • AWS 允許為 VPC 新增多達五個 IPv4 CIDR，但每個 block 最大也只能到 /16，且不可與現有任何 CIDR 重疊 docs.aws.amazon.com。
   • 如果未來可能還要再擴（例如需要 >65,536 個地址），或原 CIDR 與 on-premise／夥伴 VPC 重疊，secondary 也無法解決，此時必須 重建 VPC，以選用新的 primary CIDR 範圍 repost.aws。
3. 遷移成本與業務容忍度：停機 vs. 零停機
   • 新增 secondary 完全線上，不會影響現有資源；但做 secondary 後，各子網要手動調整、Security Group、路由表要更新，也可能短暫影響部署自動化流程。
   • 若業務對短暫停機能容忍，且 IaC（Terraform/CloudFormation）已覆蓋大部分資源，新建並批量遷移到目標 VPC 的成本反而可能低於後續在舊 VPC 不斷補丁式維護的成本。
4. 長期維護與可擴展性
   • Secondary 是快速解法，但多個 CIDR 後，子網分配、IPAM 規劃會更複雜；
   • 重建新 VPC 則可一次性依據未來 2–3 年的預估規模，設計好 CIDR 分段（例如 10.0.0.0/16），並搭配 VPC IPAM，一次到位。

總結判斷基準

1. IP 耗盡只是眼前問題，且 CIDR 規模尚可 → 使用 Secondary CIDR Block。
2. 原 CIDR 大小錯誤、與對端網路重疊、或未來需更大範圍 → 重建 VPC，並將資源遷移到新的 primary CIDR。
3. 網路設計雜亂、維護成本高 → 視業務停機容忍度，考慮重建以獲得更清晰的架構。
4. 停機不可接受、只是短期容量不足 → 優先 Secondary，並同步評估未來一次性重建的規劃。

---

Secondary CIDR Limitations

• 數量上限

  每個 VPC 預設最多可關聯 5 個 IPv4 CIDR block（包含 1 個 primary、其餘為 secondary），可向 AWS 提出 Service Quota 增加申請，最高可擴展至 50 個 docs.aws.amazon.com。

• 大小限制

  關聯時，CIDR block 的網路遮罩（netmask）須介於 /16（最多 65,536 個地址）與 /28（最少 16 個地址）之間 docs.aws.amazon.com。

• 不可重疊

  新增的 secondary CIDR 必須與該 VPC 已有的所有 CIDR block 完全不重疊，且不得與現有路由表中已存在的目的地路由衝突（例如既有對 VGW、Peering、TGW 等的 /24 路由） docs.aws.amazon.com。

• Primary CIDR 不可移除

  一旦 VPC 建立，其 Primary CIDR block 無法變更或移除；若要減少 CIDR，僅能刪除 secondary block，且必須先刪除該 block 下的所有子網才能移除 docs.aws.amazon.com。

• 地址範圍類型限制

  • 若 Primary CIDR 屬於私有網段（RFC 1918），Secondary 可選用其他 RFC 1918 範圍（如 172.16.0.0/12、192.168.0.0/16）、CGNAT（100.64.0.0/10）或公有可路由網段。
  • 若 Primary CIDR 為公有可路由範圍，則 Secondary 只能為公有可路由範圍，不能再關聯 RFC 1918 或 CGNAT 範圍 linkedin.com。

Usage

Console 上可以直接點選 edit CIDR，但沒辦法移除預設的第一個 CIDR