How to Give Access to an S3 Bucket: Every Way, From IAM Policies to S3 Access Grants

How to give access to an S3 bucket depends on who needs it. For a person or app in your own AWS account, attach an IAM policy that names the bucket (and, if you like, one folder). For someone in another AWS account, add a bucket policy and have their account allow it too. To share one file for a short time, send a presigned URL. For many teams sharing one big bucket, use access points, each with its own rules. For employees from your company directory at scale, use S3 Access Grants. And for a public website, keep the bucket private and serve it through CloudFront. Here is the trap behind most S3 security mistakes: the one-click managed policy AmazonS3FullAccess gives access to every bucket in the account, not just the one you were thinking of, plus permission to delete them. And since April 2023, new buckets block public access and turn off ACLs by default, which is why older "make it public" tutorials now fail. Below, we start with the basics and then walk through every method, with copy-ready policies.

Jake's phone repair shop had one S3 bucket and three people who needed something from it. His accountant needed to read the invoices folder. The shop's photo app needed to upload pictures of incoming phones. And now and then a customer needed to download a single invoice. In the shop's early days, a helpful friend had solved all three the quick way: one IAM user with AmazonS3FullAccess and its access key, shared by everyone. Then a sync tool on a part-time technician's laptop, using that same key, "cleaned up" a folder it should never have touched. Jake spent two days restoring photos from backups. Ethan's first question was the one this guide is organized around: who needs access, to what, and for how long?

The basics: how S3 decides who gets in

Every S3 request is checked against a few kinds of rules, and every method in this guide is just a different way of writing one of them.

• Nobody has access by default. A new bucket is private. Only the account's administrators can use it until you grant something.
• Identity-based policies are attached to who: an IAM user, a group, or a role. They say "this person may do these things to these buckets." AmazonS3FullAccess is one of these.
• Resource-based policies are attached to what: the bucket itself, through a bucket policy. They say "these people, possibly from other accounts, may do these things to me."
• An explicit Deny always wins. If any policy says Deny, no Allow anywhere can override it. Organization-wide guardrails can add Denies too.
• Block Public Access is a safety switch on the account and on each bucket that refuses public access even if a policy tries to grant it. It is on by default for new buckets.

