應用程式現代化：Serverless、容器與解耦

為什麼應用程式現代化是與遷移截然不同的獨立學科

SAP-C02 考試刻意將 Task Statement 4.3（遷移目標架構）與 Task Statement 4.4（應用程式現代化）分開處理。這個區隔至關重要，因為應用程式現代化的本質是改變工作負載的形狀——包括執行環境、資料模型、部署單元與耦合方式——而不只是改變它的位置。透過 AWS MGN 完成的 Rehost 遷移能在數週內帶來營運效益；應用程式現代化計畫則在此基礎上，透過多年時間累積彈性、部署速度，以及在不重寫系統的前提下持續演進的能力。當題目出現「團隊希望將部署前置時間從六週縮短至兩天，並削減 70% 授權成本」這樣的描述時，這是一道應用程式現代化題，而非遷移題；AWS 的應用程式現代化工具箱與遷移工具箱截然不同。應用程式現代化是所有 AWS Task Statement 中，唯一有時「保持現狀不動」（7Rs 中的 Retain）才是正確答案的場景——因為現代化有真實的成本、真實的風險，以及 Rehost 所沒有的真實失敗模式。

SAP-C02 最典型的應用程式現代化情境，正是本主題要從頭到尾剖析的那個案例：一個運行在 Oracle WebLogic 上、已有 15 年歷史的 Java 巨石應用，底層是一台內部部署的 Oracle 資料庫，期限九個月，目標是遷上 AWS 容器並拆出三個可獨立部署的服務。這個情境濃縮了現代化工具箱中的每一個槓桿：容器化（App2Container）、漸進式拆解（Refactor Spaces + Microservices Extractor）、目標執行平台工程（Proton）、資料層重平台（Oracle 轉 Aurora PostgreSQL、整合式 Schema 轉領域驅動 Schema）、事件驅動解耦（EventBridge、Kinesis、MSK）、無狀態化遷移（Session 外部化至 ElastiCache 或 DynamoDB），以及務實的 ML/AI 注入（Textract、Bedrock、SageMaker）。考試所有關於應用程式現代化的題目，都從同一個工具箱取材；深度掌握各工具之間的決策邊界，是 Task 4.4 備考中 CP 值最高的投資。

遷移與現代化的分界線

遷移關乎工作負載在哪裡跑；現代化關乎工作負載如何被組織起來。SAP-C02 用 7Rs 描述遷移類別，而應用程式現代化則落在 Replatform 與 Refactor 這兩個改變工作負載形狀的 R 內。若題目的成功指標是「縮小資料中心佔用面積」或「退租共置機房」，這是遷移題。若成功指標是「每個服務獨立部署」或「消除月度 Oracle 授權費」，這是應用程式現代化題。

為什麼 SAP-C02 Task 4.4 的比重逐年增加

應用程式現代化題目在 SAP-C02 中的份量逐年成長，因為 AWS 持續推出更多專屬的現代化服務（Refactor Spaces、App Runner、Microservices Extractor、Proton），而現實客戶的對話也從「如何遷移」轉向「遷移後如何現代化」。預計約 10–12% 的考題會深入探測現代化專屬的 AWS 工具與模式，其中大多數直接來自 Task Statement 4.4。

現代化進程：從 Rehost 到 Replatform 到 Refactor

AWS Cloud Adoption Framework 與 7Rs 定義了一條光譜，但實際上應用程式現代化座落在三個階梯上：Rehost、Replatform、Refactor。Rehost 是不改程式碼的搬家，用 MGN 做區塊複製把 VM 搬進 EC2。Replatform 是「搬家時換掉部分設備」——你替換某個元件（通常是資料庫從自管 Oracle 換成受管 Aurora，或執行環境從 VM 換成容器），但應用程式原始碼幾乎不動。Refactor 是把巨石應用拆解成服務、把模組改寫為無狀態、用事件取代同步呼叫，並依照領域邊界重新設計資料模型。每往上爬一層階梯，潛在價值與執行風險都同步提高；考題很少在抽象層次問「哪層最好」，而是問「在這個情境的具體條件限制下，哪層是合理的選擇」。

三層階梯的成本價值曲線

考試最常測試的，正是這個成本不對稱性。Rehost 帶來 10–15% 的基礎設施節省，並帶來零營運變化。Replatform（容器化 + 受管資料庫）解鎖 30–50% 的營運節省、補丁外包、彈性擴展與授權費削減。Refactor 可帶來 10 倍的部署速度與無限水平擴展，但需要 6–18 個月的工程投入。一個常見的考試陷阱是，把 Refactor 當成「最佳實踐」答案提出，但情境的限制條件明明是四個月期限；在這個提示中，Replatform 至容器加受管 Aurora 才是正確的現代化選擇，全面 Refactor 是誘餌答案。

迭代式現代化才是致勝模式

第二個考試必知規則是：這三層階梯並非一次性的決策。AWS 上的應用程式現代化是一個迭代計畫：許多成功的現代化專案先做 Rehost（排除資料中心依賴），六個月內做 Replatform（換掉資料庫並容器化），再在接下來的 12–24 個月逐模組做 Refactor（以 Refactor Spaces 作為流量切換的門面）。考試會獎勵提出階段式推進計畫的答案，懲罰那些對一個連搬上 AWS 都還沒做到的工作負載就直接建議「大爆炸式 Refactor」的答案。

典型情境：WebLogic Java 巨石應用九個月遷上 AWS

