VPC Interface Endpoint

A VPC endpoint enables you to create a private connection between your VPC and another AWS service without requiring access over the Internet. An endpoint enables instances in your VPC to use their private IP addresses to communicate with resources in other services. Your instances do not require public IP addresses, and you do not need an Internet gateway, a NAT device, or a virtual private gateway in your VPC. You can use endpoint policies to control access to resources in other services. Traffic between your VPC and the AWS service does not leave the Amazon network.

So, we can say, we use VPC Endpoint to access AWS services within a region using Private IP address.

There are two types of VPC Endpoint:

1. VPC Gateway Endpoint
2. VPC Interface Endpoint

For VPC Gateway Endpoint kindly go to the link:

https://redhatpanacia.blogspot.com/2019/06/vpc-endpoint.html

VPC Interface Endpoint

From a VPC Interface Endpoint, we can connect to the services powered by AWS Private Link. To know all supported services kindly go through the link:

https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html

Fig: VPC Interface Endpoint

To do work with VPC Interface Endpoint, first, we must have a functional VPC (means its IGW, subnets and route tables must be connected properly). In this practical, I have a functional VPC named 'webshack-vpc'. There is no need for NAT configuration in this practical.

Steps for creating VPC Interface Endpoint:

1. Create a VPC named 'webshack-vpc'
2. Launch one instance in public subnet and another in private subnet
3. Download Pageant software
4. Add Private Key to Pageant software and login to the Web Server
5. Verify AWS-CLI is installed or not
6. Update existing role with policy ec2fullaccess
7. Verify we are getting the result in Web Server or not
8. Create a VPC Interface Endpoint
9. Update Inbound rules of Interface Endpoint Security Group
10. Verify ec2 service access on DB server

Step 1: Create a VPC named 'webshack-vpc'

Follow the below mentioned link to create a VPC:

https://redhatpanacia.blogspot.com/2019/06/create-amazon-virtual-private-cloud.html

Step 2: Launch one instance in public subnet and another in private subnet:

We are launching an instance in Public Subnet, which we assume as a Web Server:

AWS ➔ Services ➔ EC2 ➔ Instances ➔ Launch Instance ➔ [*] Free Tier only ➔ Select 'Amazon Linux' AMI ➔ Instance Type: t2.micro ➔ Next ➔ Number of instances: 1 ➔ Network: select own created 'webshack-vpc' VPC ➔ Subnet: As we are creating this instance for subnet-1, which we are using for a web server, select us-east-1a ➔ Auto-assign Public IP: (already enabled as we have enabled it at the time of creation of public subnet) ➔ Next ➔ Next: tags ➔ Name: linux-jump-webserver ➔ Next: SG ➔ [*] Create a new Security Group ➔ Security group name: linux-access ➔ Description: linux-access is created to access linux instances ➔ Rule ➔ SSH: TCP: 22: Anywhere ➔ Review and Launch ➔ Launch ➔ Create a new key-pair OR select any existing key pair ➔ Launch Instances ➔ View Instances.

We are launching an instance in Private Subnet, which we assume as a Database Server:

AWS ➔ Services ➔ EC2 ➔ Instances ➔ Launch Instance ➔ [*] Free Tier only ➔ Select 'Amazon Linux' AMI ➔ Instance Type: t2.micro ➔ Next ➔ Number of instances: 1 ➔ Network: select own created 'webshack-vpc' VPC ➔ Subnet: As we are creating this instance for subnet-2, which we are using for a DB server, select us-east-1b ➔ Auto-assign Public IP: (by default it would be disabled as we did not put it enable at the time of creation of private subnet) ➔ Next ➔ Next: tags ➔ Name: linux-db-server-pvt ➔ Next: SG ➔ [*] Create a new Security Group ➔ Security group name: linux-access ➔ Description: linux-access is created to access linux instances ➔ Rule ➔ SSH: TCP: 22: Anywhere (here we are putting anywhere, but in industry use CIDR range. So that this private instance could only be access privately) ➔ Review and Launch ➔ Launch ➔ Create a new key-pair OR select any existing key pair ➔ Launch Instances ➔ View Instances.

Step 3: Download Pageant software:

Download the software from below mentioned link:

https://filehippo.com/download_putty/

This download includes the following tools:

• PuTTY (the Telnet and SSH client itself)
• PSCP (an SCP client, i.e. command-line secure file copy)
• PSFTP (an SFTP client, i.e. general file transfer sessions much like FTP)
• PuTTYtel (a Telnet-only client)
• Plink (a command-line interface to the PuTTY back ends)
• Pageant (an SSH authentication agent for PuTTY, PSCP, and Plink)
• PuTTYgen (an RSA and DSA key generation utility).

