Day 13 比較了 VPC Peering、Transit Gateway 與 PrivateLink，當需求是讓兩個 VPC 直接通訊，而且網段沒有重疊時，可以使用 VPC Peering。

今天以 跨帳號、同 Region 的環境進行實作：由 Account A 發起 Peering 請求，Account B 接受，再逐步設定路由與安全群組，驗證兩台 EC2 能否透過私有 IP 通訊。

Peering 顯示 Active，只代表連線已建立。兩側的路由與安全群組，仍然需要各自設定。

準備實作環境

本次使用兩個 AWS 帳號，Region 都選擇東京 ap-northeast-1。

帳號 ID 請換成自己的值，兩個 VPC 的 IPv4 CIDR 不可重疊，否則無法建立 Peering。

本次透過 Session Manager 連線 EC2，使用 ping 驗證 EC2 A → EC2 B 私有 IP 的 ICMP 通訊。

為了簡化管理連線，兩台 EC2 都配置公有 IPv4，透過各自的 Internet Gateway 連到 Systems Manager；跨 VPC 測試使用私有 IP，流量走 Peering。

本實作會產生 EC2、EBS 與公有 IPv4 等費用，完成後請清理資源。全程不需要開放 SSH 22。

建立兩側的 VPC 與 EC2

以下準備工作要分別在 Account A／東京與 Account B／東京完成，操作前請先確認右上角的帳號與 Region。
（以下共用準備步驟的截圖以 Account A 為例，Account B 請依環境表替換名稱與網段，完成相同設定，後續發起與接受 Peering 請求等兩側不同的操作，會另外標明使用的帳號。）

建立 VPC 與子網

進入 VPC → Your VPCs → Create VPC：

1. Resources to create 選擇 VPC only。
2. 輸入環境表中的 VPC 名稱與 IPv4 CIDR。
3. IPv6 先不配置，Tenancy 保留 Default。
4. 建立 VPC。

再進入 Subnets → Create subnet，選擇剛建立的 VPC，依環境表建立子網，可用區選擇目前帳號可用的任一 AZ 即可。

本次保留預設 Network ACL（網路存取控制清單），避免同時加入另一層封包過濾條件。

建立 Internet Gateway 與路由表

在各自帳號的 VPC → Internet gateways 建立：

• Account A：peering-igw-a
• Account B：peering-igw-b

建立後，選取 Internet Gateway，透過 Actions → Attach to a VPC，附加到對應 VPC。

接著進入 Route tables → Create route table，建立 peering-rt-a、peering-rt-b，各自選擇所屬 VPC。

每張路由表都要完成：

1. Subnet associations → Edit subnet associations：勾選對應子網。
2. Routes → Edit routes → Add route：加入 0.0.0.0/0，目標選擇該 VPC 的 Internet Gateway。

此時路由如下：

local 路由由 AWS 自動建立，目前先不要加入跨 VPC 路由。

建立 Session Manager 使用的 Role

在兩個帳號各自進入 IAM → Roles → Create role：

1. Trusted entity type：AWS service。
2. Service or use case：EC2。
3. 附加政策：AmazonSSMManagedInstanceCore。
4. Role name：PeeringLabEC2Role。

兩個帳號可以使用相同 Role 名稱，但它們是各自獨立的 IAM Role，只提供給自己帳號的 EC2 使用。
(上次做跨帳號存取實作時有帶大家建立過 Role 了，這篇就先不展示截圖了！)

建立安全群組與 EC2

在各自 VPC 建立對應的安全群組：

接著進入 EC2 → Instances → Launch instances，分別建立測試主機：

• Name：依環境表填寫。
• AMI：AWS 提供的 Amazon Linux 2023。
• Instance type：例如 t3.micro。
• Key pair：選擇 Proceed without a key pair。
• Network settings → Edit：選擇對應 VPC、Subnet 與安全群組。
• Auto-assign public IP：Enable。
• Advanced network configuration → Primary IP：A 設為 10.10.1.10，B 設為 10.20.1.10。
• Advanced details → IAM instance profile：選擇該帳號的 PeeringLabEC2Role。

AWS 提供的 Amazon Linux 2023 AMI 通常已預裝 SSM Agent。

主機啟動後，分別透過 EC2 → 選取執行個體 → Connect → Session Manager → Connect，確認兩台都能連入。

若尚未可用，先檢查 Instance Profile、公有 IPv4、路由表的子網關聯與對外連線。

Account A 發起請求，Account B 接受

先在 Account B 的 VPC → Your VPCs，記下 peering-vpc-b 的實際 VPC ID，例如 vpc-...。

切回 Account A／東京，進入 VPC → Peering connections → Create peering connection：

建立後，狀態會是 Pending acceptance。

接著登入 Account B／東京，進入 VPC → Peering connections，找到這筆請求。核對 Requester 的帳號 ID 與 VPC ID，再選擇 Actions → Accept request。

Account A 不能用自己的身分替 B 接受請求，接受後先確認連線狀態變成 Active，並記下 pcx-... 的 Peering Connection ID，兩側後續的路由都會使用它。

先測試一次

透過 Session Manager 連入 Account A 的 EC2 A，輸入：

