VPC Security and Control
VPC Sharing using the AWS Resource Access Manager
AWS Networking Basics
Using AWS Network Firewalls to Secure Your VPCs
Inter-Regional and Intra-Regional Communication Patterns
The course is part of this learning path
In this section of the AWS Certified Advanced Networking - Specialty learning path, we introduce you to the various networking and VPC services currently available in AWS that are relevant to the ANS-C01 exam.
- Identify and describe the various networking services available in AWS
- Describe how to configure an Amazon Virtual Private Cloud (VPC)
- Understand how to control network traffic via Security Groups and Network Access Control Lists (NACLs)
- Describe options for VPC connectivity, subnets, and routing
- Understand how to share VPC resources using the AWS Resource Access Manager (RAM)
- Identify how to evaluate the configuration of VPC resources using the VPC Reachability Analyzer
The AWS Certified Advanced Networking - Specialty certification has been designed for anyone with experience designing, implementing, and operating complex AWS and hybrid networking architectures. Ideally, you’ll also have some exposure to the nuances of AWS networking, particularly regarding the integration of AWS services and AWS security best practices. Many exam questions will require advanced level knowledge of many AWS services, including AWS networking services. The AWS Cloud concepts introduced in this course will be explained and reinforced from the ground up.
Resources referenced within this lecture:
Hello and welcome to this section and I'm going to be talking about VPN connections, Virtual Private Networks. Now a Virtual Private Network is essentially a secure way of connecting two remote networks across the internet. So, let's have a look how we can use VPNs within our AWS and VPC.
So, if we just create a VPC over here and we also have our remote data center over here. Just with a little door and this is our data center and this is our VPC. Now within our VPC, we're going to have a single subnet. Now this is going to be a private subnet, so there's no internet gateway and there's no route to the internet gateway as well. It's totally isolated. So, a bit more information relating to IP addressing, so our VPC will have a CIDR block of 10.0.0.0/16 and for our data center, let's say the IP address sits on a 192.168.0.0 address space.
Okay, so we have our VPC over here sitting in AWS and we have our remote data center over here, maybe sitting in London somewhere. Okay, now we have resources within our data center in London and we also have some resources over in our private subnet, for example, some EC2 instances. Now what we want to do is enable communications between our resources in our private subnet in our VPC in AWS and to resources that are held on premise within our data center. Now we want to do this via a secure connection.
So, one option is to create a VPN connection, a Virtual Private Network. Now let's look at some of the components involved with that. Firstly, on your VPC side, you need to create something called a virtual gateway and this attaches directly to your VPC. Much in the same way an internet gateway does to enable public subnets access out to the internet and again, this is managed by AWS. So, here we have our virtual gateway. Now over in our data center, we also need another endpoint and this will be our customer gateway. And then this could be a piece of hardware or it can be a software virtual appliance, other way it need to be host within your data center. So, now we have an endpoint at our data center, the customer gateway and we also have an endpoint attached to our VPC, the virtual private gateway.
Now during the creation of our virtual private gateway, we'll need to supply some additional information that's going to be used in our customer gateway such as the customer gateway's IP address and the type of routing to be used whether it's dynamic or static. Now if you're not familiar with dynamic or static routing, then please see our existing course shown on the screen and this dives into different types of routing across subnets and across site to site as well. So, that will give you a little bit in-depth information on how the routing would work.
Now once your virtual private gateway is attached to your VPC and configured and also your customer gateway's installed, then what we can do is initiate a tunnel between the two endpoints. Now, this VPN tunnel can only be initiated from your customer gateway. It can't be initiated from your virtual gateway. Now if there was some idle activity across this link for a period of 10 seconds or more, then this VPN tunnel connection would drop. So, to prevent that from dropping, you can set up network monitoring to set up continuous network pings from the customer gateway side to the virtual gateway to ensure that connection remains up and running.
So, now we have our VPN tunnel up and running created between our virtual private gateway and our customer gateway, we need to change the route table associated to this private subnet, so our EC2 instances know how to connect to the 192.168 network. So, let's take a look at that. Now we can see here that we have the local route which we have with every route table as we know but we also have this additional route here. Now the destination is 192.168.0.0/16 which points to our data center network and the target is this virtual gateway. Now we know that's a virtual gateway 'cause it's prefixed with vgw and then this is the ID of the virtual gateway itself and this relates to our virtual gateway up here. So the instances within this subnet now have an additional route that points to this virtual gateway to get to the network of the data center.
What you can do is also enable route propagation within your route table as well. Now what this will do is once your VPN tunnel is up and running, then any routes that are represented across your VPN connection will be automatically added to your route table, so you might have other networks within your data center other than the 192.168 that are configured to use that VPN tunnel, so any traffic from another network received by your virtual gateway will allow these routes to be automatically propagated to the route tables that you've enabled route propagation on. Now depending on what sort of customer gateway you installed, will depend if it supports the BGP Protocol, which is the Border Gateway Protocol and if it does, then this supports dynamic routing, so this will populate all the routes for the VPN connection for you which means you won't have to implement any static routing. Now it is recommended that if you can install a customer gateway that does support BGP, then it's probably best to do so.
Now once our routes were in place, we also need to ensure we have our security groups configured for our instances as well to allow traffic to come from my resources over here and via the customer gateway across the VPN link to our virtual private gateway and then onto our instances but as we know, they are protected by a security group, so we need to ensure that the right protocols et cetera are allowed on the inbound rule set of our security group for our resources that are based over here. So, if we wanted to allow SSH access, for example, or RDP access, then the security group would look as shown. Now we can see that this security group allows both SSH and also RDP and it's from the source 192.168.0.0 which is of course our network that we're using on our data center.
So, to quickly recap. We have our virtual private gateway attached to our VPC and we have our customer gateway installed at our remote location. We then configure it with either dynamic or static routing and here we have a static route added for our subnet that points to the virtual private gateway within our VPC to get to our destination network which is of course our destination network of the remote data center. And then we also have our security group protecting our resources within our VPC allowing only specific ports and protocols which are inbound for my remote data center network. So, that's just a simple example of a site-to-site connection using a VPN which is a secure connection across the internet.
I now want to talk to you about using another site-to-site connection called Direct Connect but this does not use the internet. This is totally isolated infrastructure. So, let me explain how this works.
Okay, so in this section, I'm going to be talking to you about Direct Connect. Now this is another method of connecting your remote location such as your data center or remote office to your AWS environment. Now whereas your VPN connection used the internet to get to your VPC, a Direct Connect connection doesn't traverse the internet. Instead it uses private infrastructure and connects directly to your VPC. So, there's no public network that the traffic traverses, so let's look at the architecture of this to see how it works and how it's different to a VPN.
Now I'm not going to go into fine configuration details on this, I just want to provide you a high-level overview of how the Direct Connect infrastructure is presented, so let's take a look. So, let's start with our on-premise data center that we'll just over here. This would be our data center. And within our data center, we'll have a router. Now with a Direct Connection, there's a middle entity before you get to AWS infrastructure, now this is usually an AWS partner or an AWS customer that holds Direct Connect infrastructure and there's two parts to this.
The first part is the partner's infrastructure or the customer's infrastructure and the other part will be managed by AWS. So, effectively we will have a customer side and also an AWS side as well. Now this is all held within a facility owned and managed by a partner of AWS. This is a separate building entirely to your remote data center. Now again in the customer side, there will also be a router and another router in the AWS side as well. Okay, let's move on to the final section. So, here we have our AWS region because with AWS Direct Connect, it enables you to create a connection between your data center and an AWS region, not just a VPC, it's actually connected to a defined region. So, this will be our region here. And within that region we also have our VPC as well. So, this is our VPC and again, within our VPC we'll have a subnet with perhaps an EC2 instance in it, for example.
Now the reason it's connected to a region and not a VPC is that a Direct Connect connection allows you to access public as as private resources, so an example of a public source could be Amazon S3 and that's because Amazon S3 resources can be accessed over the internet via a public connection. Now attached to our VPC, we'll also have a virtual gateway much like we did when we was talking about our VPN connection.
Okay, let me just recap the three elements that we have here before we go any further. So, we have our customer data center over here with a router. Now here in the middle we have our Direct Connect location, so this is our Direct Connect location. And this sits between our on-premise data center and our AWS infrastructure and this is separated into two cages effectively. We have our customer partner router and we also have the AWS router as well. And then finally we have our AWS infrastructure over here with our region and inside the region, a VPC and we have our public components over here. Let's just nest that in the AWS cloud. So, that all sits within AWS.
Now I mentioned previously that you can have a private connection and also a public connection and as a part of that configuration, you can configure private virtual interfaces and also public virtual interfaces on your router. So, let's take a look. So, there'll be two virtual interfaces. So, one of them will be a private virtual interface and we'll define this by using this gray line here. So, that connects from your on-premise router to the customer side of the Direct Connect location. Now from here there'll be a cross connect from the customer router to the AWS router within the same Direct Connect location. And then from here, this virtual private interface will then connect to your virtual gateway. Then this will allow connectivity through to your resources within your VPC.
Now the second interface is a public virtual interface, so let's use this reddish color for that. So again the connection comes from your on-premise router into the customer side of the Direct Connect location, then there a cross connect across to the AWS router and from here it connects to inside of your AWS region and from here you can access your public AWS resources such as Amazon S3 et cetera. So, now we've established a connection from our on-premise data center into a region within AWS where we can access both private resources and also public resources and it's all done without having to traverse the public internet. Instead there's dedicated and isolated infrastructure using the Direct Connect locations. Now to be able to use Direct Connect, the only path that you need to establish is from your on-premise data center to a Direct Connect location to enable you to establish a connection to this customer router here. So, as long as you have a dedicated network route to a co-location that provides a Direct Connect connection, then you can establish this dedicated network that we can see here.
Now the great thing when working with Direct Connect is that it's private connection and also you get speeds from 1 through to 10 gigabits per second. Okay, the final section I want to talk to you about in this course is relating to VPC peering and also the Transit Gateway, so let's take a look at this final section.
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.