Amazon S3 Control

Store and read account public access block settings through REST.

Plan: Free94 of 97 operations implemented1Known difference

The tested CLI adds an account prefix to the local hostname; use the REST example. Policy enforcement was not established.

Example checked on Vera 1.2.2, 8 November 2026. Each coverage note names its own evidence and date.

Connect

Start Vera as in Get started, then run this in a terminal of its own, from an empty scratch directory. The example sends plain HTTP requests with curl, so it doesn’t need the AWS CLI:

export VERA_ENDPOINT="http://localhost:5003"
ACCOUNT_ID=123456789012

The emulator serves the 2018-08-20 API over the REST XML protocol. Each request names the account in the x-amz-account-id header, so no special host name is needed. The requests need no AWS credentials. S3 Control is on the Free plan, which runs without a license key: see Licenses and plans.

The AWS CLI doesn’t work here: for these operations, it puts the account ID in front of the endpoint’s host name. The official AWS CLI 2.31.35 requested http://123456789012.127.0.0.1:5003/v20180820/configuration/publicAccessBlock, which doesn’t reach the emulator, even with AWS_DISABLE_HOST_PREFIX_INJECTION=true. boto3 1.40.72 with inject_host_prefix=False kept the prefix too. Use the REST requests below rather than editing your hosts file.

Example

Write the four public access block settings to a file and put them for the account:

cat > public-access-block.xml <<'XML'
<PublicAccessBlockConfiguration>
  <BlockPublicAcls>true</BlockPublicAcls>
  <IgnorePublicAcls>true</IgnorePublicAcls>
  <BlockPublicPolicy>true</BlockPublicPolicy>
  <RestrictPublicBuckets>true</RestrictPublicBuckets>
</PublicAccessBlockConfiguration>
XML
curl --fail --silent --show-error -X PUT \
  "$VERA_ENDPOINT/v20180820/configuration/publicAccessBlock" \
  -H "x-amz-account-id: $ACCOUNT_ID" -H 'Content-Type: application/xml' \
  --data-binary @public-access-block.xml

The put returns an XML response envelope. Read the settings back:

curl --fail --silent --show-error \
  "$VERA_ENDPOINT/v20180820/configuration/publicAccessBlock" \
  -H "x-amz-account-id: $ACCOUNT_ID"

The response returns all four settings. It starts with an XML declaration and may come on one line; these are its fields:

<PublicAccessBlockConfiguration>
  <BlockPublicAcls>true</BlockPublicAcls>
  <IgnorePublicAcls>true</IgnorePublicAcls>
  <BlockPublicPolicy>true</BlockPublicPolicy>
  <RestrictPublicBuckets>true</RestrictPublicBuckets>
</PublicAccessBlockConfiguration>

To clean up, delete the settings, which also returns an XML response envelope, then the input file:

curl --fail --silent --show-error -X DELETE \
  "$VERA_ENDPOINT/v20180820/configuration/publicAccessBlock" \
  -H "x-amz-account-id: $ACCOUNT_ID"
rm public-access-block.xml

After the delete, the same GET answers HTTP 404 with NoSuchPublicAccessBlockConfiguration.

Supported features

Public access blocks: an account’s four flags stored, read back as set and deleted.
Settings per account: the settings belong to the account ID in the request. In earlier testing, reading them with another account’s ID returned 404 NoSuchPublicAccessBlockConfiguration.
Also served, not yet tested: access points and their policies, Multi-Region Access Points, Object Lambda access points, access grants, Batch Operations job management, Storage Lens configurations and groups, S3 on Outposts buckets, and tags. They weren’t part of the checks on Vera 1.2.0 preview or Vera 1.2.0-rc.3.

Limitations

The main limits are below. A few more apply to every service, and the API coverage notes cover smaller differences.

The AWS CLI doesn’t reach the emulator. The tested CLI and boto3 add the account ID to the endpoint’s host name, and AWS_DISABLE_HOST_PREFIX_INJECTION=true doesn’t stop it. This is a connection problem, not a missing operation: the REST requests above reach the same operations.
Settings weren’t tested against S3. A public access block is stored and returned, but whether it changes S3 requests wasn’t established. Routing through access points, Multi-Region Access Points and Object Lambda, and Storage Lens metrics, weren’t tested either.
Account authorization wasn’t tested. Beyond the earlier read with another account’s ID, writes, other callers and policy enforcement weren’t tried.
Batch Operations manifests are only partly checked. In earlier testing, CreateJob accepted a manifest object that doesn’t exist, and an object ARN and version ID that belong to different objects, though it rejected a version ID that doesn’t exist. Jobs weren’t run.

API coverage

Every operation in AWS's published 2018-08-20 API (SDK model, botocore 1.43.105), and whether the emulator implements it. Availability combines the earlier implementation inventory with the dated observations below; checking a page's example does not verify every operation. Each note names its evidence first; an observation given without a build or date comes from earlier testing, on 3 November 2026. What the statuses mean

