1 00:00:00,000 --> 00:00:01,460 What is an Azure Virtual Network? 2 00:00:01,460 --> 00:00:04,260 Most people hear that term and think it's just another setting you flip on 3 00:00:04,260 --> 00:00:06,200 when you're deploying a virtual machine, 4 00:00:06,200 --> 00:00:09,060 something you check a box for and then forget about. 5 00:00:09,060 --> 00:00:10,020 But here's the truth, 6 00:00:10,020 --> 00:00:12,420 an Azure Virtual Network isn't just a setting. 7 00:00:12,420 --> 00:00:15,020 It's the foundation of everything you build in Azure. 8 00:00:15,020 --> 00:00:16,120 Every virtual machine, 9 00:00:16,120 --> 00:00:16,860 every database, 10 00:00:16,860 --> 00:00:17,620 every app service, 11 00:00:17,620 --> 00:00:18,900 every function you deploy, 12 00:00:18,900 --> 00:00:20,260 they all sit inside one. 13 00:00:20,260 --> 00:00:22,140 And if you don't understand how they work, 14 00:00:22,140 --> 00:00:23,380 you're flying blind. 15 00:00:23,380 --> 00:00:24,380 By the end of this episode, 16 00:00:24,380 --> 00:00:26,540 you'll understand what a VNet actually is, 17 00:00:26,540 --> 00:00:27,420 how it works, 18 00:00:27,420 --> 00:00:29,980 and why every single resource you deploy depends on it. 19 00:00:29,980 --> 00:00:31,100 We'll cover what a VNet is, 20 00:00:31,100 --> 00:00:32,140 how IP addresses work, 21 00:00:32,140 --> 00:00:33,140 subnet security, 22 00:00:33,140 --> 00:00:33,660 routing, 23 00:00:33,660 --> 00:00:35,180 and how to connect VNet together, 24 00:00:35,180 --> 00:00:37,260 grab your coffee and let's dive in. 25 00:00:37,260 --> 00:00:38,140 What is a VNet? 26 00:00:38,140 --> 00:00:39,540 The private cloud network. 27 00:00:39,540 --> 00:00:41,500 Let's start with the simplest definition. 28 00:00:41,500 --> 00:00:43,100 An Azure Virtual Network, 29 00:00:43,100 --> 00:00:44,420 or VNet for short, 30 00:00:44,420 --> 00:00:46,940 is your own private network inside Azure. 31 00:00:46,940 --> 00:00:48,820 Think of it like a private office building. 32 00:00:48,820 --> 00:00:50,180 Only people you allow can get in, 33 00:00:50,180 --> 00:00:52,020 you control who comes through the door, 34 00:00:52,020 --> 00:00:54,820 who gets to which floor and who's locked out entirely. 35 00:00:54,820 --> 00:00:56,020 Before VNet's existed, 36 00:00:56,020 --> 00:00:57,020 things were different. 37 00:00:57,020 --> 00:00:58,700 You deploy a virtual machine in the cloud, 38 00:00:58,700 --> 00:01:01,420 and it was basically exposed to the internet by default. 39 00:01:01,420 --> 00:01:02,940 No private network around it. 40 00:01:02,940 --> 00:01:05,020 Anyone who knew the IP address could try to connect. 41 00:01:05,020 --> 00:01:07,260 But that was a security nightmare, what changed? 42 00:01:07,260 --> 00:01:08,820 Azure gave you the ability to create 43 00:01:08,820 --> 00:01:10,700 isolated private network spaces. 44 00:01:10,700 --> 00:01:11,860 You define a boundary. 45 00:01:11,860 --> 00:01:13,180 You decide what goes inside it. 46 00:01:13,180 --> 00:01:14,820 Nothing outside that boundary can get in 47 00:01:14,820 --> 00:01:16,580 unless you explicitly allow it. 48 00:01:16,580 --> 00:01:17,700 One thing to know upfront, 49 00:01:17,700 --> 00:01:19,980 your VNet lives in a specific Azure region. 50 00:01:19,980 --> 00:01:20,820 It's not global. 51 00:01:20,820 --> 00:01:22,260 Create a VNet in West Europe, 52 00:01:22,260 --> 00:01:23,540 and that's where it stays. 53 00:01:23,540 --> 00:01:25,780 Resources in a different region can't just hop into it. 54 00:01:25,780 --> 00:01:27,300 They'd need their own VNet, 55 00:01:27,300 --> 00:01:28,740 or you'd need to connect them later. 56 00:01:28,740 --> 00:01:29,780 When you create a VNet, 57 00:01:29,780 --> 00:01:31,820 you define the IP address space yourself. 58 00:01:31,820 --> 00:01:33,060 Azure doesn't pick it for you. 59 00:01:33,060 --> 00:01:35,980 You decide the range of IP addresses your resources will use. 60 00:01:35,980 --> 00:01:37,140 That's a big responsibility, 61 00:01:37,140 --> 00:01:39,500 and we'll talk about how to get it right in the next section. 62 00:01:39,500 --> 00:01:40,660 Here's the key point. 63 00:01:40,660 --> 00:01:42,340 VNet's are the foundation. 64 00:01:42,340 --> 00:01:45,860 Every virtual machine, every database, every app service, 65 00:01:45,860 --> 00:01:48,620 every Azure function you deploy sits inside one. 66 00:01:48,620 --> 00:01:51,620 Without a VNet, your resources have no private network context. 67 00:01:51,620 --> 00:01:53,740 They're just floating in the cloud with no boundaries, 68 00:01:53,740 --> 00:01:55,580 no isolation, no security. 69 00:01:55,580 --> 00:01:56,780 So what does this mean for you? 70 00:01:56,780 --> 00:01:58,180 If you're building anything in Azure, 71 00:01:58,180 --> 00:01:59,940 start with a VNet first, 72 00:01:59,940 --> 00:02:01,660 not after you've deployed your resources. 73 00:02:01,660 --> 00:02:04,260 Before your VNet is the land you're building on, 74 00:02:04,260 --> 00:02:06,460 you wouldn't build a house without buying the land first, right? 75 00:02:06,460 --> 00:02:07,460 Same idea. 76 00:02:07,460 --> 00:02:10,740 IP addressing and CIDR choosing your address space. 77 00:02:10,740 --> 00:02:12,180 So let's dive in. 78 00:02:12,180 --> 00:02:13,180 When you create a VNet, 79 00:02:13,180 --> 00:02:15,500 the first big decision is picking an IP range. 80 00:02:15,500 --> 00:02:17,260 You do that using CIDR notation. 81 00:02:17,260 --> 00:02:20,100 CIDR is short for classless interdomain routing, 82 00:02:20,100 --> 00:02:21,900 but all that really means is you're saying, 83 00:02:21,900 --> 00:02:23,940 "I need this many IP addresses." 84 00:02:23,940 --> 00:02:24,980 Why does this matter? 85 00:02:24,980 --> 00:02:27,180 Because the range you choose determines 86 00:02:27,180 --> 00:02:30,100 how many resources you can fit in your virtual network. 87 00:02:30,100 --> 00:02:30,940 Here's how it works. 88 00:02:30,940 --> 00:02:34,500 CIDR uses a slash and a number like 16 or 24. 89 00:02:34,500 --> 00:02:36,820 That number tells you the size of the address space. 90 00:02:36,820 --> 00:02:40,220 A 16 gives you about 65,000 IP addresses. 91 00:02:40,220 --> 00:02:41,060 That's a lot. 92 00:02:41,060 --> 00:02:43,060 A 24 gives you about 250, 93 00:02:43,060 --> 00:02:46,140 which is perfect for a small team or a single application tier. 94 00:02:46,140 --> 00:02:47,540 So when you're designing your VNet, 95 00:02:47,540 --> 00:02:50,220 you need to think about how many resources you'll have 96 00:02:50,220 --> 00:02:51,460 and how you want to group them. 97 00:02:51,460 --> 00:02:53,620 Now you can't just pick any IP range. 98 00:02:53,620 --> 00:02:56,180 Azure follows the RFC 1918 standard, 99 00:02:56,180 --> 00:02:59,460 which sets aside private IP ranges for internal networks. 100 00:02:59,460 --> 00:03:00,540 You have three options. 101 00:03:00,540 --> 00:03:02,660 The 10.xx-dx range is the largest 102 00:03:02,660 --> 00:03:04,260 given you plenty of room to grow. 103 00:03:04,260 --> 00:03:08,300 The 172.xx-dx range is a bit smaller, but still useful. 104 00:03:08,300 --> 00:03:11,940 And the 192.168x-dx range is the one you probably have 105 00:03:11,940 --> 00:03:13,060 at home on your router. 106 00:03:13,060 --> 00:03:13,820 Here's the thing. 107 00:03:13,820 --> 00:03:15,940 Your VNet's address space cannot overlap 108 00:03:15,940 --> 00:03:17,980 with any other network you plan to connect to. 109 00:03:17,980 --> 00:03:19,100 This is a common mistake. 110 00:03:19,100 --> 00:03:20,940 Many people pick a range that looks familiar, 111 00:03:20,940 --> 00:03:23,860 only to find out later that it conflicts with their corporate network. 112 00:03:23,860 --> 00:03:27,900 So if your company's office network uses 10.0.0 to RFC 1918, 113 00:03:27,900 --> 00:03:29,580 don't use that same range in Azure. 114 00:03:29,580 --> 00:03:31,300 If you try to connect them later, 115 00:03:31,300 --> 00:03:33,740 they'll clash and traffic won't know where to go. 116 00:03:33,740 --> 00:03:35,100 Let me give you a concrete example. 117 00:03:35,100 --> 00:03:37,300 Imagine you're building a hybrid setup 118 00:03:37,300 --> 00:03:40,060 where Azure connects back to your on-premises data center 119 00:03:40,060 --> 00:03:42,620 and your data center uses 10.0, 20.0, 120 00:03:42,620 --> 00:03:44,220 and San Josejo 16. 121 00:03:44,220 --> 00:03:46,060 If you create a VNet with the same range, 122 00:03:46,060 --> 00:03:48,780 you'll have two networks fighting over the same IPs. 123 00:03:48,780 --> 00:03:49,860 Think about it. 124 00:03:49,860 --> 00:03:51,740 Two networks using the same IP range 125 00:03:51,740 --> 00:03:53,140 can't communicate properly. 126 00:03:53,140 --> 00:03:55,180 It's like two houses with the same address. 127 00:03:55,180 --> 00:03:56,300 The mail gets confused. 128 00:03:56,300 --> 00:03:58,580 That's a problem you don't want to solve after the fact, 129 00:03:58,580 --> 00:04:00,580 so plan ahead and pick a unique range. 130 00:04:00,580 --> 00:04:01,740 And here's a planning tip. 131 00:04:01,740 --> 00:04:03,780 Choose a larger range than you think you need. 132 00:04:03,780 --> 00:04:05,700 You might think you'll only need a 24 now, 133 00:04:05,700 --> 00:04:08,900 but as your application grows, you'll wish you had a 16. 134 00:04:08,900 --> 00:04:10,420 You can't easily change it later. 135 00:04:10,420 --> 00:04:13,060 Once your VNet is created and you've deployed resources, 136 00:04:13,060 --> 00:04:14,940 changing the address space is messy. 137 00:04:14,940 --> 00:04:17,220 It's possible, but it's not something you want to do 138 00:04:17,220 --> 00:04:18,260 on a live system. 139 00:04:18,260 --> 00:04:19,620 So give yourself room to grow. 140 00:04:19,620 --> 00:04:20,780 What does this mean for you? 141 00:04:20,780 --> 00:04:23,140 Think of your VNet's address space like buying land. 142 00:04:23,140 --> 00:04:24,580 Get enough for future growth. 143 00:04:24,580 --> 00:04:27,100 If you think you need a small plot by a medium one, 144 00:04:27,100 --> 00:04:28,340 you'll thank yourself later. 145 00:04:28,340 --> 00:04:29,540 That's the key takeaway. 146 00:04:29,540 --> 00:04:32,700 Plan your address space with future growth in mind. 147 00:04:32,700 --> 00:04:33,580 Subnets? 148 00:04:33,580 --> 00:04:34,900 Dividing your network. 149 00:04:34,900 --> 00:04:37,660 So you've got your VNet and you've picked your address space. 150 00:04:37,660 --> 00:04:38,500 Now what? 151 00:04:38,500 --> 00:04:39,940 You don't just dump everything into one big pool. 152 00:04:39,940 --> 00:04:41,020 That's where subnets come in. 153 00:04:41,020 --> 00:04:43,220 Subnets are one of the fundamental building blocks 154 00:04:43,220 --> 00:04:44,260 of your VNet. 155 00:04:44,260 --> 00:04:46,540 They let you organize and secure your resources. 156 00:04:46,540 --> 00:04:49,940 A subnet is a smaller section of your VNet's address space. 157 00:04:49,940 --> 00:04:53,140 If your VNet is the building, subnets are the individual rooms. 158 00:04:53,140 --> 00:04:55,380 You wouldn't put your server room, your reception desk, 159 00:04:55,380 --> 00:04:57,780 and your break room all in the same open space, right? 160 00:04:57,780 --> 00:04:58,540 Same idea here. 161 00:04:58,540 --> 00:05:00,620 It's a simple concept, but it makes a huge difference 162 00:05:00,620 --> 00:05:02,140 in how you manage your network. 163 00:05:02,140 --> 00:05:04,060 Different resources go in different subnets. 164 00:05:04,060 --> 00:05:07,620 Your web servers go in one subnet, your databases in another, 165 00:05:07,620 --> 00:05:09,420 and your application logic in a third. 166 00:05:09,420 --> 00:05:09,940 Why? 167 00:05:09,940 --> 00:05:10,540 Two reasons. 168 00:05:10,540 --> 00:05:11,940 Security and organization. 169 00:05:11,940 --> 00:05:14,340 Let's talk about security first, because that's usually 170 00:05:14,340 --> 00:05:15,220 the most important. 171 00:05:15,220 --> 00:05:16,260 Security first. 172 00:05:16,260 --> 00:05:17,940 If someone breaks into your web server, 173 00:05:17,940 --> 00:05:20,540 you don't want them to have direct access to your database. 174 00:05:20,540 --> 00:05:22,580 Separate subnets create a natural barrier. 175 00:05:22,580 --> 00:05:24,420 The attacker would have to cross that boundary 176 00:05:24,420 --> 00:05:26,380 and you can control exactly what crosses. 177 00:05:26,380 --> 00:05:27,980 You can also use network security groups 178 00:05:27,980 --> 00:05:29,700 to control traffic between subnets. 179 00:05:29,700 --> 00:05:31,260 That's a topic for another video. 180 00:05:31,260 --> 00:05:32,780 But it's worth knowing that subnets 181 00:05:32,780 --> 00:05:34,860 are the foundation for that security. 182 00:05:34,860 --> 00:05:36,020 Organization second. 183 00:05:36,020 --> 00:05:38,780 When everything has its place, managing it is easier. 184 00:05:38,780 --> 00:05:41,580 You know which subnet contains your front end resources 185 00:05:41,580 --> 00:05:43,420 and which one holds your back end data. 186 00:05:43,420 --> 00:05:46,500 You can apply policies and rules to the whole subnet at once 187 00:05:46,500 --> 00:05:48,980 instead of configuring each resource individually. 188 00:05:48,980 --> 00:05:51,060 That saves time and reduces errors. 189 00:05:51,060 --> 00:05:53,340 Now here's a detail that catches people off guard. 190 00:05:53,340 --> 00:05:55,900 Azure reserves five IP addresses in each subnet 191 00:05:55,900 --> 00:05:58,420 for its own internal purposes like routing and DNS. 192 00:05:58,420 --> 00:06:00,700 So if you create a subnet with a 24 range 193 00:06:00,700 --> 00:06:02,500 giving you two and 56 addresses, 194 00:06:02,500 --> 00:06:04,780 you actually only get two and 51 usable ones. 195 00:06:04,780 --> 00:06:05,860 It's a common gotcha. 196 00:06:05,860 --> 00:06:08,140 You plan for two and 56, but you only get two and 51. 197 00:06:08,140 --> 00:06:10,700 So always add a little extra when you size your subnets. 198 00:06:10,700 --> 00:06:13,580 The good news is you can add subnets after creating the vnet. 199 00:06:13,580 --> 00:06:16,500 You're not locked into the ones you set up during creation. 200 00:06:16,500 --> 00:06:18,580 So if you realize you need a separate subnet 201 00:06:18,580 --> 00:06:20,660 for management tools or monitoring systems, 202 00:06:20,660 --> 00:06:22,180 add it later, no problem, 203 00:06:22,180 --> 00:06:24,420 but it's still better to plan them upfront. 204 00:06:24,420 --> 00:06:26,020 Adding subnets later is possible, 205 00:06:26,020 --> 00:06:27,700 but you might need to move resources around 206 00:06:27,700 --> 00:06:29,060 which can be disruptive. 207 00:06:29,060 --> 00:06:30,340 But here's the best practice. 208 00:06:30,340 --> 00:06:32,020 Use separate subnets for different tiers 209 00:06:32,020 --> 00:06:33,340 of your application from the start. 210 00:06:33,340 --> 00:06:34,940 Think about your application architecture. 211 00:06:34,940 --> 00:06:36,940 Typically you have a front end tier 212 00:06:36,940 --> 00:06:39,220 that handles user requests, a back end tier 213 00:06:39,220 --> 00:06:41,820 that processes business logic and a data tier 214 00:06:41,820 --> 00:06:43,020 that stores information. 215 00:06:43,020 --> 00:06:44,540 Each of these should have its own subnet. 216 00:06:44,540 --> 00:06:46,060 Don't wait until you're in production 217 00:06:46,060 --> 00:06:47,740 to realize you need to split things apart. 218 00:06:47,740 --> 00:06:50,260 That's a lot harder when resources are already deployed. 219 00:06:50,260 --> 00:06:51,180 What does this mean for you? 220 00:06:51,180 --> 00:06:54,220 Subnets are how you keep your network organized and secure. 221 00:06:54,220 --> 00:06:55,540 They're the rooms in your building. 222 00:06:55,540 --> 00:06:57,140 Plan them early and give each tier 223 00:06:57,140 --> 00:06:58,540 of your application its own space. 224 00:06:58,540 --> 00:07:01,100 That's how you keep your network clean and secure. 225 00:07:01,100 --> 00:07:03,700 Public first private IPs, who can see what? 226 00:07:03,700 --> 00:07:05,380 Let's talk about IP addresses 227 00:07:05,380 --> 00:07:07,420 because not all IP addresses are the same. 228 00:07:07,420 --> 00:07:09,500 When you deploy a resource inside a VNet 229 00:07:09,500 --> 00:07:11,740 it gets a private IP address by default. 230 00:07:11,740 --> 00:07:14,220 That's the address it uses to talk to other resources 231 00:07:14,220 --> 00:07:15,380 inside the VNet. 232 00:07:15,380 --> 00:07:17,180 Think of it like an internal phone extension. 233 00:07:17,180 --> 00:07:19,100 Only people inside the building can reach it. 234 00:07:19,100 --> 00:07:21,740 Private IPs are only accessible from inside the VNet 235 00:07:21,740 --> 00:07:23,500 or from networks connected to it. 236 00:07:23,500 --> 00:07:25,100 If you're sitting at home on your laptop 237 00:07:25,100 --> 00:07:27,460 you can't reach a private IP in Azure. 238 00:07:27,460 --> 00:07:30,420 It's not on the internet, it's inside your private network. 239 00:07:30,420 --> 00:07:32,820 So how do you make a resource reachable from the internet? 240 00:07:32,820 --> 00:07:34,220 You give it a public IP address. 241 00:07:34,220 --> 00:07:36,340 That's the address visible to the outside world. 242 00:07:36,340 --> 00:07:37,780 Like having a published phone number 243 00:07:37,780 --> 00:07:39,300 instead of an internal extension. 244 00:07:39,300 --> 00:07:40,580 Here's the key thing. 245 00:07:40,580 --> 00:07:41,860 Public IPs are optional. 246 00:07:41,860 --> 00:07:43,020 You assign them explicitly 247 00:07:43,020 --> 00:07:45,940 because Azure never gives your resources a public IP 248 00:07:45,940 --> 00:07:47,100 unless you ask for it. 249 00:07:47,100 --> 00:07:49,020 That's by design, the default should be private 250 00:07:49,020 --> 00:07:50,860 and public should be a deliberate choice. 251 00:07:50,860 --> 00:07:52,980 And this is where a lot of beginners make a mistake there. 252 00:07:52,980 --> 00:07:54,700 They give public IPs to everything. 253 00:07:54,700 --> 00:07:56,980 Their web server, their database, their back-end API, 254 00:07:56,980 --> 00:07:57,700 all get one. 255 00:07:57,700 --> 00:07:58,700 That's a security risk. 256 00:07:58,700 --> 00:08:01,100 Your database doesn't need to be reachable from the internet 257 00:08:01,100 --> 00:08:03,220 and neither does your back-end API. 258 00:08:03,220 --> 00:08:06,140 Only the front-end resources that users actually interact with 259 00:08:06,140 --> 00:08:07,620 should have public IPs. 260 00:08:07,620 --> 00:08:09,420 Now public IPs come in two flavors. 261 00:08:09,420 --> 00:08:10,780 Static and dynamic. 262 00:08:10,780 --> 00:08:12,580 A static public IP stays the same 263 00:08:12,580 --> 00:08:14,580 even if you stop and restart the resource. 264 00:08:14,580 --> 00:08:16,060 A dynamic public IP can change. 265 00:08:16,060 --> 00:08:17,500 If you're running a production application, 266 00:08:17,500 --> 00:08:19,300 you probably want static IPs 267 00:08:19,300 --> 00:08:20,900 so your users can always find you. 268 00:08:20,900 --> 00:08:23,660 If you're testing something, dynamic might be fine. 269 00:08:23,660 --> 00:08:26,060 You can also use something called a public IP prefix 270 00:08:26,060 --> 00:08:28,180 which lets you reserve a block of addresses. 271 00:08:28,180 --> 00:08:31,500 Instead of creating them one at a time, you reserve a range 272 00:08:31,500 --> 00:08:34,100 and then assign individual addresses from that range. 273 00:08:34,100 --> 00:08:37,220 Useful if you know you're going to need multiple public IPs 274 00:08:37,220 --> 00:08:38,140 for a project. 275 00:08:38,140 --> 00:08:39,260 What does this mean for you? 276 00:08:39,260 --> 00:08:40,820 Private IPs are the safety fault. 277 00:08:40,820 --> 00:08:42,300 They're the internal phone extension. 278 00:08:42,300 --> 00:08:44,220 Public IPs are a deliberate choice you make 279 00:08:44,220 --> 00:08:46,540 only when you need something reachable from the outside. 280 00:08:46,540 --> 00:08:49,300 And when you do need them, think about whether you need static 281 00:08:49,300 --> 00:08:51,940 or dynamic and whether a prefix makes sense. 282 00:08:51,940 --> 00:08:54,060 Network security groups controlling traffic. 283 00:08:54,060 --> 00:08:56,300 So you've got your vnet, your subnets, 284 00:08:56,300 --> 00:08:57,620 your IP addresses sorted out. 285 00:08:57,620 --> 00:09:00,700 But how do you actually control what traffic is allowed in and out? 286 00:09:00,700 --> 00:09:02,900 That's where network security groups come in. 287 00:09:02,900 --> 00:09:05,700 And NSG is the gatekeeper that controls what traffic enters 288 00:09:05,700 --> 00:09:06,980 and leaves your resources. 289 00:09:06,980 --> 00:09:09,940 Think of it as a bouncer at the door of a club, checking IDs, 290 00:09:09,940 --> 00:09:12,380 looking at the guest list, and turning away anyone 291 00:09:12,380 --> 00:09:13,420 who shouldn't be there. 292 00:09:13,420 --> 00:09:15,940 Every piece of traffic that tries to reach your resource 293 00:09:15,940 --> 00:09:17,980 has to go through this bouncer first. 294 00:09:17,980 --> 00:09:19,620 NSG's work with rules. 295 00:09:19,620 --> 00:09:23,140 Each rule says either allow or deny based on four things. 296 00:09:23,140 --> 00:09:25,860 The source IP address, the destination IP address, 297 00:09:25,860 --> 00:09:27,420 the port number, and the protocol. 298 00:09:27,420 --> 00:09:30,260 So you can say allow traffic from my office IP address 299 00:09:30,260 --> 00:09:34,980 on port 443 or deny all traffic from the internet on port 22. 300 00:09:34,980 --> 00:09:36,140 That kind of control. 301 00:09:36,140 --> 00:09:37,460 Now here's a powerful feature. 302 00:09:37,460 --> 00:09:42,140 You can attach an NSG to a subnet or directly to a single VM's network interface. 303 00:09:42,140 --> 00:09:45,780 If you attach it to a subnet, that NSG applies to everything inside, 304 00:09:45,780 --> 00:09:48,940 every VM, every database, every resource, it's a blanket policy. 305 00:09:48,940 --> 00:09:51,700 If you attach it to a specific VM's network interface, 306 00:09:51,700 --> 00:09:53,660 it only applies to that one machine. 307 00:09:53,660 --> 00:09:55,020 You can even do both. 308 00:09:55,020 --> 00:10:00,140 A subnet level NSG for broad rules and the NIC level NSG for exceptions. 309 00:10:00,140 --> 00:10:02,780 The default rules that Azure creates are pretty sensible. 310 00:10:02,780 --> 00:10:04,620 They allow all traffic within the vnet, 311 00:10:04,620 --> 00:10:06,380 so your resources can talk to each other. 312 00:10:06,380 --> 00:10:08,340 And they deny all traffic from the internet, 313 00:10:08,340 --> 00:10:10,620 so nothing from outside can reach your resources 314 00:10:10,620 --> 00:10:12,460 unless you explicitly allow it. 315 00:10:12,460 --> 00:10:13,500 That's a good starting point. 316 00:10:13,500 --> 00:10:14,700 Let me give you a common example. 317 00:10:14,700 --> 00:10:16,460 Say you're managing a Linux virtual machine 318 00:10:16,460 --> 00:10:18,220 and you need to SSH into it. 319 00:10:18,220 --> 00:10:21,380 You'd create an NSG rule that allows inbound traffic on port 22, 320 00:10:21,380 --> 00:10:23,660 but you don't want to allow SSH from everywhere. 321 00:10:23,660 --> 00:10:24,860 That's asking for trouble. 322 00:10:24,860 --> 00:10:26,740 So you restrict it to your own IP address, 323 00:10:26,740 --> 00:10:30,060 so only you can SSH in and everyone else gets blocked. 324 00:10:30,060 --> 00:10:33,500 Same idea for RDP on port 3389 for Windows machines. 325 00:10:33,500 --> 00:10:34,660 What does this mean for you? 326 00:10:34,660 --> 00:10:37,340 NSGs are your first line of defense and the best part. 327 00:10:37,340 --> 00:10:38,220 They're free. 328 00:10:38,220 --> 00:10:39,580 There's no extra cost for using them, 329 00:10:39,580 --> 00:10:41,500 so there's no excuse not to set them up. 330 00:10:41,500 --> 00:10:42,940 Every subnet, every resource, 331 00:10:42,940 --> 00:10:44,300 should have an NSG attached. 332 00:10:44,300 --> 00:10:47,260 Start with the NIOL and only open what you need. 333 00:10:47,260 --> 00:10:49,740 Root tables and routing, directing traffic. 334 00:10:49,740 --> 00:10:51,100 Now let's talk about routing, 335 00:10:51,100 --> 00:10:53,420 because once you've decided what traffic is allowed, 336 00:10:53,420 --> 00:10:55,100 you need to decide where it actually goes. 337 00:10:55,100 --> 00:10:58,700 Here's the thing, Azure automatically creates system routes for every subnet. 338 00:10:58,700 --> 00:11:00,060 You don't have to do anything. 339 00:11:00,060 --> 00:11:03,260 Think of it like a default GPS that knows the basic roads. 340 00:11:03,260 --> 00:11:05,900 Traffic within the VNet, traffic to PIRD VNet, 341 00:11:05,900 --> 00:11:07,340 traffic to the internet. 342 00:11:07,340 --> 00:11:08,780 It all just works out of the box, 343 00:11:08,780 --> 00:11:11,900 but sometimes the default GPS doesn't take you where you want to go. 344 00:11:11,900 --> 00:11:14,620 That's when you need user-defined routes or UDRs. 345 00:11:14,620 --> 00:11:16,620 These let you override Azure system routes 346 00:11:16,620 --> 00:11:18,700 and take control of the path traffic follows. 347 00:11:18,700 --> 00:11:19,500 How does it work? 348 00:11:19,500 --> 00:11:20,540 You create a root table. 349 00:11:20,540 --> 00:11:21,900 You add your custom routes. 350 00:11:21,900 --> 00:11:24,140 Then you associate that root table with a subnet. 351 00:11:24,140 --> 00:11:26,940 From that point on, traffic leaving that subnet follows your rules 352 00:11:26,940 --> 00:11:28,060 instead of the defaults. 353 00:11:28,060 --> 00:11:29,580 Let me give you a concrete example. 354 00:11:29,580 --> 00:11:33,260 Say you want all internet traffic from your VNet to go to a firewall first. 355 00:11:33,260 --> 00:11:34,620 Maybe you need to inspect it, 356 00:11:34,620 --> 00:11:36,460 log it, block malicious sites. 357 00:11:36,460 --> 00:11:39,260 The default system route sends internet traffic directly out. 358 00:11:39,260 --> 00:11:40,380 That's not what you want. 359 00:11:40,380 --> 00:11:43,340 So you create a route that says any traffic going to 0.0, 360 00:11:43,340 --> 00:11:44,940 be it routes on 0.0, 0.0, 361 00:11:44,940 --> 00:11:46,540 which means anywhere on the internet 362 00:11:46,540 --> 00:11:48,300 should go to the firewall instead. 363 00:11:48,300 --> 00:11:49,660 That's a user-defined route. 364 00:11:49,660 --> 00:11:52,220 Root tables use something called next hop. 365 00:11:52,220 --> 00:11:54,540 That's the destination where traffic gets sent next. 366 00:11:54,540 --> 00:11:55,420 You have a few options. 367 00:11:55,420 --> 00:11:57,980 You can send it to a virtual appliance like a firewall 368 00:11:57,980 --> 00:12:00,380 you can send it to a virtual network gateway 369 00:12:00,380 --> 00:12:02,620 which is how you connect to on-premises networks. 370 00:12:02,620 --> 00:12:04,460 You can send it directly to the internet 371 00:12:04,460 --> 00:12:05,820 or you can send it to none 372 00:12:05,820 --> 00:12:07,980 which basically drops the traffic. 373 00:12:07,980 --> 00:12:11,260 The key thing to understand is that routing is how you control 374 00:12:11,260 --> 00:12:13,500 the path traffic takes through your network. 375 00:12:13,500 --> 00:12:15,020 System routes are a good default 376 00:12:15,020 --> 00:12:17,180 but they're not always right for your situation. 377 00:12:17,180 --> 00:12:19,100 If you need traffic to go through an inspection point 378 00:12:19,100 --> 00:12:20,540 or to a specific gateway 379 00:12:20,540 --> 00:12:21,980 or to be blocked entirely, 380 00:12:21,980 --> 00:12:23,340 you need user-defined routes. 381 00:12:23,340 --> 00:12:24,700 What does this mean for you? 382 00:12:24,700 --> 00:12:26,780 Rooting is how you tell traffic where to go. 383 00:12:26,780 --> 00:12:28,940 And you have the power to override Azure's defaults 384 00:12:28,940 --> 00:12:30,140 whenever you need to. 385 00:12:30,140 --> 00:12:32,860 Start with the system routes, understand what they do 386 00:12:32,860 --> 00:12:36,300 and then add custom routes when your architecture demands it. 387 00:12:36,300 --> 00:12:38,300 VNet Peering, connecting networks. 388 00:12:38,300 --> 00:12:40,460 So far we've been talking about a single VNet. 389 00:12:40,460 --> 00:12:42,140 One building, one private network. 390 00:12:42,140 --> 00:12:43,900 But what happens when you have multiple VNets? 391 00:12:43,900 --> 00:12:45,740 Maybe you've got one for your production environment 392 00:12:45,740 --> 00:12:46,860 and another for testing. 393 00:12:46,860 --> 00:12:48,620 Or maybe you're running applications 394 00:12:48,620 --> 00:12:50,140 in different Azure regions. 395 00:12:50,140 --> 00:12:52,300 By default these VNets are completely isolated. 396 00:12:52,300 --> 00:12:53,420 They can't talk to each other. 397 00:12:53,420 --> 00:12:55,580 They're like separate buildings with no roads between them. 398 00:12:55,580 --> 00:12:57,100 That's where VNet Peering comes in. 399 00:12:57,100 --> 00:12:59,260 It lets you connect two VNets privately. 400 00:12:59,260 --> 00:13:00,380 And I mean privately, 401 00:13:00,380 --> 00:13:03,740 traffic between Peered VNets stays on the Microsoft backbone network. 402 00:13:03,740 --> 00:13:05,260 It never touches the public internet. 403 00:13:05,260 --> 00:13:07,260 That means low latency, high bandwidth, 404 00:13:07,260 --> 00:13:09,020 and no exposure to outside threats. 405 00:13:09,020 --> 00:13:10,780 Here's something that surprises people. 406 00:13:10,780 --> 00:13:12,780 Peering works across regions too. 407 00:13:12,780 --> 00:13:14,140 That's called global peering. 408 00:13:14,140 --> 00:13:15,580 You can have a VNet in West Europe 409 00:13:15,580 --> 00:13:17,500 peered with a VNet in Southeast Asia 410 00:13:17,500 --> 00:13:20,460 and traffic between them stays on Microsoft's private network. 411 00:13:20,460 --> 00:13:22,060 No VPN gateways, no public IPs, 412 00:13:22,060 --> 00:13:23,500 just a direct private connection. 413 00:13:23,500 --> 00:13:25,740 But there's a rule you absolutely cannot break. 414 00:13:25,740 --> 00:13:28,540 Peered VNets must have non-overlapping address spaces. 415 00:13:28,540 --> 00:13:32,940 If both VNets try to use the 10.0.0 on zero, 16 range, 416 00:13:32,940 --> 00:13:34,140 they can't be peered. 417 00:13:34,140 --> 00:13:35,660 The IP addresses would clash 418 00:13:35,660 --> 00:13:38,780 and Azure wouldn't know which network a packet belongs to. 419 00:13:38,780 --> 00:13:40,540 So remember that earlier planning tip 420 00:13:40,540 --> 00:13:42,620 about choosing your address space carefully. 421 00:13:42,620 --> 00:13:43,580 This is why. 422 00:13:43,580 --> 00:13:45,740 If you think you might peer VNet later, 423 00:13:45,740 --> 00:13:48,380 make sure their ranges don't overlap from the start. 424 00:13:48,380 --> 00:13:50,220 Now here's a detail that trips people up. 425 00:13:50,220 --> 00:13:51,260 Peering is non-transitive. 426 00:13:51,260 --> 00:13:51,980 What does that mean? 427 00:13:51,980 --> 00:13:54,140 Let's say VNet A is peered with VNet B 428 00:13:54,140 --> 00:13:56,220 and VNet B is peered with VNet C. 429 00:13:56,220 --> 00:13:59,020 VNet A does not automatically reach VNet C through B. 430 00:13:59,020 --> 00:14:00,220 They're not connected. 431 00:14:00,220 --> 00:14:03,100 Each peering is a direct link between exactly two VNets. 432 00:14:03,100 --> 00:14:04,380 If you want A to talk to C, 433 00:14:04,380 --> 00:14:06,380 you need a separate peering between A and C. 434 00:14:06,380 --> 00:14:07,820 So how do you handle this at scale? 435 00:14:07,820 --> 00:14:09,420 You use a hub and spoke architecture. 436 00:14:09,420 --> 00:14:10,700 One central VNet, the hub, 437 00:14:10,700 --> 00:14:11,900 is peered with many other VNets. 438 00:14:11,900 --> 00:14:12,860 The spokes. 439 00:14:12,860 --> 00:14:14,460 The hub might contain shared services 440 00:14:14,460 --> 00:14:17,260 like a firewall, a VPN gateway or monitoring tools. 441 00:14:17,260 --> 00:14:19,500 The spokes contain your individual workloads. 442 00:14:19,500 --> 00:14:21,100 Each spoke peers directly with the hub 443 00:14:21,100 --> 00:14:22,940 but spokes don't peer with each other. 444 00:14:22,940 --> 00:14:24,460 If a spoke needs to reach another spoke, 445 00:14:24,460 --> 00:14:25,900 traffic goes through the hub. 446 00:14:25,900 --> 00:14:27,180 That keeps things organized 447 00:14:27,180 --> 00:14:30,060 and gives you a central place to apply security policies. 448 00:14:30,060 --> 00:14:31,260 What does this mean for you? 449 00:14:31,260 --> 00:14:32,700 Peering is how you build networks 450 00:14:32,700 --> 00:14:34,620 that span multiple VNets and regions. 451 00:14:34,620 --> 00:14:36,140 It's the bridge between your buildings, 452 00:14:36,140 --> 00:14:38,460 plan your address spaces so they don't overlap. 453 00:14:38,460 --> 00:14:40,300 Remember that peering isn't transitive 454 00:14:40,300 --> 00:14:41,900 and consider a hub and spoke design 455 00:14:41,900 --> 00:14:43,740 when you start growing beyond a single VNet. 456 00:14:43,740 --> 00:14:45,500 How it all connects? 457 00:14:45,500 --> 00:14:46,540 The big picture. 458 00:14:46,540 --> 00:14:49,260 So let's step back and see how these pieces actually fit together. 459 00:14:49,260 --> 00:14:50,380 That's where the real power is. 460 00:14:50,380 --> 00:14:51,660 You start with a VNet. 461 00:14:51,660 --> 00:14:53,260 That's your private space in Azure. 462 00:14:53,260 --> 00:14:54,300 Think of it as your land. 463 00:14:54,300 --> 00:14:56,140 Inside that land, you create subnets. 464 00:14:56,140 --> 00:14:57,340 Those are your rooms. 465 00:14:57,340 --> 00:14:59,020 One for web servers, one for databases, 466 00:14:59,020 --> 00:15:00,540 one for management tools. 467 00:15:00,540 --> 00:15:02,780 Each subnet gets its own block of addresses carved 468 00:15:02,780 --> 00:15:04,540 from the VNet's address space. 469 00:15:04,540 --> 00:15:06,700 Then you add security, network security groups 470 00:15:06,700 --> 00:15:08,140 attached to your subnets. 471 00:15:08,140 --> 00:15:10,700 They control what traffic is allowed in and out. 472 00:15:10,700 --> 00:15:12,860 Your web subnet allows traffic from the internet 473 00:15:12,860 --> 00:15:14,140 on port 443. 474 00:15:14,140 --> 00:15:15,980 Your database subnet only allows traffic 475 00:15:15,980 --> 00:15:18,380 from the web subnet on port 1933. 476 00:15:18,380 --> 00:15:20,860 The bouncer at each door knows exactly who is allowed. 477 00:15:20,860 --> 00:15:22,060 Next, you set up routing. 478 00:15:22,060 --> 00:15:24,060 Maybe you want all outbound internet traffic 479 00:15:24,060 --> 00:15:26,140 to go through a firewall for inspection. 480 00:15:26,140 --> 00:15:28,300 You create a root table, add a custom root 481 00:15:28,300 --> 00:15:29,740 and link it to your subnets. 482 00:15:29,740 --> 00:15:31,660 Now traffic follows the path you designed 483 00:15:31,660 --> 00:15:33,180 instead of Azure's default. 484 00:15:33,180 --> 00:15:35,340 And finally, you connect everything together. 485 00:15:35,340 --> 00:15:37,340 You peer your VNet with other VNets. 486 00:15:37,340 --> 00:15:40,140 Maybe a hub VNet that holds your firewall and shared services. 487 00:15:40,140 --> 00:15:42,780 Now, your application spans multiple networks 488 00:15:42,780 --> 00:15:45,740 but it all works as one connected system. 489 00:15:45,740 --> 00:15:47,020 Here's the aha moment. 490 00:15:47,020 --> 00:15:48,540 None of these pieces work in isolation. 491 00:15:48,540 --> 00:15:50,460 A VNet without subnets is just empty space. 492 00:15:50,460 --> 00:15:52,380 Subnets without NSGs are wide open. 493 00:15:52,380 --> 00:15:55,660 Roting without a clear design sends traffic to the wrong place. 494 00:15:55,660 --> 00:15:57,900 Peering without planning creates address conflicts. 495 00:15:57,900 --> 00:15:58,860 They are a system. 496 00:15:58,860 --> 00:16:00,300 Each piece depends on the others. 497 00:16:00,300 --> 00:16:01,900 Let me give you a concrete example. 498 00:16:01,900 --> 00:16:03,260 Imagine a web application. 499 00:16:03,260 --> 00:16:05,820 Your web server sit in a public subnet with an NSG 500 00:16:05,820 --> 00:16:07,980 that allows HTTPS traffic from the internet. 501 00:16:07,980 --> 00:16:10,380 Your application server sit in a private subnet 502 00:16:10,380 --> 00:16:12,700 that only accepts traffic from the web subnet. 503 00:16:12,700 --> 00:16:14,780 Your database sits in another private subnet 504 00:16:14,780 --> 00:16:17,340 that only accepts traffic from the app subnet. 505 00:16:17,340 --> 00:16:19,340 A root table forces all outbound traffic 506 00:16:19,340 --> 00:16:22,220 through a firewall in the hub VNet for logging and inspection. 507 00:16:22,220 --> 00:16:24,700 And the whole thing is peered with your corporate network 508 00:16:24,700 --> 00:16:26,380 so your internal team can manage it. 509 00:16:26,380 --> 00:16:28,540 That's the real value, not any single feature. 510 00:16:28,540 --> 00:16:30,060 It's how they all work together. 511 00:16:30,060 --> 00:16:32,700 20 years ago, you would buy separate servers, 512 00:16:32,700 --> 00:16:36,300 configure physical routers, and manage firewalls per device. 513 00:16:36,300 --> 00:16:38,220 Everything was manual, slow and expensive 514 00:16:38,220 --> 00:16:40,380 as your gives you all of this as a service. 515 00:16:40,380 --> 00:16:42,780 You define it with a few clicks or a script, 516 00:16:42,780 --> 00:16:43,980 and it just works. 517 00:16:43,980 --> 00:16:45,180 What does this mean for you? 518 00:16:45,180 --> 00:16:47,340 Once you see how these pieces fit together 519 00:16:47,340 --> 00:16:49,340 as your networking becomes predictable, 520 00:16:49,340 --> 00:16:51,340 you are not guessing, you are designing. 521 00:16:51,340 --> 00:16:53,740 And when something breaks, you know exactly where to look 522 00:16:53,740 --> 00:16:55,500 because you understand the system. 523 00:16:55,500 --> 00:16:57,980 So here is what I want you to take away from this episode. 524 00:16:57,980 --> 00:17:00,460 First, the most important step you can take. 525 00:17:00,460 --> 00:17:02,620 Create a VNet with a well-planned address space 526 00:17:02,620 --> 00:17:03,820 before you deploy anything. 527 00:17:03,820 --> 00:17:06,220 That single decision affects everything downstream. 528 00:17:06,220 --> 00:17:09,340 Second, use subnets to separate your application tiers. 529 00:17:09,340 --> 00:17:11,260 Web servers, app servers, databases, 530 00:17:11,260 --> 00:17:13,980 give each one its own room. And third, start with NSGs. 531 00:17:13,980 --> 00:17:15,660 They are free. They are powerful. 532 00:17:15,660 --> 00:17:18,380 And they dramatically improve your security from day one. 533 00:17:18,380 --> 00:17:21,260 Your VNet is the foundation of everything you build in Azure. 534 00:17:21,260 --> 00:17:23,500 Get it right, and everything else gets easier. 535 00:17:23,500 --> 00:17:25,340 Get it wrong, and you will spend your whole time 536 00:17:25,340 --> 00:17:26,380 fighting your network. 537 00:17:26,380 --> 00:17:28,460 Subscribe on your favorite podcast platform 538 00:17:28,460 --> 00:17:30,860 and share this with someone who is starting their Azure journey. 539 00:17:30,860 --> 00:17:32,460 Drop a comment if something clicked. 540 00:17:32,460 --> 00:17:34,460 I will see you in the next episode.