Amazon SAP-C02: 遷移與現代化 — 學習指南

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

屬於 AWS Solutions Architect Professional SAP-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

遷移策略與規劃

有效的遷移始於嚴謹的探索、相依性對應，以及基於風險的優先級排序。使用 AWS Application Discovery Service 和 AWS Migration Hub 來盤點伺服器、收集效能指標，並將應用程式相依性視覺化；再輔以無代理程式的網路流量分析和組態管理資料，以找出隱藏的有狀態連結。將探索結果轉化為落地帶 (landing-zone) 的決策：使用 AWS Control Tower 和 Organizations 選擇帳戶策略，使用 Transit Gateway 定義網路拓撲，並利用 Compute Optimizer 和適當規模調整 (right-sizing) 指南來規劃目標運算資源的規模。應針對每個應用程式選擇轉換策略：對於小規模、低風險的系統，可採用一次性轉換 (big-bang)；對於業務關鍵的套件，可採用分階段或分波次的方式；對於面向客戶的服務，則可採用藍/綠 (blue/green) 或金絲雀 (canary) 部署，以將對使用者的影響降到最低。在規劃轉換時，需考慮資料同步窗口、DNS TTL、頻寬限制以及法規限制。常見的陷阱包括低估資料傳輸的時間和成本、將直接遷移 (lift-and-shift) 視為最終狀態、忽略授權可攜性，以及未能規劃回滾計畫。決策標準通常是在成本與營運投入和彈性之間進行權衡：託管服務 (如 RDS/Aurora, DocumentDB) 提高了營運支出 (OPEX) 的可預測性和彈性，但可能需要變更結構描述 (schema)；將平台重構 (replatforming) 至託管服務可減輕營運負擔，但代價是增加了遷移的複雜度。

直接遷移 (lift-and-shift) 與資料遷移工具

為了快速重新託管 (rehosting)，AWS Application Migration Service (MGN) 可自動化地將 VMware、Hyper-V 和實體伺服器的區塊層級複寫至 EC2，從而將轉換時間降至最低，並保留作業系統層級的組態。大量或離線的資料遷移可能需要使用 AWS Snow Family 或 DataSync 來處理檔案和 POSIX/NFS 工作負載，而 Amazon S3 Transfer Acceleration 和 Direct Connect 則可加速物件和大量資料的傳輸。資料庫遷移仰賴 AWS Database Migration Service (DMS) 進行同質或異質遷移，當需要進行結構性變更時，則搭配 Schema Conversion Tool (SCT) 使用。請注意 DMS 的限制：MongoDB 的來源/目標行為有版本和功能的限制、大型物件 (LOB) 的處理方式，以及在 CDC (異動資料擷取) 期間可能出現的複寫延遲。在架構設計上應確保資料完整性：使用校驗和 (checksums) 進行驗證，執行完整載入加上 CDC 以實現最短停機時間，並在低流量時段分階段進行轉換。設計上的權衡主要圍繞在速度與保真度之間：MGN 或重新託管 (rehost) 能將應用程式變更降至最低，但會延續傳統的營運模式；平台重構 (replatforming) 雖能減少長期的營運工作，但需要重構和測試。常見的陷阱包括忽略端點安全、轉換前的驗證不足，以及假設雲端儲存體具有相同的 IOPS/吞吐量。

現代化：容器、無伺服器與重構模式

現代化選項範圍廣泛，從將平台重構 (replatforming) 至容器編排，到完全重構 (refactoring) 為無伺服器 (serverless) 架構。若要快速進行容器化部署並盡可能減少基礎設施管理，可選擇 Amazon ECS on Fargate；若為需要可攜性和複雜編排的 Kubernetes 原生工作負載，則可選擇 Amazon EKS。對於事件驅動的微服務，可結合使用 AWS Lambda、API Gateway、EventBridge 和 Step Functions，以減少營運開銷並根據請求進行擴展。資料服務應朝向託管後端發展：使用 Amazon RDS/Aurora 處理關聯式資料庫，使用 Amazon DynamoDB 或 Amazon DocumentDB 處理 NoSQL/文件儲存，並使用 ElastiCache 進行低延遲快取。權衡的關鍵在於營運複雜度與成本及效能可預測性之間的取捨：EKS 以較高的營運成本提供控制權和可攜性；Fargate 簡化了營運，但在大規模部署時可能成本更高。無伺服器架構為尖峰工作負載提供了成本效益，但也帶來了冷啟動、並行限制和可觀測性方面的挑戰。常見的架構師陷阱包括：將單體應用直接搬到容器中卻未分解有狀態的元件、CI/CD 和 IaC (如 CloudFormation, CDK, Terraform) 不足以管理部署，以及忽略為任務角色和 Lambda 執行角色設定 IAM 最小權限原則。

