遷移目標架構：運算、儲存與資料庫選型

SAP-C02 中的遷移目標基礎架構

遷移目標基礎架構（migration target infrastructure）是遷移前的 Landing Zone，用來承接所有從地端資料中心搬至 AWS 的工作負載，不論是直接搬移（lift）、重新平台（replatform）或重構（refactor）。在第一台伺服器、資料庫或檔案共享離開機房之前，目標環境就必須已以正式上線的狀態存在：帳號已佈建、guardrails 已套用、混合連線已就緒、身份識別已聯盟、可觀測性已集中、加密預設已生效、成本可視性已接通。SAP-C02 考試幾乎不問「什麼是 landing zone？」，而是問「一家擁有 3 個資料中心、5 個事業單位的企業必須在 60 天內開始遷移，最少需要哪些遷移目標基礎架構決策才能避免日後大規模翻修？」

本主題位於 Domain 4（加速工作負載遷移與現代化，任務說明 4.3），但大量引用 Domain 1 治理與 Domain 2 安全基礎的知識。遷移目標基礎架構的範圍涵蓋：AWS Control Tower、Account Factory、Account Factory Customization、Landing Zone Accelerator (LZA)、Customizations for Control Tower (CfCT)、service control policies、tag policies、backup policies、AWS Organizations OUs、AWS Transit Gateway、AWS Direct Connect、Site-to-Site VPN、Route 53 Resolver 入站與出站端點、搭載 AWS Network Firewall 的集中式檢查 VPC、IAM Identity Center、AD Connector、Trusted Identity Propagation、組織層級 CloudTrail、Amazon Security Lake、GuardDuty 委派管理、AWS Config aggregator、AWS KMS 各 OU 金鑰政策、S3 Bucket Keys、tag policies、AWS Budgets，以及成本分配報告。在 Pro 深度掌握遷移目標基礎架構，代表你要清楚知道哪些必須在第一波遷移開始前就位、哪些可以在第二波到位、哪些則真的是可選的。

本筆記假設你已熟悉 Associate 等級的多帳號基礎（什麼是 OU、什麼是成員帳號、sts:AssumeRole 做什麼）。所有內容皆以 Professional 等級撰寫——包括如何為截斷期頻寬估算 Direct Connect 容量、如何在 Account Factory Customization 與 LZA 之間做選擇、何時 Trusted Identity Propagation 優於傳統 SAML 聯盟，以及如何建立 guardrail 基礎不把一年內要搬移 300 個工作負載的遷移團隊卡死。

白話文解釋 Migration Target Infrastructure

遷移目標基礎架構有許多環環相扣的組件。以下三個類比可以讓 landing zone、連線與身份識別在深入技術細節之前先在腦中紮根。

類比一：新辦公大樓的入住前準備

想像你的公司已簽下一棟 30 層辦公大樓的租約，準備在 60 天內將 5 個事業單位從 3 棟舊辦公室搬進來。你不會在第一天就開始搬桌子。首先，大樓管理員（AWS Control Tower）要建好大廳、電梯與保全台（管理帳號、log archive 帳號、audit 帳號）。然後場地工程團隊（Account Factory + Landing Zone Accelerator）為每一層（成員帳號）佈置標準格局：網路插孔接好（VPC）、火警系統就緒（Config 規則）、每扇門口裝好感應門禁（IAM Identity Center）、閉路電視錄影集中到中央保險庫（組織層級 CloudTrail），以及每個天花板的煙霧偵測器（GuardDuty）。從舊辦公室拉來的主幹光纖（Direct Connect）也已通路測試完畢。只有在這一切都運作正常之後，才排定實際的家具搬運日（MGN 複製、DMS 遷移）。若先搬桌子、再去接火警系統，你就會花半年在已有員工辦公的格間裡翻裝撒水頭——這正是 SAP-C02 情境要懲罰的反模式。

類比二：醫院新病棟啟用

遷移目標基礎架構就像一家醫院準備接收從三家老舊院區轉入的 200 位病患，必須先把新病棟蓋好。在第一位病患入住前，你需要：隔離病房已備妥（Prod / Non-Prod / Sandbox 各自的 OU）、藥局已備好藥品（共用服務帳號，裡面有 AMI、基礎映像與 KMS 金鑰）、符合 HIPAA 的病歷室（啟用 S3 Object Lock 的 log archive 帳號）、護理站已連網（Transit Gateway hub 搭配各部門以 route table 強制隔離的 VLAN）、專用救護車停車灣（依截斷期頻寬估算的 Direct Connect 線路）、全棟通用的員工識別證（IAM Identity Center 搭配 AD Connector 聯盟醫院的 Active Directory），以及一個中央護理站儀表板（AWS Config aggregator + Security Hub），能一次看清每個房間的狀態。主治醫師（資安委派管理員）不必走進每位病患的病房，就能看到整棟大樓的狀況。只有在新病棟通過驗收（guardrail 基礎套用完畢且無偏差）後，才能宣告可以開始轉診。

類比三：高鐵新站開通前的準備

