效能優化：EBS、RDS、EC2 與 S3

效能調校是 AWS SysOps 工程師最安靜、也最難掌握的技能：當應用程式比昨天稍微慢了一點，監控面板看起來幾乎正常，客訴透過 Twitter 側面飛來，而團隊必須在下一次站立會議前找出瓶頸。SOA-C02 Task Statement 6.2 ——「實作效能最佳化策略」——將這項技能歸納為五個運維槓桿：從效能 metrics 推薦運算資源、監控並修改 Amazon EBS、實作 S3 效能功能、監控並調校 RDS，以及啟用 EC2 增強功能。SAA-C03 問的是「這個工作負載選哪種 volume type？」，SOA-C02 問的是「現有 gp2 volume 的 BurstBalance 降到 12% 且持續下滑——runbook 是什麼？」。運算、儲存與資料庫效能調校，是每一個在 Domain 1 學到的 CloudWatch metric 都成為生產環境調校旋鈕的地方。

本指南從 SysOps 角度走過 AWS 效能調校的全流程：哪些 CloudWatch metrics 告訴你 volume 被 throttle、哪些告訴你資料庫出現瓶頸、何時從 gp2 換成 gp3 以及 IOPS 計費會有什麼改變、ModifyVolume 如何讓你在不停機的情況下更改 live volume 的 type、size 與 IOPS、S3 prefix scaling 為何比 bucket 整體吞吐量更重要、Transfer Acceleration 何時值得那筆額外費用、Performance Insights 如何浮現解釋慢查詢的 Top SQL 與 wait events、RDS Proxy 何時能修復連線風暴症狀，以及 Cluster、Spread、Partition 這三種 placement groups 如何影響 HPC、故障隔離與大數據工作負載的網路行為。你會看到 SOA-C02 鍾愛的場景形狀：BurstBalance 逼近零、p99 latency 在一次 deploy 後悄悄攀升、超大型物件的 multipart upload 閾值、ENA 已啟用但 enhanced networking 仍未生效，以及 Compute Optimizer 同時標記過度與不足配置的建議。

為什麼效能調校位於 SOA-C02 Domain 6

Domain 6（成本與效能最佳化）佔 SOA-C02 考試 12%——只有兩個 topics 分享這個配額——但 Task Statement 6.2 卻穿插於其他每個 domain。Domain 2 的 Auto Scaling group 只有在 metric 來源以正確解析度發布、且 EBS volume 能跟上突發流量時才能正確擴展。Domain 2.1 的 RDS Multi-AZ 部署，若未啟用 Performance Insights，在業務高峰期仍會出現讀取延遲峰值。Domain 3 的 CloudFormation 部署在 EBS 配額耗盡時會失敗。Domain 5 的 VPC Flow Log 分析有時指向網路 throttling，而使用 enhanced networking 的 instance type 本可吸收這個問題。Domain 6.2 是儲存、運算與資料庫調校交會的運維介面。

考試的框架是運維導向，而非架構設計。SAA-C03 問「哪個 storage class 適合這個工作負載？」，SOA-C02 問「工作負載已跑在 gp2 上，BurstBalance 四小時內從 100 降到 30，應用程式開始變慢，不停機的情況下你現在要改什麼？」。答案是 ModifyVolume 切換到帶 provisioned IOPS 的 gp3——但考生必須了解 volume types、發出飽和訊號的 metrics、不停機的遷移路徑，以及成本影響。SOA-C02 要求你像醫生判讀生命徵象一樣解讀 CloudWatch metrics：VolumeQueueLength 持續高於 1，代表 volume 是瓶頸；BurstBalance 下降，代表 gp2 的 burst 正在消耗；BurstBalance 偏高但應用程式仍慢，代表瓶頸在其他地方（CPU、網路、資料庫）。

白話文解釋 Compute, Storage, and Database Performance Tuning

效能調校的術語堆疊很快。三個類比能讓概念變得具體好記。

類比一：捷運路線升級

儲存與網路效能的行為就像捷運系統。IOPS 是每分鐘通過閘口的旅客人數——許多小旅客快速通過。Throughput 是每分鐘運輸的總貨物噸數——較少的貨運車廂，但每節載更多。路線可以是 IOPS-bound（閘口太慢，即使每位旅客都很迷你）或 throughput-bound（月台被超大行李箱堵住）。gp2 是可在尖峰時段暫時加開一節車廂的兩節編組列車——BurstBalance 就是臨時車廂的備用電力；耗盡後列車縮回兩節，乘客大塞車。gp3 是設計本就是三節編組的列車，每分鐘基本 3,000 人次（IOPS）與 125 噸/分鐘（throughput），不論車廂長度，並可付費加掛至每分鐘 16,000 人次與 1,000 噸。io2 Block Express 是高鐵專用軌道：每分鐘 256,000 人次、sub-millisecond 延遲，但只有 Nitro 等級的月台（instance types）才能接入。VolumeQueueLength 是月台上等待上車的旅客隊伍——如果旅客在月台前排隊，不論列車速度多快，列車本身就是瓶頸。SysOps 工程師的工作是判讀月台等候隊伍、車廂平衡儀表與閘口速度，並決定答案是多加車廂（provisioned IOPS）、更大的貨運車廂（throughput），還是換一條路線（volume type 切換）。

類比二：便當工廠選設備

選擇 EC2 instance type 與儲存，就像便當工廠選擇生產設備。CPU 是主廚——負責大部分的主動烹飪。Memory 是料理台面——台面塞滿時，主廚必須不停清理（paging）。Network 是從廚房到出貨區的輸送帶——同時出大量便當時受頻寬限制，急單需要快速派出時受延遲限制。Enhanced networking with ENA 是把手動輸送帶升級為電動輸送帶：廚房沒變、主廚沒換，但便當移動更快、到達更穩定。Instance store 是緊鄰爐台的不鏽鋼備料台——速度極快，但爐台一關機（instance stop 或 terminate），台面上的東西全部清空（資料為暫時性）。EBS 是冷藏倉庫——耐久、可透過網路連線，可以拆下來接到另一台爐台。Cluster placement group 是把套餐流程的所有工作站排排站緊靠在一起，廚師們可以直接遞手，完全不需走路——適合高頻溝通；所有人都在同一角落的貨架上。Spread placement group 是把涼菜站、湯品站、燒烤站分散在不同的獨立廚房，單一火災只影響其中一個——故障隔離。Partition placement group 是多層樓廚房，每層樓是獨立的故障域，但每層都有多個工作站；適合 Cassandra、HDFS 這類分散式資料庫，「rack」對應到一個 partition。

類比三：健身房跑步機的速度調整

用 Performance Insights 調校資料庫，就像看著健身房跑步機的顯示屏。DB Load（AAS） 是目前的速度（km/h）——引擎運作有多努力。Top SQL 是目前正在跑的運動清單——深蹲、臥推、硬舉；其中一個佔用了所有時間。Wait events 是某個運動緩慢的原因：IO:DataFileRead 是「等器材從倉庫搬來」，Lock:transaction 是「等深蹲架空出來」，CPU 是「教練已經排滿課」。RDS Proxy 是統一接待會員報名的櫃台，讓健身房不必為每位訪客新開一個置物櫃——Lambda 健身房每天湧入數千位只待一分鐘的會員，沒有櫃台，置物間（DB 連線上限）瞬間爆滿。Multi-AZ 容錯移轉是主要健身房淹水時，無縫切換到對街的鏡像健身房——設備完全相同、預先就緒，會員卡照用。SysOps 工程師閱讀速度錶（AAS）、找出慢動作（Top SQL）、判斷瓶頸是設備（IO:DataFileRead → 增加 IOPS 或 read replica）還是排程（Lock:transaction → 改寫查詢或建立 index），然後調整跑步機（修改 instance class）或設立接待櫃台（RDS Proxy）。

從效能 Metrics 推薦運算資源

考試指南中 6.2 的第一項技能是「根據效能 metrics 推薦運算資源」。這是 SysOps 版本的 right-sizing——不是一次性的架構決策，而是持續的運維審查。

驅動運算建議的 CloudWatch metrics

AWS/EC2 namespace 中的核心 EC2 metrics：

• CPUUtilization — 使用中的 CPU 百分比。持續高於 80% 表示配置不足；持續低於 10% 表示配置過剩。
• NetworkIn / NetworkOut — 每個週期的位元組數。接近 instance type 文件中的頻寬上限表示網路是瓶頸。
• NetworkPacketsIn / NetworkPacketsOut — 每個週期的封包數。許多小封包在達到頻寬上限之前就會觸及每秒封包數（PPS）限制。
• StatusCheckFailed_System / StatusCheckFailed_Instance — 0 表示健康，1 表示失敗。

透過 CloudWatch agent 從作業系統內部取得的 metrics（位於 CWAgent namespace）：

• mem_used_percent — 最常被考到的缺失 metric。持續高於 90% 表示記憶體壓力。
• disk_used_percent（按掛載點）— 檔案系統使用率，與 EBS volume 使用率不同。
• procstat 計數 — 程序與執行緒計數。
• swap_used_percent — 在不應 swap 的工作負載上出現非零的 swap 使用率，表示記憶體配置不足。

AWS Compute Optimizer — 基於 ML 的 right-sizing 引擎

AWS Compute Optimizer 攝取最多 14 天的 CloudWatch metrics（以及可選的 CloudWatch agent 記憶體 metrics 以獲得更豐富的建議），並針對 EC2 instances、EC2 Auto Scaling groups、EBS volumes、Lambda functions 與 ECS services on Fargate 發出結構化建議。

每項建議屬於以下分類之一：

• Optimized — 目前配置大小適當。
• Under-provisioned — 增加資源；工作負載正被 throttle。
• Over-provisioned — 減少資源；你在為未使用的容量付費。
• Not optimized（部分資源類型的通用版本）。

Compute Optimizer 也會回報效能風險分數（1–4），表示它對建議不會使效能倒退的信心程度。風險分數 1 可安全執行；分數 4 表示建議可能降低效能，應先驗證。

要取得更豐富的 EC2 建議，可在 Compute Optimizer 中啟用 enhanced infrastructure metrics；這會消費 CloudWatch agent 的記憶體 metric，建議能考量記憶體壓力（否則 Compute Optimizer 假設記憶體沒有瓶頸）。

運維建議工作流程

1. 在管理主控台開啟 Compute Optimizer（或透過 CLI / API 查詢）。
2. 依建議分類篩選（先從 under-provisioned 開始修正效能問題，再處理 over-provisioned 以回收預算）。
3. 審查候選 instance types——Compute Optimizer 最多提供三個選項，依效能風險與成本排名。
4. 對於 ASG 建議，更新 launch template 至新的 instance type，並觸發 instance refresh（詳見 AMI/Image Builder 主題）。
5. 在宣告完成之前，對照原始 metrics 驗證新配置至少一個完整業務週期。

EBS Metric 監控：IOPS、Throughput、QueueLength、BurstBalance

Amazon EBS 在 AWS/EBS namespace 中發布豐富的 CloudWatch metrics。正確解讀它們，是 30 秒診斷與 4 小時事故的分水嶺。

核心 EBS metrics

• VolumeReadOps / VolumeWriteOps — 週期內完成的操作總數。除以週期秒數得到 IOPS。
• VolumeReadBytes / VolumeWriteBytes — 讀取或寫入的位元組總數。除以週期秒數得到 throughput。
• VolumeTotalReadTime / VolumeTotalWriteTime — 操作花費的總秒數。除以操作數得到每次操作的平均延遲。
• VolumeQueueLength — volume 上待處理的平均 I/O 請求數。單一最具診斷性的 metric。
• VolumeIdleTime — 無操作的秒數。使用率的反指標。
• BurstBalance — 僅限 gp2、st1、sc1——剩餘 burst credits 的百分比（0–100）。
• VolumeThroughputPercentage / VolumeConsumedReadWriteOps — 僅限 io1/io2——volume 距離其 provisioned IOPS 上限的接近程度。

如何解讀 metrics

診斷決策樹：

1. VolumeQueueLength 是否持續高於 1？ 是 → volume 是瓶頸。增加 IOPS/throughput 或切換 volume type。
2. BurstBalance 是否在下降（gp2/st1/sc1）？ 是 → 工作負載正在消耗 burst credits，耗盡後 throttle 至 baseline。擴大 volume 以提高 baseline，或遷移至 IOPS 與大小解耦的 gp3。
3. VolumeThroughputPercentage 接近 100%（io1/io2）？ 是 → 已達到 provisioned IOPS 上限。使用 ModifyVolume 提高 provisioned IOPS。
4. VolumeReadOps 除以週期 > instance type 文件中的 IOPS 上限？ 是 → instance 可能是瓶頸（其 EBS 頻寬已耗盡），而非 volume。切換至更大或 EBS-optimized 的 instance type。

SysOps 工程師必須同時檢查 volume 端（provisioned IOPS）與 instance 端（附加至 instance type 的 EBS 頻寬）。一個 64,000 IOPS 的 io2 volume 附加至 4,750 IOPS 上限的 instance，只能提供 4,750 IOPS。

設定標準告警

基本的生產 EBS 儀表板應包含以下告警：

• 任何 gp2 / st1 / sc1 volume 的 BurstBalance < 20%——耗盡前的早期預警。
• 5 分鐘平均 VolumeQueueLength > 1——volume 正成為瓶頸。
• 對於 io1/io2：VolumeThroughputPercentage > 90%——接近 provisioned IOPS 上限。
• 對於應用程式關鍵掛載點：agent 收集的 disk_used_percent > 85%——檔案系統使用率。

gp2 volume 一旦 BurstBalance 歸零，就會無聲地從 burst（最高 3,000 IOPS）throttle 至 baseline（每 GB 3 IOPS）。應用程式變慢，團隊急著找原因，而揭露問題的 metric（BurstBalance）不在大多數預設儀表板上。SOA-C02 定期測試這個場景——考生必須知道要對 BurstBalance < 20% 設告警，並在 burst 模式定期而非偶發時，將 gp2 遷移至 gp3（或更大的 gp2）。參考：https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cloudwatch_ebs.html ::

EBS Volume Types 比較：gp2、gp3、io1、io2、st1、sc1

選擇與修改 volume types 是 SOA-C02 中最具運維意義的 EBS 決策。

General Purpose SSD — gp2 vs gp3

• gp2：舊版通用型 SSD。IOPS 基準為每 GB 3 IOPS，可 burst 至最高 3,000 IOPS（小於 1,000 GB 的 volume；超過 1,000 GB 時 baseline 已超過 3,000，burst 無意義）。最高 16,000 IOPS（需達 5,334 GB）。Throughput 隨大小縮放至最高 250 MiB/s。IOPS 與 throughput 與 volume 大小耦合——小 volume 要增加 IOPS 只能靠擴容。
• gp3：現代通用型 SSD。無論大小，從 1 GB 起一律基準 3,000 IOPS 與 125 MiB/s。Provisioned IOPS 最高 16,000，provisioned throughput 最高 1,000 MiB/s，兩者皆獨立於大小計費。等效基準效能下比 gp2 便宜約 20%。新通用型工作負載的預設選擇。

gp2 → gp3 遷移是一次不停機的 ModifyVolume 呼叫。對 SOA-C02 而言，關鍵提示語句是「BurstBalance 下降」或「我們獲得的 IOPS 與需要的大小不匹配」——兩者都指向 gp3。

Provisioned IOPS SSD — io1、io2、io2 Block Express

• io1：舊版 provisioned-IOPS SSD。Nitro instances 上每 volume 最高 64,000 IOPS，最大 IOPS-to-GB 比例 50:1。耐久性高於 gp2/gp3（99.8–99.9%）。用於任務關鍵型 OLTP 與大型資料庫。
• io2：與 io1 相同上限，但99.999% 年度耐久性，IOPS-to-GB 比例 500:1。io1 的預設替代選擇。
• io2 Block Express：Nitro instances 上的 io2，每 volume 最高 256,000 IOPS、4,000 MiB/s throughput、64 TiB 大小與 sub-millisecond 延遲。適合最大型的 SAP HANA、Oracle 與 SQL Server 工作負載。需要 Nitro-based instance type。

對 SOA-C02 而言，io1 → io2 遷移是為了提升耐久性。io2 Block Express 是場景提到 sub-millisecond 延遲或 IOPS 超過 64,000 時的答案。

Throughput-Optimized HDD — st1

• st1：低成本 HDD，針對串流循序工作負載最佳化——大數據、日誌處理、資料倉儲暫存。每 volume throughput 最高 500 MiB/s；隨機存取受 IOPS 限制。不可作為開機 volume。

Cold HDD — sc1

• sc1：非頻繁存取循序資料的最低成本 HDD——仍需要 block storage 的冷封存。Throughput 最高 250 MiB/s。不可作為開機 volume。

Magnetic（已停用）

• standard / magnetic：舊世代；不要為新工作負載選用。

不停機的 volume 修改 — ModifyVolume

Elastic Volumes 功能讓你在不卸載或停止 instance 的情況下，更改已附加 live volume 的 type、size、provisioned IOPS 與 provisioned throughput。一般流程：

1. 執行 aws ec2 modify-volume --volume-id vol-... --volume-type gp3 --iops 6000 --throughput 250 --size 500。
2. Volume 進入 modifying 狀態，再到 optimizing，最後 completed。在 optimizing 期間效能降低——計畫在低流量時段進行修改。
3. 大小變更後仍需進行作業系統層級的步驟：growpart 與 resize2fs（或 xfs_growfs）以擴充分割區與檔案系統。block device 已擴大，但作業系統不會自動擴充檔案系統。
4. Type 變更後不需要 OS 層級的工作——變更是透明的。
5. 冷卻期：成功修改後，EBS 強制執行 6 小時冷卻期，相同 volume 才能再次修改。

SOA-C02 經常測試「volume 大小已修改但 df -h 仍顯示舊大小」——考生必須知道 OS 層級的 resize 指令。

S3 效能功能：Multipart、Transfer Acceleration、Byte-Range Fetches

S3 效能調校主要是用戶端側的工作——S3 本身在正確使用時幾乎可無限擴展，但用戶端必須使用正確的協定功能。

每個 prefix 的請求速率——最常被考到的 S3 效能事實

S3 依 prefix 擴展，而非依 bucket。Prefix 是物件 key 前的路徑——images/thumbnails/ 與 images/originals/ 是兩個不同的 prefix。每個 prefix 支援：

• 每秒 3,500 個 PUT/COPY/POST/DELETE 請求。
• 每秒 5,500 個 GET/HEAD 請求。

沒有固定的 bucket 全域上限。要超過熱門資料集的每秒 5,500 GET，需跨多個 prefix 分散。經典案例：改寫 bucket/2026-04-25/file-001 為 bucket/abc/2026-04-25/file-001、bucket/def/2026-04-25/file-002——隨機化的第一個字元 prefix 將請求分散到 S3 的多個內部分割區。

Multipart upload

對於大於 100 MB 的物件，AWS 建議使用 multipart upload。對於大於 5 GB 的物件，multipart 是必要的——單次 PUT 不能超過 5 GB。每個 part 最大 5 GB，每次上傳最多 10,000 個 parts，最大物件大小為 5 TB。

Multipart upload 的優點：

• 並行性：parts 從用戶端並行上傳，倍增總體 throughput。
• 可恢復性：若某個 part 失敗，只重試那個 part。一個四小時的 1 TB 上傳不會因單一網路問題從頭開始。
• 首位元組時間：用戶端可以在不知道完整物件大小前就開始上傳。

Multipart uploads 必須完成（CompleteMultipartUpload）或中止（AbortMultipartUpload）；未完成的上傳會以孤立 parts 的形式留在 bucket 中並產生費用。設定 lifecycle rule 以在 N 天後中止未完成的 multipart uploads。

Byte-range fetches

對於大型物件，可使用 HTTP Range: headers 來並行化下載。用戶端對同一物件的不同位元組範圍發出多個並發 GET，並在本地重組。這將多 GB 下載的總時間縮短至最慢範圍的時間。

Transfer Acceleration

S3 Transfer Acceleration 透過 CloudFront edge 網路與 AWS 私有骨幹路由上傳，而非直接穿越公共網際網路。用戶端上傳至最近的 edge，AWS 再透過其骨幹將位元組傳輸至目標 region。

適用時機：

• 使用者距離 bucket region 較遠的跨洲上傳（例如：東京使用者上傳至 us-east-1 bucket）。
• 大型物件（額外的每 GB 費用可被節省的位元組攤薄）。
• 一致的效能比最低成本更重要的工作負載。

不適用的時機：

• 同 region 上傳——Transfer Acceleration 增加成本但無效益。
• 小於幾 MB 的小型物件——額外費用很少能證明微小加速的合理性。

S3 Transfer Acceleration 速度比較工具可在你啟用之前，從你的網路位置估算 Transfer Acceleration 對特定 bucket 的改善百分比。

S3 下載前置 CloudFront

對於靜態或可快取內容的下載至多個用戶端，在 S3 前面放 CloudFront 通常比 Transfer Acceleration 更快且更便宜。CloudFront 在 edge 快取，後續讀取甚至不會打到 bucket。Transfer Acceleration 適用於上傳與不適合快取的一次性大型下載。

RDS Performance Insights：Top SQL、Wait Events、AAS

RDS Performance Insights 是 SysOps 團隊針對 RDS 與 Aurora 的診斷儀表板。可以以每個資料庫 instance 為單位啟用（主控台中的一個切換，或 CLI 中的 --enable-performance-insights）。

DB Load（AAS）metric

Performance Insights 的核心 metric 是 DB Load，以 Average Active Sessions（AAS） 表示。AAS 是任意時刻資料庫中正在執行查詢的 session 數量。參考基準是 instance 上的 vCPU 數量——如果 AAS 持續高於 vCPU 數量，資料庫受 CPU 限制。如果 AAS 偏高但主要是非 CPU wait events（IO、lock、network），瓶頸在其他地方。

Top 維度

Performance Insights 依維度分組 DB Load，讓你可以透視：

• Top SQL — 哪些查詢累積了最多 DB Load。整體負載偏高時的第一個查看點。
• Top waits — 哪些 wait events 佔主導（CPU、IO:DataFileRead、IO:XactSync、Lock:transaction 等）。診斷軸。
• Top hosts — 哪些用戶端主機產生負載。用於找出流氓的 cron job。
• Top users — 哪些 DB 使用者在消耗負載。在共用資料庫環境中有用。
• Top databases — 哪個邏輯資料庫（在多 DB instances 中）。

常見 wait event 診斷

• CPU — SQL 計算量昂貴。最佳化查詢、新增 index、scale up instance class。
• IO:DataFileRead — SQL 正在從未在 buffer cache 中的磁碟讀取資料。增加記憶體（更大的 instance）、配置更多 IOPS，或新增 index 以讀取較少的 pages。
• IO:XactSync（PostgreSQL）/ io_completion（SQL Server）— 寫入 commit 等待儲存。配置更多 IOPS 或移至 io2 Block Express。
• Lock:transaction — sessions 等待另一個 transaction 持有的 row lock。應用程式存在 lock contention；調查慢速 transactions。
• Client:ClientRead — 資料庫在等用戶端讀取結果。是用戶端應用程式慢，而非 DB。

保留期與定價

• 免費方案：Performance Insights 資料保留 7 天。
• 付費（長期保留）：最長 24 個月，需額外付費。

對 SOA-C02 而言，關鍵提示是「團隊需要上季度的趨勢分析」→ 長期保留；「團隊需要調查上週的事故」→ 免費方案已足夠。

Enhanced Monitoring vs Performance Insights

兩個容易混淆的 RDS 特定監控功能：

Performance Insights 回答**「是哪個 SQL 在等什麼」。Enhanced Monitoring 回答「OS 在做什麼」**。兩者互補；誰也無法取代誰。

RDS Proxy：應對連線風暴的連線池

RDS Proxy 是位於應用程式用戶端與 RDS 或 Aurora 資料庫之間的受管連線池。它維護一個對資料庫的暖連線池，並將用戶端連線多工至其中。

RDS Proxy 存在的原因

開啟資料庫連線的成本很高。典型的 PostgreSQL 或 MySQL 連線消耗記憶體與一個後端程序。Lambda 擴展至數千個並發調用時會產生連線風暴——每個 Lambda instance 開啟自己的連線，資料庫達到 max_connections 上限，新連線回傳 too many connections 錯誤。傳統修法（應用程式端連線池）對 serverless 無效，因為每個 Lambda 是全新的程序。

RDS Proxy 透過以下方式解決：

• 跨多個用戶端 session 池化並重用資料庫連線。
• 多工——許多用戶端 session 共用較少的後端連線。
• 當後端連線飽和時將額外用戶端排隊，平滑突發。
• 在 Multi-AZ 事件期間比直接 RDS 連線更快地容錯移轉（proxy 重試至新的 primary，而非強迫用戶端重新連線）。
• 與 Secrets Manager 整合，在不變更應用程式的情況下輪換憑證。
• 在 proxy 層強制執行 IAM 認證。

何時使用 RDS Proxy

• Lambda functions 連接 RDS 或 Aurora。
• 連線流轉率高的 Web 應用程式（每個請求都開新連線）。
• 需要更快容錯移轉的工作負載（proxy 縮短 Multi-AZ 的容錯移轉時間）。
• 需要 Secrets Manager 支援的憑證輪換而不重啟應用程式 instances 的工作負載。

RDS Proxy 不必要的情況

• 擁有自身良好調校的應用程式端連線池的長時間執行 EC2 應用程式。
• 連線速率極低的工作負載（proxy 增加延遲開銷）。

定價

RDS Proxy 依底層資料庫每 vCPU 每小時計費。不免費，但通常比資料庫連線上限事故的代價便宜。

EC2 Enhanced Networking：ENA、SR-IOV 與頻寬

Enhanced networking 是 EC2 的功能，透過 SR-IOV（Single-Root I/O Virtualization）繞過 hypervisor 的標準 virtio 路徑，提供更高頻寬、更高 PPS 與更低延遲。

兩種 enhanced networking 介面卡

