AWS VPC 網路安全 — SCS-C02 考試筆記（Network Firewall、Transit Gateway、端點、Flow Logs）

Q: Q2：何時應使用 AWS Network Firewall，何時應使用 Gateway Load Balancer 搭配第三方設備？

當需求可以由 Suricata 風格有狀態規則、網域名稱過濾與基本 TLS 檢查滿足時，使用 AWS Network Firewall ——典型的企業出站流量過濾、惡意軟體 C2 封鎖，以及透過 DNS 或 HTTPS 到已知惡意網域的資料外洩防護。這個選項完全受管、水平擴展，並與 Firewall Manager 整合實現全組織部署。當你需要 Network Firewall 不具備的廠商特定功能時，使用 Gateway Load Balancer + 第三方設備 （Palo Alto、Fortinet、Check Point、Aviatrix）：進階沙箱、使用自訂協定解碼器的應用感知政策、深度 mTLS 處理，或要求特定商業技術棧的嚴格法規要求。在 SCS-C02 中，除非情境明確要求第三方特定功能，否則預設選 Network Firewall。

Q: Q3：為什麼資料邊界需要同時有 VPC endpoint policy 和 S3 儲存桶政策？

因為每一層防護不同的攻擊向量。 VPC endpoint policy 限制網路路徑透過端點可到達的儲存桶——防禦的是 VPC 內遭入侵的情境，攻擊者持有有效的 AWS 憑證，但端點拒絕呼叫組織外部的儲存桶。 S3 儲存桶政策 搭配 aws:SourceVpce 條件限制哪些端點可以存取此儲存桶——防禦的是來自公開網際網路或未授權 VPC 的存取。兩者共同形成雙向封閉的邊界：無法外洩到組織外部儲存桶，也無法從外部帳號向你的儲存桶灌入資料。再加上組織層級的 SCP 拒絕 aws:ResourceAccount 不在組織帳號清單中的任何 S3 動作，攻擊者的路徑就在 IAM 授權層也被關閉了。SCS-C02 期待這三層都到位。

Q: Q5：Direct Connect 上的 Public VIF、Private VIF 與 Transit VIF 有什麼差異？

Public VIF 透過私有交叉連接承載目的地為 AWS 公有服務 IP（S3、DynamoDB、公有 IP 負載平衡器）的流量，繞過網際網路——在法規禁止即使到 AWS 自有位址也不得走網際網路傳輸時很有用。 Private VIF 透過 Virtual Private Gateway 承載到單一 VPC 的流量，用於單一 Region 單一 VPC 的混合部署。 Transit VIF 承載到 Direct Connect Gateway 的流量，再分散到多個 AWS Region 的一個或多個 Transit Gateway，實現一條 VIF 支援多 VPC 多 Region 的混合連接。SCS-C02 期待你認識 Transit VIF 是任何現代多 Region 多帳號架構的標準模式；Private VIF 是舊版單 Region 方案；Public VIF 是小眾用途。

Q: Q6：如何架構一個需要呼叫 KMS、Secrets Manager 以及外部 HTTPS API 的 VPC 附掛 Lambda 函數？

將函數放在私有子網路中。為函數呼叫的所有 AWS 服務新增 interface VPC endpoint （KMS、Secrets Manager、STS，以及任何其他 AWS 服務）——這些透過 PrivateLink 路由，不需要 NAT，大規模下成本更低，且在 CloudTrail 中可稽核。 只為外部 HTTPS API 呼叫 在公有子網路新增 NAT gateway （從函數的私有子網路路由），並透過目的地的 Security Group 嚴格限縮 NAT 的目的地範圍——或者更好的做法是，使用帶有網域名稱允許名單的 Network Firewall 作為出站過濾器，NAT gateway 在其下游。對於資料邊界，在 interface endpoint 上附掛 endpoint policy，將主體限制為函數角色，將資源限制為預期的 secret 和金鑰。這個模式是 SCS-C02 對「安全 VPC 附掛 Lambda 搭配選擇性網際網路出站」的最佳實務標準。

Q: Q7：應選擇哪個 VPC Flow Logs 版本，而 ALL 擷取了哪些 ACCEPT 和 REJECT 個別未能擷取的流量？

選擇 v5 ——它是欄位最豐富的格式（VPC ID、子網路 ID、執行個體 ID、流量路徑、ECS task ARN、子位置類型），且每攝入 GB 的成本與舊版格式相同。 ACCEPT 只擷取允許的流量； REJECT 只擷取被封鎖的流量； ALL 兩者皆擷取。安全調查和 SIEM 攝入選 ALL ——被拒絕的流量（REJECT）是偵測偵察掃描、設定錯誤用戶端和政策違規的關鍵訊號，而允許的流量（ACCEPT）則是行為基準線和橫向移動偵測所需的。只有在儲存成本是主要限制，且你接受喪失基準線的前提下，才單獨選 REJECT 。SCS-C02 的預設期待：v5 + ALL + S3 目的地 + Athena 分區。

Q: Q9：Firewall Manager 和 CloudFormation StackSets 在全組織網路安全政策上有何差異？

兩者都能將資源部署到多個帳號。 CloudFormation StackSets 是通用的基礎設施即程式碼；你撰寫範本，推送到 N 個帳號，受管堆疊的漂移偵測在有人變更資源時發出警報。 Firewall Manager 是專為安全政策打造的：它理解 WAF、Shield、Network Firewall 和 Security Group 的語義，支援偵測到違規時自動修復（StackSets 能偵測漂移但無法自動修復），與 AWS Config 整合進行資源探索，與 Security Hub 發現結合，並與 AWS Organizations 政策層級緊密連結。SCS-C02 對任何「全組織強制執行安全基準」的題目都期待 Firewall Manager；只有當 Firewall Manager 不支援該資源類型時（例如自訂 VPC 設定），StackSets 才是次佳答案。

Q: Q10：加密地端資料中心與私有 VPC 子網路中工作負載之間流量的正確方式是什麼？

依需求嚴格程度分層提供多個選項。（a） Site-to-Site VPN 搭配 IPsec——在 IPsec 層加密，足以滿足大多數法規要求，設定成本低，兩條隧道提供高可用性。（b） 僅使用 Direct Connect ——私有但未加密；搭配 MACsec 在交叉連接上進行第二層加密（線速、低延遲、在專用連結上提供強大機密性）。（c） Direct Connect 加上在其上疊加 Site-to-Site VPN（VPN over DX） ——透過 Direct Connect 進行端對端 IPsec 加密，同時滿足「私有傳輸」和「IPsec 加密」的要求；這是最嚴格受監管產業的標準答案。（d） 應用層 TLS 端對端——與以上所有選項正交；工作負載本身終止 TLS，即使 AWS 側遭入侵也無法解密。在 SCS-C02 中，當情境提到「受監管」、「合規」、「FedRAMP」或「即使在私有連結上也必須加密所有傳輸中資料」時，（c）是最高得分的答案。對於（d），注意「端對端加密」或「AWS 無法解密」的措辭。

SCS-C02 的 AWS 網路安全考題，和 SAA-C03 的出題邏輯截然不同。架構師考試問的是「資料庫要放哪個子網路？」；資安專業考試問的是：「安全團隊必須檢查所有離開 inspection VPC 的 TCP 流量、解密 TLS 以偵測資料外洩模式、把每一筆被丟棄的封包記錄到防竄改的儲存空間，並在不讓個別工作負載擁有者關閉的前提下，把同一套基準規則套用到整個 AWS Organization 的每個帳號。」這是一個需要整合 Security Group、Network ACL、AWS Network Firewall、Transit Gateway appliance mode、帶嚴格政策的 VPC endpoint、Traffic Mirroring session、VPC Flow Logs v5 欄位、Site-to-Site VPN 搭配 BGP、Direct Connect 搭配 MACsec、Lambda VPC 附掛行為，以及 AWS Firewall Manager 政策的分層設計問題——而 SCS-C02 經常在一道五行情境題中同時測驗上述所有知識點。

