August 27, 2025 • 40 mins
What happens when three major cloud providers each reimagine network design from scratch? You get three completely different approaches to solving the same fundamental problem.
The foundation of cloud networking begins with the virtual containers that hold your resources: AWS's Virtual Private Clouds (VPCs), Azure's Virtual Networks (VNets), and Google Cloud's VPCs (yes, the same name, very different implementation). While they all serve the same basic purpose—providing logical isolation for your workloads—their design philosophies reveal profound differences in how each provider expects you to architect your solutions.
AWS took the explicit control approach. When you create subnets within an AWS VPC, you must assign each to a specific Availability Zone. This creates a vertical architecture pattern where you're deliberately placing resources in specific physical locations and designing resilience across those boundaries. Network engineers often find this intuitive because it matches traditional fault domain thinking. However, this design means you must account for cross-AZ data transfer costs and explicit resiliency patterns.
Azure flipped the script with their horizontal approach. By default, subnets span across all AZs in a region, with Microsoft's automation handling the resilience for you. This "let us handle the complexity" philosophy makes initial deployment simpler but provides less granular control. Meanwhile, Google Cloud went global, allowing a single VPC to span regions worldwide—an approach that simplifies global connectivity but introduces new challenges for security segmentation.
These architectural differences aren't merely academic—they fundamentally change how you design for resilience, manage costs, and implement security. The cloud introduced "toll booth" pricing for data movement, where crossing availability zones or regions incurs charges that didn't exist in traditional data centers. Understanding these nuances is crucial whether you're migrating existing networks or designing new ones.
Want to dive deeper into cloud networking concepts? Let us know what topics you'd like us to cover next as we explore how traditional networking skills translate to the cloud world.
Purchase Chris and Tim's new book on AWS Cloud Networking: https://www.amazon.com/Certified-Advanced-Networking-Certification-certification/dp/1835080839/
Check out the Monthly Cloud Networking News
https://docs.google.com/document/d/1fkBWCGwXDUX9OfZ9_MvSVup8tJJzJeqrauaE6VPT2b0/
Visit our website and subscribe: https://www.cables2clouds.com/
Follow us on BlueSky: https://bsky.app/profile/cables2clouds.com
Follow us on YouTube: https://www.youtube.com/@cables2clouds/
Follow us on TikTok: https://www.tiktok.com/@cables2clouds
Merch Store: https://store.cables2clouds.com/
Join the Discord Study group: https://artofneteng.com/iaatj
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Tim McConnaughy (00:00):
Talk like you would talk.
Um hi, I'm going to talk like Iwould talk.
Okay, this is usually how Italk.
Chris Miles (00:06):
All right, that's fine.
Okay, good, I was just makingsure it wasn't like going to
blow my eardrums out.
Tim McConnaughy (00:12):
Oh yeah, all right then, that's fair.
Okay, hey, and welcome back toanother episode of the Cables to
(00:33):
Clouds podcast.
I'm Tim, and with me, as usual,is Chris.
We're going to try something alittle bit different.
People have been asking for awhile for us to kind of get into
some of the basics of cloudnetworking.
I mean, obviously we have a lotof listeners that are network
engineers that are trying tolearn cloud, or maybe they just
(00:54):
have to deal with cloud, whetherthey want to learn it or not.
And honestly, to be completelyclear, we messed around with
this a little bit when we firstlaunched, but we couldn't seem
to get the cadence right or itwas just really boring, so we
kind of shelved it for a longtime.
But we're going to give itanother try.
We kind of thought about it andwe're going to give it a shot.
(01:15):
So today we're going to talkabout VPCs and VNets and VCNs
and just kind of the containersthat clouds use to build, to
build so that customers canbuild their cloud networks.
We're not going to get superdeep.
We're not going to get superhigh level either.
We're going to be kind of.
We're really going to just talkabout kind of design, that kind
of design philosophies that allthe different cloud providers
(01:38):
use for how they're going tobuild, or rather allow customers
to build, networks within theirum, within their platforms,
cause, at the end of the day, aCSP is the same as a.
As an MSP, it's.
It's all managed services,right.
And so the question is then,for a managed service, when you
(01:58):
want to build a network using amanaged service, what tools,
what you know, what did they,what did the provider give you
to be able to build with?
And that's what we're going toget into today is just starting
with again with VPC, for, likeAWS and GCP column, or Google
cloud calls it, excuse me, vpc,azure calls it VNet, and then,
(02:19):
of course, you know, oci callsit VCN, and I think that's all
of them.
I can't think of any.
I don't know any any.
Any other ones, chris, I thinkthat's it right.
Chris Miles (02:27):
None none that matter, there's only so many we
can talk about.
Tim McConnaughy (02:31):
So we'll see yeah yeah, okay, fair, fair,
fair so.
So let's just get into it andlet's talk about so, basically,
just let's you know, basically,divine, define what that is
right.
So, anybody who creates whetherit be an infrastructure as a
service type of service, whereyou're creating VM workloads or
(02:53):
you're just creating somelocation to put data, whatever
that is when you're creating orconsuming services from a cloud
provider you're creating, atsome point you're going to have
to create a VPC.
I'm just going to say vpc, butwe're talking about vpcs, vnets
and vcns, right?
I just don't want to say allthree.
All the time as we go throughthis, it's going to get really
old really fast.
Chris Miles (03:14):
So I'll just say you can't even use an acronym to
describe, because they wouldall.
It would just be all vvds thetriple v's guys, when you're
making the triple vs.
Tim McConnaughy (03:24):
So that's again .
The basic idea is that it's acontainer, a container for
whatever you're going to buildin the cloud.
Now some services areserverless, meaning that you
don't actually create and holdon to a particular piece of
infrastructure like Lambda, aws,lambda or Azure you know, it's
(03:47):
not Bicep, hold on, save me,because I can't remember the
name for Functions FunctionsAzure Functions.
So yeah, just code that youkind of generate and then you
know the code does something andthere's an outcome.
You don't need a VNet or VPCfor that, necessarily, right?
So it's really focused on youneeding to build some sort of
(04:10):
infrastructure or some you knowholding pattern for something
that you're going to do insideyour own cloud network.
Chris Miles (04:19):
So yeah, yeah, there's a lot of times I feel
like when you're first learningcloud, there's a lot of
similarities drawn between youknow a VPC or virtual private
cloud is is your instance of adata center in the cloud, and I
like we'll get into this alittle bit later but in some
scenarios I like that analogy,but in some that I don't,
(04:40):
because I think of a data centeras a very like
broad-encompassing thing, likeeverything is in a data center,
whereas you know we'll get intothis a little bit later Maybe in
Google you do have, you know,one of those and it contains
everything, whereas AWS youmight, you know, pick it apart
and compartmentalize it, etc.
So a virtual data center isprobably the closest thing, but
(05:04):
it can be as something as smallas just one network, one small
subset of the data center, right?
So I think that's important toremember when you're kind of
designing these out.
Tim McConnaughy (05:15):
Yeah, I mean, and in the book that I wrote for
Network Injurers a few yearsago now, I think I specifically
said you can think of it morelike a network with a router
connected to it and all of theresources that would be
connected to that router.
It's fairly close.
Now sometimes that would be likea full data center, depending
on how the size of the datacenter, or sometimes that's just
a piece of a data center.
So these are, yeah, goodexplanation in both cases.
(05:38):
So let's talk a little bitabout kind of that shift from
traditional networking into thecloud network piece, and I think
for me the biggest one is thisidea of virtualizing the network
.
Right, we know virtual network,we've used virtual networks to
some degree.
If we have any experience withlike ACI or like Cisco ACI or
(06:00):
what is the one that Juniper has, oh, my God.
Abstra Sorry, yeah, I'm like mybrain's not working today, man
or even like VMware, you know ifwe're talking about, like VNICs
and all of that, with virtualnetworking inside a VMware
environment, right, but eventhen, all of those, all of those
virtualized infrastructurethings fail to reach the level
(06:21):
of abstraction that the cloudservice providers, you know, put
you at because, again, it's amanaged service, right?
So the idea of a hyperplane,where the hyperplane is this, is
this gigantic automation systemthat's orchestrating entire
data, you know, not one, two,three, but hundreds of of racks
and data centers together, right, yeah, it's um you know, cause
(06:43):
all the cloud providers.
Chris Miles (06:44):
I think you know we've probably talked about this
at some point.
I've introduced this idea ofavailability zones, or AZs, and
you know, under the hood, an AZis essentially multiple data
centers that are, you know, havedifferent levels of fault
tolerance and are not, you know,dependent on each other,
whereas if you, as a customer,went to build that yourself,
(07:06):
like if you had a regionaldeployment of something you
wanted to be across threedifferent data centers, that's a
one to two year project on itsown right Like that takes a long
time to design something likethat, whereas in the cloud, you
do have the option to basicallyjust be like oh well, you know,
in this region, yeah, let's putthese three things in three
different data centers.
Now, that does have itsdrawbacks and there's still
(07:28):
complexity at the end of the day, which you end up paying for.
But yeah, it's like you said,it's a mindset shift.
Yeah, for sure.
So yeah.
Tim McConnaughy (07:39):
So each provider kind of redesigned or
re-imagined cloud networkingfrom scratch when they were
building their provider services, right.
So let's kind of redesigned orreimagined cloud networking from
scratch when they were buildingtheir provider services, right.
So let's kind of get into thata little bit and it's going to
feel very kind of high level.
But I hope you know, if any ofyou have been using or playing
with the clouds, it'll start tomake sense or, if not, it'll at
(08:00):
least give you an idea of whatto expect when you go into any
one of these clouds.
And again, this is more liketheir design philosophy of how
they make their cloud networking, or not just networking right,
but for our purposes, cloudnetworking, but really just the
whole infrastructure availableto you, right?
So you have kind of.
So AWS was first, obviously AWSwas first, and they have both
(08:22):
first mover advantage and alittle bit of the what'd you
call it, not tech debt.
But, like you know, everybodyelse got to see what was good
and what was bad with what AWSdid and then decide if they
wanted to do it differently.
You know what I mean.
So so, yeah, so AWS kind of hasthis virtualized familiar
concepts, right, familiarconcepts of of networking that
(08:43):
have been virtualized, right.
So we were talking about AZs,or availability zones.
Whether it's your one or morediscrete data centers In AWS,
when you build a VPC, thatcontainer lives within a region,
and by region we're talkingabout a true geographic region,
but also a logical grouping ofdata centers of AZs that AWS
(09:06):
uses.
So, as an example, the biggestone and the first one was
actually I don't know if it'sthe biggest anymore, but
certainly the most important toAWS is still US East 1, right,
the Northern Virginia.
Chris Miles (09:16):
I think it's still probably the biggest right.
Tim McConnaughy (09:18):
So, again, within US East 1, we have
multiple AZs and then altogetherthe geographical grouping of
all these AZs make up the regionthat is US East 1, we have
multiple AZs and then altogetherthe geographical grouping of
all these AZs make up the regionthat is US East 1.
So from AWS's perspective, aVPC exists within a region.
So if I create a VPC, thathyperplane object, if you will,
(09:41):
exists within every data centerthat is inside of US East 1,
right.
Chris Miles (09:48):
By default.
You don't have to explicitlydefine it, and I think when AWS
declares a region, it's at leastthree data centers typically.
Tim McConnaughy (09:57):
I think so.
Chris Miles (09:59):
But US East 1, for example, goes up to six, so it
obviously has a higher level ofredundancy.
But, like we said, that's justby default and you get to pick
and choose how much you want toactually utilize that, and the
other cloud providers do theexact same thing.
Right, everything is all.
These AZs, or specific datacenters, are tied to that
specific region as a whole.
Tim McConnaughy (10:20):
That's right, that's right.
Although, as we talk about eachprovider, you'll see how they
chose to.
Even though they all have thatidea of like, hey, here's an AZ
and here's a region, they choseto use that differently when it
came time to like to doing theinfrastructure for it.
So, in this case of AWS, let'sjust start there, right.
(10:41):
Aws ties.
Each subnet is tied to anavailability zone.
So when you and that's anexplicit choice that you make
when you create a subnet, soyeah, so maybe just to take a
quick step back is like when youdefine this logical container,
this network container per cloudprovider.
Chris Miles (11:00):
Doesn't matter what it is.
You basically assign a C ciderrange.
Yeah, that's right.
Moving to cloud was theweirdest thing.
We started saying cider insteadof subnet I don't know why this
happened, but like cider, wasthe the way to describe a a
network?
Um, but you basically assign acider range, which is a super
net that's assigned to theentire vpc or the, the entire
(11:23):
virtual networking construct,and then you kind of chop that
up into separate subnets, right?
And like Tim is saying, everytime you chop that up and you
put a subnet into a VPC, youhave to define what data center
does this belong to or whatavailability zone does this
belong to.
In AWS specifically In AWS.
Yes, that's a good point.
Tim McConnaughy (11:42):
I forgot to mention the CIDR piece.
So yeah, that's a good, good,good point.
I forgot to mention the thecider piece.
So yeah, so it's a subnet, isjust like a subnet.
That hasn't changed, right?
What's changed with the cloudpiece is that again we're
starting with a supernet andthat supernet exists within the
cider, or sorry, within the vpc,but not outside of the vpcs.
That's the whole constructpiece, right, and and we're
gonna not talk a lot about howeach, each VPC can actually have
(12:04):
the same CIDR, which causes allsorts of network design
problems down the road.
Chris Miles (12:10):
But anyway, long story short, don't do that.
Yeah, try not to do that.
Tim McConnaughy (12:16):
But that was a design choice that I think all
of them made, really, except forGoogle, ultimately, you know,
was that they were thinking tobegin with that you know an
entire enterprise would onlyever need one.
So they were like, oh well,just give yourself a slash 16
network and just go to town.
But what ended up happening, ofcourse, is that there were
administrative or security orother you know logical reasons
(12:40):
to break this up, at least inAWS.
The way AWS designed theirconstructs made it easier to do
design by breaking it up, andwhat ended up happening is that,
you know, then you get intoweird things like that, but
let's get back to it.
So subnets are assigned to AZs,and that's explicit choice that
you make in AWS.
But you want to tell us howthey did that differently in
(13:03):
Azure.
So Microsoft chose to do this alittle bit differently.
Chris Miles (13:09):
Yeah, so Azure still has the same concept,
right, all the regional datacenters are divided into
specific availability zones butby default, any subnet that you
define within Azure spans all ofthose data centers.
It spans across all of theavailable AZs, right, so you
(13:30):
like.
Whereas, if you think aboutlogically, where you put
resources in that virtualcontainer, right, and AWS, when
you put you know virtualmachines, essentially the
infrastructure that's running inthere, a virtual machine is
always going to be tied to an AZ.
That means it's always going tobelong to a subnet that is tied
to that same AZ and everythingis kind of locked in this kind
of vertical pattern, right,whereas Azure is horizontal.
(13:56):
Right, you could have virtualmachines deployed in separate
subnets but they're all withinthe same availability zone and
we won't get too far into it.
But, like this, this kind of ledto them also developing
something called availabilitysets where you'd like.
Because you have this nature ofbeing able to span across
multiple az's, you have todefine you know where in those
(14:18):
um.
What.
What logically, between thoseum virtual machines is is kind
of fate shared, I guess, is theword I'll use there.
Tim McConnaughy (14:26):
That's right.
Chris Miles (14:28):
So you have to, you know, kind of go to extra
lengths to make sure that you'remaking sure that those things
are consistently available, youknow with maintenance and things
like that.
But that is a fundamentaldifferentiator between AWS and
Azure, and if you're from oneperson moving to the other, it
(14:48):
kind of changes the way that youhave to think about it, right?
Tim McConnaughy (14:52):
Yeah, and especially how you have to think
about how you deploy yourinfrastructure, right?
So in AWS, because you're veryexplicit about this subnet is
going to be assigned to thisavailability zone, think about
from a resiliency designstandpoint, like what that means
.
Right, so you're going todeploy an ace, essentially like
an A side and a B side, like wewould like a red green, like we
(15:12):
would think a red blue weather,like we would think in in.
That makes it very logical.
So what I find is that mostnetwork engineers find that AWS
is very logical to them.
Like just coming straight fromnetwork engineering to AWS, it
seems very logical because ofthings like that.
Right, as network engineers, wethink in resilience a very
(15:33):
large amount and the idea ofexplicit resilience is very,
very normal for us as engineersto be thinking about right,
about right Versus, whereMicrosoft, like Chris said,
microsoft took this idea thatlike, hey, it doesn't matter
where you deploy it because wehave it everywhere and if there
is a failure in any of theseavailability zones, we're going
(15:55):
to move your virtual machinesfor you to another availability
zone, right?
Chris Miles (16:00):
Yeah, aws like AWS fundamentally is.
A lot of people compare it toLegos.
Right, it's always, we alwaysgive you the building blocks and
you can do whatever you wantwith those.
Like, we give you thatflexibility, whereas Azure does
kind of be like oh well, yeah,you can explicitly put stuff in
certain configurations that willalign to what exactly you want,
(16:22):
but let us handle a lot of thatstuff, right?
So it's um, and then there'sdefault behaviors that
drastically change things, soyou gotta be very aware of those
.
Tim McConnaughy (16:33):
Yeah, absolutely.
And then uh, so let's talkabout Google cloud as well,
because Google cloud completelythrows the book out in terms of
how anybody designed this Right.
So, with Google Cloud, theiridea was let's create one global
VPC for customers and thatglobal VPC and it's not that you
can only have one VPC, but whenI say global VPC, what I'm
(16:56):
talking about is a truegeographically global construct.
Like remember I said the otherall the other providers do
region locking for a VPC, vc,vnet, whatever Google Cloud
chose to make their constructglobal.
And then, when you assignsubnets, your subnets are
(17:17):
actually associated withdifferent regions, like global
regions of the world, basically.
Chris Miles (17:26):
Yeah, so they took the idea kind of the same way
Azure does, where the subnet canbe, you know, span across
multiple AZs within the region.
But whenever you cross regions,those things were always in
different virtual networks froman Azure perspective, whereas
Google is like no, everything'sin the same VPC.
So it's like it can kind ofobviously dictate how you need
(17:48):
to facilitate routing andfirewalling and things like that
between between these things.
So yeah, it's just another,another thing to be considerate
of.
It's like it's like thisexpanding bubble of how what the
VPC can contain across thethree major providers.
Tim McConnaughy (18:04):
Yeah, and and again, what you know, what you
should be doing as you listen tothis if you, if you knew it.
Cool If you didn't know.
Cool, as you're hearing, though, about different ways that the
cloud providers are providingthe same service.
Basically, because I mean, atthe end of the day, a VPC is a
VPC is a VPC.
You know VNet whatever it's alogical, and you know VNet
(18:25):
whatever it's a logical and youknow construct for you to put
your resources inside right.
So, but think about, from adesign perspective, or just even
an implementation perspective,like what does that look like
when you're deploying resourcesinto a Google global VPC and
have to deal with, like latencyconcerns, right?
So you're probably not going toput in a red blue deployment
(18:48):
where they're in, necessarily,like you know different subnets
or different subnets that areone in Tokyo and one in London
or something like that.
You know that wouldn't make anysense, assuming that these two
ever had to talk to each otheror that they were serving the
same customers, or whatever youknow.
But also think about thecomplexity, the lack of a
complexity, probably from arouting perspective of being
(19:10):
able to have everything justkind of connected in the same
VPC but at the same time, theincredible complexity that
that's going to add if you wantto do any kind of segmentation
or inspection between theseworkloads, right, and then it's
actually flipping the script togo the opposite way.
To talk about like AWS versus,you know, azure versus Google
(19:31):
Cloud, where you have theopposite problem, where now you
have routing concerns, movingbetween VPCs, you know, and
actually the inspection doesn'tget particularly easier in that
case as well, it just becomespart of the routing.
Actually is what ends uphappening.
Chris Miles (19:46):
Yeah for sure, yeah , I think another point that's
kind of continuing on this kindof differentiating philosophies
between the cloud provider,these three major cloud
providers as well, is theconcept of the VPC, or the
virtual network router, and howthat participates in the
conversation between theinfrastructure that resides
(20:08):
within the logical container,between the infrastructure that
resides within the logicalcontainer.
So you know, like within AWS,there's a concept of a VPC
router.
You don't actually see aconstruct called VPC router.
You don't actually, you know,configure something called VPC
router.
The way you do that is bydefining route tables and
assigning them to subnetsessentially, right.
But you know, if you've everworked on a router, you know
(20:30):
what a route table is.
Right, it's a.
It's a very, you know,definitive list of destination
prefixes.
Next hops, et cetera, right.
So in this scenario, the nexthop is typically, you know, it
could be something outside theVPC, it could be something
within the VPC, it could be anendpoint, like if there's a
service that's deployed withinthat VPC that you need access to
(20:51):
, et cetera.
But one thing that is alsofundamentally different is, you
know, azure and Google have thesame construct.
Right, there is a router thatexists within that VPC.
It's a virtual construct andthe way you control, that is,
defining those route tables.
One thing that is unique thatI'll call out specifically with
AWS compared to the other majortwo is when that virtual router
(21:13):
is involved in the conversation.
So if we think, like me,logically as a network engineer
my entire life, I'm like oh,these two things are on the same
subnet, they're going to talkdirectly to each other.
There's no, nothing needs tosit in between.
That conversation that is true.
In AWS you can have direct peerto peer communication.
That conversation that is true.
(21:34):
In AWS you can have directpeer-to-peer communication.
It's like over a virtualizedlayer.
Two thing we won't get intoexactly on that there's no layer
two in cloud, yeah, like wedidn't even touch on that.
But in Azure and GCP that isnot the case.
The virtual router actuallybehaves or is involved in every
single conversation, and if youthink about that, then that can
obviously cause issues when youdidn't expect there to be issues
(21:54):
, right?
If you just assume things areon the same subnet, they should
have, you know, full east-westcapability to talk to each other
.
That's not always the case,right?
So there's that concept thatcomes into play as well.
Tim McConnaughy (22:06):
Yeah, for sure.
I mean, and for completeness,just we'll speak briefly about
OCI, because the truth is, a lotof what OCI does is very
similar to the way, I don't know, it's kind of like from a
routing perspective it feels alittle bit more like AWS.
It is slightly different.
The big one, the big differenceto point out with OCI and we're
not neither of us are OCIexperts, by the way, just FYI.
Chris Miles (22:28):
Yeah, I was going to say the reason we didn't
really include OCI on thiswasn't a dist OCI, it's just the
one we know the least.
Tim McConnaughy (22:34):
Yeah but I mean , I did some research on this
because I didn't want.
I wanted to include OCI,because OCI is becoming a major
player now that you know,especially with like the AI
workload stuff that they'redoing or not.
The big difference with OCI isthat their concept of a VCN is
really tied to these thingscalled compartments, which
(22:55):
doesn't really existmeaningfully in the other clouds
, which is the idea of not justtenancy but like secure, like
administrative policy.
So it's very, very tied intothis idea of you know, if you
want to connect two of anything,if you want to connect anything
together, there's like a wholecompartmentalized policy that
sits on top of of all of that.
So I'm not going to get intothat.
We're we'll, we could do a wholeshow, probably on OCI when we,
(23:18):
when we become better at it, orwe'll actually probably what
we'll do is reach out to some ofour friends at OCI and actually
have that, have thatconversation.
We, we know several, so, um,but yeah, but again, as chris
said, not to diss you know oci,which it's the one that both of
us know the least because weboth had the list, I think.
I think I had one customer whenyou know that I that had oci
(23:39):
and I had to learn enough aboutthe, uh, just to be dangerous
max yeah so.
But I think that will change,especially as, as oci is coming
up in the world now, they'regetting definitely a lot more
adoption.
So all right, let's get so let.
So let's talk a little bit nowabout the, a little bit about
the philosophy, how thephilosophy means the behavior is
different, right?
(23:59):
So what that means is like allright.
So, for example, going back toAWS, with manual AZ design,
which we're talking about, likeeverything is very explicit in
AWS.
What that ends up meaning isthat you as a network you know,
cloud network engineer, whateverthe title is that, when you're
building cloud networks, itmeans you have to be very, very
(24:20):
specific.
You have to be very granularbut also very predictive with it
, which is honestly what, like Isaid, network engineers really
like that.
Because, you know, somebodytold me this years ago ago and I
still think it's pretty goodtoday.
You know, a network is like adog, right?
You want to train your dog.
You don't want to let your dogrun around rampant just doing
(24:41):
whatever it wants.
You want the dog to do thetricks when you tell it.
So that's very normal for us,right?
But, like with Azure, again,like Chris was saying, it's very
much a let us handle thecomplex parts right.
You build it and we'll handleall of the resiliency for you.
Less control it's easier HA,but you get less control over it
(25:03):
.
Now in Azure you actually canforce objects to be deployed in
certain AZs, but they actuallyrecommend you don't do that
because it breaks their HAautomation.
Basically, then it's stuck tothat AZ and if that AZ goes down
it won't move.
So again, different designphilosophy.
(25:25):
Aws is like that's how it isand that's why you should design
around it.
And Microsoft is like you don'tneed to design around it, we'll
handle it.
It doesn't end up being thecase, I don't know.
And then Google is just likeglobal networking Just put
everything in the same networkand we will do all of the work
for you.
I think we've said many timesthat we feel like Google Cloud
(25:47):
networking is much moredeveloper focused and friendly,
because you don't really wantyou to necessarily care about it
.
Chris Miles (25:54):
Honestly, Unfortunately, but yeah.
Tim McConnaughy (25:57):
Oh, anyway, all right.
So let's, let's, let's wrap upsome with some gotchas that you
can run into, like you know,into in just with VPCs, even
something as simple as just VPCdesign the philosophies of the
different cloud providers.
If you don't what's the wordI'm looking for?
If you don't kind of conform tothe philosophy that they're
(26:18):
using when they designed likehow they want you to design your
cloud, basically If you rageagainst that and try to do it a
lot of times, it'll work, but itends up being a lot more
brittle.
It'll work, but it ends up beinga lot more brittle.
Like you know, when you'reusing third-party devices and
you kind of use third-partydevices to overcome some of the
design choices, sometimes youhave to do that right, like if
(26:39):
you can only have 500 routes inthe route table and that's what
they give you, but you need,like 10,000, you have to do a
third-party, something that cansupport it, but you should still
design your third partyimplementation with the design
philosophy of that cloud in mind.
Does that make sense?
Hopefully that made sense.
Chris Miles (26:57):
No, yeah, I see what you mean, yeah.
Tim McConnaughy (26:59):
All right, so okay, so like.
So AWS, the big one is becauseyou are very explicit about, and
they expect you to be veryexplicit from a, from a DR
perspective and also from an HAresiliency perspective.
They want you pinning resourcesto different availability zones
, run kind of like an AB or ared blue they.
(27:19):
That leaves you as the networkdesigner to deal with traffic
that will cross availabilityzones.
So what that means is that,like you know, sometimes that's
a design philosophy, Like youjust need to be able to do that
for resiliency purposes.
Sometimes you're supposed tolike build, basically like
application rails, if you will,where, like, you've got your X
number of tiers of applicationand the A tier or the A side
(27:43):
should never talk to the B sideand vice versa.
You know, but depending on yourapplication, depending on your
use case, maybe that's notfeasible, right, and then let's
not talk about and then, youknow, think about down the road,
we might talk about firewallsand stuff where that's you know
that could be part of yourresiliency strategy.
You know if you have an actualfirewall and that virtual
(28:03):
machine dies, like what's goingto happen to the traffic on that
rail?
Is that rail going to just diewith it or is that you know what
happens?
Do we cross availability zones?
So the reason I bring this upis because cross AZ traffic and
cross region traffic and justbasically just transfer, that
leaves the data centeressentially with aws.
Is money like you charge, theycharge you, and now it's an
(28:25):
infinitesimally small amount ofmoney, but it adds up very.
Chris Miles (28:29):
It can add up very if you're doing, if you're doing
, you know, synchronousreplication between things,
between two data centers thatcan.
That can eat up a lot of moneyvery quick, right yeah, and it
has right so let's like, in thatsame vein of of which I
mentioned, you know, like it'sjust a click of a button to make
something you know kind ofmulti availability zone, multi
(28:49):
data center or multi region.
Um, that all comes at a cost.
Right, they build, they giveyou these.
You know building blocks, butthe building blocks are kind of
no holds barred, you can buildwhatever you want.
So you can kind of build yourown noose if you're not careful.
Right, so it's it's, you've,you've got to be very aware of
(29:09):
that in the in, in, in the grandscheme of things because I've,
I've said this many times isthat the newest inch, the thing
that cloud networking brought tothe table, was this concept of
a toll booth.
Right, it's like no matter whereyou're transferring data in and
out of their data centers,you're paying the toll booth.
You know whether it be onecents per gigabyte or two cents
per gigabyte, what have you?
(29:30):
It doesn't sound like much, butyou haven't been paying that in
your, in your physical datacenter for the longest time,
right, you've, you've, you'vepaid for a pipe and you, you can
either use all the pipe or usenone of the pipe, right?
Whereas now it's like, hey, webuilt these pipes and as you put
oil through them, we're goingto charge you for every gallon,
right?
So it's a different way tothink about it.
Yep, absolutely.
Tim McConnaughy (29:50):
So that's I mean and every.
To be clear, like every cloudprovider has some version of
this, but you definitely keenlyfeel it, not feel it?
What's the word I'm looking for?
You have to really think aboutit.
In AWS versus like Azure, whereyou know you don't even deploy
in a specific availability zoneand all of that, right, you're
(30:11):
generally just deploying gearand trusting Microsoft to take
care of it, but you're usingavailability sets to say, okay,
azure, you know, this is my Arail, this is my B rail.
They exist in the same az.
Maybe maybe they're in the samedamn data center, maybe they're
the same rack, we don't knowright, but when you azure, do,
uh, maintenance, consider thatthese two devices need to not be
(30:32):
down at the same time and theazure automation will do that
right.
So that's, you're handing thekeys.
So the trade-off there is thatyou're handing the keys over to
Azure, to automation.
There's no person making thisdecision, right?
Azure automation is deciding oh, I need to reboot this rack.
Or maybe Azure's not decidingit at all.
Maybe Godzilla steps on thedata center and that AZ goes
(30:55):
down and now Microsoft is goingto automatically move those
workloads to another data center.
Move those workloads to anotherdata center.
But you know, when you designedthe applications or maybe you
maybe well, you didn't designthem because you're a network
engineer in this case, but theapplication may not be able to
handle the latency that justhappened from having to move to
a second data center and connectto other stuff, you know.
(31:17):
So it gives you lessgranularity, a little bit more.
You know easy resiliency, butit also means that you it's the
classic Faustian bargain, rightLike you hand over the keys and
you trust that, well, if it'snot in my control then you know,
hopefully they can take care ofit.
Yeah, and just to be clear.
Chris Miles (31:38):
Aws has this.
They have kind of services andconstructs that are available to
let you fail over in the samescenario, but it's just not as
implicit right you have to buildit.
Tim McConnaughy (31:49):
That's it.
Chris Miles (31:50):
So that's really the only minute difference.
I just want to make sure itdoesn't sound like we're saying
AWS is less resilient oranything.
Obviously, like you said, theyhad first mover advantage and
they chose a path and it was tolet the customer build anything
and absolutely everything,whereas Azure kind of came back
with a different approach.
But I will say there's alsothings that we see in terms of
(32:13):
just the way the cloud providersare moving.
It seems like and this is muchmore widespread than just the
networking piece but there arecertainly differentiators that
make the cloud providers lookmore appealing to certain you
know customers, or you knowtypes of customers, verticals,
et cetera, things.
(32:44):
Because I think they'll see,like, you know, if you're a
major cloud provider B and yousee cloud provider A start
charging for a certain thing andyou know people gripe about it,
but they end up, you know,making record margins, that's
right.
Eventually cloud provider B isgoing to start charging for that
as well, right.
So it's like, just becausethings are free today or
different today, that candrastically change.
Like just back to the conceptof you know paying for cross AZ
(33:04):
traffic or cross region traffic.
I think you know you can buildthis concept of a peering
between these logical containers.
So you can have a VNet peeringor a VPC peering, whereas keep
me honest here, but I thinkacross VPC peering as long as
you stay within the AZ, youdon't pay for that.
Tim McConnaughy (33:27):
Whereas Azure if you use a VNet peering.
Chris Miles (33:28):
They actually do charge for that, like on top of
it.
So it's like everything isthere's nuance to everything.
Tim McConnaughy (33:30):
Yeah, I mean, there's a lot more nuance than
we could possibly get into in apodcast episode, but this is the
point that we're making rightDesign philosophies, right.
So AWS does exactly that.
So VPC peering counts as datatransfer only if the money, or
sorry, the data, crosses AZs.
Which is to say like, again,take two different VPCs, put two
(33:53):
different workloads in thoseVPCs and maybe they need to talk
.
Well, if the workload in VPC Ais deployed in subnet A, which
is an AZA, and then VPC A isdeployed in subnet A, which is
in AZA, and then VPC B is in Bis in subnet B, those are two
different data centers and sowhen those two workloads talk,
even though it's entirely acrossthe database's backbone, it's
still using their pipes andmoving between crossing AZs.
(34:16):
But whereas if everything wasin A, then that VPC peering
would be completely free,because it's actually not even
leaving the same data center.
It's in the same data center ordiscrete group of data centers
as they, as they call it Right.
Chris Miles (34:29):
So yeah, that's hopping across the hypervisor
Exactly.
Tim McConnaughy (34:33):
So which and this is this is the point, Right
.
And then you have, you know,you have Google, where it's all
global, it's all the same, it'slogically all in the same VPC,
right?
So from your perspective it'sall the same, but obviously you
know they're.
They're different betweensubnets really means between
either geographical locations orat least data centers, so, or
(34:53):
something like that.
So, yeah, why don't we wrap upreal quick with some, some just
misconceptions about what otherpeople you know, what we really
get wrong, what we really, uh,assume based on the names and
and and kind of how we expect itto work, and then we'll, we'll
wrap it up.
You want to take this one.
Chris Miles (35:10):
Yeah, sure, Um.
So a couple of ones that wehear a lot.
Um, as far as misconceptions go, is like we, uh, you know
people talk about you know kindof within VPC is like oh, VPC.
Or you know people talk aboutyou know kind of within vpc is
like oh, vpc.
Or you know, subnet with it'sit's kind of just like a vlan.
Um, but kind of going back tothat piece that I talked about
before with the, the vpc or thevirtual network router, um, that
(35:33):
can very much not be the case.
Um, I would say that it don't.
Let's not talk about vls man Incloud, it's all layer three.
There's a couple scenarioswhere you need to identify VLANs
, but that's only when you'rebuilding physical connectivity
into a data center and you needto define the VLAN.
But other than that, let's nottalk about VLANs.
(35:53):
Everything is segmented eitherat a virtual layer, where you
don't need a VLAN, or it's alllayer three segmentation, right?
So every provider, the conceptof it being just like a VLAN,
every provider breaks that in adifferent way.
Um, so this like, if we want to, you know, get down into the
nuts and bolts, that's, that'snot really true.
Um, also, this idea of like, ohwell, I can, I can put this in.
(36:17):
You know, if I want to changeit later, that'll be super easy,
and that's, and that's,relatively true most of the time
.
However, there are certainthings that become immutable per
provider, right?
So there's things that once youput them in, you cannot change
them without completely deletingthe construct.
Right Now, we won't sit hereand kind of list out each one of
(36:37):
those things individually,because we could be here all day
.
But you know, there's, there'sthe cloud makes things easier,
but, like, there's alsodependencies built on their back
ends where they can't just, youknow, swap things out, right,
you have to be aware of whenthat comes into play.
So that's something you shouldalso be very considerate of.
Any additional ones you canthink of Tim.
Tim McConnaughy (36:59):
Well, I mean just speaking about the VPCs
themselves.
Right, Like, a VPC is immutablein that once you create it and
you assign a CIDR to it, you canadd new CIDRs, but you can't
like change the CIDR that wasassigned, you're done.
That's every you know.
And if you want to change theCIDR of a VPC and not just add a
second one but fundamentallychange it, you have to destroy
(37:22):
every resource that is in thatVPC and then delete the VPC and
then you can recreate it with anew site.
And if you think about it, ifyou've deployed a whole
application stack in that VPCthat's not a small change, right
If you've designed it right,then hopefully maybe there's
another VPC or you just stand upanother VPC, you know, and
(37:42):
replicate the application.
That's really more.
What we're talking about is,truthfully, you're going to in
cloud.
You're not going to, you know,have this downtime where you're
going to destroy something andthen rebuild it, right, you're
just going to build another one.
Remember, I said you got VPCswhere you can have the same
ciders and all this other stuff,but you're going to build
another one and then you'regoing to tear that one down,
right, and you're going to moveall your workloads and
(38:03):
everything over.
But the point is, I know thatcloud is agile, but it's not
immutable or it is veryimmutable.
There are things, especiallywith VPCs, that basic construct
is an immutable construct.
Chris Miles (38:16):
Maybe if you're a very important customer and you
call support, there's probablysome strings they can pull, but
you don't want that to be partof your regular workflow.
That would just be, I don'tknow how.
If you guys like spending timeon the phone, I don't, so I
wouldn't.
I wouldn't make that a makethat a habit.
Tim McConnaughy (38:31):
So if you guys, uh, we'll go ahead and wrap up.
If you guys I'm sorry if youguys, if, if our listeners, um,
enjoyed this, uh, you know thistype of format, or if it you
know we hit too high, we hit toolow, we didn't hit the right
things, I would love, we wouldlove some, some feedback,
(38:51):
because we like the idea of kindof going into some of this,
especially like how it'sdifferent between providers and
also how you, as a networkdesigner, are going to have to
think about the fact that it'sdifferent and what you're going
to build with it and what itlets you do or doesn't let you
do.
If we're hitting the rightnotes, let us know and we'll do
(39:11):
more like this.
Chris Miles (39:14):
Yeah, we know we have listeners that everyone's
at a different stage in theircareer.
Some people are absolutebeginners, some people are very
seasoned vets, and then the samescenario applies to cloud.
Right, some people are justgetting started with cloud.
Some people have, like, onlybeen doing cloud for the last
you know five, 10 years orsomething like that, right?
So it's like we want to kind ofgo over some of the base layer
(39:36):
concepts and maybe we'll turnthis into a series or something
like that and we'll talk aboutyou know kind of.
You know we touched on the mostbasic thing here, which is VPC,
but we can start talking about,you know, inter-vpc or
inter-VNet networking.
You know services like TransitGateway, cloud WAN, virtual WAN,
et cetera.
So I think we'll probablyexpand into some of that and
(39:56):
talk about some of the securityconcepts and draw you know
analogs to traditionalnetworking there and talk about
network segmentation et cetera.
So that's where we're headed,or where we're thinking we're
going to head.
So we would love some feedback.
So please reach out, email,twitter, x, blue Sky, linkedin,
whatever.
Just send us a PM, let us know.
(40:16):
Yeah, appreciate it, okay.
Tim McConnaughy (40:19):
Let's go ahead and wrap up.
Speaking of.
Chris already gave all the listof places.
We want you to follow us.
Chris Miles (40:25):
On YouTube as well.
On YouTube, of course, you cancomment on.
Tim McConnaughy (40:28):
YouTube if you want.
Yeah, please, please feel free.
It'd be nice.
You usually just get the spamones.
Chris Miles (40:36):
No Nigerian princes , please.
Tim McConnaughy (40:38):
Yeah, yeah, all right, we'll wrap it here and
we will see you guys in the nextepisode.
Talk like you would talk.
Um hi, I'm going to talk like Iwould talk.
Okay, this is usually how Italk.
Chris Miles (00:06):
All right, that's fine.
Okay, good, I was just makingsure it wasn't like going to
blow my eardrums out.
Tim McConnaughy (00:12):
Oh yeah, all right then, that's fair.
Okay, hey, and welcome back toanother episode of the Cables to
(00:33):
Clouds podcast.
I'm Tim, and with me, as usual,is Chris.
We're going to try something alittle bit different.
People have been asking for awhile for us to kind of get into
some of the basics of cloudnetworking.
I mean, obviously we have a lotof listeners that are network
engineers that are trying tolearn cloud, or maybe they just
(00:54):
have to deal with cloud, whetherthey want to learn it or not.
And honestly, to be completelyclear, we messed around with
this a little bit when we firstlaunched, but we couldn't seem
to get the cadence right or itwas just really boring, so we
kind of shelved it for a longtime.
But we're going to give itanother try.
We kind of thought about it andwe're going to give it a shot.
(01:15):
So today we're going to talkabout VPCs and VNets and VCNs
and just kind of the containersthat clouds use to build, to
build so that customers canbuild their cloud networks.
We're not going to get superdeep.
We're not going to get superhigh level either.
We're going to be kind of.
We're really going to just talkabout kind of design, that kind
of design philosophies that allthe different cloud providers
(01:38):
use for how they're going tobuild, or rather allow customers
to build, networks within theirum, within their platforms,
cause, at the end of the day, aCSP is the same as a.
As an MSP, it's.
It's all managed services,right.
And so the question is then,for a managed service, when you
(01:58):
want to build a network using amanaged service, what tools,
what you know, what did they,what did the provider give you
to be able to build with?
And that's what we're going toget into today is just starting
with again with VPC, for, likeAWS and GCP column, or Google
cloud calls it, excuse me, vpc,azure calls it VNet, and then,
(02:19):
of course, you know, oci callsit VCN, and I think that's all
of them.
I can't think of any.
I don't know any any.
Any other ones, chris, I thinkthat's it right.
Chris Miles (02:27):
None none that matter, there's only so many we
can talk about.
Tim McConnaughy (02:31):
So we'll see yeah yeah, okay, fair, fair,
fair so.
So let's just get into it andlet's talk about so, basically,
just let's you know, basically,divine, define what that is
right.
So, anybody who creates whetherit be an infrastructure as a
service type of service, whereyou're creating VM workloads or
(02:53):
you're just creating somelocation to put data, whatever
that is when you're creating orconsuming services from a cloud
provider you're creating, atsome point you're going to have
to create a VPC.
I'm just going to say vpc, butwe're talking about vpcs, vnets
and vcns, right?
I just don't want to say allthree.
All the time as we go throughthis, it's going to get really
old really fast.
Chris Miles (03:14):
So I'll just say you can't even use an acronym to
describe, because they wouldall.
It would just be all vvds thetriple v's guys, when you're
making the triple vs.
Tim McConnaughy (03:24):
So that's again .
The basic idea is that it's acontainer, a container for
whatever you're going to buildin the cloud.
Now some services areserverless, meaning that you
don't actually create and holdon to a particular piece of
infrastructure like Lambda, aws,lambda or Azure you know, it's
(03:47):
not Bicep, hold on, save me,because I can't remember the
name for Functions FunctionsAzure Functions.
So yeah, just code that youkind of generate and then you
know the code does something andthere's an outcome.
You don't need a VNet or VPCfor that, necessarily, right?
So it's really focused on youneeding to build some sort of
(04:10):
infrastructure or some you knowholding pattern for something
that you're going to do insideyour own cloud network.
Chris Miles (04:19):
So yeah, yeah, there's a lot of times I feel
like when you're first learningcloud, there's a lot of
similarities drawn between youknow a VPC or virtual private
cloud is is your instance of adata center in the cloud, and I
like we'll get into this alittle bit later but in some
scenarios I like that analogy,but in some that I don't,
(04:40):
because I think of a data centeras a very like
broad-encompassing thing, likeeverything is in a data center,
whereas you know we'll get intothis a little bit later Maybe in
Google you do have, you know,one of those and it contains
everything, whereas AWS youmight, you know, pick it apart
and compartmentalize it, etc.
So a virtual data center isprobably the closest thing, but
(05:04):
it can be as something as smallas just one network, one small
subset of the data center, right?
So I think that's important toremember when you're kind of
designing these out.
Tim McConnaughy (05:15):
Yeah, I mean, and in the book that I wrote for
Network Injurers a few yearsago now, I think I specifically
said you can think of it morelike a network with a router
connected to it and all of theresources that would be
connected to that router.
It's fairly close.
Now sometimes that would be likea full data center, depending
on how the size of the datacenter, or sometimes that's just
a piece of a data center.
So these are, yeah, goodexplanation in both cases.
(05:38):
So let's talk a little bitabout kind of that shift from
traditional networking into thecloud network piece, and I think
for me the biggest one is thisidea of virtualizing the network
.
Right, we know virtual network,we've used virtual networks to
some degree.
If we have any experience withlike ACI or like Cisco ACI or
(06:00):
what is the one that Juniper has, oh, my God.
Abstra Sorry, yeah, I'm like mybrain's not working today, man
or even like VMware, you know ifwe're talking about, like VNICs
and all of that, with virtualnetworking inside a VMware
environment, right, but eventhen, all of those, all of those
virtualized infrastructurethings fail to reach the level
(06:21):
of abstraction that the cloudservice providers, you know, put
you at because, again, it's amanaged service, right?
So the idea of a hyperplane,where the hyperplane is this, is
this gigantic automation systemthat's orchestrating entire
data, you know, not one, two,three, but hundreds of of racks
and data centers together, right, yeah, it's um you know, cause
(06:43):
all the cloud providers.
Chris Miles (06:44):
I think you know we've probably talked about this
at some point.
I've introduced this idea ofavailability zones, or AZs, and
you know, under the hood, an AZis essentially multiple data
centers that are, you know, havedifferent levels of fault
tolerance and are not, you know,dependent on each other,
whereas if you, as a customer,went to build that yourself,
(07:06):
like if you had a regionaldeployment of something you
wanted to be across threedifferent data centers, that's a
one to two year project on itsown right Like that takes a long
time to design something likethat, whereas in the cloud, you
do have the option to basicallyjust be like oh well, you know,
in this region, yeah, let's putthese three things in three
different data centers.
Now, that does have itsdrawbacks and there's still
(07:28):
complexity at the end of the day, which you end up paying for.
But yeah, it's like you said,it's a mindset shift.
Yeah, for sure.
So yeah.
Tim McConnaughy (07:39):
So each provider kind of redesigned or
re-imagined cloud networkingfrom scratch when they were
building their provider services, right.
So let's kind of redesigned orreimagined cloud networking from
scratch when they were buildingtheir provider services, right.
So let's kind of get into thata little bit and it's going to
feel very kind of high level.
But I hope you know, if any ofyou have been using or playing
with the clouds, it'll start tomake sense or, if not, it'll at
(08:00):
least give you an idea of whatto expect when you go into any
one of these clouds.
And again, this is more liketheir design philosophy of how
they make their cloud networking, or not just networking right,
but for our purposes, cloudnetworking, but really just the
whole infrastructure availableto you, right?
So you have kind of.
So AWS was first, obviously AWSwas first, and they have both
(08:22):
first mover advantage and alittle bit of the what'd you
call it, not tech debt.
But, like you know, everybodyelse got to see what was good
and what was bad with what AWSdid and then decide if they
wanted to do it differently.
You know what I mean.
So so, yeah, so AWS kind of hasthis virtualized familiar
concepts, right, familiarconcepts of of networking that
(08:43):
have been virtualized, right.
So we were talking about AZs,or availability zones.
Whether it's your one or morediscrete data centers In AWS,
when you build a VPC, thatcontainer lives within a region,
and by region we're talkingabout a true geographic region,
but also a logical grouping ofdata centers of AZs that AWS
(09:06):
uses.
So, as an example, the biggestone and the first one was
actually I don't know if it'sthe biggest anymore, but
certainly the most important toAWS is still US East 1, right,
the Northern Virginia.
Chris Miles (09:16):
I think it's still probably the biggest right.
Tim McConnaughy (09:18):
So, again, within US East 1, we have
multiple AZs and then altogetherthe geographical grouping of
all these AZs make up the regionthat is US East 1, we have
multiple AZs and then altogetherthe geographical grouping of
all these AZs make up the regionthat is US East 1.
So from AWS's perspective, aVPC exists within a region.
So if I create a VPC, thathyperplane object, if you will,
(09:41):
exists within every data centerthat is inside of US East 1,
right.
Chris Miles (09:48):
By default.
You don't have to explicitlydefine it, and I think when AWS
declares a region, it's at leastthree data centers typically.
Tim McConnaughy (09:57):
I think so.
Chris Miles (09:59):
But US East 1, for example, goes up to six, so it
obviously has a higher level ofredundancy.
But, like we said, that's justby default and you get to pick
and choose how much you want toactually utilize that, and the
other cloud providers do theexact same thing.
Right, everything is all.
These AZs, or specific datacenters, are tied to that
specific region as a whole.
Tim McConnaughy (10:20):
That's right, that's right.
Although, as we talk about eachprovider, you'll see how they
chose to.
Even though they all have thatidea of like, hey, here's an AZ
and here's a region, they choseto use that differently when it
came time to like to doing theinfrastructure for it.
So, in this case of AWS, let'sjust start there, right.
(10:41):
Aws ties.
Each subnet is tied to anavailability zone.
So when you and that's anexplicit choice that you make
when you create a subnet, soyeah, so maybe just to take a
quick step back is like when youdefine this logical container,
this network container per cloudprovider.
Chris Miles (11:00):
Doesn't matter what it is.
You basically assign a C ciderrange.
Yeah, that's right.
Moving to cloud was theweirdest thing.
We started saying cider insteadof subnet I don't know why this
happened, but like cider, wasthe the way to describe a a
network?
Um, but you basically assign acider range, which is a super
net that's assigned to theentire vpc or the, the entire
(11:23):
virtual networking construct,and then you kind of chop that
up into separate subnets, right?
And like Tim is saying, everytime you chop that up and you
put a subnet into a VPC, youhave to define what data center
does this belong to or whatavailability zone does this
belong to.
In AWS specifically In AWS.
Yes, that's a good point.
Tim McConnaughy (11:42):
I forgot to mention the CIDR piece.
So yeah, that's a good, good,good point.
I forgot to mention the thecider piece.
So yeah, so it's a subnet, isjust like a subnet.
That hasn't changed, right?
What's changed with the cloudpiece is that again we're
starting with a supernet andthat supernet exists within the
cider, or sorry, within the vpc,but not outside of the vpcs.
That's the whole constructpiece, right, and and we're
gonna not talk a lot about howeach, each VPC can actually have
(12:04):
the same CIDR, which causes allsorts of network design
problems down the road.
Chris Miles (12:10):
But anyway, long story short, don't do that.
Yeah, try not to do that.
Tim McConnaughy (12:16):
But that was a design choice that I think all
of them made, really, except forGoogle, ultimately, you know,
was that they were thinking tobegin with that you know an
entire enterprise would onlyever need one.
So they were like, oh well,just give yourself a slash 16
network and just go to town.
But what ended up happening, ofcourse, is that there were
administrative or security orother you know logical reasons
(12:40):
to break this up, at least inAWS.
The way AWS designed theirconstructs made it easier to do
design by breaking it up, andwhat ended up happening is that,
you know, then you get intoweird things like that, but
let's get back to it.
So subnets are assigned to AZs,and that's explicit choice that
you make in AWS.
But you want to tell us howthey did that differently in
(13:03):
Azure.
So Microsoft chose to do this alittle bit differently.
Chris Miles (13:09):
Yeah, so Azure still has the same concept,
right, all the regional datacenters are divided into
specific availability zones butby default, any subnet that you
define within Azure spans all ofthose data centers.
It spans across all of theavailable AZs, right, so you
(13:30):
like.
Whereas, if you think aboutlogically, where you put
resources in that virtualcontainer, right, and AWS, when
you put you know virtualmachines, essentially the
infrastructure that's running inthere, a virtual machine is
always going to be tied to an AZ.
That means it's always going tobelong to a subnet that is tied
to that same AZ and everythingis kind of locked in this kind
of vertical pattern, right,whereas Azure is horizontal.
(13:56):
Right, you could have virtualmachines deployed in separate
subnets but they're all withinthe same availability zone and
we won't get too far into it.
But, like this, this kind of ledto them also developing
something called availabilitysets where you'd like.
Because you have this nature ofbeing able to span across
multiple az's, you have todefine you know where in those
(14:18):
um.
What.
What logically, between thoseum virtual machines is is kind
of fate shared, I guess, is theword I'll use there.
Tim McConnaughy (14:26):
That's right.
Chris Miles (14:28):
So you have to, you know, kind of go to extra
lengths to make sure that you'remaking sure that those things
are consistently available, youknow with maintenance and things
like that.
But that is a fundamentaldifferentiator between AWS and
Azure, and if you're from oneperson moving to the other, it
(14:48):
kind of changes the way that youhave to think about it, right?
Tim McConnaughy (14:52):
Yeah, and especially how you have to think
about how you deploy yourinfrastructure, right?
So in AWS, because you're veryexplicit about this subnet is
going to be assigned to thisavailability zone, think about
from a resiliency designstandpoint, like what that means
.
Right, so you're going todeploy an ace, essentially like
an A side and a B side, like wewould like a red green, like we
(15:12):
would think a red blue weather,like we would think in in.
That makes it very logical.
So what I find is that mostnetwork engineers find that AWS
is very logical to them.
Like just coming straight fromnetwork engineering to AWS, it
seems very logical because ofthings like that.
Right, as network engineers, wethink in resilience a very
(15:33):
large amount and the idea ofexplicit resilience is very,
very normal for us as engineersto be thinking about right,
about right Versus, whereMicrosoft, like Chris said,
microsoft took this idea thatlike, hey, it doesn't matter
where you deploy it because wehave it everywhere and if there
is a failure in any of theseavailability zones, we're going
(15:55):
to move your virtual machinesfor you to another availability
zone, right?
Chris Miles (16:00):
Yeah, aws like AWS fundamentally is.
A lot of people compare it toLegos.
Right, it's always, we alwaysgive you the building blocks and
you can do whatever you wantwith those.
Like, we give you thatflexibility, whereas Azure does
kind of be like oh well, yeah,you can explicitly put stuff in
certain configurations that willalign to what exactly you want,
(16:22):
but let us handle a lot of thatstuff, right?
So it's um, and then there'sdefault behaviors that
drastically change things, soyou gotta be very aware of those
.
Tim McConnaughy (16:33):
Yeah, absolutely.
And then uh, so let's talkabout Google cloud as well,
because Google cloud completelythrows the book out in terms of
how anybody designed this Right.
So, with Google Cloud, theiridea was let's create one global
VPC for customers and thatglobal VPC and it's not that you
can only have one VPC, but whenI say global VPC, what I'm
(16:56):
talking about is a truegeographically global construct.
Like remember I said the otherall the other providers do
region locking for a VPC, vc,vnet, whatever Google Cloud
chose to make their constructglobal.
And then, when you assignsubnets, your subnets are
(17:17):
actually associated withdifferent regions, like global
regions of the world, basically.
Chris Miles (17:26):
Yeah, so they took the idea kind of the same way
Azure does, where the subnet canbe, you know, span across
multiple AZs within the region.
But whenever you cross regions,those things were always in
different virtual networks froman Azure perspective, whereas
Google is like no, everything'sin the same VPC.
So it's like it can kind ofobviously dictate how you need
(17:48):
to facilitate routing andfirewalling and things like that
between between these things.
So yeah, it's just another,another thing to be considerate
of.
It's like it's like thisexpanding bubble of how what the
VPC can contain across thethree major providers.
Tim McConnaughy (18:04):
Yeah, and and again, what you know, what you
should be doing as you listen tothis if you, if you knew it.
Cool If you didn't know.
Cool, as you're hearing, though, about different ways that the
cloud providers are providingthe same service.
Basically, because I mean, atthe end of the day, a VPC is a
VPC is a VPC.
You know VNet whatever it's alogical, and you know VNet
(18:25):
whatever it's a logical and youknow construct for you to put
your resources inside right.
So, but think about, from adesign perspective, or just even
an implementation perspective,like what does that look like
when you're deploying resourcesinto a Google global VPC and
have to deal with, like latencyconcerns, right?
So you're probably not going toput in a red blue deployment
(18:48):
where they're in, necessarily,like you know different subnets
or different subnets that areone in Tokyo and one in London
or something like that.
You know that wouldn't make anysense, assuming that these two
ever had to talk to each otheror that they were serving the
same customers, or whatever youknow.
But also think about thecomplexity, the lack of a
complexity, probably from arouting perspective of being
(19:10):
able to have everything justkind of connected in the same
VPC but at the same time, theincredible complexity that
that's going to add if you wantto do any kind of segmentation
or inspection between theseworkloads, right, and then it's
actually flipping the script togo the opposite way.
To talk about like AWS versus,you know, azure versus Google
(19:31):
Cloud, where you have theopposite problem, where now you
have routing concerns, movingbetween VPCs, you know, and
actually the inspection doesn'tget particularly easier in that
case as well, it just becomespart of the routing.
Actually is what ends uphappening.
Chris Miles (19:46):
Yeah for sure, yeah , I think another point that's
kind of continuing on this kindof differentiating philosophies
between the cloud provider,these three major cloud
providers as well, is theconcept of the VPC, or the
virtual network router, and howthat participates in the
conversation between theinfrastructure that resides
(20:08):
within the logical container,between the infrastructure that
resides within the logicalcontainer.
So you know, like within AWS,there's a concept of a VPC
router.
You don't actually see aconstruct called VPC router.
You don't actually, you know,configure something called VPC
router.
The way you do that is bydefining route tables and
assigning them to subnetsessentially, right.
But you know, if you've everworked on a router, you know
(20:30):
what a route table is.
Right, it's a.
It's a very, you know,definitive list of destination
prefixes.
Next hops, et cetera, right.
So in this scenario, the nexthop is typically, you know, it
could be something outside theVPC, it could be something
within the VPC, it could be anendpoint, like if there's a
service that's deployed withinthat VPC that you need access to
(20:51):
, et cetera.
But one thing that is alsofundamentally different is, you
know, azure and Google have thesame construct.
Right, there is a router thatexists within that VPC.
It's a virtual construct andthe way you control, that is,
defining those route tables.
One thing that is unique thatI'll call out specifically with
AWS compared to the other majortwo is when that virtual router
(21:13):
is involved in the conversation.
So if we think, like me,logically as a network engineer
my entire life, I'm like oh,these two things are on the same
subnet, they're going to talkdirectly to each other.
There's no, nothing needs tosit in between.
That conversation that is true.
In AWS you can have direct peerto peer communication.
That conversation that is true.
(21:34):
In AWS you can have directpeer-to-peer communication.
It's like over a virtualizedlayer.
Two thing we won't get intoexactly on that there's no layer
two in cloud, yeah, like wedidn't even touch on that.
But in Azure and GCP that isnot the case.
The virtual router actuallybehaves or is involved in every
single conversation, and if youthink about that, then that can
obviously cause issues when youdidn't expect there to be issues
(21:54):
, right?
If you just assume things areon the same subnet, they should
have, you know, full east-westcapability to talk to each other
.
That's not always the case,right?
So there's that concept thatcomes into play as well.
Tim McConnaughy (22:06):
Yeah, for sure.
I mean, and for completeness,just we'll speak briefly about
OCI, because the truth is, a lotof what OCI does is very
similar to the way, I don't know, it's kind of like from a
routing perspective it feels alittle bit more like AWS.
It is slightly different.
The big one, the big differenceto point out with OCI and we're
not neither of us are OCIexperts, by the way, just FYI.
Chris Miles (22:28):
Yeah, I was going to say the reason we didn't
really include OCI on thiswasn't a dist OCI, it's just the
one we know the least.
Tim McConnaughy (22:34):
Yeah but I mean , I did some research on this
because I didn't want.
I wanted to include OCI,because OCI is becoming a major
player now that you know,especially with like the AI
workload stuff that they'redoing or not.
The big difference with OCI isthat their concept of a VCN is
really tied to these thingscalled compartments, which
(22:55):
doesn't really existmeaningfully in the other clouds
, which is the idea of not justtenancy but like secure, like
administrative policy.
So it's very, very tied intothis idea of you know, if you
want to connect two of anything,if you want to connect anything
together, there's like a wholecompartmentalized policy that
sits on top of of all of that.
So I'm not going to get intothat.
We're we'll, we could do a wholeshow, probably on OCI when we,
(23:18):
when we become better at it, orwe'll actually probably what
we'll do is reach out to some ofour friends at OCI and actually
have that, have thatconversation.
We, we know several, so, um,but yeah, but again, as chris
said, not to diss you know oci,which it's the one that both of
us know the least because weboth had the list, I think.
I think I had one customer whenyou know that I that had oci
(23:39):
and I had to learn enough aboutthe, uh, just to be dangerous
max yeah so.
But I think that will change,especially as, as oci is coming
up in the world now, they'regetting definitely a lot more
adoption.
So all right, let's get so let.
So let's talk a little bit nowabout the, a little bit about
the philosophy, how thephilosophy means the behavior is
different, right?
(23:59):
So what that means is like allright.
So, for example, going back toAWS, with manual AZ design,
which we're talking about, likeeverything is very explicit in
AWS.
What that ends up meaning isthat you as a network you know,
cloud network engineer, whateverthe title is that, when you're
building cloud networks, itmeans you have to be very, very
(24:20):
specific.
You have to be very granularbut also very predictive with it
, which is honestly what, like Isaid, network engineers really
like that.
Because, you know, somebodytold me this years ago ago and I
still think it's pretty goodtoday.
You know, a network is like adog, right?
You want to train your dog.
You don't want to let your dogrun around rampant just doing
(24:41):
whatever it wants.
You want the dog to do thetricks when you tell it.
So that's very normal for us,right?
But, like with Azure, again,like Chris was saying, it's very
much a let us handle thecomplex parts right.
You build it and we'll handleall of the resiliency for you.
Less control it's easier HA,but you get less control over it
(25:03):
.
Now in Azure you actually canforce objects to be deployed in
certain AZs, but they actuallyrecommend you don't do that
because it breaks their HAautomation.
Basically, then it's stuck tothat AZ and if that AZ goes down
it won't move.
So again, different designphilosophy.
(25:25):
Aws is like that's how it isand that's why you should design
around it.
And Microsoft is like you don'tneed to design around it, we'll
handle it.
It doesn't end up being thecase, I don't know.
And then Google is just likeglobal networking Just put
everything in the same networkand we will do all of the work
for you.
I think we've said many timesthat we feel like Google Cloud
(25:47):
networking is much moredeveloper focused and friendly,
because you don't really wantyou to necessarily care about it
.
Chris Miles (25:54):
Honestly, Unfortunately, but yeah.
Tim McConnaughy (25:57):
Oh, anyway, all right.
So let's, let's, let's wrap upsome with some gotchas that you
can run into, like you know,into in just with VPCs, even
something as simple as just VPCdesign the philosophies of the
different cloud providers.
If you don't what's the wordI'm looking for?
If you don't kind of conform tothe philosophy that they're
(26:18):
using when they designed likehow they want you to design your
cloud, basically If you rageagainst that and try to do it a
lot of times, it'll work, but itends up being a lot more
brittle.
It'll work, but it ends up beinga lot more brittle.
Like you know, when you'reusing third-party devices and
you kind of use third-partydevices to overcome some of the
design choices, sometimes youhave to do that right, like if
(26:39):
you can only have 500 routes inthe route table and that's what
they give you, but you need,like 10,000, you have to do a
third-party, something that cansupport it, but you should still
design your third partyimplementation with the design
philosophy of that cloud in mind.
Does that make sense?
Hopefully that made sense.
Chris Miles (26:57):
No, yeah, I see what you mean, yeah.
Tim McConnaughy (26:59):
All right, so okay, so like.
So AWS, the big one is becauseyou are very explicit about, and
they expect you to be veryexplicit from a, from a DR
perspective and also from an HAresiliency perspective.
They want you pinning resourcesto different availability zones
, run kind of like an AB or ared blue they.
(27:19):
That leaves you as the networkdesigner to deal with traffic
that will cross availabilityzones.
So what that means is that,like you know, sometimes that's
a design philosophy, Like youjust need to be able to do that
for resiliency purposes.
Sometimes you're supposed tolike build, basically like
application rails, if you will,where, like, you've got your X
number of tiers of applicationand the A tier or the A side
(27:43):
should never talk to the B sideand vice versa.
You know, but depending on yourapplication, depending on your
use case, maybe that's notfeasible, right, and then let's
not talk about and then, youknow, think about down the road,
we might talk about firewallsand stuff where that's you know
that could be part of yourresiliency strategy.
You know if you have an actualfirewall and that virtual
(28:03):
machine dies, like what's goingto happen to the traffic on that
rail?
Is that rail going to just diewith it or is that you know what
happens?
Do we cross availability zones?
So the reason I bring this upis because cross AZ traffic and
cross region traffic and justbasically just transfer, that
leaves the data centeressentially with aws.
Is money like you charge, theycharge you, and now it's an
(28:25):
infinitesimally small amount ofmoney, but it adds up very.
Chris Miles (28:29):
It can add up very if you're doing, if you're doing
, you know, synchronousreplication between things,
between two data centers thatcan.
That can eat up a lot of moneyvery quick, right yeah, and it
has right so let's like, in thatsame vein of of which I
mentioned, you know, like it'sjust a click of a button to make
something you know kind ofmulti availability zone, multi
(28:49):
data center or multi region.
Um, that all comes at a cost.
Right, they build, they giveyou these.
You know building blocks, butthe building blocks are kind of
no holds barred, you can buildwhatever you want.
So you can kind of build yourown noose if you're not careful.
Right, so it's it's, you've,you've got to be very aware of
(29:09):
that in the in, in, in the grandscheme of things because I've,
I've said this many times isthat the newest inch, the thing
that cloud networking brought tothe table, was this concept of
a toll booth.
Right, it's like no matter whereyou're transferring data in and
out of their data centers,you're paying the toll booth.
You know whether it be onecents per gigabyte or two cents
per gigabyte, what have you?
(29:30):
It doesn't sound like much, butyou haven't been paying that in
your, in your physical datacenter for the longest time,
right, you've, you've, you'vepaid for a pipe and you, you can
either use all the pipe or usenone of the pipe, right?
Whereas now it's like, hey, webuilt these pipes and as you put
oil through them, we're goingto charge you for every gallon,
right?
So it's a different way tothink about it.
Yep, absolutely.
Tim McConnaughy (29:50):
So that's I mean and every.
To be clear, like every cloudprovider has some version of
this, but you definitely keenlyfeel it, not feel it?
What's the word I'm looking for?
You have to really think aboutit.
In AWS versus like Azure, whereyou know you don't even deploy
in a specific availability zoneand all of that, right, you're
(30:11):
generally just deploying gearand trusting Microsoft to take
care of it, but you're usingavailability sets to say, okay,
azure, you know, this is my Arail, this is my B rail.
They exist in the same az.
Maybe maybe they're in the samedamn data center, maybe they're
the same rack, we don't knowright, but when you azure, do,
uh, maintenance, consider thatthese two devices need to not be
(30:32):
down at the same time and theazure automation will do that
right.
So that's, you're handing thekeys.
So the trade-off there is thatyou're handing the keys over to
Azure, to automation.
There's no person making thisdecision, right?
Azure automation is deciding oh, I need to reboot this rack.
Or maybe Azure's not decidingit at all.
Maybe Godzilla steps on thedata center and that AZ goes
(30:55):
down and now Microsoft is goingto automatically move those
workloads to another data center.
Move those workloads to anotherdata center.
But you know, when you designedthe applications or maybe you
maybe well, you didn't designthem because you're a network
engineer in this case, but theapplication may not be able to
handle the latency that justhappened from having to move to
a second data center and connectto other stuff, you know.
(31:17):
So it gives you lessgranularity, a little bit more.
You know easy resiliency, butit also means that you it's the
classic Faustian bargain, rightLike you hand over the keys and
you trust that, well, if it'snot in my control then you know,
hopefully they can take care ofit.
Yeah, and just to be clear.
Chris Miles (31:38):
Aws has this.
They have kind of services andconstructs that are available to
let you fail over in the samescenario, but it's just not as
implicit right you have to buildit.
Tim McConnaughy (31:49):
That's it.
Chris Miles (31:50):
So that's really the only minute difference.
I just want to make sure itdoesn't sound like we're saying
AWS is less resilient oranything.
Obviously, like you said, theyhad first mover advantage and
they chose a path and it was tolet the customer build anything
and absolutely everything,whereas Azure kind of came back
with a different approach.
But I will say there's alsothings that we see in terms of
(32:13):
just the way the cloud providersare moving.
It seems like and this is muchmore widespread than just the
networking piece but there arecertainly differentiators that
make the cloud providers lookmore appealing to certain you
know customers, or you knowtypes of customers, verticals,
et cetera, things.
(32:44):
Because I think they'll see,like, you know, if you're a
major cloud provider B and yousee cloud provider A start
charging for a certain thing andyou know people gripe about it,
but they end up, you know,making record margins, that's
right.
Eventually cloud provider B isgoing to start charging for that
as well, right.
So it's like, just becausethings are free today or
different today, that candrastically change.
Like just back to the conceptof you know paying for cross AZ
(33:04):
traffic or cross region traffic.
I think you know you can buildthis concept of a peering
between these logical containers.
So you can have a VNet peeringor a VPC peering, whereas keep
me honest here, but I thinkacross VPC peering as long as
you stay within the AZ, youdon't pay for that.
Tim McConnaughy (33:27):
Whereas Azure if you use a VNet peering.
Chris Miles (33:28):
They actually do charge for that, like on top of
it.
So it's like everything isthere's nuance to everything.
Tim McConnaughy (33:30):
Yeah, I mean, there's a lot more nuance than
we could possibly get into in apodcast episode, but this is the
point that we're making rightDesign philosophies, right.
So AWS does exactly that.
So VPC peering counts as datatransfer only if the money, or
sorry, the data, crosses AZs.
Which is to say like, again,take two different VPCs, put two
(33:53):
different workloads in thoseVPCs and maybe they need to talk
.
Well, if the workload in VPC Ais deployed in subnet A, which
is an AZA, and then VPC A isdeployed in subnet A, which is
in AZA, and then VPC B is in Bis in subnet B, those are two
different data centers and sowhen those two workloads talk,
even though it's entirely acrossthe database's backbone, it's
still using their pipes andmoving between crossing AZs.
(34:16):
But whereas if everything wasin A, then that VPC peering
would be completely free,because it's actually not even
leaving the same data center.
It's in the same data center ordiscrete group of data centers
as they, as they call it Right.
Chris Miles (34:29):
So yeah, that's hopping across the hypervisor
Exactly.
Tim McConnaughy (34:33):
So which and this is this is the point, Right
.
And then you have, you know,you have Google, where it's all
global, it's all the same, it'slogically all in the same VPC,
right?
So from your perspective it'sall the same, but obviously you
know they're.
They're different betweensubnets really means between
either geographical locations orat least data centers, so, or
(34:53):
something like that.
So, yeah, why don't we wrap upreal quick with some, some just
misconceptions about what otherpeople you know, what we really
get wrong, what we really, uh,assume based on the names and
and and kind of how we expect itto work, and then we'll, we'll
wrap it up.
You want to take this one.
Chris Miles (35:10):
Yeah, sure, Um.
So a couple of ones that wehear a lot.
Um, as far as misconceptions go, is like we, uh, you know
people talk about you know kindof within VPC is like oh, VPC.
Or you know people talk aboutyou know kind of within vpc is
like oh, vpc.
Or you know, subnet with it'sit's kind of just like a vlan.
Um, but kind of going back tothat piece that I talked about
before with the, the vpc or thevirtual network router, um, that
(35:33):
can very much not be the case.
Um, I would say that it don't.
Let's not talk about vls man Incloud, it's all layer three.
There's a couple scenarioswhere you need to identify VLANs
, but that's only when you'rebuilding physical connectivity
into a data center and you needto define the VLAN.
But other than that, let's nottalk about VLANs.
(35:53):
Everything is segmented eitherat a virtual layer, where you
don't need a VLAN, or it's alllayer three segmentation, right?
So every provider, the conceptof it being just like a VLAN,
every provider breaks that in adifferent way.
Um, so this like, if we want to, you know, get down into the
nuts and bolts, that's, that'snot really true.
Um, also, this idea of like, ohwell, I can, I can put this in.
(36:17):
You know, if I want to changeit later, that'll be super easy,
and that's, and that's,relatively true most of the time
.
However, there are certainthings that become immutable per
provider, right?
So there's things that once youput them in, you cannot change
them without completely deletingthe construct.
Right Now, we won't sit hereand kind of list out each one of
(36:37):
those things individually,because we could be here all day
.
But you know, there's, there'sthe cloud makes things easier,
but, like, there's alsodependencies built on their back
ends where they can't just, youknow, swap things out, right,
you have to be aware of whenthat comes into play.
So that's something you shouldalso be very considerate of.
Any additional ones you canthink of Tim.
Tim McConnaughy (36:59):
Well, I mean just speaking about the VPCs
themselves.
Right, Like, a VPC is immutablein that once you create it and
you assign a CIDR to it, you canadd new CIDRs, but you can't
like change the CIDR that wasassigned, you're done.
That's every you know.
And if you want to change theCIDR of a VPC and not just add a
second one but fundamentallychange it, you have to destroy
(37:22):
every resource that is in thatVPC and then delete the VPC and
then you can recreate it with anew site.
And if you think about it, ifyou've deployed a whole
application stack in that VPCthat's not a small change, right
If you've designed it right,then hopefully maybe there's
another VPC or you just stand upanother VPC, you know, and
(37:42):
replicate the application.
That's really more.
What we're talking about is,truthfully, you're going to in
cloud.
You're not going to, you know,have this downtime where you're
going to destroy something andthen rebuild it, right, you're
just going to build another one.
Remember, I said you got VPCswhere you can have the same
ciders and all this other stuff,but you're going to build
another one and then you'regoing to tear that one down,
right, and you're going to moveall your workloads and
(38:03):
everything over.
But the point is, I know thatcloud is agile, but it's not
immutable or it is veryimmutable.
There are things, especiallywith VPCs, that basic construct
is an immutable construct.
Chris Miles (38:16):
Maybe if you're a very important customer and you
call support, there's probablysome strings they can pull, but
you don't want that to be partof your regular workflow.
That would just be, I don'tknow how.
If you guys like spending timeon the phone, I don't, so I
wouldn't.
I wouldn't make that a makethat a habit.
Tim McConnaughy (38:31):
So if you guys, uh, we'll go ahead and wrap up.
If you guys I'm sorry if youguys, if, if our listeners, um,
enjoyed this, uh, you know thistype of format, or if it you
know we hit too high, we hit toolow, we didn't hit the right
things, I would love, we wouldlove some, some feedback,
(38:51):
because we like the idea of kindof going into some of this,
especially like how it'sdifferent between providers and
also how you, as a networkdesigner, are going to have to
think about the fact that it'sdifferent and what you're going
to build with it and what itlets you do or doesn't let you
do.
If we're hitting the rightnotes, let us know and we'll do
(39:11):
more like this.
Chris Miles (39:14):
Yeah, we know we have listeners that everyone's
at a different stage in theircareer.
Some people are absolutebeginners, some people are very
seasoned vets, and then the samescenario applies to cloud.
Right, some people are justgetting started with cloud.
Some people have, like, onlybeen doing cloud for the last
you know five, 10 years orsomething like that, right?
So it's like we want to kind ofgo over some of the base layer
(39:36):
concepts and maybe we'll turnthis into a series or something
like that and we'll talk aboutyou know kind of.
You know we touched on the mostbasic thing here, which is VPC,
but we can start talking about,you know, inter-vpc or
inter-VNet networking.
You know services like TransitGateway, cloud WAN, virtual WAN,
et cetera.
So I think we'll probablyexpand into some of that and
(39:56):
talk about some of the securityconcepts and draw you know
analogs to traditionalnetworking there and talk about
network segmentation et cetera.
So that's where we're headed,or where we're thinking we're
going to head.
So we would love some feedback.
So please reach out, email,twitter, x, blue Sky, linkedin,
whatever.
Just send us a PM, let us know.
(40:16):
Yeah, appreciate it, okay.
Tim McConnaughy (40:19):
Let's go ahead and wrap up.
Speaking of.
Chris already gave all the listof places.
We want you to follow us.
Chris Miles (40:25):
On YouTube as well.
On YouTube, of course, you cancomment on.
Tim McConnaughy (40:28):
YouTube if you want.
Yeah, please, please feel free.
It'd be nice.
You usually just get the spamones.
Chris Miles (40:36):
No Nigerian princes , please.
Tim McConnaughy (40:38):
Yeah, yeah, all right, we'll wrap it here and
we will see you guys in the nextepisode.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.