Amazon ANS-C01: 自動化、IaC 與網路營運 — 學習指南
屬於 AWS Advanced Networking Specialty ANS-C01 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.
核心概念
在 AWS 上，網路的基礎設施即程式碼 (Infrastructure as Code) 將網路拓撲、安全政策與路由轉換為宣告式範本和確定性的生命週期操作。CloudFormation 範本 (
undefined
、
undefined
、
undefined
、
undefined
、
undefined
、
undefined
、
undefined
、
undefined
、
undefined
) 編碼了期望的狀態，而 CloudFormation API——CreateStack、UpdateStack、DeleteStack、DescribeStacks 和 ChangeSet 操作——則以原子方式套用變更。使用巢狀堆疊 (nested stacks) 和模組化範本來隔離網路網域 (共享服務、每個帳戶的應用程式 VPC、傳入/傳出流量區域)，並使用 StackSets 將一致的網路堆疊部署到整個 AWS Organizations。漂移偵測 (DetectStackDrift) 和變更集 (change sets) 提供了護欄，讓自動化能夠偵測到帶外 (out-of-band) 的網路變更，並要求人工審查。
自動化還必須涵蓋 CloudFormation 原生無法表達或需要生命週期掛鉤 (lifecycle hooks) 的部分網路功能：跨帳戶資源共享、地端整合以及主機上的執行期組態。CloudFormation 自訂資源 (由 Lambda 支援) 或 CloudFormation 模組可以呼叫像是 CreateResourceShare (AWS RAM) 這類的 API 來共享 Transit Gateway 或子網路，或呼叫 Systems Manager (SSM) SendCommand 來將憑證或路由政策注入到執行個體中。對於 EKS 中的 Kubernetes，AWS Load Balancer Controller 是透過 Helm 安裝，並透過 Service annotations 進行管理；CloudFormation 可以透過
undefined
和自訂資源來佈建 IAM 角色、OIDC 提供者和 HelmRelease 物件，但 Pod IP 到 NLB 目標群組的執行期對應則由該控制器處理。
關鍵服務與組態
在自動化網路操作時，您會反覆使用一些主要的 AWS 服務和 API：CloudFormation (CreateStack、UpdateStack、DetectStackDrift)、AWS Resource Access Manager (CreateResourceShare、AssociateResourceShare)、AWS Transit Gateway (CreateTransitGateway、CreateTransitGatewayAttachment、CreateTransitGatewayRoute)、Elastic Load Balancing V2 (CreateLoadBalancer、CreateTargetGroup、ModifyTargetGroupAttributes)、AWS Lambda (CreateFunction、AddPermission、Invoke)、Systems Manager (PutParameter、SendCommand、CreateDocument) 和 AWS Config (PutEvaluations、StartConfigurationRecorder)。這些服務構成了一個典型用於安全、可稽核網路的自動化堆疊。
在設計範本和自動化時，請注意特定的資源屬性和控制器註解 (annotations)。對於負載平衡器，請選擇正確的類型和屬性：帶有 TCP 接聽器 (listener) 的 NLB 會保留來源 IP，並可透過 CreateLoadBalancer/ModifyTargetGroupAttributes 以及在目標群組上設定 “proxy_protocol_v2.enabled” 來支援 Proxy Protocol v2；ALB (Application Load Balancer) 則會終止 TLS、為客戶端 IP 插入 X-Forwarded-For 標頭，並在設定為 HTTPS 接聽器時支援 gRPC/HTTP2。對於 EKS，您會使用像是
undefined
這類的註解，或是 AWS Load Balancer Controller 的 Ingress/Service 註解，來控制 TLS 是要穿透 (passthrough) 還是終止，並將目標類型 (target type) 設定為 ip 以直接指定 Pod 為目標。對於跨帳戶共享和多帳戶網路，您將使用 AWS RAM 來共享 Transit Gateways，並結合 CloudFormation StackSets 與委派管理員角色，在消費者帳戶中建立附件 (attachments) 和存取權限。
設計模式與權衡取捨
兩種常見且對比鮮明的模式是使用 Transit Gateway 的軸輻式 (hub-and-spoke) 架構，以及透過 AWS RAM 實現的共享 VPC (shared-VPC)。使用 Transit Gateway 的軸輻式架構將路由、檢測和 VPC 間的連線能力集中化；它具有擴展性，因為附件和路由表允許進行分段，而且您可以使用 RAM 共享 TGW，讓不同帳戶可以在不轉移完整擁有權的情況下建立附件。其權衡之處在於路由傳播和路由表限制：Transit Gateway 的路由表和附件數量限制需要預先規劃，且可能產生必須強制執行政策的單點（可使用多個路由表和 AWS Network Firewall 來隔離流量）。共享 VPC (透過 AWS RAM 共享 VPC) 將子網路放置在一個主機帳戶中，並讓消費者帳戶在這些子網路中啟動資源。這簡化了集中式的連線安全控制，但降低了帳戶層級的自主性，並且因為安全群組的擁有權和 IAM 邊界必須謹慎管理，而使得按業務單位進行網路隔離變得更加複雜。
對於傳入流量 (ingress) 和 TLS 終止，您必須在端對端加密的需求與擴展性、客戶端 IP 保留之間取得平衡。如果您需要在負載平衡器上終止 TLS（用於 WAF、憑證集中化和 HTTP 路由），ALB 是正確的工具；它會添加 X-Forwarded-For 標頭，讓應用程式日誌可以捕獲客戶端 IP，並且 ALB 支援基於路徑和主機的路由到多個目標群組。如果您需要真正的端對端 TLS 或 mTLS，且負載平衡器不得解密流量，請使用 TCP 模式的 NLB，將 TLS 流量穿透至後端端點（Pod 或執行個體），並在 Kubernetes 上設定 target type 為 ip 以及
undefined
來保留來源 IP。對於數千個帶有 mTLS 的並行雙向 gRPC 連線，一個將原始 TLS 流量轉發到 Pod 連接埠的 NLB，再結合由 Pod 終止 mTLS 的作法，可提供擴展性和真正的端對端加密，同時可使用 AWS Load Balancer Controller 的註解來建立適當的 NLB 接聽器和目標群組。
常見陷阱與決策標準
一個常見的陷阱是將 TLS 終止位置與客戶端 IP 的需求混淆：當 ALB 終止 TLS 時，它會提供 X-Forwarded-For，但它不像 NLB 那樣會將來源 IP 保留到目標。如果您同時需要 ALB 的功能（主機/路徑路由、WAF）以及後端的原始來源 IP，可以考慮使用 ALB 進行 HTTP 終止，並轉發到能夠從 X-Forwarded-For 重建來源 IP 的反向代理或 sidecar，或者採用一種架構，讓 NLB 將 TLS 直接透傳給執行 mTLS 的服務，並將 HTTP 路由卸載到叢集內的代理。另一個陷阱是跨帳戶權限的設定錯誤：當使用 RAM 分享 Transit Gateway 或其他網路資源時，請確保您使用明確的資源分享、正確的 IAM 角色和 RAM principal；若未這麼做，會導致不明確的「permission denied」錯誤。
在合規自動化方面，請勿以未加密的純文字形式儲存私鑰或 CA 材料。應使用 SSM Parameter Store SecureString，並搭配一個 KMS 金鑰，該金鑰的政策應盡可能精簡，只允許需要存取的角色和 principal。使用 AWS Config 受管規則（例如，vpc-flow-logs-enabled、restricted-common-ports、security-group-rule-check），而當受管規則無法涵蓋您的標準時，請實作由 Lambda 支援、會呼叫 PutEvaluations 的 Config 規則。修復動作應透過 SSM Automation 文件或 Systems Manager Run Command 來自動化，這些都可以由 Config 的修復動作來叫用，但對於高風險的變更，務必提供一個告警和核准的路徑。
實務問題：使用案例情境
公司：ApexTelemetrics — 挑戰：提供一個全球可達、託管於 EKS 上的 gRPC 服務，該服務需要真正的端對端相互 TLS（客戶端與伺服器使用 mTLS 進行驗證），支援在 TCP 443 上數千個並行的長連線，必須能自動擴展 pod，並確保憑證的分發和輪替是自動化且可稽核的。
方法：
- 使用 CloudFormation 佈建網路和負載平衡器：透過
undefined
建立一個 NLB，設定其在 443 埠上使用 TCP listener，並將目標群組的 targetType 設為 “ip”，同時在 TCP 上進行健康檢查。使用 CloudFormation 的
undefined
以及模組化的巢狀堆疊來管理 VPC、子網路和 NLB。在 EKS Service 上使用 AWS Load Balancer Controller 的 annotation (
undefined
,
undefined
)，讓每個 Service 直接將 pod 註冊到 NLB 目標群組中。 2) 確保 TLS 透傳並在 pod 層級終止 mTLS：設定 EKS Service 將 TCP 443 直接轉發到 pod 的埠口；在每個 pod 內實作一個 sidecar 或 envoy 代理，用以與客戶端執行 mTLS 終止並強制執行相互驗證。在 Service 上設定
undefined
以便在需要時保留來源 IP，並使用 Pod 層級的自動擴展 (Horizontal Pod Autoscaler) 搭配 Cluster Autoscaler 來同時擴展節點和 pod。 3) 自動化憑證生命週期與分發：將 CA 和伺服器憑證的私鑰儲存在由 KMS 金鑰加密的 SSM Parameter Store SecureString 中。在 CloudFormation 中建立一個由 AWS Lambda 支援的自訂資源，以便在堆疊建立期間建立 SSM 參數（使用具備適當 IAM 角色的
undefined
，然後透過 CloudFormation 自訂資源呼叫
undefined
）。使用 SSM Run Command 或一個不可變的 DaemonSet，透過綁定到 pod 的 IAM 角色（經由 IRSA）從 SSM 中提取機密，並將憑證注入到 sidecar 中。對於輪替，排程 Lambda 函數（
undefined
- EventBridge 規則）來產生新憑證、呼叫
undefined
，並使用 SSM 或 Kubernetes Jobs 來執行滾動重啟。 4) 合規與稽核：啟用 AWS Config 規則（例如
undefined
等受管規則，以及使用
undefined
的自訂 Lambda 支援規則）來驗證 NLB 的 listener 是 TCP 模式，並且沒有 ALB 為此服務終止 TLS。設定 Config 修復動作，在偵測到設定錯誤時叫用 SSM Automation 文件，並將調查結果傳送到 AWS Security Hub 和 CloudWatch Events。 AWS 的理由：TCP 模式的 NLB 提供了端對端 mTLS 所需的真正 TLS 透傳功能，並且能夠擴展到數千個並行連線，同時在負載平衡器上每個連線的 CPU 耗用量很小。透過 targetType=ip 將目標設定為 pod，可以減少一次額外的躍點（hop），並保持自動擴展的反應靈敏。將金鑰儲存在由 KMS 保護的 SSM Parameter Store 中並進行輪替，提供了具備 IAM 控制的集中化、可稽核的機密管理；而使用 CloudFormation 加上 Lambda 自訂資源和 EventBridge，則確保了整個生命週期都被程式碼化、可重複且可觀察。
← 網路效能與監控 · 所有領域 · 容器與無伺服器網路 →
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →