VPC Endpoint Policies Without Explicit Deny Bypass S3 Bucket ACLs

The Trap

VPC endpoint policies for S3 that rely on implicit restrictions without explicit Deny statements, leaving bucket policies enforceable only against internet-routed traffic whilst VPC-routed requests bypass the same controls entirely.

The Default State

AWS creates VPC endpoints with a default policy allowing all S3 actions to all resources: {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":"*","Action":"s3:*","Resource":"*"}]}. Infrastructure engineers typically focus on bucket policies and IAM roles, assuming the VPC endpoint inherits the same restrictions. When teams do customise endpoint policies, they often write Allow statements for legitimate access patterns without adding corresponding Deny rules for prohibited actions. The endpoint policy evaluation happens before bucket policies in the AWS authorisation chain, so an overly permissive endpoint policy can grant access that bucket-level controls intended to block.

The Blast Radius

Applications running inside the VPC can access S3 buckets that should be restricted by bucket policies, IAM conditions, or resource-based controls. The breach appears inconsistent because the same requests fail when routed through internet gateways or NAT instances, making the policy bypass difficult to detect during standard testing. Compliance audits discover that sensitive data buckets marked as “internal access only” or “production environment restricted” are actually reachable from development or shared service VPCs. Data exfiltration, cross-environment contamination, and regulatory violations occur through the VPC endpoint whilst perimeter monitoring tools focused on internet egress miss the internal traffic flow entirely.

The Lead Mechanic Fix

Replace the default endpoint policy with explicit Deny statements that mirror your bucket policy restrictions. Use aws ec2 modify-vpc-endpoint --vpc-endpoint-id vpce-12345678 --policy-document to deploy a policy containing both Allow and Deny statements. Structure the policy with explicit "Effect":"Deny" conditions for prohibited source IPs, invalid VPCs, or restricted principals before any Allow rules. For production S3 buckets restricted to specific environments, add a Deny statement like {"Effect":"Deny","Principal":"*","Action":"s3:*","Resource":"arn:aws:s3:::production-data/*","Condition":{"StringNotEquals":{"aws:PrincipalTag/Environment":"production"}}}. Test both VPC-routed and internet-routed access paths to ensure consistent policy enforcement across all traffic flows.