遷移目標基礎架構就像台灣高鐵要新開一座車站，所有從三個舊車站分流出來的列車必須先等新站完工才能停靠。路網總規劃圖（AWS Organizations + OU 樹）決定哪些月台服務哪些事業單位。進站安檢閘口（SCPs + guardrails）在每節車廂進入 AWS 地界前一一核查——未貼標籤的行李不放行、禁止區域的物品不放行、關閉攝影機的行為直接攔下。連接內地各倉儲的鐵路與貨車路線（Transit Gateway + Direct Connect）必須在第一班列車進站前全線通車，否則旅客只能在月台上等待。站務管理室（IAM Identity Center + Trusted Identity Propagation）核發一張全站通行的員工證，並把站務員的身份從進站閘口一路傳遞到他實際操作的那個貨盤（Redshift 列層級、S3 Access Grants）。中控調度室（CloudTrail + GuardDuty + Security Lake）在一個螢幕上監視所有月台的每列列車動態。油料補給站（KMS）儲存每個月台封存貨物時使用的金鑰。缺少其中任何一項，新站就無法開始通車——而在列車已進站運行後再補裝這些設施，是讓高鐵停駛數週的做法。

60 天 Landing Zone 情境

SAP-C02 遷移目標基礎架構考題幾乎都把限制條件埋在情境描述中。我們用一個標準範例作為本筆記後續內容的錨點，這個範例同時呼應真實考題情境與真實客戶專案。

情境。 一家製造業企業在 3 個地端資料中心（美東主要 co-location 機房、歐西區域 DR、亞太區域 edge）運作，旗下有 5 個事業單位（Corporate IT、Manufacturing、Supply Chain、R&D、Customer Support），各有自己的工程團隊、非正式環境與正式工作負載。CIO 批准了一個 3 年遷移計畫，並要求在 60 天內建立正式上線的 landing zone，使低風險工作負載（Corporate IT 企業內網、開發環境）能立即開始遷移第一波，同時第二、三波仍在規劃中。Landing zone 必須滿足：

• 從第一天起符合法規工作負載合規要求（SOC 2、ISO 27001）。
• 所有帳號強制要求靜態與傳輸中加密。
• 為企業 Active Directory 中的 2,400 名工程師提供單一登入體驗。
• 12 人資安團隊可跨帳號集中可視化，但不得給予管理帳號存取權。
• 零「神秘帳單」——每一分錢都能追溯到事業單位與環境。
• 三個資料中心的混合連線，第一波截斷期頻寬需求約為 2 Gbps 持續流量。

Landing Zone 設計 — Control Tower Account Factory 與 Landing Zone Accelerator

第一個決策是選擇哪個 landing zone 工具。AWS 提供兩條受支援的路徑，且兩者並不互斥——大多數企業遷移都會同時採用兩者。

AWS Control Tower — 具主觀意見的基礎

AWS Control Tower 是受管 landing zone 服務。約一小時內，它能佈建 AWS Organizations 結構、在 Security OU 中建立 Log Archive 與 Audit 帳號、啟用 IAM Identity Center、開啟組織層級 CloudTrail、部署 AWS Config aggregator，並對每個 OU 套用一組強制性 guardrails。它的主要介面是 Account Factory，這是一條自助式帳號佈建流水線，只要填寫一份表單並通過審核，就能建立新的成員帳號、將其掛入正確的 OU、套用該 OU 的 guardrails，並在中央 identity provider 中完成登記。Control Tower 幾乎是所有 SAP-C02 遷移情境的正確起點，因為它能在一個下午消除數週的基礎 YAML 工作，而且考試的標準正確答案也以它為前提。

Landing Zone Accelerator on AWS (LZA) — 自訂化層

Landing Zone Accelerator on AWS 是 AWS 發布的解決方案（由 AWS Solutions 維護），它在 Control Tower 之上疊加企業規模的自訂化：具主觀意見的多區域 CloudTrail、詳細的 Config 規則、預建集中日誌、集中式 Network Firewall 檢查 VPC、AWS Backup vault 政策、與常見角色對齊的 IAM permission sets，以及——尤其重要的——以程式碼表達的設定檔（accounts.yaml、organizational-units.yaml、network.yaml、security.yaml 等），這些設定檔驅動一條 CI/CD 流水線，使 landing zone 的變更可像應用程式程式碼一樣受版本控制與同儕審查。LZA 特別適合法規遵循要求嚴格的產業（醫療、金融、政府），因為它內建了與 CMMC、HIPAA、NIST 800-53 及 PCI DSS 對齊的設定基準。

Customizations for Control Tower (CfCT) — 中間路線

CfCT 是較早期的官方自訂化框架：一條 CodePipeline，在 Account Factory 佈建新帳號時套用 CloudFormation StackSets 與 SCPs。CfCT 仍完整受支援，是考題問到「如何在 Control Tower 上新增自訂化而不採用完整加速器？」時的正確答案。

60 天情境的決策矩陣

對於本標準情境，60 天內達到正式上線的路徑是：Control Tower + Account Factory + Landing Zone Accelerator。Control Tower 讓你在一個下午取得經過驗證的基礎，Account Factory 讓事業單位在兩週內完成自助式帳號佈建，LZA 則提供合規對齊的自訂化（組織層級加密、Network Firewall 檢查、Backup 政策），若靠自己從頭寫，一個五人團隊需要三個月。若團隊有豐富的 CloudFormation 技能但不想採用 LZA 的主觀預設值，CfCT 是替代選項。

帳號佈建策略 — 依工作負載、依環境、依事業單位

一旦 Control Tower 與 Account Factory 就緒，下一個設計決策是建立多少帳號、依據哪個維度劃分。這是 SAP-C02 遷移目標基礎架構考題中出現頻率最高的單一主題。

三種標準佈建維度

