2026年9月 Flociアップデートまとめ、ローカルCAが入りIAMのマネージドポリシーが評価されるようになった

Floci 2.0.0と2.1.0のアップデートをまとめました。IAMのマネージドポリシーが実際のドキュメントを返すようになり、Logs InsightsとCloud Controlの未対応ケースはエラーになりました。TLSのローカルCAを動かしました。

武田隆志

2026.09.30

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

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

導入と主要サービスの動作検証（2026年3月）
公開から1ヵ月のアップデートまとめ（2026年4月30日）
さらに1ヵ月のアップデートまとめ（2026年5月30日）
CloudFormationとWebコンソールに対応した1ヵ月（2026年6月30日）
認可の作り込みとCloudTrailのイベント記録が入った1ヵ月（2026年7月30日）
CloudFrontの配信とAppSyncのGraphQLエンドポイントが動くようになった（2026年8月29日）

前回からまた1ヵ月が経ちました。今回もこの1ヵ月の更新を、いくつか手元で動かしながらまとめていきます。

今回はメジャーバージョンが上がり、2.0.0と2.1.0が公開されました。前回の記事で挙げたIAMのマネージドポリシー、Logs Insights、Cloud Controlには、いずれも修正が入っています。

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

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

リリース 3回（2.0.0と2.0.1が9月1日、2.1.0が9月15日）。1.7.0と2.1.0の間に 856コミット
READMEの対応サービス数は、2.0.0で 84。2.1.0では総数の表記がなくなった
GitHubスターが 22,504 → 26,051 へ
READMEの互換性テスト件数は 2,506 → 2,576 へ
Dockerイメージ（amd64、圧縮サイズ）が 119.7MB → 80.6MB へ
IAMのマネージドポリシーが、AWSのポリシードキュメントを返すようになった
Logs Insightsは、>=やlike、statsを使ったクエリが失敗として返るようになった
TLSにローカルCAが入り、CAを信頼すればHTTPSで接続できる。Python 3.13のデフォルト設定では検証に失敗する
新サービスはOrganizations、FIS、EFS、Redshift、Control Tower、Verified Permissionsなど

リリースと対応範囲の数字

1.7.0（8月18日）の次が2.0.0（9月1日）で、同じ日に修正1件の2.0.1が出ています。その2週間後に2.1.0（9月15日）が出ました。リリースノートの項目数は、2.0.0がBug Fixes 146件とFeatures 92件、2.1.0がBug Fixes 337件とFeatures 156件です。前回の記事で「未リリース」としていたOrganizations、FIS、EFSなどは2.0.0に入りました。

メジャーバージョンが上がりましたが、2.0.0のリリースノートで破壊的変更として明示されているコミットは、Step Functionsの1件（#2699）です。

READMEの対応サービス数は、1.7.0の69から2.0.0で84になりました。2.1.0では総数の表記がなくなり、「Broad AWS coverage. Free forever.」という文とServices Overviewへのリンクに置き換わっています。対応サービスの表そのものは残っていて、2.1.0では91行あります。複数のサービスを1行にまとめた行を含むので、行数はサービス数と一致しません。

互換性テストの件数は2.0.0で2,576件に更新され、2.1.0でも同じ数字です。

Dockerイメージのサイズは、Docker Hubのタグ情報（amd64、圧縮サイズ）で1.7.0が119.7MB、2.0.0が138.9MB、2.1.0が80.6MBです。2.1.0には、ベースイメージをubi9-microに変える変更（#3085）が入っています。リリースノートの「109MBから78MBへ」はarm64のnightlyで測った変更前後の値で、amd64のリリースタグの数字とは測定対象が異なります。

前回の宿題

環境構築はこれまでと同じで、docker-compose.ymlを用意して起動します。

services:
  floci:
    image: floci/floci:2.1.0
    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

IAMマネージドポリシー: `Allow *`ではなくなった

前回は、1,566件のマネージドポリシーがすべてAllow *のドキュメントを返していました。IAM強制モードを有効にすると、AmazonS3ReadOnlyAccessだけを付けたユーザーでバケットを作成できる状態でした。

2.1.0には、AWSのポリシードキュメントを使う変更（#3237）と、実際のデフォルトバージョンを返す変更（#3275）が入っています。同じポリシーを取得してみます。

