效能架構：快取、儲存與專用資料庫

AWS 的效能架構是一種在發生延遲事故之前——而非之後——就選好正確運算形狀、儲存層、網路拓撲、資料庫引擎與快取層的學科。在 SAP-C02 中，效能架構屬於 Domain 2，Task Statement 2.5（「設計能達成效能目標的方案」），並直接落在 Well-Architected Performance Efficiency 支柱之內。每一道效能架構考題本質上都是選擇與取捨的問題：專用工具勝過通用工具，多層快取勝過單體快取，專用資料庫勝過一刀切的關聯式資料庫，而只要業務規則允許，非同步就勝過同步。

本指南假設你已具備 Associate 等級知識（EC2 實例族群字母識別、S3 儲存類別名稱、RDS 與 DynamoDB 基礎、CloudFront 基本概念），並聚焦在 Pro 等級的效能架構決策：何時 Graviton4 是正確的遷移目標、何時 io2 Block Express 是浪費預算、何時 DAX 優於 ElastiCache、何時 Global Accelerator 優於 CloudFront、何時 Aurora Serverless v2 是錯誤答案，以及如何在 p99 延遲低於 50 毫秒的條件下以每秒 10,000 次查詢提供機器學習推論服務。效能架構題常偽裝成成本題——選錯實例族群，預算與延遲都會同時燒掉——因此請全程保持成本效益的視角。

為什麼效能架構在 SAP-C02 如此重要

在 Professional 等級，AWS 期望你了解效能是設計階段的決策，而非執行期的調整旋鈕。考試不會要你調校一條慢查詢；它會要你選對引擎，讓查詢從一開始就不會變慢。典型的 SAP-C02 效能架構情境如下：「一家基因體新創公司必須在三個區域向 10,000 名並發使用者提供 700 億參數模型的推論服務，p99 延遲低於 50 毫秒，月費用低於 USD 120,000。請選出正確的運算、加速器、儲存、網路與快取組合。」沒有任何單一服務能回答這個問題——只有整合的效能架構才能做到。

考試也測試你快速排除錯誤效能架構答案的能力。如果你看到「通用型 M7i」用於 ML 訓練工作負載，還沒讀完句子就已經是錯的。如果你看到「CloudFront」用於有狀態的低延遲 TCP/UDP 遊戲伺服器，也是錯的。如果你看到「Lambda provisioned concurrency」在 100,000 QPS 穩態下，數學計算大概也是錯的。效能架構給你這些快速排除的直覺。

白話文解釋 Performance Architecture

效能架構涉及許多環節。以下四個來自不同領域的類比能幫助你把概念牢牢記住。

類比一：工廠生產線

把效能架構想像成台灣的工廠生產線。通用型工作站（M-family EC2）適合一般組裝工序，但你不會用它來跑高精密 CNC 加工——那需要專用加工機台（P-family GPU 做 ML 訓練），而批量重複的精密測試則需要專用測試治具（Inf-family 做推論）。倉庫冷凍庫是 Amazon S3 Glacier Deep Archive——便宜，但取件要等；備料區是 S3 Standard——隨時可取，成本適中；生產線旁的工料架是 S3 Express One Zone——取用最快、成本最高、單站儲存；機台操作員桌面是 Instance Store NVMe——就在手邊、存取最快，但一斷電桌上的東西全消失（暫存）。

快取層是生產線的備料前置工序（mise en place）——零件預先裁切、預先排列、按批放在越來越靠近工作站的料架上。CDN 邊緣快取是出貨端的成品包裝區，已打包等待出貨。ElastiCache 是生產線旁的小型備料冰箱。DAX 是只為一種零件設計的專用備料架（DynamoDB 項目）——放不了其他東西。RDS Performance Insights 是產線看板系統，告訴你哪個站台在出貨高峰時是瓶頸。

類比二：圖書館參考台

DynamoDB 的存取模式很像圖書館。DynamoDB 表是整座圖書館；partition key 是杜威十進位分類架位。選擇好的 partition key 能把請求均勻分散到各架；選錯（所有人都要同一本書）就會造成熱架，館員再快也不夠用。Adaptive capacity 是圖書館悄悄為那個熱門架位增派一名助理館員。

DAX 是剛剛借閱的書推車，就停在參考台旁邊——館員直接從推車上回答「你有 X 嗎？」，不用走回書架，回覆時間縮短到微秒。ElastiCache 放在 DynamoDB 前端則像在隔壁街道再租一間圖書館，手動把熱門書複製過去——你得自己決定複製什麼、讓過時的副本失效，還得把讀者引導到正確的建物。DAX 是內建方案；ElastiCache 前端是你在 DAX 有所不足時才自建的方案（強一致快取命中、跨表彙總或跨 DynamoDB 與其他服務共用快取）。

類比三：高速公路網絡

網路效能就像台灣的高速公路系統。公共網際網路是混合車流的平面道路——不可預測，尖峰時段塞車。CloudFront 是遍布各地的交流道便利商店，把商品預先備在客戶附近，讓他們不必開長途去工廠取貨。Global Accelerator 是ETC 快速匝道，讓你從最近的 anycast 入口快速上 AWS 私有骨幹網路（高速公路），比走公共網路快得多。對於有狀態的 TCP/UDP 流量，如遊戲伺服器或 IoT——這些 CloudFront 不處理的流量——Global Accelerator 就是高速公路；CloudFront 只是只賣 HTTP(S) 的交流道便利商店。

Placement Group — Cluster 是 F1 賽車的維修站：所有車輛緊密停放在同一個車庫，讓組員通訊以微秒計算——搭配 EFA 可達到節點間次 10 微秒延遲。Placement Group — Spread 是反過來：車停在不同賽道以隔離故障。Partition placement 是折衷方案——一百輛車分布在七個車庫，車庫內通訊緊密，車庫間各自獨立——適合 HDFS/Cassandra 這類已在應用層建模故障域的系統。

