AWS VPC Endpoints
Many AWS customers run their applications within a VPC for security or isolation reasons.
For example, previously, if you wanted your EC2 instances in your VPC to be able to access DynamoDB, you had two options.
- You could use an Internet Gateway (with a NAT Gateway or assigning your instances public IPs)
- You could route all of your traffic to your local infrastructure via VPN or AWS Direct Connect and then back to DynamoDB.
Both of these solutions had security and throughput implications and it could be difficult to configure NACLs or security groups to restrict access to just DynamoDB.
VPC Endpoints
In order to overcome the above issue, VPC endpoints were introduced.
VPC Endpoints are virtual devices, which can be horizontally scaled, redundant and highly available VPC components that allow communication between instances in your VPC and services without imposing availability risks or bandwidth constraints on your network traffic.
In other words, VPC endpoints enables you to privately connect your VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring an IGW, NAT instance, VPN connection or Direct Connect connection. Instances in your VPC do not require public IP addresses to communicate with resources in the service. Traffic between your VPC and the other service does not leave the Amazon network.
With VPC Endpoints, your EC2 instances/Application can leverage higher performance, and more secure connections to connect via its private IP address to AWS services without the need to go over the Internet (IGW), VPN connections or NAT gateways or public IP addresses.
Instances in your VPC do not require public IP addresses to communicate with resources in the service. Traffic between your VPC and the other service does not leave the Amazon network.
VPC Endpoints are highly available. They are horizontally scaled, redundant and highly available VPC components that allow communication between instances in your VPC and services without imposing availability risks or bandwidth on your network traffic.
You need endpoint policy to control who can access what. Endpoints are supported within the same region only.
VPC Endpoint Types
There are two types.
- Interface Endpoints
- Gateway Endpoints
Interface Endpoints
An interface endpoint is an elastic network interface with a private IP address that serves as an entry point for traffic destined to a supported service.
The following services are supported.
API Gateway, CloudFormation, CloudWatch, CloudWatch Events/ Logs, EC2 API, KMS, Kinesis Data Streams, ELB, SNS, Systems Manager, Endpoint Services, STS, CodeBuild, WS Config, Service Catalogue, Secrets Manager
Gateway Endpoints
Gateway Endpoint is a gateway that is a target for a specified route in your route table used for traffic destined to a supported AWS service.
The following services are supported.
- AWS S3
- AWS DynamoDB
A Case Study — Connecting to S3 via VPC Gateway Endpoint
The following scenario, basically connects to a AWS S3 bucket from an EC2 instance (resides within a private subnet) via a VPC endpoint.
Prerequisites : This exercise presumes that you have a Custom VPC created with a public and private subnet along with a NAT Gateway connected to the private subnet to have Internet access to the private subnet instances
Step 1: Create a S3 Role for the EC2 instance (within Private Subnet)
Since we are accessing S3 from an EC2 instance, it Is required to attach an IAM role to the EC2 instance. For example, create a role, which has S3 Full Access for EC2 instances. (IAM → Roles → Select EC2 → Select AmazonS3FullAccess role → Create the Role (i.e. EC2S3FullAccess).
After attaching the S3 Role, you can test the following for S3 access from the instance.
$ aws s3 ls
You should be able to see a listing of all S3 buckets.
Step 2: Take off the NAT Gateway Route Table entry
Take off the NAT Gateway routing entry from the Main Routing Table (Custom VPC). (This step basically take off the NAT Gateway connection, which us used to connect to the Internet from private subnets and paves the way to add the VPC Endpoint routing entry in the next step)
Now again try the aws s3 ls command. You will not get an output. That is because you have removed the NAT Gateway entry from the Route Table.
Step 3: Create the VPC Endpoint
Goto VPC → EndPoints → Create Endpoint → Select Service Category (AWS service) → Select Service Name (i.e. com.amazonaws.ap-southeast-1.s3) → Select your Custom VPC as the VPC→ Select the Main Route Table (where your private subnet was routed via NAT Gateway) → Then, Create the Endpoint.
The above basically adds a routing entry to the Main Route Table, where your private subnet was routed via NAT Gateway.
Step 4: SSH to the private instance and execute the following commands
Just to see all S3 buckets in your region. It is necessary to specify the region // here
$ aws s3 ls — region ap-southeast-1
If you can see all S3 buckets in the specified region. You are now able to connect to your S3 buckets within your AWS network itself rather tunneling through the public Internet.
A Case Study — Connecting to another EC2 instance using VPC Interface Endpoint
Prerequisites : This exercise presumes that you have a Custom VPC created with a public and two private subnets (See the below Diagram). An additional private subnet is required to test EC2 connectivity from another EC2 instance in a private subnet. All three subnets should have an instance created under them (t2-micro). Both the private subnet EC2 instances do not have the Internet access and there is no NAT Gateway attached. With this setup, first private subnet EC2 instance is not able to talk to the second private subnet EC2 instance. For example, aws ec2 describe-instances will not given any output since there is no Internet connectivity for the private instance.
In addition to above setting, make sure to complete the following as well.
- Open HTTPS (443) port for private instance Security Group.
- Make sure the created custom VPC is enabled with DNS hostname attribute.
Once above prerequisites are completed, you may follow the given steps below.
Step 1: Create a Role for the EC2 instance (within Private Subnet)
The EC2 instance (in the first private subnet) should have an IAM Role with EC2ReadOnlyAccess Policy attached to it in order to access the other EC2 instance in the second private subnet.
Step 2: Create an VPC Interface Endpoint for EC2
Goto VPC → EndPoints → Create Endpoint → Select Service Category (AWS service) → Select Service Name (i.e. com.amazonaws.ap-southeast-1.ec2) → Select your Custom VPC as the VPC→ Select both Private Subnets → Select Security Groups of private Subnets → Keep the DNS check “on”→ Then, click “Create Endpoint” to create the Interface Endpoint for SNS.
Once the Endpoint creation is completed, you may SSH to the first private EC2 instance and execute the following command.
$ aws ec2 describe-instances –region=<us-east-1>
If the above command gives you the EC2 listing for the us-east-1 region, you have successfully completed the exercise.
