HackMD
AWS VPC 網路架構 (觀念講解篇)
tags: 概論介紹
VPC 基礎設施 Region/AZ vs VPC/Subnet 關係介紹
◆ AWS Region 介紹
AWS 作為雲端商，會在世界各大地區建立基礎設施，ex: 東京(Tokyo)。
一個實體地區的概念對到 AWS 的架構中就是 Region
每個 Region 內，會建立多個 AZ (Availability Zone)，如下圖：
Availability Zone 為 「邏輯資料中心」，一個 AZ 中會有多個「實體資料中心」，也就是實際放上主機與硬體設備等的地方，如下圖：
如上圖所示，東京地區對應到一個 AWS Region 概念。每個 region 上有多個 AZ，每個 AZ 裡又有多個實體資料中心。
(實體資料中心為上圖的藍色長方體大樓圖像)
◆ AWS Region 與 VPC 關係介紹
VPC 為一種「虛擬的網路區域」，我們會將虛擬資源放入這個網路區域進行管理，ex: EC2 (Elastic Compute Cloud)，他會幫忙管理其中的網路流通。
而在每個 VPC 中，可以涵蓋多個 Subnets，也就是一種「更小單位的虛擬網路區域」，如下圖：
Q：Subnet 與 AZ 的關係為何？
A：每個 Subnet 都會對應到一個 AZ
在 AWS 建議的架構中有所謂的 High Availability (HA)，也就是要我們把程式部屬到不同的 AZ 中，已達到異地備援的概念。
因此，當我們把程式放到 Subnets 前，我們必須先確保這些 Subnets 是否對應到不同的 AZ，以達到 HA 的概念。
下圖紅線部分代表 Subnet 與 AZ 間的對應，可以看到 VPC 透過不同的 Subnet 對應到多個 AZ，達到 High Availability (HA)。
小結
此單元學習 AWS 如何在世界各地設置資料中心，並了解其中 Region 與 Availability Zone (AZ) 的關係。
我們也了解到 AWS 管理網路的服務 VPC，以及其與 Subnet 之間的階層關係，兩者皆用來管理與網路相關的資源與設定。
VPC 架構 Routes & Security
◆ Private Subnet 間的溝通方式
Private Subnet (下圖 #1) 是一個封閉的網路，也就是並沒有對外。
若在 Private Subnet 中放置兩台 EC2(下圖 #2)，因為這兩台在同一個網路空間，因此彼此可以進行溝通。
如果想讓兩個不同 Private Subnet 中的 EC2 溝通，必須使用到 Route Table (下圖 #1)，先到 Route Table 查詢路線後再發送封包訊息。
Route Table 介紹：
每個 Subnet 都會配到一個 Route Table，含有兩個重要的設定：
(1)目的地 IP(下圖 #2) (2)下一站位址 (下圖 #3)
用來指引網路流量若要走到目的地應該先走去哪裡，如下圖：
若想要從左邊 Subnet 的 EC2 連到右邊 Subnet 的 EC2，必須先經過一個 Local (下圖 #1) 的中繼站，當到達最終目的地後，會再返回原出發點（如下圖橘色虛線所示）。
◆ Public Subnet 與 Internet 的溝通方式
Public Subnet 的目的為讓內部網路可以與外界 Internet 溝通。
Public Subnet 的 EC2 要連到 Internet 同樣也需要用到 Route Table 來指引路線。
此時的 Route Table 內容：
(1) 目的地IP (下圖 #1)：Internet
(2) 下一站 (下圖 #2)：放置於 VPC 上的特殊中繼站 IGW (Internet Gateway) (下圖 #3)
◆ Private Subnet 與 Internet 的溝通方式
因為 Private Subnet 是封閉的網路，不能直接對外溝通。
因此若要讓 Private Subnet 中的 EC2 連到 Internet，下一站 (下圖 #1) 就必須先導向 Public Subnet 上的虛擬主機 NAT gw (NAT Gateway) (下圖 #2)，再透過 NAT gw 走到 IGW (下圖 #3) 再到 Internet。
連線路線：
Private Subnet EC2 -> Route Table (Private Subnet) -> Public Subnet NAT gw -> Route Table (Public Subnet) -> IGW -> Route Table (IGW) -> Internet
◆ NACL vs SG 的安全設定介紹
當請求想進出在 Private Subnet 中的 EC2 時，會遇到 Subnet 階層的保護工具 NACL (Network Access Control List)，用於規範何種請求可以進出此 Subnet，如下圖：
當成功通過 NACL 的規範後，請求可以繼續往裡面走，但在碰到 EC2 前，還會遇到 EC2 Instance 階層的保護 SG(Security Group)，是一種類似防火牆規範的工具，請求必須通過此規範才能進到 EC2。
同理我們會認為當請求要離開 EC2 時，同樣會再次受到 SG 的驗證，再原路返回送出此請求的來源。
實際上請求離開 SG 時，不需要再驗證一次，因為 SG 是一個 stateful 的工具。
SG 記得該請求從哪來且自己已允許過該請求進來，離開時便不需要再驗證，這是一個重要的特性，須謹記！！！
小結
(1) AWS VPC 的網路流通方式：
透過 Route Table 的設定，並搭配 NAT gw 和 IGW 來連通內外網。
(2) 安全設定的各種階層：
NACL 以及 Security Group (SG)，需進行驗證才可進入。
SG 為 stateful，因此從 EC2 返回時不須再次驗證。
VPC 架構 SC vs ENI vs EC2 關係介紹
◆ SG 與 EC2 的真實關係
前面提到我們把 SG 當作一個包在 EC2 外層的保護殼。
在概念上沒有錯誤，但實際上，從底層來看，真正的 SG 內部應該是 ENI (Elastic Network Interface) (下圖 #1)，也就是一個類似虛擬網卡的概念。
當我們使用 SG 時，其實也是跟著 ENI 走的，下面我們就來探討 ENI 與EC2 彼此的關係。
◆ ENI 與 EC2 的關係
在理解 ENI 與 EC2 之間的關係前，我們先劃分出 Network 跟 Compute 兩個世界。
- ENI 為網路世界 (Network) 裡的元素
- EC2 為計算資源世界 (Compute) 裡的資源單位
如下圖所示：
ENI 與 EC2 的關係建立於 attach 上，也就是將一個 ENI attach 到一台 EC2 上使用（如下圖藍色虛線所示）
更直接的說法為，將一個虛擬網卡提供給一台虛擬主機使用，此時的 EC2 在 Network 世界就由此 ENI 代表。
但這種 attach 是臨時性的，所以可能產生以下狀況：
假如有天 ENI attach 的 EC2 故障，我們可以將此 EC2 移除（如下圖紅色 X 所示），換上另一台 EC2 來使用原本的 ENI（如下圖藍色虛線所示）。
此操作對於 Network 世界並沒有任何變動，實際上變動的只有將 Compute 世界的運算元素，改成另一個 EC2 運算資源單位。
小結
(1) SG 並非直接給 EC2 使用，而是屬於 ENI 的一部分。
(2) ENI 被 attach 到某一台 EC2 上使用，用來進行網路相關的設定。
參考網站：
Day 4 網路寶石：AWS VPC Region/AZ vs VPC/Subnet 關係介紹
Day 5 網路寶石：AWS VPC 架構 Routes & Security (上)
Day 6 網路寶石：AWS VPC 架構 Routes & Security (下)
AWS教學 - Network - ENI vs SG vs EC2 關係介紹