本主題涵蓋 Domain 3（基礎設施安全，佔考試 20%）Task Statement 3.2 的全部內容。SCS-C02 Exam Guide v1.0 逐字列出以下知識重點：「VPC 安全機制（Security Group、Network ACL、AWS Network Firewall）」、「VPC 間連接（AWS Transit Gateway、VPC endpoint）」、「安全遙測來源（Traffic Mirroring、VPC Flow Logs）」、「VPN 技術、術語與使用方式」，以及「地端連接選項（AWS VPN、AWS Direct Connect）」。技能重點則要求考生設計網路分段、設計允許或阻擋流量的控制措施、讓資料不經過公開網際網路、選擇正確的遙測來源，並透過 AWS Firewall Manager 集中管理整個組織。本筆記從最細粒度的控制（Security Group 規則）一路到最集中的控制（透過 AWS Organizations 強制執行的 Firewall Manager 政策），完整走過整個技術棧。

為何網路安全是 SCS-C02 Domain 3 的核心

Domain 3 佔 SCS-C02 的 20%——比其他任何 Domain 都高——而 Task Statement 3.2 是考試指南中覆蓋範圍最廣的單一 task，在知識與技能清單中點名了 AWS Network Firewall、Transit Gateway、VPC endpoint、Traffic Mirroring、VPC Flow Logs、AWS VPN、AWS Direct Connect、MACsec 以及 AWS Firewall Manager。預計在這個範圍內會出現六到十道情境式考題，幾乎每一道都是情境描述題而非單純記憶題。典型的題目描述一個四帳號組織搭配 inspection VPC，問哪個 Transit Gateway 功能可確保流量在回程路徑上也被檢查，並提供四個表面上看起來很相近的選項。

網路安全也是 Domain 3 其他 task 的底層依賴。邊緣防護（3.1）終止在 ALB，而 ALB 的 Security Group 管控了進入 VPC 層的東西向可達性；運算強化（3.3）依賴主機型防火牆、執行個體 metadata 服務與 IAM instance profile，但攻擊者可能利用的網路可達性由 3.2 的控制措施決定；網路安全故障排除（3.4）本質上就是相同的架構元件在失效狀態下的表現。因此，徹底掌握 3.2 是整個基礎設施安全 Domain 中投資報酬率最高的學習活動。

本主題貫穿的核心框架是網路層的縱深防禦。SCS-C02 很少接受「用 Security Group 就好」這種單一答案——正確答案通常結合兩到三個層次：SG 加 NACL、NACL 加 Network Firewall、Network Firewall 加 VPC endpoint policy、VPN 加 Direct Connect 搭配 MACsec。如果考生腦海中只有單一防禦邊界，就會在這類題目上敗給只提到最常見控制措施的干擾選項。SCS-C02 獎勵的心智模型是：分層控制 搭配 集中治理 與 豐富遙測——這正是 AWS Security Reference Architecture inspection VPC 模式的設計精神。

白話文解釋 Network Security in AWS VPCs

VPC 網路安全由五個獨立架構元件（SG、NACL、Network Firewall、VPC endpoint policy、Firewall Manager）加上傳輸骨幹（Transit Gateway（TGW）、VPN、Direct Connect）再加上遙測（Flow Logs、Traffic Mirroring）堆疊而成。以下三個類比協助你掌握各個活動部件。

類比一：社區大樓的分層門禁管制

把每個 VPC 想像成一棟多住戶社區大樓。Security Group 是每扇辦公室門上的智慧感應門鎖——有狀態、僅允許，且個人化：每位住戶（執行個體）持有一張門禁卡（Security Group 成員資格），上面列著可以開哪些門。一旦門禁卡開鎖進入，同一住戶離開時不需要再刷卡——這就是有狀態回程流量的特性。Network ACL 是大樓一樓警衛室裡持著紙本登記簿的保全——無狀態、可允許也可拒絕，且不分對象。保全對每一次進出都獨立審查，依照登記簿上的編號規則依序比對；進門的通行證不等於出門的放行許可。AWS Network Firewall 是大廳中央的安全檢查站，配有金屬探測門、X 光輸送帶，以及受過 Suricata 訓練、能夠嗅出封包內容的警犬——它能深入應用層協定做檢查、持有正確金鑰時可拆封密件（TLS 檢查），並對每一筆告警留下記錄。Transit Gateway appliance mode 是大型社區聯棟管理規定：所有在棟與棟之間走動的訪客必須來回都經過大廳安全檢查站，讓警犬絕對不會漏掉回程的行人。VPC endpoint 是各樓層之間的氣壓管傳輸系統，讓你的辦公室直接連接到 AWS 服務的「補給庫房」，完全不必走出大樓到外頭的街道（公開網際網路）。Firewall Manager 是物業管理公司，在公司名下每一棟大樓（帳號）統一執行同樣的大廳安全檢查站與門禁卡標準，並且不允許任何個別辦公室自行更換門鎖規格。

類比二：貨櫃碼頭的安檢流程

把一個 VPC 想像成一座貨櫃碼頭，裡面有多個泊位（子網路）。貨櫃（封包）抵港、卸貨、再轉送到各個倉庫（執行個體）。Security Group 是每座倉庫裝卸碼頭的門衛，只為核准名單上的卡車開門——門衛記得哪些卡車被放行進來，同一批卡車離場時不需要重新核查。NACL 是碼頭外圍的海關稽查員，對每一個貨櫃的進出獨立蓋章，按照編號關稅表（規則編號評估順序）逐條比對，並對違禁貨物拒絕放行。AWS Network Firewall 是碼頭中央的專業貨物 X 光機與爆裂物偵測設施——凡被標記的貨櫃都要開箱檢查（Suricata 有狀態規則），高風險貨物必須解密再重新封裝（TLS 檢查），讓稽查員看清楚裡面裝的是什麼。Traffic Mirroring 是安全監控的錄影拷貝，複製一份送到獨立的分析室進行事後取證，完全不干擾碼頭正常運作。VPC Flow Logs 是碼頭的進出艙單記錄，記載每一個貨櫃的進港、出港、試圖進入卻被拒絕的案例，以及拒絕原因。Site-to-Site VPN 是從碼頭到工廠之間、行駛於公路上的專屬裝甲押運車隊；Direct Connect 搭配 MACsec 則是擁有鋼製密封軌道（第二層加密）、在兩地之間直接連通的專用鐵路。

類比三：醫院的分區門禁與取證制度

把 VPC 的網路控制想像成一間醫院的進出管制體系。Security Group 是醫師與護理師的識別證，允許持有者進入特定病房和接觸特定病患（資源對資源存取）；識別證在每道門都會被核查，系統記得員工進入的時間並允許離場。Network ACL 是醫院外圍警衛室的拒絕名單——名單上的人一律拒絕，其他人通行；這道關卡是靜態且無狀態的。AWS Network Firewall 是感染管制檢查站，對每位訪客採樣比對已知病原體（Suricata 特徵碼），必要時要求抗體檢測（TLS 檢查），並對符合已知惡意軟體特徵的訪客實施隔離。Transit Gateway appliance mode 是醫院的規定：病患在各棟病房間移送時，去程與回程都必須通過同一個感染管制檢查站——若無此規定，回程路徑可能繞過檢查。Traffic Mirroring 是病歷的副本，送交外部實驗室進行取證分析，不干擾正常醫療作業。VPC Flow Logs 是掛號與出院登記本，記錄哪些人進入、哪些人離院，以及哪些進入申請被拒絕。Firewall Manager 是醫療集團的中央感染管制辦公室，在整個體系中所有醫院統一強制執行相同的感染管制篩查流程。