類比四：醫院急診分流

非同步與串流效能架構就像醫院的急診分流。同步 API 是急診室——每位病患必須診療完畢才能進下一位。SQS 佇列是候診室——病患等候，醫師按自己的節奏叫號，即使一次湧入五十位事故傷患也不會讓醫院崩潰。Kinesis Data Streams 是生命跡象遙測串流——持續、有序、可重播，每台儀器即時推送資料，多個消費者（心臟科、加護病房、分析系統）各自獨立讀取。Step Functions Express 是五分鐘快速分流協定——每次工作流程費用低，針對高量短時工作最佳化。Step Functions Standard 是完整入院協定——執行時間更長、可稽核、可等待人工核准或七天後的回呼。

效能架構決策框架

在深入任何服務細節之前，先將 Well-Architected Performance Efficiency 支柱針對每個新設計提出的四個問題內化。每道 SAP-C02 效能架構考題本質上都是這四個問題之一的變形。

1. 存取模式是什麼？ 讀取密集還是寫入密集？隨機還是循序？鍵值、範圍掃描、圖形遍歷、全文搜尋還是關聯式 Join？答案在考慮其他因素之前就決定了資料庫引擎。
2. 延遲預算是多少？ 次毫秒（DAX、ElastiCache、Instance Store NVMe）？個位數毫秒（DynamoDB、EBS io2 Block Express）？數十毫秒（RDS、S3）？秒級（Athena、Glue）？預算決定層級。
3. 地理分布為何？ 使用者在單一區域、多個區域還是全球？無狀態 HTTP(S) 還是有狀態 TCP/UDP？這決定了 CloudFront、Global Accelerator 或兩者都不用。
4. 流量形狀為何？ 穩定、突發、不可預測還是排程型？形狀決定 Serverless 還是 Provisioned、Auto Scaling 政策類型，以及購買模式（Savings Plan、Spot 還是 On-Demand）。

運算效能 — 專用實例選型

Pro 等級的 EC2 實例選擇不是「CPU 密集用 C-family」——而是知道針對給定工作負載要選哪一世代、哪種加速器、哪種處理器架構，以及了解遷移路徑。

通用型族群與 Graviton4 遷移

• M7i / M7a（x86）：Intel Sapphire Rapids 與 AMD EPYC 第四代——「預設」族群，CPU/記憶體均衡，適合 Graviton 相容性不確定時使用。
• M7g / M8g（Graviton3 / Graviton4）：AWS 自研 ARM 處理器。Graviton4（M8g/C8g/R8g 及同系列）對可重新編譯的 Linux 工作負載，效能價格比比同等 x86 約好 30%。Graviton4 是 2025 年以後 Linux 新專案的正確遷移目標，除非有 x86 獨有的相依性。
• C7i / C7g / C8g：運算最佳化型——記憶體對 CPU 比率低於 M-family，適合 CPU 密集的 Web/API 層。
• R7i / R7g / R8g / X2idn / X2iedn / U-7i：記憶體最佳化型——R-family 用於記憶體內快取與分析；X/U-family 用於 SAP HANA 及超大型記憶體資料庫（U 實例可達數 TB RAM）。

加速運算型 — G / P / Inf / Trn / F / DL 矩陣

加速運算是 SAP-C02 效能架構考題最具體的地方。選錯族群可能讓月費從 USD 200,000 暴增到 USD 200 萬。

• P5 / P5e / P5en / P6（NVIDIA H100/H200/B200）：大型語言模型訓練、CUDA HPC、使用 NCCL 的分散式訓練。這是 AWS 提供的最重、最昂貴的 GPU。P5en 支援 EFA v2，可達多節點次 10 微秒集體通訊。
• G6 / G6e（NVIDIA L4 / L40S）：圖形、小型模型推論、3D 渲染、遠端工作站——費用僅 P-family 的一小部分。
• Inf2（AWS Inferentia2）：純推論自研晶片。對支援的模型架構（Transformer、Diffusion、CNN），每次推論的費效比比同等 GPU 實例最高好 4 倍。「10k QPS LLM 推論最低成本」的正確答案。
• Trn1 / Trn2（AWS Trainium）：純訓練自研晶片。每次訓練費效比比同等 GPU 實例最高好 50%。Trn2（及 Trn2 UltraServer）是「在 AWS 以最低成本訓練 700 億參數模型」的正確答案。
• F2（FPGA）：基因體學、影片轉碼與 ASIC 原型驗證的客製硬體加速。
• DL1 / DL2q（Habana Gaudi / Qualcomm AI 100）：替代深度學習加速器——考試鮮少出現，但值得認識。

儲存最佳化型 — I / D / H

儲存最佳化實例的存在是因為 EBS 對本地 NVMe 需求強烈的工作負載往往不夠快。

• I4i / I4g / I7ie / I8g：本地 NVMe SSD，每個實例可達數百萬隨機 IOPS。適合 EC2 上自管 NoSQL（Cassandra/ScyllaDB/ClickHouse）、大型 OLTP 快取、高 Throughput 日誌處理。資料為暫存——實例停止或終止即失去儲存。
• D3 / D3en：本地 HDD，每節點數十 TB。適合分散式檔案系統（HDFS/MapReduce）、EC2 上的資料倉儲。
• H1：混合儲存最佳化，舊世代——新設計大多已被 D3 取代。

Nitro Enclaves — EC2 實例內的隔離運算

