AWS PrivateLink & VPC Peering Comparison
Recap: Where Hybrid DNS Left Us
Day 12 closed the loop on name resolution across the hybrid boundary. Route 53 Resolver inbound endpoints let on-prem resolvers query AWS private hosted zones, while outbound endpoints plus forwarding rules let AWS resources resolve on-prem names over Direct Connect or VPN. That gave us a complete DNS story: names resolve in both directions, and the transport underneath is whatever hybrid link we already built.
Today's topic contrasts with that in an important way. Resolver work is about making two networks that are already connected resolve each other's names — it assumes reachability exists and only fixes the naming layer on top of it. PrivateLink attacks the opposite end of the problem: it deliberately avoids building network reachability at all. There is no route table entry, no CIDR exchange, no peering relationship, and no DNS forwarding rule required to make it work. A consumer reaches a provider's service through an ENI that lives in the consumer's own subnet, and the two VPCs never learn about each other's address space. Where Resolver extends a shared network, PrivateLink refuses to create one.
Foundations You'll Need Today
Today's topic is entirely about how two separate private networks are allowed to talk to each other, and the whole argument hinges on a handful of building blocks that the rest of this page will use without stopping to define them. If you have never built a network in AWS, these are the pieces the discussion assumes you already have in your head.
VPCs and CIDR blocks
A Virtual Private Cloud (VPC) is your own isolated slice of the AWS network — a private space where you launch servers, databases, and other resources, and where nothing from the outside can reach them unless you explicitly allow it. Every VPC is assigned an address range written in CIDR notation, something like 10.0.0.0/16. That notation is just a compact way of saying "this many addresses, starting here": the number after the slash tells you how large the range is, and a smaller number means a bigger range. The practical consequence is that two VPCs can be given the same range, or ranges that partially overlap, and when that happens the addresses inside them become ambiguous — a packet addressed to 10.0.0.5 could belong to either network, and no router can decide which one you meant. Keep that ambiguity in mind, because it is the single constraint that eliminates most of the connectivity options discussed below.
Route tables
Inside a VPC, every subnet has a route table, which is simply a list of rules saying "traffic destined for this address range should go out through this path." When you connect two networks together in the traditional way, the connection only works because you add a rule to each side's route table pointing at the other. This matters today because it is the mechanism PrivateLink deliberately avoids: it never adds a route, so the two networks never gain a general path to each other. When this page says a solution "requires route table changes on both sides," it means you are merging the two networks' routing, which is a much bigger commitment than it sounds.
Security groups and network ACLs
Once traffic can physically reach a resource, two layers of firewall decide whether it is actually allowed in. A security group is a set of allow rules attached to a resource itself — a server, a database, or in today's case a network interface — and it is stateful, meaning if you allow a request in, the response is automatically allowed back out. A network ACL is a coarser filter attached to a whole subnet, and it is stateless, so you have to write rules for both directions. The reason this page keeps warning that "security groups become the only remaining control" is that when two networks are fully connected, these firewalls are the last thing standing between a consumer and everything in the provider's network — and a single mistaken rule is then the entire boundary.
Elastic network interfaces (ENIs)
An elastic network interface is the virtual equivalent of a network card: it is the thing that actually holds a private IP address inside a subnet and that traffic is sent to. A server has one, and so does almost everything else that needs an address. This is worth knowing up front because PrivateLink works by placing an ENI in the consumer's own subnet and having the consumer talk to that ENI — which is why the consumer never needs to know anything about the provider's addresses, and why the endpoint's own security group becomes a place failures can hide.
Load balancers, and the difference between layer 4 and layer 7
A load balancer sits in front of a group of servers and spreads incoming requests across them, so that no single server is overwhelmed and so that a failed server can be taken out of rotation. AWS offers two kinds that matter here. An Application Load Balancer (ALB) understands HTTP — it can route based on URL paths and hostnames, which makes it a layer 7 (application layer) device. A Network Load Balancer (NLB) only understands raw TCP connections and IP addresses, making it a layer 4 (transport layer) device, but it is extremely fast and preserves the original connection. Today's material depends on this distinction because PrivateLink can only be backed by an NLB, and the exam will happily hand you a scenario with an ALB already in place to see whether you notice.
With that grounding, here is why PrivateLink exists and what problem it actually solves — and, just as importantly, when it is the wrong answer.
1. Why This Is on the Exam
PrivateLink shows up on SAP-C02 because it is the answer to a class of scenario that no other connectivity primitive solves cleanly. The exam repeatedly presents a situation where two organizations, or two business units inside one organization, need to share exactly one service and nothing else. The consumer may be a partner company, a SaaS vendor's customer, or an internal team that must not be able to reach the provider's database, its management plane, or any other workload in that VPC. The requirement is almost always phrased as "expose only this API" or "the consumer must not have network-level access to our VPC."
The naive answers — VPC peering, Transit Gateway, or a VPN — all fail that requirement in the same way: they create bidirectional network reachability between the two address spaces. Once peering exists, the consumer can route to any IP in the provider's VPC that its security groups and NACLs permit, and the provider inherits the consumer's routing table as a potential path into its own network. Security groups become the only remaining control, and the exam is designed to make you notice that a single misconfigured rule is now the entire boundary. PrivateLink removes that class of risk structurally rather than configurationally.
The topic maps most directly to Domain 1, Design Solutions for Organizational Complexity, where cross-account and cross-organization connectivity decisions live. It also appears in Domain 2 scenarios about resilient architectures, because endpoint services have their own availability model, and in Domain 4 cost questions, because interface endpoints are billed hourly and per gigabyte while gateway endpoints are free. A candidate who can only recite "PrivateLink is more secure" will lose points on the cost and availability variants; the exam expects you to know when PrivateLink is the wrong answer because it is more expensive and more operationally involved than peering would have been.
2. How PrivateLink Actually Works
The mechanism is worth understanding at the packet level, because every exam distractor is built from a misunderstanding of one of these steps. On the provider side, you create a Network Load Balancer in front of your service and register it as an endpoint service. The NLB is not optional and not interchangeable with an ALB — PrivateLink requires a layer-4 load balancer because the service is exposed at the transport layer, and the consumer's traffic arrives as TCP to a specific port. You then grant permission to specific AWS principals, which can be account IDs, IAM roles, or entire Organizations. That allow-list is the access control plane, and it is evaluated before any packet can flow.
On the consumer side, someone creates an interface endpoint (also called a VPC endpoint of type Interface) in a subnet of their choosing. AWS provisions an elastic network interface in that subnet, with a private IP from the consumer's own CIDR range, and attaches a security group to it. The consumer's application connects to that ENI's IP address or, more commonly, to a Route 53 private hosted zone name that AWS creates automatically for the endpoint. The ENI is the only thing the consumer ever sees; the provider's IP addresses are never exposed and never routable from the consumer VPC.
Underneath, the traffic is carried by the AWS network fabric rather than by any route in either VPC's route table. This is the detail that makes overlapping CIDRs a non-issue: because no route is installed and no address is exchanged, the two VPCs can both use 10.0.0.0/16 without conflict. The ENI in the consumer subnet is a local address from the consumer's perspective, and the mapping from that ENI to the provider's NLB happens inside the AWS-managed PrivateLink data plane. Gateway endpoints work differently and are worth separating early: they are route-table entries with a prefix list as the destination, they exist only for S3 and DynamoDB, and they carry no hourly charge. They are not PrivateLink, even though the console groups them under the same "Endpoints" heading.
3. The Core Decision Boundary
Almost every PrivateLink scenario question reduces to one fork: does the requirement call for service-level exposure or network-level connectivity? If the consumer needs to reach exactly one service and nothing else, PrivateLink is the answer. If the consumer needs to reach many resources across the provider's VPC — a database, a cache, several internal APIs, a bastion — then you are describing network connectivity and PrivateLink is the wrong tool, because you would have to create a separate endpoint service for each thing you want to expose. That is the boundary, and the exam phrases it in terms of "only this service" versus "the whole VPC."
The second-order fork is about address space. If the two sides have overlapping CIDRs, or if either side cannot disclose its addressing to the other, peering and Transit Gateway are off the table entirely and PrivateLink becomes the only viable option regardless of how many services are involved. This is why the overlapping-CIDR scenario is such a common exam setup: it forces the answer without requiring you to weigh the service-level versus network-level tradeoff at all.
| Requirement | PrivateLink | VPC Peering | Transit Gateway |
|---|---|---|---|
| Expose one service to many consumers | Native fit | One peering per pair | Possible but over-scoped |
| Overlapping CIDRs | Supported | Not supported | Not supported |
| Bidirectional network reachability | Not provided | Provided | Provided |
| Route table changes required | None | Both sides | Both sides |
| Consumer count scaling | Thousands of principals | Quadratic peering count | Linear attachments |
| Cross-organization support | Yes, via principal allow-list | Yes, with manual accept | Yes, with RAM sharing |
4. Configuration Modes and Their Tradeoffs
The knobs on an interface endpoint are few, but each one has a cost. The first is which subnets the endpoint's ENIs are placed in. You can select one subnet per Availability Zone, and the endpoint is only as resilient as the set of AZs you choose. Selecting a single subnet gives you a single point of failure for the endpoint itself, independent of the provider's own redundancy. The standard pattern is one subnet per AZ across at least two, ideally three, AZs, which is also what the provider's NLB should be spanning. If the provider's NLB has targets in only two AZs and the consumer's endpoint has ENIs in three, the third ENI has nothing healthy behind it.
The second knob is private DNS. When you enable it, AWS creates a private hosted zone for the service's DNS name and points it at the endpoint's ENIs, so existing application code that calls the public service name resolves to the private endpoint without any code change. This is convenient and it is also a trap: enabling private DNS on an endpoint for a service you also use publicly will redirect all in-VPC traffic for that name to the endpoint, including traffic from resources that were never intended to use it. The exam likes this because it produces a symptom — a previously working public call now failing or being billed differently — that looks like a networking fault but is actually a DNS override.
The third knob is the endpoint policy, an IAM resource policy attached to the endpoint itself. It can restrict which principals can use the endpoint and which resources they can reach through it, which matters when the endpoint is shared across many accounts in an Organization. A permissive endpoint policy combined with a permissive provider allow-list is a common audit finding. The fourth consideration is the endpoint service's acceptance model: you can require manual acceptance of each connection request, or auto-accept within an Organization. Manual acceptance is the safer default for cross-organization exposure and the more operationally expensive one at scale.
5. Sizing, Limits and Quotas
The numbers that matter here are mostly about how many endpoints and connections you can have, and about the cost model, because the exam tests whether you know that interface endpoints are not free. Each interface endpoint is billed per AZ per hour, and data processing is billed per gigabyte in each direction. A service consumed by forty accounts across three AZs is one hundred and twenty endpoint-hours per hour of wall-clock time, before any traffic moves. That is the number that makes PrivateLink the wrong answer in a cost-optimization scenario where peering would have been acceptable.
On the provider side, the endpoint service is backed by a Network Load Balancer, and the NLB's own limits apply: you configure listeners and target groups as usual, and the service inherits the NLB's cross-zone load balancing setting. The number of endpoint services per NLB and the number of principals per service are both bounded, and the exam does not usually test the exact figures — it tests the shape of the constraint, which is that the provider side scales with the number of distinct services exposed, not with the number of consumers. Adding a thousand consumers to one endpoint service is a configuration change; adding a thousand services is a thousand NLBs.
| Dimension | Behavior | Exam implication |
|---|---|---|
| Billing unit | Per endpoint ENI per AZ per hour, plus per-GB processing | Not free; gateway endpoints are |
| AZ coverage | One ENI per selected subnet | Resilience is your choice, not automatic |
| Provider requirement | Network Load Balancer (layer 4) | ALB cannot back an endpoint service |
| Consumer scaling | Principal allow-list, not per-consumer infrastructure | Scales to many accounts cheaply |
| Gateway endpoints | S3 and DynamoDB only, route-table based, no hourly charge | Different mechanism, different cost |
6. Failure Modes and What They Look Like
The most common production failure is an endpoint that exists in fewer AZs than the application uses. The symptom is intermittent: requests from instances in the uncovered AZ fail to connect while requests from other AZs succeed, and the failure rate tracks the load balancer's distribution across AZs rather than any application-level pattern. The first diagnostic move is to compare the endpoint's subnet selection against the consumer application's subnet spread, then against the provider NLB's enabled AZs. Three lists have to agree, and in practice they rarely do after a few months of drift.
The second failure mode is a security group mismatch. The endpoint's ENI has its own security group, which must allow inbound traffic from the consumer application on the service port. This is separate from the provider's NLB security group and separate from the application's own security group. A connection that times out rather than being refused usually means the endpoint ENI's security group is missing the inbound rule; a connection that is refused usually means the provider side is rejecting it, either because the principal is not on the allow-list or because the NLB has no healthy targets. Distinguishing timeout from refusal is the fastest way to bisect the problem.
The third is the private DNS override described earlier, which presents as a name resolving to an unexpected private address. The fourth is a stale connection request: a consumer creates an endpoint, the provider never accepts it, and the endpoint sits in a pending state indefinitely while the consumer's application reports connection failures. The endpoint's state is visible in the console and via the API, and checking it should be the first step whenever a newly created endpoint does not work. The fifth, less common but exam-relevant, is an NLB target group with no healthy targets in one AZ, which produces the same intermittent pattern as the AZ-coverage problem but originates on the provider side.
7. The Operational and SRE Angle
From an SRE perspective, a PrivateLink endpoint is a dependency you own but do not control. The provider can change their NLB configuration, deregister targets, or rotate certificates without any change on your side, and your application will see the effect. That asymmetry argues for treating the endpoint as an external dependency in your SLO model: measure availability and latency at the endpoint boundary, not just at your own service, so that a provider-side degradation is attributed correctly rather than showing up as an unexplained error-rate spike in your own service.
The metrics worth alarming on are the endpoint ENI's packet and byte counters, which tell you whether traffic is flowing at all, and the provider's NLB metrics — ActiveFlowCount, HealthyHostCount, and the target-group level UnHealthyHostCount — which tell you whether the provider side is healthy. A composite alarm that fires only when your own error rate is elevated and the provider's healthy host count has dropped is far more actionable than either signal alone, because it distinguishes "our code is broken" from "our dependency is broken."
The runbook shape follows from the failure modes above. First, confirm the endpoint state is available rather than pending or rejected. Second, confirm the endpoint's AZ coverage matches the application's. Third, confirm the endpoint ENI security group allows the application's source on the service port. Fourth, check the provider's NLB for healthy targets. Only after those four checks should you look at the application itself. Writing that sequence down matters because the instinct under pressure is to start with the application, and the first four checks are cheap and eliminate most causes.
8. Edge Cases and Exam Gotchas
The single most-tested gotcha is that PrivateLink does not provide network-level access. Candidates who have internalized "PrivateLink is the secure option" will select it for scenarios that require reaching a database, a file share, or several services in the provider VPC, and that is wrong. The exam will often include a distractor that says "create a PrivateLink endpoint" in a scenario where the consumer genuinely needs broad access, and the correct answer is peering or Transit Gateway with tight security groups. Read the requirement for the word "only."
The second gotcha is the ALB-versus-NLB distinction. An endpoint service must be backed by a Network Load Balancer. If a scenario describes an existing Application Load Balancer and asks how to expose it via PrivateLink, the answer involves putting an NLB in front of it or using a different exposure mechanism — you cannot register an ALB as an endpoint service directly. This trips people because ALB is the more familiar load balancer and the scenario may not mention the layer-4 requirement explicitly.
The third is the gateway endpoint scope. Gateway endpoints exist only for S3 and DynamoDB, are free, and work by installing a prefix-list route in the subnet's route table. They do not use ENIs, they do not support every service, and they cannot be used from on-premises over a VPN or Direct Connect because the route only exists inside the VPC. A scenario that asks for private S3 access from an on-premises data center needs an interface endpoint, not a gateway endpoint, and that distinction is a recurring exam item. The fourth gotcha is that endpoint policies and provider allow-lists are separate controls that both have to permit the traffic; satisfying one does not satisfy the other.
9. PrivateLink vs. the Services It Gets Confused With
The comparison that matters most is against VPC peering, because both are described as "connecting two VPCs" and they are not the same operation at all. Peering merges two routing domains: after peering, each VPC has a route to the other's CIDR, and reachability is limited only by security groups and NACLs. PrivateLink creates a single service-level path and leaves the routing domains separate. The practical consequence is that peering is the right answer when you need general connectivity and the CIDRs do not overlap, and PrivateLink is the right answer when you need narrow connectivity or the CIDRs do overlap.
Against Transit Gateway, the distinction is about scale and scope. TGW is a hub for many VPCs and on-premises networks, and it is the correct answer when you are building a network topology rather than exposing a service. PrivateLink does not participate in your routing topology at all, which is precisely why it is immune to CIDR conflicts and why it cannot replace TGW for general connectivity. A useful rule: if the question is about topology, think TGW; if the question is about a single API boundary, think PrivateLink.
| Choose | When |
|---|---|
| PrivateLink interface endpoint | One service, many consumers; overlapping CIDRs; no route changes permitted; cross-organization exposure |
| Gateway endpoint | Private access to S3 or DynamoDB from inside a VPC, cost-sensitive, no on-premises requirement |
| VPC peering | General bidirectional connectivity between two non-overlapping VPCs, small number of pairs |
| Transit Gateway | Hub-and-spoke topology, many VPCs, on-premises integration, centralized inspection |
| Route 53 Resolver endpoints | Name resolution across an already-connected hybrid network |
Hands-on Lab: Exposing a Microservice Across Accounts (45 min)
This lab builds a cross-account PrivateLink exposure end to end, deliberately using two VPCs with identical CIDR ranges so that the overlap constraint is demonstrated rather than described. You will need two AWS accounts in the same Organization, or two accounts with the ability to accept a connection request manually. Work through the steps in order; each one produces something the next step depends on.
- In the provider account, create a VPC with CIDR 10.0.0.0/16 and two private subnets in different Availability Zones. Launch a small EC2 instance running a simple HTTP service on port 8080, and confirm you can reach it from within the VPC.
- Create a Network Load Balancer in the provider VPC, internet-facing or internal as your account permits, with one listener on port 8080 and a target group containing the instance. Confirm the target group reports the instance as healthy. Note that an Application Load Balancer will not work here — the endpoint service requires layer 4.
- Create an endpoint service backed by that NLB. Record the service name, which has the form com.amazonaws.vpce.<region>.vpc-endpoint-svc-xxxxxxxx. Do not enable auto-accept yet; you want to observe the manual acceptance flow.
- In the consumer account, create a VPC with the same CIDR, 10.0.0.0/16, and two private subnets in the same two AZs. This is the point of the exercise: the two VPCs are indistinguishable by address, and no peering or TGW attachment between them is possible.
- Create an interface endpoint in the consumer VPC using the provider's service name. Select both subnets so the endpoint has an ENI in each AZ. Attach a security group that allows inbound TCP 8080 from the consumer VPC's CIDR.
- Return to the provider account and accept the pending connection request. Observe that the endpoint in the consumer account moves from pending to available only after this step.
- From an instance in the consumer VPC, connect to the endpoint's DNS name on port 8080 and confirm you receive the provider's response. Then attempt to reach the provider instance's private IP directly and confirm that it fails — this is the service-level boundary in action.
- Break it deliberately. Remove the inbound rule from the endpoint ENI's security group and observe that connections now time out rather than being refused. Restore the rule, then deregister the NLB target and observe that connections are refused instead. Note the difference; it is the fastest diagnostic signal you have.
- Finally, enable private DNS on the endpoint and observe that the service's DNS name now resolves to the endpoint's private addresses from inside the consumer VPC. Consider what would happen if the consumer also needed to reach the same service name over the public internet.
Clean up by deleting the endpoint, the endpoint service, the NLB, and both VPCs. The lab's real output is the diagnostic intuition from step 8: timeout means the consumer-side security group, refusal means the provider side, and a pending endpoint means nobody accepted the request.
Scenario Question Drills (20 min)
Q1. Two companies with overlapping CIDR ranges (both 10.0.0.0/16) need one to consume a specific API hosted in the other's VPC. What connectivity option works despite the overlap?
Q2. A consumer application must reach a provider's database, cache, and three internal APIs. The provider wants to expose all of it with minimal configuration. What is the correct approach?
Q3. You are exposing an internal service via PrivateLink but the service currently sits behind an Application Load Balancer. What must change?
Q4. An on-premises data center needs private access to S3 without traversing the public internet. Which endpoint type is required?
Q5. A consumer's requests to a PrivateLink endpoint time out rather than being refused. Where should you look first?
Q6. A newly created interface endpoint has been in a pending state for an hour and the consumer's application cannot connect. What is the most likely cause?
Q7. A service is consumed by 40 accounts, each with an interface endpoint in three AZs. What is the cost implication compared to VPC peering?
Q8. After enabling private DNS on an interface endpoint, an application that previously called the service's public endpoint starts failing. What happened?
Q9. A consumer's application runs in three AZs but the interface endpoint was created in only one subnet. What symptom should you expect?
Q10. Which statement about gateway endpoints is correct?
Q11. A provider wants to expose a service to any account in their AWS Organization without manually accepting each request. What should they configure?
Q12. A security review finds that a consumer can reach the provider's database after a PrivateLink endpoint was created. What is the most likely explanation?
Q13. Which combination of controls must both permit traffic through an interface endpoint?
Q14. A team needs to expose a service to a partner company in a different AWS Organization, and the partner must not be able to reach anything else in the provider VPC. What is the correct design?
Q15. A provider's NLB has healthy targets in only two AZs while the consumer's endpoint has ENIs in three. What is the consequence?
Peek into Tomorrow
We now have four separate connectivity primitives in hand — Transit Gateway, VPC peering, PrivateLink, and the hybrid DNS layer that sits on top of Direct Connect. Each one was introduced in isolation, with its own decision boundary and its own failure modes, and each one looked like the obvious answer in the scenario that introduced it. That is exactly the problem. On the real exam, the scenario does not announce which primitive it wants; it describes a business constraint and expects you to derive the answer, and the constraints are frequently in tension. A requirement for strict isolation pushes toward PrivateLink, a requirement for broad access pushes toward TGW, and a requirement to avoid CIDR conflicts eliminates peering entirely — but what happens when a single scenario contains two of those constraints at once?
Tomorrow consolidates the whole of Week 2 into a single decision framework, and the open question it has to answer is how these primitives compose rather than compete. Direct Connect resiliency is the sharpest version of that: a single connection is never the right answer, but the correct redundancy pattern depends on whether the second path is another DX connection, a VPN backup, or a different DX location entirely, and each choice has a different cost and a different failure profile. The networking lab exam will force those tradeoffs into explicit choices, which is why this cluster carries so much weight on the exam.
Sources
- AWS PrivateLink — What is AWS PrivateLink?
- Create a service powered by AWS PrivateLink
- Access AWS services through AWS PrivateLink (interface endpoints)
- Gateway endpoints for Amazon S3 and DynamoDB
- Access resources through an endpoint service
- What is VPC peering?
- What is a transit gateway?
- Building a scalable and secure multi-VPC network infrastructure — AWS PrivateLink