AWS re:Invent 2018: [NEW LAUNCH!] Introducing AWS Transit Gateway (NET331)

so good morning we're gonna get started welcome to this session on the newly announced AWS transit gateway hope you're all pretty excited about that and we certainly are to get it out there and

my name is Steve Seymour I'm a principal Solutions Architect I'm one of our networking specialists I went with our customers across Europe Middle East and Africa and have deep dive conversations around networking so this is a really

cool topic to be up here talking about this is Thomas friendly he's the general manager for transit gateway and for our VPN service and and let's just get this out of the way right now the right word

is route okay we're not gonna be talking about routing but actually I guess out of respect for my co-presenter here maybe I'll slip the occasional route into the to the discussion that we're

gonna be having here we'll see how I get on with that it feels a bit alien so some of you might have already seen some of these new icons in some of the other sessions and I think this is pretty

self-explanatory here we've got a cloud environment we want to be able to route things within it that's what transit gateway is all about so it's a new service that enables you to interconnect thousands of V pcs and

your on-premises networks and that's what we're going to be spending the next hour talking about in a bit more detail so what is transit gateway so let's be clear it's not a physical device it's a

fully managed fully distributed AWS service and when we started the journey with transit gateway we wanted to make sure that we could connect the pieces together and help them do that for

customers simply and so as you would expect transit gateway allows you to have the capabilities to allow you to connect thousands of V pcs together at

scale and across accounts and so whether you start your a double journey with two V pcs or if you have thousands of epcs transit gateway allows you to make simple and complex routing decisions

based on your requirements one of the other things that we heard from our customers is application teams can move very quickly by adding new V pcs while networking teams would move a little

slowly trying to connect their on-premise networks to AWS and so with transit V PC or a transit gate weight excuse me transit gateway Freudian slip so with Jazze gateway

you're able to share that on-premise connectivity across all your V pcs allowing your teams to be agile to meet business requirements and then lastly we

want it to be able to provide our customers with unique advanced routing features that allows you to build flexible Network topologies and so we created a the ability to have multiple

route tables and with these route tables you'll hear this concept of routing domains and Steve's going to go into that a little bit more in this session but with Ronnie domains you can actually

create very unique routing topologies and and allow you to isolate or create an any - anywhere network thank you okay

so taking those those three concepts we've got that interconnecting VPC is that consolidating edge connectivity and that flexibility with the routing domains let's just dive into what that might actually look like so taking our

example here we've got a typical customer scenario we've got four VP C's here if you wanted to connect those together before yesterday you would have done that using vp c peering so you

would create a vp c peering connection between each of the VP CS in this case we actually want all of the VP C's to communicate with each other perhaps these are all development environments maybe some dependencies between them so

we're going to have to create a full mesh of vp c peering connections so just with those four vp C's we've already got six V peering connections in place now what you can see here is that if we drop

the new transit gateway into this topology what we actually have are just four simple attachments to that transit gateway let's go back to our scenario again with our full VP C's and with our

clearing connections in place and now add the fact that these development teams want to be able to connect back to our on-premises Network so that's fine we're going to have a customer gateway the end of a VPN connection that exists

within a customer's network and we're now going to build VPN connections out to each of those V pcs and for those of you familiar with VPNs you're aware that those VPN connections terminate on the virtual private gateway for each V PC

each of those connections is actually two tunnels for resilience we have two endpoints on the AWS side for each of those VPN connections so this is what it would look like in a world before transit gateway but

now that we have transit gateway in the mix it's as simple as creating a single VPN connection to the transit gateway itself it still consists of two tunnels

it's still resilient on the AWS side so this now vastly simplifies your setup now let's go back to that scenario we've got our VPN connections in place we've said that they're highly available on

the AWS side we have two endpoints for you to connect to but obviously our recommendation to you is that you have a highly available pair of endpoints on your end of the connection so what that means is there's going to be two customer gateways within your

infrastructure and we're now going to create additional VPN connections from each V PC back to that pair of customer gateway devices well of course you can see where this is going when we put transit gateway into the mix

