網路基礎架構 IaC — CloudFormation、CDK 與 Terraform 模式

ANS-C01 中的網路基礎架構 IaC 是考生最容易輕視的部分。架構師助理級考試將 CloudFormation 視為「YAML/JSON 工具」。而進階網路 Specialty 考試則會問：「給定一個擁有 200 個帳戶的 AWS 組織，設計一種 IaC 模式，部署一個帶有 TGW 連接、Network Firewall 整合、流向中央 S3 儲存貯體的 Flow Logs 以及有條件轉發至內部部署的 Resolver 規則的基準 VPC — 使用 StackSets，並在漂移時自動修復，對 VPC 和子網 ID 使用動態參考，且不硬編碼可用區 (AZ) 名稱 — 並解釋在單獨的工作負載堆疊中使用該 VPC ID 時，跨堆疊與跨區域的限制」。這就是規模化生產級網路 IaC，而 ANS-C01 中大約有 3-5 個此類問題。

本主題涵蓋了 AWS 網路的 IaC 基本面：用於 VPC、子網、路由表、安全性群組、NAT 閘道、IGW、TGW 和 Network Firewall 的 CloudFormation 範本；用於多帳戶多區域基準部署的 StackSets；跨堆疊參考 (匯出/匯入) 及其區域/帳戶限制；具有 SubnetType 列舉和更高級別 L2/L3 抽象的 AWS CDK 網路建構；Terraform 網路模組與模式；用於動態 VPC/子網 ID 參考的 SSM Parameter Store；使用 EventBridge + Lambda 進行修復的事件驅動自動化；用於漂移偵測和合規性的 AWS Config；以及針對原生不支持資源的 CloudFormation 自訂資源。此內容對應至任務陳述 2.4 (網路基礎架構自動化與配置)。

為什麼 IaC 是 ANS-C01 中生產環境與展示環境的區別

ANS-C01 明確測試網域 2.4 的 IaC，是因為 AWS 看到許多生產環境故障都源於硬編碼的基礎架構範本。帶有硬編碼 AMI ID 的 VPC 範本在其他區域重複使用時會失敗。帶有硬編碼 AZ 名稱 (us-east-1a, us-east-1b) 的 CloudFormation 堆疊無法在另一個區域重新部署。一個針對 VPC CIDR 分配變更全域狀態的 CDK 應用程式會在規模化時產生衝突。考試測試如何辨識這些模式，並選擇正確的原語 — 對應 (Mappings)、參數 (Parameters)、虛擬參數 (Pseudo Parameters)、SSM 動態參考、AZ 資料查找 — 以使範本具備可移植性。

本主題的核心框架是帶有參數化的宣告式基礎架構。每個範本、CDK 應用程式或 Terraform 模組都應該取用外部輸入 (CIDR、區域、帳戶、環境)，產生其他範本可以參考的輸出，並避免嵌入魔術值 (Magic values)。這產生了可重複使用的建築區塊 — VPC 模組、TGW 連接模組、Network Firewall 模組 — 它們組合成多帳戶多區域架構。ANS-C01 期望你能辨識可重複使用的模式，並重構違反這些模式的範本。

考試以三種截然不同的形式測試 IaC。可重複使用性與可移植性會問：「什麼原因使此範本無法移植到新區域？」，選項包括「硬編碼的 AZ 名稱」和「硬編碼的 AMI ID」。多帳戶部署會問：「將 VPC 基準部署到 50 個帳戶 — 應使用哪種機制？」(StackSets，有時會以 CDK Pipelines 作為干擾項)。事件驅動修復會問：「當安全性群組向 0.0.0.0/0:22 開放時自動修復 — 什麼觸發以及什麼執行？」(Config 規則 + EventBridge + Lambda)。

白話文解釋 IaC for Network Infrastructure

IaC 將一些基本原語 (範本、參數、匯出/匯入、自訂資源、部署編排) 結合成可重複使用的基礎架構模式。我們用三個類比來幫助理解。

類比 1：帶有標準組件目錄的建築藍圖

將 IaC 想像成建築物的建築藍圖。CloudFormation 範本是主藍圖 — 每一面牆、門、窗和管道都被宣告式地指定。參數是藍圖頂部的自訂旋鈕 — 「這間房子有 4 個臥室；那間有 5 個」。對應 (Mappings) 是目錄查找表 — 「對於 X 區域使用 Y AMI，對於 Z 區域使用 W AMI」。虛擬參數是標準的測量值 — AWS::Region, AWS::AccountId, AWS::StackName — 由平台自動提供，無需建築師指定。跨堆疊匯出就像一份藍圖說：「鋼樑堆疊將提供編號為 42 的樑；我們將把它栓在上面」 — 第二份藍圖匯入該匯出值。CDK 是一個更高級的建築師程式 — 它不是繪製每一顆釘子，而是從 Python 或 TypeScript 的描述中產生藍圖：「建造一棟帶有車庫的 4 臥室房子」。StackSets 是大宗建築特許經營商 — 同一份藍圖同時部署到 200 個地塊。Terraform 是另一種繪圖服務，提供類似的藍圖，語法略有不同，供應商支援更廣 (多雲)。

類比 2：食譜書 vs 烹飪書 vs 連鎖餐廳

CloudFormation 範本是一份食譜 — 宣告式的，指定了每種食材和步驟。參數是食譜的變體 — 「4 人份用 1 杯；8 人份用 2 杯」。CDK 是一個烹飪書產生器 — 你編寫高級指令 (「標準義大利晚餐」)，它會產生食譜。Terraform 是另一家烹飪書出版商，為許多菜系提供類似的食譜 (多雲)。StackSets 是連鎖餐廳特許經營 — 同一份食譜部署到 200 家餐廳。跨堆疊匯出是共享的廚房食材 — 「預備廚房製作湯底；線路廚師取用它」。自訂資源是標準烹飪書中未列出的特殊訂購食材 — 你需要打電話給 Lambda 來採購它們。漂移偵測是食品安全檢查，檢測廚師是否偷偷更改了食譜。

類比 3：汽車製造生產線

CloudFormation 範本是車型的裝配線規格。每個組件、每個子裝配、每根電線都已宣告。參數是飾面等級選項 — 「帶鋼輪的基礎型 vs 帶合金輪的運動型」。對應是區域性的組件變體 — 「北美使用供應商 A 的鋼材；歐洲使用供應商 B」。跨堆疊匯出是零件目錄 — 當引擎堆疊發佈「引擎裝配零件 #42」時，車身堆疊會匯入並螺栓安裝。CDK 是從高級設計語言產生裝配規格的 CAD 程式。StackSets 是多工廠推廣 — 在 200 家工廠生產具有一致規格的相同車型。漂移偵測是品質檢驗，捕捉偏離規格的工廠。

CloudFormation 網路資源 — 核心清單

CloudFormation 支援對每一種 AWS 網路資源進行宣告式佈建。Specialty 考試期望考生熟悉資源類型及其關係。

核心資源類型

• AWS::EC2::VPC — VPC 本身，包含 CIDR、雙堆疊屬性、租戶模式。
• AWS::EC2::Subnet — 子網，包含 CIDR、AZ、mapPublicIpOnLaunch 旗標。
• AWS::EC2::InternetGateway + AWS::EC2::VPCGatewayAttachment — IGW 建立與連接。
• AWS::EC2::NatGateway + AWS::EC2::EIP — NAT 閘道及其彈性 IP。
• AWS::EC2::RouteTable + AWS::EC2::Route + AWS::EC2::SubnetRouteTableAssociation — 路由表、個別路由及子網關聯。
• AWS::EC2::SecurityGroup + AWS::EC2::SecurityGroupIngress / Egress — 安全性群組與規則。
• AWS::EC2::NetworkAcl + AWS::EC2::NetworkAclEntry + AWS::EC2::SubnetNetworkAclAssociation — NACL 與規則。
• AWS::EC2::TransitGateway + AWS::EC2::TransitGatewayAttachment + AWS::EC2::TransitGatewayRouteTable — TGW 家族。
• AWS::EC2::VPCEndpoint — 閘道或介面端點。
• AWS::EC2::FlowLog — VPC Flow Logs。
• AWS::NetworkFirewall::Firewall + FirewallPolicy + RuleGroup — Network Firewall 家族。

資源間的參考

CloudFormation 使用 !Ref 和 !GetAtt 來參考同一個範本中的其他資源：

Resources:
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
  MySubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: 10.0.1.0/24
      AvailabilityZone: !Select [0, !GetAZs '']

注意 !GetAZs '' 會返回當前區域的 AZ 清單 — 避免了硬編碼的 AZ 名稱。!Select [0, ...] 選擇第一個 AZ。這使其在各區域間具有可移植性。

虛擬參數 (Pseudo parameters)

CloudFormation 提供由服務自動填入的虛擬參數：

• AWS::Region — 當前區域，例如 us-east-1。
• AWS::AccountId — 部署此堆疊的帳戶。
• AWS::StackName — 此堆疊的名稱。
• AWS::Partition — aws, aws-cn, aws-us-gov。
• AWS::URLSuffix — amazonaws.com 或 amazonaws.com.cn。

使用這些參數可實現跨區域、帳戶和分割區的可移植性。

區域特定值的對應 (Mappings)

如果某個值隨區域變化 (例如 AMI ID)，請使用 Mappings 區段：

Mappings:
  RegionMap:
    us-east-1:
      AMI: ami-0abc1234
    us-west-2:
      AMI: ami-0def5678
Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !FindInMap [RegionMap, !Ref AWS::Region, AMI]

這具備可移植性，但當 AMI 更改時需要手動更新。通常更建議使用 SSM Parameter Store 動態參考 (見下一節)。

CloudFormation StackSets — 多帳戶多區域網路

