Floci — LocalStackの代替として登場したAWSエミュレータ
LocalStack を CI で使っていると、Pro 機能の認証や有償ライセンスに引っかかる場面がある。代替を探していて Floci にたどり着いたので、概念だけメモしておく。手順ではなく「何のためのツールなのか」を腹落ちさせるのが目的。
Floci とは
- AWS サービスをローカルでエミュレートするツール
- MIT ライセンス、認証不要のオープンソース
- Java / Quarkus ベースで起動が軽い
- 立ち上がってまだ1ヶ月程度だが、対応サービスが急速に拡大中（v1.0.5 → v1.5.10、20 → 41 サービス）
LocalStack の代替として位置付けられているが、設計思想にはっきりした違いがある。
設計思想：「実コンテナで動かす」
Floci の特徴は、モックではなく実エンジンを動かすサービスが多いこと。
| サービス | 中身 |
|---|---|
| Lambda | AWS 公式ランタイムで実行 |
| RDS | 本物の PostgreSQL / MySQL |
| OpenSearch | 実エンジン |
| Athena | DuckDB で実 SQL を実行 |
| CodeBuild | 実 Docker ビルドが走る |
| EKS | k3s で Kubernetes API サーバーを実装 |
制御プレーン（API レイヤ）は AWS のワイヤープロトコル互換に保ちつつ、データプレーンは本物を動かす。これにより「ローカルでは通ったが本番で挙動が違う」という乖離が起きにくい。
EC2 のエミュレートをどう捉えるか
最初に引っかかった疑問はここだった。「EC2 = VM なのに、ローカルで VM を立てるのにわざわざ AWS API エミュレータを使う意味は？」
答えは、Floci の EC2 は「インスタンスの中身」ではなく「AWS API（コントロールプレーン）」をエミュレートしている、という整理。
つまり用途はこっちに寄る：
- IaC のテスト — Terraform / CDK で書いた
aws_instance,aws_security_group,aws_vpcなどを、本物の AWS にapplyする前に検証する - SDK / CLI を叩くコードのテスト —
RunInstances→DescribeInstances→TerminateInstancesのような運用スクリプトの単体・結合テスト - 周辺サービスとの連携検証 — ELBv2 との紐付け、Auto Scaling Group、Security Group のルール伝播
RunInstances してもログインできる Linux が立ち上がるわけではなく、「管理画面に『インスタンスがある』と見える状態を作るだけ」と捉えるのが近い。実 OS が必要なら素直に Docker や Vagrant を使ったほうが早い。
「中身が動く」サービスと「APIだけ」のサービスの線引き
これを誤解するとツールの効用がブレるので、一旦分けて考える。
- 中身が動く系：Lambda、RDS、OpenSearch、Athena、CodeBuild など → 実エンジンの挙動を含めて検証できる。本番との乖離が少ない
- API だけ系：EC2、IAM、タグ系の管理 API など → 「リソースの存在」「API 応答」をテストする用途。中身を期待してはいけない
「Floci で何ができるか」を考えるとき、サービスごとにこの線引きを意識すると用途を見誤らない。
どういう場面で効くか
- CI 上で Terraform plan / apply をかけて IaC を検証したいが、本物の AWS にお金を払いたくない
- LocalStack Pro を使っていたが、ライセンス・認証回りを取り払いたい
- Lambda や RDS の挙動を「本物に近い形で」ローカルで再現したい
- 統合テストで複数 AWS サービスをまたいだ動作確認をしたい
注意点
立ち上がって1ヶ月、まだ v1.5 系。コア API のカバレッジは増えているが、本番に近いテスト基盤として据えるなら自プロジェクトで使うサービスの対応範囲・互換性は要検証。LocalStack と並べて評価して、合うほうに寄せるのが現実的。
EC2 を例に「Floci で何をエミュレートしているのか」を概念で押さえると、ツールに対する期待値がブレなくなる。「ローカルで AWS が丸ごと動く」のではなく、「AWS の API 互換層と、一部サービスの実エンジン」がセットで動く、という理解が一番近い。