AWS re:Invent 2017: Extending Data Centers to the Cloud: Connectivity Options and Co (NET301)

hello everyone thanks for joining good afternoon this is net 301 extending data centers to the cloud my name is Benjamin Feldon this is Sid Chauhan both Sid and I are solutions architects with AWS we are based out of New York City and I presented a talk with the same title last year it was then labeled net 305 so today we'll be presenting an updated version of that talk but since a lot have many new exciting releases from over the course of the last year a lot has changed so the session from last year can still be found online both the recording as well as the slides this is a 300 level talk so our expectation is that you already have a grasp of VP sees and ideally have had a chance to configure some our goal in this talk is to discuss the different options that you have for creating a hybrid environment between what you have running in AWS and what you have in your data centers outside of AWS so at the end of this talk I hope that you leave here with a good handle on what are the options that there are for you to create that chord activity and what are the architectural considerations that come into play when making those decisions for your business now the connectivity options are changing and so we've greatly developed the offering which has opened up use cases that did not exist before and so I hope that you leave here with a good vision of what it is that these new options are and how they could be relevant for you I'm going to start with a very quick level setting of terminology when we're talking about hybrid environments we're talking about network infrastructure that connects between storage and compute footprint running in AWS and some amount of footprint that you have running elsewhere so when you think about connecting a data center or a Colo or a SAS solution to AWS there are many use cases that come to mind so some examples are you could be thinking about AWS as a reliable site for object storage things like backup archival logging AWS could be your disaster recovery site offering you some geographic distance from where your applications are running in prod hybrid connectivity is almost always needed when you use workspaces as your VDI solution so you have these virtual desktops that are running in AWS but they need connectivity back to applications in your corporate data centers there are different flavors of split architectures these are cases where certain layers of an application are running in AWS some layers of an application or running elsewhere in that vein some releases that we have made this year now allow you to run a load balancer in AWS which has both AWS endpoints as well as IP based endpoints so there are a ton of use cases most of the customers that I speak to have a mixture of them and so they need to evaluate each use case what are the networking considerations that it has and then adapt their connectivity to match and that's where begin to talk about the solutions that AWS puts forward towards making this connectivity work so generally speaking we have three main options there's going over the public internet there's are creating a VPN connection or leveraging an AWS service called direct connect so going over the public Internet is pretty straightforward right our services have public endpoints your resources can have public IP is assigned to them so I'll talk today is going to focus on the other two options and so IPSec VPN is a technology that both authenticate and encrypts IP packets in the context of AWS this really breaks down into two main options there's AWS manage DPN and then there's software VPN that's running on ec2 and we'll talk about the pros and cons of each the other option is to use Direct Connect there are connect to the service you'll sometimes see this abbreviated to DX it's been offered since 2011 and what this provides is private and dedicated physical links into AWS which you achieve by connecting with us at one of 67 locations around the world and that provides a consistent network performance it would be private end to end which means that traffic traverses the areas backbone and not the internet and so is not susceptible to Internet weather type events and then for this we offer port speeds of one gigabit per second or ten gigabits per second or those sub one gig connections as well if you are using a partner these slides show some of the direct connect locations that are available for you to connect through these locations are these large colocation facilities where you are invited to come and meet us then once you are there you can physically connect to AWS you may have seen similar slides that we've shown in previous years and if so one thing that you'll notice is how many more locations there are now to choose from if I add a representation of the region's you'll see that the region in Canada is also new and now the arrows represent how each the reckoning location is honed to one specific AWS region that is its local region here are some more of the locations and again you'll see how many of them are new in fact we've added 25 over the last year alone and their regions so ole and London are also new and again each location is home to one specific AWS region now in the past connecting through a location would provide access to resources in the region that the location was home to that was true for VP C's as well as public IP s now this paradigm still exists but we've added a new one on top of it and in order to do that we've released a feature called direct connect gateway which opens up global connectivity to all of the AWS regions via each direct connect location this is true with the exception of China now you can still leverage the connectivity patent without the reckoner gateway which will connect your routers directly into your V pcs but with that pattern there is a one-to-one relationship between the location and the region that has opened up in terms of V pcs so with this new pattern by leveraging the rekha net gateway when you connect to a direct connect location you're effectively connecting to the AWS backbone and that opens up V PC connectivity in every public region as well as the public IP space of all of those regions there are other advantages to using this such as being able to connect to multiple V pcs over one virtual interface of one VLAN and we'll get into that a little bit later on Sid will walk us through the different architectures of this connectivity pattern but for now let's look again at the map slides and see what they should look like today so again these are the locations in North America and this is how you can begin to look at the REC connect connectivity going forward if I remove for a moment the locations and we focus on one example there's Equinix and Dallas Texas if you choose to leverage the direct connect gateway each location is now an entry to the global AWS network backbone over which you can connect to all of the public regions or it is an example here if we focus on the location in Perth Australia that one location could be an entry point to your entire AWS footprint via the backbone it can connect to VP C's in Frankfort or in Singapore or in Sao Paulo etc so this is a major and fundamental change in how we look at this service but before we get into the specifics of how you gain access to resources stickyswat a quick step back and talk about the different connectivity architecture options that there are so we've already established that we have a requirement for hybrid connectivity and we've noted that we'll be achieving it with either VPNs or Direct Connect let's begin to draw out what this looks like on the one hand you have your corporate data centers on the other hand you have an AWS region and that has both one or more V pcs as well as AWS services with publicly addressable endpoints so these are things like s3 or SES or dynamo DB or SQS our conversation today is about how do we connect these two things together so I'm going to move them aside and we can focus on what's going on in between we'll start with discussing the to VPN options that I mentioned before and the first one is AWS managed VPN when you use this option AWS will fully manage the VPN termination endpoint on the AWS side and we call that side of the tunnel the virtual private gateway of vgw for short as similar to other managed services this means that AWS takes of all of the underlying infrastructure as well as high availability so it's a region-wide highly available resource which means it can sustain an availability zone failure without performance degradation and we call the customer side of the connection the customer gateway or cgw for short the CGW represents the hardware or the VPN that terminates VPN on the customer side on the remote side manage VPN supports the latest features and standards that you would expect from a VPN vendor it's extremely simple and quick to set up a VPN connection this way you'll use the management console or and make an API call and create a VPN connection and we try to make things very simple by allowing you to download a configuration that you can then go and apply on your device and for that we support vendors like Cisco or juniper or 14n that doesn't mean though that if you don't see your vendor listed there the connection won't work it just means that you will have to download a generic configuration adapt it and apply it on your device once you've applied that configuration on your device you should be up and running with a working VPN connection directly into your V PC and then routing on top of that can be done either statically or using bgp now if you look closely at the configuration that you've downloaded you'll see that the vgw is represented by two separate Pablo addressable IPs and that's how high availability is achieved this is the behavior by default when you bring up that connection it will consist of two tunnels it's not a configurable thing that gives you an idea of how seriously we take high availability the cost that's going to be associated with one connection will include both of those tunnels whether you use that second one or you don't you don't have to bring up that second tunnel in order for the connection to work but if you're looking for a multi availability zone highly available connection we recommend that you do we also recommend that you think about resiliency on the remote side so if you can you should allocate a separate device for the purposes of high availability and now you bring up a second VPN connection from that second cgw into the vgw of your VPC each of those will have two tunnels and so there'll be a grand total of four when you leverage high-availability on both ends once both of them are established traffic will begin to flow through one of them and you have the influence - you have the ability to influence which one of them that is in both directions you do that with BGP and that is influenced on a per Network basis they won't both be used though at the same time to access the same network so think about this as an active standby configuration so now we know what's involved with setting up a connection for one V PC if you wanted to connect to a second V PC using VPN you have to repeat the same steps and you start by creating a second v GW for that V PC because they are unique / v PC and then you create two VPN connections towards that second v GW probably reusing the same CDW's and so there will be four tunnels for each and a grand total of eight and of course you may want to connect to more than two V pcs and so these are the steps that you need to repeat this is how I'm suggesting that you think about connectivity options it's by looking at it with these dimensions flexibility cost resiliency and performance so in that context AWS managed bpn is very simple very quick to set up it offers the latest security as well as BGP routing you get out-of-the-box H a although we encourage you to think about high availability on your end as well you pay five cents an hour for each VPN connection which will include those two tunnels and you can get up to 1.25 gigabits per second but that's limited at the vgw means which means that all of the VPN connections to that V PC share that bandwidth these are some of the highlights of what is new with AWS managed bpn from the course of the last year so just to call out a couple of things which you wish you may have missed you can now bring your own autonomous system number your ASN to the AWS side of the connection as opposed to just accepting the pre-shared keys used to establish trust can now be configured as well as the IPS inside of the tunnel and we've added cloud watch metrics so that you can monitor an alert on your connections activity so the second option is to use software that's running on ec2 this is when you create a virtual VPN appliance to terminate the VPN connection on the AWS side we typically see customers doing this if they're trying to stay uniform with their VPN provider of choice across all of their sites and or if they're trying to use a vendor specific feature like a Cisco dmvpn or a sophist UTM suite so a specific routing protocol or a security feature that sits on top of the tunnel in order to get this up and running you need to instantiate an ec2 instance connect the V PC to an Internet gateway make sure that the instance is reachable via an elastic IP and then you install the VPN software so this can be a commercial product like a Cisco like a 40 net or it can be an open-source product like an open Swan or an open VPN you can't actually one click deploy VPN software from the AWS marketplace which will make this a lot simpler now in this scenario you're establishing your VPN connection directly into the C into that instance and so the vgw does not come into play at all and unlike managed VPN it is now the customers responsibility to maintain high availability and scale and so you will need to instantiate a second VPN clients in a second availability zone for high availability it will also need to build some fairly simple automation or some of these vendors have already published their own so that if a failover is needed the VPC route tables get automatically updated to send traffic to that second VPN appliance there is going to be a little bit of a lag time that's involved with that we see failover times that are slightly longer with this option than the managed VPN option if I summarize this option this is where you're deploying VPN on ec2 it can be an open source or a commercial solution this can be leveraged in advanced architectures like the transit V PC which is a topic that CID will expand on later a little bit it's the customers responsibility to maintain high availability and scale here you are paying for the ec2 instance hours and depending on the VPN software that you've chosen there may be vendor licensing and your bandwidth is going to be a function of which ec2 instance type in size you've chosen so if you choose one of the beefier instance types you can get multi gigs per second from each instance okay so we have an understanding of the to VPN options I want to start talking about Direct Connect and the conversation here starts with an ask from our customers that they be able to truly leverage their cloud resources in the same way that they do between the different data centers which requires a private end to end connectivity entirely disconnected from the internet and so a consistent network experience how does the service work you can find the list of locations that are available in the product details page this is a list of locations if you remember from the map slides that I showed before there's these they are these large colocation facilities that we are already established in and what that means is we own and operate devices in cages that belong to AWS and we've connected between them to our backbone keep in mind these locations are not where the region is they're not where a specific availability zone is they're external to the region so once you've identified which location you'd like to connect through you need to establish the physical connectivity and this is an area where there's sometimes a little bit of confusion so I want to dig into that there are essentially three different connectivity scenarios and the first one is relevant if you have presence in that colocation in which case the reckon it cannot be simpler you simply log on to your account create a direct connect connection and that represents a physical port you need to tell us which location you're in and if you're interested in a 1 or a 10 gig connection and that's it those are all of the questions that you need to answer that will trigger a process at the end of which you can download an Loa a letter of authorization this Loa means that we have allocated a port solely for you on our devices you are now authorized to connect to it whenever you're ready at that point you take that Loa you give it to the Colo provider and you request a cross connect between your router and our device once that cross connect is established you are physically connected to AWS and you can now start connecting to resources but we'll get to that bit later on the second scenario is what if you don't have presence in a colocation that's not a problem you will need to engage with one of our partners or a network provider to build out a circuit between your data center and that colocation you'll go through the same process that I described before you tell us if it's a 1 or a 10 gig port but now you take that Loa and you give it to the network provider and they request the cross connect on your behalf we have a list of APN partners that are supporting to reconnect that is available online these are partners that are well-versed in building out circuits into Surma or of the Direct Connect locations but if you're already working with network providers even if they're not on this list talk to them ask them if they're able to build you such a circuit into the location that you've chosen so what's going on behind the scenes in this scenario is that these partners have some piece of equipment at the colocation and they extend layer 2 connectivity between your data center all the way to that port the one that's mentioned in the yellow way now you may recall that before I mention that we also offer port speeds of below one gigabit per second it is in this scenario with that option fits in only if you're using a partner you can also order connections with a port speed of 50 100 200 3 4 or 500 megabits per second keep in mind though that if you are using that option the sub 1 gig option you will only be able to create one virtual interface on top of that that's going to make a little bit more sense when Sid talks to us about virtual interfaces so keep that in the back of your mind the third scenario is relevant if you're already engaged with a service provider that's running a managed network that's connecting your different locations and you now want to extend that manage network to include AWS the underlying technology could be MPLS it could be some other backbone service you may recognize brand names such as AT&T net bond Verizon SDI level 3 Cloud Connect these are solutions that fall into this category and these providers typically have their own to reckon act in their own accounts and they connect between your data centers and your V pcs on top of them as you're making these decisions on how to physically connect I want you to keep in mind these considerations in whose account will the direct connect port be created so depending on the scenario that we just talked about if you're using a partner ask them they may be using their own or they may be asking you to create it in your account which leads us to the next consideration which is what then does the process look like for creating additional virtual interfaces for the purposes of connecting two additional V pcs or additional accounts who is responsible for the routing between the corporate networks and the AWS networks and what are the costs that are associated with this connectivity so the best recommendation I can give about all of that is if you don't already have presence in one of those locations talk to the network providers that you're currently engaged with and ask them what they can offer you in terms of getting to the location that you've chosen ask them these questions so that you understand exactly what's being offered and I also recommend that you loop in your AWS solutions architects so these are folks like sitting myself and have him or her participate in the conversation where you're debating these different options now I've already brought up costs I want to discuss a couple of finer points here you may be aware that data that's flowing into an AWS region is always free the data flows that are charged are for egress so data egress or data out over the REC connect will be less expensive than over the Internet when I say over the internet I mean the pricing that is in effect when data is flowing out of a V PC or out of the region over the Internet whether it's VPN door in the clear when you're evaluating the direct connect costs you need to not only think about the data out the data egress but also the port hours and that will depend on the port speed that you've selected as well as what was involved with getting to that location or establishing your physical presence there now you may be wondering now with Direct Connect Gateway offering the connectivity to regions all over the world through the backbone how is that priced so this is a table from the direct connect pricing page that kind of explains how this works so as I mentioned before data that going into a region is not going to be charged and that is regardless of what that destination is so let's think about that for a moment that's a major advantage to using the AWS backbone right because if your use case is very heavy on ingress there are significant cost savings to be had by leveraging the backbone for as much of the distances you can and then for data egress the Direct Connect locations are grouped together so for example all 28 of the locations in the United States have the same data out costs associated with them the regions are also somewhat grouped together and so consulting with this pricing page you can get a sense of what is going to be the cost for getting data out so as an example let's say that you have data that's flowing out of your VP see in the Singapore region that falls under the asia-pacific group and let's say that you are connected using Direct Connect in Equinix in Frankfurt that falls on the Europe and so the price will be 9 gigs sorry 9 cents per gig and that kind of leads me to the next question which is how do I choose the right location to connect through so certainly cost will be a factor in that right there's the egress pricing which we just figured out there's building the circuit or establishing the Colo presence so I'm calling all of this end-to-end costs another factor is going to be latency that should play a major role in you making this decision and you can actually connect with your AWS account team and work on figuring out some estimated latency times between a specific region and a specific location and then finally how are you connecting to that location from your data centers does that meet your performance resiliency and cost targets so now we kind of know what are the physical connectivity options how should we think about cost let's talk about resiliency as it pertains to direct connect let's assume that you have presence in one of the coalos you've completed the cross connect you are now connected between one port on your router and one port on our device earlier this year we launched support for link aggregation groups or lag for short which means that you can now group together several physical connections and treat them as one managed single connection you can bundle up to 4 ports of either 1 or 10 gigs that's actually one of those limits that you can ask to increase so as an example let's say that your connection your circuit between your data center and the location can support 40 gigabits of bandwidth if you order for 10 gig ports you can group them together and deploy virtual interfaces on top of them as if they're one connection keep in mind though that they connect to one device on the AWS I and that kind of brings us to the next question which is let's put a side lag for a moment what does all of this look like in terms of resiliency in terms of susceptibility to failure if we think about the physical elements that are here we can potentially can point to potential points of failure the customer router connected by a single port a single cross connect into a single port on the AWS device you may be using lag for performance but that connects to a single device now that piece of hardware is connected redundantly to the backbone but up to it there are fiber optics line cards power supplies software so all of the things that you would concern yourself with when connecting between your different data centers they still apply here and what is our goal our goal is to design connectivity that matches the level of resiliency that you have in your AWS workloads right so your AWS workloads are probably architected in a multi AZ fashion they're attempting to avoid any single points of failure so let's consider VPN as a backup this is very simple to set up the cost isn't going to be bad at all when you use the ADA BS managed VPN option we will automatically favor going over the reckon X as opposed to VPN when both of them are available so inherently we treat this as a backup solution but VPN may be less performance will likely be not as consistent in terms of the network experience and so you need to think about is this acceptable connectivity for the duration of time while my Direct Connect is being fixed or while my circuit is being worked on so one notch up in terms of resiliency is another direction a link when you order a second connection from the same account in the same location we will automatically place you on two different pieces of hardware and that will provide device redundancy you've gained device redundancy on the AWS device but you'll likely want to do the same on the customer device and so you may want to add another router in your cage or build out Second Circuit from one of your data centers now as soon as we start talking about to Direct Connect ports accessing the same networks we should talk about how they use together remember though this is not link aggregation because they are connected to two different pieces two different devices they're not grouped together so by default we will multipath between them which means we will use both of them at the same time and so effectively this is an active active configuration to 10 gig ports will provide 20 gigabit 20 gigabits of bandwidth but there are cases where customers choose not to do this and they configure things in an active standby configuration we typically see that if they have a stateful firewall and they're trying to avoid asymmetric routing but in this scenario you can influence which one of these links is preferred you do that using bgp a Espace prepending and with local routing decisions on your device so you can set the preference of which one as well is used now while these two devices are separate separate pieces of equipment they are in the same physical location so if the workloads that you are supporting are designed to span multiple availability zones in AWS or in other words they're designed to withstand a facility wide failure you haven't matched that level of resiliency in your connectivity architecture by connecting to connections to the same location and now with the reckoning gateway this could be your entry point to your entire AWS footprint and so that becomes even more concerning so the answer to that problem is to build that second the reckon act link via a second Direct Connect location and that will provide full facility redundancy if you remember the map slides that I showed before there are a lot of locations to choose from that's how you go about adding that layer of resiliency so as an example if your data centers are mostly located in the northeast of the United States you may want to build your first circuit through Equinix in Ashburn and maybe that second one using coresight in New York or in Reston so now we're on a properly designed fully redundant architecture that's designed to withstand up to a full facility failure but for good measure we still recommend that you add a VPN and this VPN again will not provide the same connectivity the same experience but it is there as a second layer of redundancy so regardless of which resiliency methods you choose to employ I strongly recommend that you test failure scenarios and that you do so on a periodic basis so every if I reviewed the ranking act as a whole this is a service that's offered to every public region through 67 locations around the world expect to be able to download your Loa within 72 hours although it typically takes much less building out a circuit building out a presence in a Colo will take longer than that when you think about resiliency think about VPN think about adding a second to reckoning link ultimately think about a second or a connect location your cost is going to be a factor of the port hours and the data out which are going is going to be less expensive than over the Internet and any provider charges and performance is going to be either 1 or 10 gig depending on you've chosen all those sub 1 gigs options if you're using a partner the more connections you add the more bandwidth so I also want to call out what is new with the reckon act from the course of the last year so first of all we offer many new locations as mentioned a couple of time this list is always expanding and in fact if you go to the State of the Union from the networking truck today you may hear about some more locations that are being announced similar to a TBS managed VPN you can now bring your own ASN to Direct Connect that's true for private ASNs not public ones cloud watch can be used to monitor the rekha net connections we support ipv6 you can link aggregate a bunch of connections together now and finally the REC Connect is now a HIPAA eligible service so I'm now going to hand this over to Sid to talk to us about what are we actually connecting to so now that we know what our options for connectivity are and how to layer resilience into an architecture let's see how to pin access to resources over these connectivity options let's start by talking about AWS manage VPN when you create an IPSec VPN tunnel to your V PC you can access resources inside the V PC using their private IP addresses this includes ec2 RDS lambda redshift and many more such services but there are exceptions you cannot access the network load balancer elastic filesystem VPC endpoints including the recently released private link endpoints are not accessible the V pcs DNS private DNS is also not accessible and just to be clear this is just for the V PC and not the resources sitting outside the V PC like s3 DynamoDB which are in the public AWS IP range now let's talk about Direct Connect Benjamin mentioned that we recently released it connect gateway which gives you access globally to all areas regions except China but I want to take a step back and see how things work prior to its release when you connect it directly to the virtual private gateway it is important to understand how that works because that model is still supported today and I'm sure many of you are still architected in that fashion once we look at that model then we'll go talk about direct connect gateway see what the differences are between them so that you can go about leveraging the newer model so let's start by talking about the previous model let's say you have an AWS infrastructure which consists of multiple V pcs brought test a V PC they're isolated in their own accounts now in order to access resources you need to create a virtual interface for a V PC it's called the private virtual interface while doing so you have to specify which virtual private gateway and which V PC you want to connect to you also have to specify a VLAN ID now all traffic which is destined to this V PC should be tagged with this VLAN ID by our routers as the traffic is being sent to the AWS Direct Connect devices over this VLAN ebgp session gets established over the ebgp session AWS devices will advertise to you the VPC side arranged and what you advertise to us is up to how you configure BGP at your end but remember that BPC has a limit of hundred routes when it comes to dynamic routes and that limit applies to Direct Connect as well so you might want to summarize your routes or even advertise a default route if that fits your use case configuring all of this is very simple then you create the private virtual interface AWS n gets Auto configured and you get an option of downloading a configuration file which you can go and apply on your router now you repeat this process for every V PC you want to connect to so it's a different VLAN a different private virtual interface and a different bgp session for each V PC now for resources outside the V PC you create what's called a public virtual interface this will coexist on the same Direct Connect port where it will have its own VLAN ID and its own bgp session and as part of bgp route advertisements we will advertise to you AWS public IP range so that was how the vgw base model world so let's see how things work now that we have released their connect gateway so let's say you have a SS resources in u.s. West Oregon region which consists of an app 1b PC and you want to connect to this resource to the super nap Las Vegas facility so now you create a direct connect gateway as step one next you'll create a private virtual interface but now instead of the worship private gateway you're terminated on the direct connect gateway it's still the same process around VLAN ID BG sessions next you associate your worship private gateway to this new Direct Connect gateway and that's it now the dead can I get way will start advertising the side arrange of that VPC to your router's and hence you can go ahead and access it now if you had a second V PC for app to you would simply associate the virtual private gateway of that V PC back to a direct connect gateway and now through bgp route advertisements direct connect gateway is going to advertise the side arrange of both V pcs and you get access to both now let's say you had a dr v pc for your app one in the singapore region and you wanted connectivity into that simply as simply associate the virtual private gateway of this new V PC in Singapore back to the same RIT connect gateway you can only see a difference through one private virtual interface one VLAN and one bgp session you are able to access v pc is globally now leveraging the duet connect gateway you can access resources in the b pc using its private IP addresses and this includes ec2 EFS NLB RDS and many more such services and this V PC can be located in any air bliss region so now you have your own global private network in AWS which is now acting as an extension of your data center so now that we understand how both model work let's do a comparison of how how what the differences are on the top you have the VG w based model where you create one private virtual interface for V PC giving you access into resources in the area plus region with the direct connect location is home to below we have the dear can add gateway based model where you create one private virtual interface but this gives you access into V pcs globally over one VLAN and one BGP session now there are a lot of similarities between the two models so the process of creation of private virtual interfaces and ordering new Direct Connect circuits is still the same the a SS resources which you can access inside AWS ec2 NLB all of that remains same the resiliency model which Benjamin talked about having multiple Direct Connect locations that still remains the same and finally the V PC route limit of 100 for dynamic routes that applies to both the models now we were talking this in the consist of context of a single account so let's see how the multi account model works with the connect gateway now this is the infrastructure we had set up previously now let's say if we isolate the two application V pcs into their own accounts now Direct Connect circuit can be used to access resources in multiple accounts but that can a gateway is a resource local to an account so if we put the direct connect gateway here in the app 1 B PC as such you cannot connect app to V PC to this written at gateway so you'll have to create a new direct connect gateway in the app to V PC you can create a private virtual interface and push it into this second account and then associate the app to be PCs and any other V pcs in that account to that written at Gateway so in essence you will require one grid connect gateway per account and that will give you access to the V pcs in that account now you might be familiar with the concept of V PC peering which allows to V pcs to communicate with each other now let's say we have a shared services V PC and a production V PC which we have set up and we have paired them together let's see how this works with their connect gateway so if you set up a private virtual interface into the shade services V PC and you wanted to leverage the direct connect gateway as well as the V PC peering to excess resources in the prod bpc this is transitive routing and BPC peering does not support it so this model does not work you will have to associate the Virtual Private gateway of the prod bpc directly to the direct connect gateway and access it natively that way now about two years back we released V PC private endpoints V PC private endpoints gives you access into a robles resources sitting outside the V PC like Amazon s3 and we recently added support for DynamoDB as well that feature is now renamed as gateway V PC endpoint so if you have a V PC a gateway V PC endpoint attached to your production V PC and you wanted to leverage grid connect gateway as well as the V PC endpoint to access your resources this again is transitive routing and is not supported so you cannot access gateway V PC endpoints over direct connect you can however build a fleet of proxy instances in your V PC and proxy all traffic from your on-premises networks but be mindful that you need to configure your on-prem devices to use this proxy so this is not a transparent process now we also recently announced interface V PC endpoints interface V PC endpoints gives you access to a robles services like Amazon Kinesis elastic load balancing API is ec2 api's and this works a little different interface endpoints appear as a network interface inside your V PC and gets a I P address from your B PC side arranged now if you wanted to access these interface endpoints from your on-premises networks through the direct connect private virtual interface this is supported so you can access these interface ten points or word read connect as part of the new launch of their kinetic gateway we also introduced a change to how public virtual interface works now if you had a public virtual interface set up earlier it used to give you access to the a tubeless region it was home to but now it gives you access to all arab less resources globally and here we are talking about non VPC resources like s3 DynamoDB ec2 public API endpoints and AC to public API s-- IP atlases now as part of the route advertisement we will advertise to you the entire AWS side arrange public IP range and this includes over 2,000 prefixes so this might get a little overwhelming and you can actually go and check this link that's where we list all the IP addresses so we do make it possible for you to filter out some routes and you can do it using you can do it in two ways so first is based on the geography so you can say I want to filter out routes or accept route only of the region that my Direct Connect location is home to or you can say I want to accept routes of only those a diverse region which are in the continent that my Direct Connect location is home to and you can do that using bgp communities the second option is to filter out using Erebus services so if you look closely at the JSON document which contains all the IP addresses you will see that we list out prefixes based on a SS services so you can say I want to send traffic only to Amazon s3 and you can use this information to do that in your routers now be mindful that currently we only give out this distinction for s3 ec2 cloud front route 53 and code build when creating the a Douglas manage VPN Benjamin mentioned that we give out two IP addresses for high availability these are public IP addresses and this these addresses are part of the IP range which we advertise over public with so what this means is that now we can access these IP addresses over the public virtual interface and we can use this to our advantage so instead of connecting to the VP see through reddit connect gateway we can create AWS managed VPN IPSec encrypted tunnel and this traffic will flow over public virtual interface now if you have compliance requirements which requires end-to-end encryption and your application is not using TLS as a cell then you can consider this option now I hope you have a good understanding of sort of how the direct connect get the model works but before we wrap grab this topic up I want to talk about some key considerations so let's say you have a arabela's global infrastructure which VPC is spread across multiple Erebus regions to gain connectivity into this infrastructure you set up to dread canet gateways with private virtual interfaces into both now if you wanted to route between 2 v pcs using the direct connect gateway this is not supported drit connect gateway cannot route between 2 v pcs it cannot peer to v pcs it is only meant for hybrid traffic's so for traffic between your data centers and the V PC and vice versa if you had to be pcs that overlapping IP addresses you cannot attach them both the same Dre connect gateway if a V PC was already attached to a dreaded gateway and you try to attach it to a second-rate connect gateway that is also not supported so you can have one V PC attached only to one did it can it Gateway at a given point of time now in this slide here the u.s. West to Oregon V PC is directly connected to to your routers to the private virtual interface using the vgw based model so if you have that connectivity today you cannot attach your B PC directly to the direct connect gateway so you can leverage either the vgw based model or the direct connect gateway model but not both at the same time now let's switch gears a bit and talk about something which is very relevant to our customers today since we have heard a lot of feedback from you guys that you had use cases which were not met by the native way of accessing resources over Direct Connect and VPN so let's look at what those concerns were or concerns are so customers are connecting the B pcs to remote networks which they don't trust and hence they want to implement this layer 7 security stack for all hybrid traffic and they don't want to do it for every V PC that they have in their AWS infrastructure they want to do it at a centralized location now unfortunately both vgw and a direct connect gateway don't support layer and filtering although you still have layer 4 filtering using security groups and if layer 4 filtering is your use keys and you should be using that we also heard complaints that customers were connecting to SAS providers and third-party vendors who had overlapping IP addresses and there is no easy way to handle such situations Benjamin mentioned that when you're using a robles managed VPN you have to create 4 VPN tunnels for every V PC you connect to now as you grow into number of V pcs creating more and more VPN tunnels might not be as agile as creating new v pcs especially when you are considering change management processes and the approvals required to make configuration changes to on-prem devices so from those requirements emerge the transit V PC architecture the whole idea is that you'll connect remote networks and translate all the traffic through a pair of ec2 instances now this is not an aw a service it's an architecture which is built using aw services so here we leverage both AWS managed bpn as well as ec2 software VPN to build this transitive architecture so you have two spoke Vee pcs here you have a spoke PP CA and a remote customer side and you want to send all traffic through a pair of ec2 instances so we create VPNs from the BG double use of the spoke VP C's to the transit ec2 instances sitting in the transit V PC now let's see how does this looks of at scale we have a transit hub b pc where we have a pair of ec2 instances we have bunch of spoke v pcs and the spoke v pcs can be located anywhere in any area of this region we set up a mesh of VPN tunnels from the spoke v pcs to the transit ec2 instances using a Bueller's managed VPN the transit hub b pc has connectivity in tune on AWS non v pc resources like s3 and ec2 using v pc endpoints you connect your remote office through VPN and you connect your corporate data center through direct connect leveraging the detached vgw the tash BTW is a b GW not attached to any b pc and it can be used to bridge the direct connect and the VPN infrastructure now with this architecture we are able to fulfill those use cases you now can just set up a pair of VPN tunnels from on-premises to the transit ec2 instances and as more and more V pcs are deployed they just create tunnel to this ec2 instance in all that all the VPN creation is handled in B P in the Erebus infrastructure using automation you can implement l7 security stack on the transit ec2 instances the transit ec2 instances can also do NAT and higher IP addresses in case of overlapping IP ranges they also provide access to V PC endpoints which were not otherwise accessible over VPN and this infrastructure can span the globe so you can build your own global VPN infrastructure now a few things to remember around this architecture we are using a pair of ec2 instances for high availability and these instances are in different AZ's we are using BGP for all the routing and failover so that's very important we recently published a solution on our website which leverages Cisco CSRs and lambda functions for automation so do check that out several third-party vendors have similar solutions published like cisco juniper aviatrix and you can also use open source software like open span Open VPN to implement something similar now if you have transit be PC architecture setup it does not mean you always use it so if you have traffic between B pcs which does not meet those criteria so you have to be pcs in similar trusted zones you don't have to send traffic between them through the transit ec2 instances you can still leverage V PC peering without breaking the architecture and in this scenario V PC peering is preferred over the transit EC transit ec2 instances similarly if you have traffic which is initiating from your data centers destined to a V PC which does not fall in any of those use cases again you can leverage dead connect gateway and access the V pcs directly bypassing the transit ec2 instances keep in mind the transit ec2 instances have limited bandwidth and you are managing them on your own so the less you use them the less you saturate them the better now at a global level let's see how this works you have a transit hub B PC in US east connecting to be pcs all over the world now if you see in this picture the V PC in India and V PC in Europe have to come all the way back to us is to communicate now if those VP's are really chatty you don't want that so what you can do is you can create a local transit VPC in that part of the world connect the two V pcs in India and Europe to that transit B PC and then bridge the two transit B pcs together that's how you would scale at the global level so I hope this gives you an idea of how to transit V PC works and sort of how you can leverage that I'll hand it over to Benjamin to wrap it up so I want to go back real quick to what we set out to do in today's talk we compared and contrasted AWS manage bpn and software VPN we talked about Direct Connect and how that requires to first identify which locations you want to connect through and solve that physical connectivity with with the right scenario you want to think about resiliency factoring the recommendation that we made to use to direct connect locations for full facility redundancy and then you begin to layer on top your logical connections to resources so that's how you begin to support the workloads that you have running in AWS think about those workloads in these dimensions think about them as in terms of flexibility cost performance resiliency how much bandwidth does each use case need how do you estimate their data in and their data out how sensitive are they to a break in connectivity or a degradation in performance and then based on that you make an actionable plan I can't stress enough the importance of not just designing for resiliency but also testing and out please don't skip this part and do so on a periodic basis I hope that we've given you some food for thought when it comes to the newly available features and architectures so between the direct connect gateway and transit VPC there are now use cases or architectures that didn't exist before and they speak directly to requirements for global reach to regions all over the world with things like lag interface endpoints ipv6 these are things that should help some defy how you do things and finally talk to your AWS team your account managers your solutions architects your technical camp managers and and lupus in so that we can help you make informed decisions with that I want to thank you all and please remember to fill out your feedback forms it helps us improve the content these are sessions that you may want to check out later in the track and thank you very much [Applause]

Channel: Amazon Web Services

Views: 16,729

Rating: 4.830986 out of 5

Keywords: AWS re:Invent 2017, Amazon, Networking, NET301, AI, Connect, AWS Direct Connect, Enterprise

Id: lN2RybC9Vbk

Length: 58min 21sec (3501 seconds)

Published: Thu Nov 30 2017