This course covers the core learning objective to meet the requirements of the 'Designing Network & Data Transfer solutions in AWS - Level 2' skill
- Understand the most appropriate AWS connectivity options to meet performance demands
- Understand the appropriate features and services to enhance and optimize connectivity to AWS public services such as Amazon S3 or Amazon DynamoDB.
- Understand the appropriate AWS data transfer service for migration and/or ingestion
- Apply an edge caching strategy to provide performance benefits for AWS solutions
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.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.