← Back to Blogs

How to Create a Public S3 Bucket in 2026 (Step-by-Step Guide)

How to Create a Public S3 Bucket in 2026 (Step-by-Step Guide)

Amazon S3 remains one of the most popular object storage solutions for developers, startups, and enterprise systems. However, its security defaults have changed dramatically over the last few years. In 2026, newly created buckets are private by default, block all public access, and disable legacy ACL permissions.

If you’re building a marketplace, SaaS, blog, or portfolio that needs to serve public images, you’ll need to adjust the defaults. This guide walks through the correct and secure way to create an S3 bucket with public read access in 2026, including access keys, bucket policies, and testing.


Why Public Access Changed in AWS

Before 2024, many developers simply uploaded with:

ACL: public-read

and everything just worked.

In 2026:

✔ ACLs are disabled ✔ “Block Public Access” is enabled ✔ Public URLs are denied by default ✔ Bucket owner enforced mode is applied

This means the modern, recommended way to expose objects publicly is:

Bucket Policy → Public Read → ACL Disabled

This is more secure and auditable than the old ACL system.


Step 1 — Create a New S3 Bucket

Go to the AWS Console:

Services → S3 → Create Bucket

Configure the following:

Name: my-app-assetsRegion: Choose closest region to users ✔ Object Ownership: “Bucket owner enforced” (default) ✔ ACLs: disabled (default)

Then click Create bucket.


Step 2 — Disable the “Block All Public Access” Switch

By default, AWS blocks all forms of public access for safety.

To enable public content:

  1. Go to your bucket

  2. Click Permissions

  3. Click Block Public Access (bucket settings)

  4. Uncheck:

☑ Block all public access

AWS will show a yellow warning box — this is expected for public buckets.

Click Save Changes.


Step 3 — Add a Public Read Bucket Policy

Now objects must be readable publicly via policy.

Scroll to Bucket Policy and click Edit.

Paste this policy (replace my-app-assets):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-app-assets/*"
    }
  ]
}

This allows anyone to read objects — but not upload, delete, or modify them.

Security note: This is the modern replacement for public-read ACLs.


Step 4 — Upload a Test File

Upload an image logo.png or similar.

After upload, click it and copy the Object URL, it will look like:

https://my-app-assets.s3.ap-south-1.amazonaws.com/logo.png

Open it in the browser.

If everything is configured correctly, the image will load publicly.


Step 5 — Generate AWS Credentials (Access Key + Secret Key)

To allow your backend or CI/CD pipeline to programmatically upload objects, you need IAM credentials.

Go to:

IAM → Users → Create User

✔ Name: s3-uploader✔ Access type: Programmatic access

When asked for permissions, choose:

Attach policies directly

Select:

AmazonS3FullAccess    (for dev)

or for production use least privilege:

AmazonS3PutObject
AmazonS3DeleteObject

After creation, AWS will show:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

Download the .csv — AWS will never show the secret key again.


Step 6 — Test Uploading Programmatically (Optional)

Example Node.js upload:

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
import fs from "fs";

const s3 = new S3Client({
  region: "ap-south-1",
  credentials: {
    accessKeyId: process.env.AWS_ACCESS_KEY_ID,
    secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY
  }
});

await s3.send(new PutObjectCommand({
  Bucket: "my-app-assets",
  Key: "test.jpg",
  Body: fs.readFileSync("./test.jpg"),
  ContentType: "image/jpeg"
}));

No ACL property is needed anymore.


Troubleshooting (Common Issues)

403 Forbidden

Cause:

  • Policy missing

  • Public blocked

  • Access not allowed

AccessControlListNotSupported

Cause:

  • Code attempted ACL: public-read

Fix:

→ Remove ACL usage

Works in console but not in browser

Cause:

  • Bucket policy not configured yet


When You Should NOT Use a Public Bucket

Avoid public buckets for:

❌ invoices ❌ backups ❌ sensitive data ❌ user documents ❌ health reports

Use private buckets + signed URLs instead.


Conclusion

Creating a public S3 bucket in 2026 isn’t as simple as ticking public-read anymore. AWS defaults now favor security, so enabling public access requires conscious configuration:

✔ Block Public Access → OFF ✔ Public Read Bucket Policy → ON ✔ ACLs → OFF ✔ Ownership → Bucket Owner Enforced ✔ Credentials via IAM → Secure

These practices give you a predictable, secure, and modern S3 bucket setup suitable for product images, avatars, blog assets, and public static files.


— End of the article —

Discussion (0)

Please sign in to join the discussion.

Sign In to Comment

Have any query???

Get in touch and let's discuss your query.

Send a message