在深入工具說明之前，先確立情境，讓後面每個章節都能對應到具體決策。這個系統是一個部署在 Oracle WebLogic 12c 上的 15 年老 Java EE 應用程式，運行在四台內部部署的 VMware 主機上，底層是一台擁有 4 TB 資料與 800 GB 預存程序邏輯的 Oracle 12c 資料庫。應用程式透過共用資料庫資料表，將三個隱含的業務領域黏在一起：目錄（catalog）、訂單（orders） 與客戶通知（customer notifications）。Session 狀態儲存在 WebLogic 的記憶體叢集 Session 複寫中，這意味著應用程式並非無狀態。部署作業在每季維護窗口中透過上傳 WAR 檔完成。團隊有九個月時間，目標是讓應用程式跑在 AWS 容器上，並將至少三個隱含領域拆解為可獨立部署的服務。

三階段計畫概覽

這個情境的致勝現代化藍圖遵循嚴格的三階段順序，所有 SAP-C02 題目只要對應這個形狀，都希望你辨識出這個順序。第一階段（第 1–3 個月）：以 App2Container 將現有巨石應用容器化，部署至 ECS Fargate，以 ElastiCache for Redis 的外部化 Session 取代 WebLogic Session 叢集，透過 DMS + SCT 將 Oracle 遷移至 Aurora PostgreSQL。巨石應用仍作為單一部署單元運行，但它現在跑在容器上、使用受管資料庫，且具備外部化的 Session 儲存。第二階段（第 4–7 個月）：將 Refactor Spaces 設定為應用程式層的門面，部署一個以 Lambda + SNS 構建、位於 API Gateway 路由後方的新「通知（notifications）」服務，讓流量從巨石應用逐步切換過來。第三階段（第 7–9 個月）：使用 Microservices Extractor for .NET 或手動領域切割，提取「目錄」與「訂單」服務，每個服務擁有自己的 Aurora Schema 與以 EventBridge 為基礎的事件契約。第九個月時，三個服務與一個縮小後的巨石應用並行運作，Refactor Spaces 負責路由流量，團隊也建立了在未來 12 個月持續拆解巨石應用的可重複模式。

白話文解釋（Plain-Language Explanations）

應用程式現代化充滿術語，讓簡單的機制變得晦澀難懂。以下三個類比各自照亮現代化工具箱的一個側面，當你遇到考題時，可先將情境翻譯成熟悉的語境再選答案。

類比一：夜市攤位的升級之路

把一間已經營 15 年的台式熱炒店想像成巨石應用——老闆一個人包辦前置備料、炒菜、擺盤、收碗盤和結帳，所有食材都堆在同一個冰箱裡。Rehost 就是把整間店連同老闆、冰箱、爐具，原封不動搬進一棟新大樓的同一層——地址換了，但流程完全沒變。Replatform 是保留老闆和菜單，但把自家冰箱換成由物流商統一補貨的共享冷鏈（受管資料庫），並把老舊瓦斯爐換成更省錢的 IH 電磁爐（容器化執行環境）；老闆還是那個老闆，但貴重的基礎設施現在是別人的煩惱。Refactor 是把一個全能老闆拆成四個專責角色：備料師、炒鍋廚師、擺盤師和洗碗工，每人各司其職，透過出菜單（事件）溝通和交接，而非擠在同一個冰箱前相互干擾。Refactor Spaces 就是站在出菜口的外場人員，根據菜色類型決定要喊「老菜單」（巨石應用）還是「新專區」（新服務）。App2Container 是那台真空封裝機——把老闆的全套備料用具密封進一個攜帶式容器，讓他能在任何廚房裡工作。

這個類比點出了為什麼 Refactor 如此昂貴：你不只是增加人手，而是重新設計每一條作業流程、重新協商誰負責冰箱、讓每個人都學習新的交接制度。這也解釋了為什麼在期限短暫的考題中，Replatform 往往是正確答案：換冰箱可以下週末完成，但把一個全能廚師培訓成四個專科人才需要好幾個月。

類比二：圖書館與絞殺榕

想像一座擁有龐大舊式卡片目錄系統的公共圖書館，這套系統覆蓋館內所有分區——歷史、兒童讀物、期刊、有聲書。館長希望在不關館整修一年的前提下完成數位化。她在入口處安排了一位導覽人員（門面）。當讀者詢問有聲書，導覽人員引導他們前往有聲書區的新數位查詢機；其他所有問題仍走舊卡片目錄。下個月兒童讀物區完成數位化，導覽人員更新指引。一年後，每個分區逐一遷移，舊卡片目錄終於推進庫房。這就是 Strangler Fig pattern——那位導覽人員，正是 Refactor Spaces 提供的東西：一個以 API Gateway 為前端的應用程式層代理，能逐路徑地在舊有巨石應用與新服務之間切換流量。

圖書館類比同樣說清楚了 transactional outbox pattern。若數位有聲書查詢機需要在每次借閱時通知舊卡片目錄，在同一筆交易中同時寫入兩個系統是脆弱的——萬一查詢機成功但通知卡片目錄的訊息失敗呢？替代方案是：查詢機在同一筆本地資料庫交易中，同時寫入借閱記錄和一筆 outbox 訊息。另一個獨立的工作程序讀取 outbox 資料表並發布事件。讀者永遠不會看到半途而廢的借閱記錄，卡片目錄也終將得知每一筆借閱。透過 DMS 或 Aurora 邏輯複寫實現的 Change Data Capture（CDC），是讓這個 outbox 工作程序在 AWS 上可靠運作的機制。

類比三：瑞士刀與工具箱

