developersIO
2026年6月 Flociアップデートまとめ、CloudFormationとWebコンソールに対応した1ヵ月

2026年6月 Flociアップデートまとめ、CloudFormationとWebコンソールに対応した1ヵ月

AWS
2026.06.30

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

LocalStackの代替として登場したオープンソースのAWSエミュレータ「Floci」を、これまでも取り上げてきました。

前回からまた1ヵ月が経ちました。開発のペースは変わらず活発です。今回もこの1ヵ月の更新を、いくつか手元で動かしながらまとめていきます。

前回までは「新しく増えたサービス」が記事の中心でした。今回はそれに加えて、CloudFormationによるプロビジョニングが実用寄りになり、Webコンソール（floci-ui）も登場しています。「個別のAPIを叩くエミュレータ」から「IaCでローカルにAWS環境を立てるエミュレータ」へ寄ってきた1ヵ月、という印象です。

この1ヵ月の主な変化（2026年6月29日時点）

前回記事（1.5.20時点）から現在（1.5.28）までの変化をサマリーすると、次のとおりです。

  • リリース 8回（1.5.20 → 1.5.28）、 284コミット。約3〜4日に1回というペースは変わらず
  • 対応サービスが 52 → 65 へ（公式表記）
  • GitHubスターが 13,299 → 14,528 へ
  • CloudFormationのプロビジョニング対応が拡充。リリースノートによると、VPC・Subnet・EC2・RDS・EKS・Auto Scaling・CloudWatchなどをテンプレートから作成できる。本記事ではVPC・Subnet・ロググループを実際に確認した
  • Webコンソール「floci-ui」が登場（1.5.26）。オンデマンドで起動する
  • AppSync・Cloud Map・CloudTrail・EMR・WAF v2・DocumentDB・S3 Vectors・IoT Coreなど、新サービスが多方面に追加
  • 状態の永続化（ECS・CodeBuild・Config・CodeDeployなど）が再起動をまたいで効くように整理された
  • GraalVM 25 / JDK 25 へ移行（1.5.21）

順に見ていきます。

開発の勢いと互換性テスト

GitHub APIで集計したところ、前回記事を公開した2026年5月30日（1.5.20）から本記事執筆時点（1.5.28）まで、リリースは8回、コミットは284件でした。

スター数は前回の13,299から14,528まで増えています。前回が約3倍（4,276→13,299）という急な伸びだったのに対し、今回は約9%です。公開直後の話題化フェーズが落ち着き、継続的な開発と機能拡張を見ていくフェーズに入った、という見方ができます。スターの伸びよりも、リリース回数・コミット数・対応サービスの拡大のほうが、いまのFlociの実態をよく表しています。

互換性テストの規模は、READMEによると 1,969件 でした。前回が1,968件だったので、ほぼ横ばいです。テスト件数で見ると、今回は「テストでカバーする深さを広げた月」というよりも「新サービスとIaC対応で間口を広げた月」だったといえます。

最大の変化: CloudFormation対応が実用寄りに

今回一番進んだのはCloudFormationです。この1ヵ月のリリースを追うと、プロビジョニング対応リソースが継続的に増えていました。

バージョン CloudFormationの主な追加
1.5.22 ECS・ELBv2リソースの作成、スタックの永続化、失敗時のロールバック
1.5.24 Step Functions ステートマシン
1.5.25 Lambdaバックドのカスタムリソース、レイヤーバージョン、EC2 VPC/Subnet
1.5.26 EC2インスタンス、RDS、EKS、CloudWatch Logs、メトリクスアラーム、Auto Scaling、Kinesis（データストリーム/Firehose）の9リソースタイプ、Fn::GetAZs・Fn::Cidr組込み関数
1.5.27 SAMの暗黙的API Gateway生成、SAM Globalsのマージ

特に1.5.26のまとめての追加が大きいです。リリースノート上は、VPC・EKS・RDS・Auto Scaling・監視を含むIaCスタックが、エンドツーエンドでデプロイできるようになった、とされています。本記事で実際に試したのは、このうちVPC・Subnet・ロググループの作成です。

実際にスタックをデプロイしてみる

環境構築は前回までと同じくdocker-compose.ymlを用意するだけです。リリースのペースが速いので、今回もバージョンを固定しています。

