AWS re:Invent 2015: Deep Dive in AWS Direct Connect and VPNs (NET406)

so good afternoon in this session you're going to learn how to enable connectivity with VPNs and direct connect into your AWS resources my goal is that in an hour's time whether you're a network engineer a cloud architect needs the platform or experienced with the platform that you'll have all of the skills you need to get a connection up and running with AWS my name is Steve Seymour I'm a Solutions Architect I'm based in the UK there's going to be no use of the word router in this session we'll be routing everything ok so what should you expect from this session well I'm going to be talking about various scenarios that I see with customers that I work with regularly so there's a bit of a story to this session within it there's always going to be some characters to that story so we have our network engineers for example some locations obviously the cloud is one of those a corporate data center or a corporate network is the other component that I'm going to be talking about a lot during this session and I hope to give you a toolbox a set of things that you can use in the future when you're deploying connectivity projects relating to AWS I'm finally hopefully a form of checklist and a set of methods that you can go through so let's talk about the characters the team that's involved in the slee examples we're going to be using this afternoon first of all we've got the network engineering team key very important team in terms of a connectivity project usually working very closely with a cloud architect team perhaps the application developers as well and the first thing I would say about establishing connectivity to a Dias is it's key that those teams work together there used to be an understanding of what are the requirements from the network team and what is it that the application owners the architects need from the solution and then finally I can't encourage you more to use the AWS solutions architecture team the team that I'm part of and our support team to help you with these projects you can raise support cases to ask questions about how do I do this it doesn't have to be because you're having a problem with something so this is going to be the the basis of the discussion we're having an Amazon VP see you've probably all got something deployed that's very similar to this public subnets private subnets requirements for connectivity out to the Internet but we don't need to get into the detail of what's inside this particular V PC so for this session we're going to simplify that down to this this is our V PC for the purpose of this discussion on the corporate side you've probably all seen Network diagrams that looks something like this this is representative of the corporate infrastructure that we're going to be connecting into again let's simplify that down for the purpose of this session so this is our corporate infrastructure on the right of the screen so that makes up our environment we're going to be connecting these two together using VPNs Direct Connect and a few other topics that I'll touch on so let's give ourselves a bit of room to work with and we're going to fill in the gaps in the middle okay so what have we got in the toolbox that we're working with now this is a 400 level session so I'm going to assume that you all know what all these components are and in fact we're going to go one step further we're not going to refer to them necessarily by their their full names there let's use the short names that we use in the console we don't tend to see em root tables though shorten so I'm going to leave that one as it is but we're going to be referring to VP CSV g WS c g WS DX is the abbreviation we use for Direct Connect so these components make up the elements you need to establish connectivity into your V PC the root tables send the traffic out of the V PC the igw is the way to get in and out to the Internet the vgw the virtual gateway gives you access to VPNs and Direct Connect endpoints the VPN is the connectivity that you then use to connect to the customer gateway and DX Direct Connect is the final part of the solution so these are the four specific topics we're going to cover the hardware VPN solution that we have Direct Connect itself and virtual interfaces how you deploy those on AWS VPN cloud hub which is something you may not have heard of but there's been around since we launched VPN and then finally I'm going to touch on some software VPN examples as well so first of all let's let's get straight into the hardware VPN solution that we have this is a pretty commonly accepted description of what IPSec is taken straight from Wikipedia but the things I want to focus on are the fact that provides secure IP connectivity and communications it authenticates it encrypts each and every IP packet using mutual authentication in our case using a pre shared key and enables the negotiation of cryptographic keys for exchanging the rest of the traffic over our VPN connection so that's what we're going to be working with that's the basis of the AWS hardware VPN solution we have to select variations of our VPN solution we support both static or dynamic VPNs and when we say dynamic we mean BGP based that's going to be the focus of most of the discussion here but I am going to talk a little bit about static VPNs first in a static VPN situation you need to specify the IP prefixes the routes that you want to be routing traffic to you put those into your route tables and they're configured you have to go in and manually change them manually maintain them however a dynamic VPN uses BGP or the gateway protocol and we support a hundred prefixes that you can announce to us over BGP so that's dynamic if you change them they update inside AWS automatically and then finally BGP running over a VPN connection supports two by a s numbers so what we mean by that is we go from 1 through to 65535 the AWS VPN requirements so these are these are all captured in the documentation there's a few important things I want to call out here first of all VPN connections to AWS are always initiated from the customer side so your router needs to see interesting traffic and initiate the session to us secondly we use pre-shared keys for authentication when you create a VPN connection in the AWS console or via the api's we generate a preciate key that's used for the connection we use IPSec essays in tunnel mode and that's important I'll cover that in a little bit more detail in a moment and so we don't do policy based VPNs we use AES 128 bit encryption and sha-1 we support D hpfs group 2 and dead peer detection and it's important to note that we require you to fragment IP packets before encryption so even if they have the don't fragment header on them ok so this is our static VPN example so back to the two environments that we have on the left hand side we have our BC and I've just increased the size of the virtual private gateway there so that's what we're focusing on on the right hand side we have the corporate network in a static VPN situation here you have to specify which networks you want to route traffic to and we support one unique si per tunnel so that's one inbound one outbound two unique pairs for two tunnels so where did the two tunnels come from you might ask well when you configure a VPN with AWS we actually configure two different endpoints on the AWS end in two different availability zones so when you create that VPN we actually give you the configuration details for two tunnels and they come back to a single customer gateway on your side of that connection we sometimes see customers with issues where they have certain types of hardware VPN device that every time they want to establish a new si over their VPN it's every time they want to route a different block of IP addresses over their VPN it establishes a new si that's not going to work because as I said on the previous slide we only support one in each direction so it's really important that you consolidate your ACLs to cover all of the traffic that you might want to route over this connection actually just announced it as a zero and any connection so at that point you now control what traffic routes over this particular VPN using an access control list so static VPN slightly different you do have to specify the IP addresses you want to route and just remember that we only support that pair of essays per Tong so let's move on to dynamic VPNs so a little bit of level setting here some of you might have some experience with BGP but I just want to recap quickly on that so what is BGP it's a TCP base protocol runs on port 179 support a gateway protocol within a BGP environment you have bgp neighbors they pair with each other and they exchange routing information they exchanged prefixes now a prefix is a combination of aside a block set of IP addresses and an a s path so what is an na s and a s is an autonomous system and it identifies different network environments it's not individual via devices so for example Amazon has a single large a s number that covers the whole of the Amazon Network you'll hear the terms ibgp and ebgp so ibgp is where we establish appearing relationship between two neighbors that are in the same AS number so used within usually the same network ebgp is external BGP as it says between peers that are in different AAS numbers finally you're going to see some examples in the upcoming slides of an AAS path so this is a measure of network distance every time traffic passes from one network to the other the AAS number for that network is added to the AAS path and it gradually gets longer which means when you're on the receiving end of a BGP announcement you can see where did it come from what path did it take and if you have multiple announcements for multiple prefixes you can see which one took a different path and perhaps make some decisions on which one is better so that brings me finally to local preference now you might have received two announcements for a particular prefix and one of them looks a lot shorter and a lot more efficient to get to in terms of network but actually you may have much more bandwidth on another connection or perhaps it's more cost-effective so what local preference lets you do is enforce a choice at your end of the connection that no matter what the path length says or or any of the other influencing factors or path decision elements I'm going to choose this particular path it's my local preference for sending traffic so they're the components you're going to hear about in terms of BGP so what does a dynamic VPN look like well again you'll recognize that it's pretty similar it's still got two tunnels so again when you create the VPN configuration and choose that this is a dynamic BGP based VPN we'll configure two tunnels for you you need to specify an IP address for each end of that tunnel now when you're doing this over a VPN we automatically generate those IP addresses for you in the configuration on the AWS end we have a fixed a s number generally at seven two to four but it can vary by region however for your end when you're configuring the VPN you get to choose what is number you want to use now the thing about BGP as I said is it's dynamic so as you announced routes over BGP into AWS we need to do something with them so we need to update the route table inside the V PC to specify how do we get to that remote network so in this particular example I'm actually just going to put an entry in there that specifies the corporate network on the right and to go via the virtual gateway the virtual gateway then receives all of the BGP announcements from the corporate network we'd all have an option called route propagation as well what this does is it says anything I receive at the virtual gateway via BGP automatic and put it into the route table for me so now we don't have to maintain that route table manually so BGP peer address is automatically generated your a s number when you get to choose it you can choose anything so if you happen to have a public a s number for your network and you want to use that that's fine otherwise there's a block of a s numbers reserved for private use the Amazonas number as I say 7 2 2 4 generally used in a couple of regions we have nine oh five nine and one or two others so always download the configuration that we generate and check what a s number we're using on the AWS side so how does path selection work the virtual gateway has now received its BGP announcements how does it decide where it's sending its traffic well first of all we looked for the most specific Network announcement so a slash 24 network is more preferable than a slash 16 so if we have the two of those in the route table we'll pick the slash 24 within the virtual gateway we then have a look and see what have we got in terms of connections to a customer network because they all come into the virtual gateway if we see a static VPN connection actually we prefer that first because static routes come above any of the other route selections next we choose Direct Connect and then finally we choose the shortest a s path and it's actually down here that the dynamic VPN fits in that's very relevant because later on if you have a direct connecting place you're probably going to want to be using that for all of your traffic except in a failover situation so Direct Connect comes above dynamic VPN so you might have noticed in the previous slides that we had two tunnels but it came down to a single customer gateway on the corporate side obviously a potential single point of failure there so it's quite easy to just build two VPN connections which in AWS terms means that you've just created four tunnels so now you have four resilient tunnels going into AWS terminating in two different availability zones and on the customer side you have two customer gateway devices these could be in the same data center the same location or they could be separate on your network and you're probably going to have to run some sort of internal routing protocol between them to decide how do I route traffic to AWS so that could be ibgp to use the example from earlier or OSPF or whatever it is you deploy internally this also then can extend onto connecting to multiple V pcs so a single VPN connection only connects to a single V PC so taking our resilient model where we had two customer gateways four tunnels we now have two V pcs on the left-hand side and therefore we have eight tunnels connected to them all of these are dynamically routing to each other all announcing their available prefixes back to the customer gateways so this is what I just wanted to mention a recent update to the AWS VPN service so we now support reusable customer gateway IP addresses and what that means is that on your end of the VPN connection you can use the same IP address in many of our regions now for connecting to multiple V pcs inside a ws so this is rolling out across the regions at the moment and it just means that you don't have to have unique customer IP address for each gateway on your end of the connection if this is something you want to take advantage of simply create a new virtual gateway create a new VPN connection then detach the old one from your V PC and attach the new one to it then of course delete the old virtual gateway and the old VPN connection to save cost it's important to note you can only have a single virtual gateway attached to the V PC at any one time so create the new one in parallel and then just swap them over we are going to have some further features around VPN that are going to be announced in the coming months so keep an eye on the forums and the blogs so now let's step back to the beginning how do you actually create this VPN connection what does it look like well the six steps involved first of all you're going to create that virtual gateway so you create this inside the AWS console or obviously via the api's you give it a name and at this point it's not associated with anything so the second step is you're going to attach it to your V PC what is it we want to be able to route traffic to them from the third step we're going to define the other end of that VPN connection the customer gateway we specify the IP address what type of routing we want to use give it a name etc and if it's dynamic specify das number that I mentioned earlier finally we join those two components together the virtual private gateway and the customer gateway with a VPN so at this point you're simply choosing the two endpoints and if you need to you can create a new customer gateway here if you hadn't done in the previous stage but there's no other configuration you need to do once that's done you go into your route tables and if this is a dynamic VPN simply enable route propagation as you can see there you check the box next to the virtual gateway now anything that it receives over VPN or Direct Connect as we're going to cover later will automatically be propagated into that particular route table so that's great everything's configured now on the AWS side all that's left is to configure the customer end of this VPN connection so you'll notice that we have a download configuration option we provide configurations for a range of different route manufacturers but we also have an option to download a generic configuration this is standard IPSec VPN connectivity so the information you need is within that generic configuration document and you can use that to configure the equipment on your end of the connection okay so we're going to move on to Direct Connect now so what is Direct Connect well quite simply it is a dedicated private link into the AWS Network you can create things called private or public virtual interfaces on a direct connect give you access to different types of resources within the AWS environment it enables you to benefit from reduced data transfer rates data transfer into AWS is always free but reduce data transfer rates out of AWS and one of the most common reasons for wanting to use Direct Connect is a combination between high bandwidth but consistent performance so there's always going to be latency in a connection but over a Direct Connect it's going to be a consistent experience it's going to be as low as we can make it and it's coming directly into your network it's avoiding any potential internet weather type events so the VPN connection as much bandwidth as you might have on your side and as much as is on the AWS side we are crossing the public Internet Direct Connect doesn't do that there is at least one Direct Connect location for every AWS region in many cases there's multiple Direct Connect locations and this is where you interface with our equipment to connect your fiber connection you can have multiple Direct Connect connections so you can establish multiple connections in one of our locations or across multiple locations for a particular region and also it's very common to see customers with multiple AWS accounts so they might have a perhaps a payer account and then a development account a test account a production account and they don't want to purchase a Direct Connect for every single one of those which you can share a direct connect across those accounts and then finally we have something called into region connectivity which is available within the US regions and it enables you to get a connection at one particular US region and reach out to resources in another region I'm going to talk about that in a little bit more detail later on but it's for use with public virtual interfaces for accessing things that are outside your VPC as we said earlier all of this is using BGP to exchange routing information and it's carrying that over an 802.1 queue VLAN that runs on Direct Connect we don't support any other routing protocols at all / Direct Connect it's specifically be GPS and no static routes no OSPF this is a list of the AWS regions and their corresponding Direct Connect locations as you can see many of them do actually have two Direct Connect locations and these are Colo facilities these are places that you might actually have some of your own equipment or can at least get access to to deploy equipment this list is maintained and updated on the web site and we're always expanding these Direct Connect locations so given that this is a network discussion I thought somewhere in here I've got to get a know I saw a chart so here we have it right at the bottom there I skipped a few of them as you can see but at the bottom we've got our physical layer so layer 1 what is this in Direct Connect terms well it's a single mode fiber for a one gig or a 10 gig Direct Connect the physical layer is a single-mode fiber so let's talk about the physical connection side of Direct Connect first and we've got a few terms up on the screen there I'm sure they're familiar to most of you some of them have got something in common which is that that grouping are basically the same thing they might be delivered in a slightly different way but when it comes down to it they're going to be either a layer 1 or a layer 2 Ethernet delivery of the service that extends the port from our location to wherever you're located the bottom one it's a little bit different so how do we deploy the physical connection well once you request a Direct Connect connection we give you something called an L away I have an example of it later on a letter of authority and what it is is permission to now connect to ports on AWS is Reuters so if you're located within the same facility as our equipment this can be as simple as a cross connect under the floor you can just raise a cross connect requests with say Equinix or coresight or one of our Direct Connect locations and say here's our rack here's where AWS are located a range of cross connect for me single mode fiber as I said the two interface types that we support thousand base LX and 10 G base L R if you're not within that facility that goes back to those terms I was using earlier for the physical connections so you might purchase a pseudo wire type service or a LAN extension service from a carrier or a Direct Connect partner and a Direct Connect partner will extend it from that location out to wherever you need it to be delivered to your equipment and then the final component is obviously a Rooter to go on the other end of that connection so that Rooter needs to support obviously the interface type if it's within the building that single mode connection or however the carrier presents it to you it needs to support 802.1 q VLANs which is what we use to carry the bgp sessions and this is what it looks like so we've still got our same scenario here left hand side is AWS right hand side is the corporate network we now have our Direct Connect location between us we have the AWS Direct Connect reuters in that location and in this example I'm showing that you're co-located there as well so you've got perhaps some of your service some infrastructure there and part of your environment you want to link into resources within AWS you probably also have the rest of your customer network connecting back to the corporate environment on the right-hand side so this is the the really simple example I was talking about a a cross connect so what are the components that make up this well first of all between the AWS region and the Direct Connect location we have the Amazon backbone so this is the diverse and resilient connectivity from the Direct Connect location back to all of the availability zones within the AWS region so Direct Connect gives you access to all of the availability zones the next component here is the cross connect that we've ordered perhaps from the facility between the AWS equipment and your equipment then we have your route of the customer Rooter PAP sitting in your cage your rack an Access Circuit of some sort into a network and then onward delivery into the corporate environment so pretty standard pretty simple deployment the variation on this that I mentioned earlier was the partner delivery so the Direct Connect partners and there's a list of them on the website they're very familiar with this process and what you would do is you would hand them your letter of authority which gives them permission to connect into the AWS equipment they then connected into their network and usually deliver it onto you as a layer 2 type connection so now you still run the VLANs on your router you still run the BGP there are variations out there but this is the the most standard and the simplest model for a partner connection at one gig or 10 gig so let's go back to that one that was slightly different let's talk about MPLS IP VPN VPLS that type of thing well in this scenario you've usually got an existing network connecting together your corporate locations perhaps a data center already and these might be multiple locations globally so on the edge of the MPLS network there's going to be what's called p equipment provider edge and you're going to have some c reuters customer edge equipment inside your data centers now in this particular case if the carrier providing this connectivity for you is a direct connect partner often they will take that L away from you order the cross connect and deliver it straight into their PE rooters on the side of their MPLS network they then encapsulate that and deliver it your IP VPN or your layer 3 VPN service that you receive from them but they do all of the BGP and the VLAN termination right at the edge in that location so it's a slightly different deployment model ok let's go back to our model oh I've removed the the layer 1 2 3 and just put some of the terms in here that we use for Direct Connect and how they map onto the components on the right hand side so I've mentioned a virtual interface a couple of times so what is that well it sits on top of that physical connection we have at the very bottom of the stack here so a virtual interface contains the VLAN definition that's one of the components that we need to configure for Direct Connect it contains the details of the IP addresses that we use on each end of the bgp session and it carries the bgp session itself so when you see the term virtual interface that's what it means so each virtual interface is a combination of a VLAN and a bgp session all of that then enables you to route traffic as it says at the top on the right-hand side and if this is going to a V PC so it's a private virtual interface that's where it connects with the virtual private gateway and gives you access into your V PC and this particular example all of those components are owned by the same AWS account so on the left hand side a c1 so let's talk about the difference between public and private virtual interfaces for a moment what have they got in common well they both use 802 1q VLANs they both use ebgp peering between two different AAS numbers as I said earlier we accept 100 prefixes over bgp but a private virtual interface is for accessing resources that are inside your virtual private cloud so your ec2 resources that are running on IP addresses that you specified when you created the V PC it doesn't give you access to V PC endpoints for s 3 inside that V PC and it doesn't enable any sort of transitive routing using V PC peering it just gives you access to that particular V PC so if you have multiple V pcs you'll have multiple virtual interfaces one going to each of them a public virtual interface is used to access the services that are outside of your V PC so things like DynamoDB s3 public endpoints sqs any of those kinds of services that sit outside the DPC if they're the things that you're using then you most likely to need a public virtual interface so back to our model here I want you to just call out a couple of other terms that you might see or hear around Direct Connect and this is identifying that we can separate out the ownership of the various components of Direct Connect so the physical connection perhaps that's owned by the network team so it consider one particular AWS account when you create a virtual interface you can then choose to share that virtual interface to another account and we then call that a hosted virtual interface so now we have the separation there between two different accounts perhaps the network team and the application owners a further variation on that is where you're using one of our sub 1 gig connections so these are bandwidths of 50 Meg 100 2 3 4 and 500 megabits per second these are not dedicated ports these reports that partners have connected with us already and they provision the sub rate connections for you on those ports so in this particular case the partner already has the physical connection in this case we call it an interconnect you speak with that partner about what connectivity you require how much bandwidth do you need and they will then provision you what's called a hosted connection on that interconnect they specify the bandwidth and because they own the physical connection they choose the VLAN tag that's going to be used for it but at that point is presented into your account into your customer account and we call that a hosted connection from this point up it's exactly the same as the other types of dedicated port connections you still create a virtual interface and you still attach it to a virtual private gateway there's one slight difference here in that it only supports a single virtual interface per hosted connection so if you need to connect to multiple V pcs simply have a conversation with the direct connect partner that says I might need two or three hosted connections to put a virtual interface on each one of them just to add one more layer of complexity in here you still have the option to create a hosted virtual interface in this model so the partner has now created the hosted connection and shared it with perhaps your main account within that main account you've then created a virtual interface and you've shared that to the development team so it's now a hosted virtual interface so we now have three elements involved three owners of the different components of Direct Connect so as I say it only provides access to resources within the VPC it attaches at that same place that the VPN connections do so it comes into the virtual private gateway now that's relevant for cloud hub which we'll be talking about towards the end you can attach multiple private VIP virtual interfaces to that virtual private gateway so if there's multiple connections you simply attach multiple virtual interfaces to that virtual private gateway and because this is a private virtual interface you can use whatever IP addresses you like so you can specify the IP addresses for the peering session or will automatically generate them for you you can announce any IP addresses you like over that BGP session to us will then propagate them into your route table you can also just announce a default route so at that point we'll send all traffic out via the virtual gateway back to your corporate network so what does that look like when we deploy into our environment back to our V PC and our corporate data center on the right hand side you can see the parameters at the very top so the first thing is a virtual interface we identify it by something good a DX VF identifier you'll see that in the console on the custom side it's usually identified by some sort of sub interface or VLAN definition on your equipment we choose a VLAN tag we did that via the console earlier we're going to specify the IP addresses that we use for that peering session the a s number again on the AWS side that's fixed generally the same for most regions but then what is some variation on the customer side you get to choose what is number you want to use so as I said earlier you can choose anything you like this is a private virtual interface underneath all of that there's then an md5 key that's used for authentication between the two BGP peers and the end result of this is we now have an e bgp session up and running between AWS and your equipment from the AWS side what are we going to be announcing it's quite simple it's the side a block for your V PC it will be a single prefix announcement we don't announce individual subnets and it will be just that V PC that you attached the virtual interface to on your site as I said you can announce anything to us generally it would be the culprit addresses but it could be a default route but either way you still need to go into the virtual into the route table inside your V PC and either turn on route propagation or put a static route in there this is exactly the same as we did for the VPN connection earlier so let's go back to the physical deployment that we had and you recall earlier where we've broken down the various components that make up the connection and obviously you could have two connections now if you request to direct connect connections via the AWS console we will automatically provision those for you on different equipment on the AWS side so at this point you've got Hardware resilience and redundancy it's - coming into the same physical router on your side in this particular scenario and but then onward into your network to provide that connectivity so what does this look like if we have two physical connections what do we now do with the virtual interfaces well each of those physical connections is treated independently so we're going to configure two virtual interfaces to private this in this case all the same parameters that we had before but there's two of them one thing I want to draw attention to here though is that because we're attaching these virtual interfaces to the same V PC we need to make sure that we're using different IP addresses for the peering you can however use the same VLAN and that's because the VLAN is just contained to that one particular physical connection is used to separate out each of the virtual interfaces but beyond that it doesn't get carried into the AWS Network at all so for simplicity we quite often sneak customers creating virtual interfaces with same VLAN number on each of their connections if they're going to the same place so going back to the physical infrastructure again obviously this kind of gives you a level of resilience you now have two connections from AWS but actually it would be much better if we simply did that so let's have two customer rooters so the same configuration applies here there's no difference in terms of how you deploy this but it is a really simple solution but a variation on that again if you want a level of resilience that is geographically diverse is to move those two routers on your side in two different Direct Connect locations so here I'm showing a has to Direct Connect locations so two separate sets of Direct Connect Reuters going to two separate customer gateway devices and then on virus service provider into your network but if we've gone this far well we can simply do that as well so now we have four Direct Connect connections the point I'm making is that you can layer as much resiliency into the solution as you like we give you the options to do this and each time you do you then just create virtual interfaces on top of the physical connections to carry that traffic to your resources on the AWS side and in reality a combination of these scenarios are used by many customers so we've got our two virtual interfaces up and running let's let's keep a fairly simple scenario just two connections well what does that look like well if you've got two virtual interface you probably want to be running them in an active-active configuration and by default if these came into the same route of what would happen is your route would make a decision of which one it prefers based on a certain algorithm and that would be where it sends all the traffic you can quite simply update that to use bgp multipath so the example here is a cisco router by adding one extra configuration option maximum paths to the m will appear next to those particular routes in the route table which means you'll now be multipathing across them effectively Network level load balancing if you like so now you're getting the benefit of both physical connections if we look at it though from the perspective of the virtual gateway it's received those announcements from you what's it going to do with them it's received the same thing twice well we automatically assume therefore that you want to run this as active active and that you would like us to also do multipath so we can see these two identical paths by two different peers perfect we'll do multi path for you this is not a configuration or or option or anything that you do in the console it's what we choose by default what if you don't want to run active active though so what if on your side these connections go to perhaps two different data centers and you run active standby or a hot cold set up well in that case you're going to want to choose one particular connection over the other and you probably want to actively decide which one you want prefer so this is where that local preference thing comes in that I mentioned earlier in your configuration you specify that as you receive these routes from us you apply a local preference to them the higher the preference the more preferred route so in this case the bottom example 200 that's the one that we're going to be using and you can see that indicated by the Chevron on the left hand side so that's our preferred path from the customer side but what about on the virtual gateway side well we haven't changed anything so it's still the same is path length we're still going to be doing bgp multi path so you're going to be sending traffic over one connection we're going to reply by sending traffic over both of them and that's probably not what you wanted to achieve well we give you the ability to influence that choice and you do this using a s path prepending so what you do here is you artificially make us believe that one of those connections is slightly longer in terms of network distance than the other so in this case I have two examples we're doing a s prepending x 2 and x 1 where we put our a s number on the path a couple of times before we pass it on to the AWS rooters so now we look at that from the virtual gateway perspective and one of these paths looks longer than the other so we now make a path selection and we choose the shortest path so at this point you've influenced our choice of whether we're doing active passive or active active there's no configuration that you need to do in the console for this this is all controlled from your customer device where you're announcing these routes so let's move on and talk availa a public virtual interface over Direct Connect so it provides access to Amazon's public IP addresses so this is all of the public IP addresses for that particular AWS region everything that's running there that includes things like s3 it could include other services that are running on AWS it could include the AWS the Amazon retail site when you set up a bgp session from a public virtual interface there are a few different requirements though compared to a private virtual interface we require you to use public IP addresses on a public virtual interface so if you've got your own IP addresses that you can use for this peering session and you're going to announce public IP addresses to us great nothing else needs to happen you just configure it in the console and I'll you what that looks like if however you don't have public IP addresses that you own or you aren't able to break up your network to be able to use those on a bgp session with AWS then raise a case with a double your support will actually issue you a / 31 so two IP addresses that you can use for this bgp peering session which point you can nap behind that on your end of the connection to reach all of these services so simply raise a case with AWS support if that's something you need for a public virtual interface the AES number that you use on the public virtual interface if you're going to use a public a.s number you will need to own that a s and we go through a verification process when you set up a public virtual interface where we validate the ownership of the IP addresses and the a s number that you've used when configuring it if you don't have a public a s number that's fine you can use a private a s number finally this inter-regional feature that's available within the US so what is it well quite simply a Direct Connect location is associated with one particular region so a private virtual interface gives us access to the V pcs within that region public virtual interface access to the public services within that region within the US however we actually announce all of the public IP addresses from all of the US regions at any of our Direct Connect locations so that means you could get a connection on the west coast but actually be accessing s services on the East Coast all through that single connection we recently announced that we've added bgp communities to these announcements so this was posted on the forum last week what this means is that when you look at the prefixes we announce to you you can now identify where they came from so if you see the 8,100 community tagged on a particular prefix you know that that came from the local AWS region to which you're connected if it's got 8200 on it it came from somewhere within the continent from one of the other regions and equally for traffic engineering purposes on your side you might not want us to propagate your routes beyond the local region so as you announce them into our network we look at the communities that you tagged them with as well so if you tag them with ninety one hundred then we'll keep them to just the local AWS region if you tag them with 200 they'll go to all of the AWS regions and that's the the default position within the US so what does the public virtual interface look like in our configuration well exactly all of the same parameters we talked about for a private virtual interface at the top there it's got a DX v identifier a VLAN IP addresses for the bgp session it's got an AS number both sides and an md5 key but you're going to see a slightly different announcement from the AWS side it's not a single prefix now it's going to be all of those prefixes I talked about and these vary over time so you might be aware that we actually publish a list of all of the Amazon IP addresses via an IP ranges JSON file that you can use to download and compare against this list if you need to on the customer side though you can announce to us whatever public IP addresses you want us to route to and this impacts all traffic that leaves that particular AWS region that's why we go through the verification process to check that you own them that process takes maximum of 72 hours usually a much shorter time and if you've used those IP addresses with us before it will go through much more of an automatic process you can announce those IP addresses to us and now all traffic leaving the Amazon Network destined for those IP addresses will go over this public virtual interface rather than over the Internet here's an example of the output again on a Cisco router in this particular case and you can see the a s path on the right-hand side you'll notice that 7 2 2 4 which is the one we use for Direct Connect is present on all of them but then beyond that you see another one and 160 509 is the Amazon global AAS number so we use 7 2 2 4 just for direct connect and then you're going to see the other Amazon AAS numbers beyond that for some of the prefixes as a community example here's a particular announcement that's coming over BGP where it's showing that it's tagged with the 80 100 and the 80 200 community so this is showing that it's an inter region prefix and that it's coming from outside of the local AWS region so how do we actually deploy all of this how do we order it what does it look like well here are the steps and the very first important one is make sure you choose the correct region or during a connection in the wrong region you a few few problems if you do just to be clear just delete the connections as soon as you've created it it's not a problem choose the region you want the connection the reason that's important is when you go to actually create the connection in the direct connect console we then populate a list of the direct connect locations and obviously they're tied to that particular region you then choose the amount of bandwidth you need and that's it that's your direct connect connection request it we will then send you by email an loa coa CFA letter of authority connecting facility agreement it's a document that says you have permission to excuse me you have permission to connect to these ports on the AWS reuters you're going to be using this with the facility provider to order that cross connect or with the partner if they're going to be providing connectivity the Loa CFA is sent to the route email address of the account that requested the connection so make sure that you are monitoring the email account for that particular address once you've received the Loa you then need to order the cross connect in our documentation we actually provide a list of the locations and what the process is for that particular provider some of them require this by email some of them have a longline portal that you upload this the Loa to so just follow their process to order the cross connect or a partner we'll be doing on your behalf once you've done that you're then able to configure your virtual interfaces now you can actually do this before the physical connection even comes up so once you've ordered it you've ordered the cross connect start configuring the virtual interfaces at the very very top of the screen is the decision as to whether this is a public or a private virtual interface once you make that decision the forum then updates below that to change some of the fields to match the items I was talking about earlier so now you fill in the details you're going to name this connection and you can see there the virtual interface owner is one of the options you've got so you can share this virtual interface into another AWS account as per the examples we had on the screen earlier once that's done just like in the VPN configuration scenario we give you the option to download a Rooter configuration there's a very basic configuration but it contains all the information you need for your end of the connection so contain the IP addresses for the peering session the a s number being used by Amazon the md5 key that you either chose or that you generated and all of the other details you need for configuring that connection so that's if you're ordering a 1 or a 10 gig dedicated port the process if you are doing this through a partner for one of those sub 1 gig connections is slightly different it's actually initiated by the partner so you're going to give your AWS account number to the partner this is your 12 digit AWS account number and you're going to have a discussion with them about how much bandwidth you need the partner is then going to configure that as a hosted connection for you and you'll go into your account and simply accept that hosted connection appears in the same Direct Connect console where you would have requested your own dedicated port once you've accepted that connection we're then back into the standard flow that we were following earlier configure a virtual interface configure our router so there's no difference once you've accepted that connection but remember you can only create a single virtual interface on that hosted connection ok now depending on how much resilience you've put into your solution you might have two connections going to two different Direct Connect locations we'd still always recommend that you put a VPN in place you know maintenance still might need to be done by your carriers your partners you might need to replace a route it's always good to have another backup in place so you can configure this VPN as a dynamic BGP based VPN as we talked about earlier in exactly the same way in parallel to Direct Connect we talked about the fact that from the AWS side if we see multiple ways out of a virtual gateway going by a direct connect and via a VPN will always prefer the direct connects first after that we then failover back to the VPNs and you would need to configure the same on your site so that you make pass selections there one other interesting variation of running a VPN with Direct Connect is to actually run it over the top of a Direct Connect so if you wanted an encrypted connection into your V PC or perhaps you wanted to reach a V PC that is in a remote AWS region so in the US you might have your direct connect on the west coast and you're running your V PC on the East Coast well perhaps you'd establish a VPN over that public virtual interface because within the announcements for all of the Amazon public IP addresses are the endpoints for those VPN connections as well so now you can take advantage of the Direct Connect that you have already on one coast and connect to resources on the other coast running over the Amazon backbone network so you can see the components here that you'd have to configure to do that you've got the public virtual interface at the top of the screen all the parameters that we had before and then running over the top of that we have our two tunnels for the VPN connection again running BGP so you then need to accept those onto your router and configure it appropriately to route to the different V pcs on the AWS side now I just wanted to touch on billing for both of these services so VPN connections pretty simple there are charges for each connection hour that your connection is present and then we charge for data transfer at our standard internet rates on Direct Connect we charge for port hours so this is a charge from the moment that your port goes active so when you first order that port we know that it's going to take a bit of time to organize that cross connect and to work with a partner perhaps to get their connection to your facility so we don't start charging you for that port until it comes up for the first time or if ninety days have expired whichever comes sooner over a Direct Connect you benefit from the reduced data transfer charges and one thing I wanted to identify here was that you don't pay for data transfer when you're accessing resources that are owned by other accounts so if you're downloading content from my s3 bucket you don't pay for that data transfer over Direct Connect you're only pay for data transfer from your own resources and finally if you're running a VPN over the top of Direct Connect in the scenario that was on the previous slide that gets charged for the reduced rate for Direct Connect not at the Internet data transfer rates so a few things to remember around Direct Connect it's one of our services that has that physical component to it so although you interact with it via the API is and via the console the end result is a physical port that you need to connect to so these ports are Lac third party data centers these are not Amazon data centers and they're there because we want you to be able to access them you're going to have to work with at least one other organization to achieve this connectivity if you're within the facility it's going to be the colocation provider it could be a network provider or a direct connect partner or it could be a combination of multiple if you're going to do connections to multiple thirty's so it's always going to involve a third party sub 1 gig connections only support single virtual interfaces that's quite easy to overcome if you need multiple you just request multiple hosted connections and run a diff over each one of them you can share virtual interfaces with other accounts so just because the physical connection lives in one account you can use it within another one and finally remember that the public virtual interfaces do include the hardware VPN endpoints that you can use for a BGP or static based VPN this is just an example of an implementation plan for Direct Connect and the reason I've put it up here is because of those third party engagements that are required usually for deploying Direct Connect I'd recommend that you do treat it as a mini project so put together a plan establish who should be doing what standard project planning and then stick to it work through that process you might have some complications along the way with perhaps carriers arranging connections but if you have something that everyone is referring to as the steps that are required this is something it's going to really help you succeed with the connection okay so just winding up we're going to talk about the cloud hub functionality that we have so within a virtual gateway if you have multiple connections be they over a VPN or virtual interfaces over Direct Connect if we see multiple connections all coming from different AAS numbers in BGP terms we'll actually route between them for you we'll acts as a hub to a hub-and-spoke network so this is not something that you go and turn on or turn off its default functionality within the virtual gateway so at this point we can provide that connectivity between your different locations if that's something you want some customers use it as a backup and have their own network linking their sites together one other common deployment that we see is customers choose to deploy their own VPN solution perhaps they have an established software solution that they use already and we have many on the AWS marketplace so the cisco csr the Sophos UTM there's various open source options such as open swan bios things like that so you can deploy a software vpm within your V PC of course in this case it does by the virtual private gateway it comes in through the internet gateway and terminates on that ec2 instance you also do need to consider high availability if you deploy a solution like this though so certainly make sure you deploy at least two VPN instances into two different availability zones and have appropriate health checking and failover between them one final interesting scenario is to combine those two things together so we can take cloud hub and a software VPN running in another AWS region connect the two together and provide access fire Direct Connect or VPN from the other locations so let me explain that a little bit more detail down on the bottom right there we've got one of your office locations perhaps it might have a direct connect into the virtual private gateway and it's receiving a BGP announcement for the V PC in u.s. East one in this example if you then deployed a software VPN solution into EU central one perhaps and established a VPN from those software instances to the same virtual gateway in u.s. East the prefix is now that are going to be announced from that V PC in EU central are actually going to be propagated by the virtual gateway to you over that Direct Connect so you're now actually benefitting from a single connection or in this case two office connections into AWS unable to route via the virtual private gateway to a V PC in another region so just to recap the topics that we covered there we talked about VPNs both static and dynamic how can we achieve connectivity using AWS Direct Connect via both public and private virtual interfaces cloud hub and software VPNs how you can use them together and then finally hopefully I've given you an insight into some of the steps required to configure all of these elements without I'd like to say thank you very much and I'd really appreciate it if you could complete the session evaluations thank

Channel: Amazon Web Services

Views: 65,862

Keywords: aws-reinvent, reinvent2015, aws, cloud, cloud computing, amazon web services, aws cloud, Networking, NET406, Steve Seymour - AWS, Expert (400 level), direct connect, virtual private network, vpn, Dedicated Network Connection, cloud computing event

Id: SMvom9QjkPk

Length: 53min 0sec (3180 seconds)

Published: Fri Oct 09 2015