CodeNote.net

LocalStack アーカイブ後の OSS 代替を選び直す — MiniStack、Floci、kumo、fakecloud、moto の使い分け

#aws #localstack #oss #ministack #floci #kumo #moto #testing
重岡 正 ·  Sun, April 26, 2026

LocalStack は、AWS API をローカルで再現する OSS として広く採用されてきました。CI/CD と docker-compose の両方で「ポート 4566 に向けて AWS SDK を叩けば手元で完結する」という体験は、AWS を使う多くのチームにとって事実上のデファクトでした。

しかし 2026 年 3 月 23 日に localstack/localstack リポジトリがアーカイブされ、Docker イメージは認証必須の単一イメージへ統合されました。コード自体は Apache-2.0 のまま残っていますが、リポジトリは凍結された参照用となり、Community Edition 相当の「無認証で起動して使う」運用は終了しています。

このタイミングと前後して、MiniStack、Floci、kumo、fakecloud のような新興 OSS が立て続けに登場し、コミュニティ側はおおむね「LocalStack の代替をどれにするか」を 2026 年 Q2 の論点として議論しています。本記事では、これらの代替候補を、ライセンス、対応 AWS サービス、互換性のレベル、移行コスト、保守の健全性の観点で整理し、用途別の使い分けを示します。

LocalStack に何が起きたのか

タイムラインを整理しておきます。

  • 2026 年 2 月: 料金体系を改訂し、Hobby（非商用）無償ティアを発表
  • 2026 年 3 月 23 日: localstack/localstack リポジトリをアーカイブ。Issues / PR は閉鎖、Discussions のみ受付。Docker イメージは Pro と統合された単一イメージへ。LOCALSTACK_AUTH_TOKEN が必須化（猶予環境変数 LOCALSTACK_ACKNOWLEDGE_ACCOUNT_REQUIREMENT=1 の効力もほどなく停止）

コードは Apache-2.0 のままなのでフォークは技術的に可能です。一方で、LocalStack の内部は AWS API を広く扱う独自実装が多く、フォーク側で継続的にメンテナンスする難度が高いため、Elasticsearch（OpenSearch）、Terraform（OpenTofu）、Redis（Valkey）のような著名なフォーク勢力は 2026 年 5 月時点では現れていません。代わりに、ゼロから書き起こされた新興 OSS が代替候補として複数立ち上がってきた、というのが今の地図です。

代替候補の地図 — 多サービス型と特化型

代替候補は、目的の解像度で大きく二層に分けて考えるのが実務的です。

  • 多サービス型（LocalStack ライクな広域エミュレータ）: 同じ「ポート 4566 にエンドポイントを向ければ、複数の AWS API がまとめて動く」体験を提供する。MiniStack、Floci、kumo、fakecloud が該当
  • テスト向けモック寄り: 本番互換のローカル AWS というより、テストの中で AWS SDK を差し替えるためのモック。moto が該当（standalone server モードで多サービス型に近い使い方もできる）
  • 特化型: 単一サービスの再現精度に振った実装。Amazon DynamoDB Local、ElasticMQ、S3Mock などが該当

候補の地図を先にざっくり押さえておきます。

flowchart LR
    A[LocalStack に近い体験] --> A1[MiniStack]
    A --> A2[Floci]
    A --> A3[kumo]

    B[対応サービスの API 厳密性最優先] --> B1[fakecloud]

    C[ユニットテスト中心] --> C1[moto]

    D[単一サービスのみ] --> D1[DynamoDB Local]
    D --> D2[ElasticMQ]
    D --> D3[S3Mock]

「同じ docker-compose を最小変更で動かしたい」「対応サービスについては本物の AWS と限りなく同じ挙動が欲しい」「テストの中だけで完結したい」「使うのは S3 と SQS だけ」、という分岐点で道具が変わります。以下、それぞれの候補を見ていきます。

新興の多サービスエミュレータ

MiniStack — IaC との親和性が高い広域実装

MiniStack は MIT License で配布される AWS エミュレータです。リポジトリは ministackorg/ministack にあり、pip install ministack か、ministackorg/ministack Docker イメージで起動できます。README では 40 以上のサービスをサポートと表記されており、LocalStack の旧 Community 版でカバーされていた主要 API は概ね埋まっているレンジです。