Operation	Status	Notes
AssociateAccessGrantsIdentityCenter	Implemented
CreateAccessGrant	Implemented
CreateAccessGrantsInstance	Implemented
CreateAccessGrantsLocation	Implemented
CreateAccessPoint	Implemented
CreateAccessPointForObjectLambda	Not implemented
CreateBucket	Implemented
CreateJob	Known difference	Local observation: Accepts a manifest object that doesn't exist, and an object ARN and version ID that belong to different objects, though it rejects a version ID that doesn't exist. Jobs weren't run.
CreateMultiRegionAccessPoint	Implemented
CreateStorageLensGroup	Implemented
DeleteAccessGrant	Implemented
DeleteAccessGrantsInstance	Implemented
DeleteAccessGrantsInstanceResourcePolicy	Implemented
DeleteAccessGrantsLocation	Implemented
DeleteAccessPoint	Implemented
DeleteAccessPointForObjectLambda	Not implemented
DeleteAccessPointPolicy	Implemented
DeleteAccessPointPolicyForObjectLambda	Implemented
DeleteAccessPointScope	Implemented
DeleteBucket	Implemented
DeleteBucketLifecycleConfiguration	Implemented
DeleteBucketPolicy	Implemented
DeleteBucketReplication	Implemented
DeleteBucketTagging	Implemented
DeleteJobTagging	Implemented
DeleteMultiRegionAccessPoint	Implemented
DeletePublicAccessBlock	Implemented	Local observation: Vera 1.2.0 preview, 5 November 2026 — deleted the account's settings over unsigned REST with the `x-amz-account-id` header.
DeleteStorageLensConfiguration	Implemented
DeleteStorageLensConfigurationTagging	Implemented
DeleteStorageLensGroup	Implemented
DescribeJob	Implemented
DescribeMultiRegionAccessPointOperation	Implemented
DissociateAccessGrantsIdentityCenter	Implemented
GetAccessGrant	Implemented
GetAccessGrantsInstance	Implemented
GetAccessGrantsInstanceForPrefix	Implemented
GetAccessGrantsInstanceResourcePolicy	Implemented
GetAccessGrantsLocation	Implemented
GetAccessPoint	Implemented
GetAccessPointConfigurationForObjectLambda	Implemented
GetAccessPointForObjectLambda	Not implemented
GetAccessPointPolicy	Implemented
GetAccessPointPolicyForObjectLambda	Implemented
GetAccessPointPolicyStatus	Implemented
GetAccessPointPolicyStatusForObjectLambda	Implemented
GetAccessPointScope	Implemented
GetBucket	Implemented
GetBucketLifecycleConfiguration	Implemented
GetBucketPolicy	Implemented
GetBucketReplication	Implemented
GetBucketTagging	Implemented
GetBucketVersioning	Implemented
GetDataAccess	Implemented
GetJobTagging	Implemented
GetMultiRegionAccessPoint	Implemented
GetMultiRegionAccessPointPolicy	Implemented
GetMultiRegionAccessPointPolicyStatus	Implemented
GetMultiRegionAccessPointRoutes	Implemented
GetPublicAccessBlock	Implemented	Local observation: Vera 1.2.0 preview, 5 November 2026 — over unsigned REST with the `x-amz-account-id` header, returned the four flags after a put, and HTTP `404` `NoSuchPublicAccessBlockConfiguration` after a delete. Earlier testing, 3 November 2026: for another account's ID, returned `404 NoSuchPublicAccessBlockConfiguration`. Authorization wasn't tested.
GetStorageLensConfiguration	Implemented
GetStorageLensConfigurationTagging	Implemented
GetStorageLensGroup	Implemented
ListAccessGrants	Implemented
ListAccessGrantsInstances	Implemented
ListAccessGrantsLocations	Implemented
ListAccessPoints	Implemented
ListAccessPointsForDirectoryBuckets	Implemented
ListAccessPointsForObjectLambda	Implemented
ListCallerAccessGrants	Implemented
ListJobs	Implemented
ListMultiRegionAccessPoints	Implemented
ListRegionalBuckets	Implemented
ListStorageLensConfigurations	Implemented
ListStorageLensGroups	Implemented
ListTagsForResource	Implemented
PutAccessGrantsInstanceResourcePolicy	Implemented
PutAccessPointConfigurationForObjectLambda	Implemented
PutAccessPointPolicy	Implemented
PutAccessPointPolicyForObjectLambda	Implemented
PutAccessPointScope	Implemented
PutBucketLifecycleConfiguration	Implemented
PutBucketPolicy	Implemented
PutBucketReplication	Implemented
PutBucketTagging	Implemented
PutBucketVersioning	Implemented
PutJobTagging	Implemented
PutMultiRegionAccessPointPolicy	Implemented
PutPublicAccessBlock	Implemented	Local observation: Vera 1.2.0 preview, 5 November 2026 — stored the four flags from an XML body, sent over unsigned REST with the `x-amz-account-id` header. The tested AWS CLI adds the account ID to the endpoint's host name and doesn't reach the emulator: a connection problem, not a missing operation.
PutStorageLensConfiguration	Implemented
PutStorageLensConfigurationTagging	Implemented
SubmitMultiRegionAccessPointRoutes	Implemented
TagResource	Implemented
UntagResource	Implemented
UpdateAccessGrantsLocation	Implemented
UpdateJobPriority	Implemented
UpdateJobStatus	Implemented
UpdateStorageLensGroup	Implemented