1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. Solution Architect Professional for AWS- Domain Four - Network Design

VPC Peering and Connectivity

Contents

keyboard_tab
Network Design
1
Introduction
PREVIEW40s
2
The VPC
PREVIEW15m 3s
play-arrow
Start course
Overview
DifficultyAdvanced
Duration24m
Students1092

Description

Course Description

In this course, you'll gain a solid understanding of the key concepts for Domain Four of the AWS Solutions Architect Professional certification: Network Design.

Course Objectives

By the end of this course, you'll have the tools and knowledge you need to successfully accomplish the following requirements for this domain, including:

  • Demonstrate ability to design and implement networking features of AWS.
  • Demonstrate ability to design and implement connectivity features of AWS.

Intended Audience

This course is intended for students seeking to acquire the AWS Solutions Architect Professional certification. It is necessary to have acquired the Associate level of this certification. You should also have at least two years of real-world experience developing AWS architectures.

Prerequisites

As stated previously, you will need to have completed the AWS Solutions Architect Associate certification, and we recommend reviewing the relevant learning path in order to be well-prepared for the material in this one.

This Course Includes

Expert-led instruction and exploration of important concepts.
Complete coverage of critical Domain Four concepts for the AWS Solutions Architect - Professional certification exam.

What You Will Learn

  • Key network design concepts for AWS
  • VPC peering and connectivity
  • Other critical networking skills relevant for the AWS Solutions Architect Professional certification exam. 

Transcript

There are number of ways to connect to AWS. VPC pairing provides network connectivity between two VPCs, enabling you to route traffic between those two VPCs using private IP addresses as if instances were in the same VPC. This simplifies many operations when you manage a number of accounts, and you can peer to a VPC in another AWS account within the same region. AWS uses the existing infrastructure of a VPC to create VPC pairing connections so they don't rely on a separate piece of physical hardware. That means they don't introduce a potential single point of failure on network bandwidth bottleneck between VPCs. And additionally, VPC routing tables, security groups, and network access control lists can be leveraged to control which subnets or instances are able to utilize that connection. That can be the same AWS account, or be from different accounts. And a VPC peering connection can help you facilitate the transfer of data between VPCs so you can use them to connect VPCs when you have more than one AWS account. In a common use case is linking departments together within an enterprise. So for example, you might have a VPC for the HR department, and another VPC for the Accounting department. The HR team require access to all of the resources that are in the Accounting department, and the Accounting department requires access to all the resources in the HR department. Other common use cases are for directory services. If you have an active directory in your main VPC instances and peer VPCs will require full access to the central VPC to submit requests to the active directory service, the central VPC doesn't need full access to the peered VPCs, it just needs to have a route to direct response traffic back to the requesting instances. And you might want to share your VPC with partners or customers. If a partner creates a VPC peering connection with your VPC, that partner cannot route traffic or see the resources of the other partner VPCs. Peering VPCs doesn't mean you can access another VPC network gateway or interface, so you can't share VPC connections, and it's not a transit of peering. An instance public DNS host name will not resolve to it's private IP address across peered VPCs. Okay, to set up VPC peering, we first need to ensure we have unique sider blocks with both VPCs. So if they're overlapping, the status of the VPC peering connection immediately goes to Failed. We need to have the IDs of the VPCs with which we want to peer, and both ends have to accept the peering request. So to configure it, Admin from VPC One sends a peering request to the Admin of VPC Two. Admin of VPC Two accepts the request from inside the console, VPC One and VPC Two Admin accounts add a routing table entry to route traffic to the other VPC. The routing table needs to have the sider block you want to access in the peered VPC and the target VPC connection. Now that connection will generally have a prefixed PCX stash. To route traffic to a specific instance in another VPC, add a routing table entry with the IP address and subnet mask. Some of the things you can't do, you can't access a VPN or AWS Direct Connect link to a corporate network, you can't connect to an internet connection through an internet gateway, you can't do a Classic Link connection to an EC2 Classic Instance, you can't connect a VPC endpoint to an active AWS service, EGN endpoint to Amazon S3. VPN connections are an easy way to set up remote connectivity to a VPC. Each AWS virtual private gateway comes with two VPN endpoints with capabilities for static and dynamic routing. This makes the connection more redundant, but it still presents a single point of failure. The best practice for making VPN connections highly available is to implement a second connection via a redundant customer gateway, and enable dynamic routing for automatic fail over between AWS and your VPN endpoints. Now it's the customer managed endpoint that's the component responsible for implementing redundancy and any fail over. So customer devices must support Single Hot BGP if you're using BGP for dynamic routing. Now remember, VPN still relies on the internet to carry traffic. And to set up our VPN connection, each VPN connection is assigned a VPN identifier and is associated with two other identifiers: the customer gateway identifier, and the Virtual Private Gateway identifier. Okay, AWS Direct Connect. So, it makes it easy to establish a dedicated connection from an on premise network to Amazon VPC. So the main benefit of AWS Direct Connect is that it provides a more consistent network experience than internet based connections. Direct Connect supports 802.1qv LAN standard, and you can partition the connection into multiple virtual interfaces. Now multiple dynamically routed Direct Connect connections are gonna be necessary to achieve high availability. To achieve the highest level of availability, you should use more than one AWS Direct Connect partner network to ensure network provider redundancy as well. Now another option is to have AWS Direct Connect Plus VPN. So you can combine one or more AWS Direct Connection dedicated network connections with the Amazon VPC hardware VPN. Another connection option is the VPN CloudHub. Now with this, you can securely communicate from one site to another using VPN CloudHub. The AWS VPN CloudHub operates on a simple hub and spoke model that you can use without a VPC. So use this design if you have multiple branch offices and existing internet connections, and would like to implement a convenient, potentially low cost hub and spoke model for primary or backup connectivity between these remote offices. So the VPN CloudHub leverages the VPC Virtual Private Gateway with multiple gateways, each using unique BGP autonomous system numbers. Now this is really important to remember. Each spoke in the hub has to have a unique ASN. So your gateways advertise the appropriate routes, which are BGP prefixes, over their VPN connections. Now these routing advertisements are received and readvertised to each BGP Peer, so that each site can send data to, and receive data from the other sites. Each site can also send and receive data from the VPC as if they were using a standard VPN connection. So another connectivity thing to keep in mind is high availability for NAT instances. Now, instances in a private subnet can access the internet without exposing their private IP addresses by routing their traffic through a network address translation instance, which is in a public subnet. So this is just basically a bastion host, as I'm sure you're aware. Now a NAT instance, however, can introduce a single point of failure because your VPCs outbound connectivity is primarily gonna be routed through this one resource, and it's often a single machine. And as the size of your fleet grows, so too will the volume of your outbound connections. So if you have a lot of updates, or patches that need to be done, if that's all happening at the same time, then that NAT suddenly becomes a single point of failure. So one approach to stop this issue is to leverage multiple NAT instances that can take over for each other if the other NAT instance should fail. So if one NAT instance fails, we need a script that enables the working NAT instance to take over outbound traffic and attempt to fix the failed instance by stopping and restarting it. Now, there's many other ways we could ensure scale when they're bastion host, but that is one that you should keep in mind. Okay, let's just walk through the BGP connectivity. So to connect to Amazon Virtual Private Cloud, provide a private autonomous system number, which is the ASN. Amazon allocates a private IP address in the 169 dot xxx range. You create a virtual private gateway and attach it to your VPC.

About the Author

Students60020
Courses90
Learning paths38

Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe.  His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.