嗯...最近在看 AWS 的東西，特別是網路這塊。說真的，一開始碰到 VPC 真的會頭痛。什麼 VPC、Subnet、Route Table、IGW...一堆縮寫，感覺像在念咒語。剛好看到 TryHackMe 上有一個關於 AWS VPC 攻擊與防禦的房間，就想說邊看邊整理一下思緒，用比較...你知道的，比較人話的方式把它記下來。
這不是那種一步一步帶你操作的教學，比較像是我自己吸收消化後的筆記。希望能幫助同樣覺得 AWS 網路很複雜的人，稍微理清一點頭緒。
重點一句話
簡單講，AWS VPC 就是你在雲端上的一塊私人土地，你可以自己規劃裡面的道路（路由）和門禁（防火牆）。但正因為彈性這麼大，一個小設定沒搞好，就等於大門敞開，駭客就能直接走進你家後院。
VPC 到底是什麼？一個虛擬的網路世界
想像一下，AWS 是一棟超大的公寓，裡面住了幾百萬個房客。VPC (Virtual Private Cloud) 就像是 AWS 給你的專屬樓層，這個樓層跟你鄰居的樓層是完全隔離開的，他的網路流量碰不到你，你的也碰不到他。這就是最基本的邏輯隔離。
每個 AWS 帳號在建立時，其實在各個區域（Region）都已經幫你蓋好了一個預設的 VPC。但老實說，我自己是覺得，除非你只是想玩玩 EC2，不然最好還是自己從頭規劃一個。為什麼？因為預設的 VPC CIDR (可以想成是 IP 地址的範圍) 大家用的都差不多是 172.31.0.0/16，未來要跟其他網路對接的時候，很容易發生 IP 衝突，到時候就頭大了。
所以，你可以把 VPC 看成是你在 AWS 上的網路總規劃藍圖。你在這個藍圖裡定義好你的 IP 地址範圍，然後開始把這塊「地」切成更小的區塊，也就是接下來要說的 Subnet。
VPC 的核心零件：子網路、路由表、還有通往世界的門
光有 VPC 這塊地還不夠，你得在上面蓋房子、鋪路。這就牽涉到幾個關鍵的東西。
子網路 (Subnets)
這就像在你 VPC 這塊大土地上，劃分出來的幾個小院子。每個子網路都必須存在於一個特定的可用區域 (Availability Zone, AZ) 裡面，不能跨區。劃分的時候，IP 範圍也不能互相重疊。這很重要，因為你可以把需要對外服務的機器（例如網站伺服器）放在一個子網路，把極度機密的資料庫放在另一個子網路。
路由表 (Route Tables)
路由表...嗯，就是你 VPC 裡的 GPS 導航系統。它告訴網路封包該往哪裡走。每個子網路都得跟一個路由表關聯。這個路由表會定義規則，像是「所有要去網際網路 (0.0.0.0/0) 的流量，請走 A 門」，或是「要去公司內部網路 (10.0.0.0/8) 的流量，請走 B 橋」。
公開子網路 vs. 私有子網路
這邊有個很多人會搞混的觀念。AWS 裡面沒有一個按鈕叫做「設定為公開子網路」。一個子網路是公開還是私有，完全取決於它的路由表。
- 公開子網路 (Public Subnet): 如果這個子網路的路由表裡有一條規則，把流量直接指向「網際網路閘道 (Internet Gateway, IGW)」，那它就是公開的。放在裡面的機器只要有公開 IP，就能從外面連進來。
- 私有子網路 (Private Subnet): 如果路由表沒有直接通往 IGW 的路，那它就是私有的。就算裡面的機器有公開 IP 也沒用，因為封包根本不知道怎麼出去或進來。
從攻擊者的角度想，這超關鍵的。如果我能用某種方式拿到 IAM 權限，去修改你的路由表，我就可以神不知鬼不覺地把一個你以為很安全的「私有」子網路，加上一條通往 IGW 的路由，然後...嘿嘿，你懂的。
雲端上的兩個保鑣：NACLs vs. Security Groups
好了，網路通了，接下來就是門禁管制。AWS 提供了兩種主要的網路層防火牆，Security Groups (安全群組) 和 NACLs (網路存取控制清單)。這兩個東西常常讓人混淆，我把它們的差別整理一下。
我自己是覺得，你可以把 NACL 想成是社區大樓的警衛，他管的是整個社區（子網路）的出入。而 Security Group 就像是你家自己門上的鎖，只管你這一戶（EC2 實例）。
| 特性 | Security Groups (SG) - 你家的門鎖 | Network ACLs (NACL) - 社區警衛 |
|---|---|---|
| 作用層級 | 綁在 EC2 實例的網卡 (ENI) 上。很精細。 | 綁在整個子網路上。範圍很大，一改就影響全部。 |
| 規則類型 | 只有「允許」(Allow) 規則。預設全部拒絕。 | 同時有「允許」(Allow) 和「拒絕」(Deny) 規則。 |
| 狀態 | 有狀態 (Stateful)。你放行的流量，回來的路自動放行，不用再設規則。很方便。 | 無狀態 (Stateless)。進來的規則要設，出去的也要設。不然你的伺服器回覆會被擋掉。很麻煩。 |
| 規則處理 | 評估所有規則後才決定要不要放行。 | 按規則編號由小到大處理，一配對到就執行，不管後面的。順序很重要！ |
| 常用情境 | 日常主要的防火牆。幾乎所有 EC2 都靠它。 | 用來做大範圍的黑名單，比如你想封鎖某個惡意 IP 段訪問你整個子網路。比較少用。 |
所以說，絕大多數情況下，你會用 Security Group 來做精細的權限控管。NACLs 因為影響範圍太大，而且是無狀態的，設定起來很麻煩又容易出錯，通常只有在真的需要對整個子網路做無差別封鎖時才會動它。
哪些服務在 VPC 內，哪些在外面？
這又是一個會讓人腦袋打結的點。不是所有 AWS 服務都住在你的 VPC 裡。
- 住在 VPC 裡面：EC2 虛擬主機、RDS 資料庫、RedShift 數據倉儲... 這些服務你可以用 Security Group 和 NACL 來保護它們。它們都有一個叫做 ENI (Elastic Network Interface) 的虛擬網卡，代表它們在你的 VPC 裡有一個「戶籍」。
- 住在 VPC 外面：S3 儲存桶、DynamoDB NoSQL 資料庫、SQS 佇列... 這些是全域或區域級的服務，它們預設是透過公網存取，不受你 VPC 裡的防火牆規則影響。保護它們主要靠的是 IAM 權限政策和服務本身的政策 (例如 S3 Bucket Policy)。
那問題來了，我在私有子網路裡的 EC2，不能連外網，那我要怎麼去存取 S3 上的檔案？難道只能開一條路到網際網路，然後再連回來嗎？這樣不是很不安全？
這就帶出了下一個很酷的概念：VPC 蟲洞。
VPC 蟲洞：Endpoints 和 PrivateLink
這是我自己亂取的名詞啦，但我覺得很貼切。當你想讓 VPC 內的服務，可以「私下」跟 VPC 外的 AWS 服務溝通，而不用繞道公網，你就會用到這兩個東西。
VPC Endpoints
這就像在你的 VPC 和 S3 或 DynamoDB 之間開一條專用密道。主要有兩種：
- Gateway Endpoints：這是比較早期的作法，只支援 S3 和 DynamoDB。它會在你的路由表上加上一個特殊的目標 (一個 prefix list ID)，讓流量直接導向 S3 的網路，而不是網際網路。重點是，這個是免費的。
- Interface Endpoints (底層是 AWS PrivateLink)：這是比較新的作法，支援超多 AWS 服務。它會在你的子網路裡建立一個 ENI，給你一個私有 IP。你的 EC2 只要把流量送到這個 IP，就可以連到對應的 AWS 服務。這就像把 S3 服務在你的 VPC 裡裝了一個分身一樣。
從防禦者的角度看，這超棒！可以把私有子網路的對外網路完全封死，只開特定服務的 Endpoint，安全性大大提升。不過，從攻擊者的角度...如果我駭進你的 EC2，發現有一個通往 S3 的 Endpoint，而且權限沒設好，我就可以利用這個「內部通道」把你的資料偷偷傳到我自己的 S3 桶子裡。防不勝防啊。
這個概念也跟台灣的一些產業法規有關。例如，如果你是金融業或醫療業，主管機關可能會要求敏感資料不能離開台灣。這時，你就可以把應用放在亞太區域（比如東京 `ap-northeast-1`），然後透過 VPC Endpoint 這類技術確保資料在傳輸到 S3 時，是走在 AWS 的骨幹網路上，而不是繞去公共網際網路，這在合規性上會比較站得住腳。這也呼應了 `AWS Well-Architected Framework` 裡面提到的安全性支柱（Security Pillar）原則。
採購/預算思路：安全是有價的
講了這麼多酷炫的功能，但天下沒有白吃的午餐。很多增強安全性的設計，都是要錢的，而且有時候還不便宜。
- NAT Gateway：如果你私有子網路裡的機器需要主動連外網（例如更新套件），你通常會需要一個 NAT Gateway。這東西是按小時計費，而且流經它的流量也是按 GB 計費。流量一大，一個月多個幾十甚至上百美金都很正常。
- Interface Endpoints (PrivateLink)：前面提到的新式 Endpoint，也是按小時計費，外加流量處理費。雖然很安全方便，但如果你要接的服務一多，這筆費用也是很可觀的。
- Transit Gateway：當你的 VPC 多到一個程度，用 VPC Peering 串接會變成一場惡夢，這時候就會用 Transit Gateway 來集中管理。它就像一個雲端路由器，但同樣...按連接數和流量計費。
- GuardDuty、DNS Query Logging：這些監控服務，基本上都是根據你分析的日誌量來收錢。環境越大、流量越高，費用就越多。
所以，在設計 VPC 架構時，不只是考慮技術上可不可行，也要把成本算進去。有時候，一個「最安全」的架構可能也是「最貴」的架構，必須在安全性和預算之間找到一個平衡點。這也是為什麼很多小公司或新創團隊一開始會用比較簡單的架構，等規模變大了再慢慢重構成更複雜、更安全的模式。
最後，你該怎麼想？
繞了一大圈，其實 VPC 的核心觀念就是「隔離」和「控制」。
你得知道你的資產（EC2、RDS）放在哪裡，誰（哪個 IP、哪個 Security Group）可以跟它講話，它又可以跟誰講話。然後，你得有方法去監控這些對話（VPC Flow Logs、DNS Logs），並且在出現異常時能馬上發現（GuardDuty）。
AWS 給了你非常多、非常細的工具，這既是優點也是缺點。優點是你可以打造出非常安全的環境，缺點是只要有一個環節沒設定好，可能就前功盡棄。這也是為什麼雲端安全工程師這個職位越來越重要的原因吧。
嗯，大概就是這樣。從一個 TryHackMe 的練習，延伸出這麼多東西，雲端的世界真的...很深。不知道你吸收得怎麼樣？
我想問問大家，看完這些，你覺得在日常維運中，Security Groups 和 NACLs 哪個更容易因為人為疏失而被設錯？在下面留言分享你的看法吧！
