This section of the AWS Certified Solutions Architect - Professional learning path introduces you to the core networking concepts and services relevant to the SAP-C02 exam. We start with an introduction to the AWS Virtual Private Network (VPC) and networking services. We then understand the options available and learn how to select and apply AWS networking, DNS, and content delivery services to meet specific design scenarios relevant to the AWS Certified Solutions Architect - Professional exam.
- Get a foundational understanding of VPCs, their security, and connectivity
- Learn about VPC sharing using the AWS Resource Access Manager
- Discover inter-regional and intra-regional communication patterns in AWS
- Learn about AWS Direct Connect, along with its implementation, configuration, and connectivity options
- Understand routing in AWS, including static and dynamic routing
- Understand the basics of networking, including Elastic IP addresses, Elastic Network Interfaces, networking with EC2, VPC endpoints, and AWS Global Accelerator
- Learn about the DNS and content delivery services Amazon Route 53 and Amazon CloudFront
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.
Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.