在 SCS-C02 考試中，當一道題目同時混用 Security Group、NACL 與 Network Firewall 時，社區大樓類比最為實用——分層門鎖、保全警衛與大廳安全檢查站的對應關係非常清晰。對於 Transit Gateway appliance mode 與 inspection VPC，聯棟社區規定這個子類比是最高投報率的心智模型。對於 TLS 檢查與 Suricata 規則群組，X 光機與爆裂物偵測警犬的形象讓深層封包的語義變得直觀。參考：https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html

Security Group vs Network ACL：有狀態 vs 無狀態

Security Group 與 Network ACL 是 VPC 兩個最基礎的網路控制機制，也是 SCS-C02 測驗最頻繁的組合。兩者不可互換、不是備援關係，且以不同的方式失效。

Security Group——有狀態、僅允許、附掛在 ENI

Security Group 附掛在 elastic network interface（ENI）上，而非子網路。它是有狀態的：當一條入站規則允許某個連線，回程流量就會在短暫連接埠範圍上自動放行，不需要額外的出站規則。Security Group 只支援允許規則——沒有拒絕規則。VPC 預設 Security Group 允許來自自身（相同 Security Group 來源）的所有入站流量，以及所有目的地的出站流量。自訂 Security Group 預設沒有入站規則，出站則是「允許所有流量到 0.0.0.0/0」。

每個 Security Group 預設最多可有 60 條入站與 60 條出站規則（可透過 Service Quotas 提升到合計 1000 條），每個 ENI 最多可附掛 5 個 Security Group（可提升至 16 個）。來源與目的地可以是 CIDR、另一個 Security Group、前綴清單或受管理的前綴清單。以另一個 Security Group 作為來源，是 SCS-C02 認可的東西向微分段標準模式：資料庫 SG 允許來自應用層 SG 的 5432 連接埠，而非來自某個 CIDR。

Network ACL——無狀態、允許與拒絕、附掛在子網路

Network ACL 附掛在子網路上，套用到該子網路內所有的 ENI。它是無狀態的：入站和出站規則獨立評估，你必須明確允許回程路徑上的短暫連接埠範圍（1024–65535）。NACL 同時支援允許與拒絕規則，依規則編號順序、從最小編號開始評估。預設 NACL 允許所有入站和出站；自訂 NACL 預設拒絕所有流量。

當你需要表達 Security Group 無法實現的明確拒絕時，NACL 最為實用——例如在子網路邊界封鎖特定來源 CIDR（已知攻擊者、高頻掃描器、受制裁國家），讓工作負載擁有者無法透過 Security Group 規則意外重新開放。

SCS-C02 上最常被測驗的錯誤，就是忘記 NACL 是無狀態的。考生新增了一條允許 0.0.0.0/0 連接埠 443 入站的 NACL 規則，並以為回應封包可以出去——但不行，因為回應封包從高短暫連接埠（1024–65535）出站，而出站 NACL 必須明確允許這個範圍。Linux 核心預設使用 32768–60999；Windows 使用 49152–65535；AWS NLB 使用 1024–65535。安全的預設出站 NACL 允許規則是 1024–65535。如果題目描述的是正常運作的 SG 設定、正確附掛的 NACL 入站規則，但連線仍然失敗——答案就是 NACL 上缺少短暫連接埠出站允許規則。參考：https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html

何時疊用 SG + NACL

SCS-C02 期待的是分層使用，而非二擇一。Security Group 用於具有有狀態語義的資源對資源允許規則（最自然表達應用程式架構的地方）。NACL 用於子網路範圍的明確拒絕——已知惡意 CIDR、受制裁區域、永遠不應觸及敏感子網路的內部網段。當工作負載擁有者不小心過度放開 Security Group 時，NACL 提供縱深防禦；Security Group 則在不強迫操作者思考短暫連接埠的情況下，提供彈性與有狀態的特性。

Security Group：有狀態、僅允許、ENI 範圍的防火牆。
Network ACL：無狀態、允許或拒絕、子網路範圍、依規則編號排序的防火牆。
有狀態（Stateful）：已允許連線的回程流量自動放行。
無狀態（Stateless）：每個方向的封包獨立評估。
短暫連接埠範圍：1024–65535（RFC 範圍），來源連接埠由用戶端核心選擇。
前綴清單（Prefix list）：可依名稱參照的受管 CIDR 集合；AWS 受管前綴清單涵蓋 S3、DynamoDB、CloudFront 與 EC2 instance connect。
預設拒絕（Default deny）：NACL 與 Network Firewall 有狀態規則預設「丟棄所有未明確允許的流量」。
參考：https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html

AWS Network Firewall：相容 Suricata 的有狀態深層檢查

AWS Network Firewall 是一項受管網路防火牆服務，在你的 VPC 內部執行，並檢查所有南北向，以及（透過適當路由）東西向的流量，涵蓋第三層到第七層。它是 AWS 受管、水平擴展版的 Palo Alto、Fortinet 或 Check Point 設備；在 SCS-C02 中，凡是情境題提到 深層封包檢查、網域名稱過濾、Suricata 風格的入侵偵測，或 VPC 內部的 TLS 檢查，答案幾乎都是它。

架構——防火牆、防火牆政策、規則群組

三個元件以巢狀方式組合。防火牆（Firewall） 是部署的實體——每個 VPC 一個防火牆，在你要保護的每個可用區各有一個防火牆端點 ENI。防火牆政策（Firewall Policy） 是可重複使用的無狀態與有狀態規則群組捆包，加上預設動作。規則群組（Rule Group） 是撰寫的單位——分為無狀態（五元組比對，像 ACL 一樣依優先順序評估）或有狀態（相容 Suricata 的特徵碼，帶有流量追蹤）。無狀態群組先評估，有狀態群組後評估。

無狀態規則群組——五元組比對

無狀態規則比對來源／目的地 IP 與連接埠及協定，依優先順序執行動作：pass、drop、轉交有狀態，或自訂動作。當決策純粹基於五元組時使用無狀態規則——封鎖所有流向已知 C2 IP 的流量、丟棄來自可偽造來源的 UDP、快速通行 TCP/443 以跳過已知信任目的地的有狀態檢查。

有狀態規則群組——相容 Suricata

有狀態規則追蹤連線狀態，可比對網域名稱（HTTPS 的 SNI、HTTP 的 Host header、DNS 查詢名稱）、Suricata 特徵碼（開源 IDS 規則格式），或帶有流量追蹤的五元組。Suricata 語法讓商業威脅情報訂閱和開源規則集（ET Open、ET Pro、Talos）幾乎無需轉換即可匯入 Network Firewall。網域名稱過濾是 SCS-C02 測驗最頻繁的功能——「只允許 *.amazonaws.com、*.example-corp.com 與 *.windowsupdate.com 的出站 HTTPS，其餘全部丟棄」是一個有狀態規則群組就能解決的答案。

TLS 檢查

未啟用 TLS 檢查時，Network Firewall 在加密流量上只能看到 SNI，無法檢查封包內容。TLS 檢查在防火牆處終止 TLS session，解密後套用有狀態規則，再重新加密後轉送到目的地。需求：一張由 ACM 核發或匯入的伺服器憑證，以及防火牆信任的憑證授權單位（CA）捆包（用於出站流量）。用戶端必須信任防火牆的內部 CA。TLS 檢查目前支援 TLS 1.2 與 1.3，並有特定的密碼套件限制；部分流量（mTLS、某些憑證鎖定應用程式）無法被檢查，須透過 SNI 允許名單放行。

在防火牆解密 TLS 在技術上可行，但在營運上影響深遠。以下情況會出問題：憑證鎖定的行動應用程式、使用 mTLS 驗證用戶端的 API、使用 QUIC/HTTP3 的應用程式（UDP，撰寫本文時 AWS Network Firewall TLS 檢查尚不支援），以及目的地要求特定用戶端憑證的任何流量。從法律角度看，解密員工或第三方流量涉及資料保護法規（GDPR、HIPAA）——啟用前請取得法務簽核，並在可接受使用政策中記錄檢查行為。SCS-C02 提到「解密並檢查」時，要求你同時認識這項能力與其限制。參考：https://docs.aws.amazon.com/network-firewall/latest/developerguide/tls-inspection.html