it's as simple as creating two VPN connections a total of four tunnels and you have resilient connectivity from an on-premises network so all four of our V

pcs thanks T so obviously I think you get the concepts out of high level Steve did a good job of presenting it at a 10,000 foot view so let's take it down to a thousand foot view and see what it looks like to actually create the

components of a transit gateway so let's take the scenario where you have a development environment where you have four V pcs each of those V pcs need to communicate with each other and you also have the additional requirement to

connect back to on-premise resources using a VPN connection so you might be doing that because you're accessing a code repo or a user needs to be able to test from on-prem and so one of the

things that we want to make sure that we're able to do here is we want to allow our development teams to be able to add new V pcs or destroy the PCs on the fly without having to worry about

creating new VPN connections or reconfiguring the on-premise router so the first step here let's go ahead and create 4 V pcs in our development

account let's put them in with into the 10/8 range so we've got our 10.1 10.2 10.32 enough for V pcs and then each of these V pcs has a subnet into

availability zones first we'll go off and create in our console on our V PC console a transit gateway and all you need to provide is just a name and so here

we're just gonna use the defaults for the rest of the parameters when the transit gateway gets created you'll see here that the state becomes available for use now one of the things to call

out here is a transit gateway as a regional object it's highly available and highly scaleable so how did we do that so if you were here at reinvent last

year and you happen to catch our talk or discussion around hyperplane technology that we discussed you'll know that it's highly scalable and highly available and

a transit gateway is built on that building block so we've created our transit gateway in the console the next step is to attach our V pcs to the

transit gateway and so this is actually pretty easy all you do is select the transit gateway that you want to use select the attachment type which is a V PC and then just provide the subnet of

the availability zones that your V PC is in now again just remember the transit gateways of regional object it has zonal attachments and you only need to provide

one subnet for each availability zone that you're in that V PC we repeat that process three times very simple very

easy for each of the other V pcs so now we have a transit gateway we have attachments we've attached our V pcs to the transit gateway and you see here

that each of the attachments are available and all the default parameters are applied in the screen below now now we got to make sure that basically we

have a route from the transit gateway back to our V pcs and so looking at the transit gateway route table you see here the list of all the ciders of our V pcs

you also see the attachment IDs so this help helps confirm that we have a route basically from our transit V PC or transit gateway to our V pcs okay now we

also have to think about the return path so how do we know that we can get traffic from our V pcs to the transit gateway so in our V PC route table we

need to put a 10/8 destination address and with a target of transit gateway

in the target field and that's it so how do we know it's working so we created the transit gateway we attach the VP C's

we updated the routes from the the transit gateway to the VP C's and the VP see rail table back to a transit gateway so here we set up basically four ec2

instances in each of the VP C's in the dot 50 subnet and logged into the ec2 instance in the 10.1 V PC ping to the

other three ping the other three VP C's or three other ec2 instances and you see they all responded and so what you're seeing here is the actual screenshots and an actual deployment and we just

created in any - anywhere connectivity between these VP C's that's it now if you remember the original scenario we needed to be able to connect back to

on-premise through a VPN connection so it's as simple as going back to the attachment selecting transit gateway selecting VPN and here you can either

use an existing customer gateway or create a new one and as you know the customer gateway has the IP address as

well as the ASN number for BGP we switch over to the VPN , and you download the VPN configs template and you just up

that update that to your customer gateway router and you only need to do this one time and so once your VPN

tunnels come up the bgp sessions are established you'll see here that the 10.99 prefix in the route table via the

VPN connection so now you have a path back and again how do we know it's working so right here we jump back on our two

ec2 instance in our 10.1 V PC we ping back our customer gateway and we see that it's reachable no other

configuration is required so from the on-premise side from our customer gateway how do we know we have connectivity so if we look at our you peer out table what we see here is

the Syrus of all the attached V pcs available and we see two paths each each for the two tunnels that were created automatically with our AWS VPN and then

