Understand Amazon S3 Access Points and How to Utilize Them

If you’re juggling data across multiple S3 buckets and looking for a better way to manage who can access what, S3 Access Points might be what you need. They let you create named endpoints that point to your buckets, so you can control access without changing your existing storage layout. You still get the same underlying S3 durability and availability, but with clearer boundaries between different use cases.

Let me walk you through how they work.

What Are Amazon S3 Access Points?

At their core, access points are named network endpoints that attach to your S3 buckets. Instead of relying solely on bucket policies or IAM rules, you can create access points with their own policies. This makes it easier to set up access for different teams, applications, or customers without duplicating complex policies across the board.

Once you create an access point, you can assign it a friendly name and attach a policy that defines what operations are allowed through that endpoint. Your bucket’s core features remain intact, whether you access it directly or through an access point. However, any restrictions you set in the access point policy only apply when requests come through that specific endpoint.

S3 Access Point and IAM

You manage access point permissions through IAM, the same way you handle most AWS permissions. The access point policy sits alongside your bucket policy and IAM user/role permissions, all working together to determine access.

Here’s a straightforward example. This policy grants a specific IAM user permission to read and write objects through an access point:

{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Effect": "Allow",
   "Principal": {
    "AWS": "arn:aws:iam::123456789012:user/username"
   },
   "Action": [
    "s3:GetObject",
    "s3:PutObject"
   ],
   "Resource": "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point/*"
  }
 ]
}

The user username can perform s3:GetObject and s3:PutObject on any object under my-access-point in us-east-1.

You can swap in a role instead of a user if you prefer role-based access:

{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Effect": "Allow",
   "Principal": {
    "AWS": "arn:aws:iam::123456789012:role/my-role"
   },
   "Action": [
    "s3:GetObject",
    "s3:PutObject"
   ],
   "Resource": "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point/*"
  }
 ]
}

Before deploying any policy, AWS recommends running IAM Access Analyzer to check it against security best practices.

Use Cases

Access points shine when you need to isolate different workloads or audiences. Here are some scenarios where they make sense:

Multi-Tenant Applications

If you’re building software where each customer (tenant) stores their own data in S3, you can create a separate access point per tenant. This keeps tenant A from accidentally seeing tenant B’s files, and you can track costs and usage per tenant.

Customer Data Isolation

Similar to multi-tenancy, if you manage data on behalf of your users, an access point per customer lets you enforce distinct permission sets. This scales better than managing dozens of individual IAM policies.

Team-Specific Access

Distributed teams often need access to shared project data but shouldn’t wander into other teams’ storage. Access points let you carve up storage by team boundaries.

Separate API Endpoints

If your application exposes different APIs that each need their own access controls, you can route each API through its own access point. One API can’t peek at another’s data.

Use Cases

Benefits

The main appeal of access points comes down to a few practical points:

• You define access through a named endpoint, which is easier to explain and audit than a maze of bucket policy conditions
• You can monitor which access point is getting traffic, giving you visibility into usage patterns
• You can lock an access point to a specific VPC for additional network isolation

How to Create an Access Point

Head to the S3 console and click the “Access Points” tab. Hit “Create Access Point,” pick your target bucket, give the access point a name, and optionally restrict network access to a VPC. Once it’s live, you use the access point ARN in your applications just like you’d use a bucket ARN, but with the access control you’ve defined.

Granting users access works the same way as with buckets: attach an IAM policy that references the access point ARN, and you’re set.

Access Point Policy vs. Bucket Policy

Your bucket policy controls access to the entire bucket. An access point policy only governs requests that flow through that access point. The key difference is scope: if you want fine-grained control over a specific use case without affecting bucket-wide access, an access point gives you that lever.

Both policies coexist. S3 evaluates them together when a request comes through an access point.

Restricting Access to a VPC

When you create an access point, you can choose to limit it to traffic originating from a specific VPC. This keeps data access within your private network, which is useful for internal-only applications. There’s no charge for the VPC endpoint itself, though standard S3 data transfer rates still apply for any data moving out of the VPC.

Note that the S3 console can’t browse buckets restricted to VPC access points. For those, you’ll need the AWS CLI or SDKs.

S3 Access Point vs. VPC Endpoint

These two get confused sometimes, so let’s be clear:

What they do: An S3 Access Point is about access control and policy-based isolation. A VPC Endpoint (specifically the S3 interface endpoint) creates a private connection between your VPC and S3, so traffic doesn’t traverse the internet.

Network path: Access Points can be internet-accessible or VPC-restricted. VPC Endpoints are purely internal to your VPC. Traffic through a VPC endpoint stays on the AWS network.

Pricing: Access points don’t add extra charges beyond normal S3 operations. VPC Endpoints are billed per hour plus data processing fees.

Wrapping Up

S3 Access Points won’t change how S3 stores your data, but they give you another layer of organization for access control. If you’re managing access for multiple applications, teams, or customers from the same account, access points can simplify your policies and improve visibility.

If you’re comparing this to VPC Endpoints, remember they solve different problems: access points handle permissions, VPC endpoints handle network routing.

A related S3 feature worth knowing: Object Lambda Access Points go a step further — they let you run a Lambda function on the fly when data is retrieved, so you can transform, filter, or redact objects without storing multiple copies.