S3 access points: give each team its own way into a shared bucket

How an access point decides

A request through an access point has to be allowed by both the access point policy and the bucket policy, plus the caller's own IAM policy, and an explicit deny in any of them wins. That sounds like double the work, but the usual pattern makes the bucket policy a pass-through: it allows any action, as long as the request came through an access point owned by your account. From then on each access point policy is the real gate.

Access points also have their own Block Public Access settings, which are fixed when you create the access point. They don't support anonymous access at all, only accept HTTPS, and require Signature Version 4.

S3 bucket policy examples for giving a team access to the right files

• Access point policy, bucket policy and IAM policy must all allow.
• An explicit deny anywhere wins.
• Delegate from the bucket policy once, then manage each access point separately.

Example: a finance access point scoped to one prefix

The commands below create an access point called finance on a shared bucket, delegate the bucket to access points in the account, and give one IAM role read access to finance/ only. The ListBucket statement uses the access point ARN itself with an s3:prefix condition; the GetObject statement uses the access point ARN followed by /object/ and the key pattern. That /object/ segment is the part people most often get wrong.

ACCOUNT=111122223333
REGION=us-east-1
BUCKET=amzn-s3-demo-bucket

aws s3control create-access-point --account-id $ACCOUNT --name finance --bucket $BUCKET

cat > bucket-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DelegateToAccessPoints",
    "Effect": "Allow",
    "Principal": {"AWS": "*"},
    "Action": "*",
    "Resource": ["arn:aws:s3:::$BUCKET", "arn:aws:s3:::$BUCKET/*"],
    "Condition": {"StringEquals": {"s3:DataAccessPointAccount": "$ACCOUNT"}}
  }]
}
EOF
aws s3api put-bucket-policy --bucket $BUCKET --policy file://bucket-policy.json

AP=arn:aws:s3:$REGION:$ACCOUNT:accesspoint/finance
cat > ap-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::$ACCOUNT:role/FinanceTeam"},
      "Action": "s3:ListBucket",
      "Resource": "$AP",
      "Condition": {"StringLike": {"s3:prefix": ["finance/*"]}}
    },
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::$ACCOUNT:role/FinanceTeam"},
      "Action": "s3:GetObject",
      "Resource": "$AP/object/finance/*"
    }
  ]
}
EOF
aws s3control put-access-point-policy --account-id $ACCOUNT --name finance --policy file://ap-policy.json

aws s3 ls s3://$AP/finance/

Secure AWS access with IAM roles and external IDs

Addressing an access point

Tools that accept an S3 ARN can use the access point ARN wherever they would use a bucket name, as in the aws s3 ls line above. For tools that only accept bucket names, every access point also gets an alias that ends in -s3alias, which you can use in place of the bucket name for object operations. You'll find it in the console or in get-access-point output.

Access points are reached only through virtual-hosted-style URLs, and the S3 console can't use an alias as the source or destination of a Move.

Upload files to Amazon S3: console, CLI and SDK

• ARN: works with the AWS CLI and SDKs.
• Alias ending -s3alias: works where only a bucket name is accepted.
• Virtual-hosted-style addressing only.

VPC-only access points

When you create an access point you can set its network origin to a VPC. Requests through it are then accepted only from that VPC, which is a clean way to give a backend job access to a bucket that nobody can reach through the same door from a laptop. Pair it with a VPC endpoint policy if you also want to restrict which buckets the VPC can reach.

The network origin is fixed. You can't turn an internet access point into a VPC one, or move it to a different VPC; you delete it and create another, and you can reuse the name.

• Network origin: Internet or one VPC, chosen at creation.
• Can't be changed later; delete and recreate.

Limits and settings you can't change

An account can create 10,000 access points per Region, and you can request more. Each access point policy is limited to 20 KB. An access point is attached to exactly one bucket for life, and its VPC configuration and Block Public Access settings can't be changed after creation.

A few operations don't work through access points. An access point can't be a destination for S3 Replication, and the API calls that manage access points themselves, such as PutAccessPoint and GetAccessPointPolicy, don't work across accounts. Names are 3 to 50 lowercase characters, unique per account and Region, and are published in DNS, so keep customer names and project code names out of them.

Amazon S3 replication: SRR and CRR explained

• 10,000 per account per Region, raisable.
• 20 KB per access point policy.
• One bucket per access point, forever.
• Not a replication destination.
• Names are visible in DNS.

When an access point is the wrong tool

Access points solve "who can reach which prefix through which door". They don't give anyone a way to look at the files. A finance analyst with an IAM role scoped to the finance access point still needs the CLI, an SDK, or the AWS console to see a list of files, and none of those preview a PDF or let them share one with an auditor for a week.

If the bucket has two or three readers, a few prefix-scoped statements in the bucket policy are easier to read than three access points. And for one-off access to a single file, a presigned URL is simpler than any policy.

How to create S3 presigned URLs for downloads and uploadsAccess Amazon S3 files without the AWS console

• Many teams, apps or partners on one bucket: access points.
• Two or three readers: prefix statements in the bucket policy.
• One file, short-lived: a presigned URL.

Where BucketDesk fits

BucketDesk works one layer up. You connect a bucket through a CloudFormation role in your account, approve the buckets and prefixes the workspace may see, and people browse, preview, share and upload in a browser without an IAM user or the console. Every action runs with temporary credentials from that role, so the role's policy, your bucket policy and any access point policy you add still decide what's possible. Access points keep each application's door narrow; BucketDesk gives the people a usable room behind theirs.

On the Ultra plan, Document AI lets someone ask an open document a question and get an answer with a page citation, using a Bedrock model in your own account, so the same prefix scoping limits which files it can read.

Customer-owned S3 with CloudFormation: secure accessAccess on the features page