S3 NoSuchBucket But the Bucket Exists: Every Fix

"NoSuchBucket" on an S3 operation almost always means one thing: your request went to the wrong region. But here is the part almost nobody tells you: a bucket can exist globally and not exist regionally at the same time. S3 bucket names are globally unique across all AWS accounts, but the S3 service itself runs in separate regional installations — so the same bucket is simultaneously "real" in us-west-2 where it lives, and "nonexistent" in us-east-1 where your CLI is pointed. Two commands settle it: aws s3api head-bucket --bucket my-bucket tells you where the bucket really lives, and --region on your next command points you there.

That global-name-versus-regional-bucket split is the single fact that explains every NoSuchBucket error you will ever see, and it is the fact most S3 tutorials never state plainly. Your bucket name is unique across the planet — nobody else can create my-company-backups if you already own it — but that name only resolves to an actual bucket in one region. Ask for it from a different region, and S3 in that region genuinely does not have it. The error message is honest from the perspective of the regional endpoint that received your request. It just is not telling the whole story.

The second thing worth internalizing: NoSuchBucket has a sibling error called PermanentRedirect, and which one you get depends on how your client handles the region mismatch. Some SDKs and CLI configurations catch the redirect and tell you to use the right endpoint. Others do not, and surface the failure as NoSuchBucket instead. This is why two people can hit the same wrong-region bucket and report different errors — they are experiencing the same problem through different error-handling code.

What NoSuchBucket Actually Means (Global Name, Regional Bucket)

An S3 NoSuchBucket error is an HTTP 404 from the regional S3 endpoint that received your request. That endpoint looked up your bucket name in its regional bucket registry, found nothing, and reported the absence. The error is technically accurate from where it stands — the bucket genuinely does not exist in that region. It exists somewhere else.

Here is the architecture that produces this confusion. S3 runs as a regional service — separate installations in each AWS region (us-east-1, eu-west-1, ap-southeast-2, and so on), each with its own bucket registry. When you create a bucket, you create it in one region, and it lives in that region's registry. The name is globally unique — the creation process checks all regions to prevent duplicates — but the bucket is regional. This is why the same bucket name resolves fine from one region and returns NoSuchBucket from another.

Before you debug anything, read the full error. NoSuchBucket comes in contexts that narrow the search:

• "An error occurred (NoSuchBucket) when calling the ListObjects operation" — your CLI/SDK is pointed at the wrong region, or the name is wrong.
• "An error occurred (PermanentRedirect) ... The bucket you are attempting to access must be addressed using the specified endpoint" — the sibling error. Same root cause (wrong region), different error-handling path. Your client caught the redirect and is telling you the right endpoint.
• NosuchBucket from CloudFormation or Terraform — your template references a bucket that was deleted, never created, or is being created in a different stack/region than the one deploying.
• NosuchBucket from an SDK in production code that "was working yesterday" — something changed: the region configuration, the bucket, or where the code is running.

The 30-Second Diagnostic (Three Commands, Done)

Three commands, thirty seconds, and the region question is settled for good. This is the diagnostic that makes the rest of this guide a formality.

1. Find where your CLI thinks it is.

   aws configure get region

   Or check the AWS_DEFAULT_REGION environment variable. This is the region your commands are defaulting to. If it does not match where the bucket lives, you have found your cause — but confirm with the next step before editing anything.

2. Find where the bucket actually lives.

   aws s3api head-bucket --bucket my-bucket

   This is the compass. You can make a HeadBucket call on any bucket name to any region in the partition, and the response carries the correct bucket location, so you can then make a proper request to the appropriate regional endpoint. This is exactly why HeadBucket is the recommended way to discover a bucket's region — ahead of the older get-bucket-location, which has known reliability issues cross-region.

   Run it with --debug if the response is unclear: the x-amz-bucket-region header in the response carries the answer.

3. Confirm with a properly-scoped call.

   aws s3api get-bucket-location --bucket my-bucket --region us-east-1

   If the bucket is in us-east-1, this returns LocationConstraint: null — that region's documented legacy quirk, where it reports as null rather than as "us-east-1." Any other region returns the region code. Now you know exactly where the bucket lives, and can point your commands there or relocate your workloads to match.