• 依工作負載：每個應用程式一個帳號（例如 erp-prod、ecommerce-prod）。爆炸半徑隔離與配額分離最佳，但帳號數量急速膨脹。
• 依環境：同一事業單位中每個生命週期階段一個帳號（例如 manufacturing-dev、manufacturing-test、manufacturing-prod）。管理較簡單，但可能混合了需要獨立配額的工作負載。
• 依事業單位：每個事業單位一個帳號，環境折疊進 VPC 或命名空間中。最簡單，但隔離性最弱。

真實的遷移 landing zone 三者皆用。AWS 白皮書「Organizing Your AWS Environment Using Multiple Accounts」推薦矩陣方式：至少採用事業單位 × 環境的組合，對於受法規約束、關乎核心營收或有獨立配額需求的工作負載，再導入依工作負載的帳號。

對於 5 個事業單位 × 3 個環境（dev、test、prod）的 60 天情境，你會落在 15 個事業單位帳號，加上共用帳號（log archive、audit、network、shared services、security tooling、backup、CI/CD），第一天的帳號總數約為 22 個。第二、三波遷移為受法規約束的應用程式新增依工作負載的帳號，12 個月後目標落在 50–80 個帳號——正是 Control Tower 與 LZA 最佳化的規模。

共用服務帳號

除了事業單位帳號，你的 landing zone 還需要幾個共用服務帳號來承載跨帳號基礎設施：

• Network 帳號 — 擁有 Transit Gateway、透過 AWS RAM 共享的集中式 VPCs、Route 53 Resolver 規則、Network Firewall 政策、Direct Connect gateways。
• Shared services 帳號 — Golden AMIs、ECR 中的基礎容器映像、集中式 CI/CD 工具、Systems Manager 清單、AD Connector（或 AWS Managed Microsoft AD）。
• Security tooling 帳號 — GuardDuty、Security Hub、Inspector、Macie、Config aggregator、IAM Access Analyzer 的委派管理員。
• Log archive 帳號 — 存放 CloudTrail 與 Config 的不可變 S3 儲存桶（Object Lock、MFA delete、跨帳號儲存桶政策）。
• Backup 帳號 — 用於跨帳號復原點與 vault lock（WORM）的中央 AWS Backup vault。

基礎 Guardrails — 強制性、強烈建議、選用，以及 SCP 基礎

Guardrails（在現代 Control Tower 中正式稱為 controls）是 landing zone 套用到每個帳號的可強制執行政策。SAP-C02 測試你為正確的合規需求選擇正確控制類型的能力。

四種控制類別

• 預防性控制（Preventive controls） — 以 SCPs 為底層，在不合規的 API 呼叫發生前即予以阻擋（例如「對組織 trail 拒絕 cloudtrail:StopLogging」）。在 CloudTrail 中以 errorCode 中的 DENY 呈現。
• 偵測性控制（Detective controls） — 以 AWS Config 規則為底層，事後觀察狀態並將資源標記為不合規（例如「S3 儲存桶未啟用預設加密」）。
• 主動性控制（Proactive controls） — 以 CloudFormation Hooks 為底層，在部署前檢查 IaC 範本，在佈建時攔截不合規的 stack。
• 治理意圖類別 — 與上述正交，Control Tower 也將每個控制標記為 Mandatory（不得停用，例如「禁止對 log archive 公開寫入」）、Strongly Recommended（預設啟用但可選擇退出，例如「為 root 使用者啟用 MFA」）或 Elective（選擇性啟用，例如「禁止 S3 儲存桶公開可讀」）。

60 天情境的基礎 guardrail 集合

第一天，landing zone 應在 OU 樹中套用約 30–40 個 guardrails：

• Root OU：全部 Mandatory 控制（不被竄改的 Log Archive、不被竄改的 Audit CloudTrail、兩個資安帳號上無公開 S3）。
• Security OU：額外的 Mandatory 控制，保護 Audit 與 Log Archive 帳號免受破壞性操作。
• Workloads OU：Strongly Recommended 偵測性控制，涵蓋靜態加密、root 的 MFA、CloudTrail 已啟用。
• Sandbox OU：額外的預防性 SCP，拒絕正式環境服務（RDS、EKS、Aurora），防止昂貴的意外。
• Suspended OU：對排定關閉的帳號套用全拒絕 SCP。

在上層疊加自訂 SCPs

在 Control Tower 控制之上，LZA 或 CfCT 通常會套用自訂 SCPs：

• DenyRegionsExceptApproved — 初期只允許 us-east-1、us-west-2、eu-west-1（防止意外的多區域蔓延）。
• DenyRootUserActions — 封鎖由 root 使用者執行的 IAM 動作。
• DenyDisableSecurityServices — 拒絕 guardduty:Delete*、securityhub:Disable*、config:Delete*、macie:Disable*。
• RequireIMDSv2 — 拒絕不使用 IMDSv2 的 EC2 啟動。
• DenyLeaveOrganizations — 封鎖成員帳號執行 organizations:LeaveOrganization。
• RequireEncryptedEBS — 拒絕不帶加密 EBS 的 RunInstances。
• RequireTLSForS3 — 拒絕未帶 aws:SecureTransport=true 的 S3 PutObject。

遷移混合連線 — Direct Connect、VPN、Transit Gateway

沒有可用的混合連線，遷移目標基礎架構從一開始就是死路。連線層是區分可實際使用的 landing zone 與只有投影片看起來漂亮的 landing zone 的關鍵。

為截斷期頻寬估算 Direct Connect 容量

60 天情境第一波截斷期需要約 2 Gbps 持續頻寬，用以在完整基礎複製透過 Snowball Edge 進行的同時，複製 15 台伺服器的穩態差異。AWS Direct Connect 以每埠 1 Gbps、10 Gbps 或 100 Gbps 的專用光纖提供服務。有兩個原則適用：

