LocalStack 在 2026 年 3 月把 Community Edition 從 Docker Hub 上換掉，改推的映像檔啟動時強制檢查 LOCALSTACK_AUTH_TOKEN，沒帳號的 CI job 一律拒絕。這一刀之前，用 Docker Compose 拉一顆 localstack 起來對著 SQS、S3、DynamoDB 打整合測試是每個 AWS 專案的預設流程；之後只有 Pro 版有完整功能，免費版連 Cognito、SES v2、RDS、ElastiCache、ECR、ECS 全部收進付費層。fakecloud 是這條路斷掉之後長出來的第一批替代品，也是目前把「用一支 binary 在本機跑真的 AWS 行為」這條路走得最遠的。這篇拆解它跟 LocalStack、Moto、MiniStack 的實際差別，以及在 CI 上要怎麼接。
LocalStack 這一刀是怎麼落的
LocalStack 從 2017 年開始一直是 Apache 2.0 開源專案，Community Edition 支援基本的 20 幾個 AWS 服務，Pro 版加上 IAM enforcement、Lambda hot reload、SSO 那些企業功能。過去八年這個分野對絕大多數 team 都合理——想跑 CI 就用免費版，需要企業級功能才升級。
2026 年 3 月的變更把這條線整個抹掉。新版 CE 映像檔啟動時檢查 auth token，沒 token 直接退出；Cognito、SES v2、RDS、ElastiCache、ECR、ECS 六個原本在 CE 就能用的服務被搬到 Pro 才有，含 ECS 的 CI pipeline 完全過不去。同時官方把 Docker Hub 的舊 tag 一併撤下，過去釘死版本的 pipeline 全爆掉。
這個路數跟 Portainer 3.0 把 CE 凍在 2.45 LTS、Continue.dev 被 Cursor 收購後把 repo 鎖成唯讀是同一條線：開源專案跑到某個規模，商業母公司決定把免費那塊「重新定義」到 Pro。對一次性的 side project 影響不大，對每天跑幾百次 CI 的 team 就是 pipeline 一夜之間失效。
fakecloud 選了跑真 code 這條路
fakecloud 用 Rust 寫，編出來的 fakecloud 是一支 19MB 的靜態 binary，執行後在 localhost:4566 開 HTTP server，AWS SDK 加 endpoint_url 就直接接上。啟動時間大約 300 到 500 毫秒，記憶體閒置狀態約 10 MiB——這個數字擺在 LocalStack 那顆帶 Python runtime 的容器（啟動 3 秒、閒置 150 MiB）旁邊，差異在 CI 平行跑上百個 job 時會被放大成幾分鐘的差距。
單一 binary、無 Docker 依賴這件事本身不是重點，重點是 fakecloud 對「模擬 vs 執行」這條線的選擇。多數 AWS emulator 走的是 mock：SDK 打進來，回一個看起來對的 response，state 存在記憶體或 SQLite。fakecloud 反過來——Lambda 是真的把使用者 code 跑進 23 個 runtime 容器（Node.js 20、Python 3.12、Rust 1.93 等）；RDS 起的是真的 PostgreSQL 或 MySQL 或 MariaDB 容器（六種引擎）；ElastiCache 是真的 Redis；ECS 跑的是真的 containerd task。整套動起來時，測試看到的行為跟真 AWS 幾乎沒差。
這條路的代價是覆蓋度較窄。截至 2026 年 9 月 fakecloud 定調的服務數是 105 個、7508 個 API 操作；LocalStack 全套算下來 30 幾個服務但每個都是 mock。哪一種比較適合看使用情境：如果測試會打 EventBridge → Step Functions → Lambda → DynamoDB 那種 cross-service 串接，behavior 對不對決定測試有沒有意義，這時候 fakecloud 的路走得對；如果 CI 只是驗 SDK client 有沒有把 request 組對、response 有沒有解對，那 mock 更快。
Smithy conformance 這件事到底測了什麼
fakecloud 對外強調「248,557 個 Smithy conformance test variant 每次 commit 都全過」，這個數字不是行銷話術。AWS 官方用 Smithy 這個 IDL 描述每個服務的 API 契約，包括 request/response schema、error type、認證方式、pagination 邏輯。開源社群過去五年做了工具鏈能從 Smithy model 自動生成大量的 SDK 一致性測試——同一個 API 用 20 種 request 變體發過去，比對回應是不是完全符合 spec。
fakecloud 把這條 pipeline 接進自己 CI，每個 PR 都得跑過那 24 萬個 variant。這對 emulator 品質有兩個實質影響：第一，AWS 官方哪天改 API contract，Smithy model 更新，fakecloud CI 立刻紅牌，維護者無法忽視；第二，行為對到 spec 這件事有可稽核性，不是靠「大家測過覺得沒問題」的印象派驗證。
對比之下 LocalStack Community 過去 IAM 是關的、pagination 邊界很多都對不上、Lambda 冷啟動時間跟真 AWS 完全兩個世界。這些落差在整合測試裡不會被立刻抓到，但當測試跟正式環境行為分歧時，「本機測 OK 但上 prod 炸」的 debug 成本會累積起來。
Moto、MiniStack、floci 各自的定位
LocalStack 這一刀之後長出來的替代品實際上分成兩派。第一派是 in-process library：Moto 這種 Python 套件，測試進來的時候用 monkeypatch 攔截 boto3 呼叫，直接在測試 process 裡回假 response。這條路快、輕、不需要另開 server，但缺點也直接：只支援單一語言（Moto 只服務 Python）、不能跑 cross-service workflow、不能測 IAM policy、也沒辦法在 Java 或 Go 專案裡用。
第二派是 HTTP server：LocalStack、fakecloud、MiniStack、floci 都走這條。共同介面是 localhost:4566 的 HTTP server，任何語言的 AWS SDK 加 endpoint_url 都能接。差別在覆蓋度、實作語言、Lambda 執行模式、以及 IAM enforcement 有沒有做。
實務上的分工建議是：如果專案完全 Python、測試只打 S3 跟 DynamoDB 這類無狀態 API、且不需要 cross-service 串接，Moto 是最省事的選擇；如果是 polyglot codebase 或需要真的執行 Lambda 跟 SQL 資料庫，fakecloud 這種 HTTP server 才做得到。MiniStack 的定位是「輕量 LocalStack」，覆蓋跟 LocalStack CE 差不多但拿掉 auth token；floci 較新、還在快速迭代。
AGPL-3.0 在 test 情境不會爆炸
fakecloud 授權是 AGPL-3.0-or-later。這個授權在企業內部常被誤解成「碰到就得公開整份 codebase」，實際上 AGPL 的觸發條件是「透過網路把修改過的版本提供給使用者」。開發測試用途、CI pipeline 內部使用、跑在自己 laptop 上——這些都不構成 AGPL 意義下的 conveyance，公司內部規範只要不把改過的 fakecloud 二進位提供給外部使用者就沒問題。
實際上會踩到 AGPL 界線的情境只有兩個：把 fakecloud 修改過的版本接進對外服務的 SaaS 平台當一部分核心邏輯（罕見）、或把 fakecloud 直接改造然後 fork 出商業產品（更罕見）。純粹當測試工具用、CI job 內部起停、開發者本機跑，都跟 AGPL 拘束無關。企業 legal team 對 AGPL 的過敏反應可以直接引用 GNU 官方 FAQ 這一條說明。
CI 上怎麼接
在 GitHub Actions 上把 fakecloud 接進去有三種模式。最簡單的是把 fakecloud binary 當 service container 或 background process 起起來，測試 setup 階段先 curl 一下 /health 確認起來了再跑測試：
1 | - name: Start fakecloud |
第二種是用 Docker，把 fakecloud 官方映像檔當 service 掛進 job。第三種比較進階，用 fakecloud 提供的 introspection SDK（TypeScript、Python、Go、Rust、Java、C#、PHP 都有）在測試 assertion 階段直接查「這個 SQS queue 收到幾個 message」、「Lambda 被 invoke 幾次」、「SES 發出去的信件內容是什麼」——這些是真 AWS 沒開的 API，但在本地 emulator 上是合理的測試 side effect 檢查。
Terraform 專案要接的時候，比起在 provider block 硬寫 endpoints 覆蓋，比較乾淨的做法是用 OpenTofu 的 provider schema introspection，另外開一支 provider_aws_endpoints_override.tf，只在測試環境載入，主 config 完全不動。
什麼時候別換
fakecloud 不是萬用替換。三個情境會踩到限制：第一，測試如果依賴 IAM policy 的細粒度授權判斷，fakecloud 的 IAM enforcement 有 soft 跟 strict 兩種模式，但覆蓋度不到 LocalStack Pro；第二，測試涉及 AWS 專屬服務像 QuickSight、AppSync、Amplify 這些較邊緣的服務，fakecloud 沒實作；第三，需要模擬「AWS 服務層 outage」或「region-level failure」這種 chaos testing 情境，fakecloud 沒設計進去。
還有一個實際考量：fakecloud 才走過半年，維護者是小團隊。LocalStack 這方面積累了八年的社群跟商業支援，工單有人接。fakecloud 目前 issue tracker 上的問題大多幾天內有回應，但這個 SLA 沒法保證。任務關鍵路徑上要不要押這個 emulator，得看 team 對「replace 或自己 fork」的容忍度。
不過對絕大多數 team 來說，AWS 整合測試在 CI 每天跑幾百次的頻率下，能省下 LocalStack Pro 一年幾千美元的授權費、還把 CI 啟動時間壓掉 2 秒，就是實質收益。從 LocalStack CE 遷移到 fakecloud 平均 team 花的時間是半天到兩天，主要卡在 IAM 行為差異跟 Lambda runtime 版本對應。
NCSE Network 的 VPS 適合這樣跑
自架 CI runner 是把 AWS 整合測試從雲上跑回本機的第二步。GitHub-hosted runner 每分鐘算錢，fakecloud 這種輕量 emulator 在自架 runner 上跑得最順——單顆 4 vCPU、8GB RAM 的 VPS 能同時跑 20 個 CI job 平行的 fakecloud 實例，成本比 GitHub Actions 上開 large runner 便宜一個量級。NCSE Network 的 VPS 主機跑在臺灣是方電訊機房、Intel Gold CPU 加 NVMe SSD、支援 Debian 13、Ubuntu 26.04 這些 systemd 259 的新版發行版，直接開機就能起 self-hosted runner 跑 fakecloud CI，想了解方案細節可以到 ncse.tw 看一下。
