Control access at the endpoint, not at every bucket
When a VPC reaches an AWS service through a VPC endpoint, there are two places to write the access rule: on the resource (a bucket policy, a queue policy) or on the endpoint the traffic passes through. For a rule that is about where the request came from rather than what the resource is, the endpoint is the better control point.
Why the endpoint wins
Section titled “Why the endpoint wins”- One rule instead of many. A VPC endpoint policy applies to every request that traverses that endpoint. Expressing the same restriction as a bucket policy means writing and maintaining it on every bucket, and remembering it on every bucket created afterwards.
- It fails closed for new resources. A bucket created next week is covered by the endpoint policy the moment its traffic uses that endpoint. It is not covered by a bucket policy nobody has written yet.
- It sits at the boundary you actually care about. The requirement is usually “instances in this VPC may only reach these buckets”, which is a statement about the network path.
Both directions are usually needed
Section titled “Both directions are usually needed”Endpoint policies and resource policies answer different questions and a complete design generally uses both:
- The endpoint policy limits what callers in this VPC may reach through this endpoint — for example, only buckets belonging to your own organisation.
- The resource policy limits who may reach the resource at all — for example, a bucket
policy with
aws:SourceVpcedenying any request that did not arrive through the approved endpoint.
Written together, neither an instance that escapes the VPC nor a principal outside it can get to the data. Written singly, each leaves the other route open.