• 依截斷期峰值加上穩態估算容量，而非依平均值。MGN 最終同步與 DMS 切換時，截斷期流量會出現尖峰。
• 預留 BGP 故障切換餘裕。若你規劃跨兩條 Direct Connect 線路的主動-主動架構，每條線路必須能單獨承載 100% 流量，因為另一條可能故障——因此 10 Gbps 的實際需求需要兩個 10 Gbps 埠。

AWS Direct Connect 韌性建議定義四個等級：

• Development（99.9% SLA） — 單一 Direct Connect 連線加上 Site-to-Site VPN 備援。適用於波浪零，但不適用於正式截斷期。
• High Resilience（99.99% SLA） — 兩個 Direct Connect 連線，連接到不同 Direct Connect 位置的不同設備。正式遷移流量的最低要求。
• Maximum Resilience（99.999% SLA） — 個別連線在多個 Direct Connect 位置的獨立設備上終止，若適用還要跨 AWS 區域。
• Maximum Resilience with SiteLink — SiteLink 讓地端到地端的流量透過 AWS 骨幹傳輸，在三個資料中心於遷移期間需要互相通訊時非常有用。

對於本情境，正確答案是：從美東主要資料中心到兩個 Direct Connect 位置的兩條 10 Gbps Direct Connect 連線，加上一對 Site-to-Site VPN 隧道作為緊急回退路徑，整體達到 99.99% 等級，同時提供約 10 Gbps 的可用截斷期頻寬餘裕。

Transit Gateway 作為遷移樞紐

你不會讓每條 Direct Connect 線路直接指向每個 VPC——而是讓它們指向 network 帳號中的 Transit Gateway。TGW 成為遷移目標基礎架構的樞紐：每個事業單位環境的 spoke VPCs 接入、Direct Connect Gateway 接入、Site-to-Site VPN 接入、跨區域 peering 接入。TGW route tables 強制執行隔離——Dev spokes 無法觸達 Prod spokes，即使它們共享同一個樞紐。這個模式在我們的 Transit Gateway 與混合網路 主題中有深入介紹；在此最重要的一點是，TGW 必須在第一波遷移前存在於 network 帳號，且透過 AWS RAM 的跨帳號共享已設定完畢。

Resolver 端點處理 DNS

混合 DNS 是遷移專案中最容易被忽視的殺手。地端應用程式需要解析 AWS 私有主機名稱（*.vpce.amazonaws.com、*.rds.amazonaws.com），而 AWS 工作負載在遷移切入期間需要解析地端主機名稱（corp.internal、ad.corp.internal）。解決方案是在 network 帳號中部署 Route 53 Resolver 端點：

• 入站端點（Inbound endpoints） — 每個 AZ 一個 ENI，部署在 VPC 中，接受來自地端 Directory Services 的 DNS 查詢，解析 AWS 私有託管區域。透過 VPC 關聯或 resolver rule RAM 共享，分享給其他帳號的 VPCs。
• 出站端點（Outbound endpoints） — 每個 AZ 一個 ENI，根據 Resolver rules 將 AWS 的查詢轉發到地端 DNS（corp.internal -> 10.1.1.53）。

對於 60 天情境，network 帳號在 landing zone 將承載工作負載的每個區域都需要各一組入站 + 出站端點，並透過 RAM 將規則分享至整個組織。

集中式檢查 VPC

企業等級的遷移 landing zone 會將所有東西向與南北向流量導過 network 帳號中的集中式檢查 VPC。這個 VPC 內含 AWS Network Firewall（或透過 Gateway Load Balancer 的第三方防火牆叢集），TGW route tables 將所有 spoke 間流量與出口流量重導至此。LZA 預設部署這個模式；自行建置需要數週的路由表工作。

身份識別基礎 — IAM Identity Center、AD Connector、Trusted Identity Propagation

遷移目標基礎架構的成敗取決於身份識別。若工程師在第一天無法 SSO 進新帳號，遷移團隊就會回頭使用各帳號獨立的 IAM 使用者、硬編碼 access keys，以及電子表格式的權限管理——三週內累積十年的技術債。

IAM Identity Center 作為組織層級 SSO 平面

AWS IAM Identity Center（前身為 AWS SSO）是整個 AWS 組織的中央身份識別平面。作為 AWS Organizations 整合服務，它發布 permission sets（可重用的 IAM 角色範本），並將其指定給群組 × 帳號的組合。工程師在 https://d-1234567890.awsapps.com/start 用企業帳號登入，看到的主控台只顯示他們有存取權的帳號與 permission sets。每次登入都記錄在 Identity Center 委派區域的 CloudTrail 中。

對於擁有 2,400 名工程師的 60 天情境，Identity Center 是不可或缺的。使用各帳號獨立的 IAM 使用者，第一天就需要 22 × 2,400 = 52,800 個使用者物件，且數量會無限制增長。

身份識別來源 — AD Connector 對比 Managed AD 對比外部 IdP

Identity Center 支援三種身份識別來源：

• Identity Center 目錄（內建）— 適合小型組織，不從企業 AD 同步。對於 2,400 人的企業是錯誤選擇。
• Active Directory — AWS Managed Microsoft AD（在 AWS 中完全受管）或 AD Connector（輕量代理，將 LDAP 與 Kerberos 轉發到現有的地端 AD）。對於本情境，AD Connector 是遷移的經典答案：它重用已擁有 2,400 名使用者、群組與密碼政策的企業 AD，工程師可以用與登入 email 相同的帳號認證登入。
• 透過 SAML 2.0 的外部 IdP — Okta、Azure AD / Entra ID、PingFederate。當企業身份識別不在 AD 中時使用。現代企業越來越多選擇這條路，但本情境指定「企業 Active Directory」，因此 AD Connector 勝出。

