Private App Access To S3 — Quick Learn

An EC2 application has no public IP and runs in a private subnet, but it must read and write objects in Amazon S3. The workload should not become public, pay for a general NAT path just to reach S3, or store long-lived AWS keys.

“Private” does not mean disconnected. It means the subnet lacks a direct internet-gateway route. A controlled route can still reach a supported AWS service. The VPC is the application's regional private network containing that subnet and route table.

Tap to exploreOpen diagram

The key mental model is:

route + identity + authorization = successful private S3 request

The endpoint supplies only the route. It does not grant object access.

How The Route Avoids NAT

An S3 gateway VPC endpoint is an AWS-managed route-table target for same-Region S3 traffic from a VPC. It is not an appliance, does not create endpoint network interfaces in subnets, and does not have endpoint security groups.

When the endpoint is associated with a private subnet's route table, AWS adds a route similar to:

The S3 prefix list is an AWS-maintained group of regional S3 IP ranges. When DNS resolves the normal S3 service name, the route table compares the destination IP with its rules. The specific S3 route wins over the broad 0.0.0.0/0 fallback, so the request uses the gateway endpoint instead of NAT.

The order of rows does not decide this; route tables select the most specific matching destination. A request to a public website does not match the S3 prefix list, so it can still use the NAT route. The endpoint provides no general internet access.

Every application subnet that needs this path must use a route table associated with the endpoint. Creating one endpoint does not silently add the route to every route table in the VPC.

Read deeper into prefix-list routing and longest-prefix matching

One Object Read, End To End

Tap to exploreOpen diagram

1. The application asks the AWS SDK to read an object.
2. The SDK obtains rotating temporary credentials from the EC2 IAM role and signs an HTTPS request to the normal regional S3 API.
3. DNS resolves the service name. The route table sees an S3 destination and selects the gateway endpoint.
4. The endpoint policy decides whether that identity, action, and bucket may use this path.
5. S3 evaluates the caller's identity permissions and bucket policy. An applicable allow must exist, and any applicable explicit deny wins.
6. If a customer-managed AWS Key Management Service (KMS) key protects the object, the caller must also be allowed to use that encryption key.
7. If every required layer allows the operation, S3 returns the object through the endpoint path.

A timeout usually points first toward DNS or routing. An AccessDenied response usually means the request reached AWS and an authorization layer rejected it.

The Controls Are Not Duplicates

• IAM role: defines the workload identity and which S3 API actions it may request.
• Route table + gateway endpoint: choose the private network path to S3.
• Endpoint policy: limits use of that endpoint path.
• Bucket policy: decides what the bucket accepts from the resource owner's side. A condition such as aws:SourceVpce can require one endpoint.
• KMS key policy/grants: separately authorize use of the encryption key when applicable.

Restricting a bucket to one endpoint can also block console or administrator workflows that arrive by another path. Test the complete access model before enforcing the deny.

Read deeper into IAM, endpoint, bucket, and KMS policy boundaries

Choose The Path From The Destination

Tap to exploreOpen diagram

• S3 or DynamoDB from a VPC in the same Region → start with a gateway endpoint. These are route-table based and have no endpoint hourly or data-processing charge.
• Another supported AWS API such as Secrets Manager or KMS → commonly use an interface endpoint, which creates private IP addresses in subnets and has endpoint charges.
• Public websites or third-party APIs → NAT gateway or another internet-egress design.
• On-premises systems need private S3 access over VPN or Direct Connect → use an S3 interface endpoint; gateway-endpoint routes do not extend to on-premises networks.

The endpoint does not turn S3 into a mounted filesystem, alter S3 durability, recover deleted objects, or make the bucket public. It changes the network path for supported traffic.

SAA Recognition And Traps

• Private EC2 needs same-Region S3 without NAT cost → S3 gateway endpoint associated with the required route tables.
• No credentials stored on EC2 → IAM role through an instance profile; the endpoint does not supply identity.
• Bucket must accept only one endpoint path → bucket policy using an endpoint-aware condition such as aws:SourceVpce, tested against administration workflows.
• S3 request times out → inspect DNS, subnet route table, and network controls before widening IAM.
• S3 returns AccessDenied → inspect identity, endpoint, bucket, organization, and KMS policies; the network probably reached AWS.

Do not confuse a gateway endpoint with an interface endpoint, assume all AWS services support gateway endpoints, or remove NAT before listing every non-S3 destination the workload still needs.

One-Minute Review

Private EC2 calls normal regional S3 API
↓
IAM role supplies temporary identity
↓
S3 prefix-list route selects gateway endpoint instead of NAT
↓
Endpoint policy + IAM + bucket policy (+ KMS when used) evaluate
↓
Allowed request returns through the private service path

If you remember only one thing: the endpoint provides the road to S3; the policies provide permission to use the destination.