S3 Access Points for Large Applications

Amazon S3 Access Points are named network endpoints attached to an S3 bucket that simplify managing data access at scale. Each Access Point has its own DNS name, access point policy, and network controls. Instead of writing a single, complex bucket policy that must accommodate every use case, you create separate Access Points for each application, team, or environment. Each Access Point enforces its own permissions and network restrictions, while still operating within the bucket's overall policy.

Before Access Points, managing access to a shared S3 bucket required a monolithic bucket policy. For example, a bucket used by analytics, backups, and a web application needed policy statements for each, often leading to overly permissive policies or complex condition keys. Any change risked affecting other users. Access Points solve this by allowing each consumer to have its own policy, network VPC endpoint, and block public access settings. The bucket policy becomes a simple guardrail (e.g., enforcing encryption), while detailed access control is delegated to Access Points.

When you create an Access Point, S3 generates a unique DNS name in the format {access-point-name}-{hash}.s3-accesspoint.{region}.amazonaws.com. This DNS name resolves to an S3 endpoint that is specific to that Access Point. When a request is made to this endpoint, S3 evaluates the Access Point policy, the bucket policy, and IAM user/role policies. All three must allow the action for the request to succeed. The Access Point policy can use IAM policy conditions such as aws:SourceVpce or aws:SourceIp to restrict network access. Additionally, each Access Point has its own Block Public Access settings, independent of the bucket's settings.

To create an Access Point with the AWS CLI:

aws s3control create-access-point --account-id 123456789012 --bucket my-bucket --name my-app-access-point

To attach a policy:

aws s3control put-access-point-policy --account-id 123456789012 --name my-app-access-point --policy file://policy.json

Example policy.json:

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

To use an Access Point in an S3 operation, you reference the Access Point ARN instead of the bucket name. For example, to list objects:

aws s3api list-objects-v2 --bucket arn:aws:s3:us-east-1:123456789012:accesspoint/my-app-access-point

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
  "Condition": {
    "StringEquals": {
      "s3:AccessPointNetworkOrigin": "VPC"
    }
  }
}

This allows all actions through any Access Point with VPC origin, while blocking direct bucket access.

When an application makes a request to an Access Point, S3 performs the following checks: 1. Is the request reaching the correct Access Point endpoint? (DNS resolution) 2. Does the Access Point policy allow the action for the requesting IAM principal? 3. Does the bucket policy allow the action when accessed via this Access Point? 4. Do the IAM policies allow the action on the Access Point resource? 5. Are the Block Public Access settings satisfied? 6. Are network restrictions (VPC, IP) met?

All conditions must pass. This layered approach provides defense in depth.

A large enterprise runs a shared data lake in a single S3 bucket used by multiple teams: analytics, data science, and machine learning. Each team has different compliance requirements. Analytics data is public-facing, data science data is internal, and ML data must be restricted to a specific VPC. Without Access Points, the bucket policy becomes a tangled mess of conditions and principal ARNs. With Access Points, the team creates three Access Points: analytics-ap (Internet origin, public read), datascience-ap (VPC origin, read-write for specific IAM roles), and ml-ap (VPC origin, restricted to a specific VPC endpoint). Each team uses its own Access Point, and the bucket policy simply allows all actions from any Access Point with VPC origin, plus a separate statement for the analytics Access Point. This simplifies auditing and reduces risk of misconfiguration. In production, the bucket serves 10 TB of data daily; Access Points add negligible latency. A common mistake is forgetting to update the bucket policy to allow the Access Point, resulting in 'Access Denied' errors.

A SaaS company ingests data from customers into an S3 bucket in the company's account. Each customer gets a separate Access Point restricted to their VPC or IP range. The company creates an Access Point per customer with a policy that allows only that customer's IAM role to write objects. The bucket policy includes a statement that allows access from any Access Point, but only if the request comes via a VPC endpoint (using s3:AccessPointNetworkOrigin). This ensures data never traverses the public internet. The company uses AWS PrivateLink to expose the Access Point to customer VPCs. Misconfiguring the VPC endpoint ID or forgetting to attach the VPC endpoint policy can break connectivity. At scale, the company manages hundreds of Access Points; the 1,000-per-bucket limit is a consideration, and they monitor usage to request limit increases.

A financial services firm needs to redact sensitive data (e.g., credit card numbers) before serving objects to certain applications. They create an Object Lambda Access Point that uses a supporting Access Point. The supporting Access Point has a policy that allows only the Object Lambda function to access the bucket. The Object Lambda Access Point is used by the application. This pattern centralizes data transformation without modifying the application code. The firm must ensure the Lambda function has permissions to invoke and access the supporting Access Point. A common pitfall is misconfiguring the Lambda function's IAM role, leading to timeouts or access errors.