Flociが1ヵ月で41サービス対応へ - 怒涛のアップデートをまとめてみた

こんにちは。サービス開発室の武田です。

1ヵ月前にFlociを試した記事を書きました。MITライセンスで認証不要のLocalStack代替として登場した、まだ生まれて間もないオープンソースプロジェクトです。

この1ヵ月ほどで多くのアップデートがありましたので、まとめてみました。

1ヵ月で起きた主な変化

ざっくりサマリーすると、次のような状況です（2026年4月30日時点）。

• 公式組織floci-ioが発足し、リポジトリと公式サイト・Slackコミュニティが整備された
• 1ヵ月で 20回のリリース（1.0.5 → 1.5.10）、 412コミット、 243件のissue更新
• 対応AWSサービスが 20+ から41サービスへ ほぼ倍増
• スター数が約1,200だったところ 4,276 へ（3.5倍）
• ECS、EKS、Athena、CodeBuild、CodeDeployなどLocalStackでもPro限定だった重量級サービスが続々追加

順に見ていきます。

プロジェクト体制の整備

リポジトリとイメージの正式名称

前回記事ではhectorvent/flociを参照していましたが、専用Orgfloci-ioが作られて公式リポジトリが移行しました。Docker Hubのイメージ名も変わっています。

旧hectorvent/flociリポジトリは更新を停止すると公式アナウンスが出ています。前回記事で書いたdocker-compose.ymlを使っている場合は、image:行の差し替えが必要です。

# Before
image: hectorvent/floci:latest

# After
image: floci/floci:latest

コミュニティ

Slackワークスペースが立ち上がり、GitHub Discussionsもオープンしています。質問やフィードバックを投げる場所がはっきりしたのは大きいですね。

怒涛のアップデート

GitHub APIで集計してみました。前回の記事を公開した2026年3月24日から本記事を書いている時点まで、次のような数字です。

• リリース: 20回（1.0.5 → 1.0.11 → 1.1.0 → 1.2.0 → 1.3.0 → 1.4.0 → 1.5.0 → ... → 1.5.10）
• コミット: 412件（うちfeat:約110件）
• issue更新: 243件（PR除く）

平均すると2〜3日に1回リリースされている計算です。かなり活発です。

対応サービスが41個へ拡充

前回記事では「20以上のサービスに対応」と紹介しましたが、現在は 41サービス まで増えています。前回記事の時点で未対応だった新規サービスのうち、特にインパクトの大きそうなものを抜き出すと次のとおりです。

「実コンテナで動かす」サービスが増えたのは特徴的ですね。Floci本体は軽量なJava/Quarkusアプリケーションのまま、データプレーンには本物のDocker（Redpanda、k3s、DuckDB、registry:2など）を立ち上げます。

特に目を引くのは次の3つでした。

Athena: DuckDBサイドカーで実SQL実行

floci-duckという別コンテナ（DuckDB）を裏で起動し、そこに対して実際のSQLを発行するしくみです。Glueテーブル定義はクエリ実行時にDuckDBのビューとして自動登録されます。read_parquet/read_json_auto/read_csv_autoがSerDe情報から推論される作りです。

S3に置いたParquet/JSON/CSVに対するAthenaクエリがローカルで本物のSQL結果を返すので、データレイク開発のローカル検証手段として相当強力ですね。

EKS: k3sでLive Kubernetes APIサーバー

rancher/k3s:latestをクラスターごとに起動し、kubeconfigを返します。kubectlでつないで実際のKubernetes APIをたたける状態になるので、EKSへデプロイするマニフェストの動作確認がそのままローカル環境で済みます。

CodeBuild / CodeDeploy: 実ビルドと実トラフィックシフト

CodeBuildはStartBuildで実際のDockerコンテナを起動します。ログはCloudWatch Logsへストリームされ、ビルド成果物はS3へアップロードされます（Docker-in-Dockerでも動作）。

CodeDeployはLambdaエイリアスのRoutingConfigウェイトを実際にずらし、ライフサイクルフックを呼び、失敗時には自動ロールバックまで行います。CodeDeployDefault.*系の17種類のデプロイ設定も最初から組み込まれています。

既存サービスの強化

前回記事で扱った範囲（S3、SQS、DynamoDB、Lambda、Cognito）でも、目立つアップデートが多数入りました。気になったものだけ抜粋します。

Cognito

Lambdaトリガー連携の Custom Auth Flow が追加されました。具体的にはDefineAuthChallenge/CreateAuthChallenge/VerifyAuthChallengeResponseの3つです。前回記事ではUSER_PASSWORD_AUTHのみ確認した範囲です。

今回のアップデートで、アプリケーション独自の認証チャレンジを作るシナリオもローカル検証できるようになりました。

そのほかにも次のような項目が追加されました。