lastly obviously you could do all this through the AWS console you can do this through the ABS command-line you could do it through a direct API call and for those customers who use VPN today you

see here that the only change to what you do today is you can either pass a parameter of transit gateway or pass a parameter of Virtual Private Gateway

cool so you've seen the basic concepts here and how it works but I wanted to go into a little bit more detail here so first of all there are two really

important key concepts for transit gateway the first one are attachments so we've talked about attaching V pcs we're going to dive into that in a little bit more detail the second really important

concept for a transit gateway is route tables and within route tables we have two topics to discuss around Association and propagation so let's have a look at

each of those concepts in turn so this is the new icon for the transit gateway you're gonna be seeing a lot of this and this is where we're starting from we create our transit gateway first you saw

that example in the console and the next thing we did was to attach some V pcs to that transit gateway so what you're seeing here are two of the V pcs from previous example 10.1 and 10.2 they're

the ones we're going to be working with and we're going to attach those to the transit gateway so in this case I've called the two attachments attachment red and attachment blue obviously these

show up as identify as in the console but these are our two attachments now once we attach them to our transit gateway remember there is a route table involved here and that route table

exists inside the transit gateway itself now when you attach a V PC to the transit gateway you actually have to identify a route table to associate with now when we creates the transit gateway

earlier we left all of the defaults in place so what that means is if we look back in the console we can see that there is a default route table for Association and the Association is

enabled and we also have propagate enable to that same root table so what does that actually mean well here we are we've got our attachments associated with the single root table that we have inside the transit gateway what that

means is when traffic comes in from that particular VPC to the transit gateway this route table is the list of instructions that are going to be followed in identifies the next hop and where traffic should flow to but I

should we don't have any entries inside that root table at the moment so if a packet did come in from one of those V pcs perhaps from the the 10.1 V PC and is trying to get to 10.2 it would come in to the Associated root table but

there's no entries in there so it would effectively get dropped what we have here is the concept of propagation so propagation is an automatic way of taking the side arrange for a particular

attachment in this case of V PC and propagating it into the root table so in this case we've got 10.1 being propagated over that red attachment and 10 dot due to being propagated over the

blue attachment so now we have a route table that is actually useful it has entries in it that tell us how to get somewhere so that's it that's our route table complete that's effectively what a

default deployment actually looks like um but we talked about needing to configure the V PC side of things as well so let's just go to the V pcs remember we do need to add an entry in

there that says if I have traffic that is trying to get to in this case 10/8 then let's put an entry in the route table and we just specify the next hop as the tgw identifier so this is the

same as you're probably used to creating you know a default route to the internet gateway perhaps all routes to a vgw for on-premises connectivity in the past it's exactly the same concept so we put

those entries into the route table that's the default so this is the the situation we actually created earlier and the screenshots you saw those are real screenshots of exactly all of the

steps involved in getting to the point that we showed you this is the the result we had here we had a VPN connection obviously we had 4 v pcs in this example we're showing two of them we were automatically associating all of

those attachments with the same route table and we were automatically propagating all of the routes into that same single route table so that's the default that's how easy it is to connect all of these things together

but I think all of you would like to move a little bit beyond those basics and let's look at some of the other capabilities here so here's our scenario what if we want to have more than one route table inside our transit gateway

so we could have two what about having three well we had three attachments that we've been talking about here we had two v pcs and we had a VPN so let's actually create a route table for each one of

those attachments its associated with that route table and now we need to consider what's actually going to end up inside these route tables and that's the the topic of propagation that I

mentioned now this is the overall concept of creating routing domains so you can create a route table here to decide where traffic flows in different situations so we are creating these

separate domains of behavior and that's what we have inside the transit gateway so our first step is we're going to propagate 10.1 but instead of letting the defaults happen we've actually specifically chosen here that we're

going to propagate 10.1 into the route table that is being used by the VPN attachment we're going to do exactly the same with 10.2 so now we know that if

traffic comes in from the VPN it knows how to get to those two V pcs okay well what about traffic flowing the other way the traffic that is going to be coming perhaps from one of those V pcs it needs

