In the Advanced Architecting course, there is a section on Private Link
The text in the course:
AWS PrivateLink is a highly available, scalable technology that enables you to privately connect your VPC to supported AWS services, services hosted by other AWS accounts (VPC endpoint services), and supported AWS Marketplace partner services.
You do not have to have an Internet gateway, NAT device, public IP address, AWS Direct Connect (DX) connection, or VPN connection to communicate with the service. Traffic between your VPC and the service does not leave the Amazon network. With PrivateLink, endpoints are created directly inside of your VPC using elastic network interfaces and IP addresses in your VPC’s subnets.
To use AWS PrivateLink, create an interface VPC endpoint for a service in your VPC. This creates a network interface in your subnet with a private IP address to serve as an entry point for traffic destined to the service.
This lab will focus on one of the use cases in the slide: “Enables you to privately connect your VPC to supported AWS services”. I will use the service EC2 for the test. In other words, I will access the EC2 APIs using interface endpoints. One way of testing that is to use the CLI command:
aws ec2 describe-interfaces.
As a pre-requisite to the lab, I launched an Amazon Linux 2, t2.micro instance in the default VPC in AZ-A in region eu-west-1, with SSH allowed by the Security Group. I gave it an Admin role and used “aws configure” to configure the default region. There are many ways of achieving the same thing. The goal is simply to be able to issue CLI commands.
To keep the lab as simple as possible, I am using a public subnet. However, the same idea applies to private subnets, where an instance would be able to access the AWS APIs without using an internet gateway or NAT.
To test accessing the APIs without interface endpoints, issue the command:
aws ec2 describe-instances.
It should work.
To see the IP address that the command is using to access the APIs, we need to know the names of the AWS service endpoints. The are documented here:
To see the IP address being resolved, issue the command:
dig ec2.eu-west-1.amazonaws.com <output omitted> ;; QUESTION SECTION: ;ec2.eu-west-1.amazonaws.com. IN A ;; ANSWER SECTION: ec2.eu-west-1.amazonaws.com. 6 IN A 220.127.116.11
Note that the dig returns a public IP. In other words, the EC2 APIs are being accessed over the internet.
Now to create the endpoint:
Choose services, VPC, Endpoints, Create Endpoint, select com.amazonaws.eu-west-1.ec2, or equivalent for your region.
Choose the default VPC, and, to keep it simple, select the subnet in AZA. in real life, select more than one subnet for high availability. An ENI will be created in each subnet that you choose.
Leave “Enable DNS names” selected. For the Security Group, select or create one which allow all taffic in and out. This SG is associated with the interface endpoint and controls access to the ENI.
For Policy, leave it at full access. This controls which user or service can access the endpoint.
Click Create Endpoint
It will be pending for a couple of minutes.
You can look at the details of the endpoint to see the private IP of the created ENI.
From the instance, repeat the ec2 describe-instances command. It should still work as before, but the traffic is now going over the private link.
Repeat the dig command, to see output similar to:
;; QUESTION SECTION: ;ec2.eu-west-1.amazonaws.com. IN A ;; ANSWER SECTION: ec2.eu-west-1.amazonaws.com. 60 IN A 172.31.45.146
Note that a private address is being returned.
The traffic stays on the AWS network, is more secure, and takes a more optimal path.
An interface endpoint is about $0.01 an hour.
To clean up.
Delete the Interface Endpoint.