This chapter covers AWS PrivateLink, a service that enables private connectivity between VPCs and AWS services without traversing the public internet. For the DVA-C02 exam, understanding PrivateLink is crucial for questions about secure API access, VPC endpoints, and hybrid networking. Approximately 5-10% of exam questions touch on networking and security topics that involve PrivateLink, making it a high-yield area. You will learn how PrivateLink works, how it differs from VPC peering and VPN, and how to configure it for private APIs.
Jump to a section
Imagine two office buildings in a city: Building A (your VPC) and Building B (a service provider's VPC). Normally, to send a package from A to B, you'd have to use the public street network (the internet), which exposes your package to traffic, delays, and potential snooping. Now, AWS PrivateLink is like constructing a dedicated, private, reinforced bridge directly from Building A's loading dock to Building B's loading dock. This bridge is not accessible from the public streets; only authorized personnel from Building A can use it, and the bridge only connects to the specific service in Building B (e.g., a particular department). The bridge has its own security guards (security groups and network ACLs) that check each package. The key mechanism: the bridge uses a special entry point in Building A called a VPC Endpoint (like a secure doorway with a guard), and the service in Building B is exposed through a Network Load Balancer (NLB) or AWS PrivateLink-powered service (like a designated receiving bay). The bridge is built and managed entirely by AWS; you don't have to lay cables or configure routing yourself. The packages (network traffic) travel through AWS's internal network, never touching the public internet. This ensures low latency, high security, and simplified network architecture.
What is AWS PrivateLink?
AWS PrivateLink provides private connectivity between VPCs, AWS services, and on-premises networks, all within the AWS network. It allows you to access services as if they were directly in your VPC, using private IP addresses, without exposing data to the internet. PrivateLink is the underlying technology for VPC Endpoints (Gateway Endpoints and Interface Endpoints) and AWS PrivateLink-powered services (e.g., SaaS offerings).
Why PrivateLink Exists
Before PrivateLink, connecting VPCs or accessing AWS services required either internet gateway (IGW) with NAT, VPC peering, VPN, or Direct Connect. These methods either exposed traffic to the public internet or required complex routing and overlapping IP address management. PrivateLink eliminates these issues by creating a direct, private connection using AWS's internal network. It also simplifies security: traffic never leaves the AWS backbone, reducing attack surface.
How PrivateLink Works Internally
PrivateLink uses VPC Endpoints (specifically Interface Endpoints) and Network Load Balancers (NLBs) or AWS PrivateLink services to establish connectivity. Here's the step-by-step mechanism:
Service Provider: The service owner creates an NLB in their VPC and registers target instances (e.g., EC2 instances running your API). They then create a VPC Endpoint Service configuration, which associates the NLB with a service name (e.g., com.amazonaws.vpce.us-east-1.vpce-svc-xxxxxxxx).
Service Consumer: The consumer creates a VPC Endpoint of type Interface in their VPC. They specify the service name (from step 1) and the subnets where the endpoint will be created. AWS automatically creates an Elastic Network Interface (ENI) in each specified subnet with a private IP address from the subnet's CIDR.
DNS Resolution: The endpoint generates a DNS name (e.g., vpce-xxxxxx-xxxxxx.vpce-svc-xxxxxx.us-east-1.vpce.amazonaws.com). The consumer can use this DNS name to access the service. Optionally, they can enable private DNS (for AWS services) to override the default DNS name with a private hosted zone (e.g., api.example.com resolves to the endpoint's private IP).
Traffic Flow: When a consumer instance sends traffic to the endpoint's DNS name (or private IP), the ENI receives the traffic. The ENI forwards it through AWS's internal network to the provider's NLB. The NLB distributes traffic to the target instances. The entire path stays within AWS, never traversing the internet.
Security: Security groups on the endpoint ENI control inbound/outbound traffic. The provider's NLB can have security groups on its ENI. Additionally, the endpoint service can have an acceptance required setting: if enabled, the provider must manually accept endpoint connection requests.
Key Components, Values, and Defaults
VPC Endpoint (Interface): Supports TCP traffic only. Supports IPv4 and IPv6. Default: endpoint is created in a single AZ; you can specify multiple subnets for HA. Pricing: per hour per endpoint + per GB data processed.
VPC Endpoint (Gateway): Used only for S3 and DynamoDB. No ENI; uses route table entries. Free of charge.
Network Load Balancer (NLB): Layer 4 load balancer. Must be internal (not internet-facing). Supports TCP, TLS, UDP, TCP_UDP. Cross-zone load balancing is enabled by default.
Endpoint Service: Created from NLB. Supports acceptance required (default: true). Supports adding principals (IAM ARNs) to allow specific consumers without acceptance.
Private DNS: For AWS services, enables automatic DNS resolution to endpoint private IPs. Must be enabled when creating the endpoint.
Endpoint Policies: IAM policies attached to the endpoint control what resources can be accessed through the endpoint. Default: full access.
Configuration and Verification Commands
To create an endpoint service using AWS CLI:
aws ec2 create-vpc-endpoint-service-configuration \
--network-load-balancer-arns arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/net/my-nlb/1234567890abcdef \
--acceptance-required trueTo create an interface VPC endpoint:
aws ec2 create-vpc-endpoint \
--vpc-id vpc-12345678 \
--vpc-endpoint-type Interface \
--service-name com.amazonaws.vpce.us-east-1.vpce-svc-xxxxxxxx \
--subnet-ids subnet-12345678 subnet-87654321 \
--security-group-ids sg-12345678To verify endpoint state:
aws ec2 describe-vpc-endpoints --vpc-endpoint-ids vpce-xxxxxxxxLook for State: available.
Interaction with Related Technologies
VPC Peering: Direct connection between VPCs using private IPs. Unlike PrivateLink, peering is transitive only if explicitly configured; PrivateLink allows one-to-many connections without transitive routing issues.
VPN/Direct Connect: Used for on-premises connectivity. PrivateLink can be combined with these to allow on-premises access to PrivateLink services via private IP (using AWS Transit Gateway or Direct Connect VIFs).
AWS Transit Gateway: Acts as a hub for VPCs and on-premises networks. PrivateLink endpoints can be attached to Transit Gateway for centralized connectivity.
AWS API Gateway: Private API Gateway endpoints use PrivateLink to expose APIs privately within a VPC. This is a common exam scenario: configuring API Gateway with a VPC endpoint for internal access.
Exam-Relevant Details
Traffic Direction: PrivateLink only allows traffic from consumer to provider (one-way). The provider cannot initiate connections to the consumer.
Cross-Region: PrivateLink does not support cross-region endpoints natively. You must use VPC peering or Transit Gateway inter-region peering to connect across regions, then create an endpoint in the same region as the service.
Endpoint Service Availability: The endpoint service must be in the same region as the consumer's VPC endpoint.
Security Groups: On interface endpoints, security groups act as a firewall for traffic to/from the endpoint. They can reference other security groups by ID (not by name).
Endpoint Policies: These are IAM resource-based policies. They can restrict which actions (e.g., S3 GetObject) can be performed via the endpoint. They are separate from the service provider's IAM policies.
Pricing: Interface endpoints incur hourly charges and data processing fees. Gateway endpoints are free but only for S3 and DynamoDB.
Common Pitfalls
Using Gateway Endpoint for non-S3/DynamoDB services: Gateway endpoints only work with S3 and DynamoDB. For other services, you must use Interface endpoints.
Forgetting to enable private DNS: For AWS services like S3, if you create an interface endpoint but don't enable private DNS, you cannot use the standard DNS names (e.g., s3.amazonaws.com) — they still resolve to public IPs. You must use the endpoint-specific DNS name.
Not accepting endpoint connections: If the endpoint service has acceptance required (default), the provider must accept the connection. The consumer will see a 'pending acceptance' state.
Security group misconfiguration: The endpoint's security group must allow inbound traffic from the consumer's instances and outbound traffic to the service. Also, the consumer's instance security group must allow outbound traffic to the endpoint's private IP.
Advanced: PrivateLink with NLB and Target Groups
The NLB used in PrivateLink must be internal (scheme: internal). It can be in the same VPC as the service or in a different VPC (via peering or Transit Gateway). The target group can be instances, IP addresses, or Application Load Balancers (ALB). Using an ALB as a target allows HTTP/HTTPS layer 7 processing behind PrivateLink.
Monitoring and Logging
VPC Flow Logs: Capture traffic to/from endpoint ENIs.
CloudWatch Metrics: For NLB: ActiveFlowCount, NewFlowCount, ProcessedBytes. For endpoint: BytesProcessed, PacketsDropped.
VPC Endpoint Policies: Use IAM Access Analyzer to validate policies.
Summary of Key Defaults
Endpoint type: Interface (default for most services)
Acceptance required: true (for custom endpoint services)
Private DNS: disabled (must be explicitly enabled)
Endpoint policy: default allows all actions on all resources
Security group: default VPC security group (allows all outbound, denies inbound)
NLB scheme: internal (required)
Cross-zone load balancing: enabled by default on NLB
This deep understanding will help you answer exam questions about private connectivity, API Gateway private endpoints, and secure service access.
Create Network Load Balancer
The service provider creates an internal Network Load Balancer (NLB) in their VPC. The NLB must be internal (scheme: internal) and assigned to specific subnets (at least two for high availability). The target group for the NLB points to the instances or IP addresses that host the service (e.g., EC2 instances running the API). The NLB listens on a specific port (e.g., 443 for HTTPS) and forwards traffic to the target group. Cross-zone load balancing is enabled by default, distributing traffic across targets in all enabled Availability Zones. The NLB's DNS name is not used directly; it is referenced by the endpoint service.
Create VPC Endpoint Service
The provider creates a VPC Endpoint Service configuration using the NLB's ARN. They specify whether acceptance is required (default: true). If acceptance is required, the provider must manually approve each connection request from consumers. Optionally, they can add IAM principals (users/roles) that are allowed to create endpoints without acceptance. The service is given a unique service name (e.g., `com.amazonaws.vpce.us-east-1.vpce-svc-xxxxxxxx`). The provider can also add a list of allowed principals (via IAM) for automatic acceptance.
Consumer Creates VPC Endpoint
The consumer creates an Interface VPC Endpoint in their VPC, specifying the service name from the provider. They choose the subnets (at least two for HA) where AWS will create Elastic Network Interfaces (ENIs). Each ENI gets a private IP from the subnet's CIDR. The consumer can attach security groups to the endpoint to control inbound/outbound traffic. They can also enable private DNS if the service is an AWS service (e.g., S3). For custom services, private DNS is not available; they must use the endpoint-specific DNS name.
Provider Accepts Connection (if required)
If the endpoint service has acceptance required, the provider receives a notification (via AWS Console, CLI, or API) of a pending connection. They can accept or reject the connection. Once accepted, the endpoint state changes to 'available'. The consumer can now use the endpoint. If acceptance is not required, the connection is automatically accepted when the consumer creates the endpoint.
Consumer Accesses the Service
The consumer uses the endpoint's DNS name (e.g., `vpce-xxxxxx-xxxxxx.vpce-svc-xxxxxx.us-east-1.vpce.amazonaws.com`) to access the service. This DNS resolves to the private IP addresses of the endpoint ENIs. Traffic from consumer instances to the endpoint ENI stays within the VPC. The ENI forwards traffic through AWS's internal network to the provider's NLB, which then distributes to the target instances. The entire path uses private IPs and does not traverse the internet.
Enterprise Scenario 1: Private API Access for Internal Microservices
A large financial services company runs a microservices architecture across multiple VPCs. They have a central payment processing service (in VPC A) that needs to be accessed by other microservices in VPC B, C, and D. The company cannot use VPC peering because of overlapping CIDRs and the need for non-transitive, one-way access. They deploy PrivateLink: In VPC A, they create an internal NLB pointing to the payment service instances. They then create a VPC Endpoint Service. In VPCs B, C, and D, they create Interface VPC Endpoints pointing to that service. Each microservice now accesses the payment service via the endpoint's private IP. Security groups on the endpoints restrict access to only the specific consumer security groups. The company also implements endpoint policies to ensure that only authorized API actions can be performed. Performance is excellent because traffic stays within AWS. They monitor using VPC Flow Logs and CloudWatch metrics. One common issue they face is misconfigured security groups: if the endpoint's inbound rules don't allow traffic from the consumer's subnet, the connection times out.
Enterprise Scenario 2: SaaS Provider Offering Private Connectivity
A SaaS company offers a data analytics platform to enterprise customers. Their customers require that all data remains within their own VPC and never traverses the internet. The SaaS provider deploys their service in their own AWS account, with an NLB and endpoint service. Each customer creates an Interface VPC Endpoint in their own VPC and connects to the SaaS service. The provider uses acceptance required to manually approve each customer. The provider also uses endpoint policies to restrict each customer to only their own data (e.g., by IAM policy condition on the endpoint). The customers benefit from low latency and high security. The provider must ensure the NLB can handle the aggregate traffic from all customers—they scale the NLB and target instances accordingly. A common mistake is that customers forget to enable private DNS for the endpoint, so they cannot use the standard DNS name; they must use the endpoint-specific DNS name. The provider documents this clearly.
Scenario 3: Hybrid Cloud with On-Premises Access
A company has an on-premises data center connected to AWS via AWS Direct Connect. They want to allow their on-premises applications to access a private API hosted in a VPC (VPC A) without going over the internet. They set up a PrivateLink endpoint in a shared services VPC (VPC B) that is connected to on-premises via Direct Connect and Transit Gateway. The API service in VPC A is exposed via an NLB and endpoint service. The on-premises applications route traffic to the endpoint's private IP (which is reachable via Direct Connect). The traffic flows from on-premises to VPC B's endpoint ENI, then through AWS network to VPC A's NLB. This provides a secure, private connection. The company must ensure that the on-premises routing tables point to the endpoint's IP range. They also need to consider bandwidth limits on the Direct Connect link. Misconfiguration often occurs when the endpoint's security group blocks traffic from on-premises IPs or when the NLB's target group is unhealthy.
What DVA-C02 Tests
The DVA-C02 exam tests your understanding of AWS PrivateLink primarily in the context of Domain 2: Security (Objective 2.1: Implement secure access to AWS services). Specific areas: - VPC Endpoints: Types (Interface vs Gateway), use cases, and limitations. - Private API Gateway: How to configure a private API endpoint using PrivateLink to restrict access to a VPC. - Service Provider/Consumer Model: Understanding who creates what, and the acceptance flow. - Security: Endpoint policies, security groups, and IAM integration. - DNS: Private DNS vs endpoint-specific DNS.
Common Wrong Answers and Why Candidates Choose Them
Using VPC Peering instead of PrivateLink: Candidates often choose VPC peering because they think it's the default for connecting VPCs. However, VPC peering is transitive only if explicitly configured, and it requires non-overlapping CIDRs. PrivateLink is preferred for one-to-many connections and when overlapping CIDRs exist.
Forgetting to enable Private DNS: When asked about accessing an AWS service (e.g., S3) via an interface endpoint, candidates may think the standard DNS name works. They forget that private DNS must be enabled; otherwise, the standard name still resolves to public IPs.
Choosing Gateway Endpoint for non-S3/DynamoDB services: The exam loves to test that Gateway endpoints only support S3 and DynamoDB. Candidates may incorrectly assume all services can use Gateway endpoints.
Assuming PrivateLink works cross-region: PrivateLink endpoints are regional. Candidates may think you can create an endpoint in a different region than the service. Actually, the endpoint and service must be in the same region.
Specific Numbers, Values, and Terms
Endpoint types: Interface (ENI) vs Gateway (route table).
Supported protocols: TCP only for Interface endpoints.
Pricing: Interface endpoints: $0.01 per hour per AZ + $0.01 per GB processed (approx). Gateway endpoints: free.
Default acceptance required: true.
NLB scheme: internal.
Private DNS: must be enabled explicitly.
Edge Cases and Exceptions
S3 and DynamoDB: Can use both Gateway and Interface endpoints. Gateway is free and uses route tables; Interface uses ENIs and costs. The exam might ask when to use each.
Cross-account access: PrivateLink works across accounts. The service provider can allow specific AWS accounts via IAM principals.
On-premises access: Requires routing via Direct Connect or VPN to the VPC where the endpoint resides.
Endpoint policy: Can restrict actions (e.g., only GetObject for S3). This is an IAM resource-based policy.
How to Eliminate Wrong Answers
If the question mentions 'private connectivity between VPCs without internet', think PrivateLink, not VPC Peering (unless it explicitly says 'transitive' or 'non-overlapping CIDRs').
If the service is S3 or DynamoDB and the question mentions 'cost-effective', consider Gateway endpoint first.
If the question mentions 'DNS resolution' and 'standard service endpoint', remember that private DNS must be enabled for Interface endpoints.
If the question involves 'acceptance required', look for the provider side to accept.
Always check the region: if services are in different regions, PrivateLink alone won't work.
PrivateLink provides private connectivity between VPCs and AWS services without traversing the internet.
Interface VPC Endpoints create ENIs in your subnets with private IPs; Gateway Endpoints use route tables and only work with S3 and DynamoDB.
For Interface endpoints, enable Private DNS to automatically resolve standard service DNS names to endpoint private IPs.
Endpoint services require an internal Network Load Balancer (NLB) and have acceptance required by default.
PrivateLink is regional; endpoints and services must be in the same region.
Traffic is one-way: consumer to provider. Provider cannot initiate connections.
Endpoint policies are IAM resource-based policies that control actions allowed through the endpoint.
Security groups on endpoints control inbound/outbound traffic; they can reference other security groups by ID.
These come up on the exam all the time. Here's how to tell them apart.
AWS PrivateLink
One-way connectivity (consumer to provider).
No CIDR overlap restrictions.
Non-transitive; each connection is separate.
Uses Interface VPC Endpoints (ENIs) with private IPs.
Supports service provider/consumer model across accounts.
VPC Peering
Bidirectional connectivity between two VPCs.
Requires non-overlapping CIDR blocks.
Transitive only if using Transit Gateway.
Uses route table entries; no ENIs.
Direct connection; no endpoint service concept.
Mistake
PrivateLink and VPC peering are interchangeable for all scenarios.
Correct
PrivateLink provides one-way, non-transitive connectivity without routing table modifications or CIDR overlap issues. VPC peering requires non-overlapping CIDRs and is transitive only if explicitly set up via a transit gateway. PrivateLink is better for service provider/consumer models.
Mistake
Gateway VPC Endpoints can be used for any AWS service.
Correct
Gateway endpoints only support Amazon S3 and DynamoDB. All other services require Interface endpoints (which use ENIs and incur costs).
Mistake
Interface endpoints automatically resolve standard service DNS names to private IPs.
Correct
You must explicitly enable Private DNS when creating the Interface endpoint. Without it, standard DNS names (e.g., s3.amazonaws.com) still resolve to public IPs.
Mistake
PrivateLink allows bidirectional communication between consumer and provider.
Correct
PrivateLink only supports one-way traffic from consumer to provider. The provider cannot initiate connections to the consumer. For bidirectional, use VPC peering or VPN.
Mistake
You can create a VPC endpoint in a different region than the service.
Correct
VPC endpoints are regional. The endpoint and the endpoint service must be in the same AWS region. Cross-region connectivity requires VPC peering or Transit Gateway inter-region peering.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Gateway Endpoints are free and use route table entries to route traffic to S3 or DynamoDB without leaving the AWS network. Interface Endpoints create an Elastic Network Interface (ENI) in your subnet with a private IP, incurring hourly and data processing charges. Interface Endpoints support many AWS services and custom services via PrivateLink. Gateway Endpoints only support S3 and DynamoDB.
Yes, but indirectly. You create a VPC Endpoint in a VPC that is connected to your on-premises network via AWS Direct Connect or VPN. Then, on-premises hosts can route traffic to the endpoint's private IP (which is reachable via the Direct Connect/VPN connection). The traffic flows from on-premises to the VPC, then through PrivateLink to the service.
No, PrivateLink endpoints are regional. The VPC Endpoint and the Endpoint Service must be in the same region. To connect across regions, you must use VPC Peering (inter-region) or Transit Gateway inter-region peering, then create an endpoint in the same region as the service.
Use IAM policies with conditions like `ec2:CreateVpcEndpoint` and `ec2:VpcEndpointServiceName`. You can also use `aws:SourceVpce` condition key in the service provider's endpoint policy to restrict access to specific endpoints.
The endpoint service has `AcceptanceRequired` set to true (default). The service provider must manually accept the connection request. You must ask the provider to accept the endpoint connection via the AWS Console, CLI, or API.
Yes, but indirectly. You can set the NLB's target group to point to an ALB (as IP targets or instance targets). This allows HTTP/HTTPS layer 7 processing behind PrivateLink. The NLB still handles the PrivateLink connection at layer 4.
The connection to the service is terminated. The ENI is deleted. Any traffic sent to the endpoint's IP will be dropped. The provider's endpoint service will show the connection as 'deleted'.
You've just covered AWS PrivateLink for Private APIs — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?