Configuring network access for Amazon S3 access points

When you create an Amazon S3 access point for an FSx for ONTAP volume, you configure how the access point can be reached over the network and who is authorized to use it. This section helps you choose the right network and access control configuration for your environment.

This section covers the network and IAM authorization layers — specifically, the access point's network origin, VPC endpoints, access point policies, VPC endpoint policies, IAM identity policies, and service control policies. For information about file system-level authorization (UNIX and Windows user permissions), see File system user identity and authorization.

How Amazon S3 evaluates access point requests

When a request is made through an Amazon S3 access point attached to an FSx for ONTAP volume, the request must be authorized by all of the following layers:

The network origin check occurs before policy evaluation. The remaining layers are evaluated together as part of the standard IAM authorization decision — an explicit Deny in any layer overrides Allow statements in other layers.

Choosing a network origin

When you create an Amazon S3 access point, you choose a network origin that determines how the access point can be reached. You cannot change the network origin after creation.

Internet origin

An access point with an internet network origin is similar to how S3 buckets are accessed by default. All requests still require valid IAM credentials and authorization — internet origin does not mean public or anonymous access. Amazon S3 enforces Block Public Access on all access points attached to FSx for ONTAP volumes, and you cannot disable this setting.

With internet origin, authenticated requests can come from anywhere — VPCs, on-premises networks, other AWS accounts, or the public internet. You control which authenticated callers are allowed using the access point policy and IAM identity policies.

With internet origin, you control access using the access point policy and IAM identity policies. For same-account callers, use explicit Deny statements in the access point policy to restrict access — an Allow-only policy is not sufficient because the caller's IAM identity policy can independently grant access. For cross-account callers, the access point policy must explicitly Allow the request, so omitting an Allow is sufficient to block access.

VPC origin

An access point with a VPC network origin is bound to a specific VPC and effectively behaves as an explicit Deny policy statement that rejects any request where aws:SourceVpc does not match the bound VPC. Because an explicit Deny always overrides any Allow, even a completely permissive access point policy or IAM identity policy cannot grant access to requests from outside the bound VPC.

Callers outside the bound VPC can still access the access point if their traffic is routed through a VPC endpoint in the bound VPC — for example, via VPC peering or Transit Gateway to an Amazon S3 Interface endpoint deployed in the bound VPC.

Key differences

How VPC origin enforcement works

When an access point has a VPC network origin, it effectively behaves as if there is an explicit Deny policy statement that denies all requests where aws:SourceVpc does not equal the VPC ID specified in the access point's VpcConfiguration. This Deny applies to all principals, all Amazon S3 actions, and all resources within the access point.

Because this is an explicit Deny, it overrides any Allow statements — whether in the access point policy, the caller's IAM identity policy, or any other policy.

In practice, this means:

This is also why the error message for denied requests says "explicit deny in a resource-based policy."

VPC origin vs. internet origin with an explicit Deny

A VPC-origin access point and an internet-origin access point with a manually written StringNotEquals aws:SourceVpc Deny achieve a similar result — both deny requests not from the specified VPC. The key difference is:

Using VPC endpoints with Amazon S3 access points

Amazon S3 access points work with both types of VPC endpoints for Amazon S3. The endpoint type you need depends on where your callers are located.

Gateway endpoints

Gateway endpoints are free and route-table based. When you create a Gateway endpoint, a route is added to the specified route tables that directs Amazon S3 traffic through the endpoint. This route applies only to traffic originating within the VPC.

Use Gateway endpoints for:

Gateway endpoints do not route traffic that enters the VPC from:

For more information, see Gateway endpoints for Amazon S3 in the Amazon VPC User Guide.

Interface endpoints

Interface endpoints create an elastic network interface (ENI) with a private IP address in your subnet. Traffic must be explicitly directed to the endpoint's DNS name or private IP.

Use Interface endpoints for:

When using an Interface endpoint, callers must either:

Interface endpoints have per-hour and per-GB charges. For more information, see AWS PrivateLink pricing.

Using both endpoint types together

You can deploy both a Gateway endpoint and an Interface endpoint in the same VPC. This configuration is useful when you have both in-VPC callers and on-premises callers:

Both endpoint types populate the aws:SourceVpc attribute with the VPC ID, so both satisfy the VPC origin Deny condition.

VPC endpoint policies

VPC endpoint policies control which Amazon S3 resources can be accessed through the endpoint. By default, a VPC endpoint allows all Amazon S3 actions on all resources. You can scope the endpoint policy to allow only specific access points:

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

Access point policies

Amazon S3 access points support AWS Identity and Access Management (IAM) resource policies that allow you to control the use of the access point by resource, user, or other conditions. For cross-account access, both the access point policy and the caller's IAM identity policy must permit the request. For same-account access, either the access point policy or the caller's IAM identity policy can independently grant access — to restrict same-account callers, use explicit Deny statements in the access point policy. If the request traverses a VPC endpoint, the VPC endpoint policy must also permit the request.