to know how to get to a VPN so again we can choose to propagate the routes from the VPN attachment into the two route tables at the top here so this is now what we have configured here this is

what we're going to be seeing for our traffic flow now remember you could use that propagate option and it makes things nice and easy it means as you update say the side arranges for your V

PC or you change your BGP announcements from an on-premises environment it automatically will update in these route tables now that we've turned on propagation but these are just route tables so you can put static entries in there if you like you can put a static

entry and that specifies an attachment as the next hop that's all the propagation is doing but it's doing it automatically for you so just consider that that you have options in the future to put static entries in and that might

be quite useful so let's just recap what route tables give you the ability to do here first of all a route table is all about identifying the next hop for traffic you can put those static entries in if you like

you can even create what we call blackhole entries so what that means is if you have traffic destined to a particular IP address but you actually don't want it to flow for a particular reason you can actually just put a black hole entry straight into the route table

and that packet will get dropped it's important to remember when you have static entries and black hole entries in your route table that they take precedence over anything that is coming in dynamically ie anything that's coming

fire that propagation process I talked about so effectively the static and the black hole entries override anything that's coming VAR a propagated entry you've seen that by default when you

create a transit gateway it has one route table that's being created all the attachments you then make to this transit gateway are automatically associated to that particular route

table again also by default propagation is turned on we've done this so that it makes it really simple for you to get started but it means that everything can route to everything the next step beyond

that was that we said we could have multiple route tables inside our transit gateway it's important to remember an attachment can only be associated with one route table remember it's the set of instructions that are followed for

traffic flowing into the transit gateway but an attachment can propagate its routes to any number of the route tables that you want so this gives you the idea that with a bit of extra configuration and a bit of architecture that I'm

thinking around this you can actually build some really quite interesting setups here and have full control of the routing within the transit gateway itself now the concept of routing here

you might be struggling a little bit just to think about how these packets are flowing around basically it's all about thinking about what is the next hop on a path you know if you were driving somewhere it's the decision you

would make at a particular turning or a particular Junction and I find when looking at things like this it's actually really helpful to visualize that and actually visualize it from both perspectives because traffic needs to

flow in both directions so let's go back to our our setup here we're going to introduce Dave into the equation here Dave is in our on premises environment and he has a packet that he wants to get

to 10.10 dot 50 so it's in the 10.1 VPC now the first thing that Dave is going to do is look at the on-premises environment and look do I have a route to get to a 10.1 now we know that 10.1

is going to be advertised from the transit gateway Oh the VPN connection to the on-premises environment and you can see it there it's being received by BGP so Davey's going to follow that path into the transit gateway now that he's inside the

transit gateway we're going to look at the route table that is associated with that VPN attachment in that route table remember we've got the entry that we propagated to it earlier so we've got

10.1 and we know that to get to 10.1 we go via attachment red so that's fine Dave now follows that step via attachment red and is now inside our 10.1 DPC so life is good but now he

realizes he actually needs to go back home again so how does he do that he's gonna look for an entry in the local VPC route tables to get back to 10.99 the on-premises environment where is that

entry well remember we created it in the route tables inside the V PC and we have a next hop here that is the transit gateway so great Dave follows that back we have the route table here associated

with the red attachment Dave looks at that entry sees an entry there that says 10.99 that's the on-premises environment I'm trying to get to remember that was propagated earlier from the VPN

attachment so Dave follows that we come down to the VPN needs to look where do I go next well we're receiving an announcement of the on-premises environment the 10.99 coming over that

bgp session so great dave is back home and it's really quite easy when you just follow those steps so the idea of this is just to give you a way of thinking about this and as you build some creative route tables here and decide

how you want your traffic to flow that's the kind of process I go through when I'm thinking about how is this traffic going to get both to and from two attachments on a particular transit gateway so you've seen a couple of

different transit gateway architectures here you've seen any - any which is the default very easy and quick to get started you've also seen a scenario here where we've shared some edge connectivity we've got that VPN