• ENA（Elastic Network Adapter） — Nitro instances 上的現代 enhanced networking 介面卡。在最大的 instance types（p4d、p5、c7gn）上最高 100 Gbps。任何當代 instance 的預設選擇。
• EFA（Elastic Fabric Adapter） — 針對 HPC 與 ML 工作負載的特殊介面卡，為 MPI 與 NCCL 增加 OS-bypass。用於 c5n、c6gn、c7gn、p3dn、p4d、p5。需要 EFA 驅動程式。典型 SysOps 考試範圍外，僅供參考。

舊版的 Intel ixgbevf（VF）驅動程式在考試中仍以歷史替代方案的形式出現，適用於舊版 c3/c4/r3 instances；假設當代 = ENA。

啟用 enhanced networking

對於 ENA：

1. 使用當代 instance type（大多數預設支援 ENA——查閱文件表格）。
2. AMI 必須包含 ENA 驅動程式（Amazon Linux 2/2023 與當前版本的 Ubuntu/RHEL/SUSE/Windows AMIs 均包含）。
3. AMI 與 instance 上的 enaSupport 屬性必須為 true（Amazon 發布的 AMIs 已設定；對於自訂 AMIs，使用 aws ec2 modify-instance-attribute --ena-support 設定）。

若三者中任一缺失，instance 會退回標準 virtio 介面，無法獲得 enhanced networking——即使 instance 本身是具備能力的。SOA-C02 測試這個錯誤配置：「SysOps 團隊為 100 Gbps 工作負載選擇了 c5n.18xlarge，但只看到 10 Gbps」——AMI 缺少 ENA 驅動程式或 enaSupport=false。

Instance 頻寬上限

每種 instance type 都有文件記載的頻寬上限（例如，m5.large ≈ 10 Gbps burst，c5n.18xlarge ≈ 100 Gbps sustained）。ENA 介面卡是必要條件但非充分條件——instance type 的上限才是實際 throughput 的決定因素。SOA-C02 偏好網路-bound 場景，考生必須（a）確認 enhanced networking 已開啟，（b）確認 instance 已針對頻寬需求調整大小，（c）檢查 NetworkPacketsIn/Out 的 PPS 上限。

Instance Store：用於高 IOPS 的暫時性 NVMe

Instance store 是實體附加於主機機器的本機 block storage。與 EBS（網路附加、持久）不同，instance store 的特性為：

• 暫時性：instance stop、hibernate、terminate 或硬體故障時遺失。僅重新開機時保留。
• 高效能：NVMe SSD，在 i3、i3en、i4i、m5d、c5d、r5d 系列上具備數百萬 IOPS 與數 GB/s throughput。
• 隨 instance 免費：無需另行計費。容量由 instance type 決定。
• 不可附加或卸載：它是 instance 的一部分。

適用 instance store 的時機

• 快取層 — EC2 上的 Redis、Memcached 叢集、可從持久儲存重新熱身的應用程式端快取。
• 暫存 / 臨時資料 — 排序溢出檔案、臨時 index 建構、視訊轉碼的中間幀。
• 擁有自身複製功能的分散式資料庫 — 使用 instance store 作為資料路徑的 Cassandra、MongoDB、Elasticsearch，透過跨節點複製提供耐久性。
• 效能基準測試，EBS 網路頻寬是瓶頸時。

不適用 instance store 的時機

• 必須在 instance 故障後存活的單一真實來源資料。
• 必須在 stop/start 後持續存在的資料 — aws ec2 stop-instances 會清除 instance store。
• 期望 EBS 快照的工作負載 — instance store 無法建立快照。

運維注意事項

• 在 Nitro instances 上，資料預設以 AES-256 靜態加密（AWS 受管金鑰，無額外費用）。
• Instance store volumes 以 block devices 形式出現（/dev/nvme1n1 等），但需要手動建立檔案系統並掛載。
• 替換 instance type 通常意味著遺失 instance store 內容——新 instance 有全新的空 volumes。

EC2 Placement Groups：Cluster、Spread、Partition

Placement groups 影響 AWS 如何在底層實體硬體上放置 EC2 instances，以針對低延遲或故障隔離進行最佳化。

Cluster placement group

• 將 instances 緊密聚集在單一 Availability Zone 內，位於同一個 rack 或相鄰 racks 上。
• 低延遲（sub-millisecond）與高頻寬（ENA 支援的 instances 每個 flow 最高 10 Gbps，總計 100 Gbps）。
• 使用案例：HPC 緊密耦合工作負載 — MPI 模擬、記憶體內資料分析、ML 訓練同步。
• 群組中的所有 instances 應為同一類型（混合類型降低打包效率）。
• 單一 AZ——無故障隔離。Rack 層級故障可能摧毀整個群組。

Spread placement group

• 將 instances 分散在不同的底層硬體上，使單一硬體故障最多影響一個 instance。
• 每個 instance 在獨立的 rack 上，擁有自己的網路與電源。
• Spread group 中每個 AZ 最多 7 個 instances。
• 使用案例：必須各自存活的小規模關鍵 instance 叢集 — 網域控制器、MQTT brokers、授權伺服器。
• 支援跨 AZs。

Partition placement group

• 將群組劃分為多個 partitions，每個 partition 位於不共用基礎設施的不同 racks 上。
• 每個 AZ 最多 7 個 partitions，每個 partition 可有許多 instances。
• 使用案例：框架了解 partitions / racks 的大型分散式工作負載 — Cassandra、HDFS、Kafka。應用程式將副本映射到不同 partitions，使 rack 故障最多只影響一個副本。
• Partition 編號透過 instance metadata 暴露給應用程式使用。

比較表

運維注意事項

• Placement group 建立時為空，之後才將 instances 啟動進入其中。你無法將正在執行的 instance 追加至 Cluster placement group。
• 對於 Spread / Partition，你可以透過 aws ec2 modify-instance-placement 將已停止的 running instance 移入群組。
• Cluster placement groups 應使用同一家族的 ENA-enabled instance types，以獲得可預期的頻寬。

場景模式：EBS Volume BurstBalance 歸零——升級路徑

SOA-C02 的標準疑難排解場景。Runbook：

1. 識別 volume type。 主控台 → EC2 → Volumes → 檢查 Volume type。如果是 gp2、st1 或 sc1，BurstBalance 適用。如果是 gp3 或 io2，BurstBalance 不存在（無 burst credits——效能為 provisioned）。
2. 確認 BurstBalance 是瓶頸。 CloudWatch → Metrics → AWS/EBS → BurstBalance。過去幾小時趨向 0，表示 burst credits 正在耗盡；一旦歸零，volume throttle 至 baseline。
3. 決定升級路徑。 兩個選項：
   • 使用 ModifyVolume 遷移至 gp3。 gp3 baseline 為 3,000 IOPS，無論大小——以較低成本解決大多數 gp2 burst 耗盡的情況。要提高 IOPS，額外配置最高 16,000 IOPS。
   • 擴大 gp2 volume，使 baseline（每 GB 3 IOPS）符合穩態需求。幾乎在所有情況下都比 gp3 效率低且更昂貴——僅作為舊版答案列出。
