Skip to main content
RunBook Academy

CephXLIV · Object Storage FoundationsObject Storage Foundations

The S3 API surface RGW implements

Intermediate⏱ ~17 minawss3cmdradosgw-admin

What you'll learn

  • Identify the S3 operations RGW supports
  • Recognise the notable gaps and differences
  • Verify compatibility for a specific application
  • Configure RGW for S3 and Swift access

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Not yet marked complete on this device.

Why this matters in production

RGW implements most of S3, and “most” is where the surprises live. An application relying on an unimplemented feature fails in production rather than at deployment, so checking before committing is worth the hour.

What is supported

AreaSupport
Object operations (PUT, GET, DELETE, HEAD, COPY)full
Multipart uploadfull
Bucket operationsfull
Versioningfull
Lifecycleexpiration and transition
Bucket policiesS3 policy language
ACLsfull
Server-side encryptionSSE-S3, SSE-KMS, SSE-C
Presigned URLsfull
CORSfull
Object Lock and retentionsupported
Notificationsto Kafka, AMQP, HTTP endpoints
Website hostingbasic
Select (SQL over objects)limited
Storage classessupported through placement targets

Verifying compatibility

The reliable check is the application, not the documentation:

# configure a profile against the gateway
aws configure --profile rgw
aws --endpoint-url https://rgw.example.com --profile rgw s3 ls

# exercise the operations the application uses
aws --endpoint-url https://rgw.example.com s3api put-bucket-versioning \
    --bucket test --versioning-configuration Status=Enabled
aws --endpoint-url https://rgw.example.com s3api put-bucket-lifecycle-configuration \
    --bucket test --lifecycle-configuration file://lifecycle.json

Run the application’s own test suite against RGW during evaluation. It exercises exactly the operations the application uses, which no compatibility matrix can tell you.

Common differences

DifferenceImpact
No AWS-specific IAM integrationpolicies reference RGW users, not AWS principals
Region behaviourRGW zonegroups are not AWS regions; some SDKs assume region semantics
Some newer S3 features lagcheck the Ceph release notes for the version you run
Bucket namingRGW is more permissive than AWS in some respects
Eventual consistency assumptionsRGW is strongly consistent; applications coded around AWS’s older eventual consistency do unnecessary work

That last row is worth noting: applications carrying retry loops for eventual consistency are working around a property RGW does not have.

Swift

radosgw-admin subuser create --uid=alice --subuser=alice:swift --access=full
radosgw-admin key create --subuser=alice:swift --key-type=swift --gen-secret

RGW serves Swift and S3 against the same underlying data, which is useful for migrations — the same objects are reachable through either API.

Quiz

Knowledge check · 4 questions

  1. Q1. An application carries retry loops to handle eventual consistency after PUT. What happens on RGW?

  2. Q2. RGW multisite replication between zones is asynchronous and therefore does have replication lag.

  3. Q3. Evaluate RGW for an application currently on AWS S3.

    A team plans to migrate an application from AWS S3 to an on-premises RGW deployment. They have checked a compatibility matrix, confirmed the operations they use are listed as supported, and consider the evaluation complete.

  4. Q4. Why is RGW strongly consistent within a zone without any additional mechanism?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Run the application’s own integration suite against RGW during evaluation rather than checking a compatibility matrix; the matrix answers a different question than the one that matters. Remove eventual-consistency workarounds once RGW is in use — they cost real requests for a property that is not there.

Cross-course references

  • Kubernetes: testing against the actual API server version beats consulting a feature matrix
  • Linux: POSIX compliance claims similarly need verification against the actual workload