Private service connectivity using AWS PrivateLink, Endpoint Services, and a Network Load Balancer
This project demonstrates a secure AWS architecture pattern for exposing services privately across VPC boundaries without traversing the public internet. It uses AWS PrivateLink, an Endpoint Service, and a Network Load Balancer to enable segmented, private-by-default connectivity between service consumers and providers.
Rather than treating connectivity as only a networking task, this project frames it as an architecture decision: reducing attack surface, preserving trust boundaries, and supporting secure cloud modernization.
A private service architecture that simulates secure B2B access across accounts, useful for fintech, healthcare, or internal partner APIs.
Uses PrivateLink (Interface Endpoints), Endpoint Services, NLB, and EC2 for private cross-VPC access
Provider controls access through endpoint approval
- Private service exposure without public endpoints: customer-to-service traffic stays on AWS private networking
- Provider-controlled access: endpoint connections require approval and can be tightly governed
- Reduced attack surface: only the intended service path is exposed
- Clear trust boundaries: customer and provider VPCs remain logically separated
- Secure modernization pattern: supports private connectivity for shared services, partner integrations, and regulated workloads
A Service VPC hosts an internal web application served by an EC2 instance. A Customer VPC accesses that service privately through an Interface VPC Endpoint, which routes to a provider Endpoint Service backed by a Network Load Balancer.
This mirrors real-world requirements in zero-trust and regulated environments where public internet access is not acceptable for internal, partner, or business-to-business service connectivity.
Customer VPC → Interface Endpoint → Endpoint Service → NLB → EC2 (web application)
| Service | Purpose |
|---|---|
| Amazon VPC | Isolated networks for service provider and customer environments |
| EC2 | Hosts the web application and the client used for validation |
| Network Load Balancer | Provider-side private traffic forwarding layer |
| VPC Endpoint Service | Provider control plane for endpoint approvals |
| Interface VPC Endpoint | Customer’s private entry point to the service |
| Route Tables / Subnets | Segmentation and routing by tier |
| Security Groups | Restrict inbound and outbound flows |
Note: An Internet Gateway may be used only for initial EC2 bootstrapping such as package installation. The customer-to-service data path remains private via PrivateLink.
A recommended enhancement is to replace bootstrap and management access with SSM Session Manager and supporting VPC endpoints.
- VPC isolation: separate Service and Customer environments with explicit allowed paths
- PrivateLink-only service access: no public endpoint for the shared service
- Explicit provider access control: endpoint requests must be approved before use
- Minimal exposure: only required service traffic is allowed through the endpoint path
- Auditability: endpoint creation, approval, and configuration changes are visible through the AWS control plane
- Replace public/bootstrap management with SSM Session Manager and VPC endpoints
- Add VPC Flow Logs, CloudTrail, GuardDuty, and Security Hub for visibility and detection
- Tighten security group scope and document allowed source/destination flows explicitly
- Add endpoint policies where appropriate for additional control
| Threat | Risk | Mitigation in this design |
|---|---|---|
| Public exposure of service | Internet scanning or exploitation | No public service endpoint; PrivateLink path only |
| Unauthorized customer access | Data leakage or unintended access | Endpoint approval required; security group restrictions; endpoint policy optional |
| Lateral movement | Compromise spreading across environments | Separate VPCs; segmented routing; limited allowed ports |
| Misconfiguration | Accidental exposure or broken trust boundary | Provider approval gate; validation steps; architecture documentation |
The web server in the Service VPC is launched with a minimal user-data script to install Apache and serve a custom HTML welcome page.
Script: scripts/user_data_webserver.sh
From the Customer EC2, verify that the service is reachable through the endpoint:
curl -v http://<service-dns-or-endpoint-dns>curlsucceeds only after the endpoint connection is approved- Security groups allow only the intended service traffic
- Customer-to-service connectivity does not depend on a public endpoint
- Optional: VPC Flow Logs confirm the traffic path stays within private networking
See the Deployment Guide for step-by-step instructions covering:
- Service VPC with EC2 and Network Load Balancer
- Endpoint Service setup
- Customer VPC and Interface Endpoint creation
- Manual approval and validation with
curl
- You need provider-controlled private access for B2B or partner connectivity
- You want to avoid broad VPC-to-VPC network reach
- You want a private-by-default pattern for regulated or sensitive workloads
- Interface endpoints add hourly per-AZ and data processing costs
- Setup is more complex than simpler connectivity models for small internal use cases
- VPC Peering: simpler, but creates broader network reach
- Transit Gateway: scales well across many VPCs and accounts
- VPN / Direct Connect: useful for hybrid and on-premises integration
Interface endpoints incur hourly and data processing charges per Availability Zone. Clean up resources after testing to avoid unnecessary cost.
- Terminate EC2 instances
- Delete the Interface VPC Endpoint
- Delete the Endpoint Service
- Delete the Network Load Balancer and target group
- Delete VPCs, subnets, route tables, and Internet Gateways created for the project
- Endpoint Services provide strong provider-side control over private service access
- Availability Zone alignment matters for health checks and traffic flow
- Private connectivity patterns are most effective when paired with clear trust boundaries and explicit validation
MIT
Uzo B.