AWS VPC Endpoint Policies: S3, DynamoDB, PrivateLink, and Real Examples

What is an AWS VPC endpoint policy?

A VPC endpoint policy is a JSON document attached to a VPC endpoint, not to an IAM principal or to a resource like an S3 bucket. It uses IAM policy language (Version, Statement, Effect, Principal, Action, Resource, Condition) and controls which requests are allowed to pass through the endpoint.

Every VPC endpoint starts with a default policy that allows all actions by all principals on all resources. That default provides connectivity but no additional restriction. When you replace it with a custom policy, you define exactly which principals can perform which actions on which resources through that endpoint.

Simple explanation

In practice: an application running in a private subnet can use S3, but only for one approved bucket through one approved path. If the app tries to reach an S3 bucket in a different account, even one the IAM role technically has access to, the endpoint policy blocks it.

Why this matters

Many compliance frameworks require that traffic between workloads and storage services never leave a private network. An EC2 instance or Lambda function accessing S3 over the public internet, even with encrypted data, may violate data handling requirements or expose traffic to interception risk.

VPC endpoints solve the routing problem by keeping traffic on the AWS backbone. Endpoint policies go further by restricting which resources can be accessed through that private path. This reduces accidental data exfiltration risk: even if an attacker compromises a workload inside your VPC, endpoint policies can prevent them from copying data to an S3 bucket they control.

How it works

When a workload in your VPC makes a request to an AWS service through a VPC endpoint, the request passes through several layers of control:

1. Workload sends request. An EC2 instance, Lambda function, or container makes an API call to an AWS service.
2. Route or DNS resolution. For gateway endpoints, a route table entry directs traffic to the endpoint. For interface endpoints, private DNS resolves the service hostname to a private IP.
3. Endpoint policy evaluation. The VPC endpoint checks whether the request matches the attached policy. If the policy does not allow the action, the request is denied here.
4. IAM policy evaluation. AWS checks whether the calling principal’s IAM policies allow the action.
5. Resource policy evaluation. If the target service has a resource-based policy (like an S3 bucket policy), that policy is also evaluated.

The request succeeds only if all applicable controls allow it. No single policy can override a deny from another layer.

Gateway vs interface endpoint policies

AWS offers two types of VPC endpoints, and their policy behavior differs in important ways.

For more on how PrivateLink works with interface endpoints, see the PrivateLink overview.

When to use this

Endpoint policies are most useful when you need to restrict what a private workload can reach through a specific network path. Common scenarios include:

• Restrict an application to one S3 bucket. A processing pipeline in a private subnet should only read from and write to its own bucket, not any other bucket in the account or in other accounts.
• Restrict private workloads to a small set of DynamoDB tables. A microservice that only needs the orders and products tables should not be able to scan every table in the account through the endpoint.
• Privately access KMS or Secrets Manager. Workloads in private subnets that need to encrypt data or retrieve secrets can use interface endpoints with policies that restrict access to specific keys or secrets.
• Reduce exfiltration paths. Even if a workload is compromised, a restrictive endpoint policy prevents it from copying data to an attacker-controlled S3 bucket or DynamoDB table in another account.
• Meet compliance requirements. Some regulatory frameworks require network-level controls in addition to identity-based controls. Endpoint policies satisfy this layer.

When endpoint policies are not enough

An endpoint policy controls traffic flowing through one specific endpoint. It does not protect traffic that takes a different path (through an internet gateway, a different endpoint, or VPC peering) and it cannot enforce controls on the target resource itself. You still need:

• Least-privilege IAM policies. Endpoint policies are a safety net, not a replacement. The IAM policy on each principal should already follow least privilege. See the IAM access denied troubleshooting guide if policy interactions produce unexpected denies.
• Resource-based policies. An S3 bucket policy can enforce that all access must come through a specific VPC endpoint using the aws:SourceVpce condition. Without this, someone accessing the bucket from outside your VPC bypasses the endpoint policy entirely.
• Service control policies (SCPs). In multi-account environments, SCPs set organization-wide guardrails. They operate at the account or OU level and are evaluated before endpoint policies.

VPC endpoint policy vs IAM policy vs bucket policy vs SCP

Example: S3 gateway endpoint policy

This policy restricts an S3 gateway endpoint so that only specific actions on one bucket are allowed. All other S3 access through this endpoint is denied.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificBucketOnly",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::company-app-data",
        "arn:aws:s3:::company-app-data/*"
      ]
    }
  ]
}