CloudFormation StackSets 可透過單次操作在多個帳戶和區域中編排範本部署。它是 ANS-C01 中「在整個 AWS 組織部署此 VPC 基準」的標準答案。

架構

一個 StackSet 包含：

• 範本 (Template) — 要部署的 CloudFormation 範本。
• 目標 (Targets) — 將建立堆疊的帳戶和區域。
• 權限模型 — SELF_MANAGED (手動建立跨帳戶角色) 或 SERVICE_MANAGED (使用 AWS Organizations + 服務連結角色)。
• 操作偏好 — 並行限制、失敗容許。

每個目標都會獲得自己的堆疊執行個體 (Stack instance)，這是一個與 StackSet 綁定的正規 CloudFormation 堆疊。對 StackSet 的更新會傳播到所有執行個體。

使用 AWS Organizations 的服務受管 StackSets

現代模式：啟用 CloudFormation StackSets 與 AWS Organizations 之間的受信任存取。管理帳戶可以將 StackSets 部署到組織單位 (OU) 或整個組織。當新帳戶加入 OU 時，堆疊會自動部署。自動部署 + 自動更新 + 自動移除，讓基準網路治理變得無需動手。

常見模式

• 在每個帳戶/區域啟用 VPC Flow Logs — 使用指向中央 S3 儲存貯體的 Flow Log 資源的 StackSet。
• 在每個帳戶建立基準 VPC — 建立 VPC、子網、IGW、NAT 閘道、路由表的 StackSet。
• 在每個帳戶/區域啟用 AWS Config — 包含指向中央 S3 的 Config 記錄器和傳遞通道的 StackSet。
• 全組織 TGW 連接 — 建立與中央 TGW (透過 RAM 共享) 的 VPC 連接的 StackSet。

限制

• StackSets 無法透過匯出/匯入跨帳戶參考另一個堆疊中的資源。
• 區域特定資源的可用性很重要 — 某些服務並非在所有區域都有。
• 更新傳播是單向的：StackSet → 執行個體。執行個體上的漂移偵測會報告差異。

跨堆疊參考 — 匯出與匯入

CloudFormation 支援透過匯出/匯入 (Export/Import) 機制在單個帳戶和區域內進行跨堆疊參考。一個堆疊將輸出發佈為匯出值；另一個堆疊將其匯入作為參數值。

產生者堆疊 — 匯出 VPC ID

Outputs:
  VpcId:
    Description: VPC ID for shared networking
    Value: !Ref MyVPC
    Export:
      Name: !Sub "${AWS::StackName}-VpcId"

取用者堆疊 — 匯入 VPC ID

Resources:
  MySecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      VpcId:
        Fn::ImportValue: NetworkStack-VpcId
      GroupDescription: Workload SG

限制

• 僅限相同帳戶、相同區域。跨堆疊匯出無法跨帳戶或跨區域運作。
• 一旦匯出值被另一個堆疊取用，在取用者更新之前，產生者堆疊無法刪除或修改該匯出值。
• 對匯出值的更新需要謹慎的更新順序。

跨帳戶/跨區域 — 使用 SSM Parameter Store

對於多帳戶或多區域共享，請使用 SSM Parameter Store 作為共享註冊表：

• 產生者堆疊將 VPC ID 寫入 /network/prod/vpcid (可能帶有跨帳戶 KMS 金鑰進行加密)。
• 取用者堆疊 (在具有適當存取權限的任何帳戶、區域) 透過 SSM 動態參考讀取：{{resolve:ssm:/network/prod/vpcid}}。
• 透過共享參數 (配合適當的 IAM 策略和 KMS 金鑰存取) 進行跨帳戶存取。

限制

• CloudFormation 中的 SSM 動態參考是在範本解析時解析的 — 而不是之後。
• SSM 參數的更新不會自動觸發堆疊更新。
• 跨帳戶 SSM 需要謹慎的 KMS 金鑰共享和 IAM 策略設定。

SSM Parameter Store 與動態參考

SSM Parameter Store 是 AWS 管理的配置金鑰值存儲。CloudFormation 支援動態參考以在範本解析時檢索 SSM 值。

動態參考語法

Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: '{{resolve:ssm:/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2}}'

{{resolve:ssm:...}} 語法在建立/更新堆疊期間獲取 SSM 參數值。AWS 在 /aws/service/ami-amazon-linux-latest/... 發佈當前 Amazon Linux AMI 的受管參數 — 始終保持最新，且不硬編碼。

跨堆疊對 VPC ID 使用 SSM

產生者堆疊：

Resources:
  VpcIdParameter:
    Type: AWS::SSM::Parameter
    Properties:
      Name: /network/prod/vpcid
      Type: String
      Value: !Ref MyVPC

取用者堆疊 (具有該參數讀取權限的任何帳戶)：

Resources:
  MySecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      VpcId: '{{resolve:ssm:/network/prod/vpcid}}'