AWS Nitro Enclaves 不是獨立的實例族群，而是 Nitro 型實例的一項功能。Enclave 是從父 EC2 實例中切割出來的隔離虛擬機器，無持久儲存、無網路、無操作員存取——它的存在僅為了處理機密資料。你只能透過 vsock（virtio sockets）與 enclave 通訊，enclave 提供 KMS 可驗證的加密證明文件，KMS 確認後才釋放金鑰。

SAP-C02 中 Nitro Enclaves 是正確答案的情境：

• 在切割出的 enclave 中處理支付卡資料（縮小 PCI DSS 範圍），同時父實例處理非敏感工作。
• 多方運算或隱私保護 ML，訓練集絕不可被實例操作員讀取。
• 以證明文件閘控 KMS 金鑰存取，用於密碼學簽署服務。

Graviton 遷移策略

SAP-C02 的重複情境：「一個由 2,000 台 M5 EC2 實例組成的機隊必須在不重新架構的前提下降低 30% 成本。」正確答案通常是依照以下步驟進行 Graviton 遷移：

1. 使用 AWS Compute Optimizer 的 Graviton 建議盤點語言執行環境——它會標出哪些工作負載已具備 Graviton 相容性。
2. 透過 AWS CodeBuild ARM 建置器或 Docker Buildx，將容器映像重建為多架構（arm64 + x86_64）。
3. 先在 ALB 後方的非生產環境混合目標群組中推出，觀察 p50/p99 與錯誤率。
4. 逐步轉移流量；過渡期間使用 EC2 Auto Scaling 混合實例政策，同時包含 m6g.large 與 m6i.large。
5. 穩定指標持續兩週後淘汰 x86，將 Savings Plans 承諾從 EC2 特定方案更新為 Compute Savings Plan（Compute SP 跨族群與架構通用）。

儲存效能 — EBS io2 Block Express、FSx、S3 Express 與 Instance Store

Pro 等級的儲存選型取決於 IOPS、Throughput、延遲、耐久性，以及資料是否能在實例停止後存活。

Amazon EBS 磁碟區類型選擇

• gp3：通用型 SSD。基準 3,000 IOPS 與 125 MB/s，可獨立佈建至 16,000 IOPS 與 1,000 MB/s。大多數新工作負載的預設選擇。
• io2 / io2 Block Express：高效能 SSD，99.999% 耐久性。io2 Block Express 每個磁碟區提供最高 256,000 IOPS 與 4,000 MB/s，次毫秒延遲，64 TiB 容量。適合 I/O 密集型資料庫（Oracle、EBS 上的 SAP HANA、高量 OLTP）。
• st1 / sc1：Throughput 最佳化 HDD 與冷 HDD——僅適合循序 Throughput 工作負載（日誌處理、資料倉儲附加）。
• gp2（舊版）：突發信用額度模式；新設計應避免使用——gp3 更便宜且更可預測。

FSx 族群 — 專用共用檔案系統

• FSx for Lustre：專為 HPC 與 ML 訓練設計。提供數百 GB/s Throughput 與數百萬 IOPS，原生整合 S3（工作集延遲載入、完成後匯出）。「分散式 ML 訓練跨 256 個 GPU 節點讀取 50 TB 資料集」的正確答案。
• FSx for NetApp ONTAP：具備快照、複製、SnapMirror 複寫的企業 NFS/SMB。「將現有 NetApp 工作負載遷移至 AWS 且不需重新架構」的正確答案。
• FSx for Windows File Server：具備 Active Directory 整合與 DFS 的 SMB。適合 Windows 工作群組檔案分享。
• FSx for OpenZFS：POSIX 相容，具備快照、複製，適合高 IOPS 的交易型檔案工作負載。

S3 效能架構

S3 是大規模平行的，但前提是你為此設計。

• S3 Standard：預設，多 AZ，11 個九耐久性，第一位元組延遲約 100 毫秒。每個前綴每秒可擴展至數千個請求。
• S3 Intelligent-Tiering：自動在 Frequent / Infrequent / Archive Instant / Archive / Deep Archive 間分層，附帶少量每月監控費用。適合存取模式未知或隨時間變化的資料的正確預設選擇。
• S3 Express One Zone：單 AZ，一致的個位數毫秒第一位元組延遲——小物件延遲比 S3 Standard 低最多 10 倍，代價是單 AZ 耐久性。「在單一 AZ 內重複存取的 AI/ML 訓練資料集」或「直接在 S3 上進行延遲敏感的互動式分析」的正確答案。
• S3 Standard-IA / One Zone-IA：不頻繁存取，最低 30 天；取件費用適用。
• S3 Glacier Instant Retrieval / Flexible Retrieval / Deep Archive：封存層，取件 SLA 從毫秒到 48 小時不等。

效能模式：

• 對超過 100 MB 的物件使用分段上傳（multipart upload）；分段平行化與重試粒度是讓 S3 在大型檔案上快速運作的關鍵。
• 當全球客戶端上傳至單一儲存桶時，使用 S3 Transfer Acceleration——客戶端連到最近的 CloudFront 邊緣節點，再透過 AWS 骨幹到達儲存桶所在區域。
• 對於每秒數百萬個請求，將請求負載分散至多個鍵前綴；每個前綴的限制為每秒 3,500 次 PUT/POST/DELETE 與 5,500 次 GET/HEAD。
• 對平行處理的大型物件（Athena、Spark）啟用 S3 Byte-Range Fetches。

Instance Store（暫存 NVMe）

I-family 本地 NVMe 提供數百萬隨機 IOPS，延遲低於 100 微秒——比任何 EBS 磁碟區都快。使用場景：

• 快取層，資料可從上游重建（EC2 上保存預運算結果的 Redis/KeyDB）。
• Spark/MapReduce 中 Shuffle/Sort 的暫存空間。
• 跨節點複寫的自管資料庫的交易日誌（ScyllaDB、Aerospike）。