This policy allows GetObject, PutObject, and ListBucket on the company-app-data bucket. Any attempt to access a different bucket, including attacker-controlled buckets in other accounts, is denied at the endpoint.

Notice that Principal is "*". Gateway endpoint policies require this. To scope access to specific IAM roles, add a condition:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificRoleOnly",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::company-app-data",
        "arn:aws:s3:::company-app-data/*"
      ],
      "Condition": {
        "ArnEquals": {
          "aws:PrincipalArn": "arn:aws:iam::123456789012:role/app-processing-role"
        }
      }
    }
  ]
}

This version restricts the endpoint to a single IAM role using the aws:PrincipalArn condition. Only the app-processing-role can use this endpoint to reach S3.

Complementary S3 bucket policy using aws:SourceVpce

An endpoint policy only controls traffic that flows through the endpoint. To enforce that all access to a bucket must come through the endpoint, add a bucket policy with a deny condition. Learn more about IAM policy conditions for details on how condition keys work.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessNotFromVPCEndpoint",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::company-app-data",
        "arn:aws:s3:::company-app-data/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-0a1b2c3d4e5f67890"
        }
      }
    }
  ]
}

This bucket policy denies all S3 actions on company-app-data unless the request arrives through the specified VPC endpoint. Combined with the endpoint policy above, you get two-layer control: the bucket rejects non-endpoint traffic, and the endpoint restricts which buckets are reachable.

Example: DynamoDB gateway endpoint policy

This policy restricts a DynamoDB gateway endpoint to allow only specific operations on two tables.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificTablesOnly",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:Query",
        "dynamodb:UpdateItem"
      ],
      "Resource": [
        "arn:aws:dynamodb:us-east-1:123456789012:table/orders",
        "arn:aws:dynamodb:us-east-1:123456789012:table/products"
      ]
    }
  ]
}

This allows GetItem, PutItem, Query, and UpdateItem on the orders and products tables only. Attempts to access any other table, or to perform other operations like Scan or DeleteTable, are denied at the endpoint. The IAM policy on the calling role must also allow these actions for requests to succeed.

Example: interface endpoint policy

Not all services that support interface endpoints also support endpoint policies. Before writing a policy, check whether the service supports it:

aws ec2 describe-vpc-endpoint-services \
  --service-name com.amazonaws.us-east-1.secretsmanager \
  --query "ServiceDetails[*].VpcEndpointPolicySupported"

If the result is true, you can attach a custom policy. Here is an example for a Secrets Manager interface endpoint that restricts access to secrets with a specific prefix:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificSecrets",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/app/*"
    }
  ]
}

This policy allows the endpoint to be used only for retrieving secrets whose names start with prod/app/. Any other Secrets Manager call through this endpoint is denied.

How to verify your policy is working

After creating or modifying an endpoint, verify that it is correctly configured and that your policy produces the expected allow and deny behavior.

Describe the endpoint

aws ec2 describe-vpc-endpoints \
  --vpc-endpoint-ids vpce-0a1b2c3d4e5f67890 \
  --query "VpcEndpoints[*].[VpcEndpointId,ServiceName,State,PolicyDocument]"

Confirm that the state is available and that the policy document matches what you expect.

Confirm route table associations (gateway endpoints)

aws ec2 describe-vpc-endpoints \
  --vpc-endpoint-ids vpce-0a1b2c3d4e5f67890 \
  --query "VpcEndpoints[*].RouteTableIds"

Verify that the route tables for the subnets your workloads run in are listed. If a subnet’s route table is missing, traffic from that subnet will not use the endpoint. See the route tables guide for more on how route table associations work.

Confirm DNS and security groups (interface endpoints)

For interface endpoints, confirm that private DNS is enabled (if desired) and that the security group allows inbound HTTPS (port 443) from your workload subnets.

aws ec2 describe-vpc-endpoints \
  --vpc-endpoint-ids vpce-0a1b2c3d4e5f67890 \
  --query "VpcEndpoints[*].[PrivateDnsEnabled,Groups]"

Test an allowed action

aws s3 ls s3://company-app-data/ --region us-east-1

This should succeed if the endpoint policy, IAM policy, and bucket policy all allow the action.

Test an expected deny

aws s3 ls s3://some-other-bucket/ --region us-east-1

This should fail with an access denied error if the endpoint policy restricts access to company-app-data only. If the command succeeds, traffic may not be routing through the endpoint. Check the route table or DNS resolution. For help interpreting access denied errors, see the IAM access denied troubleshooting guide.