ping -c 4 -W 2 10.20.1.10

此時預期收不到回覆：

4 packets transmitted, 0 received, 100% packet loss

目前路由與安全群組都尚未完整，所以這個結果還不能用來判斷是哪一層阻擋，接下來逐步補上設定。

兩個帳號分別加入路由

在 Account A 選取 peering-rt-a，進入 Routes → Edit routes → Add route：

這條路由讓 A 前往 B 網段的流量走 Peering。

再登入 Account B，在 peering-rt-b 加入：

這條讓 B 的回應能透過 Peering 返回 A，建立或接受 Peering，都不會替對方帳號自動補上這些路由。

完成後，在 EC2 A 重新執行：

ping -c 4 -W 2 10.20.1.10

此時仍預期失敗，因為 B 的安全群組尚未允許 ICMP 請求。

Account B 放行來自 A 的流量

登入 Account B，進入 EC2 → Security Groups → peering-sg-b → Inbound rules → Edit inbound rules，加入：

先使用 A 的私有 IP，將範圍限定在單一主機。

儲存後，在 EC2 A 執行：

ping -c 4 -W 2 10.20.1.10

設定正確時，應該能收到回覆：

64 bytes from 10.20.1.10: icmp_seq=1 ttl=... time=...

這時已經完成跨帳號、私有 IP 的通訊。

同 Region，也可以引用對方的安全群組

本次兩個 VPC 位於同一個 Region，Peering 啟用後，B 可以引用 A 的安全群組作為來源。

先在 Account A 記下 peering-sg-a 的實際安全群組 ID，再於 Account B 將剛才的來源 10.10.1.10/32 那條規則移除，新增一條規則並將來源改為：

111122223333/sg-xxxxxxxxxxxxxxxxx

前半段換成 A 的帳號 ID，後半段換成 peering-sg-a 的 ID。

重新測試，預期仍能成功，此時允許的是透過 Peering、來自附加該安全群組之網路介面的流量，不再只綁定 10.10.1.10。

安全群組引用不會複製對方的規則，也不會建立路由，跨 Region Peering 無法引用對方安全群組，需要改用私有 IP 或 CIDR。

從成功狀態，分別驗證回程路由與安全群組

前面同時缺少路由與安全群組設定，無法只靠失敗結果分辨原因，現在已經成功連線，就可以一次移除一個條件，觀察差異。

移除 B 的回程路由

在 Account B／peering-rt-b，暫時刪除：

10.10.0.0/16 → pcx-...

保留安全群組規則與 A 的路由，再從 EC2 A 發起 Ping，預期收不到回覆。

B 雖然仍有通往 Internet Gateway 的預設路由，但不能靠網際網路將回應送往 A 的私有 IP，安全群組允許回應，不會替你補上回程路徑。

將這條路由加回後，重新測試一遍確認能成功。

移除 B 的 ICMP 入站規則

保持雙向路由完整，在 Account B／peering-sg-b 暫時移除剛才允許 A 的 Echo Request 規則，再從 EC2 A 發起新的 Ping，預期失敗。

將規則加回後，重新測試一遍確認能成功，這次路徑沒有改變，變動的是 B 是否允許請求進入。

以下將測試結果整理成表格：

連通之後，開放範圍仍要分開管理

這次驗證的是 EC2 A 能透過 Peering，向 EC2 B 的私有 IP 發送 ICMP 請求並取得回應，Ping 成功還不能證明 HTTP 或資料庫連線正常；那些測試還需要對應的連接埠規則，以及正在監聽的服務。

在這個案例中，我會讓路由表提供通往對方 VPC 的路徑，再由安全群組限定來源與協定，跨帳號操作時，A 負責自己的路由與發送端設定，B 負責接受連線、回程路由與接收端規則，雙方都完成才有完整的通訊路徑。

清理測試資源

完成後，在兩個帳號分別清理本次建立的資源：

1. 終止兩台 EC2，確認不再需要的 EBS 磁碟已刪除。
2. 移除 B 引用 A 安全群組的測試規則。
3. 刪除兩側的 Peering 路由，再由任一側刪除 Peering Connection。
4. 刪除測試子網、安全群組與自訂路由表。
5. 卸離並刪除 Internet Gateway，再刪除測試 VPC。
6. 若 PeeringLabEC2Role 與對應 Instance Profile 不再使用，一併移除。

只刪除 Peering，不會自動刪除另一個帳號的 EC2 或其他測試資源。

下一篇

到這裡，網路篇先告一段落了！接下來會繼續往下介紹資料的存放方式，從應用程式如何讀寫檔案出發，比較 S3、EBS 與 EFS，看看物件、區塊與共享檔案存取如何影響選擇。

參考資料

• AWS 官方文件｜Create a VPC peering connection
• AWS 官方文件｜Accept or reject a VPC peering connection
• AWS 官方文件｜Update your route tables for a VPC peering connection
• AWS 官方文件｜Update your security groups to reference peer security groups
• AWS 官方文件｜Connect to your Amazon EC2 instance using Session Manager
• AWS 官方文件｜Step 1: Complete Session Manager prerequisites