4. 執行修改。 aws ec2 modify-volume --volume-id vol-... --volume-type gp3 --iops 6000 --throughput 250。Volume 進入 modifying，再 optimizing（此期間效能降低），最後 completed。
5. 用 metrics 驗證。 修改穩定後，觀察 VolumeQueueLength——如果新的 IOPS/throughput 符合工作負載，應降至 1 以下。觀察 VolumeReadOps/VolumeWriteOps 除以週期，得到實際達到的 IOPS。
6. 設定告警。 在任何剩餘的 gp2 volumes 上建立 BurstBalance < 20% 告警——並理想地逐步將它們全部遷移至 gp3。對於 gp3，改為對 VolumeQueueLength > 1 設告警。

最常見的根本原因是穩態 IOPS 需求超過 gp2 的大小耦合 baseline；95% 的情況下修法是 gp3。SOA-C02 期望這個確切的順序。

場景模式：RDS p99 延遲峰值——Top SQL → Wait Events → 修復

另一個標準場景。應用程式回報業務高峰期 p99 latency 翻了三倍。Runbook：

1. 開啟資料庫的 Performance Insights。 將時間窗口設定至峰值期間。
2. 閱讀 DB Load（AAS）圖表。 與 vCPU 數量比較。如果 AAS 遠高於 vCPUs，DB 已飽和；如果 AAS 適中但應用程式 p99 仍然峰值，瓶頸可能在其他地方（網路、應用程式層）。
3. 按 Top SQL 切割。 列表顯示哪些查詢正在累積負載。通常是一個新查詢（deploy 後）佔主導。
4. 按 Top Waits 切割。 這命名了瓶頸：
   • CPU — SQL 計算量龐大。新增 index、改寫查詢或 scale up instance class。
   • IO:DataFileRead — 工作集超過 buffer cache。增加記憶體（更大的 instance class）、配置更多 IOPS，或新增 index 以讀取較少 pages。
   • Lock:transaction — 應用程式存在 lock contention。調查持有 lock 的 transaction；更快 commit 或重構。
   • Client:ClientRead — DB 在等用戶端。是應用程式慢，而非 DB。
5. 檢查 DBConnections。 如果連線數達到 max_connections 上限，那本身就會導致新請求排隊或失敗。修法是 RDS Proxy。
6. 檢查底層儲存的 ReadLatency / WriteLatency。 如果高於預期（SSD 超過 10ms），儲存正在被 throttle——配置更多 IOPS 或移至 io2 Block Express。
7. 應用有針對性的修法（index、查詢改寫、instance class 變更、IOPS 提升、RDS Proxy 或 read replica 用於讀取擴展），然後在下一個業務高峰期間對相同的 Performance Insights 視圖重新驗證。

對 SOA-C02 而言，訊號語句符合 wait events：「複雜 JOIN 延遲高」→ Top SQL + index 建議；「許多短查詢超時」→ DBConnections + RDS Proxy；「寫入緩慢」→ ReadLatency/WriteLatency + provisioned IOPS。

常見陷阱：gp2 Burst Credit 耗盡若無告警則不可見

CloudWatch 預設不對 BurstBalance 設告警。gp2 volume 可以在滿 burst 狀態下運行數天，緩慢耗盡 credits，而團隊只在 credits 歸零後應用程式變得無回應時才注意到。那時 throttle 已生效，runbook 緊急應變已開始。修法是預防性的：對 BurstBalance < 20% 設告警，讓團隊有數小時的前置時間，並在 burst 模式定期而非罕見時，從 gp2 遷移至 gp3。

常見陷阱：io2 Block Express 需要 Nitro Instances

io2 Block Express 提供每 volume 最高 256,000 IOPS 與 sub-millisecond 延遲，但它僅支援 Nitro-based instance types。不允許將 io2 Block Express volume 附加至非 Nitro instance type；SOA-C02 有時在詢問 io2 Block Express 效能的場景中嵌入舊世代 instance type（m4、c4、r4）。考生必須找出不匹配，並要麼遷移至 Nitro instance type，要麼接受在更多 instance families 上支援的 io2（非 Block Express）。

常見陷阱：S3 Prefix Scaling 是以 Prefix 計算，而非 Bucket 全域

較新的 SysOps 工程師有時假設 bucket 有固定的吞吐量上限。沒有。每秒 3,500 PUT 與每秒 5,500 GET 的限制是針對每個 prefix 的，一個 bucket 可以有實際上無限的 prefixes。單一熱門 prefix 會被 throttle，不論 bucket 大小。修法是 key 命名：將 keys 分散在許多 prefixes 上（例如，隨機化第一個字元），使請求跨 S3 的內部分割擴散。

常見陷阱：Performance Insights 免費保留期是 7 天，而非 24 個月

24 個月保留期是付費的長期保留選項。預設與免費方案是 7 天。SOA-C02 可能將題目措辭使 24 個月聽起來像免費；考生必須記得長期保留是選擇加入且須付費的。

常見陷阱：詳細監控 vs CloudWatch Agent 用於 EBS

詳細 EC2 監控將 EC2 hypervisor metric 週期從 5 分鐘縮短至 1 分鐘，但不影響 EBS metrics——不論詳細監控設定為何，EBS metrics 對任何已附加 volume 預設以 1 分鐘粒度發布。CloudWatch agent 才是取得檔案系統層級 metrics（disk_used_percent）所需的工具，而非 EBS volume 層級 metrics（由 EBS 服務自動發布）。混淆兩者會導致儀表板缺少關鍵資訊。

SOA-C02 vs SAA-C03：運維視角

SAA-C03 與 SOA-C02 都涉及效能主題，但視角不同。

SAA 考生選擇正確的資源。SOA 考生衡量、即時修改、診斷並驗證變更。

考試訊號：如何識別 Domain 6.2 題目

SOA-C02 的 Domain 6.2 題目遵循可預期的形狀。

