VPC endpoints, PrivateLink and peering: SOA-C03 study notes and practice questions
What to know about VPC endpoints, PrivateLink and peering for the SOA-C03 exam, from the Networking and Content Delivery domain (18% of the exam guide), then 2 free questions to test it. Part of the SOA-C03 study guide.
These questions ask how to reach AWS services or other VPCs without the internet, and why a private connection doesn’t work.
VPC endpoints
Gateway endpoint
Interface endpoint (PrivateLink)
Services
S3 and DynamoDB only
Most AWS services, plus your own and partner services
How
A route in the route table (prefix list)
ENIs with private IPs in your subnets
Cost
Free
Per hour per AZ plus per GB
From on premises or peered VPCs
No
Yes
Security
Endpoint policy
Endpoint policy and security groups
Private DNS on an interface endpoint makes the normal service name (such as ssm.us-east-1.amazonaws.com) resolve to the endpoint’s private IPs. It needs enableDnsSupport and enableDnsHostnames on the VPC.
Endpoint policies limit what can be done through the endpoint; bucket policies with aws:SourceVpce require that requests use it.
Sharing your own service
AWS PrivateLink: put the service behind a Network Load Balancer (or Gateway Load Balancer), create an endpoint service, and consumers in other VPCs or accounts create interface endpoints to it. Only that service is exposed, not the network, and overlapping CIDRs don’t matter.
Connecting VPCs
Option
Notes
VPC peering
One-to-one, no transitive routing, no overlapping CIDRs, works across accounts and Regions; update both route tables and security groups
Transit Gateway
Hub for many VPCs, VPNs and Direct Connect; route tables on the transit gateway control which attachments reach which; supports inter-Region peering
VPC sharing (RAM)
Several accounts use subnets in one VPC
Amazon VPC Lattice
Service-to-service connectivity across VPCs and accounts at the application layer
Common traps
Interface endpoint without private DNS while the application uses the default service name: traffic still tries the internet.
Peering expected to be transitive.
Endpoint security group not allowing HTTPS (443) from the clients.
A logistics broker runs a rate-quoting service in its own VPC and wants to offer it privately to 30 partner companies, each with its own AWS account and VPC.
Several partner VPCs use the same CIDR range as the broker's VPC.
Partners must reach only the quoting service, not the rest of the broker's network, and traffic must not cross the internet.
What should a CloudOps engineer do?
Choose one answer.
AA. Create a VPC peering connection with each partner VPC and add routes to the quoting service's subnet.
BB. Put the service behind a Network Load Balancer, create a VPC endpoint service, and let each partner create an interface endpoint to it.
CC. Attach all partner VPCs to a transit gateway in the broker's account and share it with the partners through AWS RAM.
DD. Expose the service through a public Network Load Balancer and allow only the partners' NAT gateway addresses in its security group.
Show the answer and explanation
Answer: B
A. Wrong: VPC peering cannot connect VPCs with overlapping CIDR ranges. It also opens network-level paths to the broker's VPC instead of exposing a single service. Learn more: What is VPC peering? (opens in a new tab)
B. Right: Correct. AWS PrivateLink exposes one service through an endpoint service, and consumers reach it through interface endpoints in their own VPCs. Overlapping CIDR ranges do not matter, and partners cannot reach anything else. Learn more: Share your services through AWS PrivateLink (opens in a new tab)
AWS PrivateLink is the way to share a single service privately with many VPCs. The provider places the service behind a Network Load Balancer and creates an endpoint service, and each consumer creates an interface endpoint. Traffic stays on the AWS network, overlapping CIDR ranges are fine, and no wider network access is opened.
Partners reach only the service behind the load balancer, and overlapping CIDR ranges do not matter.
A pet insurer created an interface VPC endpoint for AWS Secrets Manager in its application VPC and selected the option to turn on private DNS.
Flow logs and NAT gateway metrics show that application calls to secretsmanager.us-east-1.amazonaws.com still leave through the NAT gateway. The endpoint's security group allows HTTPS from the application subnets.
The VPC was created years ago with a custom configuration.
What is the MOST likely cause?
Choose one answer.
AA. Interface endpoints for Secrets Manager accept traffic only from Lambda functions, so EC2 instances keep using the public endpoint.
BB. The application subnets need a route to the interface endpoint, because interface endpoints are reached through route table entries.
CC. The endpoint policy is missing, so Secrets Manager rejects private requests and the SDK retries through the public endpoint.
DD. The VPC's enableDnsSupport or enableDnsHostnames attribute is turned off, so the private hosted zone for the endpoint is not used.
B. Wrong: Interface endpoints are elastic network interfaces with private IP addresses in the subnets. They are reached through the local route, so no route table entry is needed. Learn more: Configure route tables (opens in a new tab)
Interface endpoints with private DNS make the normal service name resolve to the endpoint's private addresses, but only when the VPC's enableDnsSupport and enableDnsHostnames attributes are both true. Older or custom VPCs sometimes have them off, so names resolve publicly and traffic uses the NAT gateway. Checking DNS resolution from an instance quickly confirms the cause.
Want more on VPC endpoints, PrivateLink and peering? The 5 full-length practice sets have 10 more VPC endpoints, PrivateLink and peering questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →