AWS re:Invent 2018: Extending Data Centers to Cloud: Connectivity Options & Best Practices NET302

hi welcome we are here for extending data centers to the cloud connectivity options and best practices now we'll be spending the next 60 minutes together so it's only appropriate that we get to know each other a little better so starting at the back and I request you to stand up and give an introduction about yourself I'm just kidding my name is said I'm a Solutions Architect with AWS I beam with AWS for four and a half years now and this is my third year repeating this session with the same title name and it's been amazing to see how AWS has evolved over this years and this session along with it I was also fortunate enough to author the AWS advanced networking certification study guide so if you have any feedback or questions around this please catch me after the session now we are all network architects network engineers enthusiasts in this room so we know that networking and connectivity is fundamental for our applications but I do want to stress on the importance of choosing the right connectivity type networking is cool right but its sole purpose is to serve end-user applications hence the decisions we make and the networks and the connectivity we build is so that a business critical applications can communicate so it's critical that we make the right decisions in choosing the connectivity options so by the end of this session I hope you have a clear understanding of what the various options are for connecting into AWS and more importantly what's correct for your workload and we'll talk about different pillars through which we will evaluate each and every option to come to that conclusion finally we will talk about what's new and how it impacts your decisions when making this connectivity architectures now today we are talking about hybrid IT connectivity so let's do a level set on what hybrid environments mean so the idea is that you have your own data center and then you have Erebus infrastructure and you want to connect them but why because you have workloads you might want to archive your on-prem data into AWS you might want to create a disaster recovery site in AWS or do an actual application migration or you're launching virtual desktops in the cloud and they need access to internal on-premise systems you might be running a split to your application where some tears are in the cloud while others are on prem in reality it's a mix-and-match of all of these workloads but one thing is clear the connectivity better be done good to support these workloads so they are broadly 3 ways of connecting into AWS number one use public internet the idea is very clear you expose your systems to internet and then you assign public I piece to the herbalist infrastructure and have them communicate over public Internet is it a good idea if you ask this guy he's gonna say yes go ahead but if you ask your security teams they might not be ok with it the bottom line is there are some workloads which can use public internet but for most we want to look at the other options so the second option is VPN where you create an encrypted site-to-site tunnel between your datacenter in AWS it's still over the public internet but now it's encrypted and authenticated there are three ways to terminate VPN on AWS and we'll go in one-by-one and more into more details and we'll also talk about the transit gateway which was released yesterday the third option is a SS Direct Connect where you create dedicated circuit between your data center and AWS this gives you consistent Network performance and you get speeds up to one gig or 10 gig and you can even go sub 1 gig now you connect to us through third party Colo facilities we call them AWS Direct Connect locations we have 89 locations and growing across the globe this gives you a snapshot of few of the locations and the idea is that through any of those locations you can get connectivity into the AWS global infrastructure and this is enabled by the a robles global backbone so here you have connectivity into Perth and from there you're getting access to all e regions except China okay so now we now know broadly what our options are let's dive deeper into each of these options and evaluate them but how do we evaluate them will use these pillars flexibility think about feature and functionality think about how the connectivity option can adopt to your ever-changing workloads we all have fixed IT budgets so cost is important and we talk about that when you architect your workloads in AWS we always say go multi a-z what that means is that you are deploying your virtual machines and your infrastructure in multiple data centers which are miles apart and we want to have similar resiliency while connecting to that infrastructure so we'll talk about resiliency finally performance you know your workloads best so keep in mind what kind of performance you're looking for and we'll talk about that as well let's start by talking about VPN connectivity architectures so on the right we have customer data center on the Left we have AWS infrastructure which consists of multiple V pcs and what we are concerned about today is what's in middle so let's bring an internet because VPN is over Internet now there are three ways to terminate VPN on AWS the first one is AWS manage bpn on the Virtual Private Gateway what shall private gateway is a fully managed endpoint or a gateway when I say fully managed I mean we take care of the underlying infrastructure patching cabling VPN configuration high availability failover all of that you also see something called cgw that's customer gateway that's a logical representation of the VPN termination endpoint at your data center now this water private gateway is quite feature-rich it supports latest cryptographic algorithms it has support for NAT traversal the IPSec tunnels are fully customizable so you can choose your own custom custom pre shared key in our IP addresses of the tunnel are configurable you can go static routing or BGP and if you're using BGP you can bring your own ASN and apply it on the Virtual Private Gateway and we also have support for cloud watch metrics which you can use to monitor the VPN tunnel now creating the VPN is very easy using an API call or through the arab list management console you can create the VPN connection when you do that the AWS n gets auto configured with the IPSec and the BGP configuration you can download a configuration file and apply it on your router and this brings up the VPN connection once the VPN connection is up what can you really access well a lot of things and the reason I had this slide up here is because everything which you see new was not available last year so now we have added support for private link and all the services backed by the hyper plane which we discussed last year so network load balancer elastic filesystem and the newly released Amazon route 52 resolver which lets you query route 53 private hosted zone of your VPC so let's focus on what's not axle so the dot - of the V PC that's the DNS IP you cannot access it so if you want to access DNS use the route 53 resolver service gateway V PC endpoint which allows access to Amazon s3 from within your V PC is not accessible and just to be clear this is only for the V PC so we you cannot access the era blessed public IP range over VPN now when you look at the configuration file you download you will see we give our two IP addresses and this is how we manage high availability these two endpoints are highly available and multi multi easy it's recommended that you create tunnels to both these endpoints and this is a default behavior now you need to think about resiliency at your ends so we hope you'll have 2 VPN termination endpoints and hopefully in two different data centers if possible so you'll create a VPN connection from the second cgw to the vgw so now you have 4 VPN tunnels when considering high availability at both your n and AWS now then you have two parts to reach the same network one will be actor one will be standby and you can influence that using bgp parameters like a spots prepend now we have been talking in the context of one V PC and one worship private gateway so if you had another V PC you repeat the same steps and create four more tunnels to the second V PC now think about that at scale creating four VPN tunnels for every V PC you want to connect to you have ten V pcs hundred V pcs you will end up creating hundreds of tunnels that's that's not good we heard from you yeah we heard your feedback and you are not happy with this kind of an architecture so let's call this architecture architecture that needs fixing and we'll come back to it let's recap the inner bliss managed VPN on the Virtual Private Gateway it's quite feature-rich but it lacks in flexibility in the sense you need to repeat and create more tunnels for every V PC resiliency is good at multi a C and you need to think about resiliency at your end you pay for what you use you launch more tunnels you pay more and from a performance standpoint you get up to one point two five gigs per VPN tunnel and you can scale them horizontally and get more bandwidth but we don't do a CMP we don't support a CMP on this so for a given prefix you can use only one tunnel ok let's talk about a second option terminating VPN on an ec2 instance so the idea is very simple you launch an ec2 instance you load it up with a software of your choice you can use the e robles marketplace to one-click deploy software or you can use any open source software you configure the VPN and the IPSec and all the BGP configuration on your own you do the same on Prem and then the VPN tunnel comes up you probably want a pair of ec2 instances for high availability and build some kind of an automation around it so that if the primary fails the standby can take over now most vendors like Cisco avy Atrix juniper Palo Alto everyone has some kind of pond automation in place to help you do this now let's bring back our architecture that needed fixing and see how we can use VPN termination on ec2 to fix this let's get rid of all those hundreds of tunnels let's bring in the transit VPC now transit bpc is no special vp say it's it's a regular vp c but the functionality it's providing that's that's the reason why we call it transit PTC but the idea is that you have a pair of ec2 instances which you launch in there load it with a VPN software of your choice and terminate tunnels to those ec2 instances now from those ec2 instances to the sport VP C's there is also VPN but then we are using aerialists managed VPN on the spoke PPC so this is kind of a hybrid of option one and option two now we released this architecture back in July 2016 and we saw tremendous adoption we initially released with dot formation templates and automation using Cisco CSRs and we saw bunch of vendors follow through with similar architectures aviatrix juniper Palo Alto different vendors and and there was a tremendous customer adoption as well and there were two reasons for that one was that you don't have to configure your on-prem VPN device for every V PC you launch and number two is that you get visibility into a traffic you're not always connecting your on-prem data center to V to your V pcs you might connect remote networks untrusted networks and customers needed the control over traffic and do some Cerf an IPS IDs and this architecture lets you do that because you can implement firewall controls and IPS layer seven filtering whatnot on those ec2 instances so this was it's a very good architecture or is it so there are some faults these ec2 instance have limited bandwidth IPSec is not a very efficient process especially when done in virtualization so you can get a max of few gigs per second and then you have hundreds of VP C's behind those ec2 instances that can be limiting factor you have customer management overhead because you are maintaining and managing these ec2 instances you take care of H a scale and whatnot and finally you have to pay high licensing fees if you're using vendor software so let's call this architecture that needs fixing part 2 let's recap software VPN on ec2 you can use any vendor of your choice it gives you quite a bit of flexibility from an architecture standpoint but you have to pay in the resiliency point because now you have to maintain and manage it you have to pay vendor licensing fees and also for this ec2 instances you're running so not not not a great story their performance varies by ec2 instance size and type and how many of those instances you're running ok so the architecture that needed fixing part 2 so let's fix this and we do that by getting rid of the transit VPC and bringing in the transit gateway now transit gateway is a fully managed endpoint you can connect your B pcs directly to the transit gateway so there is no longer VPN and wall to connect your V pcs to the hub this transit gateway has arab Lewis managed VPN endpoint on it using that you can create VPN to the transit gateway so this gives you the VPN edge consolidation you were looking for so just a pair of VPN tunnels and now you can connect up to 5,000 V pcs behind it there was a second feature we talked about when we are talking about transit V PC which our customers love and that was security visibility into traffic and the transit gateway Delhi was there as well you have the ability to create advanced routing rules through which you can send traffic to an ec2 instance before it makes it to the final spoke PPC and on that ec2 instance you can IPS ideas or some kind of a firewall so let's dive a little deeper into transit gateway now this is not the session which will give you everything you need to know about the transit gateway transit gateways are much broader networking construct but we'll be talking about this from the eyes of hybrid IT connectivity so transit gateway lets you build hub-and-spoke Network designs where the transit gateway sits as a hub and you have a bunch of spoke networks you attach your V pcs to the transit gateway - and simple API call its native attachment and this V pcs can belong to multiple net multiple accounts so we do have multi account support on the transit gateway you connect your remote networks via VPN over bgp using the aggress managed VPN endpoint and you can also connect wire Direct Connect but that's not here yet this is expected early 2019 so please keep that in mind it's not here yet so for this discussion I'm gonna get rid of red connect but the feature and functionality I mentioned now is also valid to Direct Connect once it makes it the transit gateway has its brain that's its routing table that's how it makes all the routing and packet forwarding decisions at the V PC level you'll just write a static route pointing your default gateway through transit gateway now let's say V PCC wants to communicate with the remote customer office it sends a packet to transit gateway the transit gateway looks at its routing table sees yeah I have a route for the remote network and sent it off fairly simple and this is how the hub-and-spoke model works it's like a brain sitting in the center of your architecture now let's talk about the security aspect of it and for that I want to introduce to you the concept of multiple route tables the idea here is that the transit gateway doesn't need to have just one route table it can have more people Rock tables and you can associate different spoke networks to different route tables so the routing decision or the packet forwarding decision with transit gateway makes will vary based on which spoke network the traffic is coming from and which route table it is associated with so let's try to understand this with an example so I create purple zone and red zone and the network's in the purple zone are connected to the purple route table and the networks in the red zone are connected to the red route table now the route tables are fully customizable so you can start with an empty route table add static routes you can propagate routes from the VPC or from the from the bgp session so it's fully customizable so what we do here is we put the routes of the remote networks in that zone in that route table and the same for red so now let's see what happens if V PCC wants to talk to the remote office it sends traffic to a transit gateway transit gateway looks at the red route table and it sees it doesn't have a route for VPN one it drops the traffic so what you essentially did here is you created logical isolation of the red zone with the purple zone so if you have your test dev environments and here are production environments and you want to create isolation you can do that now as I mentioned the route tables are fully customizable which means you can now add static routes to forward traffic to any c2 instance so this how it works you add a static route in your purple route table you say my default if the traffic is not within my zone I wanted to go to a security VPC and that's where my ec2 instance it's and the same for the red zone so what happens now is when the remote office wants to talk to the VP CC it sends traffic to the transit gateway transit gateway looks at the routing table sees that it's not in my zone so let me use the default out to the VP see xxxxX it sends it out there it goes to the ec2 instance easy to instance something with the traffic sends it back and then it goes to the PCC alright let's recap a doubles manage we pian on transit gateway you have the same feature from Charlotte II as a Robles manage VPN but now you have added flexibility of edge consolidation you can have advanced routing capabilities send traffic to an ec2 instance inline create different routing domains isolation resiliency is inbuilt and from a pricing standpoint there is some additional charge for the transit gateway usage now performance is key because now you get 1.25 gigs per VPN tunnel but now we allow ecmp which means you can load balanced traffic across multiple VPN tunnels and scale the VPN bandwidth horizontally and we have tested up to 50 gigs per second of packet forwarding capabilities on the transit gateway so it's very high performant so the question arises is transit gateway a new default for VPN yes but as I mentioned transit gateway is a broader networking construct and to learn more about it I would suggest one of these sessions which is done by my Pierre Nick Matthews and you can learn more about the transit BPC and the transit gateway and sort of all the functionality all right so we just talked about VPN now let's jump to Direct Connect so the idea here is that you create a dedicated circuit between your data center and AWS and you do it wire a Direct Connect location it's a third particle of facility where we have our cages and our devices and we have redundant connectivity back from the Direct Connect location to the AWS global infrastructure now step one is for you to decide which Direct Connect location you want to connect wire you might ask how do I make that decision well we'll come back to that but for now let's just say you made a decision now there are three scenarios you can be in scenario number one you have presence in the same connect location if that's the case it couldn't be simpler all you do is through Arab Luis management console or an API call request a Direct Connect connection specify the port fees the port speed one gig 10 gig and within 72 hours you can download a letter of authorization hand it over to your Colo provider and ask them to do a cross connect and done second scenario is where you don't have presence in this scenario you'll still go and request the letter of authorization but hand it over to a service provider who will extend a circuit from the Direct Connect location all the way to your data center now you can work with your own service provider or you can work with one of the 100-plus AWS partners which was which are listed on this link now option 3 is interesting and slightly different in this option you don't go to AWS console and request a connection you actually directly go to your service provider and tell them to connect you to AWS why would you do that one of the scenarios is where your service provider maintains and manages a private MPLS VPN which connects all your remote sites and you want AWS infrastructure to be part of that MPLS VPN or the service provider might say connect to me and I'll give you multi cloud connectivity whatever be the case what's happening technically in in the background is your service provider has existing circuits through AWS and they're just onboarding you onto those circuits so you don't get a dedicated one gig or 10 gig circuit but you are leveraging your service provider circuits so what speed do you get what's the resiliency model how much do you pay it all depends on your contract with the service provider and they're offering AT&T net born Verizon SC I Equinox cloud exchange if you're familiar with these options that's all in this category now when you're choosing what to do which option to go with there are some considerations one is how easy it is to add and remove virtual interfaces we will talk about virtual interfaces in a bit but just keep in mind that it lets you connect to resources inside your V PC hence it's important to know what's the speed of creating those and it will vary based on which option you go with you might or might not want to have routing ownership and create those bgp sessions and exchange routes so that will also vary based on which option you go with time to get connectivity to your resources is important and that will vary based on the option as well and option two probably is going to take the most amount of time because you have to create brand-new circuits and that takes months to do finally cost is important now there are two factors in cost one is a SS charges and other our circuit costs now let's talk about AWS charges now there are two parameters one is the hourly charge for the port so one gig 10 gig or sub 1 gig whatever you get you're paying an hourly charge for that port and you're also paying for their transfer charges now data transfer in is free and this is global so if you have connectivity from your data center to a remote region let's say from u.s. to Singapore you can transfer a bunch of data to Singapore it's all free but data transfer out will vary based on which region and which the connect location you're using in option 3 again you are paying your service provider fees based on your contract but you'll still pay for the here a SS to your transfer charges so you might ask how do I choose the right location end-to-end cost we just spoke about is critical how much does it take for you to build a circuit to that location latency is important thing about latency depending upon which their clinic location you are choosing what are my latency estimates and finally geographic redundancy so you want to choose multiple Direct Connect locations which are geographic geographically redundant and apart in case of failure and this brings up to my next topic which is resiliency now let's say you decided to go with a Direct Connect location so now you have your router a single router connected to a single area bless Direct Connect device over a single port using a single cross connect I mentioned single four times it's all single points of failure so you're going to get rid of single points of failure so let's add VPN while VPN is a valid option it does not perform this does not give you the same performance as you would expect from Direct Connect so you want a standby option which is more meeting your needs so let's add wreden C with the ports and and the cross connects so one thing you can do is use link aggregation groups so let's say you had 40 gigs of bandwidth between your data center and the Direct Connect location then you can request for 10 gig ports bundle them together in a lag and get 40 gigs bandwidth to AWS now if any of those links or the port fails the other links and ports will take over but you still have single router and a single leader bridge device so let's add redundancy there now two weeks back we released a feature which gave you logical bgp level redundancy now what we do there is over a single Direct Connect connection we give you two physical devices in the back end as BGP peers so in case of failure or maintenance it automatically fails over to the second BGP peer now this is only available for one red clinic location now so keep that in mind but even in this scenario you are still doing one cross connect to AWS because it's one location sorry one connection so we want to add modern dance so for that you get to direct connect connections so it's two different cross connects and by default we'll make sure that it's landing on two different a SS devices you need to think about resiliency at your end so hopefully you're using two different devices for these two circuits and if the service provider is extending circuits all the way to your data centers then you're doing it on two different data centers now when you have two paths to reach the same a Robles resource you can run active-active using ecmp or you can run active standby and we'll talk about how you do that in a bit but this is still a single point of failure because it's still a single physical data center or a Direct Connect location or even a campus so what you want to do is connect wire to different Direct Connect locations and hopefully you are connecting wire to different data centers at your end as well now there's a confusion on what a Direct Connect location actually means so this is a screenshot from our website which lists all the Direct Connect locations as you can see the first column is the Direct Connect location and the second is the campus from which it is accessible now if you're getting two direct connects into NY 1 + NY - in New York you are not getting redundant see because the Direct Connect location NY 1 is still a single point of failure so you want to get connection to two different Direct Connect locations which is basically two different line items in this table and we love VPN so let's keep VPN as our backup so let's recap you get global connectivity you connect through 89 and growing Direct Connect locations from a resiliency standpoint it's recommended to have two connections in two different direct connect locations with VPN you pay for port are fees dear transfer out charges from performance standpoint you can get one gig 10 gig sub one gig and you can get multiple of those links and do ecmp and scale horizontally in the bandwidth now some of the features which we release over the last one year we have support for bring your own autonomous system number which you can apply on the drake and a gateway we added more cloud watch metrics which gives you better visibility into your dread connect links ipv6 support and it now Direct Connect is a HIPAA eligible service and we also have support for jumbo frames so now we have talked about the physical aspect of Direct Connect let's talk about how you get access to the resources like V PC and s3 and all that over this physical connectivity so let's say you connected while the super nap 8 facility here in Las Vegas the cross connects are done the setup is done and now you have your app 1 V PC in u.s. West Oregon which you want to connect to step 1 you create a direct connect gateway step 2 you create a private virtual interface to this direct connect gateway you can create the private virtual interface Y Erebus console or an API call but while doing so you have to specify a few parameters and one of them is a VLAN ID the idea here the idea here is that your router will tag all the packets which it is sending to this direct connect gateway using this VLAN ID you also specify bgp parameters like bgp authentication password bgp pure IP addresses and the ASN numbers but once you do so and you create this private virtual interface the AWS end gets auto configured and you can download a configuration file and use that to configure your routers once you do that the bgp session is up and the direct connect gateway is now a bgv peer to your router next step using an API call or the management console you associate the VPC and the worship private gateway attached to it to the direct connect gateway and that's it now you have connectivity from your on-prem to app one VPC now if you had more B pcs like an app to V PC you just associate that V PC to the drake and Gateway and now you have access to two V pcs what about a remote region in the same step one API call and you associate that remote V PC to the drake in a gateway and you get access to all the three v pcs over that one bgp peering and one virtual interface now when you connect your V PC to a drake in a gateway it becomes an extension of your data center and you can access resources inside it using its private IP addresses but which resources this is the exact same slide from the a SS managed VPN so the list of resources is exactly the same so I won't spend much time on this since we have already discussed what you can and what you cannot access and this list is valid whether you are accessing a V PC in the local region or a remote region now transit gateway it is not here yet but I just wanted to talk about how will that work once the support comes early 2019 the idea would be similar but now instead your direct in a gateway directly connecting to the BG w of the V PC it will connect to the transit gateway which behind the scenes will connect to thousands of V pcs now the transit gateway is a regional resource so you'll have a transit gateway in your remote region as well and you can connect that transit gateway to your direct connect gateway now we have been talking about how you connect to your resources why a wonder connect location and we just discussed that resiliency is key it's important so let's see how that works when you have multiple Direct Connect ok so through the magic of PowerPoint let's make that smaller and let's bring in a second draconic location now if you wanted to connect to your AWS resources why the second location all you need to do is create a private virtual interface over the second connection to the same direct connect gateway and that's it now the direct connect gateway has to be GP peers and that's your two routers in the two different locations you can influence which path is active which is primary active and standby by using bgp parameters like es path people so in this example where you do the path prepend becomes the back up and the northbound link becomes the primary there's another way to influence traffic and you can do that by tagging your outs with specific bgp communities so the idea here is that you can tag your come in your routes with the community which is low and other which is high and the high will be preferred these is the list of the actual communities which you'll have to use to tag and the idea here is that if you tagged your routes with high that will be preferred and this is all to influence how AWS is sending traffic back so how you send traffic to AWS is under your control and you can use bgp weights or you can use local preferences now multiple accounts I think this has been a major pain point so let's talk about how multiple accounts work with direct connect gateway so let's say the application VP sees are in their own accounts so app one VPC app to VPC and the drake in a gateway was in app one VPC now we don't support the direct connect gateway connect to a VP see which is in a different account so this won't work the way you would want to connect is create a different reconnect gateway in the app to V PC over the same direct-connect physical connection create a virtual interface to this second trick in a gateway and then connect this direct connect gateway to the V pcs and our account and this is how you can use a physical connection across multiple accounts now I know it's a it's still a pain point we have heard your feedback and you warned the ability to connect direct connect gateway in one account to be pcs and multiple accounts and since this is a public forum and we don't have NBA's in place I cannot give you a road map information but all I can say is we value your feedback quite a bit now V PC endpoints these are the important one so V PC endpoints allows resources inside the V PC like ec2 instances access AWS public services without a need of an Internet gateway and you might think okay why are we talking about this because we have seen more and more customers want to connect to a tableau as public services leveraging V PC endpoints so let's talk about how this works with V PC endpoints so we have two kinds of V PC endpoints one is the enter interface v pc endpoint this is powered by private link and it lets you connect to a SS services like Amazon Kinesis load-balancing api's and this interface V PC endpoint shows up in your V PC as a network interface and this is accessible over Direct Connect so we have support for this so if you wanted to access easy to api's you would create interface V PC endpoint in your V PC and that has an IP address from within your V PC and that IP address can be reached over Direct Connect the second kind of gateway is the gateway V PC endpoint and this allows resources in your VPC connect to services like s3 and dynamo DB now this gateway endpoint is slightly different it's not an Eni it's an actual gateway which attaches to your V PC and it's a routing entity now this gateway unfortunately is not axial or direct connect so you cannot connect to s3 and DynamoDB leveraging the gateway V PC endpoint so how do we access s3 dynamodb well one option is to create a pair of ec2 instances which will act as a proxy so the idea here is that you will proxy all the traffic to s3 why are this pair of ec2 instances while this is a valid option there are some problems one is that now you have to manage and maintain the entire fleet of ec2 instances which are working as proxy scale them at Shea and secondly you need to configure your on-prem systems to use a proxy because they don't work in a transparent mode so that brings up the public virtual interface public virtual interface allows you to connect to a SS public services over Dre Connect and it lets you do that not only in the region where you have connectivity but globally across all a SS regions now public virtual interface is very similar to the private virtual interface in the sense that there's a VLAN ID associated so you have to tag the packets and there's a BGP session which gets established but the key difference is that over the bgp session we advertise to you the entire AWS public IP range and that's a global IP range which consists of more than 2,000 prefixes so let's think about that a minute it's not just resources which belong to you your s3 buckets your dynamodb tables your public ec2 instances but it's all of Amazon so any customer running on AWS and has a public IP will be reachable so we recommend that you put a firewall in front of the public virtual interface and Duke or some kind of a filtering ideally if you can do layer 7 filtering using URLs that's the best there are some other options if you go to this link this is where we list out all the IP ranges and we list them out based on region as well as service now the services which we list here is pretty limited so its s3 ec2 we have code billed CloudFront route 53 global load balancer cloud front and I might have missed one or two but those are the services which we list out explicitly so you can use that information and you can use the regional information to create some kind of a filtering there is one more way so when we advertise the routes to you we tag them with BGP communities which represent the scope of the the geographic scope of the prefixes so you can know which prefixes belong to the region in which you are connected in which you have the direct connect location which region which regional prefixes belong to the continent in which you have connection and which are global so that distinction is also possible using bgp communities so these are solve the ways you can filter the routes now when we talked about a SS managed VPN whether it was on the virtual private gateway or the transit gateway it gives out two IP addresses public IP addresses for VPN termination these public IP addresses are also accessible over public virtual interface so we can use that to advantage and what we can do is we can create IPSec tunnel over direct connect to the transit gateway so this not only gives us access to the transit gateway but it creates encrypted tunnel to it so a lot of our customers who require encryption over Direct Connect tend to go with this kind of a design so when talking about Direct Connect Gateway there are few things to remember let's bring up a sample architecture where we have to direct connect gateways and bunch of V pcs in different regions now if you wanted to be pcs to communicate with each other why are the direct in a gateway that's not supported so Drake in a gateway only allows for hybrid traffic so from your on-prem data center to AWS and vice-versa if you want to be pcs to communicate use the transit gateway or native V PC peering if you have two V pcs with overlapping IP addresses you cannot connect them to the same direct connect gateway although if you had two V pcs with overlapping IPs you can connect them to the transit gateway so transit gateway supports connectivity to 2 V pcs with overlapping IP addresses and you'll learn more of that in the other two transit Gate processions I don't know I want I don't want to go in too deep on transit gateway and some of the functionality around that in this session now if you have a V PC which is connected to a direct connect gateway it cannot connect to another direct connect gateway so it's like a one-to-one mapping now transit sorry the drake in a gateway was released in November last year so if you had read connect prior to that the way you get connectivity was to have a private virtual interface go directly to the virtual private gateway of the V PC and that's the yellow line at the bottom so if you architected in that way then you can associate your worship private gateway through a drake in a gateway and get rid of the old connectivity type and that's one of the ways you can migrate to the connect gateway model so when we started out there were three key key takeaways which we discussed so now I'm gonna judge and quiz you to see if you were paying attention and I have few prizes here so you are in for a treat so what are the options for connecting into AWS the option F looks very interesting I should try to do a P or C around that so if you can raise your hands if you know the answer okay I saw that guy right there first so yeah you there are three options here yeah II as well that's correct so you got a prize so you get this fancy colored pencils and you can use these pencils to draw connectivity architectures you can come in congratulations so we saw that you have VPN and it was Direct Connect you can connect wire and then you have transit gateway which brings new possibilities and new architectures the Direct Connect you have private virtual interface which gives you access into your V PC and public virtual interface which gives you access into public area bles services like s3 and you need to take care about how you're working with the public virtual interface the second key takeaway what's appropriate for my workloads so let's look at a cushion you have a business critical hybrid application and it requires low latency ten gates bandwidth and minimum downtime so you need a resilient highly available architecture so do you use VPN where tunnels to both the endpoints you use Direct Connect with connections to different red Connect locations you use internet or the application has too many expectations and we need to react attacked the application okay right there sorry B that's correct so you get a price so you get a magic ball and if ever you fall into a scenario where not able to decide which AWS connectivity option to go with you can use the magic ball alright congratulations so we saw different pillars through which you need to judge your connectivity type and you'll have this slide so you'll have all that than matrix which we saw flexibility we saw transit gateway added a lot of flexibility cost is important think about circuit costs vendor licensing costs and finally resiliency is key and performance so when you're evaluating what do you require for your workload look at these different pillars look at some of the stuff we talked today and you can make a decision of what to which option to go with now the final key takeaway what's new and how does it affect my architecture all right so which of the following new releases allows you to consolidate VPN connectivity for up to thousand V pcs and lets you define advanced routing rules what should probably get very bond that connects super gateway or the transit gateway all right let me go there the back yeah sorry at the back yes yep yeah that's you yeah transit gateway that's correct so you get a price so you have a lol surprise puzzle so in case the new AWS releases doesn't surprise you enough you can always use this puzzle and get amazed thank you all right congratulations so we saw what's new we saw we have transit gateway which got released and it honestly changes quite a bit of things you don't have to use ec2 instances in your transit VPC anymore you can go with transit gateway which is providing you with similar functionality but now it takes care of resiliency scalability and it's fully managed a Robles Direct Connect provides the logical redundancy of a single virtual interface that's just limited to one location right now but it opens new ways of achieving resiliency all right thank you and please don't forget to complete your session survey I'll take any questions you have thank you

Channel: Amazon Web Services

Views: 18,821

Rating: 4.9691119 out of 5

Keywords: re:Invent 2018, Amazon, AWS re:Invent, Networking, NET302, AWS Direct Connect

Id: LNYY3bMSiHM

Length: 51min 41sec (3101 seconds)

Published: Wed Nov 28 2018