1
00:00:00,640 --> 00:00:05,370
Let's look at a hybrid cloud network topology that I created using Lucidchart.

2
00:00:05,370 --> 00:00:08,520
We don't have to get into every moving piece on this picture,

3
00:00:08,520 --> 00:00:11,340
I just want to show you some high‑level trends.

4
00:00:11,340 --> 00:00:14,070
Here we have a site‑to‑site virtual private network.

5
00:00:14,070 --> 00:00:18,540
This is an IPsec IKEv2 tunnel going over the public internet.

6
00:00:18,540 --> 00:00:22,330
That provides a secure tunnel connection between the edge of your

7
00:00:22,330 --> 00:00:26,730
on‑premises environment and a hub Azure virtual network,

8
00:00:26,730 --> 00:00:27,640
you see?

9
00:00:27,640 --> 00:00:29,590
Though, this site‑to‑site VPN,

10
00:00:29,590 --> 00:00:33,850
or an alternative that doesn't use the internet would be ExpressRoute,

11
00:00:33,850 --> 00:00:37,490
provide a way for you to extend your OSI Layer 3,

12
00:00:37,490 --> 00:00:39,890
your on‑premises environment into Azure,

13
00:00:39,890 --> 00:00:43,420
and that way you can use local administration tools

14
00:00:43,420 --> 00:00:50,340
to govern your Azure‑based VMs, you can use Azure tools to govern your local VMs,

15
00:00:50,340 --> 00:00:54,640
or you could truly use them both in a truly hybrid scenario.

16
00:00:54,640 --> 00:00:55,510
You might wonder,

17
00:00:55,510 --> 00:00:58,700
what do I have to set up with regard to routing within

18
00:00:58,700 --> 00:01:00,530
a single virtual network in Azure?

19
00:01:00,530 --> 00:01:03,610
And the answer is, at least initially, nothing.

20
00:01:03,610 --> 00:01:07,190
I'll describe the Azure wire server in a little while,

21
00:01:07,190 --> 00:01:12,470
but just suffice it to say that although we have separate subnets here that have

22
00:01:12,470 --> 00:01:16,360
different IP ranges within the same overall address range,

23
00:01:16,360 --> 00:01:18,140
we don't have to worry about routing.

24
00:01:18,140 --> 00:01:21,500
Azure system routes take care of that traffic.

25
00:01:21,500 --> 00:01:26,440
Same thing with name resolution, at least single label name resolution.

26
00:01:26,440 --> 00:01:30,840
A common way to join virtual networks is to create peerings.

27
00:01:30,840 --> 00:01:36,630
This opens up a routing path between two VNets that stays on the Azure backbone,

28
00:01:36,630 --> 00:01:39,540
so you're not going out onto the internet.

29
00:01:39,540 --> 00:01:44,080
And you should know that you can use peering to connect any two VNets.

30
00:01:44,080 --> 00:01:46,270
They don't have to be in the same region,

31
00:01:46,270 --> 00:01:48,190
they don't have to be in the same subscription,

32
00:01:48,190 --> 00:01:50,810
they don't even have to be in the same Azure AD tenant,

33
00:01:50,810 --> 00:01:51,450
believe it or not.

34
00:01:51,450 --> 00:01:52,940
It's pretty convenient.

35
00:01:52,940 --> 00:01:55,580
And this peering, this hub‑spoke architecture,

36
00:01:55,580 --> 00:02:01,020
as it's called, opens up all sorts of useful conveniences like service chaining.

37
00:02:01,020 --> 00:02:04,090
For example, you could deploy an AzureBastionSubnet,

38
00:02:04,090 --> 00:02:07,550
which is a managed jump host in your hub VNet,

39
00:02:07,550 --> 00:02:18,000
and you can go through that bastion to make a secure connection to, say, our system s1 in the s1 spoke VNet by transiting over that peering.