部署在 inspection VPC 中

SCS-C02 的標準部署是 AWS Security Reference Architecture 參考的專用 inspection VPC。所有 spoke VPC 透過 Transit Gateway（TGW）路由到 inspection VPC，inspection VPC 在每個可用區各有 Network Firewall 端點。inspection VPC 沒有任何運算工作負載——只有防火牆，以及供出站到網際網路（若允許出站）的 NAT gateway。這樣設計讓整個架構只有一個流量瓶頸點、一個規則政策作者、一個日誌目的地，以及一個統一的限速決策。

每個 VPC 一個防火牆，每個受保護的可用區各有一個防火牆端點 ENI。
無狀態先評估，有狀態後評估——政策撰寫時順序很重要。
相容 Suricata 的有狀態規則——可直接匯入商業訂閱（ET Pro、Talos）。
網域名稱清單過濾 HTTP Host 與 HTTPS SNI，不需啟用 TLS 檢查。
TLS 檢查需要 ACM 憑證 + CA 捆包；僅支援 TLS 1.2/1.3。
日誌：告警日誌（符合有狀態規則的流量）與流量日誌（所有流量），可送往 S3、CloudWatch Logs 或 Kinesis Firehose。
有狀態預設動作：drop established、drop strict（丟棄所有不符規則的流量）或 alert。
不支援 mTLS 或 QUIC 檢查（撰寫本文時）——透過 SNI 允許名單放行。
參考：https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-rule-groups.html

Transit Gateway 安全模式與 Appliance Mode

AWS Transit Gateway（TGW）是 VPC 對 VPC、VPC 對地端，以及 VPC 對 VPN 連接的中樞輻射式傳輸骨幹。SCS-C02 可測驗的安全模式包括：inspection VPC 路由、appliance mode 對稱路徑、路由表隔離控制爆炸半徑，以及透過 AWS RAM 跨帳號共享資源。

Inspection VPC 模式

每個 spoke VPC 的預設路由（0.0.0.0/0）指向 TGW。TGW 路由表將 spoke 流量透過 inspection VPC attachment 轉送，再路由到其他 spoke 或網際網路。inspection VPC 中的 Network Firewall 檢查流量。來自目的地 spoke 的回程流量也透過 TGW 路由回 inspection VPC。若未啟用 appliance mode，非對稱路由可能導致 TGW 將請求送往某個可用區的 Network Firewall，而回應卻被送往另一個可用區——由於 Network Firewall 是有狀態的，它從未見過請求，因此會丟棄回應。

Appliance Mode——必考功能

在 inspection VPC 的 TGW attachment 上啟用 appliance mode 後，TGW 會強制讓同一條流的兩個方向都走相同可用區的相同 attachment ENI。這是 SCS-C02 對「多可用區情境下 inspection VPC 丟棄回程流量」的標準答案。Appliance mode 是每個 attachment 的個別開關，在建立 attachment 時設定，或透過 modify-transit-gateway-vpc-attachment API 修改。若未啟用，有狀態防火牆在跨可用區的 inspection VPC 中將無法正常運作。

路由表隔離

TGW 支援多個路由表，每個路由表有自己的關聯（association）與傳播（propagation）。標準隔離模式：生產 VPC 關聯到只傳播生產和共享服務路由的「prod」TGW 路由表；非生產 VPC 關聯到另一個「non-prod」路由表；inspection VPC 在第三個路由表中，可看到所有路由。這樣即使生產和非生產 VPC 都附掛在同一個 TGW 上，非生產 VPC 也無法直接路由到生產 VPC。

SCS-C02 常見干擾選項：題目描述 inspection 流量在單一可用區內運作正常，但跨可用區流量卻失敗。考生急著往 Security Group、NACL 或 Network Firewall 規則找原因——但真正的根本原因是 TGW attachment 未啟用 appliance mode。AWS 在 inspection VPC 參考架構中明確標注了這個警告。記住症狀與修復的對應關係：「有狀態防火牆，跨可用區非對稱丟包」→ 啟用 TGW attachment appliance mode。參考：https://docs.aws.amazon.com/vpc/latest/tgw/tgw-appliance-scenario.html

跨帳號 TGW 搭配 AWS RAM

中央網路帳號擁有 Transit Gateway。AWS Resource Access Manager（RAM） 將 TGW ID 分享給成員帳號，讓這些帳號可以附掛自己的 VPC，無需每個帳號重新建立連接。中央網路團隊控制 TGW 路由表；成員帳號控制自己的 VPC 路由表。這是 AWS Security Reference Architecture 的標準佈局，在 Specialty 考試中大量測驗。

VPC Endpoint：Gateway vs Interface（PrivateLink）

VPC endpoint 讓 VPC 與支援的 AWS 服務之間的流量留在 AWS 網路上，不經過公開網際網路。共有兩種類型，不可互換。

Gateway endpoint——僅支援 S3 與 DynamoDB

Gateway endpoint 是新增到 VPC 路由表的路由目標。只有 Amazon S3 與 Amazon DynamoDB 可透過 gateway endpoint 存取。這種端點免費、以區域為範圍，且沒有 ENI——它是一筆路由表前綴清單條目，攔截目的地為服務公開 IP 範圍的流量，透過 AWS 骨幹路由。Gateway endpoint 支援端點政策，用於限制可透過端點存取的儲存桶、資料表或主體。

Interface endpoint——PrivateLink 涵蓋其他所有服務

Interface endpoint 是在你的子網路中建立一個或多個 ENI，代理對 AWS 服務或第三方 SaaS 的請求。由 AWS PrivateLink 提供支援，interface endpoint 涵蓋數百項 AWS 服務（KMS、Secrets Manager、STS、Systems Manager、ECR、SNS、SQS 等），以及客戶和合作夥伴發布的服務。每個 ENI 在你的子網路中擁有一個私有 IP；用戶端指向端點的 DNS 名稱（解析為 ENI IP），或在端點上啟用 Private DNS，讓 VPC 內的用戶端覆蓋服務的公開 DNS。

Interface endpoint 按每個可用區每小時計費，加上每 GB 處理費。它們在 ENI 上支援 Security Group（控制哪些用戶端可以抵達端點）與端點政策（控制這些用戶端可以執行哪些動作）。

端點政策——資料邊界的槓桿

VPC endpoint policy 是附掛在端點上的 IAM 政策，限制哪些主體、動作與資源可以透過端點流通。SCS-C02 中最強大的模式是資料邊界：S3 gateway endpoint 政策只允許存取組織自有帳號清單中的儲存桶（使用 aws:PrincipalOrgID 與 s3:ResourceAccount 條件），即使遭洩漏的憑證在 VPC 內被使用，也無法將資料外洩到攻擊者控制的儲存桶。

SCS-C02 要求你認識三層資料邊界。（a）VPC endpoint policy 限制網路路徑可到達的儲存桶。（b）S3 儲存桶政策搭配 aws:SourceVpce 條件，要求存取只能來自已知端點。（c）Service Control Policy（SCP） 完全拒絕來自組織外部的存取。三層合力防止資料外洩到組織外部儲存桶，以及防止從外部帳號向你的儲存桶灌入資料——形成雙向封閉的邊界。「阻止對組織外部儲存桶的任何 S3 GetObject」這類題目需要這三層，而非只有 endpoint policy。參考：https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html

Interface endpoint 與 Security Group

由於 interface endpoint 有 ENI，它們也有 Security Group。端點的 Security Group 必須允許來自用戶端子網路的入站流量（通常是 TCP 443）。建立 interface endpoint 時的預設行為是套用 VPC 預設 Security Group，這在生產環境通常過於寬鬆——請換成精確範圍的 SG。

