🚨 AWS Error Guide: 'A conflicting conditional operation is currently in progress' — S3 Bucket Reuse

Overview

Amazon S3 serializes conflicting mutations against a single bucket name. When you delete a bucket and immediately try to recreate it — or issue two conflicting bucket-level operations close together — S3 returns OperationAborted with the message “A conflicting conditional operation is currently in progress against this resource.” The bucket namespace change from the previous operation has not finished propagating, so the new operation is refused rather than racing.

You will see it from the CLI or SDK:

An error occurred (OperationAborted) when calling the CreateBucket operation: A conflicting conditional operation is currently in progress against this resource. Please try again.

The same shape appears from Terraform or CloudFormation when a bucket is replaced:

Error: creating S3 Bucket (app-artifacts): OperationAborted: A conflicting conditional operation is currently in progress against this resource. Please try again.

It occurs almost entirely during bucket delete-then-recreate cycles, region changes for a reused name, or concurrent bucket-config operations — not during normal object I/O.

Symptoms

• CreateBucket fails with OperationAborted shortly after a DeleteBucket of the same name.
• Terraform/CloudFormation replace of a bucket errors, then succeeds on a later retry with no code change.
• Recreating a bucket name in a different region fails until several minutes have passed.
• Two pipeline runs touching the same bucket name collide intermittently.

aws s3api delete-bucket --bucket app-artifacts
aws s3api create-bucket --bucket app-artifacts --region us-east-1

An error occurred (OperationAborted) when calling the CreateBucket operation: A conflicting conditional operation is currently in progress against this resource. Please try again.

Common Root Causes

1. Delete-then-recreate too fast

The most common cause: a bucket is deleted and recreated within seconds, before the namespace release propagates.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=app-artifacts \
  --query 'Events[?EventName==`DeleteBucket`||EventName==`CreateBucket`].[EventTime,EventName]' --output text

2026-07-08T12:00:04Z	CreateBucket
2026-07-08T12:00:01Z	DeleteBucket

Three seconds between delete and create — far too short for the change to settle.

2. Recreating the same name in a different region

Reusing a just-deleted name in a new region forces a namespace relocation that takes longer to propagate.

aws s3api get-bucket-location --bucket app-artifacts 2>/dev/null

An error occurred (NoSuchBucket) ...

The bucket is gone, but the global name reservation for the old region is still clearing.

3. IaC replacing a bucket in a single apply

Terraform/CloudFormation deletes and recreates a bucket in one operation when a force-new attribute (like the name or region) changes, hitting the same too-fast window.

terraform plan | grep -A2 'aws_s3_bucket.artifacts'

  # aws_s3_bucket.artifacts must be replaced
-/+ resource "aws_s3_bucket" "artifacts" {

The -/+ replace runs delete and create back to back.

4. Concurrent bucket-level operations

Two processes issue conflicting bucket configuration or lifecycle operations against the same bucket simultaneously.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=app-artifacts \
  --query 'Events[].[EventTime,EventName,Username]' --output text | head

2026-07-08T12:00:02Z	PutBucketPolicy	ci-a
2026-07-08T12:00:02Z	PutBucketPolicy	ci-b

Two principals mutating the same bucket at the same second collide.

5. Retrying without backoff

A create loop that retries instantly keeps hitting the in-progress conditional operation instead of waiting it out.

grep -n "create-bucket" provision.sh

9:until aws s3api create-bucket --bucket app-artifacts; do :; done

A tight until loop with no sleep re-triggers the conflict on every pass.

Diagnostic Workflow

Step 1: Confirm the bucket’s current existence

aws s3api head-bucket --bucket app-artifacts 2>&1

NoSuchBucket (404) means the delete completed and you are waiting on propagation; 403 means it exists and may be owned elsewhere.

Step 2: Check the timing of recent bucket operations

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=app-artifacts \
  --query 'Events[].[EventTime,EventName]' --output text | head

If a DeleteBucket and CreateBucket are seconds apart, the gap is the problem.

Step 3: Verify the name is not owned by another account

aws s3api head-bucket --bucket app-artifacts 2>&1 | grep -q 403 && echo "exists / possibly owned elsewhere"

A persistent 403 (not a transient OperationAborted) means the global name is taken by someone else and no wait will help.

Step 4: Retry with backoff and a waiter

for i in 1 2 3 4 5; do
  aws s3api create-bucket --bucket app-artifacts --region us-east-1 && break
  echo "attempt $i failed, backing off"; sleep $((i*10))
done
aws s3api wait bucket-exists --bucket app-artifacts && echo "ready"

Exponential backoff lets the prior operation finish; the waiter confirms the bucket is usable.

Example Root Cause Analysis

A blue/green artifact pipeline recreated its bucket on every deploy to guarantee a clean state. It failed intermittently with OperationAborted on CreateBucket.

CloudTrail showed delete and create only seconds apart:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=deploy-artifacts \
  --query 'Events[].[EventTime,EventName]' --output text | head -2

2026-07-08T12:00:05Z	CreateBucket
2026-07-08T12:00:01Z	DeleteBucket

The 4-second gap was inside S3’s propagation window, so roughly one deploy in five failed. Two changes fixed it. First, stop deleting the bucket at all — empty it instead of destroying and recreating the name:

aws s3 rm s3://deploy-artifacts --recursive

And where a true recreate was unavoidable, wrap the create in backoff plus a waiter. Reusing the bucket eliminated the conflict entirely, since the namespace never churned.

Prevention Best Practices

• Do not delete and recreate a bucket to “reset” it — empty it with aws s3 rm --recursive (or a lifecycle rule) and keep the same bucket.
• When a recreate is truly required, wait between delete and create and use aws s3api wait bucket-exists/bucket-not-exists instead of an instant retry.
• Retry OperationAborted with exponential backoff; it is explicitly a “please try again” transient condition.
• Avoid changing force-new bucket attributes (name, region) in IaC unless necessary, since that triggers a delete/create replace.
• Serialize bucket-level configuration operations so two pipelines never mutate the same bucket concurrently.

Quick Command Reference

# Does the bucket currently exist?
aws s3api head-bucket --bucket <name> 2>&1

# Timeline of recent bucket operations
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=<name> \
  --query 'Events[].[EventTime,EventName,Username]' --output text | head

# Empty a bucket instead of deleting/recreating it
aws s3 rm s3://<name> --recursive

# Create with backoff and a waiter
for i in 1 2 3 4 5; do aws s3api create-bucket --bucket <name> --region <r> && break; sleep $((i*10)); done
aws s3api wait bucket-exists --bucket <name>

Conclusion

OperationAborted: A conflicting conditional operation is currently in progress means a previous bucket-namespace change has not finished propagating. The usual root causes:

1. Deleting and recreating a bucket within seconds.
2. Reusing a just-deleted name in a different region.
3. IaC replacing a bucket (delete + create) in one apply.
4. Concurrent bucket-level operations against the same name.
5. Retrying instantly with no backoff.

The best fix is to stop churning the namespace — empty and reuse the bucket instead of destroying it. When a recreate is unavoidable, retry with exponential backoff and a wait bucket-exists step so the prior operation can settle.