何時使用 SSM 動態參考 vs 跨堆疊匯出

• 跨堆疊匯出：相同帳戶、相同區域、緊密耦合的堆疊，且你希望 CloudFormation 追蹤相依性。
• SSM 動態參考：跨區域、跨帳戶或鬆散耦合。產生者發佈；取用者獨立讀取。

限制

• 解析發生在部署時。隨後的 SSM 參數變更不會重新觸發堆疊更新。
• 某些資源屬性不支持動態參考 (在網路方面較少見；在 IAM 方面較常見)。

AWS CDK — 網路建構與高級抽象

AWS CDK (Cloud Development Kit) 是一個基於程式語言的 IaC 框架，用於合成 CloudFormation。它提供 L1 建構 (原始 CloudFormation)、L2 建構 (AWS 精選抽象) 和 L3 建構 (模式組合)。

CDK L2 網路 — ec2.Vpc

import * as ec2 from 'aws-cdk-lib/aws-ec2';

const vpc = new ec2.Vpc(this, 'MyVPC', {
  ipAddresses: ec2.IpAddresses.cidr('10.0.0.0/16'),
  maxAzs: 3,
  subnetConfiguration: [
    {
      name: 'public',
      subnetType: ec2.SubnetType.PUBLIC,
      cidrMask: 24,
    },
    {
      name: 'private-egress',
      subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
      cidrMask: 24,
    },
    {
      name: 'isolated',
      subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
      cidrMask: 28,
    },
  ],
});

這段簡潔的程式碼會合成一個完整的 CloudFormation 範本，包含 VPC、IGW、9 個子網 (3 個 AZ × 3 種類型)、出口子網在每個 AZ 的 NAT 閘道，以及每個子網類型的路由表。

SubnetType 列舉 — 標準 CDK 抽象

CDK 的 ec2.SubnetType 列舉是 ANS-C01 中最常測試的 CDK 建構：

• PUBLIC — 具有 IGW 路由，執行個體可以擁有公有 IP。
• PRIVATE_WITH_EGRESS — 沒有公有 IP，但具有用於對外連線的 NAT 閘道路由 (舊稱為 PRIVATE)。
• PRIVATE_ISOLATED — 沒有公有 IP，完全沒有網際網路路由 (舊稱為 ISOLATED)。

使用 SubnetType 讓 CDK 能自動管理 NAT 閘道放置、路由表和安全性預設設定。

高級 CDK 模式

CDK 支援 L3 模式，例如 ApplicationLoadBalancedFargateService，它在一次建構呼叫中捆綁了 ECS、ALB、安全性群組和目標群組。對於網路，典型的 L3 模式是用幾行程式碼部署一整套 VPC + TGW + Network Firewall 堆疊。

CDK + Aspects + 標籤

CDK 透過 Aspects 支援橫切關注點 (Cross-cutting concerns) — 將標籤或合規檢查套用到樹狀結構中的所有資源。常見模式：一個 Aspect 為堆疊中的每個資源新增 CostCenter 和 Owner 標籤。

CDK 與 L3 隱含安全性群組

一個 CDK 陷阱：L3 建構可能會建立隱含的安全性群組，你必須理解並配置它們。例如，ApplicationLoadBalancedFargateService 會建立 ALB SG 和 ECS 任務 SG；預設規則對生產環境可能過於寬鬆。請務必檢查合成的 CloudFormation 並在必要時覆蓋 SG 規則。

用於 AWS 網路的 Terraform

Terraform 是 HashiCorp 的多雲 IaC 工具。它使用 HCL 語法和基於狀態的執行模型。儘管 CloudFormation/CDK 是 AWS 原生的，ANS-C01 仍期望考生熟悉 Terraform 的網路資源。

核心 Terraform AWS 網路資源

• aws_vpc — VPC。
• aws_subnet — 子網。
• aws_internet_gateway + aws_nat_gateway + aws_eip — 閘道。
• aws_route_table + aws_route + aws_route_table_association — 路由。
• aws_security_group + aws_security_group_rule — 安全性群組。
• aws_vpc_endpoint — 閘道與介面端點。
• aws_ec2_transit_gateway + aws_ec2_transit_gateway_vpc_attachment — TGW。

Terraform 模組

Terraform 支援模組 (Modules) — 可重複使用的 HCL 捆綁包。社群維護的 terraform-aws-modules/vpc/aws 模組是標準的 AWS VPC 模式，抽象化了與 CDK 的 ec2.Vpc 相同的概念。

Terraform 狀態

Terraform 的有狀態執行模型 (位於 S3 中的狀態檔案配合 DynamoDB 鎖定) 與 CloudFormation 的無狀態宣告模型不同。含義：

• Terraform 需要後端 (S3 + DynamoDB) 供團隊使用。
• 狀態漂移需要透過 terraform refresh 或 terraform plan 偵測。
• 在模組之間重命名或移動資源需要 terraform state mv 或仔細的重構。

