Welcome back and in this lesson,
I want to expand on previous Transit Gateway lessons.
I want to cover a few advanced concepts
and things that you need to know for real world usage
and for your study at this level.
Now, we do have a lot to cover,
so let's jump in and get started straight away.
Now, some of this should be a refresher,
but let's go ahead and do it anyway.
On screen now I'm going to show you
a pretty typical Transit Gateway architecture.
First, we have two regions ap-southeast on the left
and us-east on the right
and inside the ap-southeast-2 region,
we create a Transit Gateway,
which isn't initially attached to anything.
It's a gateway object within the ap-southeast-2 region.
Now Transit Gateway as you've learned previously,
is a hub and spoke architecture,
so it can be connected to various other networking types
and networking objects within AWS.
For example, VPC1 and VPC2 on the left
using VPC attachments.
It can also connect to on-premises networks
via VPN attachments, where it's used as a termination point
for the VPN tunnels rather than a Virtual Private Gateway.
It can also integrate with Direct Connect indirectly.
Now to do this, a transit VIF is created
rather than a private VIF on a Direct Connect.
This goes via a DX Gateway
and this DX Gateway can attach to the Transit Gateway.
One DX Gateway can be attached to three Transit Gateways
in this way and provide the DX connection,
access to all of the things connected
to all of those Transit Gateways.
Now, as you'll see soon,
this potentially can be many, many VPCs.
Now, the Transit Gateway for all of these attachments
has a default route table
which is populated with any routes learned
from the attachments.
So for the VPCs, this is the side arranges of those VPCs,
for the VPNs, it's the routes learned using DGP
over the VPN and for a DX Gateway
and Transit Gateway attachment, you define the networks
within the attachment configured at the DX Gateway side.
It's important that you understand though,
this default route table has by default,
all routes which the Transit Gateway learns about
and by default, the route table is used
by all of the attachments of the Transit Gateway.
Now, the last thing I want to mention
is that you can peer Transit Gateways
with other Transit Gateways in different regions.
You can peer it with up to 50
other Transit Gateways per Transit Gateway,
and all of those Transit Gateways can also peer
with other Transit Gateways.
So this is what you should already know
about the Transit Gateway product.
Let's take a moment to summarize.
So a Transit Gateway by default, has one route table.
All attachments use this route table
to make routing decisions.
So as traffic leaves an attachment, it uses the route table
that's associated with that attachments.
Now by default, all attachments propagate routes
to this single route table.
So this means that every attachment adds the routes
that it knows about to this default route table.
Now, there is an exception to this
and that's peering attachments,
but I'll talk more about this later in the lesson.
Now with this kind of configuration
where you have one default route table
where it's associated with every attachment
and every attachment propagates to it,
it means that all attachments
can route to all other attachments
on a single Transit Gateway,
and this again is the default configuration.
Now, let's talk more
about Transit Gateway peering attachments across regions.
So we have the same ap-southeast-2 region
and us-east-1 regions that I just discussed
and between them, an inter-region peering attachment
between the two Transit Gateways.
The Transit Gateway on the left is connected
to the same two VPCs, the DX gateway via a transit VIF
and the customer VPN using a VPN attachment.
On the right, this Transit Gateway
has a similar set of attachments
only without the Direct Connect.
Both sides are adding their learned routes.
So the prefixes to their own default route table,
which is added to by all attachments connected
to that single Transit Gateway
and it's used by all attachments
on that single Transit Gateway.
Now, what's critical to understand
about peering attachments though,
is the routes aren't shared.
So the Transit Gateway on the left
isn't passing routes that it knows about
to the Transit Gateway on the right.
You need to use static routes
to allow this peering to function
and that's much the same as you use
when configuring VPC peering.
So it's important that you understand
that these routes are not advertised from left to right
and right to left, you have to configure static routes.
Now, AWS are also hinting
that there will be future enhancements
and so they recommend when configuring a Transit Gateway
that you use a unique ASN
to allow for these future enhancements.
Now, I've learned to take AWS advice
whenever things are framed in this way.
So you should probably do that,
if you're configuring any Transit Gateways,
make sure that you configure them with unique ASNs.
I do expect at some point in the future
that route advertisements
will work over Transit Gateway peering.
So it's best to stick with unique ASNs
and that will minimize any future issues
which you might experience.
Now, it's also worth noting
that the resolution of public DNS to private addressing,
for example, with EC2,
isn't supported over inter-region peers.
So remember how with the VPC,
if you attempt to resolve the public DNS
of an EC2 instance from within the same VPC,
it will resolve to the private address.
This doesn't currently work
over Transit Gateway peering attachments
and this has more to do with the cross-region nature
rather than a Transit Gateway limitation.
And then finally, in addition,
much like VPC peering, the data transfer over the peer
is encrypted over the global AWS network.
Now, there are a number of key points about peering
that I want to discuss.
Firstly, you can peer
up to 50 pairing attachments per Transit Gateway
and these can be in different regions
and different AWS accounts.
As I just mentioned, the Transit Gateway is not capable
of learning or propagation across this peer,
so you can't send automatic route advertisements
across an individual peer between two Transit Gateways
and you need to use static routes
in order to allow each Transit Gateway
to be aware of the networks at the other side of the peer
and data is encrypted just like VPC peering.
Again, you should expect updates
to the Transit Gateway product
and so it's always best to configure unique ASNs
for every Transit Gateway that you use.
Now, next I want to cover
how Transit Gateways can be used
for more advanced routing architectures.
I've mentioned this a few times,
but in the default mode of Transit Gateway,
you have one route table and all attachments
are associated with the same route table,
which means when traffic leaves that attachment
destined for somewhere else,
the attached route table is used to decide
where that traffic goes to.
In addition, it's also the default
that all attachments propagate
to the same single route table,
which means that all attachments are aware
of all other attachments
and each of them can route to every other attachment.
In this example, the route table ends up
looking something like this.
Each of the side arranges, so 10.16, 10.17, 10.18
and 10.19 has an attachment object as a target
so the Transit Gateway knows how to route traffic
from every connected attachment to all of the others.
Now, you might not want this
and that's what I want to cover
as the last thing in this lesson.
But right before we do, again, a few key summary points.
Attachments can only be associated with one route table
and it's this route table,
which controls where the traffic goes
when it leaves that attachment.
A route table though,
can be associated with many different attachments.
Now, attachments can propagate,
so pass on the routes that they know about
to one or more route tables,
even route tables which they're not associated with.
And these two mechanics are what allows us
to create some fairly advanced,
isolated routing architectures.
You can create hub and spoke networks,
multiple of them inside a single Transit Gateway
for routing isolation.
So on the screen, I'm showing the same architecture
that I've talked about previously,
only it's slightly reformatted
so I can talk about routing and routing isolation.
I want to really make sure that you understand
the difference between two important terms,
association and propagation.
Association is when a route table
is associated with an attachment.
An attachment can be associated with one route table,
and when associated the Transit Gateway
uses this route table to route traffic
which is leaving that attachment.
So if VPC1 on the left was sending data to VPC2,
the Transit Gateway would use whatever route table
was associated with the VPC1 attachment
to decide where to send that data.
So remember, route table associations
are used when data is exiting an attachment.
It's how the Transit Gateway decides
where to route traffic to.
Propagation on the other hand
is the configuration which controls which route tables
will be populated with routes known by the attachments.
So in this example, VPC1 is using 10.16.0.0/16.
You could configure it to propagate that side arrange
to the route table that it's associated with
or other route tables.
Propagation controls which route tables learn about routes
from which attachments.
Now, as I've mentioned,
the default is this single route table
which all attachments will use
and all the attachments are configured
to propagate into that route table.
But what if you want to isolate networks?
In this example, what if you wanted the VPCs,
so VPC1 and VPC2, to be able to access
the on-premises networks, but not each other?
You want VPC1 to be able to communicate
with the 10.18 and 10.19 networks,
but you don't want VPC1
to be able to communicate with VPC2 or vice versa.
Generally when configuring route tables
inside Transit Gateway, any attachments or any networks
which need to freely communicate,
will generally use the same route table
and all of them will propagate to that route table.
For isolated networks, you'll want to isolate
the route tables and the propagations.
With this example, we want free communication
between the VPCs and the on-premises networks
and vice versa.
So we create a route table and we configure all attachments
to propagate to this route table.
This means that the route table 7007 looks like this,
where it knows about all of the side arranges
of all of the different attachments.
Then we associate this with only the VPN
and Direct Connect gateway attachments.
So this means that the on-premises networks
can talk to each other
and it means they can talk to the VPCs.
What we don't want to do though,
is associate the VPC attachments with this route table,
because if we did, they too could communicate
with each other as well as all of the on-premises networks.
What we need to do is refine
what routes they have available
and to do that, we create another route table,
route table 1337.
Then we set the on-premises attachments
to propagate their routes to this route table,
which means that it contains the 10.18
and 10.19 side arranges
and then we associate this route table
with the VPC attachments.
This means that the VPCs can route
to the on-premises networks,
because those attachments are propagating their routes
to this route table, but the VPCs can't reach each other,
because they're not propagating their routes
to this route table.
In effect, it creates two isolated routing domains.
This is where the VPCs can reach the on-premises networks
and vice versa, but where the VPCs can not reach each other.
Now, this is really, really critical
to understand for the exam
and especially so for real world usage.
So if you need to watch this part of the video again,
then do so.
You need to understand the difference
between association and propagation
and how we've architectured this solution
so the VPC attachments use a separate route table,
which they don't propagate their side arranges into.
Remember, route tables are used for outgoing traffic,
so the route table that the VPC attachments
are using on the left
doesn't need to have prefixes for the VPCs,
because in this example, VPC1 knows its own side arrange
and we don't want VPC1 to have any awareness of VPC2
and that's why we have an isolated route table,
which doesn't get propagated to
by either of the VPC attachments.
Now, that's everything I wanted to cover
in this theory lesson, you're going to get the chance
to experiment with some of what you've learned
in an upcoming demo lesson, but for now,
go ahead and complete this video and when you're ready,
I look forward to you joining me in the next.