ハクソク

世界を動かす技術を、日本語で。

Floci – 無料のオープンソースのローカルAWSエミュレーター

45日前原文(github.com)

概要

Floci は、無料でオープンソースの ローカルAWSエミュレータ。 LocalStack Community のサポート終了を受け、 認証不要・CI制限なし を強みとする代替案。 高速起動・低メモリ消費・軽量イメージ を実現。 20以上のAWSサービス をサポートし、 MITライセンス で自由に利用可能。 docker compose up で即座に利用開始。

Flociとは

  • floccus雲 （ポップコーン状の雲）に由来する、 軽量・無料・OSS なローカルAWSエミュレータ
  • LocalStack Community Edition のサンセット（2026年3月）後の 制限回避 を目的とした選択肢
  • 認証トークン不要、 CI/CD制限なし、 セキュリティアップデート継続
  • docker compose up だけで即利用可能な手軽さ

FlociとLocalStackの比較

  • 認証トークン ：Flociは不要、LocalStackは2026年3月以降必須
  • CI/CDサポート ：Flociは無制限、LocalStackは有料プラン必須
  • セキュリティアップデート ：Flociは継続、LocalStackは凍結
  • 起動時間 ：Flociは約24ms、LocalStackは約3.3秒
  • アイドル時メモリ ：Flociは約13MiB、LocalStackは約143MiB
  • Dockerイメージサイズ ：Flociは約90MB、LocalStackは約1.0GB
  • ライセンス ：FlociはMIT、LocalStackは制限付き

サポートサービス

  • API Gateway v2 / HTTP API、 Cognito、 ElastiCache（Redis + IAM認証）
  • RDS（PostgreSQL + MySQL + IAM認証）、 S3 Object Lock（COMPLIANCE / GOVERNANCE）
  • DynamoDB Streams、 IAM（ユーザー、ロール、ポリシー、グループ）
  • STS（全7操作）、 Kinesis（ストリーム、シャード、ファンアウト）
  • KMS（署名、検証、再暗号化）
  • 20以上のサービスサポート、全408件のSDKテスト合格

クイックスタート

  • docker-compose.yml 例
    • サービス名：floci
    • イメージ：hectorvent/floci:latest
    • ポート：4566
    • ボリューム：./data:/app/data
  • 起動方法 ：docker compose up
  • アクセスURL ：http://localhost:4566
  • 任意のAWSリージョン・クレデンシャル利用可能
    • 環境変数設定例
      • AWS_ENDPOINT_URL=http://localhost:4566
      • AWS_DEFAULT_REGION=us-east-1
      • AWS_ACCESS_KEY_ID=test
      • AWS_SECRET_ACCESS_KEY=test
  • AWS CLI操作例
    • aws s3 mb s3://my-bucket
    • aws sqs create-queue --queue-name my-queue
    • aws dynamodb list-tables

SDK連携例

  • Java（AWS SDK v2）
    • DynamoDbClient.builder().endpointOverride(URI.create("http://localhost:4566"))
  • Python（boto3）
    • boto3.client("s3", endpoint_url="http://localhost:4566", region_name="us-east-1", aws_access_key_id="test", aws_secret_access_key="test")
  • Node.js（AWS SDK v3）
    • new S3Client({ endpoint: "http://localhost:4566", region: "us-east-1", credentials: { accessKeyId: "test", secretAccessKey: "test" }, forcePathStyle: true })

イメージタグ

  • latest ：ネイティブイメージ（推奨、サブ秒起動）
  • latest-jvm ：JVMイメージ（幅広いプラットフォーム対応）
  • x.y.z / x.y.z-jvm ：ピン留めリリース

設定方法

  • 全設定項目は環境変数（FLOCI_プレフィックス）で上書き可能
    • QUARKUS_HTTP_PORT（デフォルト4566）：HTTPポート
    • FLOCI_DEFAULT_REGION（デフォルトus-east-1）：AWSリージョン
    • FLOCI_DEFAULT_ACCOUNT_ID（デフォルト000000000000）：AWSアカウントID
    • FLOCI_STORAGE_MODE（デフォルトhybrid）：ストレージモード（memory、persistent、hybrid、wal）
    • FLOCI_STORAGE_PERSISTENT_PATH（デフォルト./data）：データディレクトリ
  • 詳細は公式ドキュメント参照

ライセンス

  • MITライセンス ：商用・非商用問わず自由利用可能

Hackerたちの意見

LocalStackのコミュニティエディションは2026年3月に終了します。認証トークンが必要になり、CIサポートがなくなり、セキュリティアップデートも凍結されます。Flociは条件なしの代替案です。

このプロジェクト、もし成功したら面白いことになるね。ルーマニア語でこの名前は「小さな毛の束」という意味だけど、カジュアルには陰毛のことを指すことが多いんだ。

└

ラテン語では「ウールの房」という意味で、価値がないことを表す「flocci non facio」という表現が有名だよ。これは「私はそれをウールの房の価値もないと考えている」という意味。