connection giving you access to two V pcs but what about if you wanted to have a slightly different setup here perhaps these two V pcs actually should never be able to talk to each other which does

remember our default situation but they both want to share that connectivity back to the on-premises environment you don't want to go back and create multiple VPNs just to isolate them so could we perhaps do that with transit

gateway and the answer is of course yes and actually it's what we had in place a moment ago so if we put Dave back into his VPC here at 10.1 and we say I want to get to 10.2

the other VPC so remember the first step here is to look at the root table inside the VPC we're going to follow that and we're going to end up at the transit gateway now the root table that is associated with this attachment doesn't

have an entry in it for 10.2 we didn't propagate from the 10.2 attachment into this particular root table so at this point there is nowhere for Dave to go the packet drops there we stop so in

that scenario we built we actually already have isolation between these two VP C's but the ability to share that VPN connection back to the on-premises environment now you can see that this is

just the start of some really quite interesting architecture possibilities here with transit gateway and I put a few examples up on the screen here and you can actually even have multiple

transit gateways attached to a V PC so you can see how this would become really quite interesting there is a session on Thursday Mick Matthews is presenting that on transit gateway architectures so if you're really interested in some of

these design patterns some of the ideas that we have here in some of the the things that we've seen customers want to use transit gateway for I'd really suggest you go along to next session and

see what he's got to share there now I mentioned the other concept here of VPC attachments but we haven't looked at it from the VPC side of things so first of

all let's just remind ourselves transit gateway is this regional object it is something that is a single target for those route tables inside your V PC but we said you needed to identify which availability zones you were using and

you had to choose just one subnet in each of those availability zones for this to attach to your V PC one of the options you have here is to use some existing subnets that's absolutely fine

but if you're building a new environment here or you have spare address space within your V PC my suggestion would actually be that you create new subnets purely for this attachment and you'll see why in a moment it gives you some

really interesting options of how you route traffic inside your V PC but you can use those existing ones if you need to so here's what is probably a pretty

familiar architect for you we've got our VP see we've got some public subnets one in each availability zone we've got three availability zones here there's a route table that is

with those particular subnets and the default route is via the Internet gateway we think of some private subnets there's a route table that we're using for those private subnets and actually the entries in that route table are going to be a little bit different and

we'll look at that in a moment I think created three more subnets that I'm going to use for connectivity these are the ones that I'm going to be using with the transit gateway itself so when I attach the transit gateway what you'll

actually see in your V PC is three network interfaces get created and you can see these if you go and look in the network interfaces part of the console one of the route tables look like well I mentioned that the public subnets will

have a route to the internet gateway that's pretty standard we've actually put some nat gateways into those public subnets so as you might expect the private subnets then have a next hop of default route that goes by those NAT

gateways but what about the route table I'm using for those connectivity subnets well actually I don't need to do anything with them we've got just our default in there the local entry that is always created in a route table that's

fine we can just leave that alone for the moment so at this point we have our transit gateway attached to our V PC and it's going to work in the way that we've

already described the the thing just to consider is back on the private subnet here I have added that route the 10.8 via the transit gateway so this is how we're going to establish connectivity

from anything that is in the private subnets to the rest of our Vee pcs that are attached to the transit gateway that's the only place that I've put 10.8 ok so this is where it gets interesting

with the inbound routing side of things what do I mean by that well here's our V PC that's now pretty familiar to us we've got the three network interfaces from the transit gateway one per availability zone and remember that

route table that we looked at doesn't actually have to have anything in it just got the local entry we have a packet coming in this is Dave again he's coming in from the transit gateway he's trying to get to the ec2 instance that

was 10.1 0.50 well the entries in that route table tell him that that's local to the V PC and of course that's fine so dave is now quite happily over at that ec2 instance he's got the 10/8 route back to the transit gateway so that's

how traffic will normally flow if you don't change anything else but we can actually be a bit more creative here so we can go back to the route table that is inside the transit gateway and statically add an entry to it now in