• SRP-6a認証の実装
• 管理系API（AdminEnableUser/AdminDisableUser/AdminResetUserPassword）
• ユーザープールのタグ操作（TagResource/UntagResource/ListTagsForResource）
• DescribeUserPoolのSchema完全対応

Lambda

地味に効きそうなのが、 S3経由のホットリロード です。S3Bucket=hot-reloadの予約値を使うと、関数コードのZipではなくS3に置いたコードを直接バインドマウントして起動するしくみで、コードを書き換えるだけで再デプロイ不要になります。

ほかにも次のような項目が入りました。

• ImageConfig.Command/EntryPointのサポート
• UpdateFunctionConfigurationAPI
• Reserved/Per-regionの同時実行制御
• Lambdaコンテナへのデフォルト資格情報やログ環境変数の自動注入
• SQSイベントソースのScalingConfig.MaximumConcurrency

DynamoDB

ExportTableToPointInTime/DescribeExport/ListExportsが実装されました。エクスポートが非同期に走ってgzip NDJSONとマニフェストをS3に書き出す、本家と同じレイアウトの動作です。

そのほかにも、AWSとの挙動差を埋める細かい改善が複数入っています。

• ReturnValuesOnConditionCheckFailure対応
• UPDATED_OLD/UPDATED_NEWのReturnValues対応
• CloudFormationでのGSI/LSI対応
• 起動時のDynamoDB Streams永続化ロード
• Kinesis Streaming Destination有効化

1.5.8では並行更新の整列まで入りました。UpdateItemカウンタや条件付きPutItem/DeleteItem、TransactWriteItemsが線形化（linearizable）になっています。

S3

次のような項目が追加されました。

• Lambda通知（PutBucketNotificationConfigurationのLambda行先）
• 静的Webサイトホスティング
• Object Lockヘッダー保持、明示的SSEヘッダー保持
• Content-Disposition/Cache-Controlヘッダー保持
• Canned ACLs対応
• ライフサイクルtransition-default-minimum-object-size

CloudFormation

リソースタイプの対応が大きく拡張されました。

• AWS::Events::Rule
• AWS::Pipes::Pipe
• AWS::Lambda::EventSourceMapping
• Fn::FindInMap
• DynamoDBのGSI/LSI

ZipFileインラインソースの自動Zipラップや、CDK生成のパス形式S3TemplateURLのローカルS3解決といった、CDK利用者にうれしい修正も入っています。

IAM

Floci起動時にAWS managed ExecutionRole系のポリシーが23本、自動登録されるようになりました。具体的には次のようなポリシーが含まれます。

• AWSLambdaKinesisExecutionRole
• AWSLambdaSQSQueueExecutionRole
• AWSLambdaVPCAccessExecutionRole
• AmazonECSTaskExecutionRolePolicy

Terraformやアプリケーション側でこれらのARNを指定してもエラーにならない、地味ですが効く改善ですね。

アーキテクチャ: 実Docker統合の拡大

前回記事ではLambda、ElastiCache、RDSが実コンテナで動くしくみを紹介しましたが、対象が増えました。READMEで「実Docker / 実エンジンで動く」とされているサービスは次のとおりです。

「ローカルで本物のエンジンが動く」「ただし制御プレーンはAWSのワイヤープロトコル互換」という二層構造になっています。LocalStackも有料プランで一部似たことをしていますが、Flociはこれを無料で提供している格好です。

まとめ

Flociは1ヵ月の間に、コミュニティ整備・サービス追加・既存機能強化のすべてで大きく前進していました。特に印象的だったのはこのあたりです。

• 公式Orgfloci-ioの発足とDockerイメージ移行。前回記事のdocker-compose.ymlを使っている方はイメージ名の差し替えが必要
• 対応サービスが41個まで拡充。ECS・EKS・Athena・CodeBuild・CodeDeployなどLocalStackでもPro限定だった重量級が無料でそろった
• 「実Docker / 実エンジンで動かす」サービスが拡大し、ローカル検証の精度が上がっている
• 1.0.5 → 1.5.10 と20リリース、412コミットという開発ペース

一方で、リリース頻度が高いぶん挙動の変化には注意が必要です。バージョンをlatestで固定せず、floci/floci:1.5.10のようにタグをピン留めしておく方が安心でしょう。

今回の記事を書くにあたって、新規追加されたサービスのうちいくつかを実機で軽く動かしてみました。基本的なシナリオはおおむね動いています。

サービスごとの実装深度には差があり、API数の多いサービスでは未実装のオペレーションに遭遇する可能性もあります。READMEの比較表やdocs/services/<service>.mdの対応Action一覧で事前確認しておくと安心です。

LocalStack Community Editionの代替として様子見していた方も、そろそろ試してみてはいかがでしょうか。1ヵ月後にもう一度様子を見てみたいですね。