(In the case, if the provided link does not work, kindly Google it)

Step 4: Add Private Key to Pageant software and login to the Web Server:

Run Pageant software (this software opens as hidden; right bottom side in windows machines) ➔ Right Click on that icon ➔ View keys OR double click on that icon ➔ Add Key ➔ Select ppk file of private key which you used to launch the instance ➔ Close ➔ Go to putty ➔ Session: put linux-jump-webserver public IP ➔ Expand SSH ➔ Click on Auth ➔ [*] Allow agent forwarding ➔ Browse: select private key ➔ Open.

Fig: Pageant Key List

Step 5: Verify AWS-CLI is installed or not:

As it is an Amazon AMI, AWS-CLI is already installed in this AMI. In 'redhat' AMI we need to install this manually. We can verify this via checking binary of AWS using 'which' command. 

$ which aws

/usr/bin/aws

If we get this output, means AWS-CLI is installed on that instance.

But if we want to get list of our buckets, this will prompt us an error for credentials, because we did not provided it any access key or secret access key:

$ aws s3 ls

Unable to locate credentials. You can configure credentials by running "aws configure".

To rectify this issue we must need to provide our access key and secret access key, which we do not want to do so, because this will store in our instance. So, we will create a role.

Step 6: Create a role with ec2fullaccess policy: 

Navigate to AWS IAM:

AWS ➔ Services ➔ IAM ➔ Roles ➔ Create role ➔ Select AWS Service (which is by default selected) ➔ Select EC2 ➔ Next: Permission ➔ In Search bar search 'ec2fullaccess' ➔ [*] AmazonEC2FullAccess ➔ Next: Tags (if you want, provide a tag) ➔ Next: Review ➔ Role name: webshack-ec2-to-s3-full ➔ Provide a proper description ➔ Create role.

Fig: Create Role

Step 7: Verify we are getting the result in Web Server or not:

Navigate to Putty, where Web Server is running and run the command again.

Fig: Describe AWS Regions

We are getting this result only because we are on our Web server, which has internet access. But if we try to run the same command from DB server, this command will not work because there is neither internet access nor private link.

Step 8: Create a VPC Interface Endpoint:

From Web server just do SSH to DB server and try to run the same command:

[ec2-user@ip-10-0-2-58 ~]$ aws ec2 describe-regions

You must specify a region. You can also configure your region by running "aws configure".

This is only a configuration error. So, we need to provide a default region to DB Server:

[ec2-user@ip-10-0-2-58 ~]$ aws configure

AWS Access Key ID [None]:

AWS Secret Access Key [None]:

Default region name [None]: us-east-1

Default output format [None]: table

Now, again if we run the same command, it's not working because previously created PL was just for S3 service not for EC2. Now, we will create a private link from EC2 service in N. Virginia region.

AWS ➔ Services ➔ VPC ➔ Endpoints ➔ Create Endpoint ➔ Service Category: AWS service ➔ Service Name: com.amazonaws.us-east-1.ec2 ➔ VPC: webshack-vpc ➔ select both subnets ➔ Enable Provide DNS Name: DNS resolution and DNS hostname both services must be enabled in our VPC. We can enable them by:

Navigate to VPC in AWS console in another tab ➔ Select your VPC ➔ Actions ➔ Edit DNS resolution: [*] enable (this must be enabled) ➔ Save and Edit DNS hostnames: [*] also enable this service ➔ Save ➔ Close.

Now go back to the previous tab where we are creating Interface Endpoint:

➔ Enable Provide DNS Name: [*] enable for this endpoint ➔ Security Group: Select default SG, because default has full access ➔ Create Endpoint ➔ close.

It takes some time from pending to available.

As we did so, we can see one IP from both subnets gone because an interface is added to public subnet and another interface is added to another subnet.

Step 9: Update Inbound rules of Interface Endpoint Security Group:

Once our Interface Endpoint is created and in the available state, we will go to the security group of our interface endpoint, which we selected default. Make sure all the traffic should be accepted from anywhere.

Step 10: Verify ec2 service access on the DB server:

Even we do not have internet access then too we are now able to get access AWS EC2 service.

[ec2-user@ip-10-0-2-58 ~]$ ping google.com

PING google.com (172.217.164.142) 56(84) bytes of data.

…..no response…..

But as we use the command:

]$ aws ec2 describe-regions
Getting Result

Yaayyyyy!

We are through…