this case I'm actually creating a default route so I'm introducing a 0 0 dot 0 dot 0 / 0 route into the transit gateway route table and what I've actually specified here is that if the

traffic doesn't match any of the other more specific entries in that route table send the traffic to the attachment read so I'm sending it into my V PC now I've simplified the VPC diagram a little bit here I've just removed the other

subnets and the other availability zones but we now can see that that traffic is going to flow into this V PC so what happens next we're inside the V PC we've got the

route table that earlier didn't have any other entries in it but actually the traffic that's coming in from the transit gateway will obey that route table so we can actually add an entry in there that says if you receive a packet

and it's not for this V PC it's addressed to perhaps something out on the internet let's just send that traffic to the nat gateway so now we have centralized our outbound internet access from all of

the other attached v pcs to our transit gateway through this particular V PC so that's the inbound routing capability that you have by modifying that route table now the important thing to remember here is if we're sending that

traffic out to the nat gateway remember in our route tables earlier when we looked at the public subnet we didn't have an entry in there for the return path so let's go back to thinking about dave if his packet gets out there it

gets translated how does he get back we just need to go and put an entry into the route table for those public subnets now that identifies 10/8 is available

via the transit gateway so this is all about next top routing this is that inbound traffic coming into our V PC and if you're going to be using this you do need to consider the fact that it will come in on one of those particular

network interfaces and you want to consider that you want to keep that traffic ideally within the same availability zone so it's a concept that we call AZ independence and therefore you might actually choose to have a

separate route table for each of those connectivity subnets just to keep the traffic aligned to that particular availability zone that would be our best practice recommendation and therefore that next hop would effectively be one

per AZ so let's go back to our V PC here I've taken out the public subnets this is now a V PC that doesn't have internet connectivity doesn't have an Internet gateway but we still have our connection to the Tran

Gateway what if we want to use things like the newly announced route 53 resolver service the endpoints that you create for that well what does route 53 resolver do it creates endpoints by

putting an en I into your subnets what about if we look at V PC interface endpoints perhaps you're accessing some of the other AWS services via those endpoints again what does it actually do

it creates a network interface that is inside the subnets inside your V PC so these have an IP address that is within the side arrange for that particular subnet private link is exactly the same

it creates a network interface inside your V PC and again another IP address from your range of IPs well what does all of that mean it means well where we have a connection to a transit gateway here all of the other V pcs can actually

access any of these endpoints because they're just IP addresses within the 10.1 V PC so again you can see this gives you options perhaps to centralize connectivity to some of these other services and other endpoints that you

might be using but there's kind of an important thing to remember here whilst there is no specific configuration required from a routing perspective you do need to step back and think about how are people actually accessing these

endpoints so they're probably using DNS you know if you're calling some of our api's you're using our standard endpoints where we have changed the endpoint IP address to now be with inside that V PC so you just need to

consider that perhaps from your other V pcs you need to do something with DNS and route 53 resolver that we announced a couple of weeks ago actually is a really good way of doing this so you can

manipulate and control how traffic is routed from a DNS perspective and return particular entries for those services so if you're going to be doing this have a

closer look at route 53 resolver now I use the example there of an @ gateway so an AWS managed service for sending that traffic out to the internet but obviously you could actually do this

with any ec2 instance inside your V PC you know some of you may already be doing this routing your traffic pad through something from the market place that you've deployed to manage or monitor or control access out to the

internet but you can absolutely do the same thing here but it's actually quite interesting that you might want to be able to route traffic through a middle box between two other attachments so we'll come on to that in a little bit

more detail the important thing to remember is if you're going to be setting up a middle box type architecture here you want to put the next hop the ec2 instance in a

different subnet to the connectivity subnet so I showed you earlier so what does that actually look like well here's the example here we've got our root table we're saying that this time the

traffic is going by an en I so a market place instance that we've deployed in here and the next hop is that en I obviously that instance is probably in a public subnet but in this case what we're actually considering is that we