AWSやGCP、Azureみたいなクラウドプロバイダーは、開発用のローカルエミュレーターを提供すべきだね。そうすれば、開発者がもっとサービスを使うようになると思う。今、いくつかのAWSサーバーレススタックを使ってるけど、ローカルで統合テストするのが難しいか、ほぼ不可能なんだ。Localstackはまあまあの解決策を提供してるけど、AWSが開発者体験を向上させるために提供すべきサービスだと思う。彼らが最新の状態を保つのにも最適な立場にいるしね。

└

彼らは…収益を犠牲にするために努力すべきだね？

└

マイクロソフトは以前、Azure Service Dev Kitを使ってたよね。ASDKは、Azureクラウド全体をローカルでエミュレートするためのシングルノードの「サンドボックス」だった。今は似たようなものがあるかもしれないけど、規模は縮小してるかも。

└

CloudFlareのサーバーレス提供もやってるけど、まあまあ使えるよ。

└

AWSのエンジニアがローカルAWSスイートを公開してるのを見たよ。https://github.com/local-web-services/local-web-services これ、比較できるみたい。Localstackが少しオフセットされてるのを見るのはいいね…AI駆動のシフトレフトインフラツールのおかげかな？これはいいトレンドだ。

└

公式のローカルエミュレーターっていい響きだけど、AWSが「S3やIAM、Kinesisがノートパソコンでちょっと違う動きをする理由」を説明しなきゃいけなくなるんだよね。認められた瞬間に、みんなその不一致をAWSのバグだと思っちゃうから、開発の妥協点だとは考えない。AWSはそんなサポートの悪夢は避けたいんだよ。

これこそ私が待ってたものだよ。Localstackは大好きだし、彼らがやってくれたことには感謝してるけど、オープンなコミュニティ主導のソリューションの方がずっと適してると思ってた。AWSのエンジニアが貢献しやすくなるしね。彼らの人気製品の多くがローカル版を持ってるから、そうするのが彼らの利益になるのは間違いないよ。AIの導入が進む中で、ローカルファーストの統合テストは必須だし、それに対応できるチームは他のチームよりも先に行けると思う。

└

100%同意だね。特にエージェントワークフローが実際に状態を変化させるようになってきた今、ローカルテストが唯一安全にモデルがテーブルを消す時に何が起こるかを見る方法だから。

いいね、前にLocalstackを試したことがあるから、また試すのが楽しみだよ。ところで、GCP用の似たようなものって知ってる？今のところ、https://github.com/goccy/bigquery-emulatorがBigQueryの挙動をエミュレートするのにすごく役立ってるけど、GCP全体のエミュレーターは見つからないんだよね。

「ローカルAWS」（または「ローカルクラウド」）について、他のコメントや自分の経験を基にいくつかメモ。 - こういう製品が新しい顧客を獲得する足がかりになるかは疑問だな。お金がないとか、カード情報を入力したくない人は、年に6桁の顧客にはならないと思うし、そういう人たちが注目されるレベルにはならないよ。 - AWSの無料プランは実際かなり寛大。自分のニーズには、何十個ものアカウントに分けて年間10ドル未満で済んでる。 - AWSを学びたいなら、ハードな支出制限がないことを理解しないとダメ。実際に学ぶには、早い段階で痛い目に遭うのが一番。最初に5ドルオーバースペンドする方が、プロダクションで5,000ドルオーバースペンドするよりマシ。 - ローカルクラウドの主な利点は、物事を簡単にして、早く反復できること。セキュリティレイヤーに気を取られずに済むからね。すべてがローカルだから、サービスを使うことに集中できる。実際の開発アカウントに依存したいなら、まずすべてが安全であることを確認しないといけないけど、ローカルクラウドならそれをスキップできる。ただ、ライブに移行することに決めたら、そのセキュリティの負債を解消しないといけなくて、たいていの場合「私のコンピュータでは動く」ものが壊れちゃう。 - LocalstackはAWSの実際のサポートを受けてるから、機能が豊富でサービスのリリースに追従できるんだと思う。このFOSSの代替品がそれを持つとは思えないけど。

└

ローカルエミュレーターの主な使い道はユニットテストだね。特にVPCの設定みたいな、グローバルな副作用なしにはできないことのための統合テストもあるかも。開発アカウントのセキュリティは大したことじゃない。各開発者に個別のアカウントを与えて、請求アラートを設定すればいいだけ。

└

セキュリティが、こういうツールが欲しい理由の全てなんだ。特にIAMのエミュレーションについてね。組織の「最小特権」方針が厳しいと、ほとんど何も許可されてない状態から始めて、使うAPIコールの明示的なセットに対して権限を有効にしていかないといけない。Allow :を使うわけじゃないし、AWS管理のロールも使わない。これに加えて、特にterraformを使うと「このリソースを管理する必要がある」と「それを行うために必要な権限」との間にマッピングがないから、インフラで新しいことをするたびに権限のワッカモグのゲームに突入することになる。デプロイ/修正/デプロイのサイクルは、デプロイしたい機能を開発するのにかかった時間の何倍もかかることがある。ループを一周するのが完全なデプロイの試みだからね。もし機能だけでなく、それに付随する権限の正確なローカルエミュレーターがあれば、遅い部分をショートカットできる。Localstackは有料製品の一部としてIAMエミュレーションを提供してる。これがどれだけうまく機能するか楽しみだな。

