TopolearnPrivateLink connects services without routing whole networks together, which sidesteps overlapping CIDRs and shrinks the attack surface.
AWS PrivateLink provides private, one-directional connectivity to a service rather than to a network.
Consuming AWS services: an interface VPC endpoint for, say, com.amazonaws.eu-west-1.sqs creates an ENI with a private IP in each subnet you choose. With private DNS enabled, the normal hostname sqs.eu-west-1.amazonaws.com resolves to those private IPs inside the VPC, so SDKs work unchanged and traffic never needs a NAT or internet gateway. Endpoints have security groups (allow 443 from your workloads) and endpoint policies that restrict which actions and resources can be used through them.
Providing your own service: put it behind a Network Load Balancer and create an endpoint service. Consumers in other VPCs or accounts create interface endpoints to its service name; you control which principals may connect and can require manual acceptance. Traffic is consumer-initiated only, the provider never sees the consumer's network, and overlapping CIDRs don't matter because nothing is routed between the VPCs. This is how most SaaS vendors offer private connectivity.
Trade-offs and details:
- Billed per endpoint per AZ-hour plus per GB; dozens of endpoints in many VPCs add up, so larger organisations centralise them in a shared VPC.
- Gateway endpoints remain the free option for S3 and DynamoDB within a VPC.
- Match AZs: a consumer endpoint can only use AZs where the provider's NLB has capacity, and AZ names differ per account, so compare AZ IDs.
- VPC Lattice offers an application-layer alternative for service-to-service traffic, with auth policies and HTTP routing.
Example
# Consumer: private access to SQS from isolated subnets
aws ec2 create-vpc-endpoint --vpc-endpoint-type Interface --vpc-id vpc-app \
--service-name com.amazonaws.eu-west-1.sqs \
--subnet-ids subnet-priv-a subnet-priv-b --security-group-ids sg-endpoints \
--private-dns-enabled
# Provider: publish an NLB-fronted service
aws ec2 create-vpc-endpoint-service-configuration --acceptance-required \
--network-load-balancer-arns "$NLB_ARN" \
--query ServiceConfiguration.ServiceName --output text
# com.amazonaws.vpce.eu-west-1.vpce-svc-0a1b2c3d4e5f67890
aws ec2 modify-vpc-endpoint-service-permissions --service-id vpce-svc-0a1b2c3d4e5f67890 \
--add-allowed-principals arn:aws:iam::444455556666:root
# Consumer account connects; provider accepts
aws ec2 create-vpc-endpoint --vpc-endpoint-type Interface --vpc-id vpc-partner \
--service-name com.amazonaws.vpce.eu-west-1.vpce-svc-0a1b2c3d4e5f67890 \
--subnet-ids subnet-x subnet-y --security-group-ids sg-x
aws ec2 accept-vpc-endpoint-connections --service-id vpce-svc-0a1b2c3d4e5f67890 \
--vpc-endpoint-ids vpce-0123456789abcdef0Remember
- Interface endpoints are ENIs with private IPs; private DNS keeps hostnames unchanged
- Endpoint services expose an NLB-fronted service to other accounts
- Consumer-initiated and not routed, so overlapping CIDRs are fine
- Costs are per endpoint-AZ-hour plus data; centralise when many VPCs need them
Watch out for
- Enabling an interface endpoint without allowing 443 from workloads in the endpoint's security group.