For more information about access point policies, see Configuring IAM policies for using access points in the Amazon Simple Storage Service User Guide.

Condition keys for network-based access control

IAM provides global condition keys that you can use in access point policies to control access based on network properties of the request. These condition keys are included in the request context only under specific circumstances, as described in the following table.

For more information about IAM global condition keys, see AWS global condition context keys in the IAM User Guide.

Example scenarios

The following example scenarios show common configurations for Amazon S3 access points attached to FSx for ONTAP volumes. Each scenario includes the recommended network origin, VPC endpoint type, and access point policy.

Single VPC access

Use case: Amazon EC2 instances, Lambda functions, or Amazon ECS tasks within a single VPC access the access point. No external access needed.

With VPC network origin:

The VPC origin configuration effectively denies requests where aws:SourceVpc does not match the bound VPC. Requests from other VPCs, the internet, or on-premises networks are denied. You can use either a Gateway or Interface Amazon S3 VPC endpoint.

Example access point policy (VPC origin): With VPC origin, the network restriction is built in. The access point policy only needs to grant the desired permissions.

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

With Internet network origin:

With internet origin, you restrict access to the VPC using aws:SourceVpc conditions in the access point policy (with an explicit Deny). A VPC endpoint is required so that aws:SourceVpc is populated on the request.

Example access point policy (internet origin): The policy includes both an Allow with a VPC condition and a Deny for requests not from the VPC.

{
    "Version": "2012-10-17", 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::123456789012:role/my-app-role"},
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point",
                "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point/object/*"
            ],
            "Condition": {
                "StringEquals": {"aws:SourceVpc": "vpc-1a2b3c4d"}
            }
        },
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point",
                "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point/object/*"
            ],
            "Condition": {
                "StringNotEquals": {"aws:SourceVpc": "vpc-1a2b3c4d"}
            }
        }
    ]
}

On-premises and VPC access

Use case: Both on-premises users (via VPN or Direct Connect) and in-VPC compute resources access the access point. All traffic stays private.

Both the Gateway endpoint (in-VPC traffic) and Interface endpoint (on-prem traffic) are in the same VPC, so both satisfy the VPC origin Deny condition.

Multi-VPC access

Use case: Callers in multiple VPCs need to access the same access point. For example, applications in separate VPCs within the same account, or VPCs in different accounts that are connected through VPC peering or Transit Gateway.

There are two approaches for multi-VPC access, depending on whether you want to use policy-based controls or the VPC origin network enforcement.

Option 1: Internet origin with a Gateway endpoint in each VPC

Each VPC has its own Amazon S3 Gateway endpoint. Callers in each VPC access the access point through their local Gateway endpoint, which populates aws:SourceVpc on the request. The access point policy restricts access to the allowed VPC IDs.

This option is simpler to set up because each VPC operates independently — no VPC peering or Transit Gateway is required. To add or remove VPCs, update the access point policy.

Option 2: VPC origin with a centralized Interface endpoint

One VPC hosts an Amazon S3 Interface endpoint, and the access point is created with VPC origin bound to that VPC. Other VPCs route their Amazon S3 traffic to the Interface endpoint through VPC peering or Transit Gateway. Because all requests arrive through an endpoint in the bound VPC, they satisfy the VPC origin enforcement.

This option provides stronger enforcement because the VPC origin restriction cannot be bypassed through policy changes. However, it requires VPC peering or Transit Gateway connectivity, and the Interface endpoint has per-hour and per-GB charges. For more information about Interface endpoints, see AWS PrivateLink for Amazon S3 in the Amazon Simple Storage Service User Guide.

Troubleshooting network access issues

When an Amazon S3 access point request fails, the error message often does not indicate which authorization layer denied the request. Use the following guidance to diagnose common issues.

AccessDenied with "explicit deny in a resource-based policy"

This error can come from multiple sources. Work through the following checks in order:

1. Check the VPC origin Deny (VPC-origin access points only)

If the access point has a VPC network origin, it effectively denies requests where aws:SourceVpc does not match the bound VPC. Verify that:

2. Check the VPC endpoint policy

If the request traverses a VPC endpoint, the endpoint's policy must allow the action on the access point resource. The default endpoint policy allows all actions on all resources. If you have scoped the policy, verify it includes the access point ARN.

3. Check the access point policy

Verify that the access point policy allows the requesting principal. Check for Deny statements with conditions that might match the request.

4. Check the caller's IAM identity policy

The caller's IAM role or user must have permissions to perform the Amazon S3 action on the access point ARN.

5. Check service control policies (SCPs)

If the account is part of an AWS Organizations organization, verify that no SCPs deny Amazon S3 actions on the access point.

On-premises callers get AccessDenied but in-VPC callers succeed

This typically means on-premises traffic is not routing through a VPC endpoint:

Access point policy conditions appear to have no effect