Would you like to know about VPC peering? If so this video is for you.
Hi, my name is Michael Gibbs and I'm the founder and CEO of Go Cloud Architects.
And we're an organization that's dedicated towards building high performance cloud computing
and networking careers. I've been working in technology for over 25 years and I've been
helping others get their first tech job or get promoted in tech for more than two decades. And
the best thing in the world is when someone calls me and says, hi Mike, I just got cloud hired. Now,
today, we're going to talk about VPC peering. I know you're all familiar with the virtual
private cloud, which is an organization's basically private network/data center
inside of the cloud provider. And since you're all aware that an organization has their own virtual
private data center, which is called the virtual private cloud inside of the cloud provider,
you may also be aware that just because you've got your own data center
doesn't mean you don't want to connect that data center to other organizations.
Let's talk about a few examples. Let's say you have an auto manufacturer who's sitting on the
AWS cloud, for example. And let's say on the AWS cloud, you'll also have a part supplier
for auto parts. And let's say you've got the auto manufacturer on the AWS cloud
and the parts supplier on the AWS cloud and you want to create a connection in between
them. That's what VPC peering is about. So VPC peering is about connecting entities to each other
across the AWS cloud. Now, if you're on the Azure cloud or the Google cloud or any other cloud,
they all have some concept of a virtual private cloud, and they all have the concept of peering
or using that cloud provider's network as a means to promote communication between entities.
So this is really great. Now, prior to talking about peering, let's talk about
other ways you can connect entities, because I really want you guys to truly understand it.
In the traditional environment, let's say we've got our data center and we want to connect to
another organization's data center. We either buy a private line, which is just like a direct
connection on AWS. Or we would connect both sites to the internet and then create an IPSEC tunnel
or a VPN over the internet and that's how we could connect our entities. Now, when we use VPC peering
on the cloud, we're actually going to ride on the cloud provider's network, which is really great.
So if our auto manufacturer is on AWS and the parts supplier is on AWS, they can connect to
each other over the AWS network, which means there's no networking to build,
which is a sad day for the CCIs like me, because we're going to be sitting in the corner looking
for things to do. Just joking, there's plenty for us CCI network experts to do. But the point
is it's a lot of the work is taken care of for you by the cloud providers via VPC peering.
Now, when we talk about VPC peering, there's some information that's pretty important to
talk about. And like I said, this exists on every cloud provider,
but here we're talking about just AWS. Now, when you're talking about VPC peering,
you're talking about non-transitive routing and we'll show you more about what that means.
But what non-transitive routing means is if this person gives this person a route,
this person who got the route won't give that route to anybody else. So that's what we're
talking about. So for those of us that are in networking, non-transitive routing is a
very common thing. We've been dealing with it with a protocol BGP or border gateway protocol, for all
of us network engineers and all of us network architects, we all have worked with interior BGP
or IBGP, internal BGP, and it is non-transitive. So if you're a network engineer or an architect,
remember this, remember the solutions that route reflect are going to come right back to it.
But for the rest of us, we're going to talk about VPC peering in the cloud world.
So when we're dealing with VPC peering, like I said, it's going to be connecting of two entities.
And as you can see in this graphic here, you can see we've got entity one on one side,
entity two on the other side, and we're communicating through VPC peering.
So what you've got to remember is when you use VPC peering, you're creating this network connection
and you've got good communication between both VPCs. So now I want you to really think it,
you're connecting two entities that are external. You're going to have to have your security.
So be very careful with regards to your IAM roles that you're going to use and with your
cross account roles and be very careful in the other ways that you secure it. But for right now,
we're just going to talk about VPC peering. Now, when you're dealing with VPC peering,
you're dealing with two entities that are going to connect to each other on the cloud.
And because they're going to connect, they're going to have to connect via internet protocol.
Now VPC peering on AWS uses the private IP address space.
So remember that, private IP address space. What that means is you've got two VPCs and they've got
overlapping IP addresses. You've got a problem because you can't have overlapping IP addresses
and you must use the private IP address space. So let's walk through some examples.
Now, let's talk about that non-transitive property that we keep talking about.
So for example, if we've got three VPCs, VPC one, VPC two, and VPC three. In a normal environment,
let's use me as an example. If my left hand over here is VPC A, my torso is VPC B and my right hand
is VPC C. If VPC A, which is my left hand here and granted it will look opposite on the camera,
if VPC A advertises a route to me, which is VPC B and VPC advertises A's routes to VPC A
and then VPC C over here says, hey VPC B tell VPC A about my routes. Guess what? Everybody
knows how to reach everybody through me. And that is perfect. This is called a hub and
spoke architecture and we've been using it in networking forever. But remember, VPC peering
is not transitive. And because VPC peering is not transitive, realistically speaking, meaning
routes learned from here, won't be given to here which means we've got to do something different.
So in order to get everybody to talk to everybody, we have to do something called fully mesh our
peers. And you can see in this graphic what we did to fully mesh our peers is we have everybody
connected to everyone. And by doing that, we always learn and can communicate to everyone. Now
this looks simple. We've got basically three VPCs, they're peered in a triangular shape. Life is
good. Now this would be absolutely wonderful, but let's talk about the scalability problem of this.
When you're dealing with fully mesh, meaning everybody has to connect to everybody,
if you've got two devices, it's easy, you've got one link. If you've got three devices,
you've got three links. But as you increase devices, it goes up exponentially. In fact,
it can get so busy with regards to all this peering that this full mesh can be a nightmare.
In fact, the formula is N times N minus one divided by two. So let's say for example,
you had 10 VPCs you wanted to connect. It would be 10 times 10 minus one,
which is nine. So 90 divided by two. As you can see with only 10 different VPCs that you're going
to connect in a full me environment, you've got 45 connections. Now imagine what goes up when you've
got 20 connections, 20 VPCs, 30 VPCs, a thousand VPCs. So obviously this is not going to scale. So
understand this is what's done. Now, let's pretend that we wanted a hub and spoke
environment. Now in this graphic, you can see we've got a hub and spoke environment
and you can see VPC A is in the center. Now let's go back to remembering that
this is non-transitive routing. So VPC A in the center can reach everybody.
VPC B, VPC C, VPC D, VPC E, F and G. And that's great. And VPC A can reach everybody and everybody
can reach VPC A. But in this environment, remember it's not transitive. VPC B can't talk to C or D
or E or F or G. Only A can talk to everybody there. And if we don't want the spokes talking
to each other, this is beautiful. And that's why AWS does this by default. They don't want
you to become transitive. So let's talk about an environment where this would be good, this
non-transitive routing. So now let's say in this environment with this hub and spoke environment,
VPC A or me is the auto manufacturer. And let's say VPC B is a tire manufacturer. And VPC C
is an axle manufacturer. And VPC D is a wheel manufacturer. And VPC E is a muffler manufacturer.
And VPC F is a leather manufacturer. And VPC G makes steering wheels.
Guess what? They don't need to talk to each other through us, but we need to talk to all of them.
So we can buy our steering wheels or our parts. So this again is elegant. And that's why, by default,
the cloud providers are not transitive because look at it this way, right now
you are safe. You can connect to everybody and your organization doesn't become the transit
network for the internet. And naturalistically speaking, what we're talking about, about dealing
with non-transitive routing. But let's say you needed everybody to talk to each other.
Let's say that instead of you being the auto parts manufacturer
and needing to talk to everyone to get your stuff, let's pretend you are a single company,
and let's say you've got your company, or maybe you bought a lot of companies, and
the companies now all need to talk to each other and they need to be able to exchange information.
Well, now you've got a problem. Problem would be, you've got two options. You can fully mesh
by connecting everybody to everybody, but we see that doesn't scale. And we know that hub
and spoke environments don't work because of the non transitive routing. So what if we could still
do hub and spoke environments with transitive routing? What if we could break the rules that
said AWS VPC peering is non-transitive, but if we could break the rules to make it transitive,
then we could run a hub and spoke environment. Well, guess what? AWS gives you that option
as do the other providers. In AWS, they use a technology called CloudHub and Transit Gateway,
and they're similar but different and we'll talk about the differences. For those of you that have
been working in networking, think route reflector 30 years ago. The 30 year old route reflector that
we used in IBGP to break the rules is basically identical to CloudHub and Transit Gateway.
So if you need to create a hub and spoke environment
and pass routing for transitive communications, then you can use CloudHub or Transit Gateway.
So realistically speaking, now you know what that works. So let's talk about what this
actually looks like. Let's look in this graphic over here. You can see we've set up CloudHub.
CloudHub, to let you know, is used with VPC peering and VPNs. So in a VPC peering environment
like such, if we wanted to use a VPN to connect to three different offices, for example,
a Boston office, a Washington DC office and a San Francisco,
to our cloud, we can use a virtual private gateway. We can set up CloudHub and CloudHub
will enable us to pass the routing information from Boston to Washington to San Francisco and
vice versa. And then everyone in this graphic can talk to everybody. That is CloudHub.
Now, guess what? If we wanted to use private lines instead of VPNs or a combination of private
lines and VPNs with AWS, we would use Transit Gateway. Functionally speaking they are the same,
but they are known as a different service. But the whole point of the Transit Gateway
or the CloudHub is to do the following, it's to break the rules of transitive routing,
or non-transitive routing to allow transitive routing.
So let's review. CloudHub and Transit Gateway, both enable hub and spoke transitive routing.
CloudHub, just like the BGP route reflector, uses BGP. So when each site and using CloudHub,
for example, is going to appear for their VPC peering, they're going to use EBGP and EBGP by
default or external BGP, meaning peering to an external autonomous system is transitive. So
instead of being IBGP and being non-transitive, you're going to use EBGP, which is transitive.
Now the way this is going to work, when you set up CloudHub, you're going to have to obviously
use an autonomous system number because of BGP. So make sure you set up your BGP systems right
and make sure you understand BGP. Now, when you set up CloudHub, obviously it'll spit out
a configuration and these things are relatively easy to do, but it's actually knowing what to
do. So please remember this. When you set up VPC peering, everybody can reach everybody. So make
sure you've got your security, make sure you've got your IM, make sure you everything that's going
to be necessary to ensure the communication. I hope you've enjoyed this video on VPC peering.
I look forward to seeing you in another video very soon. It was so nice having you join us for
this video today. Let me tell you about some free services we do for the cloud community.
Once per week, we actually have a free question and answer session live on YouTube, where you
can come and ask us any questions you want about building your career related to cloud computing
or networking and we'll answer them in real time for you. Because we want to get you to your goals.
Several more times per week, we have guests from industry, industry experts that I have
known for decades that are movers and shakers that have changed the world, that can give you
information so you can build the best career. I invite them periodically. They are on my show.
If there's a chance to do some free training on our channel, we'll do it live because we want
you all to have the best skills for the best career. So please subscribe and hit the bell.
I look forward to seeing you and I look forward to assisting you in your technology career.
Thank you so much. This is Michael Gibbs from Go Cloud Architects.