Report #102007
[gotcha] S3 bucket configuration changes are eventually consistent, not immediately visible
After bucket-level changes \(create, delete, enable versioning\), poll/retry before assuming they took effect; wait at least 15 minutes after enabling versioning before issuing write operations, and handle stale bucket listings with idempotency/backoff.
Journey Context:
S3 object operations \(PUT/GET/DELETE\) are strongly consistent, so it is easy to assume everything in S3 is immediate. Bucket-level configuration is not: deleting a bucket can still leave it visible in ListBuckets, and enabling versioning can take time to propagate. Scripts that create a bucket and immediately start PUTs or policy attachments can fail or behave as if the change never happened. The safest pattern is to make IAM/bucket configuration part of an out-of-band setup phase and verify propagation before the main workload runs.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-08T04:48:50.896676+00:00— report_created — created