$ aws iam get-policy --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
    --query 'Policy.DefaultVersionId' --output text
v3
$ aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
    --version-id v3 --query 'PolicyVersion.Document.Statement'
[
    {
        "Action": [
            "s3:Get*",
            "s3:List*",
            "s3:Describe*",
            "s3-object-lambda:Get*",
            "s3-object-lambda:List*"
        ],
        "Effect": "Allow",
        "Resource": "*"
    }
]

読み取り系のアクションだけを許可するドキュメントになりました。件数は1,566件のままです。入っているのは現在のデフォルトバージョンだけで、v1を指定するとNoSuchEntityが返ります。

強制モード（FLOCI_SERVICES_IAM_ENFORCEMENT_ENABLED=true）で、前回と同じ操作をします。

# ro-user（AmazonS3ReadOnlyAccess のみ）のアクセスキーで実行
$ aws s3 ls s3://root-bucket
2026-09-29 11:06:14          5 x.txt
$ aws s3 mb s3://ro-made-this
make_bucket failed: s3://ro-made-this An error occurred (AccessDenied) when calling the CreateBucket operation: User is not authorized to perform: s3:CreateBucket
$ echo written-by-ro | aws s3 cp - s3://root-bucket/y.txt
upload failed: - to s3://root-bucket/y.txt An error occurred (AccessDenied) when calling the PutObject operation: User is not authorized to perform: s3:PutObject
$ aws sqs create-queue --queue-name ro-q

aws: [ERROR]: An error occurred (AccessDeniedException) when calling the CreateQueue operation: User is not authorized to perform: sqs:CreateQueue

一覧と取得は成功し、バケットの作成、オブジェクトの書き込み、SQSキューの作成は拒否されました。前回は3つとも成功していた操作です。

確認できたのは、強制モードを有効にした環境で、IAMに登録したユーザーが今回のAPIを呼んだ場合の結果です。強制モードはデフォルトでは無効です。有効にしても、アクセスキーがtestの場合や、IAMに登録されていないアクセスキーの場合は評価されずに許可されます。

#2042: Logs Insightsの`>=`や`like`はクエリの失敗になった

前回は、>=やlikeを使ったfilterが警告付きで無視され、全件が返る状態でした。issueの論点だった「未対応の構文をエラーにすべきか」は残っていました。

このissueは9月6日にcloseされました。対応するPR（#3139）が2.1.0に入っています。3件のログイベントを入れたロググループに、前回と同じクエリを投げます。

$ aws logs start-query --log-group-name /hw/app \
    --start-time $(( $(date +%s) - 3600 )) --end-time $(( $(date +%s) + 3600 )) \
    --query-string 'fields @message | filter @message >= "x"' \
    --query queryId --output text
e51ff11f-1e33-41f3-bdf0-3b2a3457ea2b
$ aws logs get-query-results --query-id e51ff11f-1e33-41f3-bdf0-3b2a3457ea2b \
    --query '{status:status,count:length(results)}'
{
    "status": "Failed",
    "count": 0
}

StartQueryはクエリIDを返し、GetQueryResultsのstatusがFailedになります。クエリごとの結果は次のとおりです。

クエリ	1.7.0	2.1.0
`filter @message >= "x"`	警告付きで全件	Failed
`filter @message like /ERROR/`	警告付きで全件	Failed
`stats count(*) by bin(5m)`	警告付きで無視	Failed
`filter @message = "beta INFO two"`	1件	1件

likeとstatsも失敗するようになりました。Logs Insightsのクエリを含むテストをFlociで動かしている場合は、2.1.0への更新でクエリが失敗に変わる可能性があります。

失敗の理由はAPIの応答には含まれず、サーバーログに出ます。

WARN  [io.git.hec.flo.ser.clo.log.CloudWatchLogsService] Logs Insights query e51ff11f-... will fail: Unsupported filter expression: @message >= "x"

andで条件をつないだfilterは、2.1.0でもエラーにならず0件を返します。前回のissueに書いた、警告なしで0件になるケースです。

# filter @message = "beta INFO two" and @message != "x"
{
    "status": "Complete",
    "count": 0
}