何時使用 Terraform vs CloudFormation/CDK

ANS-C01 並未強烈偏好其中之一。在以下情況下使用 Terraform：

• 多雲環境 (AWS + GCP, AWS + Azure)。
• 現有的 Terraform 專業知識和工具鏈。
• 你所依賴的模組生態系統 (例如 terraform-aws-modules/vpc)。

在以下情況下使用 CloudFormation/CDK：

• 僅限 AWS。
• 需要 StackSets 進行全組織多帳戶多區域部署。
• 原生 AWS 支援 (例如用於 CloudFormation 的 AWS Config 規則、與 Service Catalog 的整合)。

避免硬編碼值 — 可移植性反模式

硬編碼值是 IaC 無法移植的頭號原因。ANS-C01 明確測試如何辨識硬編碼反模式。

反模式：硬編碼 AMI ID

ImageId: ami-0abc1234efgh5678

這在另一個區域重新部署 (不同的 AMI ID) 或 AMI 被棄用時會失敗。修正方法：使用 SSM 動態參考：'{{resolve:ssm:/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2}}' — 始終為當前區域獲取最新的 AMI。

反模式：硬編碼可用區 (AZ) 名稱

AvailabilityZone: us-east-1a

在任何其他區域都會失敗。修正方法：!Select [0, !GetAZs ''] 返回當前區域的第一個 AZ。

反模式：硬編碼 VPC CIDR

CidrBlock: 10.0.0.0/16

如果多個堆疊需要不同的 CIDR 以避免重疊，則會失敗。修正方法：使用具有預設值且可按環境覆蓋的參數，或使用 AWS IPAM 進行集中式 CIDR 分配。

反模式：硬編碼帳戶 ID

RoleArn: arn:aws:iam::123456789012:role/MyRole

跨帳戶會失敗。修正方法：使用虛擬參數 !Sub 'arn:${AWS::Partition}:iam::${AWS::AccountId}:role/MyRole'。

反模式：硬編碼資源名稱

RoleName: MyHardcodedRoleName

在同一個帳戶重新部署時會失敗 (名稱衝突)。修正方法：省略名稱並讓 CloudFormation 產生，或使用 !Sub '${AWS::StackName}-MyRole'。

事件驅動網路自動化

事件驅動自動化使用 EventBridge 規則和 Lambda 函數來對網路事件 — 安全性群組變更、VPC 建立、BGP 工作階段狀態變更 — 做出反應，並套用修復或治理。

EventBridge + Lambda 模式

1. 來源事件：CloudTrail API 呼叫 (例如 AuthorizeSecurityGroupIngress)、Config 規則評估結果或 AWS Health 事件。
2. EventBridge 規則：比對事件模式 (例如在連接埠 22 上具有 IpRanges = 0.0.0.0/0 的安全性群組)。
3. 目標 Lambda：隨事件詳細資訊叫用，執行修復 (例如撤銷該規則)。
4. 通知：SNS 主題供安全性團隊知悉。

常見模式

• 自動撤銷 0.0.0.0/0:22 — 針對包含 IpRanges = 0.0.0.0/0 和連接埠 22 的 AuthorizeSecurityGroupIngress 的 EventBridge 規則；Lambda 撤銷規則並發送 Slack 警示。
• 為新 VPC 自動附加 Flow Logs — 針對 CreateVpc 的 EventBridge 規則；Lambda 向中央 S3 新增 Flow Log。
• 在執行個體狀態變更時自動更新 Route 53 健康檢查 — 針對 EC2 狀態變更的 EventBridge 規則；Lambda 更新健康檢查或 DNS。
• BGP 工作階段中斷告警 — Direct Connect BGP 狀態的 CloudWatch 指標；針對警示的 EventBridge 規則；Lambda 呼叫值班人員。

EventBridge 跨帳戶

對於多帳戶組織，成員帳戶中的 EventBridge 可以設定規則，將事件轉發到中央安全性帳戶的 EventBridge 匯流排。中央修復 Lambda 接著可以對來自許多帳戶的事件採取行動。

用於複雜修復的 Step Functions

對於多步驟修復 (例如：隔離執行個體 + 擷取鑑識資料 + 通知 + 建立票據)，使用 Step Functions 編排帶有重試、錯誤處理和人工審核步驟的 Lambda 叫用。

用於漂移偵測與合規性的 AWS Config

AWS Config 記錄資源配置隨時間的變更並針對規則進行評估。它是「此 VPC 配置是否正確？」以及「誰在凌晨 3 點更改了安全性群組？」等問題的 AWS 原生答案。

Config 記錄器與傳遞通道

每個帳戶的每個區域都有一個 Config 記錄器，用於擷取所選資源類型 (或所有類型) 的配置變更。變更會傳遞到 S3 儲存貯體 (通常是中央儲存貯體) 並可選傳遞到 SNS 進行通知。

Config 規則 — 受管與自訂

