How to Set Up an AWS S3 Bucket and Get Your Credentials (Complete Guide)

A step-by-step walkthrough for developers — from bucket creation to environment variables

If you’re building a web app and need to store images, files, or media in the cloud, AWS S3 is the gold standard. But getting everything configured correctly — the bucket settings, public access policies, CORS, and credentials — can trip up even experienced developers.

This guide walks you through everything in one place: creating the bucket with the right settings, locking it down with a proper policy, and generating the AWS credentials your app needs.

Part 1: Creating the S3 Bucket

Step 1 — Go to the S3 Console and Create a Bucket

Head to console.aws.amazon.com/s3 and click Create bucket.

When choosing a region, select ap-south-1 (Mumbai) if your backend (EC2, Lambda, etc.) and database (e.g. MongoDB Atlas) are also in Mumbai. Keeping all three in the same region means near-zero latency between them and avoids cross-region data transfer charges. If your stack is elsewhere, pick the closest matching region.

Step 2 — Choose a Globally Unique Bucket Name

S3 bucket names are unique across ALL AWS accounts globally — not just yours. That means images or media are definitely taken.

Use something descriptive and project-specific:

destination-images
prod-media-2026
myapp-user-uploads

Tip: Avoid using your exact domain name as the bucket name — you’ll map a clean CDN domain to it later anyway. Add a year or suffix if your preferred name is taken.

Step 3 — Object Ownership: Keep “ACLs Disabled” (Default)

Leave this at the default “ACLs disabled” setting. This is the modern AWS-recommended approach (enforced since 2023).

Instead of setting permissions per object, you’ll control access entirely through a Bucket Policy (covered in Step 7). This is simpler, more auditable, and harder to misconfigure.

Step 4 — Block Public Access: Uncheck “Block all public access”

⚠️ This is the setting most people get wrong.

If your S3 bucket serves publicly viewable content — destination images, product photos, profile pictures — you must uncheck “Block all public access”. Otherwise your images will return 403 errors to website visitors.

• Uncheck the box
• Check the acknowledgement checkbox that appears below it

You are not making the bucket a free-for-all. The next step (Bucket Policy) restricts it to read-only access — nobody can upload or delete without IAM credentials.

Step 5 — Bucket Versioning: Enable It

Turn on Bucket Versioning.

This protects against accidental overwrites or deletions. If an admin uploads a corrupted image over an existing filename, you can roll it back to the previous version. For a content-heavy application, this is worth the small additional storage cost.

Step 6 — Default Encryption: Leave It Alone

Server-side encryption (SSE-S3) is enabled by default at no extra cost. No action needed here — just leave the default as-is.

Step 7 — Add a Bucket Policy (Public Read-Only)

After the bucket is created:

1. Click your bucket name
2. Go to the Permissions tab
3. Scroll to Bucket policy and click Edit
4. Paste the JSON below (replace wanderly-destination-images with your actual bucket name)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::wanderly-destination-images/*"
    }
  ]
}

What this does:

• ✅ Anyone can read/view objects (your images load on your website)
• ❌ Nobody can list, upload, or delete without valid IAM credentials
• ❌ Nobody can access the bucket root — only individual objects via direct URL

Step 8 — Add CORS Configuration

Still on the Permissions tab, scroll to Cross-origin resource sharing (CORS) and click Edit.

Paste this configuration (replace the origins with your actual domains):

[
  {
    "AllowedHeaders": ["*"],
    "AllowedMethods": ["GET", "PUT", "POST"],
    "AllowedOrigins": [
      "https://yourapp.com",
      "https://admin.yourapp.com",
      "http://localhost:3001"
    ],
    "ExposeHeaders": ["ETag"]
  }
]

Why this matters: If your admin panel or frontend ever uploads files directly to S3 from the browser (using presigned URLs), the browser will block the request unless CORS is configured. Add this now — it costs nothing and saves a debugging headache later.

Part 2: Getting Your AWS Credentials

The credentials (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) don't come from S3 — they come from AWS IAM (Identity and Access Management). Here's how to generate them.

Step 9 — Create an IAM User

1. In the AWS Console, search for IAM and open it
2. Click Users → Create user
3. Give it a name like s3-app-user or myapp-backend
4. Click Next → Attach policies directly
5. Search for and attach **AmazonS3FullAccess**

Better practice: Instead of AmazonS3FullAccess, create a custom policy that restricts access to only your specific bucket. See the bonus section at the end.

1. Click through and hit Create user

Step 10 — Generate Access Keys

1. Click on the IAM user you just created
2. Go to the Security credentials tab
3. Scroll down to Access keys → click Create access key
4. For use case, select “Application running outside AWS”
5. Click Next → Create access key

Copy both values immediately. The secret access key is shown only once and cannot be retrieved again.

AWS_ACCESS_KEY_ID     = AKIA...         ← copy this
AWS_SECRET_ACCESS_KEY = xxxxxxxx        ← copy this (shown only once!)

Step 11 — Fill in Your .env File

Now you have everything you need:

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=xxxxxxxx
AWS_REGION=ap-south-1
S3_BUCKET=wanderly-destination-images

How to find your region code if you’re unsure: Go to S3 → click your bucket → Properties tab → look for AWS Region. Mumbai shows as ap-south-1.

Bonus: Least-Privilege IAM Policy (Recommended)

Instead of granting full S3 access, restrict the IAM user to only your specific bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::wanderly-destination-images",
        "arn:aws:s3:::wanderly-destination-images/*"
      ]
    }
  ]
}

To use this: in IAM → User → Permissions → Add permissions → Create inline policy → paste the JSON above.

Security Checklist Before You Ship

✅ Check ☐ .env file is in .gitignore ☐ Bucket policy is read-only (no s3:PutObject for Principal: *) ☐ IAM user has least-privilege permissions (not AdministratorAccess) ☐ Access keys are not hardcoded anywhere in your source code ☐ Versioning is enabled on the bucket

⚠️ Never commit .env to Git. Exposed AWS keys get detected and abused within minutes by automated bots that run up thousands of dollars in charges.

Quick Reference Summary

What Where Create S3 bucket AWS Console → S3 → Create bucket Add bucket policy S3 → Your bucket → Permissions → Bucket policy Add CORS config S3 → Your bucket → Permissions → CORS Create IAM user AWS Console → IAM → Users → Create user Generate access keys IAM → User → Security credentials → Create access key Find your region code S3 → Bucket → Properties → AWS Region

That’s it! You now have a properly configured S3 bucket with public read access, CORS support, versioning, and the IAM credentials your application needs to upload and manage files programmatically.

Have questions or ran into a specific error? Drop it in the comments below.

Tags: AWS, S3, Cloud Storage, DevOps, Backend Development, Node.js, Web Development