floci-io/flociは、AWS SDKやCLI、Terraform、CDK、OpenTofuなどをそのまま使いながら、クラウドアカウントなしでAWS互換のAPIをローカルで動かすオープンソースのローカルAWSエミュレーターです。ポート4566番で待ち受け、LocalStack Community版の代替として、認証トークンなし・機能制限なしで76個のAWSサービスをカバーすると説明されています。README上ではDocker composeまたは専用CLIで起動し、既存のAWSワークフローをそのまま流用する設計です。
.dockerignoreがpom.xml、src、target配下のネイティブランナー、docker/entrypoint.shだけを残す構成になっており、Java系ビルドツールチェーン、おそらくQuarkusのネイティブイメージとしてビルドされたバイナリが実体だと読み取れます。README記載の起動時間 約24ミリ秒、アイドルメモリ 約13MiBという数値も、ネイティブバイナリ前提の値です。README表によると、Lambda、RDS、Neptune、ECS、EC2、CodeBuildなど状態を持つサービスは「Real Docker」実行、つまりホストのDockerを使ってコンテナを実際に起動し、応答の忠実度を高めています。永続化はin-memory、persistent、hybrid、write-ahead logの4方式から選べるとREADMEにあります。compatibility-testsディレクトリには、awscli・Go SDK・Java SDK・CDK・Terraform・OpenTofu向けのbatsテストやJUnitテストが多数あり、floci本体をfloci:4566として起動した上でこれらのテストを回して互換性を検証する仕組みが読み取れます。
- STEP 01
公式CLIをインストールしてfloci startを実行すると、ネイティブバイナリが起動し数十ミリ秒でポート4566が立ち上がる様子を確認できます。
- STEP 02
eval $(floci env)でAWS_ENDPOINT_URLやダミーの認証情報が環境変数に設定され、その後は通常のawsコマンドがそのまま使えるようになります。
- STEP 03
aws s3 mbやaws dynamodb create-tableを実行すると、実際のAWS環境と同じレスポンス形式でバケットやテーブルが作成されます。
- STEP 04
docker composeで起動する場合はimage floci/floci:latestを指定するだけで、AWS_ENDPOINT_URLを手動でexportする一手間が増えます。
- STEP 05
compatibility-tests配下のcompat-cdkやcompat-terraformを動かすと、cdklocal bootstrapやterraform applyがfloci:4566に対して実行され、S3バケットやSQSキュー、DynamoDBのGSIやLSIまで検証されるテストの流れを追体験できます。
- STEP 06
RDSやECS、Neptuneなど「Real Docker」対象サービスを使う場合は、floci自体がホストのDockerソケットを使って追加コンテナを起動するため、Docker権限やリソース消費が単純なモック型エミュレーターより増えると想定されます。
インストールなしで判断する前提では、localhost:4566に対してAWS SDKやTerraformなどをそのまま向けられる、無料でトークン不要のAWS互換エンドポイントが手に入るという建付けです。compatibility-testsのbatsやJUnitテスト群を見る限り、S3・SQS・SNS・DynamoDB・Secrets Manager・CDKデプロイなど広い範囲で実際のツールチェーンと組み合わせた動作確認がリポジトリ内に用意されています。
提供された資料はREADMEとファイルツリー、一部のテスト用ファイルのみで、コアとなるJavaソース本体は確認できていないため、76サービスの実装の質までは検証できません。
RDSやECS、Neptuneなど「Real Docker」方式のサービスは、Floci自体がホストのDocker daemonを操作する構成のため、Docker in Dockerに近い権限やセキュリティ考慮が必要になると考えられます。
README記載の起動時間やメモリ使用量、LocalStackとの比較表は開発元による自己申告の数値であり、第三者による再検証結果はこの資料には含まれていません。
ネイティブバイナリのビルドにはGraalVMなどのネイティブイメージツールチェーンが必要になると推測され、ソースからのビルドはDockerイメージ利用より難易度が上がる可能性があります。
LocalStack Communityの認証トークン要求やセキュリティ更新停止に不満があり、S3・SQS・DynamoDB・Terraform・CDKなど標準的なAWSワークフローをローカルやCIで無料に再現したいチームには合う選択肢です。一方でRDSやNeptuneなどDocker連携が必要な高忠実度サービスを本格的に使うなら、Docker実行環境の準備状況を事前に確認すべきです。compatibility-tests配下に実際のAWS CLIやCDK、Terraform、Go・Java SDKを使った検証テストが体系的に揃っている点は、単なる主張ではなく検証可能な設計になっている根拠として信頼できます。ただしコア実装自体は今回未確認のため、本番相当の精度が必要な用途では自分のユースケースで一度動作確認することをおすすめします。