One more detail causes more "AccessDenied" confusion than any other: a bucket and the objects inside it are two different things, with two different addresses (ARNs). Listing what is in a bucket is an action on the bucket (arn:aws:s3:::jakes-shop-data), while reading or writing a file is an action on the objects (arn:aws:s3:::jakes-shop-data/*). A policy that grants s3:GetObject on the bucket ARN alone does nothing at all.

"So the old setup was like giving everyone the master key to the whole building," Jake said.

"To every building you own," Ethan said, "including the safe. Now we hand out room keys, and only for the rooms people actually use."

Which method do you need? A quick map

Who needs access	Use	Jake's example
A person or app in your account	IAM policy on their user, group or role	The photo app uploads to photos/
One folder only	IAM policy limited to a prefix	The accountant reads invoices/
Another AWS account	Bucket policy + their IAM policy	A repair partner's system reads shared/
Anyone with a link, briefly	Presigned URL	A customer downloads one invoice
Many apps or teams on one shared bucket	Access points	Not needed yet
Company directory users and groups, at scale	S3 Access Grants	Not needed yet
The whole internet (a website)	CloudFront in front of a private bucket	The shop's website images

Method 1: an IAM policy for someone in your account

This is the right answer most of the time. Write a policy that names exactly the bucket and the actions needed, and attach it to the user, group or role that needs it. Here is a policy that lets an app read, write and delete files in one bucket, and list what is in it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListTheBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::jakes-shop-data"
    },
    {
      "Sid": "ReadWriteObjects",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::jakes-shop-data/*"
    }
  ]
}

Notice the two statements: ListBucket on the bucket, and the object actions on bucket/*. Drop s3:DeleteObject if the app should never delete, which for Jake's photo app it should not.

1. Open the IAM console and choose Policies → Create policy.
2. Switch to the JSON editor, paste the policy, and replace the bucket name.
3. Give it a clear name, such as photo-app-s3-upload, and create it.
4. Attach it: open the role (for an app running on AWS) or the group (for people), choose Add permissions → Attach policies, and select it.
5. Test with the real identity, for example aws s3 ls s3://jakes-shop-data/, before telling anyone it works.

Limiting access to one folder (prefix)

Jake's accountant only needs the invoices/ folder, read-only. Listing has to be limited with a condition, because the list action applies to the bucket, not to a folder:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListOnlyInvoices",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::jakes-shop-data",
      "Condition": { "StringLike": { "s3:prefix": ["invoices/*"] } }
    },
    {
      "Sid": "ReadInvoices",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::jakes-shop-data/invoices/*"
    }
  ]
}

With this, the accountant can list and download invoices, and gets AccessDenied for anything else, which is exactly the point.

"S3 full access policy": what AmazonS3FullAccess really grants

AWS offers ready-made managed policies, and AmazonS3FullAccess is the one tutorials reach for. It allows every S3 action on every bucket in the account: reading, writing and deleting objects, changing bucket policies, turning off Block Public Access, and deleting buckets. AmazonS3ReadOnlyAccess similarly allows reading every bucket. They are fine for an administrator, or for a throwaway learning account. For anything that touches real data, write a policy that names the bucket, as above. It takes five minutes and turns a disaster into an AccessDenied message.

Method 2: a bucket policy, for other accounts and services

A bucket policy lives on the bucket and can name principals from other AWS accounts, or AWS services. You need one when the person or system asking is not in your account, or when you want a rule that applies to everyone, such as "refuse unencrypted connections." Edit it under the bucket's Permissions → Bucket policy.

Here is a policy that lets a role in a partner's account read the shared/ folder:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PartnerReadShared",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::444455556666:role/repair-partner-reader" },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::jakes-shop-data/shared/*"
    }
  ]
}

Cross-account access needs both sides to agree: your bucket policy allows their role, and their account's IAM policy allows that role to use your bucket. If either side is missing, the answer is AccessDenied; if the files are encrypted with your own KMS key, the key policy must allow them too. Our cross-account Access Denied guide walks through all three layers.

A bucket policy is also where you enforce rules for everyone. A common one denies any request that does not use HTTPS, using the aws:SecureTransport condition. Because an explicit Deny always wins, such a rule protects the bucket no matter what other policies say.

S3 access keys and secret access keys

Programs outside AWS, such as a script on an office PC or a backup tool, need credentials to call S3. The classic answer is an access key: an access key ID and a secret access key belonging to an IAM user. They work, but they are long-lived passwords for your data, and leaked keys are one of the most common causes of AWS breaches.

• For people, prefer signing in through IAM Identity Center, which gives temporary credentials, including to the AWS CLI.
• For apps running on AWS (EC2, Lambda, ECS), use an IAM role. The service supplies short-lived credentials automatically; there is no key to leak.
• If you must use an access key, give its IAM user only the narrow policy it needs, store the secret in a secrets manager or the tool's credential store, never in code, and rotate it.

If a key ever ends up somewhere it should not, such as a public code repository, act within minutes; our leaked-key guide lists the steps in order. Jake's shared full-access key was retired the same day: the photo app now runs with a role, the accountant signs in through Identity Center, and nobody has a long-lived key.

Giving access to AWS services, not people

Much of S3 access is not for people at all, but for other AWS services: a Lambda function that resizes photos, an EC2 server that writes backups, a load balancer that writes logs. Two patterns cover nearly all of it.

Your own compute gets a role. Lambda functions, EC2 instances (through an instance profile), ECS tasks and Glue jobs all run with an IAM role. Put the narrow S3 policy from Method 1 on that role, and the service receives short-lived credentials automatically. Nothing is stored on disk and nothing needs rotating.

AWS services that deliver into your bucket are allowed in the bucket policy, by their service name, with conditions that tie them to your account. Load balancer logs, CloudTrail logs and S3 server access logs all work this way, and the console usually writes the right statement for you when you turn the feature on. Always keep the account condition (aws:SourceAccount) or source ARN condition (aws:SourceArn) in those statements, so only your resources can write to your bucket.

S3 event notifications into SQS, SNS or Lambda

A common surprise: you set S3 to send an event to an SQS queue when a file arrives, and S3 refuses to save the setting. The permission here is on the destination, not the bucket. The queue's access policy must allow the S3 service to send messages, limited to your bucket and account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ToSend",
      "Effect": "Allow",
      "Principal": { "Service": "s3.amazonaws.com" },
      "Action": "sqs:SendMessage",
      "Resource": "arn:aws:sqs:us-east-1:111122223333:new-photos",
      "Condition": {
        "ArnLike": { "aws:SourceArn": "arn:aws:s3:::jakes-shop-data" },
        "StringEquals": { "aws:SourceAccount": "111122223333" }
      }
    }
  ]
}

SNS topics need the same idea with sns:Publish, and for Lambda the console adds a resource-based permission to the function when you choose it as the destination. If the queue is encrypted with a customer managed KMS key, the key policy must allow S3 to use it as well.

Method 3: presigned URLs, for one file and a short time

When a customer needs one invoice, you do not want to create an account for them. A presigned URL is a normal web link with a signature in it that grants access to one object, for a limited time, using the permissions of whoever created it. Anyone with the link can use it until it expires.

aws s3 presign s3://jakes-shop-data/invoices/2026/INV-4471.pdf --expires-in 3600

That prints a link valid for one hour. The longest allowed is seven days (604,800 seconds), and a link created with temporary credentials stops working when those credentials expire, even if you asked for longer. Apps can also create presigned URLs for uploads, so a customer's browser can send a file straight to S3 without your server handling it. Our presigned URL guide covers both directions.

Conditional and time-limited access

Policies can say more than "who" and "what." Conditions let you add "from where," "how" and "until when," which is often the difference between acceptable and risky access.

• Only until a date. A contractor helping for a month can be allowed with a DateLessThan condition on aws:CurrentTime. After that date the Allow simply stops applying, even if nobody remembers to remove it.
• Only from the office or VPN. An IpAddress condition on aws:SourceIp limits access to your public IP range. (Requests coming through AWS services or VPC endpoints use other conditions, such as aws:SourceVpce.)
• Only over HTTPS. A Deny with aws:SecureTransport set to false refuses unencrypted connections for everyone.
• Only with multi-factor sign-in for sensitive actions, using the aws:MultiFactorAuthPresent condition.

Here is the contractor case, read-only on one folder until the end of October:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::jakes-shop-data/shared/*",
  "Condition": {
    "DateLessThan": { "aws:CurrentTime": "2026-10-31T23:59:59Z" }
  }
}

Jake used exactly this for a contractor who digitized his old paper invoices. The access ended on schedule, with no reminder needed.

Checking who has access to a bucket

Sooner or later someone asks, "who can actually get into this bucket?" Three free tools answer it without guesswork:

• IAM Access Analyzer reviews your bucket policies, access points and other resource policies and lists every bucket that is shared outside your account or with the public. In the S3 console, the same findings appear under IAM Access Analyzer for S3. Review the list whenever it changes.
• The IAM policy simulator answers "would this user or role be allowed to do this action on this object?" before anyone tries, which is the quickest way to test a new policy.
• CloudTrail shows what actually happened: bucket-level changes are recorded by default, and object-level reads and deletes are recorded when you turn on data events for the bucket.

Removing access cleanly

Granting access is the easy half; taking it away is where gaps appear. When a person leaves, a contractor finishes, or an app is retired:

• Detach or delete the policy from the user, group or role, and remove the person from any group that carries S3 permissions.
• Deactivate, then delete, access keys. Deactivating first lets you confirm nothing important breaks before the key is gone for good.
• Remove their account or role from bucket policies and access point policies, and delete their Access Grants.
• Remember presigned URLs. A presigned URL cannot be canceled on its own; it works until it expires. To stop one early, remove the permissions of the identity that created it, deactivate the key it was signed with, or move or delete the object. Short expiry times are the real protection.

Method 4: S3 access points, for many apps on one bucket

As more teams and apps share one large bucket, its single bucket policy turns into a long, risky document that everyone edits. Access points split it up. Each access point is a named entry point to the bucket, with its own policy, its own Block Public Access settings, and optionally a rule that it accepts requests only from inside one VPC. An "accounting" access point can allow the finance team into invoices/, while a "media" access point lets the photo app into photos/, without either team touching the other's rules.

Useful things to know: an account can have thousands of access points per Region, each policy can be up to 20 KB, and access points work for object operations such as reading and writing files, not for bucket administration. Each access point gets an alias that many tools accept in place of a bucket name. The access point policy works together with the bucket policy, so a common pattern is a short bucket policy that delegates control to the account's access points, and detailed rules on each access point.

Method 5: S3 Access Grants, for company users at scale

S3 Access Grants solves a specific, large-scale problem: giving many people from a company directory access to many datasets, without writing a policy for each combination. Instead of policies, you create simple grants: "this group may READ s3://bucket/finance/," "this user may READWRITE s3://bucket/projects/alpha/."

The pieces:

• An Access Grants instance: the container for your grants in a Region of your account.
• Locations: the S3 buckets or prefixes the instance may hand out access to, each registered with an IAM role that Access Grants uses behind the scenes.
• Grants: a grantee, a permission level (READ, WRITE or READWRITE) and a scope (a bucket, prefix or object). Grantees can be IAM users and roles, or, through IAM Identity Center, users and groups straight from your corporate directory, such as Microsoft Entra ID or Okta.

When an application needs data on a user's behalf, it asks Access Grants for credentials with the GetDataAccess call. Access Grants checks the grants and returns short-lived credentials scoped to just what that user may see. With IAM Identity Center's trusted identity propagation, CloudTrail then records the actual end user on each S3 data event, not just an application role, which makes audits far simpler. AWS publishes plugins for some SDKs and tools so apps can fetch these credentials automatically.

To set it up, open the S3 console, choose Access Grants, create an instance in your Region (optionally connected to IAM Identity Center), register a location, and create grants. Access Grants has its own pricing, so check the current Amazon S3 pricing page; storage and request charges apply as usual.

S3 Access Grants vs access points vs bucket policies

	Bucket and IAM policies	Access points	Access Grants
Best for	A few people, apps and buckets	Many apps or teams on shared buckets	Many directory users and groups on many datasets
Who can be granted	IAM principals, other accounts, services	IAM principals	IAM principals and corporate directory identities
How rules are written	JSON policies	A JSON policy per access point	Simple grants: who, READ/WRITE, where
Main limit	Bucket policies max out at 20 KB	Clients must use the right access point	Apps must request credentials through it

A shop like Jake's will not need Access Grants for years, if ever. A company with thousands of employees, hundreds of datasets, and an auditor asking "who read this file?" is exactly who it is for. For tables in a data lake rather than files, AWS Lake Formation plays the same role at the table, column and row level.

Public access: when, and how to do it safely

Searches for an "S3 public access policy" usually come from one of two situations: hosting a website, or sharing files with the world. Since April 2023, new buckets have Block Public Access turned on and ACLs turned off by default, so the old tutorial steps (make the object public with an ACL, or add a "Principal": "*" policy) fail with errors such as "Access Denied" or "The bucket does not allow ACLs."

The safe ways to share with the public:

• For a website or downloads, use CloudFront. Keep the bucket private and let CloudFront read it through Origin Access Control. You get HTTPS, your own domain, caching and lower costs, and the bucket never becomes public. Our CloudFront and OAC guide sets it up.
• For a few files, use presigned URLs with sensible expiry times.
• Only if you truly need a public bucket, such as S3's own static website endpoint, turn off Block Public Access for that bucket only, put nothing private in it, and add a bucket policy that allows s3:GetObject for everyone on bucket/*.

"The bucket does not allow ACLs": Object Ownership explained

Older guides grant access with ACLs (access control lists), per-object permission lists such as "public-read." Since April 2023, new buckets use the Bucket owner enforced Object Ownership setting, which turns ACLs off completely: the bucket owner owns every object, and access is controlled only by policies. Any tool that still sends an ACL with an upload, for example aws s3 cp file s3://bucket/ --acl public-read, gets an error such as AccessControlListNotSupported: The bucket does not allow ACLs.

The fix is almost never to turn ACLs back on. Remove the ACL option from the command or the app's settings, and grant access with the policies described above. Turning ACLs back on brings back a second, harder-to-audit permission system that AWS now recommends against for nearly every use. Our ACL error guide covers the rare cases where an old integration truly needs them.

Encryption adds its own permission check

Every new object in S3 is encrypted at rest automatically with S3-managed keys (SSE-S3), and that encryption needs no extra permissions. Many organizations choose SSE-KMS instead, using a key in AWS KMS that they control. That adds a second lock: to read an object, the caller needs s3:GetObject on the object and kms:Decrypt on the key; to upload, they need kms:GenerateDataKey. If the key's policy does not allow them, the answer is AccessDenied even when the S3 policy is perfect. For cross-account sharing, this is the step most often forgotten, because a key policy lives in the key owner's account. Our KMS AccessDenied guide shows the exact statements.

Mounting S3 as a drive: s3fs and Mountpoint

Some people want S3 to appear as a folder on a Linux machine, so ordinary programs can read files from it. Two common tools do that, and both use the same permissions as everything above: the credentials they run with need a policy that allows the bucket.

• s3fs-fuse is a long-standing open-source tool. On Ubuntu or Debian, sudo apt install s3fs, put credentials in a file readable only by you (chmod 600), and mount with s3fs jakes-shop-data /mnt/shop -o passwd_file=${HOME}/.passwd-s3fs. On an EC2 instance, use the instance's IAM role instead of a key file.
• Mountpoint for Amazon S3 is AWS's own open-source mount client, built for high-throughput reading of large files, such as data for analytics or machine learning. It is fast, but deliberately limited: it is built for reading and for writing new files in one pass, not for editing existing files in place.

Either way, remember that S3 is object storage, not a disk: renaming a folder means copying every file, and many small edits are slow and billed as requests. For sharing files between servers like a real file system, a service such as Amazon EFS is often the better fit.

Accessing S3 from the command line and from code

Once access is granted, here is how people actually use it. With the AWS CLI installed and signed in (for people, aws configure sso is the modern way):

aws s3 ls s3://jakes-shop-data/invoices/                  # list a folder
aws s3 cp INV-4471.pdf s3://jakes-shop-data/invoices/2026/  # upload a file
aws s3 cp s3://jakes-shop-data/invoices/2026/INV-4471.pdf . # download it
aws s3 sync ./photos s3://jakes-shop-data/photos/          # copy only what changed

Be careful with sync --delete: it removes files in the destination that are not in the source, which is exactly how Jake's folder was wiped by a misconfigured sync on a laptop. With narrow permissions, that same mistake would have failed harmlessly. The same caution applies to aws s3 rm --recursive, which deletes everything under a prefix without asking twice.

From Python, the AWS SDK (boto3) picks up the same credentials automatically:

import boto3

s3 = boto3.client("s3")
s3.upload_file("INV-4471.pdf", "jakes-shop-data", "invoices/2026/INV-4471.pdf")
s3.download_file("jakes-shop-data", "invoices/2026/INV-4471.pdf", "copy.pdf")
for obj in s3.list_objects_v2(Bucket="jakes-shop-data", Prefix="invoices/").get("Contents", []):
    print(obj["Key"], obj["Size"])

If any of these fails with AccessDenied, the message itself is a clue: it names the action that was refused, which tells you which statement of the policy is missing.

Putting it together: Jake's three doors, end to end

Here is how Ethan rebuilt the shop's access in an afternoon, using only the methods above:

• The shared full-access user was retired. Its access key was deactivated, a day of watching confirmed nothing important broke, and then the key and user were deleted.
• The photo app got its own identity. It runs on a small PC in the back room, not on AWS, so instead of a stored key it uses IAM Roles Anywhere, which lets machines outside AWS exchange a certificate for short-lived role credentials. The role's policy allows s3:PutObject on photos/* and nothing else; no list, no delete.
• The accountant signs in through IAM Identity Center with a permission set carrying the read-only invoices/ policy, and uses a desktop S3 browser that supports single sign-on.
• Customers receive presigned links generated by the shop's invoice tool, valid for 24 hours.
• The bucket itself keeps Block Public Access on, has a bucket policy that refuses non-HTTPS requests, has versioning turned on so any deletion can be undone, and has CloudTrail data events for the invoices/ folder.

Total extra cost: a few cents a month for the data events. Total risk removed: the single key that could delete everything. The next time a laptop sync tool misbehaved, as one eventually did, it failed with AccessDenied and nothing was lost.

A simple starting template for small teams

If you are setting up S3 access for a small team for the first time, three levels cover most needs, and they map neatly onto IAM Identity Center permission sets or IAM groups:

• Admins: full control of the team's buckets, including policies and settings. One or two people, signed in with multi-factor authentication.
• Editors: read, write and delete objects in the team's working prefixes, but no changes to bucket settings or policies. Most day-to-day users.
• Viewers: read-only access to the prefixes they need, such as reports or invoices.

Apps get their own roles with the smallest policy that works, never a person's credentials. Write each policy once, name the buckets and prefixes explicitly, and attach people to groups rather than giving individuals their own policies; when someone changes jobs, you move them between groups instead of editing JSON. Add versioning on important buckets so editors' mistakes can be undone, and review the group memberships every few months. That simple structure is enough for a business of a few dozen people, and it grows naturally into access points or Access Grants later.

Still getting AccessDenied? A quick checklist

1. Is the request using the identity you think? Run aws sts get-caller-identity with the same profile or role.
2. Does the policy name the right ARN: bucket for listing, bucket/* (or bucket/prefix/*) for objects?
3. Cross-account: do both the bucket policy and the caller's IAM policy allow it?
4. Is there an explicit Deny anywhere, in the bucket policy, an organization policy, or a permissions boundary? Deny always wins.
5. Are the objects encrypted with a KMS key the caller cannot use?
6. Is Block Public Access refusing a public grant, or are ACLs disabled while the tool still sends one?

Each of those has its own detailed walkthrough in our S3 AccessDenied guide, and organization-wide denies are explained in our AWS Organizations guide.

For IT admins: keeping S3 access tidy as it grows

• Keep account-level Block Public Access on, and make exceptions per bucket only with a documented reason.
• Prefer roles and Identity Center over IAM users with keys. Audit and remove old access keys regularly.
• Use IAM Access Analyzer to find buckets shared with other accounts or the public, and review its findings on a schedule.
• Set organization guardrails with service control policies and resource control policies, for example to forbid public buckets or require encryption across every account.
• Turn on CloudTrail data events for buckets holding sensitive data, so you can answer who read or deleted what.
• Move from one big bucket policy to access points or Access Grants before the policy becomes something nobody dares to edit.

Giving access to S3: frequently asked questions

Jake's bucket now has three narrow doors instead of one master key. The photo app uploads through a role that cannot delete. The accountant reads invoices through Identity Center and sees nothing else. Customers get a one-day link to their own invoice. If a laptop sync tool ever misbehaves again, the worst it can do is fail with AccessDenied. If you have been unsure how to share an S3 bucket without opening it to the world, you were right to be careful; the right answer is almost always smaller than the first one you are offered.

Revision note. Written October 5, 2026. If S3 permissions have felt like a maze of JSON, you were never alone; may your next policy be short, specific, and the last one you have to fix.