Trusted Identity Propagation — Pro 等級功能

Trusted Identity Propagation (TIP) 是 2023 年 Identity Center 推出的能力，可將實際的人類使用者身份從 Identity Center 透過 AWS 服務一路傳遞到資料層授權。工程師以 alice@corp 登入 → Identity Center 核發 token → token 流經 QuickSight、Redshift、S3 Access Grants、EMR 和 Lake Formation → 每個服務為特定的 alice@corp 強制執行列層級 / 欄層級 / 前綴層級授權，而非為「所有 BI 分析師」使用的共用角色授權。在 TIP 出現之前，每個服務看到的都是「全體 BI 分析師」的同一個 IAM 角色，必須透過檢查 SAML 屬性或 session tags 來近似使用者身份。

對於遷移目標基礎架構，當目標架構包含共享資料平台時（本情境的 R&D 事業單位將遷移一個資料湖），TIP 至關重要。沒有 TIP，你最終要為每個服務撰寫繁瑣的 ABAC 政策；有了 TIP，Lake Formation 與 Redshift 可原生識別 AD 群組成員資格。

可觀測性基礎 — CloudTrail、Security Lake、GuardDuty、Config Aggregator

可觀測性是身份識別之後第二大的第一天投資。每個帳號必須在第一天——而非事後補——就將其日誌、發現項目與設定狀態送進中央 security tooling 帳號及 log archive。

組織層級 CloudTrail

Control Tower 預設建立一條組織 trail：管理帳號中的一個 CloudTrail，記錄每個成員帳號的管理事件，並傳遞到 log archive 帳號中的 S3 儲存桶。在此之上，LZA 為法規遵循工作負載帳號新增資料事件（S3 物件層級、Lambda 呼叫、DynamoDB 項目層級），以及用於以 SQL 查詢歷史事件的 CloudTrail Lake。

對於本情境，基準線是：組織 trail、log archive 儲存桶上的資料事件、保留 365 天的 CloudTrail Lake 事件資料存放區。

Amazon Security Lake 用於正規化日誌

Amazon Security Lake 從 AWS 服務（CloudTrail、VPC Flow Logs、Route 53 Resolver、Security Hub findings、EKS Audit Logs）及自訂來源擷取日誌，將其正規化為 OCSF（Open Cybersecurity Schema Framework），並以分區 Parquet 格式儲存在 security tooling 帳號的 S3 中。訂閱者（如 Splunk、Datadog 等 SIEM 或自訂 Athena 查詢）消費正規化資料，無需每個工具各自解析原始日誌。

對於本情境，Security Lake 是第一天的正確答案，因為 12 人資安團隊需要一個可統一查詢的介面，而且之後至少會有一個第三方 SIEM 訂閱。

GuardDuty 搭配委派管理員

GuardDuty 透過 Organizations 整合在整個組織啟用，以 security tooling 帳號作為委派管理員。一旦完成委派，資安團隊即可在所有現有和未來的成員帳號中啟用 GuardDuty（及其保護方案：S3、EKS、Malware、RDS、Lambda），無需接觸管理帳號。Findings 匯聚在委派管理員中並路由至 Security Hub。

AWS Config aggregator

AWS Config 必須在每個帳號的每個區域中執行，以評估對 Config 規則（包含 Control Tower 的偵測性 guardrails）的合規性。每個帳號的 Config 資料傳送到 log archive 儲存桶。security tooling 帳號中的 Config aggregator 從每個帳號 × 區域拉取狀態到一個可搜尋的視圖，讓資安團隊能用單一查詢回答「哪些帳號有未加密的 EBS？」

加密基礎 — KMS 各 OU 政策與 S3 Bucket Keys

靜態加密事前套用容易，事後翻裝痛苦。現有未加密的 RDS 需要快照與還原遷移；現有 S3 儲存桶需要重新上傳物件。Landing zone 必須在工作負載落地之前強制執行加密預設值。

KMS 金鑰組織架構

Landing zone 加密設計通常遵循三個層次：

• 各帳號 KMS 金鑰，用於帳號範圍的服務（EBS 預設加密、RDS、Secrets Manager、Parameter Store）。由 LZA 在帳號佈建時建立，金鑰政策限制使用者為擁有帳號。
• 各 OU 共享金鑰，用於跨帳號工作流程（例如與 backup 帳號共享的備份加密金鑰、與 log archive 共享的日誌加密金鑰）。金鑰政策使用 aws:PrincipalOrgID 條件將存取限制在組織內。
• 各服務 KMS 金鑰，位於 security tooling 帳號，用於集中加密 Security Lake、Config 匯聚，以及 Security Hub findings。

S3 Bucket Keys 降低 KMS 成本

每次帶有 SSE-KMS 的 S3 PUT 都會產生一個 KMS API 呼叫（每 10,000 次 $0.03）。高流量的日誌儲存桶（CloudTrail、VPC Flow Logs）每天可能產生數百萬次 PUT——光是加密開銷就可能帶來每月五位數美金的 KMS 帳單。S3 Bucket Keys 透過在時間窗口內生成一個中間儲存桶層級的資料金鑰來加密物件，可將 KMS 請求減少多達 99%。在 landing zone 的每個高流量儲存桶上啟用 S3 Bucket Keys——這是一個沒有任何缺點的單行設定變更。

