This chapter covers AWS PrivateLink, a service that enables private connectivity between VPCs and SaaS services without traversing the public internet. For the SAA-C03 exam, PrivateLink is a critical topic under Domain 1: Secure Architectures, specifically objective 1.1 (Design secure access to AWS resources). Approximately 5-10% of exam questions touch on PrivateLink, often in scenarios requiring secure, scalable connectivity to third-party services or across VPCs. You must understand when to use PrivateLink over VPC peering, VPN, or AWS Transit Gateway, and how to configure it correctly.
Jump to a section
Imagine two office buildings: one is your company (VPC) and the other is a SaaS provider (service VPC). Normally, to reach the SaaS provider, you'd have to walk through the public street (the internet), which is insecure and congested. PrivateLink builds a private, controlled bridge between the two buildings. The bridge has two endpoints: on your building, a door called a VPC Endpoint (interface endpoint), and on the provider's building, a door called a Network Load Balancer (NLB). The bridge spans a special private corridor within a larger office complex (AWS network). Traffic crossing the bridge never touches the public street. The bridge is managed by a security guard (the PrivateLink service) that ensures only authorized visitors (traffic from your VPC) can enter. Importantly, the bridge is one-way: you enter the provider's building but cannot see the internal layout (IP addresses) of the provider's building. The provider exposes only the specific rooms (services) they want you to access. The bridge also supports multiple tenants: many companies can each have their own private door (endpoint) to the same provider, but each sees only their own authorized rooms. This is analogous to how PrivateLink uses ENIs (elastic network interfaces) in your VPC to connect to an NLB in the provider's VPC across the AWS backbone, without traversing the internet.
What is AWS PrivateLink and Why Does It Exist?
AWS PrivateLink provides private connectivity between VPCs, AWS services, and on-premises networks without exposing traffic to the public internet. It is designed to securely access SaaS applications hosted on AWS or your own services across different VPCs. The core idea is to expose a service in one VPC (the service provider) to consumers in other VPCs (the service consumers) using private IP addresses, eliminating the need for internet gateways, NAT devices, or VPN connections.
PrivateLink solves the problem of securely connecting to third-party SaaS services that run on AWS. Without PrivateLink, you would have to route traffic over the internet or set up complex VPNs. With PrivateLink, the service provider creates a Network Load Balancer (NLB) in their VPC, associates it with a PrivateLink service, and the consumer creates a VPC Endpoint (interface endpoint) in their VPC. Traffic flows entirely within the AWS global network, never leaving the AWS backbone.
How PrivateLink Works Internally
PrivateLink operates at the network layer (Layer 4) using TCP or UDP. The architecture involves two main components: - Service Provider: Creates an NLB (or supports Gateway Load Balancer for GWLB) that fronts the application. The NLB is placed in the provider's VPC. The provider then creates a VPC Endpoint Service, which is a logical construct that exposes the NLB to consumers. - Service Consumer: Creates a VPC Endpoint (of type Interface) in their VPC. This endpoint is an Elastic Network Interface (ENI) with a private IP address from the consumer's subnet. Traffic destined to the service is sent to this ENI, which then traverses the AWS network to the provider's NLB.
When a consumer sends a packet to the endpoint's private IP, the packet is encapsulated and routed over the AWS backbone to the provider's NLB. The NLB then forwards the packet to the target group (e.g., EC2 instances). The response flows back along the same path. The consumer never sees the provider's IP addresses; they only see the endpoint's IP. Conversely, the provider's NLB sees the consumer's traffic coming from the endpoint's IP (or from the NLB's own IP if cross-account), not the original consumer instance IP.
Key Components, Values, Defaults, and Timers
VPC Endpoint (Interface Endpoint): An ENI in the consumer's VPC, with a private IP from the subnet (e.g., 10.0.1.100). It supports TCP and UDP. Maximum transmission unit (MTU) is 1500 bytes. The endpoint is associated with a security group that controls inbound/outbound traffic.
VPC Endpoint Service: Created by the provider, associated with an NLB. It has a service name (e.g., com.amazonaws.vpce.us-east-1.vpce-svc-xxxxxxxx). The provider can accept or reject connection requests from consumers.
Network Load Balancer (NLB): Must be in the same VPC as the provider's application. It uses a listener (e.g., TCP:443) and routes to a target group. The NLB's IP addresses are private and not exposed to consumers.
Default Timeouts: NLB idle timeout is 350 seconds (configurable). The PrivateLink service itself has no specific timeout; connection state is managed by the NLB.
Cross-Account: PrivateLink works across AWS accounts. The provider creates the service and shares it with consumers via AWS RAM (Resource Access Manager) or by accepting connection requests.
Pricing: You pay for the VPC Endpoint per hour and per GB of data processed.
Configuration and Verification Commands
To create a VPC Endpoint Service (provider side) via AWS CLI:
aws ec2 create-vpc-endpoint-service-configuration \
--network-load-balancer-arns arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/net/my-nlb/abcdef123456To create a VPC Endpoint (consumer side):
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-id subnet-12345678 \
--security-group-id sg-12345678To verify connectivity, you can ping the endpoint's private IP (if ICMP is allowed) or use telnet to test TCP port 443.
How PrivateLink Interacts with Related Technologies
VPC Peering: VPC peering connects two VPCs directly, but traffic flows over the AWS backbone. PrivateLink is more secure for exposing specific services because it doesn't require full VPC-to-VPC routing and doesn't expose the entire VPC. For SaaS, PrivateLink is preferred because the consumer only accesses the endpoint, not the provider's entire VPC.
AWS Transit Gateway: Can be used to route traffic between many VPCs. PrivateLink can be combined with Transit Gateway for centralized connectivity, but the endpoint is still per-VPC.
VPN/Direct Connect: On-premises networks can access PrivateLink endpoints via VPN or Direct Connect by routing traffic through the VPC where the endpoint resides. The endpoint must be in a subnet that has a route to the on-premises network.
Gateway Endpoints: For S3 and DynamoDB, gateway endpoints use a different mechanism (route table entries). PrivateLink (interface endpoints) is used for many other AWS services (e.g., API Gateway, Kinesis) and custom SaaS.
Security Considerations
Security Groups: Attached to the VPC Endpoint. Control inbound traffic to the endpoint. Outbound rules control traffic from the endpoint to the service.
Network ACLs: Apply to the subnet where the endpoint ENI resides. They can filter traffic to/from the endpoint.
Endpoint Policies: For AWS service endpoints (not custom), you can attach a policy to control which actions are allowed. For custom PrivateLink services, the provider controls access via acceptance of connection requests.
Data in Transit: Traffic is encrypted if the application uses TLS. The underlying PrivateLink transport is within AWS network, which is private but not encrypted by default.
Performance and Limitations
Bandwidth: Up to 10 Gbps per endpoint, depending on instance type of the consumer's resources.
Latency: Typically single-digit milliseconds within the same region.
Limits: You can have up to 20 VPC endpoints per VPC (default, can be increased). The provider can have up to 20 endpoint services per account (default). Each endpoint service can have up to 1,000 consumer endpoints.
Availability: PrivateLink endpoints are regional. For cross-region access, you need to use VPC peering or Transit Gateway inter-region peering, but PrivateLink itself does not support cross-region endpoints natively.
Common Use Cases
Connecting to SaaS applications like Datadog, Snowflake, or Confluent Cloud, which offer PrivateLink endpoints.
Exposing your own internal services (e.g., a database) to other VPCs in your organization without using VPC peering.
Hybrid architectures where on-premises systems access AWS services via Direct Connect and PrivateLink.
Exam Tips
Remember that PrivateLink uses an NLB on the provider side, not an ALB or CLB. The NLB must be in the same VPC as the service.
The consumer creates an Interface VPC Endpoint (not Gateway).
Traffic stays within the AWS network and does not traverse the internet.
PrivateLink does not support transitive routing: traffic must go directly from the consumer endpoint to the provider NLB. It cannot go through a Transit Gateway to another VPC and then to a PrivateLink endpoint.
The provider can accept or reject connection requests. The consumer can also modify endpoint attributes (like security groups) after creation.
Provider creates NLB and service
The service provider deploys a Network Load Balancer (NLB) in their VPC, configured with a listener (e.g., TCP 443) and a target group pointing to their application instances (e.g., EC2). The NLB is internal-facing (scheme internal) so it only has private IPs. The provider then creates a VPC Endpoint Service configuration via the AWS console, CLI, or API, associating the NLB. This generates a unique service name (e.g., com.amazonaws.vpce.us-east-1.vpce-svc-xxxxx). The provider can optionally add a principal ARN to allow specific AWS accounts to connect automatically, or manually accept connection requests.
Consumer creates VPC Endpoint
The consumer (another AWS account or the same account) creates an Interface VPC Endpoint in their VPC. They specify the service name, the VPC ID, and one or more subnets (one per Availability Zone for high availability). An Elastic Network Interface (ENI) is created in each specified subnet with a private IP from that subnet's range. The consumer must attach a security group to the endpoint to control inbound traffic. The endpoint also gets a DNS name (e.g., vpce-xxxxx-xxxxx.vpce-svc-xxxxx.us-east-1.vpce.aws) that resolves to the endpoint's private IPs.
Connection request and acceptance
When the consumer creates the endpoint, a connection request is sent to the provider's endpoint service. The provider sees the request in the VPC Endpoint Service console. If the provider has not added the consumer's account to the allowed principals, the provider must manually accept the request. Once accepted, the connection state changes to 'Available'. The consumer can then start sending traffic. The provider can also set up automatic acceptance by adding the consumer's account ARN to the allowed principals list.
Traffic flow from consumer to service
The consumer's application sends traffic to the endpoint's DNS name or private IP. The ENI receives the packet and encapsulates it with a VXLAN-like header (AWS internal) and forwards it over the AWS backbone to the provider's NLB. The NLB receives the packet, performs NAT (source IP is replaced with the NLB's private IP, or the endpoint's IP depending on configuration), and forwards it to a healthy target in the target group. The target instance sees the traffic coming from the NLB's private IP (or the endpoint's IP if client IP preservation is enabled on the NLB).
Response flow back to consumer
The target instance sends the response packet back to the NLB. The NLB then sends it back through the AWS backbone to the consumer's endpoint ENI. The ENI delivers the packet to the consumer's application. The entire path stays within AWS network, never traversing the internet. The consumer's security group and NACLs are evaluated at the endpoint ENI. The provider's security groups on the target instances are evaluated at the NLB's target group level.
Scenario 1: SaaS Integration for Security Monitoring
A large enterprise uses Datadog for monitoring. They need to send logs and metrics from their EC2 instances to Datadog's ingestion endpoints. Without PrivateLink, traffic would go over the internet, which is both a security risk and adds latency. The enterprise sets up a PrivateLink connection: they create a VPC Endpoint for Datadog's service name (provided by Datadog). They attach a security group that allows outbound HTTPS to the endpoint's private IP. Datadog's NLB receives the traffic and forwards it to their backend. The enterprise benefits from lower latency (since traffic stays within AWS) and improved security (no internet egress). They also avoid NAT gateway costs for this traffic. Misconfiguration: if the security group on the endpoint blocks outbound traffic, the connection fails. Also, if the enterprise uses a proxy that routes traffic incorrectly, the endpoint's DNS must be resolved correctly.
Scenario 2: Exposing an Internal Database to Multiple VPCs
A company has a central database (e.g., Amazon RDS for PostgreSQL) in a 'shared-services' VPC. They have multiple application VPCs (dev, test, prod) that need to connect to the database. Instead of VPC peering each app VPC to the shared VPC (which creates a mesh and routing complexity), they use PrivateLink. The database is fronted by an NLB in the shared VPC. The NLB's target group points to the RDS instance. The database team creates a VPC Endpoint Service. Each app VPC creates an Interface Endpoint and routes traffic to the database through the endpoint. This isolates the database from direct VPC-to-VPC routing and simplifies security groups. Performance: each endpoint supports up to 10 Gbps. If the database receives many connections, the NLB must be scaled (increase targets). Common pitfall: forgetting to update the database's security group to allow traffic from the NLB's private IPs (or the endpoint's IPs if client IP preservation is off).
Scenario 3: Hybrid Access to SaaS via Direct Connect
A company with an on-premises data center connects to AWS via AWS Direct Connect. They want to use a SaaS application that offers PrivateLink (e.g., Snowflake). They create a VPC Endpoint in a VPC that is connected to the Direct Connect virtual interface. They then advertise the endpoint's IP range (or the VPC's CIDR) over BGP to the on-premises router. On-premises users can now access Snowflake via the endpoint using private IPs, without leaving the AWS network or going over the internet. This reduces latency and improves security. However, they must ensure that the on-premises routes point to the Direct Connect for the endpoint's IP range. If the endpoint's DNS name is used, it must resolve to the private IP, which may require a private hosted zone in Route 53.
What the SAA-C03 Tests on PrivateLink
On the SAA-C03 exam, PrivateLink appears in questions about designing secure, private connectivity to SaaS services or between VPCs. Specific objective: Domain 1.1 - Design secure access to AWS resources. You need to know when to choose PrivateLink over VPC peering, VPN, or AWS Transit Gateway. Key exam scenarios:
Connecting to a third-party SaaS that offers PrivateLink (e.g., Datadog, Snowflake).
Exposing a service in one VPC to multiple consumer VPCs without peering.
Hybrid connectivity: on-premises to SaaS via Direct Connect and PrivateLink.
Common Wrong Answers and Why Candidates Choose Them
VPC Peering: Candidates often select VPC peering because it's a familiar way to connect VPCs. However, VPC peering requires full route table entries and exposes the entire VPC. PrivateLink is more secure because it only exposes the specific service via an endpoint.
AWS Transit Gateway: Transit Gateway is great for hub-and-spoke connectivity, but it does not provide the same isolation as PrivateLink. Also, Transit Gateway does not inherently provide private connectivity to SaaS; you still need an endpoint or peering.
Internet Gateway + NAT: Candidates think that since traffic goes to a SaaS, it must go over the internet. But PrivateLink avoids the internet entirely.
Gateway VPC Endpoint: Gateway endpoints are for S3 and DynamoDB only. For custom SaaS, you need Interface endpoints.
Specific Numbers and Terms on the Exam
The provider must use a Network Load Balancer (NLB), not ALB or CLB.
The consumer creates an Interface VPC Endpoint (not Gateway).
The endpoint is an Elastic Network Interface (ENI) with a private IP.
Traffic stays within the AWS network and does not traverse the internet.
The service is identified by a service name (e.g., com.amazonaws.vpce.region.vpce-svc-xxxx).
Connection requests must be accepted by the provider (or auto-accepted via allowed principals).
PrivateLink does not support transitive routing.
Cross-region PrivateLink is not natively supported; you need inter-region VPC peering or Transit Gateway.
Edge Cases and Exceptions
If the consumer uses a VPC with overlapping CIDR with the provider, PrivateLink still works because the endpoint's IP is from the consumer's subnet, and the provider's NLB IP is private. No overlapping issue.
Client IP Preservation: By default, the NLB preserves the client IP (the endpoint's ENI IP) when forwarding to targets. If you disable it, the target sees the NLB's private IP.
Security Groups: The endpoint's security group controls inbound traffic to the endpoint. The provider's security groups on the NLB targets control inbound from the NLB.
DNS Resolution: The endpoint's DNS name resolves to the private IPs. For on-premises, you need to use Route 53 private hosted zones or custom DNS.
How to Eliminate Wrong Answers
If the question mentions "private connectivity to a SaaS" and the SaaS offers a PrivateLink service, choose PrivateLink.
If the question says "expose a service to many VPCs without peering", PrivateLink is the answer.
If the question involves S3 or DynamoDB, think Gateway Endpoint, not PrivateLink.
If the question mentions "internet" or "public" as an option, it's likely wrong because PrivateLink avoids the internet.
If the question says "transitive" or "hub-and-spoke", Transit Gateway might be mixed in, but PrivateLink does not provide transitive routing.
PrivateLink uses an NLB on the provider side and an Interface VPC Endpoint (ENI) on the consumer side.
Traffic never traverses the public internet; it stays within the AWS global network.
PrivateLink does not support transitive routing; traffic must go directly from endpoint to NLB.
The consumer's endpoint has a security group; the provider's NLB targets have their own security groups.
PrivateLink is regional; for cross-region, combine with VPC peering or Transit Gateway inter-region peering.
The provider must accept connection requests (or auto-accept via allowed principals).
PrivateLink is ideal for connecting to SaaS services that offer it, or exposing internal services to multiple VPCs.
Gateway Endpoints are for S3 and DynamoDB only; do not confuse with Interface Endpoints.
These come up on the exam all the time. Here's how to tell them apart.
PrivateLink
Exposes only a specific service via an endpoint, not the entire VPC.
No need to manage route tables or CIDR overlaps.
Consumer uses an Interface Endpoint (ENI) with private IP.
Traffic flows over AWS backbone, fully private.
Supports cross-account and cross-VPC without transitive peering.
VPC Peering
Connects two VPCs fully, allowing any resource to communicate if routes allow.
Requires non-overlapping CIDR blocks and route table entries.
No endpoints; traffic uses direct routing between VPCs.
Traffic stays within AWS network but may traverse multiple hops.
Does not support transitive routing; each peering is one-to-one.
PrivateLink
Designed for point-to-point service exposure.
No central hub; each consumer has its own endpoint.
Simpler setup for a single service to many VPCs.
No transitive routing; traffic goes directly to service.
Priced per endpoint per hour + data processing.
AWS Transit Gateway
Designed for hub-and-spoke connectivity between many VPCs.
Central hub (Transit Gateway) routes traffic between all attached VPCs.
More complex to set up but scales to many VPCs.
Supports transitive routing (e.g., VPC A to VPC C via Transit Gateway).
Priced per attachment per hour + data processing per GB.
Mistake
PrivateLink can connect VPCs across different regions natively.
Correct
PrivateLink endpoints are regional. To connect across regions, you must use inter-region VPC peering or Transit Gateway inter-region peering, then create a PrivateLink endpoint in the peered VPC. There is no cross-region PrivateLink.
Mistake
PrivateLink requires an internet gateway or NAT gateway.
Correct
PrivateLink does not require any internet gateway, NAT gateway, or VPN. Traffic flows entirely within the AWS backbone, using private IPs. The endpoint ENI is placed in a private subnet.
Mistake
PrivateLink works with any AWS service.
Correct
PrivateLink (Interface Endpoint) works with services that support it (e.g., API Gateway, Kinesis, Sagemaker, and custom SaaS). For S3 and DynamoDB, you must use Gateway Endpoints, not PrivateLink.
Mistake
The provider must use an Application Load Balancer (ALB) for PrivateLink.
Correct
The provider must use a Network Load Balancer (NLB) for PrivateLink. ALB and CLB are not supported. The NLB operates at Layer 4 and can handle TCP/UDP traffic.
Mistake
PrivateLink allows the consumer to access any resource in the provider's VPC.
Correct
The consumer can only access the specific service fronted by the NLB. They cannot reach other resources in the provider's VPC. The endpoint is isolated to that service.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, PrivateLink works across AWS accounts. The provider creates a VPC Endpoint Service and shares it with consumer accounts. The consumer creates an Interface VPC Endpoint using the service name. The provider can accept connection requests or pre-authorize specific accounts. This is a common exam scenario for SaaS services where the provider is a third party.
PrivateLink itself does not extend to on-premises directly. However, if you have an on-premises network connected to AWS via VPN or Direct Connect, you can access a PrivateLink endpoint from on-premises by routing traffic through the VPC where the endpoint resides. The endpoint's private IP must be reachable from on-premises via the VPN or Direct Connect connection.
Interface Endpoints (PrivateLink) are ENIs with private IPs in your subnet, used for many AWS services and custom SaaS. Gateway Endpoints are used only for S3 and DynamoDB; they work by adding a route table entry that points to the service's prefix list. Gateway Endpoints are free but only support S3 and DynamoDB. Interface Endpoints incur hourly and data processing charges.
No. PrivateLink requires a Network Load Balancer (NLB) on the provider side. The NLB operates at Layer 4. If you need Layer 7 features (like HTTP header modification), you can place an ALB behind the NLB, but the NLB must be the endpoint service's front-end.
Create the VPC Endpoint in multiple Availability Zones (subnets) within the same region. Each AZ gets a separate ENI. The endpoint's DNS name resolves to all the ENI IPs, and the consumer can use DNS-based load balancing. The provider's NLB should also be deployed across multiple AZs for redundancy.
Yes, you can modify the security group attached to an Interface VPC Endpoint after creation. This is done via the AWS console, CLI, or API. Changes take effect immediately. This is useful for adjusting access without recreating the endpoint.
Each Interface VPC Endpoint can support up to 10 Gbps of throughput, depending on the instance type of the consumer's resources. The provider's NLB can scale to higher aggregate bandwidth by adding more targets or using larger instances. There is no hard limit per endpoint, but performance is tied to the ENI's capabilities.
You've just covered AWS PrivateLink for SaaS Services — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?