Traffic Mirroring：取證與深層封包檢查

VPC Traffic Mirroring 將網路封包從來源 ENI 複製到目標，進行帶外分析。這是 SCS-C02 對「在不中斷生產環境的前提下，擷取完整封包內容以供取證審查」的標準答案。

組成元件——來源、目標、過濾器、Session

鏡像來源（Mirror source） 是 Nitro 架構 EC2 執行個體上的 ENI（較舊的執行個體類型不支援）。鏡像目標（Mirror target） 是 Network Load Balancer、Gateway Load Balancer 或另一個 ENI——通常指向安全分析設備、Suricata IDS 叢集或 Zeek 感測器。鏡像過濾器（Mirror filter） 定義要複製哪些流量（五元組比對加上規則編號排序）。鏡像 Session 將來源、目標與過濾器綁定在一起，Session 編號決定當一個 ENI 符合多個 Session 時的優先順序。

Traffic Mirroring 擷取完整封包內容（從第二層開始），以 VLAN 封裝，支援 VPC Flow Logs 無法提供的 payload 檢查。缺點是成本：每個被鏡像的位元組都被複製，高流量執行個體可能讓目標 NLB 的頻寬趨於飽和。

使用情境

事件取證擷取——在懷疑遭入侵的執行個體上啟動鏡像，送往取證 VPC 進行離線分析。
威脅獵捕——將鏡像流量送入 Suricata IDS，進行超越 GuardDuty 的特徵碼與行為偵測。
法規封包留存——部分受監管產業要求保留 N 天的完整封包；Traffic Mirroring 搭配 S3（透過 Kinesis Firehose 從自訂收集器拉取）是常見模式。
深層效能除錯——擷取並重播 TCP 流量，調查重傳與協定層問題。

SCS-C02 常見干擾：Traffic Mirroring 與 VPC Flow Logs 被當成替代方案。實際上它們是互補的：Flow Logs 是彙總的五元組記錄（來源 IP、目的地 IP、連接埠、協定、動作、位元組、封包數）——成本低、常態開啟，非常適合 GuardDuty 與廣泛遙測；Traffic Mirroring 是完整封包擷取——成本高、目標明確，非常適合取證調查。「需要檢查 HTTP 請求本體中是否含有已知 XSS payload 模式」的答案是 Traffic Mirroring，而非 Flow Logs。「偵測資料庫子網路中大量異常出站 TCP 22 連線」的答案是 Flow Logs。參考：https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html

VPC Flow Logs：網路安全遙測

VPC Flow Logs 擷取流過 ENI、子網路或整個 VPC 的 IP 流量 metadata。它是 AWS 最基礎的網路安全遙測來源，也是 Amazon GuardDuty、Amazon Detective 以及大多數第三方 SIEM 的資料輸入。

擷取類型與目的地

Flow log 可以擷取 ACCEPT 記錄（允許的流量）、REJECT 記錄（被 SG 或 NACL 丟棄的流量）或 ALL（兩者皆有）。目的地：CloudWatch Logs（近即時查詢，搭配 Logs Insights）、S3（低成本長期儲存，搭配 Athena 查詢），或 Kinesis Data Firehose（串流至 SIEM 或資料湖）。

v2 vs v3 vs v4 vs v5 記錄格式

Flow Logs 支援多種記錄格式版本，每版新增更多欄位：

v2（預設）——原始 14 個欄位：version、account-id、interface-id、srcaddr、dstaddr、srcport、dstport、protocol、packets、bytes、start、end、action、log-status。
v3——新增 VPC ID、子網路 ID、執行個體 ID、TCP flags、流量類型、封包來源/目的地。
v4——新增 AWS 服務、流量方向、流量路徑。
v5——新增 6 個欄位，包括 ECS task ARN、子位置類型、子位置 ID——容器與 Outposts 工作負載最豐富的格式。

需要為 SIEM 攝入或容器感知分析提供完整功能集時，選擇 v5。無論格式為何，成本相同——Flow Logs 依每攝入 GB 計費。

Flow Logs 與拒絕流量

當 Security Group 或 NACL 丟棄封包時，會記錄 REJECT 記錄。NACL 丟棄和 SG 丟棄都會產生 REJECT 項目，但 Flow Logs 不區分是哪個控制措施執行丟棄——需要推斷（若來源被 SG 允許但被丟棄，就一定是 NACL）。對於 Network Firewall 的丟棄，你需要額外使用 Network Firewall 的流量日誌和告警日誌；Network Firewall 的丟棄不會以 VPC Flow Log REJECT 的形式出現。

SCS-C02 干擾選項：考生以為 Flow Logs 是完整的。但它們並非如此。Flow Logs 明確排除：送往或來自 Amazon DNS 伺服器（169.254.169.253）的流量、Windows 授權啟用流量、執行個體 metadata 服務請求（169.254.169.254，包含 IMDSv2）、Amazon Time Sync（169.254.169.123）、DHCP 流量、送往 VPC router 保留位址的流量，以及使用 Gateway Load Balancer 時端點間的流量。這些情況要達到取證完整性，需要 Traffic Mirroring 或主機端日誌。參考：https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html

Flow Logs 在安全帳號集中化模式中的運用

AWS Security Reference Architecture 模式：每個成員帳號中所有 VPC 的 Flow Logs 都寫入 Log Archive 帳號中的集中式 S3 儲存桶，以帳號/區域/日期分區。該儲存桶不可竄改（Object Lock + 拒絕刪除的儲存桶政策），可從 Security Tooling 帳號透過 Athena 查詢。當題目問到「在整個組織內集中化網路遙測」時，這就是 SCS-C02 期待的黃金標準答案。

Site-to-Site VPN：IPsec、BGP 與加速 VPN

AWS Site-to-Site VPN 在 AWS Virtual Private Gateway（VGW）或 Transit Gateway 與地端客戶閘道設備之間建立 IPsec 隧道。它是成本低、建置快速的混合式連接選項，也是情境題中不需要 Direct Connect 時的 SCS-C02 標準答案。

IPsec 隧道設計

每條 Site-to-Site VPN 連接由兩條 IPsec 隧道組成，分別終止在不同實體基礎設施上的不同 AWS 端點，以提供高可用性。使用 BGP 時兩條隧道預設都是主動的（active/active 路由）；若使用靜態路由，則為一主一備的 active/passive 模式。客戶閘道必須設定為使用兩條隧道——只使用其中一條會使可用性減半，且一旦 AWS 對主動端點執行維護，立即造成中斷。

預設加密：AES-256、SHA-2 完整性驗證、DH group 14 以上、IKEv2。SCS-C02 期待你認識這些現代預設值；在描述全新部署的題目中，使用 SHA-1 的舊版 IKEv1 應被標記為不合規。

BGP 路由

VPN 隧道上的 Border Gateway Protocol（BGP） 路由是建議的模式。BGP 啟用動態路由傳播、隧道間自動故障切換，以及在不重新建立 VPC 路由表路由的情況下新增或移除地端 CIDR。靜態路由是客戶閘道不支援 BGP 時的備選方案，在 SCS-C02 中只有明確說明時才可接受。

加速 Site-to-Site VPN

Accelerated VPN 讓 IPsec 隧道透過 AWS Global Accelerator 邊緣網路路由，降低遠端地端站點的延遲和抖動。在建立 VPN 連接時以個別連接為單位啟用，適合延遲敏感工作負載（即時遊戲、VoIP、金融交易）透過 Site-to-Site VPN 傳輸的情境。有限制條件：加速 VPN 與 VGW 不相容（僅支援 Transit Gateway），且需要額外的每小時費用。

每條 VPN 連接兩條 IPsec 隧道，終止在不同的 AWS 端點上。
建議使用 BGP，靜態路由作為不支援 BGP 的客戶閘道備選方案。
AES-256、SHA-2、DH 14+、IKEv2 是現代預設值。
Accelerated VPN 透過 AWS Global Accelerator 路由，僅支援 TGW，需額外付費。
客戶閘道是地端設備（路由器或防火牆）；AWS 提供主流廠商（Cisco、Juniper、Palo Alto 等）的設定範本。
參考：https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html

Direct Connect 搭配 MACsec：在交叉連接上的第二層加密

AWS Direct Connect 是地端路由器與 AWS Direct Connect 機房之間的專用、私有第二層連接。MACsec（IEEE 802.1AE）在專用連結上以第二層進行加密，提供線速加密，且不消耗任何一端的 CPU 資源。

何時用 Direct Connect，何時用 MACsec

Direct Connect 是情境題提到可預測頻寬（1、10 或 100 Gbps）、穩定低延遲、非網際網路傳輸的法規要求，或大量高容量資料傳輸時的答案。若未使用 MACsec，Direct Connect 連結是私有的但第二層未加密——需要 IPsec（Direct Connect 上的 VPN）才能提供機密性保護。有了 MACsec，第二層連結本身以線速的 AES-256-GCM 加密，讓分層的 IPsec 對於機密性要求來說變得可選或不必要。

MACsec 需求：在支援 MACsec 的 Direct Connect 機房建立專用 10 Gbps 或 100 Gbps Direct Connect 連接、兩端都支援 IEEE 802.1AE-2006 搭配 GCM-AES-256 密碼套件，以及在兩台路由器上都設定預共享的 Connectivity Association Key（CAK）。

公有、私有與 Transit VIF

Direct Connect 連接承載三種類型的虛擬介面（VIF）：

Public VIF——透過私有連結存取 AWS 公有服務（S3、DynamoDB），繞過公開網際網路，且不需要使用 VPC endpoint。
Private VIF——透過 Virtual Private Gateway 存取單一 VPC。
Transit VIF——存取 Direct Connect Gateway，再分散到多個 Region 的多個 VPC，透過 Transit Gateway 路由。

對於多 VPC、多 Region 的存取需求，Transit VIF + Direct Connect Gateway + Transit Gateway 的組合是 SCS-C02 的標準答案。

Direct Connect 高可用性

單一 Direct Connect 連接是單點故障。AWS 建議的韌性設計：在兩個不同的 Direct Connect 機房各建立一條連接，搭配 BGP 加權路由或 AS-PATH prepending 實現 active/active 或 active/passive 故障切換。Site-to-Site VPN 作為單條 Direct Connect 的備份，對於較不關鍵的工作負載是可接受的做法。SCS-C02 提到「第一層任務關鍵型混合連接」時，期待的答案是雙 Direct Connect 加上 VPN 作為第三層備援。

SCS-C02 的一個細微區別：MACsec 只加密從你的路由器到 AWS Direct Connect 設備的專用交叉連接。它不加密超出 AWS 邊緣之後的流量——在 AWS 內部，Direct Connect Gateway 上的流量走 AWS 骨幹（私有但非 MACsec 加密）。若要從你的資料中心到特定 VPC 執行個體實現端對端加密，仍需要應用層 TLS 或在 Direct Connect 上疊加 IPsec VPN。MACsec 滿足「加密交叉連接」的需求；它不滿足「加密所有傳輸中資料，端對端」的需求。參考：https://docs.aws.amazon.com/directconnect/latest/UserGuide/MACsec.html

Lambda in VPC：ENI 行為與出站流量

設定為存取 VPC 資源的 AWS Lambda 函數會在 VPC 的子網路內建立 elastic network interface。SCS-C02 測驗此主題有兩個原因：突發流量下的 ENI 擴展行為，以及附掛 VPC 的函數的出站路徑。

ENI 佈建——Hyperplane

舊版 Lambda VPC 整合為每個函數並行單元建立一個 ENI，導致冷啟動緩慢且高並行時 ENI 耗盡。現代 Lambda 使用 AWS Hyperplane 網路代理：ENI 在函數調用間共享並預先暖機，冷啟動延遲從數十秒縮短到數百毫秒。ENI 數量依子網路 × Security Group 的唯一組合數擴展，而非依並行數量。

出站流量

附掛 VPC 的 Lambda 函數只能透過公有子網路中的 NAT gateway 存取公開網際網路（需從函數的私有子網路路由到 NAT）。若無 NAT，函數無法存取網際網路——包括 AWS 服務端點，除非這些服務在函數的 VPC 中設有 interface endpoint。對於呼叫 Secrets Manager、STS 或 KMS 的 VPC 附掛函數，SCS-C02 認可的設計是為這些服務新增 interface VPC endpoint，而非透過 NAT 路由——讓呼叫停留在 AWS 骨幹上，並降低每 GB 的 NAT 成本。

Security Group

每個 Lambda 函數都至少附掛一個 Security Group。函數的出站規則決定它可以連接到哪裡。目的地服務（RDS 資料庫、EC2 執行個體）必須允許來自 Lambda Security Group 的入站流量——以 SG ID 作為來源參照是標準模式。

SCS-C02 設計模式：當 VPC 附掛的 Lambda 函數只需呼叫 AWS 服務（Secrets Manager、STS、KMS、Systems Manager Parameter Store，以及透過 gateway endpoint 的 S3）時，為這些服務佈建 interface VPC endpoint 加上一個 S3 gateway endpoint，函數完全不需要 NAT gateway。函數的子網路是純私有子網路（沒有網際網路路由），所有 AWS 呼叫都透過 PrivateLink 傳輸，資料邊界嚴密。NAT 只保留給需要連接非 AWS 網際網路目的地的出站流量——大多數 Lambda 函數不需要這個。參考：https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html

AWS Firewall Manager：全組織政策強制執行

AWS Firewall Manager 是跨 AWS Organization 集中管理網路安全政策的管理平面。當 SCS-C02 題目問「在每個帳號、每個 VPC、每個 Region 強制執行相同的防火牆基準設定，且防止工作負載擁有者關閉它」時，答案就是 Firewall Manager。

Firewall Manager 管理的內容

Firewall Manager 套用四個政策系列：

AWS WAF 政策——在整個組織的 ALB、CloudFront distribution、API Gateway 與 Cognito user pool 上套用 WAF web ACL。
AWS Shield Advanced 政策——在整個組織的特定資源上套用 Shield Advanced 保護。
AWS Network Firewall 政策——自動將集中撰寫的 Network Firewall 政策和規則群組部署到組織中的每個 VPC。
Security Group 政策——三種子類型：通用 Security Group（對特定資源套用基準 SG）、稽核現有 Security Group（標記並選擇性修復不符規範的 SG），以及使用量稽核（找出未使用的 SG）。

前置條件

Firewall Manager 需要：AWS Organizations 已啟用完整功能（不只是合併帳單）、AWS Config 在每個成員帳號與 Region 中啟用（Firewall Manager 使用 Config 來探索資源），以及指定 Firewall Manager 的委派管理員帳號（通常是 Security Tooling 帳號，而非管理帳號）。

常見使用模式

強制性基準 Network Firewall——組織中每個 VPC 都必須有 Network Firewall，搭配集中撰寫的「封鎖已知惡意網域、只允許企業 SaaS SNI」政策。當新建 VPC 時，Firewall Manager 自動部署。
強制性 WAF 基準——組織中每個 ALB 與 CloudFront 都必須套用 AWS Managed Rule sets（核心規則集、SQL injection、已知惡意輸入），若工作負載擁有者移除規則，自動修復。
稽核 Security Group——標記任何在連接埠 22 或 3389 上有 0.0.0.0/0 的 Security Group，並透過移除這些規則進行修復。
封鎖公開 S3 端點——結合 SCP + Firewall Manager（SCP 是 IAM 層強制執行；Firewall Manager 處理網路層強制執行）。