don't use this to get out to the Internet we want to use it as a path for traffic between two V pcs that are attached to our transit gateway so think about what we can use that inbound routing for here here's our next hop

we've got that en I to the middle box but what if we actually look at the route table for the middle box subnet and send it back to the transit gateway so this is where we can use that concept of having to route tables inside our

transit gateway one that is associated to the attachment that determines traffic coming into the VP's into the transit gateway but for traffic leaving we can actually put an entry in there so we've got a default route here that says

send all traffic via this particular V PC it comes in it goes to the middle box we can then send it back again so that might be kind of interesting as well from an architecture perspective

obviously in this scenario you still need to consider the AZ independence that I mentioned so perhaps deploying multiple instances and aligning your traffic to those particular AZ's the other scenario though that you could do

here is actually to use VPN connections so you could host ec2 instances in another V PC give them an elastic IP address and build VPN connections back to the transit gateway and that gives you some pretty creative options that

Thomas is going to talk a little bit more about later on thanks Steve so Steve did a great job of going from the thousand foot view to 100 foot view and

so let's talk about what other capabilities that are available in the transit gave me so we've talked about VPN attachments and how simple and easy that is to do on a transit gateway today

but one of the things that our customers have talked to us about is is how do I get more than a gigabyte exact raft bandwidth to AWS and so when VPN

connections are actually attached to transit gateway transit gateways supports equal cost multi pathing and so what does that allow you to do so think

of equal cost multi pathing as a routing strategy that where the next hop goes to a single destination but there's multiple best paths right and so in this case if we basically advertise the same

IP prefix across all the VPN connections transit gateway will distribute that traffic across all those connections that allows you now to create elastic bandwidth across those VPN connections

and so why would I use that so for example a customer who may be using a 10 gig direct connect might want to back up previously they would only have a one

gig VPN connection in this case they could actually create an 8 VPN connections against a transit gateway and create equivalently a 10 gig pipe

the other playing that we started off with was transit gateway supports thousands of V PC connections and so we know that we want to be able to support multiple accounts across all those

connections and so how do we do this so transit gateway uses the newly announced resource access manager to centrally manage resource sharing and I

think I hit the wrong button sorry about that yeah research very sorry here I think I had two slides too many apologies here ok

so so how do you do that technical difficulties so how do you do that so it's really a like a three step process so you would start with you start with the resource access manager

where you would go in and create a new resource share that centrally is manage the owner of the transit gateway would go in and create the resource share and

the participants of who would actually access that and that could be either accounts in your organization or accounts outside of your organization now it's important to remember that

those participants accept the invitation so think of it as the transit gateway owner enable sharing the next step is

for the participant in this case the VPC owner to be able to request an attachment to the transit gateway and when they request that attachment because they were part of one of the

they were one of the principal's as part of the resource share they're now able to describe the transit gateway they're able to attach to a transit gateway as

well as they're able to make those attachment requests and the third step is the transit gateway owner now has the ability to accept or reject that

attachment request and so in this case you can actually set it up as auto accept or you can manually accept those requests and so why would I do that why

would I actually do that so think of it as the the network teams want to be able to control the transit gateway but they want to allow the application teams to

be able to use network services and those teams when they use those network services you want to be able to attach and describe but you don't want to

change your network configuration and so what would that look like so if we go to the console for the resource access manager all we have to do is put in a

name for the the resource share we would basically select transit gateway as the resource that we want to share and then under the principles we would actually select or provide the accounts that we

want to share and those again could be within your organization or they could be outside of your organization and that's it so we talked about how transit

gateway is a fully managed service and it works with all other AWS services as well and we talked about how it connects with V PCs and VPNs but with launch of the transit gateway

we actually support cloud formation templates which allows you to easily automate their build process as well as being able to monitor the transit

gateway we integrate with Amazon's Cloud watch and you have metrics on packets in packets out drop packets you also can enable flow logs on your en is for all

the V pcs are attached to a transit gateway as far as pricing so there's two dimensions to pricing for the transit gateway your build hourly for every