絕對不要將 Instance Store 用於無法重建的資料——停止/終止即失去資料。

網路效能 — Placement Groups、EFA、Global Accelerator vs CloudFront

網路是 SAP-C02 最愛深入探查的層次，因為選錯元件差距可達一個數量級。

Placement Groups — Cluster、Partition、Spread

• Cluster placement group：所有實例置於同一機架，達成低延遲、高頻寬的節點間通訊。搭配 EFA，在支援的族群上可達節點間次 10 微秒延遲，每實例最高 3,200 Gbps。適合緊耦合 HPC、分散式 ML 訓練、記憶體內分析。
• Partition placement group：實例分布在每 AZ 最多 7 個邏輯分割；兩個分割不共用硬體。適合自行建模故障域的分散式系統（HDFS、Cassandra、Kafka）——複本跨分割配置。
• Spread placement group：每個實例位於不同硬體，最大化故障隔離。每 AZ 限制 7 個實例。適合少量關鍵有狀態實例。

Elastic Fabric Adapter (EFA)

EFA 是特殊的 EC2 網路介面，繞過作業系統核心進行集體通訊——是讓 MPI 與 NCCL 效能接近地端 HPC 的唯一途徑。適用於 P4/P5/Trn1/Trn2/C5n/C6i/C7i/HPC6a/HPC7a/HPC7g。以下情況必須使用：

• 使用 NCCL / AllReduce 的多節點 ML 訓練。
• MPI 型 HPC 模擬（CFD、氣象、分子動力學）。
• 節點間 RPC 量高的分散式記憶體資料庫。

Global Accelerator vs CloudFront — 決策樹

這是 Pro 等級中最常考的網路效能架構決策。

• Amazon CloudFront 是內容傳遞網路（CDN）。它在邊緣節點快取 HTTP(S) 回應，在邊緣終止 TLS 並向 ALB/NLB/S3/自訂來源發起請求。它不承載原始 TCP/UDP。當工作負載是 Web/API 內容、串流影片、靜態資源，且加速來源為快取加上 TLS 終止時使用。
• AWS Global Accelerator 是網路加速器。它提供兩個靜態 anycast IP，將客戶端路由至最近的邊緣節點，再透過 AWS 全球骨幹網路到達區域端點（ALB、NLB、EC2、Elastic IP）。它接受 TCP 與 UDP，保留來源 IP，並確定性地路由有狀態連接。它不快取內容。當工作負載是非 HTTP（遊戲伺服器、VoIP、IoT、MQTT）、需要 sticky 連接的 HTTP API、具備即時容錯移轉的多區域主動式架構，或無法容忍重新握手的有狀態 TCP 時使用。

CloudFront 大規模效能模式

• Origin Shield：邊緣節點與來源之間額外的區域快取層——透過去重邊緣未命中請求來減少來源負載。當許多邊緣節點各自未命中同一個來源物件時使用（熱門資源的典型情況）。
• 快取行為（Cache behaviours）：路徑型快取政策、TTL 覆寫、查詢字串正規化。對高快取命中率至關重要。
• CloudFront Functions（在每個邊緣執行、次毫秒、每毫秒數十個請求）vs Lambda@Edge（在區域邊緣執行、毫秒級、完整 Node/Python 執行環境）。Functions 用於 header/URL 改寫；Lambda@Edge 用於任何需要 SDK 呼叫或大型程式碼的場景。
• Origin Access Control (OAC)：取代舊版 Origin Access Identity 用於 S3——以 SigV4 正確簽署請求並支援 KMS 加密的儲存桶。

資料庫效能 — 專用資料庫、Aurora Pro 深度、DynamoDB 模式

在 Pro 等級，你不應該預設選「RDS」——考試期望你將存取模式對應到正確引擎，再在該引擎內選擇正確的形狀。

專用資料庫選型矩陣

• 嚴格一致性的關聯式 OLTP → Amazon Aurora（MySQL/PostgreSQL 相容）或 RDS。
• 超出單一寫入者限制的大規模關聯式 OLTP → Aurora Limitless Database。
• 任意規模的鍵值/文件 → Amazon DynamoDB。
• 圖形遍歷（詐欺偵測、社群、知識圖） → Amazon Neptune。
• 時序（IoT、指標、日誌） → Amazon Timestream。
• Cassandra 相容的寬列 → Amazon Keyspaces。
• 搜尋與日誌分析 → Amazon OpenSearch Service。
• 帳本/不可變稽核 → Amazon QLDB（正逐漸被 Aurora PostgreSQL 加區塊鏈擴充套件取代，但仍為考試相關內容）。
• 記憶體快取 → ElastiCache for Redis/Valkey/Memcached，或需要耐久性的 MemoryDB for Redis。

Aurora Pro 深度 — Serverless v2、Limitless、Global Database、Parallel Query

Aurora 是 SAP-C02 中關聯式引擎的重點考測對象。