If those three commands do not resolve it, the bucket name is the problem — typo, wrong account, ARN confusion — and the causes below walk through each in order of likelihood.

Cause 1: Region Mismatch — Your Client Is Asking the Wrong Regional S3

This is the cause behind most NoSuchBucket-when-the-bucket-exists reports, and it has a dozen faces. The core mechanism is always the same: the CLI, SDK, or configuration is set to one region, the bucket lives in another, and S3 in the client's region honestly reports that it has no such bucket.

The common variants

• The default region was never set. A fresh CLI install with no aws configure has no default region, and some commands fail confusingly while others limp along with unexpected defaults. Check with aws configure get region — if it returns nothing, that is your problem.
• The environment variable disagrees with the config file. AWS_DEFAULT_REGION in the shell overrides the config file's region. A stray export from a previous session silently redirects every subsequent command to the wrong region.
• The named profile points elsewhere. AWS_PROFILE=production with a production region configured, when the bucket you want is in the dev profile's region. The terminal "works" but for a different region than the one you are thinking about.
• The SDK client was constructed with a hardcoded region. Application code creates an S3 client with region: 'us-east-1' and never revisits it. The bucket was created in us-west-2 by someone else, and the code has been quietly pointing at the wrong regional S3 since deployment.
• Terraform or CloudFormation provider block. The provider's region determines where S3 resources are looked up. A template that creates a bucket in eu-west-1 but reads from a provider configured for us-east-1 will produce exactly this error on the read side while the write side succeeds.

The fix, in every variant

Point the client at the bucket's region. In the CLI:

aws s3 ls s3://my-bucket --region us-west-2

Or set it permanently for the profile:

aws configure set region us-west-2

Or set the environment variable for the session:

export AWS_DEFAULT_REGION=us-west-2

In an SDK, construct the client with the right region:

const s3 = new S3Client({ region: "us-west-2" });

The fix is always the same shape. The challenge is finding every place a region can hide — config file, environment variable, named profile, SDK constructor, Terraform provider — and making them all agree with the bucket's actual home.

Cause 2: The EC2 Instance Defaults to Its Own Region, Not Yours

A special case of Cause 1 that deserves its own section because it produces a maddening signature: the same command works on your laptop and fails on the EC2 instance, with identical credentials, identical bucket name, identical everything — except the region.

