Skip to main content
Access Points streamline and secure Amazon S3 bucket access for multiple teams, applications, and workloads. Instead of a single, complex bucket policy, you can create dedicated Access Points—each with its own ARN and resource policy—to manage permissions at scale.
Access Points work with existing S3 features, including bucket ACLs, public access settings, and server-side encryption.

​
The Challenge of Complex Bucket Policies

When you have diverse stakeholders sharing one bucket, the policy can balloon:
TeamRequired PermissionsUse Case
Developerss3:PutObject, s3:DeleteObjectUpload and manage application assets
Infrastructures3:*Full lifecycle, encryption, and logging
Legals3:GetObject, s3:ListBucketCompliance audits and data retrieval
Every change to a team’s access means editing the monolithic bucket policy, which increases the risk of errors and makes audits difficult.

​
Introducing Access Points

With S3 Access Points, you assign each team or application its own “window” to the bucket. Each Access Point:
  • Has a unique ARN (arn:aws:s3:<region>:<account-id>:accesspoint/<name>)
  • Behaves like an independent bucket
  • Carries a tailored resource policy
The image illustrates access points for different roles (Developers, Admin, Infra, Legal) connecting to a central bucket, likely representing a data storage or resource access system.
Clients reference the Access Point ARN instead of the bucket ARN, and permissions live closer to the consumer. For example, developers use the developer-ap Access Point ARN with write/delete privileges, while the legal team uses legal-ap with read-only permissions.

​
Restricting Access by VPC

You can tie an Access Point to a specific VPC Endpoint to enforce network-level boundaries. Bind the Access Point so only resources in your VPC can connect:
The image illustrates a concept of access point restriction for Virtual Private Clouds (VPCs), showing one VPC with access to a resource (indicated by a check mark) and another without access (indicated by a cross mark).
For instance:
  • VPC A: EC2 instances can access via ap-vpc-a.
  • All other VPCs: Traffic is blocked by the endpoint policy.
Ensure your VPC Endpoint policy explicitly grants s3:* actions for the Access Point ARN; otherwise, requests will be denied.

​
Simplifying Policy Management

Instead of embedding every role’s permissions in the bucket policy, you delegate authority to Access Points with a single bucket policy statement:
The image illustrates an "Access Point Policy" with diagrams showing the process of copying policies to a bucket policy and delegating policies to an access point.
  1. Delegate in the bucket policy to allow S3 actions for any Access Point.
  2. Define fine-grained permissions within each Access Point resource policy.
Example: Delegate List and Get operations for all Access Points in the bucket policy: 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DelegateAccessPointActions",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "s3:ListBucket",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:s3:us-west-2:123456789012:accesspoint/*"
        }
      }
    }
  ]
}
Then, move user- or group-specific permissions into each Access Point policy. Example for a developer Access Point: 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/Developer"
      },
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:us-west-2:123456789012:accesspoint/developer-ap/object/*"
    }
  ]
}
With this approach, you only update the bucket policy once. All subsequent permission changes happen at the Access Point level, making management and compliance audits far simpler.

Watch Video