└

LocalStackの大きな使い道はCI/CDだよ。CIパイプラインで毎日何百もの統合テストスイートを実行してると、無料プランは関係ない。数秒で立ち上げて解体できる、速くて決定的で隔離された環境が必要なんだ。リアルなAWSコールだとネットワーク遅延や最終的な整合性の不安定さ、レート制限、マージリクエストごとにかかるコストがあるからね。AWSを使えたらいいけど、実際にはそうならない。たとえ請求が問題にならなくても、制限や名前空間の概念がないと、CIではすぐに問題が出てくる。すべての開発者にAWSアカウントを持たせるのも現実的じゃない。200人でやったことがあるけど、まあまあうまくいったけど、管理が大変だった。無料プランは組織には対応してないし。 > 「彼らはハードな支出制限がないことを学ばなければならない。そして、実際に学ぶ唯一の方法は、できるだけ早く痛い目に遭うことだ。」これは変な意見だね。「火災安全を学ぶ最良の方法は、焼かれることだ。」ってこと？サプライズチャージを通過儀礼として扱わなくても、AWSの請求を理解することはできるよ。

数日前のこれにかなり似てるね（ただ、カバー範囲は少ないみたいだけど）： https://news.ycombinator.com/item?id=47420619 https://github.com/robotocore/robotocore

ローカルのAWSエミュレーターって、ステージング環境への信頼度が低いほど価値が増すツールの一つだよね。もしステージングアカウントが本番環境を完璧に再現しているなら、ローカルエミュレーターなんて必要ない。でも、誰もが完璧に本番を再現できるわけじゃないから、IAMポリシーやStep Functionsのステートマシン、SQS/SNSのファナウトに関しては、実際のAWSに対するイテレーションサイクルが数分で測られるから、こういうツールが必要になる。いつも疑問なのは、エミュレーションが実際のAWSの挙動にどれだけ近いかってこと。LocalStackはそれを追い続けてるけど、まだギャップがあるみたい。FlociがAWSの挙動があまり文書化されていないサービスをどう扱っているのか、ちょっと気になるね。

└

ステージングに頼ると、オフライン開発ができないし、他の人とぶつかることにもなる。安価なローカル実装は、一貫したテストには最高だよね。

└

結局、ステージングは必要だよね。でも、全ての開発者が同時にステージングをいじるわけにはいかない。地盤が揺れている中で、どうやってデバッグするの？理想を言えば、全ての開発者が自分のAWSアカウントを持って遊べるといいけど、それはコスト的に厳しいこともある。良い妥協点は、95%の作業をローカルのエミュレーターで行い、残りの5%をステージングで使うことかな。新しいコンポーネントを作るときに最初にやることの一つは、そのためのDocker Compose環境を作ることだね。

└

こういうツールの目的は開発であって、ステージングじゃないよ。ここで言う「開発」は、単に開発者がコードを書くことだけじゃなくて、簡単にモックできないような振る舞いテストを必要とするユニットテストも含まれる。だから、ステージングにプッシュする準備が整ったときには、AWSをエミュレートしたいという段階を超えて、UAT/test/staging（あなたの命名規則に応じて）AWSアカウントにプッシュするべきだよね。理想を言えば、AWSに複数の非本番環境があって、チームがしっかりしていれば、専任のクラウドプラットフォーム/DevOpsチームが開発者からこれらの非本番環境を本番と同じようにロックするべきだよ。機能ブランチ用にCI/CD経由でエフェメラル環境を自動的に立ち上げられたらボーナスポイントだけど、平均的なクラウドベースのプロジェクトには実用的じゃないことが多いよね。

このプロジェクト、機能を見る限りすごく良さそうだけど、コミット履歴（開発ブランチでも）を見るとほとんど何もないね。プルリクエストも実際の問題もないし、自動生成された匂いがして残念だな。もし「リアルデータ」でテストするつもりなら、どこに送られるかわからないから、信頼しづらくなるよね。

└

もしかしたら、雰囲気で作られたプロジェクトかもしれないね。

└

このコメントをする理由がわからないな。コミット履歴を見ると、このプロジェクトはまだ1週間しか経ってないのに。 >「どこに送られるかわからない」って、オープンソースの意味は、誰かが気づいて報告してくれるという理論的な信頼だったはずだよね。最近は、自分の好きなLLMを使ってセキュリティ監査を頼むだけで済むから。これを騙す方法はいくつかあるけど、魔法のようなものじゃないし、こういう監査を覆すのはかなり難しいと思うよ。

こういうツールは無駄な努力に思えるな。ユニットテストに使いたいなら、AWSサービスへの呼び出しをモックする方がいいと思う。そうすれば、自分がコントロールできる環境で自分の実装だけをテストできるからね。ローカル開発に使いたいなら、テスト環境を用意する方がいいと思う（Terraformや他のIaCツールを使って）。そうすれば、エミュレーターが実際のサービスとは異なる挙動をすることで、本番にバグが混入するリスクを避けられるよ。