受管 Config 規則是 AWS 發佈的用於常見合規評估的規則：

• vpc-flow-logs-enabled — 每個 VPC 都啟用了 Flow Logs。
• restricted-ssh — 沒有 SG 允許連接埠 22 上的 0.0.0.0/0。
• vpc-sg-open-only-to-authorized-ports — SG 不允許在未授權連接埠上的 0.0.0.0/0。
• vpc-default-security-group-closed — 預設 SG 拒絕所有流量。

自訂 Config 規則是針對特定組織合規性而由 Lambda 支援的評估工具。

Config 與修復

Config 規則可以透過 SSM 自動化文件具有自動修復功能。當規則評估為 NON_COMPLIANT 時，Config 會叫用修復文件 — 例如 AWS-EnableVPCFlowLogs 為不合規的 VPC 自動附加 Flow Logs。

CloudFormation 漂移偵測

CloudFormation 具有自己的漂移偵測功能，可將已部署堆疊的實際狀態與範本的預期狀態進行比較。透過主控台或 detect-stack-drift API 偵測漂移。漂移會按資源報告。這對於捕捉繞過 IaC 的手動更改非常有用。

Config + Firewall Manager

對於全組織合規，AWS Firewall Manager 依賴於每個成員帳戶中的 AWS Config。Firewall Manager 使用 Config 發現資源 (安全性群組、WAF Web ACL、Network Firewall) 並強制執行中央宣告的策略。這是標準的全組織網路治理模式。

用於不支持類型的 CloudFormation 自訂資源

CloudFormation 中的自訂資源 (Custom resources) 是由 Lambda 支援 (或 SNS 支援) 的資源，用於填補 CloudFormation 原生資源覆蓋範圍的空白。適用於：

• CloudFormation 尚未支援的資源類型。
• 需要預部署查找 (例如「尋找符合標籤 X 的最新 AMI ID」)。
• 需要命令式邏輯的複雜設定 (例如「建立資源 A，然後根據結果有條件地建立 B」)。

Lambda 支援的自訂資源模式

自訂資源類型為 Custom::* (Custom:: 後的任何命名空間)。在堆疊建立/更新/刪除時，CloudFormation 會向 Lambda 函數發送事件。Lambda 執行命令式工作，並向 CloudFormation 預先簽署的 URL 返回成功/失敗。

Resources:
  MyCustomResource:
    Type: Custom::FindLatestAMI
    Properties:
      ServiceToken: !GetAtt MyLambda.Arn
      ImageNamePattern: amzn2-ami-hvm-*-x86_64-gp2

Lambda 接收 ImageNamePattern，呼叫 EC2 DescribeImages，返回 AMI ID。其他資源透過 !GetAtt MyCustomResource.AmiId 參考結果。

考量因素

• 自訂資源會增加複雜性和風險。儘可能偏好原生 CloudFormation。
• Lambda 必須響應所有事件 (建立、更新、刪除)，包括失敗路徑 — 不完整的實作會導致堆疊回滾卡住。
• 對於 CDK，對類似模式使用 Custom::Resource L1 或 Provider 框架。

常見陷阱回顧 — ANS-C01 中的網路基礎架構 IaC

陷阱 1：跨堆疊匯出/匯入可跨區域運作

錯誤。僅限相同帳戶、相同區域。

陷阱 2：在同區域範本中使用硬編碼的 AZ 名稱沒問題

錯誤。即使是同一個區域，AZ 名稱在不同帳戶間也可能重新對應 (例如帳戶 A 中的 us-east-1a 可能是帳戶 B 中的不同物理 AZ)。請始終使用 !GetAZs。

陷阱 3：StackSets 適用於任何多資源部署

誤導。StackSets 專門用於將同一個範本部署到多個帳戶及多個區域。對於單個帳戶中的多資源部署，應使用單個堆疊或巢狀堆疊。

陷阱 4：SSM 動態參考在參數變更時會自動更新

錯誤。在部署時解析。隨後的 SSM 變更不會重新觸發堆疊更新。

陷阱 5：CDK L3 建構不需要安全性審核

錯誤。L3 建構可能會建立隱含的安全性群組和 IAM 角色，其預設規則可能過於寬鬆。請務必檢查合成的 CloudFormation。

陷阱 6：Terraform 狀態會自動備份

錯誤。Terraform 狀態取決於你的後端配置 — 通常是 S3，你必須為其配置版本控制 + 加密 + 鎖定。

陷阱 7：每個空白處都需要自訂資源

錯誤。CloudFormation 已大幅趕上；許多以前需要自訂資源的空白現在已是原生的。在編寫自訂邏輯前請先查看最新文件。

陷阱 8：漂移偵測會自動修復

錯誤。漂移偵測僅負責偵測；你必須手動或透過單獨的自動化 (Lambda) 採取行動。

常見問答 — 網路基礎架構 IaC

Q1: 何時該使用 CloudFormation StackSets vs AWS CDK Pipelines 進行多帳戶部署？

