Amazon S3 Bucket Names Aren’t Always Globally Unique Anymore — Here’s What Changed (and Why I’m Excited)

I still remember the first time S3 humbled me.

I was following a “hello AWS” tutorial, feeling confident, and then S3 hit me with:

Bucket name already exists

I tried again. And again. And again.

Different names, different variations, still taken!

That’s when I learned the “classic rule”:

S3 bucket names are globally unique (within an AWS partition).

Meaning: if someone anywhere already owns that bucket name, you can’t have it.

But here’s the big update I recently learned, and it’s huge for builders, platform teams, and security folks:

Amazon S3 now supports creating general-purpose buckets inside an “account regional namespace”, which removes the “find a globally unique name” pain.

AWS announced this on Mar 12, 2026:
https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-s3-account-regional-namespaces/

---

In this article, I’ll break down what changed, how it works, why it matters, and how I’d explain it if I were designing bucket naming at scale.

What used to be true (and is still true by default)

By default, general purpose buckets exist in a global namespace.

AWS puts it plainly:

• “Each bucket name must be unique across all AWS accounts in all the AWS Regions within a partition.” Official docs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

That means:

• my-company-logs can only exist once (in that partition).
• If the bucket is deleted, the name becomes available again — and someone else could recreate it later.

What changed: Account regional namespaces (Mar 2026)

AWS introduced a second option:

You can now create a general purpose bucket in a namespace reserved only for your account:

“You can also choose to create a bucket in your account regional namespace. Your account regional namespace is a subdivision of the global namespace that only your account can create buckets in.”

Official docs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

AWS also summarizes the “why” in the announcement:

• eliminates the need to find globally unique bucket names
• makes it easier to build workloads like “one bucket per customer/team/dataset”
• can be enforced using IAM policies/service control policies (SCPs)

Announcement: https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-s3-account-regional-namespaces/

The nuance I want to keep clear:

• Global namespace is still the default
• But now you have a reserved namespace you can opt into

How the naming looks (the new naming convention)

Buckets in your account regional namespace follow this naming pattern:

bucket-name-prefix-accountId-region-an

Official example:

amzn-s3-demo-bucket-111122223333-us-west-2-an

Source: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

So instead of fighting to get:

• my-company-logs

…you can choose a predictable prefix like:

• my-company-logs

and the final name will include your account + region suffix that makes it unique to you.

Why this matters (in real systems)

1) It kills the “I spent 20 minutes naming a bucket” problem

If you’ve ever created buckets for different environments, you know this loop:

• myapp-prod-logs (taken)
• myapp-prod-logs-1 (taken)
• myapp-prod-logs-2026 (taken)
• myapp-prod-logs-<random> (finally works, but now it’s ugly)

Account regional namespaces support a much more predictable naming scheme.

2) It reduces risk after deletion (a security win)

In the shared global namespace, once a bucket is deleted, the name becomes available again. Another account can recreate the name later and potentially receive requests intended for that name.

Official docs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

In contrast, for account regional namespace buckets:

• Only your account can create buckets in that namespace
• Another account cannot recreate your account-regional bucket name

Official docs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

3) It scales for bucket-per-customer / bucket-per-team designs

AWS explicitly calls out bucket-per-customer/team/dataset workloads in the announcement:

https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-s3-account-regional-namespaces/

That’s a very modern SaaS/platform pattern, and it’s nice to see S3 making it easier to do it safely and predictably.

Creating an account-regional namespace bucket (AWS CLI)

The official docs show creating a bucket using the AWS CLI like this:

aws s3api create-bucket \
    --bucket amzn-s3-demo-bucket-012345678910-us-west-1-an \
    --bucket-namespace account-regional \
    --region us-west-1 \
    --create-bucket-configuration LocationConstraint=us-west-1

Source: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

Note: Before you run the command, make sure your aws cli command is updated.

How I’d enforce this in an organization (IAM/SCP policy)

If I were working on a platform team, I’d want consistent naming and fewer security foot-guns. AWS provides a clean enforcement pattern using the condition key:

• s3:x-amz-bucket-namespace

Here’s an example IAM policy from the docs that denies s3:CreateBucket unless the request is using account-regional:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireAccountRegionalBucketCreation",
      "Effect": "Deny",
      "Action": "s3:CreateBucket",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-bucket-namespace": "account-regional"
        }
      }
    }
  ]
}

Source: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

Bucket naming rules (still important)

Even with namespaces, S3 bucket names still follow the general naming rules, like:

• 3–63 characters
• lowercase letters, numbers, periods (.), and hyphens (-) only
• must start and end with a letter or number
• no two adjacent periods
• cannot look like an IP address

Official rules: https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html

Also note:

• -an is reserved for account regional namespace buckets
• the account/regional suffix counts toward the 63-character limit

Official docs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html

The mental model I use

This is how I explain it to myself:

Global namespace (default)

• Like a global username system
• If someone owns it, you can’t use it
• If deleted, someone else might grab it later

Account regional namespace (new)

• Like a reserved “username space” under my account + my region
• I still choose the prefix, but uniqueness is guaranteed by the suffix
• Another account can’t recreate my account-regional bucket name

Final takeaway

When I first learned S3 bucket names had to be globally unique, I accepted it as “just an AWS thing.”

But account regional namespaces feel like AWS responding to how people actually build today: lots of environments, lots of teams, and a need for predictable and secure naming.

If I’m building something new, I’d strongly consider defaulting new buckets to the account regional namespace — especially if naming conventions matter, or if I want to reduce the risk of name reuse after deletion.

---

References (official)

• AWS announcement (Mar 12, 2026): https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-s3-account-regional-namespaces/
• Namespaces for general purpose buckets: https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html
• General purpose bucket naming rules: https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html