轉換、混合式網路與遷移後維運

成功的轉換取決於混合式網路與身分整合，以及健全的可觀測性與復原計畫。若要在 VPC 與地端 Active Directory 之間進行混合式 DNS 解析，請部署 Amazon Route 53 Resolver 的 inbound 與 outbound endpoint，或使用 AD Connector/Managed Microsoft AD 來讓 EC2 Windows 執行個體加入網域。網路連線的選擇包括用於可擴展多帳戶拓撲的 AWS Direct Connect 與 Transit Gateway；當可預測的頻寬與較低的 egress 成本很重要時，請選擇 Direct Connect；若要簡化多對多的 VPC 與地端連線，則選擇 Transit Gateway。遷移後的維運必須涵蓋監控 (CloudWatch, X-Ray)、集中式日誌記錄與分析 (CloudWatch Logs、Kinesis Firehose 到一個集中式帳戶)、備份與跨區域快照策略 (AWS Backup、跨區域快照複製)，以及透過 AWS Config 與 IAM boundary policies 強制執行的安全基準。常見的陷阱包括：未能在轉換前調降 DNS TTL、未大規模測試 AD 整合，以及 Transit Gateway 頻寬佈建不足或遺漏路由傳播設定。此處的決策標準是彈性與成本的權衡：active-active 多區域設計能提高可用性，但會倍增複寫成本與複雜度；active-passive 則簡化了成本，但會拉長 RTO。

實務問題：使用案例情境

情境：全球研究企業 Acme Energy 擁有一個現有的 AWS 環境，其中包含 AWS Organizations 下的多個帳戶，以及一個透過私有 Direct Connect 線路連接的地端資料中心。他們需要將一套 Linux 模擬伺服器、一個 MongoDB 複本集，以及夜間映像檔共享遷移到 AWS，並盡可能減少中斷。

挑戰：降低維運負擔並實現彈性擴展，同時確保模擬服務的轉換停機時間不超過兩小時，且 MongoDB 複本集與夜間映像檔的擷取達到零資料遺失。

建議方法：

部署 AWS Application Migration Service (MGN) 代理程式，將模擬伺服器複寫到一個專用的遷移帳戶；設定低 RPO 的持續性區塊層級複寫，並為非關鍵節點優先安排分階段的轉換梯次。
使用 AWS DMS，以 MongoDB 為來源、Amazon DocumentDB (with MongoDB compatibility) 為目標，執行 full load 加上 CDC，並使用 checksums 與並行的讀取複本進行驗證，以確保文件層級的一致性。
使用 AWS DataSync 將夜間映像檔遷移到由 S3 生命週期規則支援的 Amazon S3 儲存貯體；為需要 NFS 語意的 POSIX-backed 工作負載，佈建 Amazon FSx for Lustre 或 Amazon EFS，並在尖峰負載下測試讀寫效能。
透過調降的 Route 53 TTL、用於藍/綠流量轉移的 Route 53 加權路由來協調轉換，並在 smoke tests 成功後完成 DNS 交換；強制執行 IAM roles 並啟用 CloudWatch X-Ray、集中式 CloudWatch Logs，以及用於快照的 AWS Backup。

理由：此方法透過分階段複寫與 CDC 將停機時間降至最低，藉由採用託管服務 (DocumentDB, S3, DataSync) 降低維運開銷，並提供安全的復原點與可觀測性，以便在最終轉換前驗證正確性——這與專業架構在遷移與現代化方面的最佳實踐一致。

← 資料庫與分析 · 所有領域 · 韌性、災難復原與高可用性 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →