Private S3 Access Lab

Concepts Covered

• Private S3 access from VPC workloads
• Gateway VPC endpoints
• Route table association
• Endpoint policies
• Bucket policy conditions
• IAM instance roles
• SSE-KMS decrypt authorization
• NAT Gateway cost avoidance
• AccessDenied troubleshooting
• SAA-C03 private access traps

1. Lab Goal

Design a private path from workloads in private subnets to Amazon S3.

The lab goal is to understand that "private access" is not one control. It is a stack:

workload role -> route table -> gateway endpoint -> endpoint policy -> bucket policy -> object permission -> KMS key

You should leave the lab able to explain why a gateway endpoint can remove the need for NAT for supported S3 access, why a bucket policy may restrict access to a specific endpoint, and why encrypted objects can still fail if KMS permission is missing.

2. Scenario Brief

A data processing application runs on EC2 instances in private subnets. The instances read input files from S3 and write processed output to another S3 prefix.

Security does not want S3 traffic to use a public internet path through NAT. Finance also notices NAT data processing charges. The bucket uses SSE-KMS encryption. The platform team wants the bucket to accept access only through the approved VPC endpoint path.

Design the network and policy shape.

3. Architecture Decision Targets

Decide these items:

• Endpoint type: S3 gateway endpoint for supported VPC-to-S3 access.
• Route tables: private subnet route tables associated with the endpoint.
• IAM role: instance profile permissions scoped to required bucket and prefixes.
• Endpoint policy: restrict which buckets or actions the endpoint can reach when required.
• Bucket policy: optionally require the approved endpoint path using endpoint-aware conditions.
• KMS key policy: allow the workload role to decrypt and encrypt as required.
• Cost model: avoid NAT data processing for this S3 path when gateway endpoint requirements fit.

This is a policy-and-routing lab, not a console-memory lab.

4. Design Constraints

Use these constraints:

• Workloads are in private subnets.
• The workloads need S3 access in the same Region.
• The design should avoid NAT for this S3 traffic.
• The bucket should not become public.
• The application uses an IAM role, not static access keys.
• The bucket uses SSE-KMS.
• The design should be testable by a learner reading logs and access errors.

These constraints intentionally include network, identity, resource policy, encryption, and cost signals.

5. Guided Build Plan

Start by drawing the subnet route.

Private subnet route tables should have a route for the S3 prefix list through the gateway endpoint. The instances do not need a route to an internet gateway for this S3 path.

Create or identify the S3 gateway endpoint in the same Region as the bucket. Associate it with the private route tables used by the application subnets.

Attach an IAM role to the workload. Scope it to required S3 actions such as read from the input prefix and write to the output prefix. Avoid broad bucket-wide permissions unless the lab intentionally tests a temporary baseline.

Add an endpoint policy when the organization wants the endpoint itself to permit only specific bucket access. Remember that an endpoint policy is not the only permission check; it is another gate.

Add a bucket policy when the bucket should accept requests only from the expected VPC endpoint or workload principal. Be careful with conditions because they can lock out legitimate administrative or service access if written too broadly.

Finally, check KMS. If objects use SSE-KMS, the role needs KMS permissions and the key policy must allow that use path.

6. Security Review

Use the principle of layered authorization.

The instance role should allow only the required S3 actions. The bucket policy should express bucket-side trust. The endpoint policy should limit what can be reached through the endpoint if the organization requires it. The KMS key policy should authorize key usage for encrypted object reads and writes.

Do not use IAM users or long-lived access keys for the EC2 workload. Do not make the bucket public to make the lab work. Do not assume that "private subnet" means "authorized."

For troubleshooting, identify which layer denies the request. S3 AccessDenied can come from identity policy, bucket policy, endpoint policy, object ownership or ACL edge cases, Block Public Access interactions, or KMS key policy.

7. Resilience Review

A gateway endpoint is a managed regional service construct for supported S3 access. The main resilience task is not operating endpoint instances; it is making sure the route tables that matter are associated correctly.

If workloads run across multiple Availability Zones, confirm that every private subnet route table used by those workloads has the endpoint route. A missing route table association can make one subnet behave differently from another.

Also consider operational resilience. A too-strict bucket or endpoint policy can cause an outage. Changes to endpoint policies can take a few minutes to apply, so build a rollback plan for policy edits.

8. Performance Review

This lab is not about accelerating S3 performance with more EC2 capacity. It is about the correct path.

Large transfers may still need application-level tuning: multipart upload, retry behavior, parallelism, backoff, object key design, and appropriate instance/network capacity.

Do not confuse VPC endpoints with caching. A gateway endpoint gives a private route to S3; it does not cache objects or remove the need to design efficient S3 access patterns.

9. Cost Review

Gateway endpoints for S3 have no additional endpoint charge. NAT Gateways have hourly and data processing costs, so routing heavy S3 traffic through NAT can be unnecessarily expensive when a gateway endpoint satisfies the requirement.

Cost review should also include KMS request cost, S3 request cost, storage class, data transfer patterns, and CloudWatch logs from the application. A private path is not automatically a complete cost strategy.

If the scenario requires access from on-premises, peered VPCs in other Regions, or through Transit Gateway, the endpoint choice may change. That is where interface endpoint considerations can appear.

10. Validation Checklist

Before calling the design complete, answer:

• Does the private subnet route table point S3 traffic to the gateway endpoint?
• Is the endpoint in the same Region as the bucket?
• Does the instance role allow only required S3 actions?
• Does the bucket policy allow the workload and restrict the intended path?
• Does the endpoint policy accidentally block required access?
• Does the KMS key policy allow decrypt and encrypt for the workload role?
• Can the application read, write, and list only what it needs?
• Does the design avoid NAT for supported S3 traffic?
• Is there a rollback plan for policy changes?

11. Exam Connections

SAA-C03 often tests this lab with short wording.

"Private subnet EC2 needs S3 without NAT" points to an S3 gateway endpoint.

"Restrict S3 access to the endpoint path" points to bucket policy conditions and endpoint-aware design.

"AccessDenied on encrypted object despite S3 allow" points to KMS.

"On-premises needs private S3 access" may move the answer away from gateway endpoint toward interface endpoint or another connectivity pattern depending on details.

"Reduce NAT Gateway cost for heavy S3 traffic" points to gateway endpoint when supported.

12. Cleanup And Next Steps

If you implement the lab, remove test buckets, objects, KMS keys created only for the lab, endpoint policies, and unused endpoints when finished. Be careful with KMS key deletion scheduling in real accounts.

Next, review Event-Driven Order Workflow Lab, Private App Access To S3, and S3 Encryption And KMS Key Policy Traps.

Official AWS references:

• Gateway endpoints for Amazon S3
• Gateway endpoints
• Control access using bucket policies
• AWS Well-Architected Framework