SCS-C02 常見干擾選項：多帳號情境要求在整個組織建立基準 WAF 或 Network Firewall 設定，而選項包括「透過 CloudFormation StackSets 部署」和「透過 Firewall Manager 部署」。StackSets 可行，但缺少 Firewall Manager 提供的自動修復與政策違規偵測。考試偏好 Firewall Manager，因為它原生整合 Organizations、Config 與 Security Hub。只有當 Firewall Manager 不在選項清單中時，StackSets 才是次佳答案。參考：https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html

常見陷阱總覽——SCS-C02 網路安全

每次 SCS-C02 考試都會遇到這些干擾選項中的大部分。

陷阱一：NACL 是有狀態的

錯誤。NACL 是無狀態的。任何期待回應的入站流量，都必須在出站方向明確允許短暫連接埠。

陷阱二：Security Group 有拒絕規則

錯誤。Security Group 只有允許規則。若要拒絕，使用 NACL 或 Network Firewall 有狀態丟棄規則。

陷阱三：TGW inspection 不需要 appliance mode 就能正常運作

錯誤。跨可用區的非對稱路由會在 inspection VPC 中破壞有狀態檢查，前提是未啟用 appliance mode。

陷阱四：VPC Flow Logs 不擷取所有流量

這裡的類比：VPC Flow Logs 不擷取所有流量（DNS、IMDS、link-local 位址被排除）。若要完整擷取，使用 Traffic Mirroring 或主機端日誌。

陷阱五：KMS、Secrets Manager 等服務有 gateway endpoint

錯誤。只有 S3 和 DynamoDB 有 gateway endpoint。其他所有服務使用 interface endpoint（PrivateLink）。

陷阱六：只有 endpoint policy 就能關閉資料邊界

不足夠。資料邊界需要 endpoint policy 加上儲存桶政策（aws:SourceVpce）加上組織層級的 SCP。每一層單獨使用都有繞過的方式。

陷阱七：MACsec 在整個 AWS 範圍內端對端加密

錯誤。MACsec 只加密專用交叉連接。在 AWS 骨幹內部，流量是私有的，但不是 MACsec 加密。

陷阱八：Site-to-Site VPN 只用一條隧道就夠了

錯誤。客戶閘道必須設定兩條隧道才能實現高可用性；否則 AWS 側端點維護就會中斷連線。

陷阱九：VPC 中的 Lambda 一定需要 NAT

錯誤。如果函數只呼叫 AWS 服務，interface endpoint 完全取代 NAT，並收緊邊界。

陷阱十：Network Firewall 的丟棄會出現在 VPC Flow Logs 中

錯誤。Network Firewall 有自己獨立的流量日誌與告警日誌。SG/NACL 的丟棄在 VPC Flow Logs 中以 REJECT 呈現；Network Firewall 的丟棄不會出現在其中。

陷阱十一：Firewall Manager 不需要 AWS Config 就能運作

錯誤。Firewall Manager 依賴每個成員帳號與 Region 中的 AWS Config 來探索資源。

陷阱十二：Traffic Mirroring 適用於所有執行個體類型

錯誤。Traffic Mirroring 來源必須是 Nitro 架構 EC2 執行個體上的 ENI。較舊的執行個體類型（m4、c4 等）無法成為鏡像來源。

決策矩陣——各 SCS-C02 目標對應的網路安全元件

考試時使用此查詢表。

安全目標	主要元件	備註
允許特定層之間的東西向流量	Security Group（以 SG 作為來源）	有狀態、僅允許、ENI 範圍。
在子網路邊界封鎖已知惡意 CIDR	NACL 拒絕規則	無狀態；記得短暫連接埠範圍。
深層封包檢查 / Suricata IDS	AWS Network Firewall 有狀態規則群組	相容 Suricata。
出站 HTTPS 網域名稱允許名單	Network Firewall 有狀態（SNI/Host 過濾）	TLS 檢查為選用。
透過 inspection VPC 的對稱流量	TGW attachment 啟用 appliance mode	有狀態防火牆的必要條件。
S3/DynamoDB 的私有存取	Gateway endpoint	免費、以 Region 為範圍、路由表條目。
KMS、Secrets Manager 等的私有存取	Interface endpoint（PrivateLink）	每可用區 ENI，有 SG 與政策。
封鎖外洩到非組織儲存桶	Endpoint policy + 儲存桶政策 + SCP 三重防線	資料邊界。
取證完整封包擷取	Traffic Mirroring 至 NLB / 設備	僅限 Nitro 來源。
SIEM 用的網路 metadata	VPC Flow Logs v5 至 S3 / Firehose	成本低、常態開啟、以帳號/Region 分區。
混合連接，設定成本低	Site-to-Site VPN 搭配 BGP	兩條隧道，IPsec 加密。
遠端站點的延遲敏感 VPN	Accelerated Site-to-Site VPN	僅支援 TGW，需額外付費。
可預測頻寬，受監管傳輸	Direct Connect 搭配 private/transit VIF	第二層專用連接。
以線速加密交叉連接	Direct Connect 搭配 MACsec	10/100G 專用，802.1AE。
Lambda 私有呼叫 AWS 服務	VPC 附掛 Lambda + interface endpoint	不需要 NAT。
全組織 WAF / Network Firewall 基準	Firewall Manager 政策	需要 Organizations + Config。
偵測不符規範的 Security Group	Firewall Manager 稽核 Security Group 政策	自動修復為選用。

FAQ — AWS VPC 網路安全

Q1：無狀態 NACL 的短暫連接埠範圍何時會造成連線失敗，而 Security Group 的有狀態特性何時能夠救我？

NACL 是無狀態的，Security Group 是有狀態的。這意味著 Security Group 不需要明確的出站規則就能自動允許短暫連接埠範圍上的回程流量，但 NACL 不行——每個方向都需要各自的 NACL 規則。因此，完全正常運作的 SG 設定加上缺少短暫連接埠出站允許的錯誤 NACL，會導致入站封包成功但回應被丟棄。修復方式是新增一條允許 TCP 和 UDP 連接埠 1024–65535 的出站 NACL 規則（或特定核心定義的短暫連接埠範圍——現代 Linux 為 32768–60999，Windows 為 49152–65535）。SCS-C02 的這類題目通常展示正常運作的 SG 規則和只設了入站允許的不完整 NACL；正確答案是「新增短暫連接埠出站 NACL 規則」。

Q2：何時應使用 AWS Network Firewall，何時應使用 Gateway Load Balancer 搭配第三方設備？

當需求可以由 Suricata 風格有狀態規則、網域名稱過濾與基本 TLS 檢查滿足時，使用 AWS Network Firewall——典型的企業出站流量過濾、惡意軟體 C2 封鎖，以及透過 DNS 或 HTTPS 到已知惡意網域的資料外洩防護。這個選項完全受管、水平擴展，並與 Firewall Manager 整合實現全組織部署。當你需要 Network Firewall 不具備的廠商特定功能時，使用 Gateway Load Balancer + 第三方設備（Palo Alto、Fortinet、Check Point、Aviatrix）：進階沙箱、使用自訂協定解碼器的應用感知政策、深度 mTLS 處理，或要求特定商業技術棧的嚴格法規要求。在 SCS-C02 中，除非情境明確要求第三方特定功能，否則預設選 Network Firewall。

Q3：為什麼資料邊界需要同時有 VPC endpoint policy 和 S3 儲存桶政策？

