Skip to main content
This article explains Amazon S3 Access Points: what they are, why they simplify access management for large shared buckets, how they interact with VPC endpoints, and best practices for policy design. Why this matters
  • When many teams or applications share a single S3 bucket, a single monolithic bucket policy becomes hard to manage.
  • Access Points provide named entry points into the same bucket, each with its own ARN and policy scope, so you can move fine-grained permissions closer to the consumer (team, application, or role).
What is an access point?
  • An access point is a named network endpoint and policy container for a single S3 bucket.
  • Each access point has its own ARN (for example: arn:aws:s3:us-west-2:123456789012:accesspoint/my-access-point) and acts like a separate S3 endpoint you can reference in IAM policies or application configuration.
  • Consumers interact with objects using the access point ARN rather than the bucket ARN, allowing per-consumer policy scoping and network controls.
A diagram titled "Access Points" showing avatars for Developers, Admin, Infra, and Legal on the left, each mapped via arrows/unique ARNs to access-point icons and policy lists. Those access points then point to a central storage bucket on the right.
Key benefits
  • Logical separation: Each team or application can have an access point that encapsulates its permissions.
  • Simpler policies: Keep the bucket policy minimal and place fine-grained grants on access points.
  • Unique ARNs: Access point ARNs can be referenced directly in IAM policies and network configurations (e.g., VPC endpoint policies).
  • Network controls: Restrict access through an access point to specific VPCs or VPC endpoints.
Benefits at a glance Restricting access to specific VPCs
  • Access points can be configured to accept requests only from particular VPCs (via AWS condition keys like aws:sourceVpc or by restricting VPC endpoint connections).
  • Combine access points with S3 VPC endpoints so only resources inside the designated VPC can reach the bucket through that access point.
A diagram titled "Access Point Restricting VPCs" showing two Virtual Private Cloud (VPC) boxes with VPC endpoints, one allowed (green check) and one denied (red cross). Both link to an access point icon which then points to an S3 bucket.
Policy evaluation: what to keep in mind
  • S3 evaluates access by combining all relevant policies: IAM identity policies, access point policy, bucket policy, and any applicable service control policies (SCPs) or organization policies.
  • A deny in any applicable policy results in an overall denial, so the bucket policy must not inadvertently block a request you intend to allow through an access point.
Access points have their own resource policies, but S3 evaluates access using the union of relevant policies (identity, access point, bucket, SCP). For predictable behavior, keep the bucket policy permissive for expected access paths and place fine-grained rules on the access points.
A common, maintainable pattern
  1. Keep the bucket policy minimal — allow (or at least do not deny) requests that come through authorized access points.
  2. Put consumer-specific allow/deny rules on each access point policy.
  3. Use access point ARNs in IAM policies, application code, and VPC endpoint policies to limit scope.
A diagram titled "Access Point Policy" that compares two approaches: copying the same policies to an S3 bucket policy (left) versus delegating policies to the access point (right). It uses bucket and checklist icons with arrows and user/principal symbols to show the two flows.
Example: Delegating access through an access point
  • Bucket policy (minimal) — allows access when the request uses a matching access point ARN:
  • Access point policy (fine-grained) — allow only specific principals and actions:
Warning about evaluation
A deny anywhere in the evaluation chain overrides allows. An access point policy cannot override an explicit deny in the bucket policy or an applicable SCP. Design bucket policies so they don’t block intended access through access points.
When to use a bucket policy vs an access point Best practices
  • Use access points to give each team or application a dedicated ARN and set of permissions.
  • Minimize duplication: delegate access via the bucket policy to access points, then manage details on access-point policies.
  • Use VPC endpoint policies and access point restrictions to keep traffic internal to your VPC where required.
  • Test policy combinations in a non-production account to confirm effective permissions before rolling out.
Additional resources Summary
  • S3 Access Points let you create multiple named entry points into a single bucket, each with its own ARN and policy scope.
  • They simplify permission management and can enforce network restrictions (for example, limiting requests to specific VPCs via VPC endpoints).
  • Always consider the full policy evaluation chain (IAM, access point, bucket, organization policies) when designing access control.

Watch Video