docs/services/cloudwatch.mdのLogs Insightsの節は、2.1.0でも「未対応の構文はクエリを失敗させない」という説明のままです。これは前々回に私が#2044で書いた内容です。#3139はソースとテストだけを変更しています。挙動に合わせてドキュメントを書き直すPRを出しました（#4717）。

#2043: Cloud Controlの未対応タイプはエラーになった

未対応タイプのListResourcesが空のリストを返す件も、9月6日にcloseされました。対応するPR（#3141）が2.1.0に入っています。

$ aws cloudcontrol list-resources --type-name AWS::Lambda::Function

aws: [ERROR]: An error occurred (UnsupportedActionException) when calling the ListResources operation: ListResources is not supported for resource type AWS::Lambda::Function.
$ aws cloudcontrol list-resources --type-name AWS::S3::Bucket \
    --query 'ResourceDescriptions[].Identifier'
[
    "cf-origin"
]

一覧できるタイプは前回と同じ9つで、増えてはいません。前回の「作れるが一覧できない」という差も残っています。SQSキューで試すと、作成と個別取得はできて、一覧はエラーになります。

$ aws cloudcontrol create-resource --type-name AWS::SQS::Queue \
    --desired-state '{"QueueName":"cc-created-2"}' \
    --query ProgressEvent.RequestToken --output text
# → GetResourceRequestStatus で SUCCESS
$ aws cloudcontrol get-resource --type-name AWS::SQS::Queue \
    --identifier http://localhost:4566/000000000000/cc-created-2 \
    --query 'ResourceDescription.Properties' --output text
{"QueueName":"cc-created-2","Id":"http://localhost:4566/000000000000/cc-created-2"}
$ aws cloudcontrol list-resources --type-name AWS::SQS::Queue

aws: [ERROR]: An error occurred (UnsupportedActionException) when calling the ListResources operation: ListResources is not supported for resource type AWS::SQS::Queue.

空のリストが返っていたときは「キューが存在しない」と読めてしまいましたが、2.1.0では一覧に対応していないことがエラーで分かります。この対応範囲の差は、2.1.0のドキュメントにも明記されています。

AppSync: APIキー認証は成功、2.1.0のリゾルバーは未実装

前回出したPR（#2645）と、認証のPhase 7（#2380）が2.0.0に入りました。create-api-keyが返すidはda2-で始まるキー値になり、レスポンスからapiKeyフィールドはなくなっています。

$ aws appsync create-api-key --api-id ${API_ID}
{
    "apiKey": {
        "id": "da2-1j1qi8dt7pl4cbpnuqxov6a1l2",
        "expires": 1791252000,
        "deletes": 1796436000
    }
}

`x-api-key`	結果
なし	401（`Missing authorization header`）
誤った値	401（`You are not authorized to make this call.`）
`create-api-key`の`id`	200

2.1.0には、JWTの署名とSigV4の検証（#3541）も入っています。

リゾルバーは2.1.0でも実行されません。NONEデータソースのリゾルバーを設定してクエリを投げると、前回と同じく{"data":{"hello":null}}が返ります。2.1.0のドキュメントでも、リゾルバーのディスパッチはPhase 8、データソース接続はPhase 9の未実装項目です。

mainには、VTLリゾルバーを実行する変更（#4356、#4423）が入っています。nightlyイメージ（floci/floci:nightly-09282026）で試したところ、NONEデータソースのリゾルバーはエラーになりました。

{"data":{"hello":null},"errors":[{"message":"VTL mapping template evaluation failed: io.github.hectorvent.floci.services.appsync.graphql.ReturnDirective","locations":[],"path":["hello"],"errorType":"MappingTemplate","errorInfo":null}]}

サーバーログにはReturnDirectiveのClassNotFoundExceptionが出ています。DynamoDBデータソースにGetItemのリゾルバーを付けたクエリも、同じエラーでした。1日前のnightlyでは、レスポンスを固定値だけのテンプレートに変えても結果は変わりませんでした。

2.0.0で変わったJSONataの定義検証

2.0.0の破壊的変更は、Step FunctionsのJSONata式に関するものです（#2699）。入力をトップレベルの名前（nameなど）で参照している定義は、作成の時点で拒否されます。AWSも同じ定義を拒否します。