StackSets 專為將同一個範本部署到多個帳戶和區域而設計。服務受管權限與 AWS Organizations 整合，實現無人值守擴展。最適合：每個帳戶中的基準 VPC/Flow Logs/Config；標準的全組織網路治理。CDK Pipelines 專為部署具有跨帳戶階段提升的 CDK 應用程式的 CI/CD 管道而設計。最適合：具有從開發 → 測試 → 生產的程式碼驅動演進的複雜多階段部署，且每個階段位於不同帳戶。ANS-C01 期望 StackSets 作為全組織基準網路的標準答案。CDK Pipelines 更多屬於 SAP-C02 / DevOps 領域。兩者可以共存：StackSets 用於基準，CDK Pipelines 用於基準之上的應用程式部署。

Q2: 如何在不同帳戶的堆疊間共享 VPC ID 和子網 ID？

跨堆疊匯出/匯入無法跨帳戶運作。兩種模式。模式 1 (SSM Parameter Store)：產生者堆疊將 VPC ID 寫入參數 (例如 /network/prod/vpcid)，透過參數資源策略 + KMS 金鑰共享授予跨帳戶讀取權限。其他帳戶中的取用者堆疊使用 '{{resolve:ssm:/network/prod/vpcid}}' 動態參考。模式 2 (AWS RAM)：對於支援 RAM 的資源 (透過 VPC 共享的子網、TGW、Resolver 規則、License Manager)，透過 RAM 共享。取用者直接參考共享的資源 (無需手動複製 ID)。對於 RAM 支援的資源，模式 2 是首選；當資源共享原生不支持時，模式 1 是通用答案。

Q3: 網路建構中的 CDK L1, L2, L3 有什麼區別？

L1 (CloudFormation Resource)：與 CloudFormation 資源類型 1:1 對應。ec2.CfnVpc, ec2.CfnSubnet。最繁瑣，也最靈活。當 L2 尚不支持某個功能時使用。L2 (AWS Construct)：帶有合理預設值的 AWS 精選抽象。ec2.Vpc, ec2.SecurityGroup。大多數程式碼都在此層級。使用 SubnetType 列舉、預設安全的 SG、輔助方法。L3 (Pattern Construct)：結合多個資源的高級模式。aws-ecs-patterns.ApplicationLoadBalancedFargateService, aws-rds.DatabaseCluster。當模式符合你的架構時使用；否則請組合 L2 建構。ANS-C01 期望考生對 VPC, SG, NACL, NAT 閘道的 L2 程度具備熟練度。L3 較偏向應用層，在網路考試中測試較少。

Q4: 如何在 CloudFormation 範本中避免硬編碼 AMI ID？

對 AWS 受管 AMI 使用 SSM Parameter Store 動態參考：

Parameters:
  LatestAmiId:
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2

這宣告了一個類型為 SSM 參數的 CloudFormation 參數，AWS 在堆疊建立時解析它。AWS 在每個區域發佈當前 AMI 的受管參數 — 相同的範本無需修改即可在任何區域運作。對於自訂 AMI，將 AMI ID 儲存在自訂 SSM 參數中 (例如 /myorg/baseline/ami) 並以類似方式參考。動態解析會自動獲取當前區域的正確 AMI。

Q5: 如何偵測有人手動修改了由 CloudFormation 管理的資源？

使用 CloudFormation 漂移偵測 (Drift detection)。執行 aws cloudformation detect-stack-drift --stack-name MyStack (或透過主控台)。CloudFormation 會將每個資源的實際狀態與範本預期狀態進行比較，並按資源報告漂移。若要實現持續偵測：安排一個定期呼叫 detect-stack-drift 並告警差異的 Lambda 函數。或者，使用帶有 cloudformation-stack-drift-detection-check 規則的 AWS Config 進行受管合規評估。對於自動修復，將漂移偵測與重新執行 update-stack 的 Lambda 結合使用以還原手動更改 — 但請小心：如果手動更改是緊急修復，自動還原可能會導致生產環境停機。最佳實務：偵測漂移、告警、手動決定更新範本還是還原。

Q6: 什麼時候該使用 CloudFormation 自訂資源，而不是部署後的單獨 Lambda 叫用？

當工作必須作為堆疊生命週期的一部分發生時使用自訂資源 — 在堆疊建立時建立、在更新時更新、在刪除時刪除，並具備適當的回滾支援。自訂資源是相依性圖表的一部分；其他資源可以參考其輸出。當工作是鬆散耦合且生命週期獨立時，使用單獨的 Lambda 叫用 (手動或透過 EventBridge) — 部署後的配置、定期修復、事件觸發的操作。自訂資源功能更強但也更複雜；單獨的 Lambda 較簡單但需要額外的編排。典型 ANS-C01 範例：用於「尋找符合標籤 X 的最新 AMI」的自訂資源 (必須在堆疊建立時發生)；用於「自動撤銷 0.0.0.0/0:22 SG 規則」的單獨 Lambda (事件驅動，持續進行)。