attachment to the transit gateway as well as for data processing yet one for every gig - that's processed by the transit gateway or to the transit

gateway from each of the attachments region availability wise we are currently launched in six regions and we have more coming by the end of the year

so we talked about how transit gateway is a highly scaleable service we wanted to make sure that whether your journey started with two V pcs or a thousands of

V pcs that transit gateway could support that for you and so the transit gateway we've were supporting up to 5,000 V PC

attachments against the transit gateway as well as you're able to install up to 10,000 routes on a transit gateway and

then as Steve mentioned the the power of the routing domains and being able to create the use of flexible network topologies we're supporting up to 20

route tables so what's on our roadmap now this is kind of dangerous when you actually actually put some stuff on the roadmap right so you can't hold me to it

so we know that Direct Connect is important for our customers and so right now at launch we're supporting AWS VPN if you're a direct connect customer if you're a pulpit public directly to that

customer you can actually connect to turns a gateway using AWS VPN for a private Direct Connect we're going to be providing that support in q1 2019

this next one actually gets me excited and so when we were designing transit gateway one of the things we wanted to do was to be able to create a global network and so it's not just about having a transit gateway within a region

but what if you can connect transit gateways across regions so you have a transit gateway in your US East region and you want to be able to always be pcs in your u.s. region you want to be able

to send traffic to another read transit gateway and say Asia Pacific you can do that when this comes out and so think about how you might be able to use that

so take an example where you have a branch office that's in Virginia that basically uses a VPN connection and connects into the u.s. East region sends

traffic over to the asia-pacific region and then through a VPN connection sends traffic down to an office of Mumbai you just created a global network all within

AWS and then additionally we want to continue to provide advanced routing capabilities for our customers and we were really excited about what you can do with routing domains and if you think about that in the ability of with

routing domains that that Steve went through what else can we do for our customers and what we're looking to do is add the ability to do policy-based routing so think about policy papers

routing as being able to make routing decisions on the properties of a packet outside of just the destination IP that's gonna be powerful when you'll be

able to do that so to bring it all back home and back together is we talked about how in this journey and when we build transit gate we wanted to make it simpler to and easier for customers to

connect thousands of V pcs together you know so no matter your journey from to 2000's we want transit gateway to be that that simplifying ability we talked about how you want to share

your edge connectivity you don't want to have to make a network change every time you add a new VP C and transit gateway allows you to do that the visibility and control with transit gateway now you

have a central place where you can make all those routing policy changes and where Steve was talking about middleboxes think about that you now have the ability to put other services and share

those network services weathers network services are things like Active Directory those network services could be a firewall those network services could be other AWS services like private

link or NAT gateway or an NL B all those things work through a transit gateway now and you have one place to do that in feature interoperability we talked about

how trans gateway works with other AWS services cloud Watch metrics cloud formation flow logs and then for those customers who use VPN the on-demand

bandwidth and be able to ecmp traffic across multiple tunnels there's many different use cases where you can use that whether it's at a branch office or a backup for VP or for a Direct Connect

and then with routing we're excited to see what customers are going to do with the routing constructs that we have with routing domains and be able to use

different types of next-hop abilities that are there thank you so there are a couple of other sessions happening this week that I just wanted to draw your attention to where there's going to be

some mentions of transit gateway and first of all we have Dave Brown our VP for EC to EC to networking he's doing a leadership session tomorrow afternoon definitely I recommend you go along to

that to hear about some of the cool things we've done with networking at AWS over the past year and some of our future plans there's a session that Nick is doing on Thursday where he's going to be diving into those reference architectures some of the the ones I had

on that list and explaining how you can build those and then finally if VPN is your thing and you want more detail around VPN and our plans there what we've built out and how that interacts with transit gateway

Tommy's doing a session on Friday that I'd also highly recommend so I hope you're all as excited as we are about transit gateway we think it gives you a lot of new capabilities we're looking forward to seeing what you do with

so thank you very much for coming to the session and we'd really appreciate your feedback in the mobile app [Applause]