瑞士軍刀把刀片、螺絲起子、剪刀和開瓶器全折進同一個握把——野餐時很方便，裝修時卻派不上用場：你沒辦法把螺絲起子借給隊友同時用剪刀，開瓶器壞了就得整把換掉。這就是巨石應用：一個部署單元、一個語言執行環境、一個資料庫、一個發布節奏。工具箱裡的工具各自獨立掛在洞洞板上；螺絲起子可以借出去，剪刀可以單獨磨利，開瓶器壞了只換開瓶器。這就是跑在 ECS、EKS 或 Lambda 上、由 EventBridge 和 SQS 協調的微服務架構。洞洞板是共享的事件匯流排，板上的標籤孔是登記在 EventBridge Schema Registry 裡的事件 Schema。Proton 是洞洞板的製造商——它定義每個新掛鉤的標準形狀，確保每件工具的掛法一致，沒有人自行發明奇怪的安裝支架。

瑞士刀類比也解釋了為什麼過早拆分會造成傷害：如果你把剪刀從瑞士刀上取下，卻讓它仍與螺絲起子共用同一個刀軸，你就得到了兩件工具加一個隱藏的共享依賴，處境反而更糟。這正是分散式巨石應用（distributed monolith）反模式，辨識它是考試高頻考點。

App2Container：從現有 VM 容器化 Java 與 .NET 應用

AWS App2Container（A2C）是一個命令列工具，能夠掃描 Linux 或 Windows VM 上正在運行的 Java 或 .NET 應用程式、擷取其執行期依賴，並產生 Docker 容器映像檔及 ECS、EKS 或 App Runner 的部署產物。它是現代化容器化階段最具考試相關性的工具，因為它把「容器化我們的巨石應用」這個故事，從一個六個月的工程專案壓縮成一個數週的營運任務。

A2C 的分析與容器化兩個階段

A2C 分兩個階段執行。分析（analyze） 階段在來源 VM 上（或在能存取 VM 的工作機上）執行，產出一份應用程式清單，包含其連接埠、依賴、組態檔，以及 WebLogic/Tomcat/IIS/WebSphere 特有的元資料。容器化（containerize） 階段將偵測到的應用程式打包進 Dockerfile、建置映像並推送至 Amazon ECR，同時生成用於 ECS 或 EKS 部署目標的 CloudFormation 模板。A2C 處理了你不願手動搞定的 Java 複雜性：它保留 JVM 旗標、內嵌必要的 JAR、擷取 WebLogic 網域設定，並生成能重現 WebLogic 啟動流程的容器進入點。對於 .NET，A2C 同時支援 Windows 上的 .NET Framework（產生 Windows 容器）以及 Linux 上的 .NET Core/6/8。

影響考試決策的 A2C 限制

A2C 的重要限制會影響考試決策：它不修改應用程式程式碼、不將 Session 狀態從記憶體叢集轉換為外部化儲存、不遷移資料庫、也不拆分巨石應用。若考題說「Java EE 應用程式使用 WebLogic Session 複寫，團隊希望實現無狀態容器」，A2C 本身不是答案——A2C 加上外部化 Session 儲存（叢集模式的 ElastiCache for Redis，或帶 TTL 的 DynamoDB）才是。A2C 是必要條件，但不足以完成真正的現代化；它是真空封裝機，而非重新設計的過程。

AWS Migration Hub Refactor Spaces：Strangler Fig 門面即服務

AWS Migration Hub Refactor Spaces 是 Strangler Fig pattern 的受管實作。它建立一個應用程式層代理，由一個 API Gateway 搭配後端的 Network Load Balancer 組成，並設有路由規則，可將特定 URL 路徑模式送往舊有巨石應用（通常跑在 EC2 或 ECS 上），或送往新微服務（Lambda、ECS 服務或 HTTP 端點）。Refactor Spaces 管理跨帳號網路配置——VPC Peering、Transit Gateway 掛載或 PrivateLink——讓「現代化」帳號中的新服務能接收來自「遺留」帳號中巨石應用的流量，而無需團隊手動配置網路。

漸進式路徑路由機制

