July 2026 Floci Update Summary: A Month That Brought Refined Authorization and CloudTrail Event Logging

Hello. I'm Takeda from the Service Development Department.

We've previously covered "Floci," an open-source AWS emulator that emerged as an alternative to LocalStack.

• Introduction and verification of key service behavior (March 2026)
• Summary of updates one month after release (April 30, 2026)
• Summary of another month of updates (May 30, 2026)
• A month with CloudFormation and web console support (June 30, 2026)

Another month has passed since our last article. This time, we'll summarize the updates over this past month while running a few things locally.

This time, fewer new services were added, while many changes focused on filling in the details of existing services. Additionally, there were several things that couldn't be understood just from the release note headings, so we'll cover those as well. Points of concern discovered during testing have been submitted as issues and PRs.

Main Changes Over the Past Month (as of July 30, 2026)

Summarizing the changes from our previous article (as of 1.5.28) to the current version (1.5.34):

• 6 releases (1.5.29 → 1.5.34), 170 commits
• Supported services increased from 65 → 69 (official count). However, the breakdown includes some recounting
• GitHub stars increased from 14,528 → 18,022
• Compatibility test count in README went from 1,969 → 2,506
• Authorization implementation has progressed. IAM AssumeRole trust policies, STS session policies, and S3 authorization checks can each be enabled via configuration
• The !Cidr shorthand notation issue mentioned in the previous article was resolved in 1.5.30. The submitted PR was merged
• Step Functions expanded in multiple areas: state machine version API, ecs:runTask, JSONata Assign, HTTP invocations, and more
• Two new services: Amazon MQ (1.5.30) and Lightsail (1.5.32). CloudTrail became an in-process implementation in 1.5.34 and now records S3 data events

Let's go through each item.

Update Status and Compatibility Tests

Based on data collected via the GitHub API, from the time of the previous article's data collection (June 29, 2026) to the release of 1.5.34 on July 29, there were 6 releases and 170 commits. The previous period had 8 releases and 284 commits, so both counts are lower.

Looking at the release dates, from 1.5.29 (June 30) through 1.5.33 (July 15), releases came every 3–4 days, but then there was a 2-week gap until 1.5.34 (July 29). 25 PRs were merged during those 2 weeks. Compared to 1.5.30, which saw 44 PRs merged in 3 days, this was a relatively calm month in terms of pace.

The star count grew from 14,528 to 18,022.

The compatibility test count, as shown in the README, went from 1,969 to 2,506. However, we can't simply say "537 tests were added." Comparing the breakdown against the README from version 1.5.28, it was as follows (the figure of 2,506 hasn't changed between 1.5.33 and 1.5.34):