• 「BurstBalance 正在下降」 → 使用 ModifyVolume 將 gp2 遷移至 gp3。
• 「sub-millisecond 延遲，IOPS 200,000」 → io2 Block Express 在 Nitro instance 上。
• 「Lambda 的 Too many connections」 → RDS Proxy。
• 「業務高峰期查詢緩慢」 → Performance Insights → Top SQL → wait events。
• 「PUT 503 SlowDown 錯誤」 → S3 prefix 重新分配。
• 「物件 > 100 MB 上傳緩慢 / 不穩定」 → multipart upload + 跨洲時使用 Transfer Acceleration。
• 「100 Gbps 工作負載只得到 10 Gbps」 → ENA 驅動程式缺失或 enaSupport=false。
• 「Cassandra / Kafka / HDFS 分散式叢集」 → Partition placement group。
• 「HPC 模擬需要最低網路延遲」 → Cluster placement group。
• 「網域控制器 / 授權伺服器 / brokers 必須各自存活於主機故障」 → Spread placement group。
• 「根據實際使用情況 right-size 叢集」 → 帶 enhanced infrastructure metrics 的 Compute Optimizer。
• 「上季度的容量規劃趨勢」 → Performance Insights 長期保留（付費）。

決策矩陣——每個 SysOps 目標的效能構件

考試期間使用此速查表。

常見陷阱回顧——效能調校

每次 SOA-C02 考試都會出現其中兩到三個干擾選項。

陷阱 1：gp2 burst 耗盡若無告警則不被注意

CloudWatch 不自動對 BurstBalance 告警。在 20% 設置告警，並在 burst 模式定期發生時遷移至 gp3。

陷阱 2：非 Nitro instance types 上的 io2 Block Express

考試在詢問 io2 Block Express 的場景中嵌入舊世代 instance types；正確答案是 Nitro instance。

陷阱 3：S3 prefix scaling 與 bucket scaling 混淆

每秒 3,500 寫入與每秒 5,500 讀取是以 prefix 計算。修法是 key 重新分配，而非 bucket 分片。

陷阱 4：Performance Insights 24 個月保留不是免費的

免費方案是 7 天。長期保留是選擇加入且須付費的。

陷阱 5：詳細監控不是記憶體或檔案系統 metrics 的答案

詳細監控將 EC2 hypervisor metrics 的週期從 5 分鐘改為 1 分鐘。它不產生記憶體或磁碟使用率 metrics——那是 CloudWatch agent 的責任。

陷阱 6：Multipart upload 閾值是建議，但 5 GB 是硬性限制

單次 PUT 不能超過 5 GB。AWS 建議 100 MB 以上使用 multipart；在考試中，「物件是 8 GB 且團隊使用單次 PUT」是 multipart 的修正。

陷阱 7：自訂 AMI 上缺失 ENA 驅動程式

Enhanced networking 必須滿足三個條件：具備能力的 instance type、含 ENA 驅動程式的 AMI、enaSupport=true。自訂 AMIs 有時缺少驅動程式並無聲地退回至 virtio。

陷阱 8：Placement group 大小限制

Spread 每 AZ 上限 7 個 instances。50 節點叢集無法放入 Spread group——正確答案是 Partition 或每 instance 不同硬體的配置。

陷阱 9：ModifyVolume 大小變更後未進行 OS 層級 resize

block device 擴大，但分割區與檔案系統不會自動擴大。大小修改後 growpart + resize2fs（或 xfs_growfs）為必要步驟。

陷阱 10：Instance store 資料在 stop/start 後仍然存在

不是的。Instance store 僅在重新開機時保留。Stop、terminate、hibernate 或硬體故障都會清除資料。

FAQ — 運算、儲存與資料庫效能調校

Q1：我應該何時從 gp2 切換到 gp3？

幾乎在所有情況下，只要運維方便就應切換。gp3 的基準（3,000 IOPS、125 MiB/s，無論大小）高於 1,000 GB 以下的 gp2，IOPS 與 throughput 與大小解耦（因此可以維持小 volume 但快速），支援獨立的 IOPS 與 throughput 配置最高 16,000 IOPS / 1,000 MiB/s，且比等效 gp2 便宜約 20%。遷移是 aws ec2 modify-volume --volume-id vol-... --volume-type gp3，live 執行無需停機。留在 gp2 的唯一理由是罕見的成熟工作負載，你已經為了滿足 IOPS 而過度配置大小——在這種情況下，在下次維護視窗遷移。SOA-C02 視 gp3 為新通用型工作負載的預設選擇。

Q2：我如何判斷瓶頸是 EBS volume 還是 EC2 instance？

檢查 volume 端的 VolumeQueueLength 與 instance 端文件記載的 EBS 頻寬上限。如果 VolumeQueueLength 持續高於 1，volume 是瓶頸——增加 IOPS、throughput 或遷移 volume type。如果 VolumeQueueLength 低於 1 但應用程式仍然慢，限制在其他地方：instance 的 EBS 頻寬上限（每種 instance type 都有文件記載的上限，限制所有附加 EBS 的總 volume throughput）、網路、CPU 或資料庫。SOA-C02 有時呈現 64,000 IOPS io2 volume 附加在 4,750 IOPS 上限的 instance 上——考生必須認識到 instance 端限制了實際可達到的 IOPS，無論 volume 的 provisioned IOPS 為何。

Q3：IOPS 與 throughput 有什麼差異，哪個更重要？

IOPS 是每秒操作數；throughput 是每秒位元組數。它們衡量同一工作負載的不同面向。進行許多小型讀取（每次 4 KB）的工作負載是 IOPS-bound——在達到 throughput 上限之前，它可以先飽和 IOPS 上限。進行少量大型讀取（每次 1 MB）的工作負載是 throughput-bound——它可能在 IOPS 之前先飽和 throughput。OLTP 資料庫與交易型應用程式通常是 IOPS-bound；資料倉儲、影片處理與大數據掃描通常是 throughput-bound。gp3 讓你可以獨立配置兩者，這正是 SysOps 調校的槓桿。CloudWatch metrics 一對一映射：VolumeReadOps/VolumeWriteOps 對應 IOPS，VolumeReadBytes/VolumeWriteBytes 對應 throughput。永遠兩者都要檢查。

Q4：我應該何時使用 S3 Transfer Acceleration？

當用戶端距離 bucket region 較遠（跨洲上傳）、物件夠大使每 GB 附加費用被攤薄，且一致的上傳效能比絕對最低成本更重要時。從你的網路位置對 bucket 執行 S3 Transfer Acceleration 速度比較工具——如果比較顯示有意義的百分比改善，啟用 Transfer Acceleration。對於同 region 上傳、小型物件或下載至多個用戶端，Transfer Acceleration 不是正確答案。對於可快取內容至多個用戶端的下載，CloudFront 比 Transfer Acceleration 更快且更便宜，因為第二次請求會命中快取。Transfer Acceleration 用於上傳與一次性大型下載；CloudFront 用於可快取的下載。

Q5：Performance Insights 實際上如何找到慢查詢？