PassステートのOutputにトップレベル参照を書いた定義を用意します。

{
  "QueryLanguage": "JSONata",
  "StartAt": "Greet",
  "States": {
    "Greet": {
      "Type": "Pass",
      "Output": { "message": "{% 'hello ' & name %}" },
      "End": true
    }
  }
}

1.7.0では、この定義は検証と作成のどちらも成功します。入力に{"name":"Floci"}を渡して実行すると、次の結果になりました。

$ aws stepfunctions describe-execution --execution-arn ${EXECUTION_ARN} \
    --query '{status:status,output:output}'
{
    "status": "SUCCEEDED",
    "output": "{\"message\":\"hello \"}"
}

実行は成功し、出力はnameの値を含まないhello でした。2.1.0では、同じ定義が検証で拒否されます。create-state-machineも、同じメッセージのInvalidDefinitionで失敗します。

$ aws stepfunctions validate-state-machine-definition --definition file://bare.json
{
    "result": "FAIL",
    "diagnostics": [
        {
            "severity": "ERROR",
            "code": "UNSUPPORTED_JSONATA_EXPRESSION",
            "message": "Reference to 'name' at the top level is not supported.",
            "location": "/States/Greet/Output/message"
        }
    ],
    "truncated": false
}

式を{% 'hello ' & $states.input.name %}に直した定義は、1.7.0でも2.1.0でも作成でき、hello Flociを返します。

1.7.0でトップレベル参照がどう評価されるかは、式の書き方によって変わります。今回の式では値が空のまま成功しましたが、別の式でも同じ結果になるとは限りません。2.0.0以降に更新して定義の作成が失敗した場合は、エラーのlocationが指す式を$states.input.<名前>に直します。Assignで定義した変数を参照する場合は$<名前>です。

CloudFrontの配信に反映されたヘッダー設定

前回の記事では、CloudFrontがS3オリジンのコンテンツを配信するようになったことを確認しました。そのとき、レスポンスヘッダーはS3のものがそのまま返っていました。2.0.0には、レスポンスヘッダーポリシーの適用（#1833）と、オリジンカスタムヘッダーの転送（#1832）が入っています。

レスポンスヘッダーポリシー

カスタムヘッダー1つとセキュリティヘッダー3つを設定したポリシーを作ります。

{
  "Name": "blog-headers",
  "Comment": "custom + security headers",
  "CustomHeadersConfig": {"Quantity": 1, "Items": [{"Header": "X-Policy", "Value": "applied", "Override": true}]},
  "SecurityHeadersConfig": {
    "ContentTypeOptions": {"Override": true},
    "FrameOptions": {"FrameOption": "DENY", "Override": true},
    "StrictTransportSecurity": {"AccessControlMaxAgeSec": 31536000, "IncludeSubdomains": true, "Override": true}
  }
}

このポリシーのIDを、ディストリビューションのDefaultCacheBehavior.ResponseHeadersPolicyIdに指定します。オリジンは前回と同じく、index.htmlを置いたS3バケットです。

$ curl -s -i -H "Host: EI5ZKYEAL7U76Q.cloudfront.net" http://localhost:4566/
HTTP/1.1 200 OK
Content-Type: text/html
...
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Policy: applied

<h1>hello from S3 origin</h1>

ポリシーに書いた4つのヘッダーが付きました。1.7.0でも同じ手順でポリシーの作成と関連付けはできますが、配信のレスポンスにヘッダーは付きません。

AWSマネージドのレスポンスヘッダーポリシーも、Managed-SecurityHeadersPolicyやManaged-SimpleCORSなど5件が取得できます。

オリジンカスタムヘッダー

オリジンカスタムヘッダーは、CloudFrontからオリジンへのリクエストに固定のヘッダーを足す設定です。オリジン側でこのヘッダーを検証して、CloudFrontを経由しないアクセスを拒否する構成でよく使います。

受け取ったリクエストヘッダーをJSONで返すHTTPサーバーを、カスタムオリジンとして用意しました。Flociと同じDockerネットワークにecho-originという名前で起動しています。プライベートアドレスに解決されるホストはデフォルトで拒否されるので、Floci側の環境変数で許可します。

    environment:
      FLOCI_SERVICES_CLOUDFRONT_ALLOWED_PRIVATE_ORIGIN_HOSTS: "echo-origin"

オリジンの設定にX-Origin-Verify: shared-secret-42を指定し、ビューアからは同じ名前のヘッダーに別の値を付けてリクエストします。

$ curl -s -H "Host: EJXR0YT9QDEBOH.cloudfront.net" \
    -H "X-Origin-Verify: forged" -H "X-Viewer-Only: v1" \
    "http://localhost:4566/items?color=red"
{
 "path": "/items",
 "headers": {
  "X-Origin-Verify": "shared-secret-42",
  "Host": "echo-origin:8080",
  "Connection": "keep-alive",
  "User-Agent": "Apache-HttpClient (Java/25.0.4.1)"
 }
}

オリジンが受け取ったX-Origin-Verifyは設定した値で、ビューアが送ったforgedは届いていません。

このディストリビューションには、X-Frame-OptionsをOverride: falseにしたポリシーを付けていました。オリジンのHTTPサーバーはX-Frame-Options: SAMEORIGINを返すようにしてあり、配信のレスポンスでもオリジンのSAMEORIGINが残りました。

クエリ文字列の?color=redと、ビューアが付けたX-Viewer-Onlyは、オリジンに届いていません。ドキュメントによると、キャッシュポリシーとオリジンリクエストポリシーの配信時の評価は未実装のままです。オリジンへ何を転送するかをポリシーで制御する構成は、まだ確認できません。

許可していないプライベートなオリジンを指定した場合、ディストリビューションの作成は成功し、配信が502になります。サーバーログに出るのはUnknownHostExceptionという例外名だけです。実装では、名前解決のあとにプライベートアドレスを検出した場合もこの例外を投げるので、ログからはDNSの失敗と区別できません。

2.1.0のTLSとローカルCA

FlociのTLSは以前からあり、FLOCI_TLS_ENABLED=trueで有効になります（デフォルトは無効）。これまではサーバー証明書が自己署名で、ドキュメントの例もクライアント側で証明書の検証を無効にするものでした。2.1.0で、ローカルのルートCAがサーバー証明書に署名するしくみが入りました（#3078）。

services:
  floci:
    image: floci/floci:2.1.0
    ports:
      - "4566:4566"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      FLOCI_TLS_ENABLED: "true"

CAを取得して信頼する

CAの証明書は/_floci/ca.pemから取得できます。

$ curl -s http://localhost:4566/_floci/ca.pem -o floci-root-ca.pem
$ openssl x509 -in floci-root-ca.pem -noout -subject -enddate
subject=CN=Floci Local CA
notAfter=Dec 31 23:59:59 2050 GMT

$ aws --endpoint-url https://localhost:4566 sts get-caller-identity

aws: [ERROR]: SSL validation failed for https://localhost:4566/ [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)

$ export AWS_CA_BUNDLE=$PWD/floci-root-ca.pem
$ aws --endpoint-url https://localhost:4566 sts get-caller-identity
{
    "UserId": "000000000000",
    "Account": "000000000000",
    "Arn": "arn:aws:iam::000000000000:root"
}

1.7.0で同じ設定にすると、サーバー証明書の発行者はCN=localhost（自己署名）で、/_floci/ca.pemは404です。

AWS_CA_BUNDLEはプロセス単位の設定のため、OSの信頼ストアにCAを入れなくても使えます。ドキュメントでも、プロセス単位の環境変数を使う方法が先に案内されています。

ACMで発行した証明書も同じCAが署名しています。request-certificateで作った証明書を取り出してopenssl verify -CAfile floci-root-ca.pemにかけると、検証に成功しました。

カスタムドメインを作るとSANが増える

サーバー証明書のSANには、localhostや*.localhost.floci.ioなどが最初から入っています。ワイルドカードは1階層分だけのため、api.dev.localhost.floci.ioのような名前は対象外です。2.1.0では、API Gatewayなどでカスタムドメインを作ると、その名前がサーバー証明書に追加されます（#3086）。

$ aws apigateway create-domain-name --domain-name api.dev.localhost.floci.io

作成の前後でサーバー証明書を比べると、シリアル番号が変わり、SANの末尾にDNS:api.dev.localhost.floci.ioが増えていました。Flociの再起動はしていません。作成前は証明書のエラーになっていたhttps://api.dev.localhost.floci.io:4566/へのリクエストが、作成後はTLSの接続まで通ります。ドメインにAPIをマッピングしていないので、応答は404です。

追加されるのは、localhostやlocalhost.floci.ioなどローカル用の接尾辞をもつ名前だけです。api.example.comで試すと、ドメインの作成は成功し、証明書には追加されず、サーバーログに警告が出ました。

WARN  [io.git.hec.flo.con.TlsCertificateManager] TLS: refusing to add api.example.com to the server certificate: not under a local suffix (...)

Lambdaのコンテナに入るCAバンドル

Flociが起動するコンテナには、CAバンドルが渡されます（#3091）。Lambda関数の中で環境変数を出力すると、CAに関する5つの変数が/etc/floci-ca-bundle.pemを指していました。SSL_CERT_FILE、AWS_CA_BUNDLE、REQUESTS_CA_BUNDLE、NODE_EXTRA_CA_CERTS、CURL_CA_BUNDLEです。

バンドルには119件の証明書が入っていて、公開されているCAにFlociのCAを足した内容です。Lambdaから公開サイトへのHTTPSリクエストも200が返りました。

Lambdaに渡されるAWS_ENDPOINT_URLは、TLSを有効にしていてもhttp://を指していました。この値を使うクライアントはHTTPで接続します。

Python 3.13のデフォルト設定ではFlociの証明書を検証できない

Lambdaの中からhttps://localhost.floci.io:4566/_floci/healthへ、urllibでリクエストしました。python3.12のランタイムでは200が返りました。python3.13ではCERTIFICATE_VERIFY_FAILED: Missing Authority Key Identifierになります。ホストのPython 3.13でも同じ結果になります。

import ssl, urllib.request
ctx = ssl.create_default_context(cafile="floci-root-ca.pem")
print(urllib.request.urlopen("https://localhost:4566/_floci/health", context=ctx).status)

Python 3.13では、ssl.create_default_context()がVERIFY_X509_STRICTをデフォルトで有効にします。Flociが発行する証明書をopenssl x509 -textで見ると、鍵識別子の拡張が2つともありませんでした。Authority Key Identifier（AKI）とSubject Key Identifier（SKI）です。サーバー証明書、CAの証明書、ACMで発行した証明書のいずれも同じです。

どちらの拡張が必要なのかを確かめるために、検証用のCAで組み合わせを4つ作り、Python 3.13で接続しました。

CAのSKI	サーバー証明書のAKI	結果
なし	なし	Missing Authority Key Identifier
なし	あり	Missing Subject Key Identifier
あり	なし	Missing Authority Key Identifier
あり	あり	OK

サーバー証明書にAKIを足すだけでは通らず、CAの証明書にもSKIが必要でした。永続化されている既存のCAにはSKIがないので、新しく発行する証明書に拡張を足しても、既存の環境ではエラーが残ります。

この内容はissueにしました（#4621）。起票した日のうちに、別の方から修正のPR（#4644）が出ています。PRでは、既存のCAは同じ鍵で証明書を発行し直す方針です。CAのフィンガープリントが変わるので、Python 3.13から接続する場合はca.pemを取得し直します。curl --cacert、AWS CLI、Python 3.12では検証に成功します。Python 3.13でも、SSLコンテキストからVERIFY_X509_STRICTを外すと200が返りました。対応が入るまでの接続方法には、HTTPのほかに、FLOCI_TLS_CERT_PATHで自前の証明書を指定する方法があります。

その他の更新

次の表は、リリースノートに記載されている更新のうち、手元では動かしていないものです。

