搜尋
隨著企業雲端環境從「基礎設施遷移與維運」邁向「AI 原生、服務網格化與極致彈性工程」，AWS 最頂級的架構師認證迎來了歷史性的升級。
即將於 2026 年 10 月 27 日開放註冊的 AWS Certified Solutions Architect - Professional（SAP-C03），正式告別過往聚焦於傳統混合雲路由、經典遷移策略與單體多帳號架構的設計思維。新版考綱重構為五大核心架構領域，並將跨帳號自主代理（Agentic AI）、Amazon VPC Lattice 服務網格以及 AWS FIS（Fault Injection Service）混沌工程列為核心指標題型。
本文深度剖析這三大關鍵考核點的架構設計原理與實務選型邏輯。
SAP-C03 將原本較為抽象的四大設計階段重塑為契合現代雲端架構師職責的五大領域：
+-----------------------------------------------------------------------------------------+
| SAP-C03 五大架構領域核心模型 |
+-----------------------------------------------------------------------------------------+
│ 領域 1: 雲原生與 AI 應用架構設計 (Cloud-Native & AI Architecture Design) │
│ 領域 2: 安全、合規與跨帳號治理 (Security, Governance & Post-Quantum Cryptography) │
│ 領域 3: 高效能與成本最佳化 (High Performance & FinOps Infrastructure) │
│ 領域 4: 系統韌性與業務連續性 (Resilience, Chaos Engineering & Disaster Recovery) │
│ 領域 5: 現代維運與自動化卓越 (Modern Operations & Observability) │
+-----------------------------------------------------------------------------------------+在此架構下，跨帳號 Bedrock AgentCore、VPC Lattice 與 AWS FIS 分別代表了智慧應用整合、現代網路拓撲與主動可靠性工程的技術巔峰。
在 SAP-C02 時代，AI/ML 題目多偏向 SageMaker 託管訓練叢集或一般 API 呼叫；而在 SAP-C03 中，架構師必須設計企業級多代理協同系統（Multi-Agent System）。
大型企業通常具備多帳號（Multi-Account）結構：AI 核心模型資產部署於專屬的 AI Core 帳號，而實際業務邏輯（如 ERP 訂單處理、人資薪酬資料）則分散在各個業務應用帳號（LOB Accounts）。傳統單一帳號部署代理的做法無法滿足最小權限原則與資料隔離合規。
AgentCore 模組化編排：使用 Bedrock AgentCore Runtime 作為伺服器less執行環境，協調具備特定專長的子代理（如查詢代理、審批代理、執行代理）。
跨帳號 Action Group 委派：透過 Resource-based Policies 與 IAM 角色扮演（sts:AssumeRole），讓 Central Agent 能安全調用分散於不同業務帳號內的 AWS Lambda 函數（Action Groups），執行後端 API。
企業級知識檢索隔離：中央代理調用跨帳號的 Amazon OpenSearch Serverless（AOSS）或 Aurora PostgreSQL pgvector 時，必須結合 AWS KMS 跨帳號金鑰共用與嚴格的 IAM Condition（如 aws:PrincipalOrgID）限制存取邊界。
在過去，實現數十個 VPC 與跨帳號微服務互通，標準答案往往是 AWS Transit Gateway（TGW）結合共享 VPC 與複雜路由表，但這種設計面臨著 CIDR 網段衝突、IP 重疊與第四層（L4）缺乏應用層身分感知的致命瓶頸。
| 維度 | AWS Transit Gateway (TGW) | Amazon VPC Lattice (SAP-C03 重點) |
| 運作層級 | 網路層 / 傳輸層（OSI Layer 3 / 4） | 應用層（OSI Layer 7） |
| IP 規劃與 CIDR | 必須嚴格規劃，不可重疊；重疊需透過 Private NAT 轉換 | 完全不受 CIDR 重疊影響，以服務名稱與 DNS 為導向 |
| 通訊拓撲 | 需配置繁瑣的路由表、傳輸閘道關聯與附件（Attachments） | 透過 Service Network 邏輯關聯，無需修改底層 VPC 路由表 |
| 身分安全驗證 | 主要仰賴安全性群組（Security Groups）與 NACL 控制 IP | 原生的 SigV4 授權策略（Auth Policy），以 IAM 身分治理請求 |
| 微服務流量管理 | 需額外自建 ALB、NLB 或 Envoy 代理 | 原生支援加權路由、藍綠部署、金絲雀發布與 Path-based 路由 |
情境：企業透過收購獲得多個現有 AWS 環境，各帳號的 VPC 均使用了相同的 10.0.0.0/16 網段，且需要讓各系統內的容器服務（ECS/EKS）安全通訊。
架構解答：不再推薦繁複的 Secondary CIDR 擴展或 Private NAT 閘道，而是建立中央 VPC Lattice Service Network，將各帳號的服務關聯至該網路，並配置 IAM Auth Policies 實現無 IP 依賴的跨帳號安全互通。
高階架構師不能只在白板上聲稱架構「具備 99.999% 高可用性」，必須具備主動注入破壞並驗證自動復原的工程能力。
在 SAP-C03 考評中，AWS Fault Injection Service (FIS) 成為評測 Multi-Region 活體架構（Active-Active）與跨可用區（Multi-AZ）韌性的核心工具。
跨區域網路黑洞與中斷模擬：
利用 AWS FIS 實驗範本（Experiment Templates），針對跨區域 VPC Peering、Transit Gateway Peering 或 DynamoDB 全域資料庫（Global Tables）注入人工網路延遲或中斷。
Availability Zone 斷網實戰：
配合 Amazon Route 53 Application Recovery Controller (ARC) 實施分區感知（Zonal Shift），使用 FIS 模擬單一 AZ 內所有 EC2/RDS 實例同時失效，驗證健康檢查是否能在秒級將流量自動切換至其他可用區。
安全停止條件（Stop Conditions）：
架構師在設計 FIS 實驗時，考題會著重於如何配置 CloudWatch Alarms 作為「緊急熔斷條件（Stop Conditions）」，確保在生產環境進行混沌工程實驗時，一旦業務錯誤率（如 HTTP 5xx）超過臨界值，能立即中止實驗並自動回滾。
破除舊有思維慣性：遇到跨 VPC 微服務整合時，優先評估是否為 L7 應用通訊；若涉及跨帳號服務發現與非重疊路由負擔，VPC Lattice 是優先考量選項。
掌握 Agentic 治理邊界：熟悉 Amazon Bedrock AgentCore 的組成結構，重點理解 IAM 跨帳號 AssumeRole 與 OpenAPI Schema 定義 Action Group 的整合原理。
深化混沌工程驗證：理解 AWS FIS 的 Target、Action 與 Stop Condition 架構，並與 Route 53 ARC、Multi-Region 資料庫容錯機制串聯複習。
SAP-C03 的演進清晰地表明：現代架構師的價值，在於能否以雲原生安全網格連接服務，以智慧代理驅動業務流，並以受控的混沌實驗打造無懼故障的極致韌性系統。