What is a VPC endpoint policy, how does it combine with the caller's IAM policy and the target resource's own policy, and what is it typically used for?

## Where it sits in the evaluation AWS authorises a request by collecting every policy that applies and requiring that at least one allow exists in each *relevant* category, with any explicit deny overriding everything. When a request travels through a VPC endpoint, the endpoint policy joins that set. So for an S3 `GetObject` arriving over an S3 gateway endpoint, three things all have to permit it: the calling principal's identity policy, the bucket policy if the bucket has one, and the endpoint policy. A deny in any of them ends the matter. The consequence people trip over is the direction of power. **An endpoint policy can only narrow.** Writing `"Resource": "arn:aws:s3:::finance-data/*"` with an `Allow` in an endpoint policy does not grant anything to anyone; it merely declares that requests for other resources will not be permitted to pass through this endpoint. If the instance role has no S3 permission, the call still fails. The second consequence is the default. A newly created endpoint carries a full-access policy: ```json { "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" } ] } ``` That is deliberately permissive so the endpoint does not break anything on creation, and it means an endpoint you never edited is providing zero restriction. ## What it is actually for The headline use case is the **data perimeter** — specifically, egress of data to resources you do not own. Consider a compromised or simply misconfigured workload in a private subnet with a legitimate S3 endpoint. Its role permits `s3:PutObject`. Nothing about the network stops it from writing to *someone else's* bucket, because S3 is one global service reached through the same endpoint. Scoping the endpoint policy so only your organisation's buckets are reachable closes that path. Historically this meant listing bucket ARNs, which does not scale. The organisation-aware condition keys make it tractable: ```json { "Statement": [{ "Effect": "Allow", "Principal": "*", "Action": "s3:*", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceOrgID": "o-exampleorgid" } } }] } ``` The mirror-image control uses `aws:PrincipalOrgID` to require that whoever comes through the endpoint belongs to your organisation, which matters more for endpoints that can be reached from beyond a single VPC. A second, narrower use is blast-radius reduction inside an account: an endpoint dedicated to one workload's subnets can be scoped to just that workload's buckets or secrets, so a credential leak in that tier cannot reach the rest. ## Practical limits and gotchas Endpoint policies apply to *requests that go through the endpoint*, and nothing else. A workload that still has an internet route can reach the service publicly and is entirely unaffected by the endpoint policy — the control is only meaningful if the private path is the only path, which is why perimeter designs remove or restrict NAT egress at the same time. Not every service supports endpoint policies on its interface endpoint, and the actions and condition keys that can be used vary by service, so a policy that is syntactically valid may not do what you expect for a less common service. Verify against the specific service rather than assuming parity with S3. Another trap is over-scoping and forgetting the shared dependencies. Locking an S3 endpoint to your own buckets breaks legitimate reads of AWS-owned or vendor-owned buckets — package repositories, Amazon Linux and other OS repository mirrors, and some service artefacts all live in buckets outside your organisation. Teams discover this when instances stop being able to install packages. The fix is a deliberate allow-list of those known third-party sources alongside the organisation condition. Finally, keep it distinct from neighbouring controls. The endpoint's **security group** decides which hosts may open a connection to an interface endpoint; the **endpoint policy** decides which API calls may pass. And a resource policy on the target — a bucket policy conditioned on `aws:SourceVpce` — is the complementary control that says "this data may only be reached through that endpoint". Endpoint policy restricts what leaves through the pipe; the resource-side condition restricts which pipe may reach the data. Mature designs use both, because each covers the direction the other cannot.