透過 SCP 強制加密

Landing zone 透過掛載在 root 的預防性 SCPs 強制執行加密：

• 拒絕不帶 s3:x-amz-server-side-encryption 的 s3:PutObject。
• 拒絕不帶加密 EBS 的 ec2:RunInstances。
• 拒絕不帶 StorageEncrypted=true 的 rds:CreateDBInstance。
• 拒絕不帶 SSE-KMS 規格的 dynamodb:CreateTable。

再搭配偵測性 Config 規則補漏（雖然只要 SCPs 寫得正確，應該沒有東西能溜過去）。

成本與標籤基礎 — Tag Policies、Budgets、成本分配

Landing zone 的最後一個支柱是財務管理。如果遷移完成後 CFO 無法回答「Manufacturing 事業單位上季度花了多少？」，不管資安姿態多乾淨，這個 landing zone 都是失敗的。

由 Organizations 強制執行的 Tag Policies

Tag policies（AWS Organizations 中的政策類型，功能類似 SCPs 但用於標籤）定義了允許的標籤金鑰、每個金鑰允許的標籤值，以及繼承關係。Landing zone 應在第一天就定義一組強制標籤：

• cost-center（每個事業單位的固定清單之一）
• environment（dev、test、prod）
• workload（應用程式識別碼）
• data-classification（public、internal、confidential、restricted）
• owner-email（企業電子郵件地址）

Tag policies 不會阻擋未加標籤的資源（那需要 SCP）。Landing zone 因此將 tag policies 與一個拒絕沒有強制標籤的 ec2:RunInstances 和 rds:Create* 的 SCP 配對使用，並搭配 Config 規則標記事後發生的偏差。

在整個組織啟用成本分配標籤

在管理帳號的帳務主控台中，每個驅動分攤計費的標籤金鑰都必須在 Cost Explorer 或 Cost and Usage Report 中顯示之前被啟用為成本分配標籤。漏掉這個步驟是「我們標記了所有東西但仍然無法按事業單位分切帳單」最常見的原因——在 SAP-C02 中這是一個固定陷阱。

AWS Budgets 搭配動作與 SNS 警報

每個事業單位帳號都會收到一個依預期支出設定的每月 AWS Budget，在達到 50%、80% 和 100% 時透過 SNS 通知該事業單位的 FinOps 負責人。正式環境帳號另外新增一個 Budget Action，在達到 120% 時自動套用一個限制性 SCP（封鎖新資源建立但不中斷正在執行的工作負載），防止因失控的 Lambda 或外洩的 access key 造成的帳單暴衝。

Cost and Usage Report 送至 log archive

管理帳號以 Parquet 格式將 Cost and Usage Report (CUR) 寫入 log archive 儲存桶，以日期分區。security/finance tooling 帳號中的 Athena + QuickSight 接著建置 FinOps 儀表板——依事業單位、依環境、依工作負載、依服務分切的成本——全部源自你在第一天強制執行的 tag policies。

60 天 Landing Zone 建置計畫

對於本情境，以下是 SAP-C02 期望你能複述的逐週計畫。

第 1–2 週：基礎

• 第 1–2 天：在管理帳號部署 AWS Control Tower。驗證 log archive 與 audit 帳號。
• 第 3–4 天：透過 CloudFormation 部署 Landing Zone Accelerator，將初始設定 YAML 提交至 CodeCommit，執行流水線。
• 第 5–10 天：設計 OU 樹（Security、Infrastructure、Workloads → Prod/Non-Prod、Sandbox、Suspended），與事業單位負責人審核。
• 第 10–14 天：佈建共用服務帳號（network、shared services、security tooling、backup、CI/CD）。將 GuardDuty、Security Hub、Config aggregator、Macie、IAM Access Analyzer 委派到 security tooling 帳號。

第 3–4 週：連線與身份識別

• 第 15–17 天：從美東資料中心到兩個 DX 位置佈建兩條 10 Gbps Direct Connect 連線。建立 Site-to-Site VPN 備援。
• 第 18–20 天：在 network 帳號部署 Transit Gateway，接入 Direct Connect Gateway，接入 VPN，設定 route tables。
• 第 21–23 天：在 network 帳號佈建 Route 53 Resolver 入站 + 出站端點，為 corp.internal 建立轉發規則，透過 RAM 共享。
• 第 24–26 天：將 IAM Identity Center 與指向地端 AD 的 AD Connector 整合（DNS 已透過 Resolver 正常運作）。測試 SSO 登入。
• 第 27–30 天：定義 permission sets（Admin、PowerUser、ReadOnly、BillingReadOnly、SecurityAuditor、NetworkAdmin）。指定到 AD 群組。為即將到來的資料湖工作負載啟用 Trusted Identity Propagation。

第 5–6 週：資安、加密、成本

• 第 31–35 天：搭配 AWS Network Firewall 部署集中式檢查 VPC。更新 TGW route tables，將東西向與出口流量導過檢查。
• 第 36–40 天：啟用帶有資料事件的組織層級 CloudTrail、CloudTrail Lake、Security Lake。在所有帳號啟用 GuardDuty（所有保護方案）、Security Hub、Inspector、Macie。
• 第 41–44 天：定義 KMS 金鑰層次結構。透過 SCP 在帳號間啟用 EBS 預設加密、S3 預設加密、RDS 強制 SSL。在日誌儲存桶開啟 S3 Bucket Keys。
• 第 45–48 天：定義 tag policies。套用強制標籤 SCPs。啟用成本分配標籤。設定帶有動作的 AWS Budgets。

