Virtual Private Cloud (VPC)
AWS Data Migration
AWS Transit Gateway
Using Amazon Route 53
The course is part of this learning path
This course covers the core learning objective to meet the requirements of the 'Designing Network & Data Transfer solutions in AWS - Level 1' skill
- Understand the different AWS connectivity options for implementing a Hybrid solution
- Understand the AWS global infrastructure and its components in relation to networking and data transfer.
- Understand the purpose of Route 53 & Amazon CloudFront
- Analyze the different AWS data transfer services that are available
- Understand the different components of a Virtual Private Cloud
In this section, I want to talk to you about VPC peering. Now we've looked at VPN connectivity which looked at connecting your on-premise data center or remote office to your VPC and also Direct Connect which done the same thing but over an isolated network. Now with VPC peering, it's relating to connectivity again but what it allows you to do is connect two VPCs together.
So, we have one here and another VPC here. Now each of these VPCs will have resources in them. EC2 instances or databases, et cetera and what we want to allow to happen is for these two VPCs to be able to communicate with each other. Now these VPCs might be in the same region to they might be in different regions. Either way we can allow VPC peering to allow them to communicate with each other. Now the peering connection itself here that links the two VPCs is actually run and hosted on the AWS infrastructure. So, this is highly resilient, there's no single point of failure and also there's no bottlenecked bandwidth either. So, it's a very good way of linking two VPCs together to allow you to exchange information and for each VPC to communicate with another.
Now you might have multiple VPCs for organization or management and there will be times when you want resources in one VPC to communicate with another. And a quick and simple solution is to implement VPC peering. Now it's important to mention that this peering connection is a one-to-one connection only. So, if we had a third VPC down here, call this one VPC-3, again this had additional resources in as well and you had a VPC peering connection between two and three, resources in VPC-1 could not go via VPC-1 and then through VPC-2 to get through to VPC-3. That simply is not allowed as it's a one-to-one connection only. If you wanted VPC-1 to connect to VPC-3, then you'd have to set up a separate VPC peering connection between one and three. So, that's a very important point when mapping out your peering connections between your VPCs.
Now another important point relates to IP addressing, so for example, if VPC-1 had an address of 10.0.0.0/16, VPC-2 was 172.31.0.0/16 and then VPC-3 was also 10.0.0.0/16, then this connection here would not be possible because when you create VPC peering connections, each VPC cannot have an IP address overlap between them and these two VPCs have the same IP addressing scheme, so this VPC connection would not be possible. So, that's also something else to bear in mind when creating your VPC peers. So, let's take that connection away.
Now I also mentioned that you can have VPC peering configured between the same region or between different regions. So, let's say VPC-1 and VPC-2 was in one region and VPC-3 was in another region. Then this link here would be an inter-region VPC connection. Let me now run through the process of how this peering connection is initiated.
So, let me just get rid of what we have on the screen here and start again. So, we have two VPCs. Our first one and also our second one. VPC-1 and VPC-2. Now VPC-1 is going to be known as the requester and VPC-2 is going to be known as the accepter. Now the owner of VPC-1 needs to send a VPC peering request to the owner of VPC-2. And again, remember, we need to make sure that the CIDR blocks of these VPCs do not overlap, so that request comes across to the VPC accepter and that's the first stage. If the VPC accepter is happy with that peering connection, then an acknowledgement and acceptance of that request is sent back to the requester and that's the second stage and this creates the peering connection between the two. At this stage, each VPC needs to update their routing tables to allow the traffic from VPC-1 to get to the destination of VPC-2.
Now to do this, we need to know the CIDR blocks of these VPCs. So, let's assume VPC-1 is 10.0.0.0/16 and VPC-2 is 172.31.0.0/16. So that are two CIDR blocks that we have for our VPCs and as we know, they're not overlapping, so from an IP perspective, there's no issues there. So, now let's look at the route table for each of these. So, firstly, VPC-1. As we can see, we always have our local route and then we also have this additional route here. So, the destination 172.31.0.0/16 which is VPC-2 to go via the target of this peering connection. And the pcx simply means that this target is a peering connection. And these digits here are the ID of that peering connection. Now this VPC knows how to get to the 172.31 network by going via the peering connection here.
So, let's now look at the route table for VPC-2. Again, we have our local route which every route table has and then also this additional route that points to VPC-1 again across the same peering connection. So, this VPC can now access the network of VPC-1 again via the same peering connection.
Now the final part of the configuration would be to modify the security groups that are hosting any resources within your VPC. So, you might have a security group here and a security group here each with EC2 instances or databases and we'll simply need to update the rules to allow the correct resources, ports and protocols to communicate with each other.
So that's a high-level overview, that is VPC peering. Now what I want to talk to you about is the AWS Transit Gateway and again, this looks at how to connect more than one VPC together but through a one-to-many connectivity method, so let's take a look at that.
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.