考試關鍵概念是漸進式路徑路由（incremental path-based routing）。Refactor Spaces 應用程式擁有一組服務與路由。服務可以是舊有巨石應用（類型 URL），也可以是新微服務（類型 LAMBDA 或 URL）。路由將 URL 路徑模式綁定到服務，且你可以在不重新部署用戶端的情況下更改綁定，因為 API Gateway 端點是穩定的客戶端對外 URL。當團隊將「通知（notifications）」領域提取到 Lambda 函數時，他們為 /notifications/* 新增一條指向新 Lambda 的路由，巨石應用完全不知情。/orders/*、/catalog/* 及其他所有流量仍打到巨石應用。六個月後，隨著更多領域被提取，越來越多路由指向新服務，最終預設路由（巨石應用）處理的請求少於 10%，可以排程退場。

Refactor Spaces 是遷移期門面，而非 Service Mesh

Refactor Spaces 不是微服務框架、Service Mesh 或服務探索系統。它專為巨石應用與新服務並行共存的遷移期設計。一旦巨石應用退場，你通常會以直接的 API Gateway 或 ALB 取代 Refactor Spaces，因為你不再需要相容舊有的回退路由。考試會測試你是否理解這個遷移期定位：若情境說「巨石應用已經退場，我們需要一個 Service Mesh」，Refactor Spaces 是錯誤答案，App Mesh 或 VPC Lattice 才正確。

Refactor Spaces vs 自組 Strangler Fig

在 AWS 上自組 Strangler Fig 是可行的：一個帶有路徑型監聽規則的 Application Load Balancer、一個指向巨石應用的預設目標群組，以及每個新服務的額外目標群組。那麼為什麼要用 Refactor Spaces？答案是跨帳號隔離與治理。在大型企業遷移中，舊有巨石應用住在「遷移」帳號，新服務由不同的產品團隊在「現代化」帳號中構建。Refactor Spaces 負責處理 Transit Gateway 掛載、跨帳號路由更新的 IAM 許可，以及 API Gateway 生命週期管理——自組 ALB 方案需要遷移團隊為每個新上線的服務自行配線，通常耗費數週工程時間。

Microservices Extractor for .NET：透過靜態分析進行巨石拆解

AWS Microservices Extractor for .NET 是一個獨立桌面工具，可載入 .NET 或 .NET Framework 解決方案、執行靜態程式碼分析以建立類別和方法的呼叫圖（call graph），並透過視覺化圖形分區協助架構師識別候選的微服務邊界。此工具不會自動重構程式碼；它產出一個提取後的專案骨架、所需依賴清單，以及需要替換為跨服務呼叫的參考報告。

在領域邊界進行呼叫圖分區

心智模型是：巨石應用的呼叫圖在領域內部有密集的邊（同一領域的類別頻繁互呼）、在跨領域之間有稀疏的邊（跨領域的類別較少互相呼叫）。領域邊界就是圖形自然稀疏的地方，良好的微服務提取就是在這些稀疏點下刀。Microservices Extractor 將此圖形視覺化，讓架構師畫出邊界；工具回報需要轉為跨服務呼叫的對外呼叫與共享物件數量，這就是該邊界選擇的實作成本。

將此技術應用於 Java 及非 .NET 巨石應用

對我們情境中的 Java 巨石應用，Microservices Extractor 無法直接適用，因為它專屬於 .NET。然而，這個分析技術（在領域邊界進行呼叫圖分區）是通用的。對於 Java，等效的靜態分析可透過 Structure101、或手動以 Maven 加 Sonargraph 繪製依賴關係圖來完成。考試不會測試具體的 Java 工具，但會測試這個概念：先識別縫合點，再下刀切割，因為在密集的圖形邊處切割，會產生兩個服務透過網路頻繁通訊、共享資料庫的分散式巨石應用反模式。

AWS Proton：現代化目標的平台工程

AWS Proton 是 SAP-C02 考生最常低估的服務。它是一個平台工程服務，讓中央平台團隊發布環境模板（共享基礎設施如 VPC、叢集、共享資料庫）和服務模板（標準化的部署模式，例如「帶有 CloudWatch 告警和 CI/CD Pipeline 的 Fargate 服務，位於 ALB 後方」）。產品團隊只需選擇模板並提供少量參數即可佈建服務，完全不用撰寫原始的 CloudFormation 或 Terraform。結果是，一個有 50 個微服務的現代化計畫不會產生 50 個各具形態的部署；而是產生三到四個經過審核的服務模板的 50 個實例。

微服務爆炸失敗模式

Proton 之所以在應用程式現代化中重要，正是因為微服務爆炸失敗模式（每個團隊各自發明自己的日誌記錄、自己的 IAM 結構、自己的部署 Pipeline）是在第二年殺死現代化計畫的營運災難。Proton 是 AWS 對這個失敗模式的解答，考試會以「平台團隊如何在不失去治理的前提下實現自助服務」來呈現這個問題。正確答案是 Proton 環境與服務模板，加上版本管理和推廣工作流，以受控方式將新模板版本從開發環境升至正式環境。

Proton 可選，但紀律不可少

Proton 不是現代化的必要條件——團隊可以用每服務一份手寫 CloudFormation 或 CDK 成功完成現代化——但缺乏 Proton 同等紀律，是第二年現代化失敗的最常見根本原因。考試透過這個情境來測試：「18 個團隊各自建立了自己的部署 Pipeline，現在排查正式環境事件需要了解 18 種不同的日誌慣例」；正確的改善方案是整合到 Proton 模板上。

資料層現代化：從整合式 Schema 到領域驅動資料

在沒有現代化資料層的情況下容器化應用程式，會讓大部分現代化價值停留在桌面上。一個由數百個緊密連接的資料表組成、依賴單一 Oracle Schema 的巨石應用，無法成為微服務，因為資料庫是隱藏的耦合點。每一個微服務架構最終都面對同樣的問題：我們如何拆分資料？

Oracle 轉 Aurora PostgreSQL：最常被測試的 Replatform

最常見、也是考試最常問到的 Replatform 動作，是 Oracle 轉 Aurora PostgreSQL。AWS Database Migration Service（DMS）執行完整載入加 CDC 複寫，AWS Schema Conversion Tool（SCT）將 Oracle DDL、預存程序和 PL/SQL 轉換為 PostgreSQL PL/pgSQL。SCT 回報自動轉換的物件百分比（Oracle 轉 Aurora PostgreSQL 通常為 70–85%），並標記需要手動重寫的項目。切換模式是：DMS 完整載入、DMS CDC 在雙跑期間保持 Aurora 同步、透過 DMS 資料驗證任務進行驗證，然後 DNS 切換，同時將舊資料庫保持在複寫來源模式以供回滾。

Cassandra 轉 Amazon Keyspaces

對於 Cassandra 工作負載，現代化目標是 Amazon Keyspaces——一個具有按需計費的無伺服器 Cassandra 相容資料庫。遷移路徑在概念上類似（資料複製、CDC、切換），但工具不同：Keyspaces 支援透過 cqlsh COPY 進行 CQL 原生遷移，或透過 AWS Glue 處理較大的資料集。考試陷阱是假設 Keyspaces 是直接替換；它不是——Keyspaces 有不同的次要索引語意、不同的計數器語意，以及不同的一致性效能取捨，需要在切換前進行應用程式層驗證。

Change Data Capture 與 Transactional Outbox

服務拆分後，它們需要在不依賴同步呼叫的緊密耦合的情況下通訊狀態變更。Transactional outbox pattern 是考試認可的解決方案：當服務更新自己的資料庫時，在同一筆本地交易中寫入一列 outbox 記錄，捕捉應該發布的事件。一個獨立的程序（通常是 CDC 模式的 AWS DMS、透過 Database Activity Streams 讀取 Aurora binlog 的 Lambda，或帶有 Debezium connector 的 MSK Connect）讀取 outbox 資料表並將事件發布至 EventBridge、Kinesis 或 MSK。這保證了每一筆提交的狀態變更都會產生一個事件，反之，任何因回滾而未提交的狀態變更都不會發布事件——這是下游服務可以去重的至少一次（at-least-once）語意。

Transactional outbox 取代了「寫入資料庫後呼叫 SNS」的失敗模式，因為後者沒有原子性：資料庫寫入可能成功但 SNS 呼叫可能失敗，導致靜默的狀態偏差。它也取代了「先發布至 SNS 再寫入資料庫」的失敗模式，因為後者可能為從未提交的狀態發布事件。Outbox 是唯一能在所有失敗模式下倖存的至少一次模式，考試會獎勵能識別它的答案。

在現代化過程中選擇合適的目的型資料庫

現代化也是重新審視關聯式模型是否仍適合的時機。若存取模式是鍵值查詢（以主鍵查找、簡單的範圍查詢），DynamoDB 消除了 Schema 管理，並能擴展至每秒數百萬次請求。若資料是階層式或圖形結構（推薦引擎、詐欺環），Neptune 是目的型的最佳選擇。若資料是時間序列（遙測、指標），Timestream 是最適合的。應用程式現代化是採用目的型資料庫成本最低的時間窗口；事後再做改造代價高昂。

事件驅動解耦：EventBridge、Kinesis 與 MSK

一旦巨石應用拆分成服務，串連它們的膠水就是事件。考試測試三個 AWS 事件傳遞服務及其決策邊界：EventBridge、Kinesis Data Streams 與 MSK（Managed Streaming for Apache Kafka）。

EventBridge 用於離散的應用程式事件

EventBridge 是應用程式整合事件的首選預設：像「訂單已成立」、「使用者已註冊」、「庫存已調整」這樣的離散業務事件。EventBridge 提供基於內容的路由規則、事件契約的 Schema Registry、跨帳號事件匯流排，以及按事件計費。當消費者異質（部分是 Lambda、部分是 SQS、部分是 HTTP 端點）且你希望基於內容過濾，讓每個消費者只看到自己關心的事件時，EventBridge 表現最佳。EventBridge 的限制是吞吐量（預設每帳號每秒 10,000 個事件，可申請提升）以及缺乏每分區有序交付。

Kinesis Data Streams 用於有序的高吞吐量串流

Kinesis Data Streams 是你需要每分區鍵有序交付和高吞吐量（每秒數百萬筆記錄）時的正確選擇。Kinesis 在點擊流、IoT 遙測和 CDC 管道中表現最佳，其中下游消費者需要按每個實體的嚴格順序處理記錄。Kinesis 也提供重播功能（最多 365 天的保留期），EventBridge 沒有此功能，使其對於事件溯源（event sourcing）模式很有價值，新服務可以從歷史事件重建狀態。

MSK 用於 Kafka 原生工作負載

MSK 是當團隊有現有的 Kafka 專業知識、需要 Kafka Connect 生態系統相容性（Debezium、現有的 Kafka Sink），或正在遷移自管 Kafka 部署時的正確選擇。MSK 提供完整的 Kafka 語意，包括精確一次的生產者、事務訊息和分層儲存。MSK Serverless 為可變工作負載移除了叢集規模決策。MSK 的成本和營運複雜性高於 EventBridge；除非 Prompt 明確提及 Kafka 遷移或 Kafka Connect 需求，否則考試不會為綠地應用程式整合情境授予 MSK 加分。

EventBridge Pipes 用於點對點整合

EventBridge Pipes 是一個較新的功能，從來源（SQS、Kinesis、DynamoDB Streams、MSK、Kafka）到目標（Lambda、Step Functions、EventBridge Bus、Kinesis）建立點對點連接，並可選擇性地進行過濾和擴充。Pipes 是當情境為「從 DynamoDB Streams 過濾後轉送每一個 CDC 變更到 EventBridge」時的正確考試答案——以前這需要一個手寫的 Lambda，現在只需設定即可。

無狀態化遷移與 Session 外部化

現代化問題中反覆出現的是 Session 狀態問題。我們情境中的 WebLogic 巨石應用使用記憶體內叢集 Session 複寫：使用者登入時，其 Session 儲存在一台 WebLogic 伺服器的 JVM 堆積中，並透過 WebLogic 的複寫協定複寫到叢集中的其他伺服器。這個模式從根本上與現代化的彈性容器部署不相容。容器可能在任何時刻被終止（Fargate Spot 中斷、ECS 滾動部署、Pod 驅逐），這意味著儲存在容器記憶體中的 Session 狀態會遺失。Auto Scaling 無法在不造成 Session 遺失的情況下增加容量。藍綠部署會讓每個使用者的登入狀態中斷。

ElastiCache for Redis vs DynamoDB 用於 Session 儲存

現代化目標是在受管服務中實現 Session 外部化儲存。兩個 AWS 選項佔主導地位：叢集模式的 ElastiCache for Redis（快速 Session 查詢的預設選擇，通常個位數毫秒延遲，支援基於 TTL 的過期）和帶 TTL 的 DynamoDB（當團隊希望低流量應用程式有零營運開銷和按需計費時的選擇）。程式碼變更很小——將 httpSession.setAttribute 替換為 Redis SET 指令——但這是一個真實的程式碼變更，A2C 無法自動完成。這是第一階段的現代化任務，必須在無狀態容器部署之前完成。

為什麼 ALB Sticky Sessions 不夠用

考試陷阱是假設負載平衡器的 Sticky Sessions 解決了問題。ALB Sticky Sessions 確實能為單一使用者保持對單一容器的親和性，但它無法在容器終止、Auto Scaling 事件或部署滾動更新中倖存。Sticky Sessions 是一種局部因應措施，而非無狀態 Session 解決方案。任何提及零停機部署或彈性 Auto Scaling 的 Prompt，都需要 Session 外部化，而非 Sticky。

反模式：過早拆分與分散式交易之痛

現代化失敗遵循少數幾個重複出現的模式，考試測試這些反模式，因為它們是現實世界的失敗模式。

過早拆分與分散式巨石應用

過早拆分是在團隊識別出真正的領域邊界之前就決定將巨石應用拆解成服務。症狀是服務之間頻繁通訊——服務 A 需要呼叫服務 B 三次才能完成單一請求，而服務 B 沒有呼叫服務 C 就無法完成。根本原因是「拆分」沒有遵循真正的領域縫合點；它遵循了一個與系統其他部分共享資料的方便模組邊界。在正式環境中診斷出過早拆分時，修復方案通常是將頻繁通訊的服務合併回單一服務共用程式碼庫，並以更好的縫合點識別重新拆解。

分散式交易與 Saga Pattern

分散式交易之痛是意識到，一個在巨石應用中原子化的業務操作（跨五個資料表的一筆資料庫交易），在服務間變成非原子的（五個服務中分別的五次資料庫寫入）。幼稚的解決方法是兩階段提交（two-phase commit），但它在微服務規模下無法運作，因為它要求每個參與的服務同時可用。考試正確的解決方法是 Saga pattern：將業務操作建模為一系列本地交易，每個服務提交自己的狀態，如果後續步驟失敗則發布補償動作。AWS Step Functions 是 Orchestrated Saga 風格的受管協調服務；帶有 Choreographed 處理程序的 EventBridge 是 Choreographed Saga 風格的替代方案。無論哪種方式，思維模式的轉換都是從「一筆交易」到「帶有補償的本地交易工作流」。

共享資料庫是無聲的耦合

共享資料庫反模式是當團隊拆分了應用程式層，但讓兩個服務繼續讀寫同一資料庫中的同一資料表時留下的無聲耦合。每一次資料庫 Schema 變更現在都需要跨服務協調部署，這消除了激發拆分動機的部署獨立性價值。正確的模式是每服務一個資料庫（database per service）：每個提取的服務擁有自己的 Schema，跨服務的資料存取透過擁有服務的 API 或非同步事件進行。這是現代化中最困難的部分，也是最常被回滾的決策。

ML/AI 注入：以受管 AI 服務進行務實現代化

一個微妙但日益常見的考試主題是ML/AI 注入到現代化的應用程式中。Prompt 通常描述一個手動工作流（客服人員閱讀 PDF 表單、支援人員回答重複的產品問題、規劃團隊在試算表中預測需求），並詢問如何使用 AWS 受管 AI 服務進行現代化。考試正確的答案不需要構建自訂 ML 模型；它們使用能以 API 形式交付能力的受管服務。

Amazon Textract 用於文件處理

Amazon Textract 從 PDF、掃描文件和圖片中提取結構化文字、資料表和表單欄位。當情境提到「手動輸入發票資料」或「處理紙本表單」時，它是正確的現代化目標。Textract 從表單回傳鍵值對和結構化資料表資料；現代化後的架構通常是 S3 上傳 → EventBridge 觸發 → Textract 非同步任務 → 結果寫入 DynamoDB 或 SNS 通知。

Amazon Bedrock 用於生成式 AI 注入

Amazon Bedrock 透過單一 API 提供受管的基礎模型（Anthropic Claude、Amazon Titan、Cohere、Meta Llama、Mistral），並透過 Knowledge Bases 內建 RAG（Retrieval-Augmented Generation）能力。當情境提到「支援人員回答重複的產品問題」或「客戶想要文件的自然語言介面」時，它是正確的現代化目標。現代化後的架構通常是 使用者查詢 → Bedrock Agent 或 Knowledge Base → 以團隊文件為基礎的 LLM 回應。

Amazon SageMaker 用於自訂模型

Amazon SageMaker 是當團隊有現有的資料科學家和自訂模型需求（需求預測、客戶流失預測、推薦）時的正確選擇。SageMaker 提供訓練基礎設施、模型託管端點和 MLOps 能力（Pipelines、Model Registry）。現代化後的架構，用 SageMaker 批次轉換任務取代基於試算表的手動預測，該任務從資料湖取用歷史資料並將預測發布至下游服務。

情境演練：Java 巨石應用九個月上 AWS

回到典型情境——運行在 WebLogic 上的 15 年 Java 巨石應用、4 TB Oracle 資料庫、九個月期限、預期三個解耦服務——以下是對應上述工具的分階段應用程式現代化計畫。

第一階段（第 1–3 個月）：Replatform 基礎

使用 App2Container 將 WebLogic 巨石應用容器化為 Fargate 相容映像。同時，使用 SCT 評估 Oracle 轉 Aurora PostgreSQL 的轉換（預期 75% 自動，25% 預存程序手動工作）。使用 DMS 完整載入加 CDC 將 Oracle 複寫至 Aurora PostgreSQL。以叢集模式的 ElastiCache for Redis 取代 WebLogic Session 複寫，並更新應用程式的 Session 存取程式碼以使用 Redis。部署到帶有 Application Load Balancer 前端的 ECS Fargate。第三個月時，巨石應用跑在 Fargate 上、使用 Aurora，並具有外部化 Session；團隊尚未拆分任何服務。

第二階段（第 4–7 個月）：Strangler Fig 與第一個服務提取

佈建 Migration Hub Refactor Spaces，將預設路由指向 Fargate 上的巨石應用。在 Lambda + SES + SNS 上構建新的「通知（notifications）」服務，並設計自己的事件契約。為 /notifications/* 新增一條指向 Lambda 的 Refactor Spaces 路由。透過 Transactional Outbox pattern（Aurora 中的 outbox 資料表，DMS CDC 任務透過 Lambda 代理複寫至 EventBridge）讓巨石應用發布「訂單已成立」事件至 EventBridge。通知服務消費 EventBridge 事件並發送客戶電子郵件。第七個月時，一個服務已提取，巨石應用仍擁有目錄和訂單，團隊已驗證了後續提取的可重複模式。

第三階段（第 7–9 個月）：目錄與訂單提取

透過分析 Aurora Schema 中耦合度低的切割點（跨領域外鍵少的資料表），識別領域縫合點。將「目錄（catalog）」提取為新的 Fargate 服務，搭配自己的 Aurora 叢集（可變負載用 Aurora Serverless v2）；透過 DMS Schema 過濾複寫遷移目錄資料表；為 /catalog/* 新增 Refactor Spaces 路由；更新巨石應用透過內部 API 呼叫目錄服務。對「訂單（orders）」重複同樣流程。使用 AWS Proton 模板確保每個新服務繼承相同的 Fargate 加 Pipeline 基線（CloudWatch 告警、IAM 角色、X-Ray 追蹤）。在每個新服務中使用 Transactional Outbox pattern 處理跨服務事件。第九個月時，三個服務與縮小的巨石應用並行運作；Refactor Spaces 路由流量；團隊在接下來的 12 個月有可重複的模板繼續拆解巨石應用。

為什麼順序在考試中至關重要

刻意的順序很重要：在拆分之前容器化、在彈性擴展之前外部化 Session、在引入服務之前遷移資料庫、在提取第一個服務之前引入 Strangler Fig 門面。考試提供一條重新排列這些步驟的路徑時——例如「先將通知服務提取為 Lambda，再容器化巨石應用」——這是誘餌答案，因為在巨石應用自身尚未上彈性基礎設施之前就提取服務，會創建一個混合同步呼叫架構，比兩個端點狀態都更糟。

衡量現代化：ROI 對話

SAP-C02 考試偶爾將應用程式現代化框架為需要可衡量結果的業務決策。重要的、考試在答案中獎勵的指標是：

• 部署頻率：從季度（巨石應用）到每日（微服務）——典型提升 90 倍
• 變更前置時間：從數週到數小時——從程式碼提交到正式環境的時間
• 平均恢復時間（MTTR）：從數小時到數分鐘，因為單一服務故障不會拖垮整個巨石應用
• 變更失敗率：導致正式環境事故的部署百分比——由於每次部署的爆炸半徑更小，通常從巨石時代的 15–20% 降至微服務時代的 5–8%
• 基礎設施成本：Replatform 通常減少 30–50%（受管服務、彈性擴展、授權消除）；微服務早期階段通常持平或略高（更多移動部件），穩定狀態下低 20–40%
• 授權成本：在從 Oracle Database、WebLogic、WebSphere 或 SQL Server Enterprise 遷移時，往往是最大的現代化 ROI 驅動因素

常見的考試框架是「CFO 希望看到現代化計畫的 12 個月 ROI；哪些指標能展示價值」。正確答案始終是 DORA 指標（部署頻率、前置時間、MTTR、變更失敗率）加上直接成本削減，絕對不只是純技術指標，如「提取的服務數量」或「重構的程式碼百分比」。

常見考試陷阱

SAP-C02 現代化題目中有幾個反覆出現的具體陷阱，在閱讀誘餌答案之前辨識它們，在考試當天價值 5–10 分。

大爆炸式 Refactor 陷阱

大爆炸式 Refactor 陷阱呈現四個月的期限並詢問最佳現代化方案。誘餌是「將巨石應用重構為 12 個微服務」；正確答案是「Replatform 至容器和受管資料庫，將 Refactor 推遲到後續階段」。

A2C 已足夠陷阱

A2C 已足夠陷阱呈現 A2C 成功容器化應用程式的情境，並詢問下一步是什麼。誘餌是「現代化已完成」；正確答案涉及 Session 外部化、受管資料庫，以及漸進式拆解計畫。

共享資料庫陷阱

共享資料庫陷阱呈現一個已將巨石應用「拆分」成三個服務，但抱怨部署耦合的團隊。誘餌是「增加更多資料庫連接」；正確答案是「將 Schema 拆分為每服務一個資料庫，並為跨領域狀態引入非同步事件」。

兩階段提交陷阱

兩階段提交陷阱呈現分散式交易情境，並提供 XA 交易或分散式鎖作為解決方案。正確答案始終是使用 Step Functions 或 Choreographed EventBridge 的 Saga pattern。

同步呼叫鏈陷阱

同步呼叫陷阱呈現三個微服務的呼叫鏈，使用者請求阻塞在所有三個上。誘餌是「增加更多容量」；正確答案是「用 SQS 或 EventBridge 解耦，使只有第一跳是同步的」。

過早引入 Kafka 陷阱

過早引入 Kafka 陷阱呈現綠地事件驅動設計，並提供 MSK 作為整合服務。除非 Prompt 明確提及 Kafka 遷移或 Kafka Connect 需求，否則正確答案是應用程式事件用 EventBridge，或高吞吐量有序串流用 Kinesis。

常見問題

什麼時候應該選擇 Refactor Spaces，而非自組 ALB 型 Strangler Fig？

當舊有巨石應用和新服務將存在於不同的 AWS 帳號中、跨帳號網路（Transit Gateway、VPC Peering）尚未就緒，或你需要對遷移期門面進行集中治理時，選擇 Refactor Spaces。當一切都在單一帳號中，且團隊有現有的監聽規則 CI/CD 自動化時，自組 ALB 是可接受的。考試在多帳號企業遷移中傾向 Refactor Spaces，在單帳號綠地情境中傾向 ALB。

正確順序是先容器化還是先遷移資料庫？

在可能的情況下同時進行，因為它們有獨立的團隊和獨立的風險狀況。若必須排序，先容器化應用程式，因為它在過渡期間仍可以透過 Direct Connect 或 VPN 連接到內部部署的 Oracle 資料庫。在沒有容器化應用程式的情況下先遷移資料庫，會迫使內部部署的應用程式透過網際網路或 Direct Connect 對每個查詢路由，對大多數正式環境工作負載來說，這是無法接受的延遲。致勝模式是：第 1–2 個月容器化，第 2 個月啟動 DMS CDC，第 3 個月切換資料庫。

AWS App2Container 能在不改變程式碼的情況下現代化 WebLogic 應用程式嗎？

App2Container 無需程式碼變更即可容器化，但容器化的應用程式並不是完全現代化的。具體來說，WebLogic 叢集 Session 複寫在容器內無法運作，因為 Fargate 上容器間的多播不可靠。團隊必須修改 Session 管理程式碼以使用外部化儲存（ElastiCache 或 DynamoDB），容器化的應用程式才能彈性擴展。A2C 會產生一個可運行的容器，但沒有 Session 變更，該容器無法安全地進行 Auto Scaling 或滾動部署。

AWS Proton 是成功現代化的必要條件，還是可選的？

Proton 是可選的，但它預防的失敗模式是非常真實的。一個產出 20 個微服務、每個都有各自手寫 CloudFormation、各自日誌慣例、各自 CI/CD Pipeline 和各自 CloudWatch 告警設定的現代化，在第二年是無法維護的。Proton（或基於 Terraform 的等效 golden-path 紀律）是解藥。當情境明確描述多個團隊部署服務時，考試傾向 Proton 答案；對於單一團隊、單一服務的現代化，Proton 不是正確答案。

我如何在 Aurora PostgreSQL、DynamoDB 和 Keyspaces 之間選擇現代化資料庫目標？

經驗法則：若舊有應用程式使用關聯式語意（跨多個資料表的 JOIN、交易、複雜查詢），目標是 Aurora PostgreSQL 或 Aurora MySQL。若存取模式是鍵值（以主鍵查找、簡單的範圍查詢），目標是 DynamoDB——但這需要圍繞存取模式而非只是遷移資料來重新設計資料模型。若舊有應用程式使用 Cassandra，目標是 Keyspaces，但需驗證次要索引和計數器語意是否匹配。Aurora Serverless v2 是關聯式工作負載有可變負載時的正確子選項；預置的 Aurora 是具有 Reserved Instance 節省的穩態工作負載的正確子選項。

為現代化的應用程式添加 AI 能力最快的方式是什麼？

從以 API 形式公開能力的受管 AI 服務開始。Amazon Textract 用於文件提取，Amazon Comprehend 用於文字分析，Amazon Rekognition 用於圖片和影片分析，Amazon Bedrock 用於生成式 AI。這些不需要模型訓練、不需要資料科學團隊、不需要 ML 基礎設施。只有當團隊有自訂特徵、無法傳送至受管服務的專有訓練資料，或禁止共享模型 API 的法規要求時，才升級到 SageMaker。考試在 AI 注入情境中強烈偏好受管 API 答案；除非明確要求自訂模型訓練，否則 SageMaker 是誘餌答案。

我怎麼知道巨石應用什麼時候準備好被拆分？

當巨石應用有穩定的 CI/CD Pipeline、可觀測性已就緒（CloudWatch、X-Ray、結構化日誌）、資料庫在受管服務中且有多個 Schema 的空間，以及團隊識別出至少一個具有明確邊界資料存取的領域時，巨石應用才準備好了。若缺少其中任何一項，拆分就會失敗——通常出現分散式巨石應用的症狀，新服務與巨石應用頻繁通訊，部署無法獨立進行。在現代化第一階段讓巨石應用在營運上卓越；只有在第二階段才應提取第一個服務。

總結

應用程式現代化是與遷移截然不同的獨立學科，SAP-C02 考試獎勵那些能為特定情境識別出在 Rehost-Replatform-Refactor 階梯上正確位置的考生。AWS 原生現代化工具箱——容器化用 App2Container、漸進式 Strangler Fig 路由用 Refactor Spaces、.NET 拆解分析用 Microservices Extractor、平台工程用 Proton、資料庫現代化用 DMS 加 SCT、事件驅動解耦用 EventBridge 加 Kinesis 加 MSK、Session 外部化用 ElastiCache 加 DynamoDB，以及務實 AI 注入用受管 AI 服務——涵蓋了考試所有現代化題目。典型的 15 年 Java 巨石應用情境，將這些工具整合進一個三階段九個月的路線圖：第 1–3 個月完成 Replatform 基礎，第 4–7 個月完成 Strangler Fig 與第一個服務提取，第 7–9 個月完成額外的服務提取。掌握順序、反模式和陷阱答案——過早拆分、共享資料庫、兩階段提交、大爆炸式 Refactor——是 Task Statement 4.4 及格與優秀之間的分水嶺。

當你在考試當天閱讀應用程式現代化 Prompt 時，先做階梯檢核（業務限制要求哪層階梯），再做工具箱檢核（哪些 AWS 服務符合目標架構），最後做反模式檢核（有沒有誘餌答案倡導已知的失敗模式）。有了這三個步驟，現代化題目就從記憶練習變成結構化決策，通過 Task 4.4 的路徑變得持續可重複。