第 7–8 週：強化與波浪零

• 第 49–52 天：執行 guardrail 合規稽核。修復偏差。執行 GameDay 演練（模擬帳號入侵、模擬 Direct Connect 中斷）。
• 第 53–56 天：引入波浪零工作負載（Corporate IT 企業內網測試環境）。驗證端對端：SSO → 網路 → 部署 → 日誌進 log archive → findings 進 Security Hub → 成本進 Budgets。
• 第 57–60 天：撰寫操作手冊、發布 landing zone 操作指南、訓練事業單位遷移負責人。移交給第一波遷移啟動。

SAP-C02 遷移目標基礎架構常見陷阱

Professional 等級的遷移目標基礎架構考題圍繞著完全相同的一組陷阱建構。把這些背熟，你就能在每道題目中至少排除一個錯誤答案。

• Control Tower Landing Zone vs LZA vs CfCT 混淆。 Control Tower = 基礎服務。LZA = AWS Solutions 維護的加速器。CfCT = 舊版但仍受支援的自訂化流水線。三者不是同義詞。
• 把工作負載放進管理帳號。 永遠是錯的。SCPs 不適用於管理帳號，任何在那裡被入侵的管理員就擁有了整個組織。
• 誤以為 Account Factory 單獨就是「landing zone」。 Account Factory 佈建帳號，但不提供連線、身份識別或可觀測性。需要 LZA 或等效的自訂化層。
• 忘記 AD Connector 需要可到達的 AD。 沒有混合 DNS + 沒有 Direct Connect/VPN = 損毀的 Identity Center。連線是身份識別的前置條件。
• 正式截斷期只用單一 Direct Connect。 單一 DX 的 99.9% SLA 適用於開發環境。正式截斷期需要 99.99% 等級（兩條 DX、兩個 DX 位置）。
• 忽略 resolver 端點。 沒有 Route 53 Resolver 入站/出站端點，混合應用程式無法解析彼此的主機名稱。漏掉這個會讓第一天就出問題。
• 在沒有委派管理員的情況下啟用 GuardDuty/Security Hub。 讓管理帳號成為資安團隊的日常使用帳號，破壞了帳號衛生原則。
• 在遷移後才翻裝加密。 RDS 必須從快照重建才能新增加密。永遠在資料落地之前強制執行加密。
• 依賴手動標籤。 Tag policies 宣告允許的標籤金鑰/值；SCPs 強制執行標籤存在。兩者都需要，否則標籤覆蓋率會靜默衰退。
• 混淆 Customer Managed Key 與 AWS Managed Key。 Customer Managed Keys 支援金鑰政策、輪換控制與精細存取。AWS Managed Keys 則不支援。法規工作負載需要 CMKs。

相關主題與遷移目標基礎架構的邊界

遷移目標基礎架構刻意設計得廣泛，因為 SAP-C02 測試 domain 之間的邊界。可以交叉參考的相關主題：

• 多帳號治理 — OU 設計、SCP 評估以及 Control Tower 控制內部機制的深度介紹。
• Transit Gateway 與混合網路 — TGW route tables、DX 韌性等級、CIDR 重疊、集中式出口。
• 遷移評估與 7R — 如何分類將落入此基礎架構的工作負載。
• 遷移工具（MGN、DMS、DataSync、Snow family）— 工作負載實際上如何遷移到此基礎架構。
• 集中式資安日誌 — CloudTrail Lake、Security Lake OCSF、跨帳號可觀測性深度介紹。
• 加密與憑證管理 — KMS 多區域金鑰、ACM Private CA、CloudHSM。

遷移目標基礎架構主題擁有遷移前的設計——帳號佈建、guardrails、連線、身份識別、可觀測性、加密、成本。它不涵蓋遷移執行（那是遷移工具主題）或應用程式目標架構（那是 migration-target-infrastructure 的兄弟主題，應用程式目標架構，用來選擇 EC2 執行個體類型、RDS 引擎、FSx 變體）。

FAQ

Q1. 為什麼不能只用 AWS Organizations 加上幾條 SCPs 代替 AWS Control Tower？

技術上你可以用手寫的 CloudFormation 與 AWS Organizations 建立 landing zone，但工作量龐大：引導 Log Archive 與 Audit 帳號、撰寫並維護 30+ 個 guardrail SCPs 和 Config 規則、整合 Identity Center、設定 org trail、設定 Config aggregator、設計偏差偵測。採取這條路的團隊通常花 3–6 個月建造 Control Tower 一個下午就能做到的事，而且他們很少能讓手刻的設置跟上 Control Tower 受管更新的步伐。在 SAP-C02 中，「從頭自己建」在 60 天期限下幾乎不會是正確答案。

Q2. 每個事業單位應該有自己的 OU，還是只在共享的 Workloads OU 中各有自己的帳號就好？

兩者都要，分層使用。Workloads OU 通常分為 Prod 與 Non-Prod 子 OU，在其中再建立各事業單位的分組。原因在於政策繼承：「正式工作負載必須使用加密 EBS」的 guardrail 會自動被每個事業單位的 prod 帳號繼承。若改為在頂層按事業單位分割，你最終要在 5 個事業單位 OU 中重複相同的 prod 特定政策，並在規則更新時遺漏其中一個。SAP-C02 偏好政策驅動的 OU 設計，而非鏡像組織架構的 OU 設計。