services:
  floci:
    image: floci/floci:1.5.28
    ports:
      - "4566:4566"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

$ export AWS_ENDPOINT_URL=http://localhost:4566
$ export AWS_DEFAULT_REGION=us-east-1
$ export AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test

今回新しく入ったFn::GetAZsとFn::Cidrを使って、VPCとサブネット2つ、ロググループを作るテンプレートを用意しました。Fn::Cidrで10.0.0.0/16から/24のサブネットを切り出し、Fn::GetAZsでアベイラビリティゾーンを割り当てます。

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  Vpc:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
  SubnetA:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId:
        Ref: Vpc
      CidrBlock:
        Fn::Select:
          - 0
          - Fn::Cidr:
              - Fn::GetAtt: [Vpc, CidrBlock]
              - 4
              - 8
      AvailabilityZone:
        Fn::Select: [0, Fn::GetAZs: ""]
  SubnetB:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId:
        Ref: Vpc
      CidrBlock:
        Fn::Select:
          - 1
          - Fn::Cidr:
              - Fn::GetAtt: [Vpc, CidrBlock]
              - 4
              - 8
      AvailabilityZone:
        Fn::Select: [1, Fn::GetAZs: ""]
  LogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: /floci/demo
      RetentionInDays: 7
Outputs:
  VpcId:
    Value:
      Ref: Vpc
  SubnetIds:
    Value:
      Fn::Join: [",", [Ref: SubnetA, Ref: SubnetB]]

デプロイしてみます。

$ aws cloudformation create-stack --stack-name floci-demo --template-body file://stack.yaml

$ aws cloudformation describe-stacks --stack-name floci-demo \
    --query 'Stacks[0].StackStatus' --output text
CREATE_COMPLETE

$ aws cloudformation list-stack-resources --stack-name floci-demo \
    --query 'StackResourceSummaries[].[LogicalResourceId,ResourceType,ResourceStatus]' --output text
Vpc       AWS::EC2::VPC       CREATE_COMPLETE
LogGroup  AWS::Logs::LogGroup CREATE_COMPLETE
SubnetA   AWS::EC2::Subnet    CREATE_COMPLETE
SubnetB   AWS::EC2::Subnet    CREATE_COMPLETE

すべてのリソースがCREATE_COMPLETEになりました。アウトプットも解決されています。

$ aws cloudformation describe-stacks --stack-name floci-demo \
    --query 'Stacks[0].Outputs[].[OutputKey,OutputValue]' --output text
VpcId      vpc-d96f0a14
SubnetIds  subnet-16e0dd4e,subnet-ab5a7299

CloudFormationで作ったサブネットは、EC2側のAPIからも見えます。Fn::Cidrが10.0.0.0/16を10.0.0.0/24と10.0.1.0/24に分割し、Fn::GetAZsがus-east-1a・us-east-1bを割り当てているのが確認できました。

$ aws ec2 describe-subnets \
    --query 'Subnets[?starts_with(CidrBlock, `10.`)].[SubnetId,CidrBlock,AvailabilityZone]' --output text
subnet-16e0dd4e  10.0.0.0/24  us-east-1a
subnet-ab5a7299  10.0.1.0/24  us-east-1b

CloudFormationの結果が、EC2サービスの状態としても反映されています。テンプレートをパースして終わりではなく、各サービスのリソースとして作られている、という点がポイントです。

注意点: ショートハンド記法（!Cidrなど）は要確認

ひとつ注意点があります。上のテンプレートはFn::Cidrのフル記法で書いていますが、最初は次のようなショートハンド（短縮形）で書いていました。

CidrBlock: !Select [0, !Cidr [!GetAtt Vpc.CidrBlock, 4, 8]]

これはエラーになりました。

could not determine a constructor for the tag !Cidr

!Cidrタグのコンストラクタが見つからない、というYAMLパース段階のエラーです。Fn::Cidrのフル記法に書き換えたところ、問題なく動きました。

Flociはショートハンド記法そのものには対応していて、!Refや!Select、!GetAttなど主要なタグは短縮形でも動きます。今回落ちたのは、新しく追加された!Cidrと!GetAZsだけでした。リポジトリを確認したところ、Fn::Cidr・Fn::GetAZsはロング形式の組込み関数としては追加されているものの、対応するショートハンドタグの登録が漏れていました。実装漏れと判断し、2つのタグの登録を追加するPRを出しています（floci-io/floci#1635）。

新しく追加された組込み関数では、ショートハンドがまだ対応していないことがあります。テンプレートが通らないときは、まずフル記法で書いてみるとよさそうです。

floci-ui: ローカル環境を「見る場所」ができた

1.5.26で、Webコンソールのfloci-uiが追加されました。これまではCLIやSDK越しに状態を確認するしかありませんでしたが、ブラウザでリソースを見られるようになっています。

floci-uiは、UIサーバーが常駐する作りではありません。ブラウザでFlociのエンドポイント（http://localhost:4566）にアクセスすると、まずランディングページが表示されます。

floci-2026-06-cloudformation-web-console-update_01.png

Acceptヘッダーで応答を出し分けています。Accept: text/htmlを送るブラウザには、同じ/でもこのHTMLを返します。AWS SDKやCLIには、これまでどおりS3のListBucketsレスポンス（XML）を返します。手元で試した範囲では、Acceptヘッダーの有無で応答が変わり、SDK/CLI相当のリクエストは従来どおりのXMLでした。

# ブラウザ相当（HTMLのランディングページが返る）
$ curl -s -H "Accept: text/html" http://localhost:4566/ | head -1
<!DOCTYPE html>

# SDK/CLI相当（従来どおりS3のListBuckets）
$ curl -s http://localhost:4566/ | head -c 80
<?xml version="1.0" encoding="UTF-8"?><ListAllMyBucketsResult ...

ランディングページの「Open Floci UI」ボタンを押すと、floci/floci-uiのコンテナがサイドカーとしてオンデマンドで起動します。手元では、ボタンを押したタイミングでfloci-uiコンテナが立ち上がりました。Flociから起動されるので、別プロセスとして管理する必要はありません（リリースノートによると、Flociのライフサイクルに紐づいて停止します）。起動後のコンソールがこちらです。

floci-2026-06-cloudformation-web-console-update_02.png

S3・データベース・k8sエンジンといったカテゴリでリソースを一覧でき、左上にはエンドポイントへの接続状態（Runtime reachable）が出ています。事前にCLIで作っておいたS3バケットも、Storageのリソース数に反映されていました。

興味深いのは、画面右上にAWSだけでなくAzure・GCPのタブがある点です。現状で実体があるのはAWSですが、UIの作りとしてはマルチクラウドを視野に入れているようです。

65サービスへ: この1ヵ月で増えた新サービス

対応サービスは前回の52から、公式表記で 65 になりました。実際に起動すると、ログとランディングページのどちらでも67個のサービスが有効と表示されました（公式表記の65とは差がありますが、数え方の違いによるものと思われます）。この1ヵ月で追加された主な新サービスを挙げます。一部はサービスそのものではなく、既存サービス内の新機能です。

分類 サービス 追加バージョン
アプリケーション統合 AppSync（GraphQL） 1.5.22
サービス検出 Cloud Map 1.5.24
監査 CloudTrail 1.5.24
分析 EMR 1.5.25
エッジセキュリティ WAF v2 1.5.25
バッチ処理 AWS Batch 1.5.25
DB（サーバーレスSQL） RDS Data API 1.5.25
DB（ドキュメント） DocumentDB 1.5.26
ベクトル検索 S3 Vectors 1.5.27
DB（インメモリ） MemoryDB 1.5.27
CI/CD CodePipeline 1.5.27
ネットワーク EC2 Network ACL（EC2内の新機能） 1.5.27
IoT IoT Core 1.5.28
アプリケーション実行環境 Elastic Beanstalk（初期対応） 1.5.28

分析（EMR）、エッジ（WAF v2）、IoT、CI/CD（CodePipeline）、ベクトル検索（S3 Vectors）と、方向性はかなり多方面です。1サービスずつ深掘りはしませんが、一覧で見ると守備範囲の広げ方が分かります。

なお、Steampipe（クラウドリソースをSQLで照会するOSSツール）のようなリソース収集ツールが使う読み取り系APIへの対応も入りました（1.5.28、#1538）。これまで未対応で400を返していたものが実装され、こうしたツールがFlociのリソースを読み戻す際に途中で失敗しなくなった、という互換性の改善です。

深掘り: AppSync・EKS・実エンジン路線

新サービスの追加と並行して、既存サービスを段階的に作り込む動きも続いています。全部を同じ重さでは扱えないので、いくつか抜き出します。

AppSyncの段階的な実装

AppSyncは1ヵ月で3段階に分けて作り込まれていました。

  • Phase 1（1.5.22）: 管理API。GraphQL APIのプロビジョニング
  • Phase 2（1.5.23）: スキーマレジストリ、CRUDLの完成、AWSスカラ型
  • Phase 3（1.5.28）: VTLリゾルバー向けの$utilランタイムライブラリ

特にPhase 3の$util対応が大きいです。$util.dynamodbや$util.errorといった、リゾルバーテンプレートでよく使うユーティリティのランタイムライブラリが入りました。リリースノートは、これで実際のAppSyncテンプレートに残っていた大きなギャップのひとつが埋まったとしています。ただしドキュメント上は、VTLテンプレートの評価（実行エンジン）自体はまだ未実装です。テンプレートをそのまま実行して検証できる段階ではないようです（手元での動作確認は今回はしていません）。

EKSがエンドツーエンドで通るように

EKSも複数のリリースにまたがって整備されました。

  • ホストからクラスターに到達・認証できるように（1.5.22）
  • IAMが標準のEKSクラスター/ノードグループ管理ポリシーをあらかじめ用意（1.5.23）
  • マネージドノードグループの作成・参照・一覧・削除に対応（1.5.24）

リリースノートによると、これらがそろったことで、EKSのプロビジョニングフローがひととおり通る構成になりました（こちらも手元での確認は今回はしていません）。

「実エンジン」路線の継続

制御プレーンはAWS互換のAPIを返し、データプレーンには実在のデータベースエンジンをバックエンドとして立ち上げる、という二層構造の方針は今回も継続しています。

  • Neptune: openCypherクエリ向けにneo4jバックエンドを追加（1.5.27）。NEPTUNE_DB_TYPEで切り替え。従来のGremlin（Apache TinkerPop Gremlin Server）も併存
  • DocumentDB: MongoDB互換のワークフロー向けに追加（1.5.26、mongo:7.0）
  • MemoryDB: ACLとユーザーによる認証をモデル化（1.5.28）。素のRedis的なオープンエンドポイントではなく、本物に近い認証の形に

互換性・信頼性周りの改善

ここでは、手元で確認できた信頼性周りの修正を挙げます。

S3 Selectの未対応式がエラーになった

前回記事で、S3 Selectについて「簡易評価器は未対応の式に出会っても、エラーや警告を出さずに黙って空の結果を返す」という点を注意点として挙げました。本物のAWSなら400エラーになる場面です。

ここが1.5.22で改善されました（#1160）。未対応の式を投げると、空ではなくエラーが返るようになっています。floci-duckを起動していない状態で、前回と同じCAST付きのクエリを投げてみます。

$ aws s3api select-object-content --bucket select-test --key data.csv \
    --expression "SELECT * FROM S3Object s WHERE CAST(s.age AS INTEGER) > 25" \
    --expression-type SQL \
    --input-serialization '{"CSV":{"FileHeaderInfo":"USE"}}' \
    --output-serialization '{"JSON":{}}' out.json