分類	内容	バージョン
IAM	SCPの評価と`aws:PrincipalArn`（#2637）。IAMとOrganizationsの両方の強制フラグが必要	2.0.0
Lambda	Kubernetesを実行基盤にするランナー（#1941）	2.0.0
Step Functions	`SFN_MOCK_CONFIG`によるサービス統合のモック（#2452）、`Retry`（#2455）	2.0.0
S3	グローバルなバケット名前空間を有効にするオプション（#2640）	2.0.0
CloudFormation	CDKのProviderフレームワークによるカスタムリソース（#2688）	2.0.0
EC2	インスタンスの起動時にVPC単位のDockerネットワークを作成（#3272）。VPCピアリング接続の管理API（#2654）	2.1.0
IoT	MQTT over TLS（#3142）とWebSocket（#3150）、デバイス証明書の発行と検証（#3079、#3180）	2.1.0
Redshift	`COPY FROM s3`（#3100）と`UNLOAD TO s3`（#3129）、Data API（#3186）	2.1.0
Firehose	JSONレコードのParquet変換（#3333）、Lambdaによる変換（#3393）	2.1.0
Bedrock	`ConverseStream`の実装（#2889）。`InvokeModelWithResponseStream`は501のまま	2.1.0
Webコンソール	Flociがコンソールをサイドカーとして起動する設定と、コンソール側の契約の公開（#3641）	2.1.0

S3のオプションを有効にすると、別のアカウントのバケットを名前で参照できます。IAMの強制モードとS3の認証はどちらもデフォルトで無効のため、このオプションだけを有効にすると、前回確認したアカウント間の分離がなくなります。アクセスをポリシーで制御するには、FLOCI_SERVICES_IAM_ENFORCEMENT_ENABLEDとFLOCI_SERVICES_S3_ENFORCE_AUTHも有効にします。

まとめ

2.0.0以降へ更新するときに既存のテストへ影響するのは、JSONataのトップレベル参照と、Logs Insightsのlikeやstatsを使ったクエリです。どちらも、これまで通っていたものがエラーになります。IAMの強制モードを有効にしている場合は、マネージドポリシーで許可されていない操作が拒否に変わります。

2.1.0のあと、mainには9月29日時点で644コミットが積まれています。AppSyncのリゾルバーはこの中に含まれますが、9月28日のnightlyではエラーになりました。次のリリースに入った時点で、#4621と#4717の行方と合わせて確認する予定です。

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

floci-io/floci（GitHubリポジトリ）
Releases（2.0.0、2.0.1、2.1.0のリリースノート）
Floci公式ドキュメント
動作確認はfloci/floci:2.1.0で実施しました。以前の挙動との比較にはfloci/floci:1.7.0、AppSyncのリゾルバーの確認にはfloci/floci:nightly-09282026を使用

2026年9月 Flociアップデートまとめ、ローカルCAが入りIAMのマネージドポリシーが評価されるようになった

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

リリースと対応範囲の数字

前回の宿題

IAMマネージドポリシー: `Allow *`ではなくなった

#2042: Logs Insightsの`>=`や`like`はクエリの失敗になった

#2043: Cloud Controlの未対応タイプはエラーになった

AppSync: APIキー認証は成功、2.1.0のリゾルバーは未実装

2.0.0で変わったJSONataの定義検証

CloudFrontの配信に反映されたヘッダー設定

レスポンスヘッダーポリシー

オリジンカスタムヘッダー

2.1.0のTLSとローカルCA

CAを取得して信頼する

カスタムドメインを作るとSANが増える

Lambdaのコンテナに入るCAバンドル

Python 3.13のデフォルト設定ではFlociの証明書を検証できない

その他の更新

まとめ

関連記事

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

EVENTS

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

リリースと対応範囲の数字

前回の宿題

IAMマネージドポリシー: Allow *ではなくなった

#2042: Logs Insightsの>=やlikeはクエリの失敗になった

#2043: Cloud Controlの未対応タイプはエラーになった

AppSync: APIキー認証は成功、2.1.0のリゾルバーは未実装

2.0.0で変わったJSONataの定義検証

CloudFrontの配信に反映されたヘッダー設定

レスポンスヘッダーポリシー

オリジンカスタムヘッダー

2.1.0のTLSとローカルCA

CAを取得して信頼する

カスタムドメインを作るとSANが増える

Lambdaのコンテナに入るCAバンドル

Python 3.13のデフォルト設定ではFlociの証明書を検証できない

その他の更新

まとめ

関連記事

EVENTS

IAMマネージドポリシー: `Allow *`ではなくなった

#2042: Logs Insightsの`>=`や`like`はクエリの失敗になった