• Aurora Serverless v2：以半 ACU 為增量線上擴展（0.5 ACU ≈ ~1 GiB RAM + 比例 CPU），從設定的最小值到設定的上限。適合變動或不可預測的工作負載。與 v1 不同，v2 擴展不會中斷連線，且支援讀取複本、Global Database 與 RDS Proxy。預設最低 0.5 ACU 表示它不再是「縮放至零」，但較新版本提供 0-ACU 選項供開發/測試使用。
• Aurora Limitless Database：水平分片的 Aurora PostgreSQL。自動將表格分布於多個運算分片，對大多數查詢對應用程式透明。當「單一寫入者無法承受 100,000+ 次寫入/秒」且應用程式相容 PostgreSQL 時的正確答案。
• Aurora Global Database：跨區域複寫，典型延遲低於一秒，次分鐘 RPO，以及透過受管容錯移轉達到一分鐘或更好的 RTO。主要特色：次要區域可在約 1 分鐘內升格為主要區域並開始接受寫入。適合具備積極 RTO/RPO 的多區域主動被動架構，以及透過每個區域的唯讀複本降低全球讀取延遲。
• Aurora Parallel Query：將 SQL 處理推入 Aurora 儲存層，跨數千個儲存節點執行，大幅加速 OLTP 資料庫上的長時間執行分析查詢。當 OLTP 與輕度 OLAP 共存於同一個 Aurora 叢集時啟用。

DynamoDB Pro 深度效能模式

• Partition key 設計佔 DynamoDB 效能的 80%。 熱 partition key（所有寫入流向同一個使用者 ID、所有讀取流向同一個商品 SKU）無論佈建了多少容量都會被節流。以高基數屬性組合鍵；當單一邏輯實體承受不成比例的流量時，使用寫入分片（user#<id>#<0–9>）。
• Adaptive capacity 在表內跨分割重新分配 Throughput——持續執行、無需設定。它能緩解但無法消除不良的鍵設計。
• On-demand 容量模式：按請求計費，無需佈建，可即時擴展至前次峰值的 2 倍。適合不可預測或新的工作負載。每次請求費用約為完全利用的佈建模式的 7 倍——損益平衡點取決於使用率。
• Provisioned 容量搭配 Auto Scaling：使用率穩定且可預測（70% 以上）時更便宜。Auto Scaling 需數分鐘而非數秒響應——冷突發仍會被節流。
• Global Secondary Indexes (GSIs)：獨立 Throughput，僅支援最終一致。用於替代存取模式。GSI 熱鍵問題與基礎表獨立存在。
• Local Secondary Indexes (LSIs)：共用基礎表分割容量，必須在表建立時定義，強一致。盡量少用；複合 GSI 通常是更好的選擇。
• DynamoDB Streams：每個 partition key 有序的變更日誌，保留 24 小時。透過 Event Source Mapping 饋送 Lambda，或透過受管 DDB 至 Kinesis 管道饋送 Kinesis Data Streams。
• TTL：每個項目的到期屬性；DynamoDB 在到期後 48 小時內免費刪除。適合工作階段資料、暫時快取、時效性記錄。TTL 刪除會產生串流事件供下游清理使用。

DAX vs ElastiCache 放在 DynamoDB 前端

• DAX 是內建的項目/查詢/掃描快取。快取命中為微秒延遲。直寫策略：寫入同步通過 DAX 到 DynamoDB。讀取僅支援最終一致——強一致讀取繞過 DAX。適合具有重複鍵讀取的讀取密集型 DynamoDB 工作負載。
• ElastiCache 放在 DynamoDB 前端是手動模式：應用程式寫入 DynamoDB 並使 ElastiCache 條目失效/更新。工作量更多、失效模式更多，但在以下情況適合：
  • 快取必須跨 DynamoDB 與其他資料來源共用（例如來自 DDB + RDS 的 Join 結果）。
  • 快取必須提供強一致命中（可透過單一寫入者快取設計實現，DAX 不支援）。
  • 需要自訂資料結構（Sorted Sets、Streams、Pub/Sub）——只有 Redis/Valkey 提供這些。

OpenSearch 搭配 UltraWarm 與 Cold Storage

OpenSearch 管理熱、UltraWarm 與 Cold 三個層，讓你不必把一年的日誌都放在 SSD 上。

• 熱層：帶有 EBS SSD 的資料節點，以全速查詢完整索引。
• UltraWarm：S3 支撐，查詢延遲約為熱層的 10 倍，每 GB 成本約為熱層的 1/10。適合 30 到 90 天的日誌保留。
• Cold Storage：S3 支撐，從叢集分離——只有在重新附加後才可查詢。適合 90 天以上且可接受臨時查詢的保留需求。
• Index State Management (ISM) 政策自動化各層之間的轉換。

RDS Performance Insights

RDS Performance Insights 提供資料庫的由上而下負載視圖——按等待事件、SQL 陳述式、使用者與主機分類的平均活躍工作階段（AAS）。這是以下情況的正確診斷工具：

• 找出消耗最多 CPU 的 SQL 陳述式。
• 將鎖定等待歸因至特定查詢。
• 付費層 2 年保留期的長期效能趨勢分析。
• 與 DevOps Guru for RDS 整合以自動偵測異常。

快取層級 — Browser → CloudFront → ElastiCache → DAX → Origin

大規模效能架構就是多層快取。請求在鏈路中越早被服務，速度越快、成本越低。

1. Browser 快取（HTTP Cache-Control + ETag）。從客戶端以零毫秒服務。設定 CloudFront 為不可變資源（雜湊命名的 bundle）發出含有長 max-age 的正確快取標頭。
2. CloudFront 邊緣快取。從最近的邊緣節點以數十毫秒服務。調整快取行為、查詢字串正規化、Cookie 轉發與 Origin Shield，讓靜態資源的快取命中率超過 90%。
3. Global Accelerator（不可快取的 TCP/UDP 可選用）。路由繞過公共網際網路，但不快取內容。
4. 區域快取 — ElastiCache / DAX / MemoryDB。從記憶體節點以微秒至低毫秒服務。ElastiCache 用於通用快取與共用狀態；DAX 專門用於 DynamoDB 項目；MemoryDB 用於快取必須在節點故障後存活且需要耐久性的場景。
5. 讀取複本（Aurora/RDS）。從複本提供讀取以減輕寫入者負擔。延遲通常低於 100 毫秒，但應用程式必須容忍最終一致性。
6. Origin（Aurora/RDS/DynamoDB/S3）。資料的唯一真相來源。每個抵達 Origin 的請求，成本和時間都高於任何快取層。