因為每一層防護不同的攻擊向量。VPC endpoint policy 限制網路路徑透過端點可到達的儲存桶——防禦的是 VPC 內遭入侵的情境，攻擊者持有有效的 AWS 憑證，但端點拒絕呼叫組織外部的儲存桶。S3 儲存桶政策搭配 aws:SourceVpce 條件限制哪些端點可以存取此儲存桶——防禦的是來自公開網際網路或未授權 VPC 的存取。兩者共同形成雙向封閉的邊界：無法外洩到組織外部儲存桶，也無法從外部帳號向你的儲存桶灌入資料。再加上組織層級的 SCP 拒絕 aws:ResourceAccount 不在組織帳號清單中的任何 S3 動作，攻擊者的路徑就在 IAM 授權層也被關閉了。SCS-C02 期待這三層都到位。

Q4：Transit Gateway appliance mode 是否影響效能或成本？

Appliance mode 強制讓同一條流的兩個方向都走同一個可用區的相同 Transit Gateway attachment ENI。這消除了非對稱路由（會破壞有狀態防火牆）的問題，且不產生額外費用——appliance mode 本身沒有額外收費，每 GB 的 Transit Gateway 資料處理費也不變。唯一實際影響是跨可用區路徑選擇的彈性略微降低，但對 inspection VPC 情境來說，這正是期望的行為。任何承載有狀態檢查功能的 VPC（Network Firewall、透過 Gateway Load Balancer 的第三方防火牆、Palo Alto VM-Series）的 TGW attachment 都應啟用 appliance mode。忘記啟用 appliance mode 是 SCS-C02 「多可用區流量間歇性中斷」故障排除題中最高頻率的根本原因。

Q5：Direct Connect 上的 Public VIF、Private VIF 與 Transit VIF 有什麼差異？

Public VIF 透過私有交叉連接承載目的地為 AWS 公有服務 IP（S3、DynamoDB、公有 IP 負載平衡器）的流量，繞過網際網路——在法規禁止即使到 AWS 自有位址也不得走網際網路傳輸時很有用。Private VIF 透過 Virtual Private Gateway 承載到單一 VPC 的流量，用於單一 Region 單一 VPC 的混合部署。Transit VIF 承載到 Direct Connect Gateway 的流量，再分散到多個 AWS Region 的一個或多個 Transit Gateway，實現一條 VIF 支援多 VPC 多 Region 的混合連接。SCS-C02 期待你認識 Transit VIF 是任何現代多 Region 多帳號架構的標準模式；Private VIF 是舊版單 Region 方案；Public VIF 是小眾用途。

Q6：如何架構一個需要呼叫 KMS、Secrets Manager 以及外部 HTTPS API 的 VPC 附掛 Lambda 函數？

將函數放在私有子網路中。為函數呼叫的所有 AWS 服務新增 interface VPC endpoint（KMS、Secrets Manager、STS，以及任何其他 AWS 服務）——這些透過 PrivateLink 路由，不需要 NAT，大規模下成本更低，且在 CloudTrail 中可稽核。只為外部 HTTPS API 呼叫在公有子網路新增 NAT gateway（從函數的私有子網路路由），並透過目的地的 Security Group 嚴格限縮 NAT 的目的地範圍——或者更好的做法是，使用帶有網域名稱允許名單的 Network Firewall 作為出站過濾器，NAT gateway 在其下游。對於資料邊界，在 interface endpoint 上附掛 endpoint policy，將主體限制為函數角色，將資源限制為預期的 secret 和金鑰。這個模式是 SCS-C02 對「安全 VPC 附掛 Lambda 搭配選擇性網際網路出站」的最佳實務標準。

Q7：應選擇哪個 VPC Flow Logs 版本，而 ALL 擷取了哪些 ACCEPT 和 REJECT 個別未能擷取的流量？

選擇 v5——它是欄位最豐富的格式（VPC ID、子網路 ID、執行個體 ID、流量路徑、ECS task ARN、子位置類型），且每攝入 GB 的成本與舊版格式相同。ACCEPT 只擷取允許的流量；REJECT 只擷取被封鎖的流量；ALL 兩者皆擷取。安全調查和 SIEM 攝入選 ALL——被拒絕的流量（REJECT）是偵測偵察掃描、設定錯誤用戶端和政策違規的關鍵訊號，而允許的流量（ACCEPT）則是行為基準線和橫向移動偵測所需的。只有在儲存成本是主要限制，且你接受喪失基準線的前提下，才單獨選 REJECT。SCS-C02 的預設期待：v5 + ALL + S3 目的地 + Athena 分區。

Q8：何時應使用 Traffic Mirroring 而非 VPC Flow Logs，有哪些注意事項？

當需要 payload 檢查時使用 Traffic Mirroring——取證分析的完整封包擷取、封包內容的 IDS 特徵碼比對、重播除錯，或需要完整封包留存的法規要求。Flow Logs 用於僅需 metadata 的遙測——連線記錄、安全分析基準線、GuardDuty 輸入、廣泛可觀測性。Traffic Mirroring 注意事項：來源 ENI 必須在 Nitro 架構執行個體上（m5/m6i/c5/c6i 及更新）；目標 NLB 或設備必須能擴展以處理鏡像頻寬（這有效地讓你的網路負載加倍）；鏡像流量同時對 mirror session 和目標處理計費；VLAN 封裝會被加入，因此分析工具必須能夠處理它。Traffic Mirroring 也是即時性的——它不能追溯擷取；事件發生前就要開啟，或準備在事件進行中啟用。

Q9：Firewall Manager 和 CloudFormation StackSets 在全組織網路安全政策上有何差異？

兩者都能將資源部署到多個帳號。CloudFormation StackSets 是通用的基礎設施即程式碼；你撰寫範本，推送到 N 個帳號，受管堆疊的漂移偵測在有人變更資源時發出警報。Firewall Manager 是專為安全政策打造的：它理解 WAF、Shield、Network Firewall 和 Security Group 的語義，支援偵測到違規時自動修復（StackSets 能偵測漂移但無法自動修復），與 AWS Config 整合進行資源探索，與 Security Hub 發現結合，並與 AWS Organizations 政策層級緊密連結。SCS-C02 對任何「全組織強制執行安全基準」的題目都期待 Firewall Manager；只有當 Firewall Manager 不支援該資源類型時（例如自訂 VPC 設定），StackSets 才是次佳答案。

Q10：加密地端資料中心與私有 VPC 子網路中工作負載之間流量的正確方式是什麼？

依需求嚴格程度分層提供多個選項。（a）Site-to-Site VPN 搭配 IPsec——在 IPsec 層加密，足以滿足大多數法規要求，設定成本低，兩條隧道提供高可用性。（b）僅使用 Direct Connect——私有但未加密；搭配 MACsec 在交叉連接上進行第二層加密（線速、低延遲、在專用連結上提供強大機密性）。（c）Direct Connect 加上在其上疊加 Site-to-Site VPN（VPN over DX）——透過 Direct Connect 進行端對端 IPsec 加密，同時滿足「私有傳輸」和「IPsec 加密」的要求；這是最嚴格受監管產業的標準答案。（d）應用層 TLS 端對端——與以上所有選項正交；工作負載本身終止 TLS，即使 AWS 側遭入侵也無法解密。在 SCS-C02 中，當情境提到「受監管」、「合規」、「FedRAMP」或「即使在私有連結上也必須加密所有傳輸中資料」時，（c）是最高得分的答案。對於（d），注意「端對端加密」或「AWS 無法解密」的措辭。

延伸閱讀與相關操作模式

VPC 網路安全就位之後，SCS-C02 上自然銜接的下一層操作主題包括：CloudFront、AWS WAF 與 AWS Shield Advanced 的邊緣防護（Domain 3.1），保護 VPC 前端的公開存取層；VPC endpoint policy 與資料邊界，處理 IAM 與網路政策交會的邊界；GuardDuty 威脅偵測，消費 VPC Flow Logs 與 DNS 日誌進行行為威脅分析；Security Hub 聚合，將 Network Firewall、GuardDuty 與 Firewall Manager 的發現整合到單一視窗；以及 KMS 傳輸中與靜態加密，在網路控制之上疊加密碼學機密性。