Creating an S3 Bucket (Step by Step)

A bucket is the top-level container that holds your data in Amazon S3 (Simple Storage Service, AWS’s object storage service). Before you can upload a single file, you need a bucket, and a handful of decisions you make at creation time, the name, the Region, and the security settings, stick with you for the life of that bucket. This page walks through creating a bucket the right way, in both the AWS Management Console and the AWS Command Line Interface (CLI, the terminal tool for AWS), and explains the few choices that are genuinely hard to undo.

What you decide when you create a bucket

Four things matter most when you create a bucket. Get these right and the rest is easy to change later.

Setting	What it controls	Can you change it later?
Bucket name	The globally unique identifier and part of the URL/DNS name	No, names are permanent
Region	The physical AWS Region where data lives	No, you must recreate and copy
Block Public Access	Whether the bucket can ever be made public	Yes, anytime
Versioning	Whether S3 keeps old copies of overwritten objects	Yes (can suspend, not fully disable)
Encryption	How data is encrypted at rest	Yes, anytime

Gotcha: Bucket names are globally unique across every AWS account on Earth, not just yours, and they become part of the bucket’s DNS hostname (my-bucket.s3.amazonaws.com). You cannot rename a bucket. If you need a different name, you create a new bucket and copy the objects across. Choose carefully.

Naming rules you must follow

A bucket name has to be valid DNS, so the rules are stricter than a normal filename:

• 3 to 63 characters long.
• Lowercase letters, numbers, hyphens (-), and dots (.) only. No uppercase, no underscores.
• Must start and end with a letter or number.
• Cannot look like an IP address (e.g. 192.168.1.1).
• Cannot start with xn-- or sthree-, and cannot end with -s3alias.
• Avoid dots in names you plan to use with HTTPS, dots break the wildcard TLS certificate (a digital certificate that proves a server’s identity over an encrypted connection).

A common, safe pattern is to prefix names with your company or project plus a random suffix, for example devcraftly-app-logs-7f3a2b. This keeps the name readable and avoids collisions with other accounts.

Choosing a Region

A Region is a geographic location (such as us-east-1 in Northern Virginia or eu-west-1 in Ireland) where AWS runs its data centers. Pick a Region close to your users for lower latency, and in a country that satisfies any data-residency rules you must follow. Cross-Region data transfer costs money, so keeping your bucket near the services that use it also saves on bills.

Creating a bucket in the Console

1. Sign in to the AWS Management Console and open the S3 service.
2. Click Create bucket.
3. Under Bucket name, type a globally unique name (e.g. devcraftly-app-logs-7f3a2b).
4. Under AWS Region, select the Region you want (e.g. US East (N. Virginia) us-east-1).
5. Leave Object Ownership on the default ACLs disabled (recommended), this means access is controlled by policies, not legacy access control lists.
6. Under Block Public Access settings for this bucket, keep Block all public access checked. Leave it on unless you have a deliberate reason to expose the bucket.
7. Under Bucket Versioning, choose Enable if you want S3 to keep previous versions of overwritten or deleted objects (recommended for important data).
8. Under Default encryption, leave Server-side encryption with Amazon S3 managed keys (SSE-S3) selected, all new buckets are encrypted by default.
9. Click Create bucket.

That’s it. The bucket appears in your list and is ready to receive objects.

Creating a bucket with the CLI

The CLI gives you two paths. aws s3 mb (“make bucket”) is the quick, high-level command. aws s3api create-bucket is the lower-level command that maps directly to the S3 API and gives you more control.

The quick way: aws s3 mb

aws s3 mb s3://devcraftly-app-logs-7f3a2b --region us-east-1

Output:

make_bucket: devcraftly-app-logs-7f3a2b

The precise way: aws s3api create-bucket

us-east-1 is special, it is the only Region where you must omit the location constraint. Every other Region requires --create-bucket-configuration.

For us-east-1:

aws s3api create-bucket \
  --bucket devcraftly-app-logs-7f3a2b \
  --region us-east-1

For any other Region (e.g. eu-west-1):

aws s3api create-bucket \
  --bucket devcraftly-app-logs-7f3a2b \
  --region eu-west-1 \
  --create-bucket-configuration LocationConstraint=eu-west-1

Output:

{
    "Location": "http://devcraftly-app-logs-7f3a2b.s3.amazonaws.com/"
}

Apply the secure defaults

New buckets created via the API still need you to confirm the safe settings explicitly. Turn on Block Public Access, versioning, and encryption:

aws s3api put-public-access-block \
  --bucket devcraftly-app-logs-7f3a2b \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

aws s3api put-bucket-versioning \
  --bucket devcraftly-app-logs-7f3a2b \
  --versioning-configuration Status=Enabled

aws s3api put-bucket-encryption \
  --bucket devcraftly-app-logs-7f3a2b \
  --server-side-encryption-configuration \
  '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'

These commands return no output on success.

Infrastructure as Code

If you create buckets often, define them in code so they’re consistent and repeatable. Here is the same secure bucket in Terraform (an Infrastructure as Code tool):

resource "aws_s3_bucket" "logs" {
  bucket = "devcraftly-app-logs-7f3a2b"
}

resource "aws_s3_bucket_public_access_block" "logs" {
  bucket                  = aws_s3_bucket.logs.id
  block_public_acls       = true
  ignore_public_acls      = true
  block_public_policy     = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_versioning" "logs" {
  bucket = aws_s3_bucket.logs.id
  versioning_configuration {
    status = "Enabled"
  }
}

Cost note: Creating a bucket is free, you pay only for what you store and transfer. S3 Standard storage is about $0.023 per GB per month in us-east-1. Versioning, however, keeps every old version and bills for all of them, so a heavily overwritten bucket can grow your bill quietly. Pair versioning with a lifecycle rule to expire old versions.

Best practices

• Choose a clear, prefixed bucket name with a random suffix to avoid global collisions, and remember you can never rename it.
• Pick the Region closest to your users and aligned with your data-residency requirements before you create the bucket.
• Leave Block Public Access ON. Only disable it for a specific, deliberate use case like a static website, and even then prefer Amazon CloudFront (AWS’s content delivery network).
• Enable versioning on buckets holding important or hard-to-recreate data, and add a lifecycle policy to expire old versions.
• Keep default encryption enabled, every new bucket gets SSE-S3 automatically, so never turn it off.
• Define buckets in Terraform or CloudFormation so security settings are consistent across environments.

Related Topics

• What is Amazon S3?
• S3 objects and keys
• S3 Block Public Access
• S3 versioning
• S3 encryption