Building blocks
Design goal
Keep supported AWS service traffic on private connectivity paths without creating unnecessary shared-routing or DNS dependencies.
Architecture
Gateway endpoints provide route-table based private access to supported services such as S3 and DynamoDB, while interface endpoints use private IP addresses and PrivateLink for many other services.
Architecture decisions
Choose endpoint type by service and access path
WhyGateway and interface endpoints have different reachability, DNS, and cost characteristics.
Trade-offPrivate endpoints can reduce internet/NAT use, but interface endpoints add hourly and data-processing cost while gateway endpoints have different routing constraints.
Centralize only when it improves operations
WhyShared endpoint patterns can reduce duplication but add routing and DNS dependencies.
Trade-offShared endpoints reduce duplication, but centralization introduces additional routing, DNS, ownership, and failure dependencies.
Networking
Make the traffic path explicit. Use route-table and DNS design appropriate to gateway versus interface endpoints; validate cross-VPC and on-premises access requirements before centralizing.
Security
Protect the control and data paths deliberately. Use endpoint policies where supported, security groups on interface endpoints, private DNS intentionally, and least-privilege IAM and bucket policies.
Availability
Design for the failure domain that must be survived. Deploy interface endpoints across required AZs when resilient private access is needed.
Disaster recovery
Treat regional recovery as a separate operating state. For multiregion designs, recreate required endpoints and DNS/routing dependencies in the recovery region.
Cost drivers
- Interface endpoint hourly charges
- endpoint data processing
- cross-AZ traffic
- NAT savings
Design assumptions
- Target AWS services are identified
- DNS behavior is understood
- Routing model is documented
Implementation plan
- Inventory which AWS services private workloads must reach and decide whether each requires an interface endpoint, gateway endpoint, or another private path.
- Place interface endpoints in the subnets and security groups that match the consumer networks; attach gateway endpoints to only the required route tables.
- Enable and validate private DNS where service-name resolution should return endpoint addresses inside the VPC.
- Use endpoint policies and resource policies together where supported so private connectivity does not become unrestricted authorization.
- Validate DNS and packet paths, then remove unnecessary NAT or internet dependencies only after every required service path has been proven.
Validate the design
- Resolve the service hostname from a private workload and confirm it returns the intended endpoint path.
- Trace or observe the connection and confirm it does not use NAT or an internet path when private access is required.
- Attempt an action denied by the endpoint/resource policy and confirm connectivity alone does not grant authorization.
- Disable or remove the endpoint in a controlled test and confirm the resulting dependency/failure mode is understood.