AWS Scenarios
Private App Access To S3
Design private AWS application access to Amazon S3 using VPC gateway endpoints, IAM roles, endpoint policies, bucket policies, and route tables.
After this, you will understand
This scenario explains one of the most repeated private-network exam patterns: reaching S3 without an internet gateway or NAT device.
Private subnet resources can access S3 through a gateway VPC endpoint by updating route tables and permissions.
Learners think private subnets cannot reach S3, or that NAT is always required for private instances to call AWS services.
Add an S3 gateway endpoint, associate the private route tables, use instance roles, and restrict access with endpoint and bucket policies.
Think before readingWhat is the usual lowest-cost way for private subnet EC2 instances to access S3 without NAT?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Private subnet S3 access
- Gateway VPC endpoints
- Route table endpoint targets
- IAM instance roles
- Endpoint policies
- Bucket policies
- NAT gateway alternatives
- S3 access from VPC
- Private network design
- SAA-C03 endpoint traps
1. Situation
An application runs on EC2 instances in private subnets. It needs to read and write objects in Amazon S3.
The security requirement says the EC2 instances should not have public IP addresses, and the data path to S3 should not require an internet gateway or NAT gateway. The cost requirement says avoid unnecessary managed network appliances when a cheaper native option exists.
This is a classic SAA-C03 scenario. The learner must know that S3 is not inside the VPC, but private VPC resources can still reach S3 through VPC endpoints.
The clean solution is usually an S3 gateway VPC endpoint.
2. Naive Design
The naive design places EC2 instances in private subnets, then adds a NAT gateway so instances can reach S3:
private EC2 -> NAT gateway -> internet gateway path -> S3 public endpoint
This can work for outbound access, but it is not the best answer when the requirement specifically asks for private S3 access or lowest cost for S3/DynamoDB connectivity.
Another naive design moves EC2 instances into public subnets and gives them public IP addresses. That makes S3 access easy, but it violates the security intent. The application compute is now directly reachable if security groups or OS settings are wrong.
A third naive design hardcodes access keys on the EC2 instance. That solves neither network path nor credential hygiene.
3. What Breaks
NAT gateways cost money per hour and per data processing. If private instances only need S3 and DynamoDB, NAT can be unnecessary spend.
Public subnets increase exposure. Even if security groups are restrictive, the architecture has moved private application compute closer to the internet than needed.
Hardcoded credentials can leak. They also create rotation and audit problems.
Bucket policies can also become messy. If you allow broad access from an entire account, the bucket may be reachable from places you did not intend. If you try to use source IP conditions without understanding endpoint behavior, access may break or become weaker than expected.
The deeper issue is mixing three separate questions:
network path: how traffic reaches S3
identity: who is allowed to call S3 APIs
resource policy: which bucket accepts those calls
Each layer needs a correct answer.
4. AWS Architecture
Use a gateway VPC endpoint for Amazon S3.
Create the endpoint in the same Region as the VPC and associate it with the route tables used by the private subnets. AWS adds routes that send S3-destined traffic to the endpoint.
The EC2 instances stay in private subnets. They use an IAM role through an instance profile. The role allows only the required S3 actions on the required bucket and prefix.
Add an endpoint policy when you want to restrict what can be accessed through the endpoint. Add a bucket policy when the bucket should accept requests only from expected principals, VPC endpoints, accounts, or conditions.
The resulting shape is:
private EC2
-> private subnet route table
-> S3 gateway endpoint
-> S3 bucket
No public IP address is required on the instance. No NAT gateway is required for S3 access through the gateway endpoint.
5. Request Or Data Flow
The application calls S3 using the normal AWS SDK and bucket name.
The EC2 instance receives temporary credentials from its instance role. The SDK signs the S3 request with those credentials.
DNS resolves S3 normally for the Region. The private subnet route table contains a route for the S3 prefix list that targets the gateway endpoint. Traffic destined for S3 follows that endpoint route.
S3 evaluates the request. IAM identity policy must allow the role to perform the action. The endpoint policy must allow the request through the endpoint. The bucket policy must not deny the request and may explicitly allow or restrict the expected principal and endpoint.
If all policy layers allow the request and no explicit deny applies, S3 serves the object operation.
6. Security Controls
Use IAM roles for compute. Do not store access keys on instances.
Scope the role to specific actions:
s3:GetObjectfor read pathss3:PutObjectfor write pathss3:ListBucketonly when listing is needed
Scope resources to the bucket and prefix, not *.
Use endpoint policies to restrict which buckets can be accessed through the endpoint. Use bucket policies to restrict access to the expected role, account, or endpoint condition.
Enable S3 Block Public Access unless public access is intentional. Use encryption with S3-managed keys or KMS depending on requirements. If KMS is used, grant the role KMS permissions too.
Security groups must still allow outbound HTTPS traffic. NACLs must allow the relevant traffic path.
7. Resilience Controls
Gateway endpoints are horizontally scaled, redundant VPC components managed by AWS. You do not deploy endpoint instances.
Associate the endpoint with every private route table that needs S3 access. A multi-AZ app can still fail if only one subnet's route table has the endpoint route.
S3 is regional. Create the endpoint in the same Region as the S3 bucket access pattern. If the app accesses buckets in other Regions, understand how endpoint and DNS behavior applies.
Use S3 versioning, lifecycle, replication, or object lock only when the data recovery requirement needs it. The endpoint solves the network path, not object recovery.
Keep NAT if the private app also needs general outbound internet access. The S3 endpoint is not a universal outbound route.
8. Performance Controls
Gateway endpoints avoid NAT processing for S3 traffic and keep the path on AWS-managed networking.
Use multipart uploads for large objects. Use S3 Transfer Acceleration only when the access pattern involves long-distance internet uploads and the requirement supports its cost.
For read-heavy public delivery, CloudFront may be better than private app instances repeatedly serving objects through S3.
For internal app access, avoid forcing S3 traffic through a small proxy tier. Let compute call S3 directly with proper IAM and endpoint controls.
Monitor S3 request metrics, application latency, and errors such as access denied. Many "network" issues are actually IAM, bucket policy, KMS, or endpoint policy issues.
9. Cost Controls
Gateway endpoints for S3 have no additional endpoint hourly charge. This is why they are often preferred over NAT gateways for private S3 access.
NAT gateways still cost money and may be needed for other internet-bound traffic. Do not remove NAT if private instances need patch repositories, external APIs, or services without endpoints.
Endpoint policies and bucket policies cost nothing but reduce blast radius.
S3 request, storage, lifecycle, replication, and data transfer costs still apply. The endpoint does not make S3 storage free.
Use lifecycle rules for logs, temporary files, and old uploads where appropriate.
10. Exam Variants
"Private subnet instances need S3 access without NAT" points to an S3 gateway endpoint.
"Private subnet instances need DynamoDB access without NAT" points to a DynamoDB gateway endpoint.
"On-premises network needs private access to S3" may point to S3 interface endpoints, not a gateway endpoint.
"Restrict bucket access to requests from a specific VPC endpoint" points to a bucket policy condition such as source VPC endpoint context.
"Application needs AWS API access without credentials on disk" points to an IAM role.
"Needs general outbound internet access" may still require NAT, even if S3 uses an endpoint.
11. Common Traps
Do not assume private subnets cannot reach AWS services.
Do not choose NAT gateway as the best answer when the requirement is private S3 access at lowest cost.
Do not forget to associate the endpoint with the correct route tables.
Do not forget IAM. A network path to S3 does not grant permission to objects.
Do not use hardcoded access keys.
Do not confuse gateway endpoints and interface endpoints. S3 supports both, but gateway endpoints are the common VPC-to-S3 private subnet answer.
12. Related Topics
Review VPC Networking Model, Identity Policies vs Resource Policies, and Amazon S3.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.