AWS Emulator 正式開放：AI 代理本機測雲端程式，哪些結果仍要回 AWS 驗證？
AWS Emulator 讓 AI 代理在本機反覆測試雲端應用。解析模擬金鑰、獨立實例、fidelity 行為測試、IAM 與跨區限制，以及費用、遙測和代理建置流程。
AI 程式代理反覆修改雲端應用時，常需要建立資源、跑測試，再修下一版。若每一步都要真的部署到雲端，等待、費用與測試資源互相干擾，就會一起增加。
AWS 在 2026 年 11 月 11 日正式開放 AWS Emulator，讓開發者在自己的機器上，用熟悉的 AWS 工具呼叫本機模擬端點，測試應用與代理產生的程式。
模擬器把資源留在本機，不需要先有 AWS 帳號，也沒有額外服務費。真正部署到 AWS 時仍要支付相關資源，自己的電腦與 CI 運算也不會變成免費。
本機測試的價值，在於縮短修改與驗證的循環。但官方明確列出權限政策、跨帳號與跨區行為限制，因此測試通過仍有需要回到真實雲端核對的部分。
我會建議先把它用在建立、讀寫與刪除資源的開發測試，保留正式環境與安全驗證。它讓代理更容易反覆試做，可信度仍取決於測試是否代表真正需要的行為。
要安排這個分工，先確認請求怎麼被導到本機，以及每個測試如何維持自己的狀態。這能決定多個代理是否會碰到彼此的資料。
同一套 AWS 呼叫，改由本機端點回答
模擬器用本機端點接收工具請求，讓程式可以在不建立真實雲端資源下測試。應用仍使用熟悉的 AWS 呼叫方式，改變的是請求交給哪裡處理。
AWS Emulator 預設使用本機 HTTPS 端點，位於 127.0.0.1:9297。HTTPS 的加密與憑證機制仍存在，只是對方是自己機器上的模擬服務，而非 AWS 雲端的正式服務。
每次啟動會產生模擬器專用的金鑰、憑證與設定。金鑰有 EMULATOR 前綴，並以一般 AWS 工具使用的簽章方式驗證。它只接受自己的模擬金鑰，不需要把真實 AWS 帳號憑證交進這個流程。
這讓代理能反覆練習建立、讀取、修改與刪除資源，而不必每次等候真實雲端部署。若測試本來只是檢查程式是否正確組合請求，本機回圈可以減少外部資源帶來的干擾。
但是端點設定仍需確認。程式的某一部分若沒有採用本機設定，就可能繼續呼叫真實 AWS。不能只因啟動了模擬器，就假設所有工具都自動轉向本機。測試前應核對實際使用的工具與設定來源。
請求路徑分清之後，還要把每份測試資料與憑證隔開。本機執行能縮短距離，卻不會自動替測試安排好彼此的邊界。
獨立實例避免代理搶資源，也有啟動與建置成本
每個實例保有自己的狀態與金鑰，Rust 測試也可把模擬器嵌進程序。這讓多個代理有機會各自測試，不必共用同一組雲端資源名稱。
例如，兩個測試都建立相同名稱的儲存資源，如果跑在同一環境就可能互相覆寫或刪除。分開的實例可以各自保存狀態，測完再丟棄，減少「單獨能過、一起跑卻失敗」的干擾。
Rust 的嵌入式路徑適用 AWS Rust SDK，將模擬器放進測試程序，不需要另外安排 HTTP 端點、憑證與環境設定。這是特定語言工具的整合方式，不能推論每種 SDK 都已有相同嵌入介面。
平台取得方式也不同。原生 Linux 套件涵蓋指定的六十四位元 x86 與 Arm 環境。macOS 與 Windows 文件則提供以 Docker 建置短小映像的做法，查核時沒有官方預先建立的 Docker 映像可直接取用。
因此，「本機可跑」仍包含下載、建置與運行成本。若選擇從原始碼建立，還需要相應工具鏈與磁碟空間。把它放到持續整合環境時，也應將啟動與清理時間算進測試。
能啟動不代表行為相同，仍要看官方如何量測相容程度。避免共用資源只是第一步，測試結果是否接近 AWS 才決定它能接下哪一段工作。
fidelity 測試比較行為，分數要連分母一起看
相容性測試以真實 AWS 作對照，逐項核對呼叫回應與最後資源狀態。官方將這種行為接近程度稱為 fidelity，重點是模擬結果是否符合實際服務。
API 模型可以協助建立請求欄位、回應結構與錯誤形狀，但「介面長得像」仍不足以證明行為相同。建立資源後是否能找到、刪除後是否真的消失，以及錯誤條件如何回答，都需要額外實作與測試。
官方流程先在真實 AWS 驗證測試，再將相同呼叫重播到模擬器。比較內容包括每次呼叫的狀態、回應內容、精確錯誤與最終資源狀態，避免只核對第一個成功回應。
這也說明為什麼應連測試數量一起讀分數。若新增更嚴格的案例，通過比例可能暫時下降，即使原本行為沒有退步。反過來，少量簡單案例全過，也不代表整個服務已完整重現。
官方提到以大量 API 模型作為建置起點，不能把模型數直接當成已完整實作的 AWS 服務數。讀者真正需要的是自己的操作是否被支援，以及相關行為有多少可重播檢查。
遇到未支援操作時，模擬器以 501 明確失敗。這有助於看見缺口，勝過把沒有實作的行為偽裝成成功。沒有被這些測試保證的權限與跨環境行為，需要另外安排驗證。
權限與跨區限制，決定哪些測試必須留在 AWS
模擬器不會完整重現 IAM 政策，也不提供相同的跨帳號與跨區行為。IAM 是 AWS 用來判斷身分可以操作哪些資源的權限管理系統，這是部署安全的重要部分。
因此，本機成功建立資源，只能說明模擬環境接受了該請求。它不能證明正式角色具備必要權限，也不能證明應被拒絕的操作在雲端會被擋下。
資源政策同樣不能用本機通過取代安全測試。若應用需要檢查跨服務存取或特定角色限制，就要在受控 AWS 環境驗證允許與拒絕兩種結果，不能只測一條成功路徑。
查核時模擬器使用單一帳號 000000000000。這讓本機環境較容易建立，也代表跨帳號與跨區的應用不能直接照搬結論。不同部署範圍的名稱、政策與相互存取仍需真實測試。
合理的分工是把反覆修改的功能測試盡量前移，本機先找出請求格式與應用流程問題，再把環境與安全相關驗證留給真實 AWS。這樣可以縮短多數開發回圈，同時保留重要的最後檢查。
除了測試結果，使用者也應知道本機程式會保存與傳送哪些資訊。「在自己的機器跑」描述的是主要執行位置，仍要另外閱讀遙測與授權條件。
本機執行與遙測、授權，分開理解
應用請求由本機處理，預設遙測與原始碼授權仍各有條件。官方表示遙測預設開啟，也提供參數、環境變數與設定檔等停用方式。
AWS 說明遙測不包含應用請求、回應、程式碼、憑證或個人資料。這是供應商對收集範圍的說明，並不等於本刊已檢查所有網路流量。需要封閉環境的團隊，仍應按自己的要求確認設定。
因此，不能把應用呼叫留在本機，轉述成任何情況都不會有對外連線。若工作環境要求限制外傳，遙測狀態應與程式端點一樣明確記錄，而不是靠「local」這個字推論。
授權也有區別。核心程式採 CC0，vendor/ 目錄中的內容則有 Apache 2.0 條件。開放原始碼有助於查看與修改，但整合時仍應辨識不同部分的授權，不概括成所有檔案完全沒有條件。
費用方面，模擬器本身沒有額外服務費，不代表整套開發免費。電腦、容器與持續整合運算仍有成本。回到真實 AWS 的驗證與正式部署，也會產生相應資源費用。
這些限制也提醒讀者，代理寫程式仍需要人設計驗證邊界。工具讓嘗試更容易，並沒有替工程團隊決定何時能信任結果。
代理寫程式，工程團隊負責設計可重播的檢查
AWS 描述由三組代理與合併關卡建立產品，可信度來自規格、對照與檢查流程。這是原廠工程團隊的建置經驗，沒有經過本刊獨立重做。
第一組測試代理撰寫案例，並在真實 AWS 確認行為。第二組找缺口的代理重播這些案例，比較模擬器的差異。第三組修復代理針對個別問題修改實作，讓修正有清楚目標。
這種分工的重要之處，是把「看起來合理」轉成可重複檢查。修復代理不能只聲稱功能已完成，仍要通過建置、程式品質、安全與行為相容性等合併關卡。
原廠作者表示產品程式碼由代理撰寫，沒有由人逐行撰寫或審查。但人仍設計規格、參考行為與驗證關卡。不能把這段敘述簡化成工程師不再需要，因為判定成功的方法正是工程工作的一部分。
同樣的原則也能用在一般應用開發。讓代理每次修一個可重現失敗，保存請求與預期結果，再用測試確認修正，比只要求「把雲端流程寫完」更容易累積可靠進展。
把這種分工接回自己的工作，才能縮短開發循環而不省略最後驗證。模擬器適合承接頻繁試做，真實環境則繼續負責它沒有涵蓋的行為。
測試分層之後，代理才知道何時可以停止
一份可執行的驗收清單，可以分成請求結構、資源生命週期與真實環境三層。本機先確認欄位與應用邏輯，再檢查建立後能讀取、修改後可見變化、刪除後符合預期，最後留下需要 AWS 才能回答的項目。
代理完成本機部分時，應回報哪些案例通過、哪些操作未支援，以及哪些結果尚未送到真實環境。這比只寫「全部測試成功」更能協助接手的人判斷剩餘工作，也避免代理為了消除錯誤而自行改用正式資源。
失敗案例則應保留最小請求與對照結果。若是模擬器行為差異，就不應先改應用程式迎合錯誤結果。若是真實服務也失敗，才回頭檢查應用假設。對照的作用，正是避免兩邊彼此證明一個共同錯誤。
當每層都有清楚完成條件，本機測試才能替開發流程省時，並把剩餘驗證準確交回工程團隊。
AWS Emulator 常見問題
需要先登入 AWS 帳號嗎？
本機模擬使用自己的金鑰與狀態，不需要先有 AWS 帳號。正式部署或用真實 AWS 作驗證，則是另一個有帳號與費用條件的步驟。
所有 AWS 服務都完整支援嗎？
不是。API 模型數量不等於完整服務數，應核對自己使用的操作與行為測試。未支援的操作會明確失敗，不應假設能直接代替全部服務。
本機通過就可以刪掉雲端測試嗎？
不能一概刪除。權限政策、跨帳號、跨區與正式環境特有行為仍需在 AWS 驗證，本機主要減少反覆修改時的等待。
沒有服務費，為什麼仍要算成本？
因為本機與持續整合仍使用硬體、儲存與維運資源，最後的真實雲端驗證也可能計費。應比較整段流程，而非只看工具售價。
已有 AWS 應用的團隊可以先用一組可重播測試，判斷它能接下哪一段工作。保留未支援項目與真實環境檢查，開發加速才有清楚且可維護的範圍。
延伸閱讀：Vercel Sandbox 快照加速：中位數低於0.4秒，舊快照與保存費用怎麼看？
延伸閱讀：AI 說完成之後，怎麼驗收？文件、網站與資料任務的檢查方法