Q3. 對於 60 天情境，Landing Zone Accelerator、CfCT 還是純粹的 Account Factory Customization 才是正確的？

Landing Zone Accelerator 最為吻合。本情境要求合規對齊（SOC 2、ISO 27001）、集中式檢查、組織層級加密、backup policies 以及從第一天起的治理——這些全部都是 LZA 預建好的。CfCT 需要你的團隊自己撰寫 CloudFormation 基礎，這會讓 60 天期限破功。Account Factory Customization 只能處理佈建期間各帳號的藍圖自訂化；它無法完成 Network Firewall 檢查 VPC 或 Security Lake 的部署。在 SAP-C02 中，當速度與合規兩者並存時，LZA 是可以站得住腳的選擇。

Q4. 未來如何從 AD Connector 過渡到 Azure AD 這樣的雲端原生 IdP？

先用 AD Connector 建立 Identity Center，因為這符合本情境「企業 Active Directory」的描述。把 Azure AD（Entra ID）的過渡規劃為獨立專案：你將 Identity Center 的身份識別來源從 AD 換成外部 SAML IdP，將 permission set 指定從 AD 群組遷移到 Entra 群組（SCIM 同步），然後淘汰 AD Connector。遷移目標基礎架構不需要預先考慮這個——Identity Center 支援在不拆除 permission sets 的情況下切換身份識別來源。在 SAP-C02 中，不要因為推測性的未來身份識別變更而讓第一天的設計過度複雜。

Q5. 既然 CloudTrail Lake 已支援 SQL 查詢，為什麼還需要 Security Lake？

CloudTrail Lake 只能查 CloudTrail。Security Lake 除了 CloudTrail 之外，還擷取 VPC Flow Logs、Route 53 Resolver 查詢日誌、Security Hub findings、EKS audit logs，以及自訂 OCSF 格式來源，統一以單一 schema 儲存。當 SIEM 或資安團隊在調查事件時，他們需要把 CloudTrail 事件、VPC Flow Logs 與 GuardDuty findings 聯結起來——只有 Security Lake 能讓這成為單次查詢操作。CloudTrail Lake 很適合 CloudTrail 專屬的合規查詢，但在 SAP-C02 等級的答案中無法取代正規化的日誌資料湖。

Q6. 在每個儲存桶上啟用 S3 Bucket Keys 的成本取捨是什麼？

S3 Bucket Keys 可讓帶有 SSE-KMS 的儲存桶每次物件操作的 KMS 請求減少多達 99%，在高流量的日誌、分析與備份儲存桶上產生顯著的節省。唯一的取捨是儲存桶層級的資料金鑰會在一個時間窗口內快取，因此若你撤銷 KMS 金鑰授予，最多需要 24 小時才能讓撤銷完全傳播到儲存桶。對於絕大多數的 landing zone 使用案例（log archive、Security Lake、backup），這個延遲是可接受的。對於有秒級撤銷需求的情境（機密工作負載），在這些特定儲存桶上使用不帶 Bucket Keys 的物件層級 SSE-KMS。

Q7. 如何估算截斷期所需的 Direct Connect 容量而不過度佈建穩態頻寬？

建立三個流量元件的模型。第一，基礎複製：MGN agents 從地端推送差異到 AWS，每個活躍複製通常 100–500 Mbps。第二，截斷期的最終同步：所有待處理寫入一次性排出的短暫尖峰，通常是基礎頻寬的 2–4 倍，持續 15–60 分鐘。第三，穩態混合流量：遷移共存期間地端與遷移後應用程式之間的使用者連線，從 100 Mbps 到數 Gbps 都有可能。將三者在預期峰值重疊時加總，乘以兩倍作為主動-主動冗餘，再向上取整到下一個 Direct Connect 速度等級。對於 60 天情境第一波，兩條 10 Gbps 連線是正確的——對複製本身來說是偏多，但把穩態混合流量與冗餘需求疊加進去後，容量就很合適了。一旦所有工作負載都完成遷移，可以重新評估並降級 Direct Connect 頻寬。

考試訊號總結

遷移目標基礎架構位於 Domain 4（20% 權重），在 60 天情境的視角下，SAP-C02 期望你能：

• 當速度與合規都有要求時，選擇 Control Tower + Landing Zone Accelerator 作為 landing zone 工具組合。
• 將 OU 樹設計為 Security + Infrastructure + Workloads (Prod/Non-Prod) + Sandbox + Suspended，絕不鏡像組織架構。
• 將 Direct Connect 容量估算到 99.99% 韌性等級用於正式截斷期，加上 VPN 備援，全部在 network 帳號的 Transit Gateway 上終止。
• 在 AD Connector 之前部署 Route 53 Resolver 入站 + 出站端點。
• 對企業 AD 場景使用 IAM Identity Center 搭配 AD Connector，在資料湖類型的工作負載遷移時啟用 Trusted Identity Propagation。
• 在第一波遷移前啟用組織層級 CloudTrail、Security Lake、GuardDuty（委派管理員）、Config aggregator。
• 透過帳號層級預設值（EBS、S3）、SCPs 以及高流量儲存桶上的 S3 Bucket Keys 強制執行加密。
• 搭配 SCPs、已啟用的成本分配標籤配對使用 tag policies；透過帶有 Budget Actions 的 AWS Budgets 設定警報。

如果一個答案選項以「之後再做」為由跳過上述任何一項，它幾乎肯定是 SAP-C02 的錯誤答案。Landing zone 是遷移的基礎，考試給分給那些如此對待它的考生。