1. Home
  2. Training Library
  3. Amazon Web Services
  4. Amazon Web Services Courses
  5. Inter-Regional and Intra-Regional Communication Patterns

VPC Endpoints and Endpoint Services

Contents

keyboard_tab
Start course
Overview
Difficulty
Intermediate
Duration
19m
Students
15
Ratings
5/5
starstarstarstarstar
Description

In this course, we discuss how our services deployed to AWS communicate with each other. We cover what communication looks like when our services are in the same region and what communication looks like when our services are in different regions.

Learning Objectives

  • Inter-regional communication patterns
  • Intra-regional communication patterns

Intended Audience

  • Anyone working with AWS Networking 
  • Those studying for the AWS Networking Specialty certification
  • Anyone studying for the AWS Solutions Architect certifications
  • Anyone just looking to increase their AWS knowledge

Prerequisites 

  • Before attending this course, you should already be familiar with AWS networking services such as VPCs and VPC peering

 

Transcript

There'll be many occasions when a resource is deployed to a VPC will want to connect to other AWS services, such as S3 or DynamoDB. Services like S3 and DynamoDB have Public endpoints. Most services offer Regional endpoints you can connect to programmatically. This means that if you have an application running on an EC2 instance in a VPC in eu-west-2, it can use the S3 Regional endpoint to connect to your bucket and read and write content. 

The problem is these connections are using Public endpoints. So, the traffic from your EC2 instances will travel on public networks to get to the S3 bucket. Using VPC endpoints, you can connect to services provided by AWS and third parties through either a Gateway endpoint or an Interface endpoint. These endpoints keep your traffic on the AWS Backbone, keeping your data away from public networks, so are therefore more secure. Also, as your data is not being routed to public networks, and instead it's being routed directly to the service, your applications should also see reduced latency. Only two AWS services provide Gateway endpoints: S3 and DynamoDB.

When you configure a Gateway endpoint, a new route is added to your VPC Route tables. You get to choose which VPCs and which route tables the routes are added to. Here's an example of an S3 endpoint route in a VPC Route table. It appears in the route table as a destination and a target. In other words, any traffic addressed to destination pl-7ca54015 will be sent to the VPCE endpoint target. pl-7ca54015 is a prefix list. You can see more details of the prefix list in this screenshot. 

The Prefix list entries have a CIDR blocks that our traffic will be matched against. If our traffic is addressed to any IP address matched by these CIDRs, it will be routed through the VPC endpoint. In this example, the endpoint to S3 in eu-west-2 region. Instead of adding routes to route tables, Interface endpoints create Elastic Network Interfaces (ENIs), and attach them to subnets that you choose. The Interface endpoint ENIs obtain IP addresses from the subnets they're attached to. To route traffic to a service, you send that traffic to the appropriate ENI IP address.

All of the AWS services that support VPC endpoints are configured as Interface endpoints, as are all VPC endpoints that connect to third-party services. In addition, VPC endpoints for S3 and DynamoDB, can also be configured as Interface endpoints. Differences between Interface and Gateway endpoints. Well, Gateway endpoints are free, whereas when using Interface endpoints, you are charged an hourly fee for the endpoint, and a per gigabyte fee for data sent through the endpoint. 

Gateway endpoints cannot be accessed from outside the VPC. Interface endpoints can be accessed from any source so long as that source can route traffic to VPC subnets that the endpoint ENIs are connected to. It is worth remembering that VPC endpoints are regional. The only exception to this is S3 that offers a global S3 interface endpoint. Because VPC endpoints are regional, if you want to create an endpoint that connects to a DynamoDB database in eu-west-2, then you must create and attach the endpoint to subnets in eu-west-2. But what if you want to connect from an EC2 instance in eu-west-1 to a DynamoDB database in eu-west-2?

Can you use Interface endpoints? The answer is yes. In eu-west-1, create a VPC and subnets. In eu-west-2, create an Interface VPC endpoint that connects the DynamoDB. Then, you have to create a VPC Peering Connection between the VPC that hosts the EC2 instances in eu-west-1 with the VPC in eu-west-2 that host the endpoints, or attach both VPCs to Transit Gateways. As well as creating VPC endpoints that connect you to AWS services and third-party services through the AWS Backbone, you can also advertise your services through the AWS Backbone so that your customers or other business units can connect to your services without having to send traffic out onto the Internet. To create an endpoint service, create the compute service that host your application. For example, EC2 instances. Create a network load balancer and a target group. And add the compute services that host your application to the target group.

Then, through the VPC console or CLI, create your endpoint service. Depending on the service you're trying to advertise, you can also use Gateway load balancers with endpoint services. Here, we can see the properties of a newly created endpoint service. The arrow is pointing at the Allow Principals tab. Through this tab, you can identify entities that are allowed to access your endpoint service. The entities that are allowed to access your endpoint service could be an AWS account, a specific IAM user, or a specific IAM role. Once the endpoint service is created, your customers or other business units can connect to your endpoint service by creating a VPC endpoint and searching for your service.

 

About the Author

Mike has worked in IT since 1997, specializing in networking, storage, and architecture. He's been in cloud computing for the last 8 years, working across several cloud platforms but specializing in AWS. He's been involved in many cloud projects over the years covering migrations, hybrid connectivity, security optimization, networking, and storage architecture.

He gained his first training qualification in 1998 and, about 3 years ago, became an AWS Authorized Champion Instructor. He's delivered AWS cloud courses across Europe for a range of clients, with a focus on Architecture, Security, and Networking. He currently holds certifications for the four biggest cloud vendors, including the AWS Solutions Architect Professional, AWS DevOps Engineer, and AWS Advanced Networking specialty certifications.

He lives in the North of England with his wife Frances and their dog Inca.