The mechanism: when you run the AWS CLI or an SDK on an EC2 instance with an attached instance profile, the SDK resolves its region from the instance metadata service, which reports the region the instance is running in. Your laptop resolves its region from your local config file. If the instance is in us-east-1 and the bucket (and your laptop's config) are in us-west-2, the code that works locally fails on the instance with NoSuchBucket — because the instance is asking us-east-1's S3 for a bucket that lives in us-west-2.

This is one of the most commonly reported variants on Stack Overflow and AWS forums: "aws s3 ls works locally but NoSuchBucket on EC2." The debugging mistake is checking credentials, permissions, and the bucket name — all of which are fine — because the difference is the region, not the identity.

The 10-second test

From inside the EC2 instance:

curl -s http://169.254.169.254/latest/meta-data/placement/region

This reports the instance's region. If it does not match the bucket's region, that is your answer — and the fix is the same as Cause 1: explicitly set the region in the command, the environment, or the SDK client, overriding the instance's default.

The architectural fix

For applications deployed across regions, the robust pattern is to never hardcode a region for S3 access — instead, discover the bucket's region dynamically at startup using HeadBucket, and construct the S3 client with that region. This makes the code region-agnostic and immune to deployment-region mismatches. It adds one API call at initialization and removes an entire class of production failures.

Cause 3: The Bucket Name Is Wrong (Typo, Case, Suffix)

The boring cause, worth more of your time than the exciting ones. S3 bucket names are case-sensitive, globally unique, and easy to fat-finger:

• Missing or extra suffix. my-bucket-prod versus my-bucket — the production suffix that a copy-paste dropped.
• Case sensitivity. My-Bucket and my-bucket are different buckets (and only one of them is a valid S3 name — capital letters are not allowed in modern S3 bucket names, but older buckets and some tooling still surface the mismatch).
• Hyphens versus underscores. my_bucket versus my-bucket — one character different, completely different bucket.
• Trailing whitespace. A bucket name copied from a spreadsheet or Slack message with a trailing space is invisible to the eye and fatal to the request.
• Environment prefix dropped. dev-my-bucket versus prod-my-bucket — the environment prefix that separates two identically-named logical buckets.

The 10-second test

List every bucket your credentials can see, in the bucket's region, and eyeball the exact spelling:

aws s3 ls --region us-west-2

Then copy the bucket name from that output — not from memory, not from the docs, not from the variable in your code — and paste it into the failing command. If the error disappears, the name was the problem all along.

For a deeper look at bucket naming constraints and the errors that naming problems produce, our S3 BucketAlreadyExists guide covers the globally-unique namespace and what happens when names collide across accounts.

Cause 4: The Bucket Was Actually Deleted

Sometimes the bucket does not exist, and the "but it exists" part of the error report is stale information. Buckets get deleted — by cleanup scripts, by Terraform runs that removed a resource from state, by a colleague "tidying up," by a lifecycle event nobody connected to this failure.

The signature of this cause: the error is new and nothing about your code changed. Yesterday's deployment worked, today's identical deployment fails, and the difference is that the bucket being referenced is gone. CloudTrail will show the DeleteBucket API call with the identity that made it and the timestamp, if management-level event recording covers it.

The 10-second test

aws s3api head-bucket --bucket my-bucket --region us-west-2

A 404 here, in the bucket's correct region, means the bucket is genuinely gone. Check CloudTrail's Event history for DeleteBucket events on that name to see who removed it and when.

The Terraform variant

A special case worth naming: Terraform state says the bucket exists (because the state file has not been refreshed), but the actual bucket was deleted out-of-band. terraform plan reads from state, shows no changes, and the application fails at runtime with NoSuchBucket. The fix is terraform plan -refresh=true (or just terraform apply -refresh-only) to reconcile state with reality, then re-create the bucket if the plan calls for it.

Cause 5: The Bucket Exists — in a Different AWS Account

S3 bucket names are globally unique, which means a bucket name you encounter in documentation, a tutorial, or a colleague's example might belong to someone else's account entirely. The name exists in the global namespace; the bucket exists in their account; and your request to it from your account, without cross-account permissions, can fail in confusing ways — sometimes as NoSuchBucket, depending on how the regional endpoint handles the lookup.

The scenarios that produce this:

• Copy-pasted bucket names from documentation or blog posts that use a real bucket belonging to the author's account.
• Shared bucket names across an organization where the bucket lives in a central logging or data account, and the application account references it by name without the cross-account bucket policy.
• A partner or vendor bucket that you are supposed to access with granted permissions, but the request is arriving without the right credentials or from an account the bucket policy does not allow.

The debugging approach: confirm the bucket exists and you can see it with your credentials in the correct region (aws s3 ls --region <bucket-region>). If the bucket does not appear in your account's bucket list but HeadBucket finds it, it belongs to another account — and the access question shifts from "does it exist" to "am I allowed," which is the AccessDenied territory our companion guide covers in full.

Cause 6: ARN Where a Bucket Name Belongs (and Vice Versa)

A silent killer in CloudFormation templates, Terraform configurations, and application code: using the full ARN (arn:aws:s3:::my-bucket) where the API expects just the bucket name (my-bucket), or the reverse. Some interfaces accept both; some accept only one; and the ones that accept only the name will treat the ARN as a literal (nonexistent) bucket name and return NoSuchBucket for it.

The confusion is understandable because different AWS surfaces want different things:

The CloudFormation trap deserves specific mention: !Ref MyBucket on an AWS::S3::Bucket resource returns the bucket name, not the ARN. If your template uses !Ref where the ARN is needed (in a policy Resource, for instance), or uses !GetAtt MyBucket.Arn where the name is needed, you produce exactly this class of error — and the failure surfaces not in the template validation but at runtime, as NoSuchBucket from the API call that received the wrong string.

Cause 7: Access Point Aliases and Directory Buckets Look Like Buckets But Are Not

Two newer S3 features create bucket-like addresses that are not buckets, and using them in the wrong context produces NoSuchBucket:

S3 Access Points. An access point is a named network endpoint with its own permissions and policies, attached to a bucket. Access points have automatically generated aliases that are interchangeable with bucket names for data access operations — you can use the alias where you would use a bucket name when getting and putting objects. But use an access point name in a context that expects an actual bucket — bucket-policy operations, some CLI commands, older SDK versions — and the lookup fails, because the access point is not a bucket. The alias and the access point ARN are different things, and mixing them up produces this error or its sibling.

Directory buckets (S3 Express One Zone). Directory buckets are a distinct bucket type with a different naming scheme — the name includes an Availability Zone suffix (like my-bucket--usw2-az1--x-s3) and lives in a different namespace than general-purpose buckets. Operations against directory buckets use different endpoints and different addressing. If your tooling expects a general-purpose bucket and encounters a directory bucket name — or vice versa — the namespace mismatch surfaces as NoSuchBucket, because from one namespace's perspective, the other's buckets genuinely do not exist.

For permission issues that arise specifically with access points and modern S3 security features, our guide on the "bucket does not allow ACLs" error covers the Object Ownership and ACL landscape that access points operate within.

Cause 8: Website Endpoints, FIPS Endpoints, and Custom Endpoint Overrides

The rarest cause, but it appears in environments with endpoint configuration that differs from the default:

• Website endpoints versus API endpoints. A bucket configured for static website hosting has a website endpoint (my-bucket.s3-website-us-west-2.amazonaws.com) distinct from its API endpoint (my-bucket.s3.us-west-2.amazonaws.com). Requests to the website endpoint follow website-hosting semantics; SDK and CLI requests to the API endpoint follow S3 API semantics. Using one where the other is expected — particularly with tools that auto-construct endpoint URLs from bucket names — can produce unexpected failures, including NoSuchBucket when the constructed URL does not resolve to the bucket the caller intended.
• FIPS endpoints. US government and regulated environments use FIPS-compliant S3 endpoints (s3-fips.us-gov-west-1.amazonaws.com). A client configured for a FIPS endpoint in one region, pointed at a bucket in another, produces the same region-mismatch failure dressed in a different endpoint URL.
• Custom endpoint overrides. The AWS_ENDPOINT_URL environment variable and the --endpoint-url CLI flag override the default S3 endpoint entirely — useful for S3-compatible storage (MinIO, Wasabi, on-premises) or for routing through proxies, but a source of NoSuchBucket when the override points at an endpoint that does not have the bucket. A stale endpoint override from a previous project is the classic lurking variable: no amount of region-fixing solves it because the endpoint itself is wrong, not the region.

Every Cause at a Glance, in Order

The Sibling Error: PermanentRedirect (and Why It Is Good News)

If your NoSuchBucket investigation surfaces a PermanentRedirect error instead — "The bucket you are attempting to access must be addressed using the specified endpoint" — that is actually the better outcome. PermanentRedirect means S3 found your bucket, knows it lives in a different region, and is telling you the correct endpoint to use. The fix is the same as Cause 1 (point at the right region), but the error message has done the work of identifying the endpoint for you.

The reason you see one error instead of the other depends on the client configuration and how it handles the redirect response. Some setups translate the redirect into a helpful error; others treat the regional miss as a plain 404 NoSuchBucket. Neither is wrong — they are different presentations of the same underlying fact.

If you are seeing PermanentRedirect, read the error message carefully: it names the correct endpoint, and that endpoint embeds the region. Fix the region configuration once, and the error is gone for good.

When Nothing Works: The Honest End of the Road

If every cause above is ruled out — the region is right, the name is spelled correctly, the bucket is confirmed to exist in the right account, no endpoint overrides are in play — then two possibilities remain, and neither is solvable from your side.

The first: a regional service disruption. S3 regional endpoints occasionally have incidents — elevated error rates, partial availability — and during those windows, requests can fail in ways that resemble configuration errors. Check the AWS Health Dashboard (or the AWS Service Health page) for the region in question before assuming your configuration broke. If S3 in that region is having a bad day, your configuration is fine and patience is the fix.

The second: the request is not what you think it is. A proxy, a service mesh, an SDK retry layer, or a caching layer between your code and S3 can silently rewrite or redirect requests. The request you believe is going to s3.us-west-2.amazonaws.com may be arriving somewhere else entirely. The definitive test is CloudTrail: the event record shows the request as S3 received it, at the endpoint it arrived at. If CloudTrail shows no record of your request in the bucket's region, your request never reached that regional S3 — and the problem lives somewhere between your code and the endpoint, not in your AWS configuration at all.

For the truly stubborn case: AWS support, armed with the request ID from the error response and the timestamp, can trace exactly where the request landed. That is the end of the road for client-side debugging, and it is the right place to stop.

Admin: Preventing NoSuchBucket Across a Fleet

Debugging one NoSuchBucket is an afternoon. Preventing them across dozens of services and environments is a practice. The habits that hold up:

1. Never hardcode S3 regions in application code. Use HeadBucket at initialization to discover the bucket's region, then construct the S3 client with that region. One extra API call at startup eliminates the entire class of region-mismatch failures across every environment the code will ever deploy to.
2. Standardize bucket-naming conventions across environments. A consistent prefix (myapp-dev-, myapp-staging-, myapp-prod-) removes the suffix-dropping variant of Cause 3 and makes wrong-environment references obvious at a glance.
3. Put the region in the Terraform provider, not in every resource. One provider block with the correct region, and every S3 resource in the template inherits it. Scattered region overrides are how multi-region drift begins.
4. Alert on NoSuchBucket error rates. A single NoSuchBucket is a typo; a spike is a deleted bucket, a broken deployment, or a region configuration that shipped to production. CloudTrail plus a metric filter on the error code turns the invisible into a dashboard.
5. Document bucket locations centrally. A simple registry — bucket name, region, owning account — that teams consult before wiring up new integrations prevents the "which region is that bucket in again?" conversation from happening during an incident.

Frequently Asked Questions

Why does S3 say NoSuchBucket when the bucket exists?

The bucket exists in one region, and your request is going to a different region. S3 bucket names are globally unique, but the S3 service runs as separate regional installations — so a bucket in us-west-2 genuinely does not exist from us-east-1's perspective. Point your CLI or SDK at the bucket's actual region and the error disappears.

How do I find out what region an S3 bucket is in?

Run aws s3api head-bucket --bucket my-bucket from any region. The response includes the bucket's correct location, so you can then make a proper request to the right regional endpoint. This is the recommended approach — ahead of the older get-bucket-location, which has known reliability issues cross-region.

Why does aws s3 ls work locally but fail on EC2 with NoSuchBucket?

The EC2 instance's AWS SDK or CLI resolves its region from the instance metadata service, which reports the region the instance is running in — not the region your laptop is configured for. If the bucket lives in a different region than the instance, the same command works locally and fails on EC2. Fix: explicitly set the region in the command or the SDK client configuration.

What is the difference between NoSuchBucket and PermanentRedirect?

Both mean your request went to the wrong region. PermanentRedirect means S3 found the bucket, knows it lives elsewhere, and is telling you the correct endpoint to use. NoSuchBucket means the regional S3 that received your request genuinely does not have a bucket by that name. Same root cause, different error-handling behavior in your client.

How do I fix NoSuchBucket in the AWS CLI?

Add the --region flag matching the bucket's actual region: aws s3 ls s3://my-bucket --region us-west-2. Or set the region permanently with aws configure set region us-west-2, or for the current session with export AWS_DEFAULT_REGION=us-west-2. The key is making the CLI's region match the bucket's region.

Why does S3 return a 404 for a bucket I can see in the console?

The console and the CLI are pointed at different regions. The console shows buckets from the region selected in the top-right corner; the CLI defaults to the region in its configuration. Both are correct from their own perspective. Align the CLI's region with the console's region (or vice versa) and the bucket appears in both.

Can a bucket name exist but belong to another AWS account?

Yes. S3 bucket names are globally unique across all AWS accounts, so any bucket name you encounter — in documentation, tutorials, or examples — might belong to someone else's account. HeadBucket can confirm the bucket exists from anywhere, but if aws s3 ls does not list it under your credentials, it is not in your account.

Why does CloudFormation say NoSuchBucket when the bucket is in my template?

Check how you are referencing it. Using !Ref on an AWS::S3::Bucket resource returns the bucket name; using !GetAtt MyBucket.Arn returns the ARN. If a property expects the name and receives the ARN (or vice versa), the resulting string is not a valid bucket name, and the operation fails with NoSuchBucket. Also verify the bucket has actually been created — a resource in the template that failed to deploy will still be referenced by later resources.

What is get-bucket-location and why does us-east-1 return null?

get-bucket-location is the older API for discovering a bucket's region. For historical reasons, buckets in us-east-1 return a LocationConstraint of null rather than the region code — a quirk from when us-east-1 was the only region and needed no location marker. All other regions return their region code normally.

How do I set the region for the AWS CLI permanently?

Run aws configure set region us-west-2 to set it for the default profile, or aws configure set region us-west-2 --profile myprofile for a specific named profile. You can also edit the ~/.aws/config file directly, adding region = us-west-2 under the profile section.

What is the AWS_DEFAULT_REGION environment variable?

It overrides the region set in the AWS CLI config file for the current shell session. Export AWS_DEFAULT_REGION=us-west-2 and every subsequent CLI command in that session targets us-west-2, regardless of what the config file says. Useful for temporary overrides, dangerous as a lurking stale setting — check it when region problems appear.

Can an S3 access point cause NoSuchBucket?

Yes, if you use the access point name in a context that expects an actual bucket name. Access point aliases work for data access operations like getting and putting objects, but bucket-level operations and some tooling expect the real bucket. Use the bucket name for bucket operations and the access point for object operations, and the error goes away.

What is a directory bucket and why does it cause NoSuchBucket?

Directory buckets (S3 Express One Zone) are a distinct bucket type with a different naming scheme that includes an Availability Zone suffix, and they live in a different namespace than general-purpose buckets. Tooling designed for general-purpose buckets encounters a directory bucket name and looks it up in the wrong namespace, where it genuinely does not exist.

Can an endpoint override cause NoSuchBucket?

Yes. The AWS_ENDPOINT_URL environment variable and the --endpoint-url CLI flag replace the default S3 endpoint entirely. If the override points at an endpoint that does not have your bucket — a stale setting from a previous project, a proxy, or an S3-compatible service — every request fails as if the bucket does not exist, because from that endpoint's perspective, it does not.

Why did my bucket suddenly disappear?

Check CloudTrail Event history for a DeleteBucket API call on the bucket name. Someone or something — a cleanup script, a Terraform run, a colleague — deleted it. If Terraform state still lists the bucket, run terraform plan -refresh=true to reconcile state with reality. The bucket genuinely no longer exists, and the fix is recreation (plus finding out who deleted it).

How do I check if an S3 bucket exists from code?

Call HeadBucket on the bucket name. You can make the call to any region in the partition, and the response carries the bucket's correct location. The status codes are ambiguous between "does not exist" and "no permission" (400, 403, or 404 — the documented behavior), but the location header in the response is the useful part either way: if it names a region, the bucket exists somewhere.

Wrapping Up: The Compass and the Map

The next time NoSuchBucket stares back from a terminal, resist the urge to open the IAM console or start re-reading permissions. The bucket exists — you can see it, your colleague can see it, the console shows it. What does not exist is the bucket at the regional endpoint your request went to. That is the whole error.

Run HeadBucket first, every time, from anywhere. It tells you the bucket's true region in thirty seconds. Then align your client to that region — flag, environment variable, config file, SDK constructor, whichever layer your setup uses — and the error is gone.

The name typos and the ARN confusion and the access point edge cases fill in the remaining fraction. But the region is the first suspect, the most likely culprit, and the one that HeadBucket settles instantly. Jake taped the three-command diagnostic inside the repair-counter cabinet, next to the AccessDenied table and the Dynamic Lock instructions. Ethan's verdict: "Every S3 error guide should be one page long: run head-bucket, read the header, point at the region it names. The rest of the documentation is for the days that does not work, and those days are rarer than the internet makes them look."

Revision note. Written September 2026. The regional-service architecture is fundamental to S3 and unlikely to change; specific SDK behaviors around redirect handling evolve between versions. If you have spent an afternoon being told a bucket you can see does not exist, you have met the global-name-regional-bucket split the hard way — and knowing to run head-bucket first puts you ahead of everyone still checking their IAM policies for a region problem.