The Rust test suite was removed in 1.5.30 (#1717). The reason for removal is not mentioned in the release notes. The majority of the increase came from Java SDK tests (+427).

In the previous article, I described a month where test counts were flat and called it "a month that widened the scope," but this time the test side was built up.

Previous Homework: !Cidr Shorthand Notation

In the previous article, I noted a caveat about CloudFormation's Fn::Cidr and Fn::GetAZs: while the full notation worked, the shorthand (!Cidr, !GetAZs) would fail at the YAML parsing stage. After checking the repository, I found that tag registration was missing and submitted a PR to add it.

This PR was merged on July 3 and included in 1.5.30, released the same day. Let's verify. The environment setup is the same as before — just prepare a docker-compose.yml.

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

This time, I write the template using the shorthand notation directly, without converting to full notation as I did last time.

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: !Select [0, !Cidr [!GetAtt Vpc.CidrBlock, 4, 8]]
      AvailabilityZone: !Select [0, !GetAZs ""]
  SubnetB:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref Vpc
      CidrBlock: !Select [1, !Cidr [!GetAtt Vpc.CidrBlock, 4, 8]]
      AvailabilityZone: !Select [1, !GetAZs ""]
Outputs:
  SubnetIds:
    Value: !Join [",", [!Ref SubnetA, !Ref SubnetB]]

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

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

$ aws ec2 describe-subnets \
    --query "Subnets[?starts_with(CidrBlock, '10.0')].[SubnetId,CidrBlock,AvailabilityZone]" \
    --output text
subnet-50549f44  10.0.0.0/24  us-east-1a
subnet-89ae5138  10.0.1.0/24  us-east-1b

The template that previously failed with could not determine a constructor for the tag !Cidr now passes as-is. The CIDR splitting via Fn::Cidr and AZ assignment via Fn::GetAZs also produce the same results as with the full notation.

I could have reported it as an issue, but since the cause was already identified, I went straight to submitting a PR. It took two days to merge, and it was included in a release just 3 hours after that. In fast-moving projects, it's quicker to go ahead and fix things as you notice them.

Authorization Implementation

What was consolidated this month is the authorization area. Up until now, Floci processed requests regardless of the contents of the access key. Over this past month, the following settings have been added:

All of these are disabled by default and can be enabled via environment variables. Let's try S3 authorization.

There are two relevant environment variables, described as follows:

We start with both enabled and create one IAM user with S3 permissions and one with no permissions at all.

$ aws iam create-user --user-name s3-user
$ aws iam put-user-policy --user-name s3-user --policy-name s3-access \
    --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:*","Resource":"*"}]}'
$ aws iam create-access-key --user-name s3-user

With the credentials of the user who has permissions, bucket creation and object retrieval work as before. When the same operations are attempted with a user without permissions, and with an access key that isn't registered at all, the results were:

# IAM user without permissions
$ aws s3api get-object --bucket auth-demo --key o.txt /tmp/out.txt
An error occurred (AccessDenied) when calling the GetObject operation:
User is not authorized to perform: s3:GetObject

# Unregistered access key
$ aws s3api get-object --bucket auth-demo --key o.txt /tmp/out.txt
An error occurred (InvalidAccessKeyId) when calling the GetObject operation:
The AWS Access Key Id you provided does not exist in our records.

The same error codes as in the actual AWS environment were returned.

Note that the two environment variables have different roles. Testing each one individually, the results were as follows:

FLOCI_SERVICES_S3_ENFORCE_AUTH checks whether the access key exists and whether the resource is public or private on the S3 side, but does not evaluate IAM policies. FLOCI_SERVICES_IAM_ENFORCEMENT_ENABLED is needed to reproduce policy-based denial. When you want to test policy behavior locally, it seems best to enable both.

Additionally, default encryption behavior was also fixed in 1.5.33. Previously, calling GetBucketEncryption on a bucket without a setting configured would return a 404, but now it returns an SSE-S3 configuration, just like in a real environment.

$ aws s3api get-bucket-encryption --bucket auth-demo
{
    "ServerSideEncryptionConfiguration": {
        "Rules": [
            {
                "ApplyServerSideEncryptionByDefault": {
                    "SSEAlgorithm": "AES256"
                },
                "BucketKeyEnabled": false
            }
        ]
    }
}

To 69 Services: New Services and New Features

The number of supported services officially went from 65 to 69. However, not all 4 additions are brand new services. In 1.5.30, IoT Core and S3 Vectors, which were already supported, were added to the service list, and together with Amazon MQ added in the same release, the count was corrected to 68 (#1716). Lightsail was then added to bring the total to 69.

Here are the newly added services and notable features within existing services added over this past month:

Amazon MQ spins up a RabbitMQ container, following the same approach as RDS and ElastiCache — placing a real engine as the backend. Lightsail, on the other hand, is an in-process implementation and does not actually start real VMs. The EKS Fargate profile support doesn't mean a Fargate-equivalent execution environment is created; it means configurations including profiles can now be provisioned.

RDS mock mode is a mode where clusters and instances can be created without starting Docker containers. It's useful in CI environments where Docker in Docker isn't available, or for tests that don't actually run SQL.

CloudTrail Now Records Events

In 1.5.34, CloudTrail became an in-process implementation and now actually records S3 data events (#1460). Previously, it only handled the lifecycle of trails (creation, deletion, logging start/stop), but now operation records are retained. Let's try it locally.

We create a destination bucket for logs and a bucket to monitor. The interval for writing logs defaults to 60 seconds, but we set it to 10 seconds to reduce waiting time.

services:
  floci:
    image: floci/floci:1.5.34
    ports:
      - "4566:4566"
    environment:
      FLOCI_SERVICES_CLOUDTRAIL_FLUSH_INTERVAL_SECONDS: "10"

$ aws s3 mb s3://my-source
$ aws s3 mb s3://my-trail-logs

$ aws cloudtrail create-trail --name my-trail --s3-bucket-name my-trail-logs
$ aws cloudtrail put-event-selectors --trail-name my-trail --event-selectors '[{
    "ReadWriteType": "All",
    "IncludeManagementEvents": false,
    "DataResources": [{"Type": "AWS::S3::Object", "Values": ["arn:aws:s3:::my-source/"]}]
  }]'
$ aws cloudtrail start-logging --name my-trail

We run a successful operation and a failing operation against the target bucket.

$ echo hello | aws s3 cp - s3://my-source/greeting.txt
$ aws s3 cp s3://my-source/greeting.txt -
hello
$ aws s3api get-object --bucket my-source --key nothere /tmp/nope
An error occurred (NoSuchKey) when calling the GetObject operation: ...

After a short wait, a log file appears in the destination bucket. The key format matches AWS as well.

$ aws s3api list-objects-v2 --bucket my-trail-logs --query 'Contents[].Key' --output text
AWSLogs/000000000000/CloudTrail/us-east-1/2026/07/30/000000000000_CloudTrail_us-east-1_20260730T0035Z_5eSB3s8UPvfON0jU.json.gz

After decompressing the gzip, 4 records were inside.

Even the internal HeadObject call made by aws s3 cp is recorded. Failed operations are also retained with an errorCode, so you can test processing that assumes audit logs for errors. The record structure also follows AWS closely.

{
  "eventVersion": "1.11",
  "userIdentity": {
    "type": "IAMUser",
    "accessKeyId": "test",
    "userName": "root"
  },
  "eventTime": "2026-07-30T00:35:25Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "PutObject",
  "awsRegion": "us-east-1",
  "requestParameters": {
    "bucketName": "my-source",
    "key": "greeting.txt"
  }
}

The 6 S3 operations recorded are PutObject, GetObject, HeadObject, DeleteObject, ListObjects, and GetObjectAcl. A list is available in docs/services/cloudtrail.md. Conversely, only S3 data events are recorded, so it cannot be used for auditing API calls to services other than S3.

Trying Logs Insights and AppSync

I ran two new features whose scope was hard to read from the release note headings alone.

CloudWatch Logs Insights

It says that Logs Insights queries were supported in 1.5.31. I put 1 INFO and 2 ERROR entries into a log group and tried filtering with filter.

$ NOW=$(date +%s)
$ QID=$(aws logs start-query --log-group-name /floci/demo \
    --start-time $((NOW-300)) --end-time $((NOW+300)) \
    --query-string 'fields @timestamp, @message | filter @message like /ERROR/' \
    --query queryId --output text)

$ aws logs get-query-results --query-id "$QID" --query '{status:status,stats:statistics}'
{
    "status": "Complete",
    "stats": {
        "recordsMatched": 3.0,
        "recordsScanned": 3.0,
        "bytesScanned": 0.0
    }
}

It should have been narrowed down to the 2 entries containing ERROR, but all 3 were returned. The query itself completes with Complete and no error. Changing the syntax to filter @message like "ERROR" produced the same result. I also tried stats count(), but raw records are returned without aggregation. On the other hand, limit 1 did work.

Looking at the implementation, the supported commands are fields, filter, sort, dedup, and limit, and the filter operators are only =, !=, and ==. This scope is intentional, and the PR that added Logs Insights also states "filter (= / !=)." Since like isn't in the support table, the entire stage is dropped and all records are returned.

What caught my attention is that there's another way things get dropped. Let's try using >=.

$ aws logs start-query --log-group-name /floci/demo \
    --start-time $((NOW-300)) --end-time $((NOW+300)) \
    --query-string 'fields @timestamp, @message | filter @message >= "x"' \
    --query queryId --output text

The result was 0 records. Because the logic that searches for operators interprets the = part of >= as the operator, the field name becomes @message >. Since no such field can be resolved, no rows match and the result is 0. When using like, a warning appears in the server log, but this path produces no warning at all.

# A warning appears for 'like'
Ignoring unsupported Logs Insights filter: @message like /ERROR/
Ignoring unsupported Logs Insights command: stats

# Nothing appears for '>='

According to AWS documentation, filter supports =, !=, <, <=, >, and >=, and like /ERROR/ is also listed as a regex syntax. Both are valid queries in an actual AWS environment. Using the conventional FilterLogEvents on the same log group does produce filtered results.

$ aws logs filter-log-events --log-group-name /floci/demo \
    --filter-pattern "ERROR" --query 'events[].message' --output text
ERROR database timeout   ERROR connection refused

In the previous article, I covered the case where S3 Select silently returned empty results for unsupported expressions. That was improved in 1.5.22 to return an error. This is a similar situation, so I filed an issue for Logs Insights as well (#2042). The gist is whether it would be safer to fail the query for unsupported syntax. The >= misparse looks like a standalone bug that could be fixed directly, so I included that point as well.

Also, as of 1.5.34, docs/services/cloudwatch.md does not list StartQuery or GetQueryResults. Of the 24 actions the handler implements, only 14 are documented. This table is managed manually rather than being auto-generated. I submitted a PR to add the missing entries, and it was merged (#2044).

AppSync

AppSync received "Phase 4: VTL engine" in 1.5.29 and "Phase 5" in 1.5.32, with the release notes indicating that five phases of implementation are now complete. In the previous article, I wrote that while the $util runtime library had been added, VTL template evaluation itself was not yet implemented. Let's check whether that has changed.

Starting with the management API: registering a schema and creating a NONE data source and resolver.

$ API_ID=$(aws appsync create-graphql-api --name vtl-demo \
    --authentication-type API_KEY --query 'graphqlApi.apiId' --output text)

$ aws appsync start-schema-creation --api-id "$API_ID" --definition fileb://schema.graphql
{
    "status": "PROCESSING"
}

$ aws appsync get-schema-creation-status --api-id "$API_ID"
{
    "status": "SUCCESS"
}

This works without issues so far. The asynchronous schema creation added in Phase 5 also transitions from PROCESSING to SUCCESS. Data source and resolver registration succeeded as well.

Next, let's try sending a GraphQL query. The endpoint can be retrieved from GetGraphqlApi.

$ aws appsync get-graphql-api --api-id "$API_ID" \
    --query 'graphqlApi.uris.GRAPHQL' --output text
http://localhost:4566/v1/apis/16bfb9b4149a4c2a905b25cad1/graphql

$ API_KEY=$(aws appsync create-api-key --api-id "$API_ID" \
    --query 'apiKey.id' --output text)

$ curl -s "http://localhost:4566/v1/apis/${API_ID}/graphql" \
    -H "Content-Type: application/json" -H "x-api-key: ${API_KEY}" \
    --data '{"query":"query { hello(name: \"Floci\") { message } }"}'
<?xml version="1.0" encoding="UTF-8"?><Error><Code>InvalidArgument</Code>
<Message>POST requires either ?uploads, ?uploadId, ?restore or ?select parameter.</Message>

An S3 error was returned as XML. This path is not being handled as a GraphQL endpoint and is instead being routed to S3. Setting the Host header to {apiId}.appsync-api.us-east-1.amazonaws.com format and calling from inside the container yielded the same result.

Checking the repository documentation, docs/services/appsync.md at the 1.5.34 tag lists the following under "Not Implemented":

Execution engine (Phase 5): GraphQL query execution, resolver dispatch, VTL template evaluation

GraphQL query execution, resolver dispatch, and VTL template evaluation are listed as not implemented. The documentation and the local test results are consistent.

1.5.34 includes a fix to prevent REST requests to unknown services from falling back to S3 (#1967). This addresses the difficulty of tracing routing, but the same S3 error is returned for AppSync's GraphQL endpoint even in 1.5.34.

So the situation with AppSync is unchanged from what I described in the previous article. The management API side has been fleshed out, so you can go as far as defining AppSync resources with CloudFormation or CDK. However, it hasn't yet reached the point of executing GraphQL queries and validating results.

Looking at the implementation plan issue (#1173), query execution and HTTP endpoints are organized as "Phase 6." The corresponding PR (#1884) has been open since July 15 and involves changes on the scale of 1,300 lines. Once that's merged, it should become possible to send queries. The phase numbering differs between the release notes and the documentation, but the work itself continues.

Cloud Control API Coverage

In 1.5.31, ListResources for the Cloud Control API was supported. This is an update connected to resource collection tools like Steampipe, which I mentioned in the previous article. Let's test whether resources created with service-specific APIs can be read back.

I created an S3 bucket, an SQS queue, and a log group, then listed each type:

S3 and EC2 could be read back, but SQS and CloudWatch Logs returned 0. They are visible via ListQueues and DescribeLogGroups, so the resources themselves exist. These were types not yet covered by the Cloud Control API side. Looking at the implementation, the supported types are S3 buckets, VPCs, subnets, security groups, IAM roles, and IAM users — 6 types in total — and all others return an empty list.

In the actual AWS environment, both of these are covered by the Cloud Control API. The user guide uses AWS::Logs::LogGroup as "an example schema supporting all five operations from creation to listing." AWS::SQS::Queue is also listed in the supported resources. So these are things that should be enumerable but come back empty locally.

$ aws cloudcontrol list-resources --type-name AWS::SQS::Queue
{
    "ResourceDescriptions": [],
    "TypeName": "AWS::SQS::Queue"
}

Unsupported types don't return an error; they return an empty list. The same result occurs for nonexistent type names like AWS::NoSuch::Type. From the response alone, you can't tell whether "there are no resources" or "the type is not supported." From the perspective of a tool that collects resources across types, unsupported types are all treated as "nothing found," making it hard to notice that most results are actually empty after going through everything.

I filed an issue for this as well (#2043). Whether to return an error, explicitly document supported types, or expand support is a matter of policy, so I framed it as a discussion with options listed.

Other Improvements

I haven't verified these locally, but here are notable changes I could pick up from the release notes.

Step Functions was one of the services with the most changes this month. State machine version APIs, ResultSelector, Pass parameters, and ecs:runTask integration were added in 1.5.30. Following that, Map's ItemReader that reads JSON from S3 (1.5.31) and JSONata workflow variable Assign (1.5.33) were added. In 1.5.34, HTTP invocation steps and States.JsonMerge were added.

ECS continues to receive fixes to support patterns closer to real-world use. In 1.5.32, support was added for resolving task definition secrets from SSM and Secrets Manager. Additionally, POSIX ownership application for EFS access points and dynamic host port assignment for awsvpc tasks were also added.

Fixes to error response behavior were also numerous. EMR now returns AWS client error codes instead of 500 (1.5.31). In 1.5.33, RDS's DescribeDBSubnetGroups now returns DBSubnetGroupNotFoundFault for nonexistent groups, and EC2's ImportKeyPair now rejects duplicate names. An S3 bug where DeleteBucketReplication would delete the entire bucket was also fixed (1.5.33).

Persistence coverage was expanded: Elastic Beanstalk, Lambda version counters, API Gateway key tags, and resource tag mappings now survive restarts.

Artifact verification also changed in 1.5.34. Published container images now include provenance and SBOM attestations (#2032). According to the release notes, you can now cryptographically verify that a pulled image matches the one built from source, and you can also extract the list of software it contains.

Documentation generation also changed. Starting from 1.5.31, the Supported Actions table is now auto-generated from handler source code (#1641). This is a change that structurally reduces drift between documentation and implementation. However, it doesn't cover all services. The generation configuration file has an exclusion list, which includes CloudWatch Logs and Cloud Control API. The reason the Logs Insights entries were missing this time is that this table was still being managed manually.

Summary

Over this past month, Floci saw fewer newly added services, with changes focused on filling in the details of existing services. Locally, I verified CloudFormation shorthand notation, S3 authorization, CloudTrail, Logs Insights, AppSync, and Cloud Control API.

• The !Cidr and !GetAZs shorthand notation issues mentioned last time were resolved in 1.5.30. The submitted PR was merged
• Authorization settings are now available, allowing local reproduction of IAM policy denial and rejection of unregistered access keys. However, the two environment variables have different roles
• Supported services went to 69. However, the difference from 65 includes some recounting, and the practical new services are just Amazon MQ and Lightsail
• Compatibility test count went from 1,969 to 2,506. Most of the increase came from the Java SDK side, and the Rust suite was removed
• CloudTrail became an in-process implementation and now records S3 data events. Both successful and failed operations are recorded, with failed ones carrying an errorCode

On the other hand, there were gaps between the release note headings and what was actually usable. AppSync is described as "completed in Phase 5," but the repository documentation states that the execution engine is not implemented, and GraphQL queries could not be executed locally either. A PR addressing this is in progress. Logs Insights also accepts queries but filter and stats are not reflected in the results.

I went ahead and filed the points of concern rather than leaving them:

• #2042: Logs Insights silently changing results for unsupported syntax. like causes the stage to be dropped returning all records, and >= is misparsed returning 0 records
• #2043: Cloud Control API returning an empty list for unsupported types
• #2044: PR to add Logs Insights support scope and 10 missing actions to docs/services/cloudwatch.md. This was merged

When checking these things, docs/services/<service>.md is closer to the actual state than the support table at the top of the README. In particular, the "Not Implemented" section of each page is worth reading. However, as seen this time, there are cases where the documentation itself hasn't caught up with the implementation. When there's a feature you want to use, the safest approach is to run a small test first and confirm.

The number of releases and commits both decreased compared to last time, and there was a 2-week gap between 1.5.33 and 1.5.34. The development pace has settled down from the momentum right after the initial release. Even so, there are large PRs like AppSync's that remain open and in progress. We'll continue to keep an eye on things.

The figures and release content in this article are based on the following primary sources:

• floci-io/floci (GitHub repository)
• Releases (release notes for 1.5.29–1.5.34)
• Floci official documentation
• Verification was performed using floci/floci:1.5.34