主要針對 Multiple VPCs, Regions, Account 的規劃，其中涵蓋到 CIDR / Subnets / Route Table / NAT Gateway / Security Group / Network ACLs… 等規劃。

Considerations

考慮這些面向：Multiple AWS Accounts, Multiple Regions, Multiple VPCs, and On-Premise + Hybrid Cloud

• Multiple AWS Account: 如果有多個 AWS 帳號，要思考帳號本身的用途，以及權限管理方式。
  • 需要用到 EC2-base (IaaS) 的才需要規劃
• Multiple Regions / VPCs: 同時用了多個 Region 的時候，該怎麼規劃每個 Region 的 VPC、如何串接 VPC
• On-Premise: 每個 Region 的 VPC，如果又要跟公司資料中心串接，該如何做？
• Hybrid Cloud: 考慮其他 Public Clouds

CIDR 規劃

如果公司有規劃未來會使用很多 VPC、或者跨 Region，那要為每一個 Region 規劃好 CIDR Block 

• 依據 Private IPv4 Addres Space  的定義 (RFC1918 )，建議使用 24-bit block: 10.0.0.0 - 10.255.255.255 規劃
• 規劃不同的 AWS Account、用途 (Prodution, Test, Development)，各個 CIDR Space
  • 每個 Region 的 VPC 都要先規劃好 CIDR Block
  • 這張表要有人維護，因為訂下去之後，就不能改了
• 要考慮其他的 Public Cloud (GCP, Azure) 的 Network CIDR，像是 GCP 的 VPC Network
• On-Premise 的 CIDR Space，依照公司規模，可能有不同地區、大樓、樓層 … 等
• 要考慮，如果未來有商業的合併，像是合併某家公司，網路要串接時，如何處理 CIDR 碰撞的問題。
  • GCP Project 都會有自己的 VPC Network，預設是一樣的，如果要串接就會遇到 CIDR 碰撞問題。參考： Study Notes – VPC Network in GCP

Connect the VPCs, On-Premise, and Hybrid Cloud

有很多 VPCs，或者是辦公室、甚至是其他 Public Cloud (GCP or Azure) 要串接要注意的地方：

• 如果同一個 Region 可以透過 VPC Peering ，不同 AWS Account 也可以
• 不同 Region，可以用 OpenVPN 串接 Site to Site VPN 串接
• 跟 On-Premise 串接 VPN
• 如果 On-Premise 的資料量很大，公司預算也充足，則可以使用 AWS Direct Connect (DX) 
• 使用 OpenVPN 的 Instance 要注意 Network Throughput 部分
  • PoC 用 t2.nano / t2.micro 就可以
  • 需要大流量，可以使用 r4.large 就會有 10Gbps
• Site to Site VPN 可以透過 Lambda 實作 HA 的 Failover 機制，但是兩邊 VPC 都個要開兩台 EC2 Instances，是否需要 HA 要看 SLA 怎麼定義。

GCP 的 VPC Network 的好處就是，都不用管這些，預設都是可以通的。

Subnet 的規劃

每個 Region 的 VPC 我會依照用途或者功能規劃數個 Subnet

Public Subnet: 通常會規劃幾個給以下用途

• AWS Internet-Facing: ALB / ELB, NAT Gateway / Instance
• ThirdParty: 需要讓第三方打進來 (InBound) 串接的節點
• Bastion / Jumper 跳板機
• DNS Root Domain: Route53 root domain 一定要用 IP
• Reverse Proxy
• OpenVPN:
  • Site to Site VPN
  • Backup VPN: 備援 VPN Instance，平常不開機，特定時候會開，像是辦公室的 VPN 要維護時。

Private Subnets:

• Application: Web Server, DB, Batch, Storage …
• Infra Service: AD, Proxy,
• Office Application (OA): ERP, HR, Finance …
• AWS Services:
  • EC2, Lambda, ECS, EB
  • Internal ALB / ELB
  • RDS, ElastiCache, DynamoDB DAX
  • EFS

VPC Endpoint

讓 VPC 到 AWS Service 可以不用走 Internet，目前支援 S3 和 DynamoDB。

新增 VPC Endpoint 時，需要選擇要 Apply 到哪一些 Route Table，之後會出現類似以下設定：

• Destination: pl-1a2bxxxx
• Target: vpce-11xxxxx

Destination 其實是由 AWS Maintain 的 Public IP List，可以透過 VPC Flow Log 查到實際的資料去處。

使用 VPC Endpoint 實際上效能沒有提升多少，可以參考我這篇測試： Lambda Network Traffic Test in VPC w/ or w/o Endpoint

使用 VPC Endpoint 重點在於可以減少 Network Traffic，然後減省成本，最常見的案例就是從 EC2 備份資料到 S3。如果沒有開 VPC Endpoint，Network Outbound 通常會走 EIP or NAT 出去，整個成本會相對高很多。我的實際案例分享：Migrate to AWS NAT Gateway

規劃上，建議都打開 VPC Endpoint，把 Route Table 設定好。

VPC Peering

可以直接打通兩個同 Region 的 VPC，也可以跨帳號。如果是 Region，則要透過 site to site VPN 打通才行。

Route Table

有多個 VPC 串接後，Route Table 會多以下：

1. VPC Peering
2. VGW: 到辦公室的, 如果是使用 Dynamic (BGP), 在 Route Table 可以打開 Proganation 選項，會自動交換 Route Table
3. Site to Site VPN

NAT Gateway

如果公司要求 SLA 比較高，建議使用 NAT Gateway，但是如果沒有很高的 SLA，像是測試環境、新的 VPC 環境，則可以使用一台 NAT Instance 即可。

使用 NAT Instance 未來一樣可以換成 NAT Gateway，注意把 EIP 保留下來，避免第三方串接單位無法接受 Request。像是串接中華電信 API，中華電信防火牆就會有 NAT IP 的白名單。

參考：Migrate to AWS NAT Gateway

Security Groups (Firewall)

我把 SG 的規劃分成三大類：Public, Protected, Private

利用命名規則管理與識別用。

• Public: 允許直接讓 所有 WAN IP 存取，通常是商業用的服務，Source 都是 0.0.0.0/0，Protocol 則依照需求定義，以下是常見的例子：
  • Public-Default-ELB: HTTP, TCP, 80, 0.0.0.0/0, HTTPS, TCP, 443, 0.0.0.0/0
  • Public-Auth-ELB: HTTPS, TCP, 443, 0.0.0.0/0
• Protected: 只允許 特定 WAN IP 存取，這些通常有 AWS 或者 on premise 的對外 Public IPs ，像是 NAT Gateway 的 EIP、公司的 ADSL IP … 等
• Private: 只允許 公司 LAN IP 存取，這些通常有 AWS VPC CIDR 或者 on premise 的 Private IPs

這三大類都會有一個 Default，像是 Public-Default, Protected-Default, Private-Default，由 Network Engineer, Security 共同維護。

命名規則源自於 物件導向 (封裝, Encapsulation) 的概念。。。

相關文章：Security Groups and Network ACLs

Provisioning

規劃好的 VPC 可以用 CloudFormation, Terraform 先準備好，未來異動可以重複使用。這樣的好處是，規劃時考慮的點，不會遺漏，不會重建 VPC 時，忘記要怎麼規劃，然後設計出有問題的規劃。

相關概念請參考：Resource Provisioning and DevOps