An error occurred (ExternalEvalException) when calling the SelectObjectContent
operation: Unsupported S3 Select WHERE expression: Unsupported predicate near: (

前回は黙って空のファイルが返っていましたが、今回は「この式はサポートしていない」とはっきり返ってきました。気付かないうちに空の結果を本物だと思い込む、というリスクが減りました。なお、全件取得（SELECT * FROM S3Object）は前回同様そのまま動きます。

その他の修正

  • SQSのMaximumMessageSizeの上限を256KBから、実際のAWSの上限である1MBに修正（1.5.25）
  • DynamoDBの式バリデーション強化。無効な式は400と正確なエラーメッセージを返す（1.5.27, 1.5.28）
  • IAMのエンティティストアを並行アクセスでスレッドセーフに（1.5.28）
  • LocalStack互換のReady.起動ログ行（1.5.24）。Ready.行を待ち受けているCIなら、待受マーカーを変えずに流用しやすくなる

起動ログでは、このReady.行も実際に出ていました。

=== AWS Local Emulator Ready ===
Ready.
floci 1.5.28 native (powered by Quarkus 3.36.0) started in 0.035s.

状態の永続化が整理された

再起動をまたいだ状態保持も、この1ヵ月でまとめて手当てされています。これまでサービスごとに作り込まれていた永続化を、1.5.24で入ったStorageBackedMapという共通基盤に寄せる形で整理した、という流れです。この基盤の上に各サービスを順次移しており、対応サービスのリソースが再起動後も残るようになりました。

  • EC2の状態（1.5.26）。CloudFormationの参照が再起動後も解決できる
  • ECS・CodeBuild・AWS Config・ACM証明書（1.5.27）
  • CodeDeploy（1.5.28）

永続化の挙動はFLOCI_STORAGE_MODEで切り替えます。モードは4つあります。

モード 再起動後のデータ 書き込み 主な用途
memory 残らない 最速 ユニットテスト・CI
persistent 残る 変更ごとに同期ディスク書き込み 永続状態が必要な開発
hybrid 残る メモリ読み込み＋非同期でディスクへ書き出し 一般的なローカル開発
wal 残る 追記型のWAL＋コンパクション 書き込みの多いワークロード

注意したいのはデフォルト値です。コード上のデフォルトはhybridですが、配布されるDockerイメージはapplication.ymlの指定でmemoryになっています。前述のdocker-compose例のようにFLOCI_STORAGE_MODEを指定しなければ、状態は再起動で消えます。永続化したいときはFLOCI_STORAGE_MODE=hybridなどを明示します。保存先（FLOCI_STORAGE_PERSISTENT_PATH）はボリュームに割り当てておきます。なお、モードはサービス単位で個別に上書きできます。

まとめ

この1ヵ月のFlociは、新サービスの追加に加えて、CloudFormation対応とWebコンソールという「使い方そのものが変わる」変化があった月でした。手元で動かした範囲では、CloudFormationスタックのデプロイ（Fn::Cidr/Fn::GetAZs含む）、floci-uiコンソール、S3 Selectの改善を確認しました。いずれも期待どおりに動いています。

  • CloudFormationのプロビジョニングが拡充。リリースノート上はVPC・EC2・RDS・EKS・Auto Scaling・監視周りまでテンプレートから作成でき、IaCでローカル環境を立てられるようになってきた。手元ではVPC・Subnet・ロググループを確認した
  • Webコンソール「floci-ui」が登場。オンデマンドのサイドカーとして起動し、SDK/CLIの挙動には影響しない
  • 対応サービスが65個へ。AppSync・Cloud Map・EMR・WAF v2・DocumentDB・S3 Vectors・IoT Coreなど多方面に拡大
  • 既存サービスの段階的な作り込み（AppSync Phase 1〜3、EKSのエンドツーエンド対応）
  • 状態永続化の整理と、S3 Selectのエラー化など信頼性周りの改善。前回挙げた弱点のひとつが解消された

一方で注意点もあります。互換性テストの件数は横ばいで、サービスごとに実装の深さにはばらつきがあります。プロダクション相当の検証に使うなら、READMEのservice notesやdocs/services/<service>.mdで対応状況を確認しておくのがよいでしょう。本文の!Cidrの例のように、新しく追加された組込み関数では、ショートハンド記法がまだ通らない場合もあります。また、リリース頻度が高いので、latestではなくバージョンをピン留めしておくことを引き続きお勧めします。

「サービス数が増える」段階から、「IaCやコンソールで実際の開発体験が変わる」段階へ移ってきた、という1ヵ月でした。引き続き様子を見ていきたいですね。

本記事の数値やリリース内容は、次の一次情報をもとにしています。

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

【セッションレポート】AWS Infrastructure as Code : 2025 年主要アップデートの振り返り（DVT225）
tmorio (まると)
2026.06.30
KiroのAI-DLCで、あえて脆弱なEC2環境のCloudFormationテンプレートを生成・検証してみた
suzuki.ryo
2026.06.14
[アップデート]Amazon CloudWatch が EC2 コンソールにビジュアルエージェント設定機能を追加しました
Shiina Yuichi
2026.05.01
Console-to-Codeが一般提供開始になりました！
tmorio (まると)
2024.10.10