Performance Insights 每秒取樣一次資料庫 session 列表，記錄哪些 sessions 是活躍的以及每個在等什麼。隨著時間推移，這會產生按 SQL 陳述式、主機、使用者、資料庫與 wait event 切割的 DB Load（AAS）直方圖。慢查詢是累積負載最高的 SQL——意味著並發活躍 sessions 最多，或個別執行時間最長。Wait events 告訴你每個 session 緩慢的原因：IO:DataFileRead 表示儲存讀取，CPU 表示運算，Lock:transaction 表示競爭。Top SQL 加上 Top waits 的組合能唯一識別瓶頸。Performance Insights 不需要啟用慢查詢日誌或任何用戶端儀器化；它在資料庫引擎層工作。

Q6：我應該對每個 RDS 部署都使用 RDS Proxy 嗎？

不需要。RDS Proxy 是高連線流轉工作負載的正確答案——Lambda functions 連接 RDS、每個請求開新連線的 Web 應用程式、帶 autoscaling 叢集的微服務。對於擁有自身良好調校應用程式端連線池的長時間執行 EC2 應用程式，RDS Proxy 增加延遲開銷而不解決實際問題。決策規則是連線速率：如果應用程式每秒開啟超過數十個新連線，或達到資料庫的 max_connections 上限，RDS Proxy 就有其必要性。RDS Proxy 也在 Multi-AZ 事件期間加速容錯移轉，這本身就是為任何 tier-1 RDS 工作負載部署它的理由，無論連線模式如何。SOA-C02 在場景提及 Lambda + RDS 時偏向 RDS Proxy。

Q7：我停止 instance 時 instance store 資料會發生什麼？

它會永久遺失。Instance store 僅在重新開機時保留。Stop、terminate、hibernate 與底層硬體故障都會清除 instance store 內容。這是 instance store 保留給暫時性資料的運維原因：快取、暫存空間、排序溢出、分散式資料庫中的複製資料。如果資料必須在 aws ec2 stop-instances 後持續存在，使用 EBS。如果資料必須能從快照恢復，使用 EBS。Instance store 無法建立快照、無法卸載，也無法在 instances 間移動。

Q8：我如何在 Cluster、Spread 與 Partition placement groups 之間選擇？

根據工作負載的通訊模式與故障容忍度選擇 placement group。Cluster 適用於 HPC、MPI、ML 訓練同步，以及任何 instances 之間頻繁通訊且受益於同一 rack 上低延遲與高頻寬的工作負載——接受 rack 故障會影響整個群組。Spread 適用於個別關鍵的小規模叢集（每 AZ ≤ 7 個）——網域控制器、MQTT brokers、授權伺服器——你希望每個都在不同的 rack 上，使硬體故障最多只影響一個。Partition 適用於框架了解「rack」或「partition」的大型分散式工作負載——Cassandra、HDFS、Kafka——你希望副本跨 partitions 分散，使 partition 故障最多影響一個副本。大小提示是關鍵：≤ 7 個關鍵 instance → Spread；HPC 緊密耦合 → Cluster；大型分散式 → Partition。

Q9：我的 Compute Optimizer 建議看起來不對——為什麼？

Compute Optimizer 需要至少 14 天的 CloudWatch metrics 才能給出有信心的建議，且需要 CloudWatch agent 的記憶體 metric 才能偵測記憶體-bound 工作負載。沒有 agent，Compute Optimizer 假設記憶體沒有瓶頸，並純粹根據 CPU 建議更小的 instances；如果工作負載實際上記憶體已鎖定，按建議縮小規模將降低效能。在 Compute Optimizer 中啟用 enhanced infrastructure metrics（消費 agent 的記憶體 metric），並確保 CloudWatch agent 已發布記憶體與磁碟 metrics 至少兩週，然後再信任建議。此外，將效能風險分數作為把關標準：只在無需進一步驗證的情況下對 risk-1（最低風險）建議採取行動；risk-3 與 risk-4 建議在應用前需要基準測試。

Q10：為什麼我的 c5n.18xlarge instance 只提供 10 Gbps，而規格說是 100 Gbps？

ENA-based enhanced networking 要提供文件記載的頻寬，必須同時滿足三個條件：（a）instance type 支援 ENA（c5n 支援）；（b）AMI 已安裝 ENA kernel 驅動程式（當前版本的 Amazon Linux、Ubuntu、RHEL、SUSE、Windows AMIs 都有；自訂 AMIs 有時沒有）；（c）AMI 與 instance 上的 enaSupport 屬性設定為 true。若任一缺失，instance 退回標準 virtio 介面，你就得到標準 EC2 網路——在 c5n.18xlarge 上大約是 10 Gbps。Linux 上的診斷指令是 ethtool -i eth0；驅動程式行應顯示 driver: ena。如果顯示 driver: vif 或其他驅動程式，ENA 未啟用。修法是更新 AMI（為你的發行版執行 ENA 安裝程式）並透過 aws ec2 modify-instance-attribute 在 instance 上設定 enaSupport=true。修復後，stop 並 start（而非 reboot）instance，讓新屬性生效。

延伸閱讀與相關運維模式

• Amazon EBS Volume Performance on Linux
• Amazon EBS Volume Types
• Modify an EBS Volume Using Elastic Volumes
• Amazon CloudWatch Metrics for Amazon EBS
• Best Practices Design Patterns: Optimizing Amazon S3 Performance
• Uploading and Copying Objects Using Multipart Upload
• Amazon S3 Transfer Acceleration
• Monitoring DB Load with Performance Insights on Amazon RDS
• Using Amazon RDS Proxy
• Enhanced Networking on Linux Instances
• Enable Enhanced Networking with the Elastic Network Adapter (ENA)
• Amazon EC2 Placement Groups
• Amazon EC2 Instance Store
• AWS Compute Optimizer User Guide
• Monitoring Metrics in an Amazon RDS Instance
• AWS SOA-C02 Exam Guide v2.3 (PDF)

效能調校與 SOA-C02 其他部分環環相扣。下一個運維層次是：EC2 Auto Scaling 與 ELB 高可用性，用於這些旋鈕所服務的工作負載層；RDS 與 Aurora 韌性，用於 Performance Insights 與 RDS Proxy 和 Multi-AZ 容錯移轉共存的資料庫層；成本可視性與 rightsizing，用於相同 Compute Optimizer 建議的預算面；以及 CloudWatch metrics、alarms 與 dashboards，作為使本主題中每個 metric 可觀測的基礎。

• EC2 Auto Scaling、ELB 與 Multi-AZ 高可用性 — SOA-C02 學習筆記
• RDS 與 Aurora Multi-AZ、Read Replicas 與 Caching — SOA-C02 學習筆記
• 成本可視性、Budgets 與資源 Rightsizing — SOA-C02 學習筆記
• CloudWatch Metrics、Alarms 與 Dashboards — SOA-C02 學習筆記