設計上のポイントは次の通りです。

  • ポート 4566 で受け付け、AWS_ENDPOINT_URL=http://localhost:4566 を渡せば AWS SDK / AWS CLI / Terraform / CDK / Pulumi / CloudFormation が一通り素直に動く
  • LocalStack 互換のパス（/etc/localstack/init/ready.d/*.sh の init script、LOCALSTACK_* 環境変数の一部受け入れなど）を意図的に温存している
  • Testcontainers の Java / Python モジュールが用意されており、Spring Boot 3.1+ の @ServiceConnection パターンで @SpringBootTest に組み込みやすい
  • ステートレス系の AWS API はインメモリで動かす一方、SERVICES=rds を指定すると裏で実物の PostgreSQL や MySQL のコンテナを起動するなど、リアルなバックエンドに寄せた構成が選べる

一方で、公式 docs 自身が IAM ポリシーは強制しない、一部のサービスはメタデータのみ実装、EventBridge Scheduler の自動実行は未対応 などの差分を明示しています。実 AWS の細部を再現することが必須の用途では、これらが PoC でブロッカーになり得ます。

Floci — Quarkus Native による高速起動の広域実装

Floci は MIT で、リポジトリは floci-io/floci にあります。Quarkus + GraalVM Native Image で実装されており、起動時間とアイドル時のメモリが極めて小さいのが特徴です。README では起動 24 ms・アイドル 13 MiB・イメージ 90 MB、6 SDK と 3 IaC ツールに対する 1,850+ の互換性テストを主張しています（数字はベンダー自身の計測値である点には注意）。

Floci の設計上の特徴は LocalStack 置換性に大きく振られている点です。

  • ポートは 4566、wire protocol も LocalStack に揃え、LOCALSTACK_PARITY=true で LocalStack 系の環境変数を自動翻訳して受け付ける
  • ステートレス系（SSM/SQS/SNS/IAM/Kinesis など）は in-process、ステートフル系（S3/DynamoDB）は memory / persistent / hybrid / wal のストレージ抽象を選択可能
  • Lambda / RDS / ElastiCache / ECS / EKS / EC2 / MSK / OpenSearch / CodeBuild など 本物のコンテナを spawn する サービスは、/var/run/docker.sock をマウントしておく必要がある
  • Java / Python / Node / Go 向けの compatibility tests と Testcontainers モジュールが提供されている
  • Quarkus Dev Services への統合提案が出ており、Quarkus プロジェクトでは事実上の標準候補化が進んでいる

プロジェクト自体は 2026 年初頭に立ち上がったばかりで、エッジケースの互換性は今後の検証次第、というのが実情です。

kumo — 単一バイナリで CI に貼りやすい軽量実装

kumo は MIT ライセンスのエミュレータです。日本人開発者の sivchari 氏 による開発で、76 個の AWS サービスを実装と README で公開されています。

最大の魅力は配布形態の単純さです。

  • 単一バイナリ、または ghcr.io/sivchari/kumo:latest の Docker イメージ
  • ポートは 4566 で LocalStack 互換、AWS SDK for Go v2 では BaseEndpoint("http://localhost:4566") 指定だけで動く
  • デフォルトはインメモリ、KUMO_DATA_DIR 環境変数を指定すれば s3.json、dynamodb.json、iam.json などに atomic write で永続化
  • CI/CD でのオーバーヘッドが非常に小さく、docker-compose.yml でイメージ名を 1 行差し替えるだけで LocalStack 用のワークフローから移行できる

ただし、プロジェクトは v0.x 系で、リリースサイクル自体は活発ですが Bus factor の観点では事実上の単独メンテナ体制に近く、エンタープライズ採用前に「どのサービスでどこまで深さがあるか」を PoC で確認するのが安全です。

fakecloud — AWS API 厳密性を最優先する新興候補

fakecloud は AGPL-3.0 の AWS エミュレータです。リポジトリは faiscadev/fakecloud にあります。GitHub の README では 30+ サービス・2,400+ オペレーションと公開されており、対応サービスの広さでは Floci / MiniStack / kumo に届きませんが、対応サービスについては実 AWS との挙動同等性に強く振った設計 が他と異なるポイントです。

具体的には次のような特徴があります。

  • 公式に「100% Smithy conformance per implemented service」「Smithy モデルから生成された conformance テスト」「Terraform acceptance tests を CI で回している」ことを掲げている
  • --verify-sigv4 で SigV4 署名検証、--iam soft|strict で IAM 認可の段階的有効化が可能
  • 起動 500 ms 前後、アイドルメモリ 10 MiB 前後、バイナリサイズ 19 MB 前後と軽量
  • TypeScript / Python / Go / PHP / Java / Rust 向けの first-party テスト SDK が用意されている

ライセンスが AGPL-3.0 である点には注意が必要です。社内のローカル開発・CI で使う限りは概ね問題ありませんが、自社製品にバイナリやネットワーク経由で第三者へ提供する形で組み込む場合は法務確認が必要で、MIT や Apache-2.0 の OSS よりも制約が厳しくなります。

テスト向けのモック寄り — moto

moto は 2014 年から開発が続いている Apache-2.0 の Python 製モックライブラリで、AWS API カバレッジは依然として業界最大級です。100 以上のサービスに対応しており、S3、SQS、SNS、DynamoDB、Kinesis、Lambda、Step Functions、EventBridge、API Gateway、CloudFormation、KMS、Secrets Manager、IAM、EC2、ECS、EKS、CloudWatch Logs などをほぼ網羅しています。

使い方は 3 種類から選べます。

  • Python デコレータ @mock_aws: 関数やテストクラスにアタッチして in-process でモックを差し込む。外部プロセスを起動しないため起動オーバーヘッドが事実上ゼロで、Python テストでは最速
  • ThreadedMotoServer: プロセス内で HTTP サーバを立てる。同一プロセスから AWS SDK が endpointOverride 経由で叩ける
  • Docker motoserver/moto: ポート 5000 で HTTP サーバとして起動。Java / Go / Node.js / Terraform など、Python 以外の言語から AWS_ENDPOINT_URL で接続可能

moto は LocalStack の置換というより、テスト戦略の再設計先 として捉えるのが正確です。LocalStack で「docker compose 経由で広く AWS を立てて統合テストする」習慣がついていた場合、moto の在り方はやや違います。テストをコード近傍に寄せ、in-process デコレータで爆速にする方向と相性が良く、外部プロセスが必要なら server mode で言語非依存にも振れる、という柔軟さが本質的な強みです。

コミュニティ規模、リリース頻度、スポンサーシップの観点から、getmoto/moto は依然として最も保守健全性が高い選択肢の一つです。

単一サービス特化型

複数の AWS サービスを横断的にローカル再現する必要がなく、たとえば「S3 だけ」「SQS だけ」「DynamoDB だけ」というケースでは、広域エミュレータより特化型のほうが運用が楽です。

Amazon DynamoDB Local — AWS 公式

DynamoDB Local は AWS が公式に配布している DynamoDB のローカル実装です。amazon/dynamodb-local の Docker イメージで起動し、ポート 8000 でリクエストを受け付けます。-sharedDb -dbPath で SQLite ベースに永続化でき、AWS NoSQL Workbench からも接続可能です。AWS 公式かつ DynamoDB のセマンティクスを忠実に再現するため、エンタープライズ用途では「DynamoDB だけは公式ローカルに任せる」という分担が現実的です。

ElasticMQ — SQS 互換に絞った成熟実装

ElasticMQ は Apache-2.0 の SoftwareMill 製 SQS 互換実装で、Pekko ベースで実装されています。softwaremill/elasticmq の Docker イメージのほか、GraalVM ネイティブビルドの softwaremill/elasticmq-native も提供され、JVM プロジェクトでは組み込み起動も可能です。FIFO キュー、DLQ、Visibility Timeout、Long Polling など SQS 仕様を忠実に再現しており、SQS 限定なら Floci / MiniStack より精度・成熟度・性能ともに先行しています。

S3Mock — JVM テストとの親和性が極めて高い S3 部分実装

S3Mock は Adobe 製の Apache-2.0、Spring Boot ベースの S3 部分実装です。Docker / Testcontainers / JUnit 5 / TestNG への統合が非常に強く、Java エコシステムで S3 だけ手元に持ちたいときには第一候補になります。一方で、path-style only、presigned URL は受理するが検証しない、KMS は ARN 検証のみで暗号化しない、といった制約があり、これらが実際のアプリケーションのフローと衝突しないかは事前確認が必要です。

MinIO — S3 互換のオブジェクトストア

MinIO は AGPL-3.0 の S3 互換オブジェクトストアで、PutObject、GetObject、Multipart Upload、Bucket Policy、Versioning など S3 API をほぼフルにカバーしています。実運用としては、ローカル開発・CI でテスト用途に使う限りでは商用利用に問題ありませんが、自社製品にバイナリを同梱したり、ネットワーク経由で第三者にサービスとして提供する場合は AGPL の影響を受ける 可能性があり、Apache-2.0 や MIT の OSS より法務確認の手間がかかります。

なお minio/minio リポジトリは 2026 年 4 月 25 日にオーナーによってアーカイブされ、現在は read-only になっています。最新リリースの Docker イメージを社内開発で使い続けることは可能ですが、「この OSS リポジトリを基点にメンテナンスを追従していく」前提はもう成立しません。S3 単独用途の新規採用先としては、保守が続いている S3Mock（Apache-2.0）など Apache-2.0 / MIT 系の代替を優先的に検討するのが現実的です。

比較表

主要な候補を運用観点でまとめます。

候補ライセンス対応 AWS サービスの広さ主な互換性ポイントLocalStack 移行コスト
MiniStackMIT広い（40+）ポート 4566、AWS_ENDPOINT_URL で IaC 一通り対応。LocalStack 互換 init script パス小〜中。IAM 非強制
FlociMIT中〜広（47）ポート 4566、LOCALSTACK_PARITY で環境変数自動翻訳、コンテナ系は実 Docker spawn小
kumoMIT広い（76）ポート 4566、KUMO_DATA_DIR で永続化、Go SDK v2 互換を明示小
fakecloudAGPL-3.0中（30+）ポート 4566、Smithy 由来の conformance、SigV4 検証と IAM strict モード小〜中。AGPL の確認が必要
motoApache-2.0非常に広い（100+）デコレータ / Threaded server / Docker server。SDK の AWS_ENDPOINT_URL で多言語対応中〜大（テスト戦略の見直しを伴う）
DynamoDB LocalAWS 公式DynamoDB のみAWS 公式実装、SQLite 永続化小（単一サービス前提）
ElasticMQApache-2.0SQS のみ組み込み起動可、FIFO / DLQ / Visibility Timeout 対応小
S3MockApache-2.0S3 のみ（部分実装）JUnit / Testcontainers 統合が強い、path-style のみ小〜中

サービス数の表記は、公式サイトと README、リリースノートで揺れることが多く、新興 4 プロジェクト（MiniStack、Floci、kumo、fakecloud）はとくにマーケティング上の数字と実装の深さが必ずしも一致しません。採用判断では、「使う AWS API を PoC でどこまで通せるか」 を優先するのが安全です。

ユースケース別の選定ガイド

LocalStack に最も近い置き換えを最小変更で

docker-compose.yml のイメージ名と一部の環境変数を差し替えるだけで動かしたい場合は、Floci と MiniStack が第一候補です。両者ともポート 4566 を使い、LocalStack の init script パスや一部環境変数を温存しています。Java / Spring Boot プロジェクトでは Floci の Quarkus 親和性が、Python / IaC 中心のプロジェクトでは MiniStack の AWS_ENDPOINT_URL 統一が、それぞれ移行コストを下げます。

対応サービスについての API 厳密性を最優先

「使うサービスは限定的だが、本物の AWS と限りなく同じ挙動を求めたい」場合は fakecloud が候補です。Smithy 由来の conformance テストと SigV4 検証、IAM strict モードを持ち、対応サービスの範囲が要件に合えば、CI で「ローカルだけ通って本番で落ちる」種類のドリフトを最小化できます。ライセンスが AGPL-3.0 である点だけは事前に法務と合わせて確認しておきます。

Java / Spring Boot 中心のプロジェクト

Java / Spring Boot 中心のプロジェクトでは、Testcontainers と組み合わせて @SpringBootTest に組み込みやすいかが大きなポイントになります。Floci と MiniStack はどちらも Testcontainers モジュールを公式に提供しており、Spring Boot の @ServiceConnection パターンに自然に乗せられます。エンタープライズ用途の堅実な構えとしては、基盤エミュレータに Floci か MiniStack、DynamoDB だけは AWS 公式の DynamoDB Local、SQS は ElasticMQ で精度を補強、というハイブリッドも有力です。

Python テストを軽量に回したい

外部プロセスを立てずに in-process でモックを差し込みたい場合は、依然として moto のデコレータ が最速・最軽量です。「統合テストをもう少し下流に寄せず、コード近傍で速く回す」方針に切り替えるなら、LocalStack 置換ではなく moto への設計変更を選ぶほうが筋が良いです。多言語のテストを混在させたい場合は moto の standalone server を motoserver/moto で 1 つ立て、各言語の AWS SDK から AWS_ENDPOINT_URL で叩く形に統一できます。

単一サービスだけが必要

S3 だけ、SQS だけ、DynamoDB だけ、という限定要件であれば、広域エミュレータより DynamoDB Local / ElasticMQ / S3Mock に分解したほうが運用は単純です。AWS 公式や Apache-2.0 の特化型は、新興 OSS よりも保守の健全性とエッジケースの精度で先行している領域があります。

LocalStack からの移行チェックリスト

新興 OSS は更新速度が速い反面、エッジケースでの互換性は今後 6〜12 か月で見極めるべき段階にあります。一気に全面移行するより、次の順序で進めるのが失敗しにくいです。

  • 使用 AWS サービスと API の棚卸し: docker-compose.yml の SERVICES=、init script /etc/localstack/init/ の AWS CLI 呼び出し、テストコード内の endpoint_url 参照を grep する
  • LocalStack 固有機能の依存有無: Cloud Pods、Persistence snapshot、Resource Browser など、AWS API ではなく LocalStack 独自の機能に依存している箇所を洗い出す
  • Golden tests の整備: S3 / SQS / DynamoDB / Lambda / IAM / STS など、壊れると困る主要シナリオを golden tests としてコード化する
  • PoC: 候補を 2〜3 個選び、ブランチを切って docker-compose.override.yml でイメージだけ差し替えて、既存テストの通過率・起動時間・CI 安定性を比較する
  • IAM / SigV4 / presigned URL / path-style S3 / 永続化 / reset API の差分を明文化: 新興 OSS は各論で挙動差が出やすいため、テストで明示しておくと後の判断が早まる
  • CI で並行稼働: 一定期間 LocalStack と新候補を並列に走らせて差分を可視化してから切り替える
  • rollback 可能な構成を維持: 切替後もしばらくは compose / env / IaC profile を残し、必要に応じて戻せるようにしておく
flowchart TD
    A[利用 AWS サービスと LocalStack 依存を棚卸し] --> B{単一サービス中心か}
    B -- はい --> C[特化型を評価<br/>S3Mock / ElasticMQ / DynamoDB Local]
    B -- いいえ --> D{何を最優先にするか}
    D -- LocalStack に近い置き換え --> E[Floci / MiniStack / kumo を PoC]
    D -- 対応サービスの API 厳密性 --> F[fakecloud を PoC]
    D -- テスト軽量化 --> G[moto へ設計変更]
    C --> H[Golden tests 作成]
    E --> H
    F --> H
    G --> H
    H --> I[IAM / SigV4 / 永続化 / S3 URL 差分を検証]
    I --> J[CI で並行稼働]
    J --> K{差分が許容範囲か}
    K -- いいえ --> L[候補を変更またはサービス別に分割]
    K -- はい --> M[本番開発フローを切替]

セキュリティとライセンスの注意点

新興 OSS の採用にあたって、特に意識しておきたい点を最後にまとめておきます。

ライセンスは候補ごとに分かれており、MIT（MiniStack、Floci、kumo）、Apache-2.0（moto、ElasticMQ、S3Mock）、AGPL-3.0（fakecloud、MinIO） が混在します。社内のローカル開発・CI 用途で使う限りは AGPL でも大きな問題は起こりにくいですが、自社製品に同梱したり、SaaS の中で「ネットワーク経由で第三者に提供」する形態に組み込む場合は法務確認のステップが必要です。SPDX を採用候補のリスト単位で一覧化しておくと、後から議論しやすくなります。

Docker socket のマウントは、Floci / MiniStack の Lambda・コンテナ系サービスで必要になります。これはコンテナエスケープの典型ベクターでもあるため、CI ランナーが共有環境（GitHub Actions セルフホスト等）の場合は、socket をマウントしないジョブ分離か rootless Docker を検討します。

AI コーディングエージェント（Claude Code、Codex CLI など）と組み合わせて使う場合は、CLAUDE.md や AGENTS.md などのプロジェクト指示ファイルに 「このリポジトリでは LocalStack ではなく Floci（または MiniStack）を使う、ポート 4566 / AWS_ENDPOINT_URL=http://localhost:4566 / 認証不要」 を明示しておくと、生成コードの初期コンテキストが揃いやすくなります。LocalStack のドキュメントは学習データに大量に含まれているため、何も書かないとエージェントは localstack/localstack を docker-compose.yml に書き戻してくる傾向があります。

まとめ

LocalStack のアーカイブをきっかけに、AWS をローカルで再現する OSS の地図は 2026 年に大きく書き換わりました。LocalStack に近い体験を求めるなら Floci と MiniStack が第一候補、対応サービスについて API 厳密性を最優先するなら fakecloud、Python テストを軽く回したいなら moto、単一サービスのみなら DynamoDB Local / ElasticMQ / S3Mock へ分解するのが、現時点で最もぶれない方針です。新興 OSS はどれも勢いがある一方で、まだ若いプロジェクトであることに変わりはありません。Golden tests と並行稼働を挟みながら、半年〜1 年単位でどの実装が勝ち残るかを見ていくのが、エンタープライズ用途では現実的な構えになります。

以上、LocalStack のアーカイブを受けて OSS 代替を整理した、現場からお送りしました。