快取大小調整與驅逐策略

• 時間型驅逐（TTL）：預設；當 x 秒的過時可接受時適用。
• 直寫失效：應用程式在每次寫入時使快取失效；當需要讀自身寫入時適用。
• 延遲載入（cache-aside）：未命中時填充。簡單，但冷啟動時有大量請求同時打到 Origin 的風險——以請求合併或預熱來緩解。

快取失效模式

• 快取未命中時的雷群效應（Thundering herd）：當一個熱點鍵過期，數千個請求同時打到 Origin。以抖動 TTL、單一飛行（一個請求填充，其他等待）或 SQS 緩衝非同步重填來緩解。
• 重啟時的快取衝刺（Cache stampede）：冷快取重啟驅動一波 Origin 突發流量。以預熱腳本、交錯節點重啟與優雅降級路徑來緩解。
• 部署時的過時快取：以舊程式碼版本為鍵的快取被新程式碼服務。以快取鍵中的版本前綴來緩解（v7:user:123）。

非同步與串流模式 — Kinesis、Lambda、Step Functions Express

並非每個工作負載都能透過同步方式變快。許多工作負載只有透過轉為非同步才能變快。

Kinesis Data Streams + Lambda 實時攝入

Kinesis Data Streams 是有序、可重播、多消費者的串流。其效能模型：

• Shards：每個 Shard 支援 1 MB/秒或 1,000 條記錄/秒寫入；2 MB/秒聚合讀取。透過增加 Shard 來擴展。
• Enhanced fan-out：每個消費者獲得專用的每 Shard 2 MB/秒——當多個消費者需要完整 Throughput 時適用。
• Lambda Event Source Mapping：輪詢 Shard 並以批次呼叫 Lambda。Parallelization factor（1–10）可在保留 partition key 內順序的同時，對同一個 Shard 平行執行多個 Lambda 調用。在相同 Shard 數量下達到 10 倍 Throughput 的正確方案（當每個鍵的順序足夠時）。
• Extended retention：最長 365 天，用於重播情境。

Step Functions Express vs Standard

• Standard：最長 1 年執行時間，恰好一次執行，完整稽核歷史。適合人工介入、長時間執行、可稽核工作流程。按狀態轉換計費。
• Express：最長 5 分鐘執行時間，至少一次執行，日誌記錄至 CloudWatch。按請求 + 執行時間 + 記憶體計費——高量時便宜許多。適合高 Throughput 攝入管線、IoT 事件處理、Serverless 微服務編排。

非同步請求模式

• API Gateway + SQS + Lambda worker：客戶端 POST，API Gateway 立即入隊，Lambda worker 非同步處理，客戶端輪詢狀態。適合會超時的長時間執行請求。
• EventBridge + Lambda：客戶端發布事件，多個消費者訂閱。適合帶過濾的扇出。
• DynamoDB Streams + Lambda：寫入觸發下游處理。適合實體化視圖、搜尋索引、稽核日誌。

情境：10,000 QPS ML 推論服務，p99 < 50 毫秒

將完整效能架構框架套用到典型的 Pro 等級情境。

需求：

• 提供 700 億參數 Transformer 模型的推論服務。
• 穩態 10,000 QPS，峰值 25,000 QPS。
• 端到端 p99 延遲 < 50 毫秒，在客戶端測量。
• 三個區域（us-east-1、eu-west-1、ap-northeast-1），主動式架構。
• 月費上限 USD 120,000。
• 查詢中的個人識別資訊（PII）絕不可離開 Enclave；金鑰材料由 KMS 保護。

效能架構：

1. 運算 — Inferentia2 (inf2.48xlarge)。Inferentia2 為主流 Transformer 提供最佳每次推論費效比。Neuron SDK 從 PyTorch 編譯模型。每個區域 12 台 inf2.48xlarge（共 36 台），每月保留等效費用約 USD 2,500——運算費用約 USD 90,000/月。GPU（P5）費用將高出 3–4 倍。
2. 加速儲存 — FSx for Lustre 連結至 S3。模型權重暫存於 Lustre，冷啟動載入時間達次毫秒；S3 是具備跨區域複寫的授權儲存。
3. Tokenization 與 PII 清除 — Nitro Enclaves。原始查詢進入 Enclave；PII 清除在 Enclave 內完成；只有清除後的提示才離開。KMS 在釋放加密金鑰前對 Enclave 進行認證。
4. 網路 — Global Accelerator 搭配區域 NLB 端點。靜態 anycast IP 將客戶端路由至最近的健康區域；即時區域容錯移轉。保留來源 IP 用於稽核。CloudFront 在此不適用，因為推論回應是不可快取的逐請求結果。
5. 快取 — ElastiCache for Valkey 放在模型層前端，用於確定性提示（重複查詢）。即使 20% 的命中率也能移除每秒 2,000 次推論呼叫。以 MD5 雜湊提示為鍵的 cache-aside 模式，TTL 5 分鐘。
6. 中繼資料儲存 — DynamoDB on-demand 用於請求中繼資料與使用者工作階段狀態。On-demand 在無節流的情況下處理 2.5 倍峰值。工作階段讀取路徑前端的 DAX（p99 < 5 毫秒）。
7. 非同步稽核日誌 — Kinesis Data Firehose → S3 → Athena。每次推論發出一條稽核記錄；Firehose 緩衝並以區域/日期/小時分區交付至 S3，供 Athena 分析而不增加即時成本。
8. 區域資料 — Aurora Global Database 用於使用者與計費資料。寫入者在 us-east-1，eu-west-1 與 ap-northeast-1 各有唯讀複本，讀取延遲低於 50 毫秒；跨區域寫入者容錯移轉 RPO < 1 秒。
9. 可觀測性 — Aurora 的 RDS Performance Insights + Lambda/Inferentia runner 的 CloudWatch Embedded Metrics Format + X-Ray 端到端追蹤。p99 延遲在每一層追蹤。

