AWS Error: NoSuchBucket — S3 Bucket Does Not Exist

An error occurred (NoSuchBucket) when calling the GetObject operation:
The specified bucket does not exist
<Error>
  <Code>NoSuchBucket</Code>
  <Message>The specified bucket does not exist</Message>
  <BucketName>my-prod-bucket-eu</BucketName>
  <RequestId>EXAMPLE123</RequestId>
</Error>

NoSuchBucket is S3 saying “I cannot find a bucket by this exact name in the region you queried.” It’s almost always one of three things: a typo, a region mismatch, or a bucket that was deleted (often by a Terraform run or a manual cleanup). The XML response includes the bucket name S3 saw, which is the single most useful clue for debugging — copy it and grep your config.

A debugging tip: S3’s “global namespace, regional data” model trips up almost every team eventually. Bucket names are unique worldwide, but the data and the API endpoint are regional. A bucket named acme-prod-uploads in eu-west-2 cannot be reached by a US-East-1 client without an explicit redirect — and the failure mode is NoSuchBucket, not a clear region error. Pin region explicitly in every long-lived S3 client.

Why this happens

• Typo or stale bucket name in config. Most NoSuchBucket errors are mundane — env var typo, hardcoded name from a deleted resource, Terraform state pointing at a destroyed bucket. Always print the bucket name your code is actually using before assuming a deeper issue.
• Wrong region client for the bucket. S3 bucket names are globally unique but data is regional. A client built with `region_name='us-east-1'` calling a bucket in `eu-west-2` may get NoSuchBucket (newer SDKs auto-redirect; older or misconfigured ones do not). Always pin the region explicitly.
• Bucket was recently deleted. After deletion, the bucket name is reserved for a grace period (up to a few hours) and then released. Calls during the grace period return NoSuchBucket; calls after release may return AccessDenied if someone else recreated the name.
• Path-style vs virtual-hosted-style addressing mismatch. Buckets with dots in the name (`my.bucket.com`) break virtual-hosted-style HTTPS due to wildcard cert mismatch. Some SDKs fall back to path-style; others fail with NoSuchBucket. Use `s3v4` and force path-style addressing for dotted names.
• Cross-account access without the right ARN. Calling a bucket in another account without specifying its full ARN can resolve to your own account's namespace. If your account has no bucket by that name, you get NoSuchBucket — even though the bucket exists in the partner account.

How to fix it

Fixes are ordered by likelihood. Start with the first one that matches your context.

# Does it exist at all?
aws s3api head-bucket --bucket my-prod-bucket-eu

# What region is it in?
aws s3api get-bucket-location --bucket my-prod-bucket-eu
# { "LocationConstraint": "eu-west-2" }

# List your account's buckets to confirm spelling
aws s3 ls

import boto3

# Wrong: client default region may not match the bucket
# s3 = boto3.client('s3')

# Right: pin to the bucket's region
s3 = boto3.client('s3', region_name='eu-west-2')

obj = s3.get_object(Bucket='my-prod-bucket-eu', Key='config.json')

import boto3
from botocore.client import Config

s3 = boto3.client(
    's3',
    region_name='us-east-1',
    config=Config(s3={'addressing_style': 'path'}, signature_version='s3v4'),
)

Detection and monitoring in production

Track NoSuchBucket separately from other 4xx S3 errors. A spike on a single bucket usually means a deletion event in another account. A spike across many buckets in one region usually means a misconfigured deploy pinned the wrong region. CloudTrail `s3:DeleteBucket` events let you correlate quickly.