Q7: 如何使用 AWS Config 強制要求每個 VPC 都啟用了 Flow Logs？

在每個帳戶和區域啟用 AWS Config (通常透過 StackSets)。新增受管 Config 規則 vpc-flow-logs-enabled 以評估每個 VPC。規則會按 VPC 報告 COMPLIANT 或 NON_COMPLIANT。若要實現自動修復，請將 SSM 自動化文件 AWS-EnableVPCFlowLogs 附加為修復操作 — Config 將為不合規的 VPC 叫用它。結合 EventBridge 針對 compliance change 事件的規則，當出現 NON_COMPLIANT 結果時發出警示。對於全組織強制執行，使用 AWS Firewall Manager 在整個組織部署此 Config 規則 + 修復操作，並為新帳戶自動部署。結果：全組織的每個 VPC 都會自動獲得 Flow Logs，並帶有持續的合規驗證。

Q8: 在 IaC 中處理環境差異 (dev/staging/prod) 的正確方法是什麼？

模式 1：帶有環境輸入的參數 — 單個範本配合 Environment 參數 (dev, staging, prod)；使用 Conditions 和 Mappings 改變行為。精簡，但參數過多會變得難以管理。模式 2：每個環境單獨的堆疊，共享範本並使用按環境的參數檔案。乾淨的分離，但範本更改會同時傳播到所有環境。模式 3：具有環境特定應用程式建構的 CDK — 程式設計式區分：new MyStack(app, 'Dev', { env: dev }); new MyStack(app, 'Prod', { env: prod, prodOnly: true })。最靈活，因為可以使用程式設計邏輯。模式 4：每個環境單獨的範本 — 完全解耦，但代價是重複。ANS-C01 期望針對正式工作負載使用模式 2 或模式 3。避免在單個堆疊中混合環境 — 意外更新的爆炸半徑太大。

Q9: 如何將工作負載帳戶的 TGW 連接部署到從網路帳戶共享的 TGW？

架構：網路帳戶建立 TGW，透過 RAM 與工作負載帳戶共享。工作負載帳戶部署建立參考共享 TGW ID 的 AWS::EC2::TransitGatewayAttachment 的 CloudFormation。工作負載的 CloudFormation 範本需要 TGW ID — 將其作為參數傳遞，或從 SSM 讀取 (網路帳戶將 TGW ID 寫入共享的 SSM 參數)。對於服務受管 StackSets：網路帳戶建立包含 TGW 的父堆疊；成員帳戶具有子堆疊，其中的連接資源透過 SSM 或 RAM 參考父堆疊的輸出。在 TGW 上設定自動接受 (由網路帳戶設定)，可避免每個連接都需要手動核准。結果：工作負載帳戶部署一個堆疊，自動建立 TGW 連線，同時網路團隊保留對 TGW 路由表的集中控制。

Q10: 如何將事件驅動修復與我的 IaC 基準整合？

分層方法。第 1 層 (基準)：StackSets 向組織中的每個帳戶/區域部署基準資源 (VPC Flow Logs、基準 NACL、基準 SG、Config 規則)。第 2 層 (偵測)：Config 規則持續評估合規性；CloudWatch 警示偵測異常 (例如 NAT 閘道丟包)；CloudTrail 擷取所有 API 呼叫。第 3 層 (事件)：EventBridge 規則比對可疑事件 (例如具有 0.0.0.0/0 規則的 CreateSecurityGroup)。第 4 層 (行動)：Lambda 函數進行修復 (撤銷規則、隔離執行個體、擷取鑑識快照)。第 5 層 (通知)：向安全性團隊發送 SNS，可選 Slack 整合。ANS-C01 的期望：IaC 宣告穩定狀態 (第 1 層) 和偵測規則 (第 2-3 層)；事件驅動的 Lambda 處理偏離 (第 4 層)；人員獲得警示 (第 5 層)。這結合成一個自我修復的網路治理平台。

進階閱讀

• AWS CloudFormation 使用者指南
• CloudFormation StackSets
• CloudFormation 跨堆疊參考
• AWS CDK v2 開發者指南
• AWS CDK ec2.Vpc 建構
• Terraform AWS 提供者 — aws_vpc
• CloudFormation 動態參考
• AWS Config 受管規則
• AWS ANS-C01 考試指南

IaC 是自動化平面；ANS-C01 的下一層是 IaC 實際部署的 VPC 架構與 CIDR 設計；IaC 編排的多帳戶多區域網狀結構 Transit Gateway 路由；IaC 必須透過 RAM 共享的 Route 53 Resolver 規則；以及 IaC 必須自動接線的網路監控與成本優化關注點。

• VPC 架構、CIDR 設計與子網劃分
• Transit Gateway — 路由表、連接與 Connect
• Route 53 Resolver — 混合 DNS 與有條件轉發
• 網路監控、疑難排解與成本優化