延遲預算分解（目標端到端 p99 < 50 毫秒）：

• 客戶端 → Global Accelerator 邊緣：5 毫秒
• Global Accelerator 骨幹 → 區域 NLB：5 毫秒
• NLB → Inferentia Pod：2 毫秒
• Tokenization（Nitro Enclave）：3 毫秒
• DAX 工作階段查詢：2 毫秒
• 推論（命中快取）：3 毫秒 /（未命中快取）：30 毫秒
• 回應路徑：5 毫秒
• 未命中快取 p99 預算總計：~50 毫秒 ——沒有餘裕；快取命中與平行 Tokenization 才能建立緩衝。

效能監控與驗證

效能架構若無持續量測就不算完整。

• Amazon CloudWatch：基線指標、複合告警、異常偵測、儀表板。在 DynamoDB 上使用 Contributor Insights 找出生產環境中的熱 partition key。
• AWS X-Ray：跨 Lambda、API Gateway、Step Functions、ECS、EKS 的分散式追蹤。找出哪個跳點擁有 p99 延遲的正確工具。
• RDS Performance Insights：資料庫層等待事件分析（見上文）。
• CloudWatch RUM（Real-User Monitoring）：來自實際終端使用者的瀏覽器端延遲。
• CloudWatch Synthetics：量測端到端可用性與延遲的腳本化 Canary。
• AWS DevOps Guru：跨應用程式、RDS、Lambda 指標的 ML 型異常偵測——無需閾值調整即可浮現效能衰退。
• Compute Optimizer：EC2、Lambda、EBS、ECS、ASG 的持續右型建議。

常見陷阱與快速排除直覺

• 「對 UDP 工作負載使用 CloudFront」 → 錯，CloudFront 僅支援 HTTP(S)。使用 Global Accelerator。
• 「使用 DAX 做強一致讀取」 → 錯，DAX 僅提供最終一致。
• 「對 95% 時間閒置的工作負載使用 Aurora Serverless v2」 → 檢查最低 ACU 底限是否讓它比小型佈建或 DynamoDB on-demand 更貴。
• 「對 Web 應用程式資料庫使用 io2 Block Express」 → 通常規格過高；除非明確需要 > 16,000 IOPS 或次毫秒一致性，gp3 已足夠。
• 「使用 P5 做推論」 → 可行但昂貴；Inf2 是主流 Transformer 推論的成本最佳答案。
• 「在 100,000 QPS 穩態下使用 Lambda provisioned concurrency」 → 可行但費用過高；該規模下容器（Fargate）或 EC2 可能更便宜。
• 「使用 Nitro Enclaves 隔離不可信租戶程式碼」 → 錯，使用 Firecracker（透過 Fargate/Lambda）或容器。
• 「使用 Instance Store 作為記錄型交易日誌」 → 錯，它是暫存的。
• 「使用 CloudFront Functions 進行 SDK 呼叫」 → 錯，使用 Lambda@Edge；Functions 無法存取 SDK。
• 「對 50 台 EC2 實例使用 Spread placement group」 → 錯，Spread 每 AZ 限制 7 個實例；使用 Partition 代替。
• 「使用 Kinesis Data Firehose 進行重播」 → 錯，Firehose 是 fire-and-forget；使用 Kinesis Data Streams 做重播。
• 「使用 Aurora Global Database 進行多區域主動式寫入」 → 只有使用次要區域的write-forwarding 才正確；否則 Aurora Global Database 只有一個寫入者區域。真正的多主寫入，請使用 DynamoDB Global Tables 或區域內的 Aurora Limitless。

決策矩陣 — 哪個元件對應哪個效能目標

常見問題

何時應使用 DAX 而非 ElastiCache 放在 DynamoDB 前端？

當工作負載是簡單的讀取密集型 DynamoDB 模式且使用最終一致讀取時，使用 DAX——DAX 是專門設計的、受管的，且只需交換 SDK 客戶端即可，無需應用程式其他變更。只有當你需要 DAX 缺少的功能時，才在 DynamoDB 前面使用 ElastiCache（Redis 或 Valkey）：強一致快取命中、跨來源快取（DynamoDB + RDS + 計算結果）、自訂資料結構（Sorted Sets、Streams、地理空間），或跨服務共用快取。執行 ElastiCache 的成本與營運開銷較高；只有當你能說出具體的 DAX 限制時才選它。

現在應該遷移至 Graviton4 嗎？

對於 Linux 工作負載，如果你的相依性有 ARM 建置版本——2025 年幾乎所有主流執行環境（Java、Python、Node.js、Go、Rust、.NET）都有——答案是肯定的。Graviton4 通常比同等 x86 提供 30% 更好的效能價格比。遷移步驟：使用 Compute Optimizer 盤點、將容器映像重建為多架構、在混合實例 ASG 後方推出至非生產環境、驗證 p99 指標，然後轉移生產環境。遷移期間保留 Compute Savings Plans（而非 EC2 Instance Savings Plans），讓承諾跨架構適用。應留在 x86 的工作負載：使用 x86 專有函式庫的工作負載（如今已罕見）、EC2 上的舊版 Windows，或任何沒有 ARM 建置版本的 ISV 二進位檔。

Global Accelerator 的額外費用何時值得，相較於 CloudFront？

