Skip to content

Incompatibilities With AWS S3

Ben McClelland edited this page Apr 4, 2026 · 5 revisions

This section documents key incompatibilities between versitygw and AWS S3. Most of these differences relate to legacy AWS S3 behaviors that versitygw does not currently implement and may not implement unless there is a strong use case or community demand.

1. BucketAlreadyOwnedByYou behavior in us-east-1

AWS S3 behavior (legacy): In most regions, attempting to create a bucket that already exists and is owned by you returns the BucketAlreadyOwnedByYou error. In us-east-1, AWS S3 historically behaves differently: recreating an existing bucket you already own can return 200 OK and may reset the bucket ACLs (legacy compatibility behavior).

Versitygw behavior: versitygw does not implement the special-case legacy behavior for us-east-1. Attempting to create a bucket that already exists and is owned by the same account returns BucketAlreadyOwnedByYou (error) in us-east-1 as well.

Reference: AWS docs

2. Bucket ACLs

Bucket ACLs are supported, but their behavior differs from AWS S3 in some cases. The details are documented here:

Recommendation: Prefer bucket policies for all bucket- and object-level access control requirements, and treat ACL support as compatibility-oriented rather than a primary access control model.

3. Object ACLs

AWS S3 behavior: AWS S3 supports object ACLs, allowing permissions to be applied per-object (in addition to bucket policies, IAM, etc.).

Versitygw behavior: versitygw currently does not support object ACLs. Any ACL-like behavior is effectively managed at the bucket level, and bucket-level permissions apply across objects within that bucket.

Impact / notes:

  • Object ACL headers are ignored for incoming requests.
  • Use bucket policies / bucket ACLs(less recommended) instead of object ACLs.

Clone this wiki locally