Global Accelerator 費用約 USD 0.025/小時/加速器，另加資料傳輸費。以下情況值得：工作負載是有狀態的 TCP 或 UDP（遊戲伺服器、VoIP、MQTT、長連線 TCP API）；工作負載需要保留來源 IP；架構是多區域主動式且需要即時容錯移轉；或對你的使用者地理分布而言，使用 AWS 骨幹（而非公共網際網路）的效能提升是可量測的。當工作負載是可快取的 HTTP(S) 內容時，費用不值得——CloudFront 已透過邊緣快取加上 TLS 終止提供加速。部分高流量架構兩者並用：靜態資源與公開 HTML 用 CloudFront，有狀態 API 層用 Global Accelerator。

對於新的 OLTP 工作負載，如何在 Aurora Serverless v2、Aurora 佈建版、Aurora Limitless 與 DynamoDB 之間做選擇？

從存取模式開始。如果 Schema 是鍵值型且存取由主鍵決定且存取模式已知，DynamoDB 是效能架構答案——它可擴展至任何 QPS 與任何大小，個位數毫秒延遲，無需管理伺服器。如果工作負載需要 SQL Join、跨多表交易與關聯式模型，選擇 Aurora。在 Aurora 內：Serverless v2 適合工作負載變動或不可預測且需要不中斷連線的自動擴展；佈建版適合工作負載穩定且你想要 Reserved Instance 定價；Limitless 適合單一寫入者無法吸收你的寫入 Throughput 時（通常是 PostgreSQL 上超過 10 萬次寫入/秒）。在上述任何選項之上使用 Aurora Global Database 進行多區域災難復原與讀取就近服務。

在 AWS 訓練大型語言模型的正確實例族群是什麼？

對於主流架構（Transformer、Diffusion 模型、CNN）的成本敏感訓練，AWS Trainium（Trn2 或 Trn2 UltraServer） 通常是正確答案——對支援的模型，每次訓練費效比比同等 NVIDIA GPU 實例最高好 50%，Neuron SDK 處理 PyTorch/TensorFlow 編譯。對於需要最新 NVIDIA CUDA 功能或自訂 Kernel 的前沿模型研究，P5e / P5en / P6（H100/H200/B200） 是正確答案，費用較高。多節點分散式訓練始終搭配 EFA、Cluster Placement Group 與 FSx for Lustre。單節點除錯或小規模微調可使用 G6 或單台 P5。

如何讓全球 API 達到 p99 延遲 SLA 低於 50 毫秒？

組合使用：Global Accelerator 提供保留來源 IP 的骨幹加速網路進入點；至少三個區域的區域主動式部署；DynamoDB 搭配 DAX 或 ElastiCache for Valkey 提供次毫秒熱路徑讀取；透過 SQS 或 Kinesis 的非同步寫入路徑讓寫入不阻塞讀取路徑；CloudFront 放在靜態內容前面以從動態層移除非關鍵流量；以最輕量能達到需求的原件執行運算（Lambda 搭配 provisioned concurrency 達到次 100 毫秒冷啟動、Fargate 用於中等負載、EC2 用於重負載）；以及 X-Ray 端到端追蹤找出每個威脅到預算的跳點。從綜合 Canary（CloudWatch Synthetics）和真實使用者（CloudWatch RUM）測量每區域 p99——兩者都需要才能閉環。

SAP-C02 上最常見的效能架構陷阱是什麼？

三個陷阱最為主要：（1）為加速器工作負載選擇通用型運算——如果情境提到 ML 訓練、HPC 模擬或影片轉碼，非加速器答案幾乎肯定是錯的；（2）為有狀態 TCP/UDP 選擇 CloudFront——Global Accelerator 是所有非 HTTP(S) 可快取內容的答案；（3）對純 DynamoDB 讀取快取選擇 ElastiCache 而非 DAX——DAX 是專門設計的，是正確答案，除非有特定限制排除它。第四個陷阱是在 DynamoDB 才是正確答案時預設選擇 RDS——仔細閱讀「任意規模」、「100k QPS 個位數毫秒延遲」或「Serverless」等指向 DynamoDB 的訊號。

摘要

AWS 的效能架構是一門選擇與取捨的學科：選對運算族群（通用型選 Graviton4、ML 選 Inf/Trn、儲存型選 I/D/H、敏感運算選 Nitro Enclaves）、選對儲存層（gp3 預設、需求 IOPS 選 io2 Block Express、HPC/ML 選 FSx Lustre、單 AZ 低延遲選 S3 Express One Zone、暫存選 Instance Store）、選對網路元件（HPC 選 Placement Groups + EFA、有狀態全球 TCP/UDP 選 Global Accelerator、可快取 HTTP(S) 選 CloudFront）、選對資料庫（規模化關聯式選 Aurora Serverless v2 / Limitless / Global Database、規模化鍵值選 DynamoDB + DAX、搜尋/日誌選 OpenSearch 搭配 UltraWarm），以及多層快取（Browser → CloudFront → ElastiCache/DAX/MemoryDB → 讀取複本 → Origin）。非同步與串流模式（Kinesis、Step Functions Express）完全消除同步瓶頸。在 SAP-C02 中，正確的效能架構答案幾乎始終是一個組合式方案：在每一層指名正確的元件、在有專用工具存在的地方使用專用工具，並透過 X-Ray、RDS Performance Insights 與 CloudWatch 進行端到端量測。掌握快速排除直覺（CloudFront 僅支援 HTTP、DAX 僅支援最終一致、Inf2 是成本最佳推論、Trn2 是成本最佳訓練、Aurora Global Database 容錯移轉約一分鐘、Global Accelerator 保留來源 IP），效能架構題就會成為考試中得分最快的部分。