See some examples of various Azure hierarchies, including designing from the Account and Subscription level, to virtual networks subnets, and network security groups.
- [Instructor] In Azure, we have to design our hierarchies around two levels, the account level and the subscription level. You will need to plan your hierarchy to meet your needs, which may include, isolation, separate billing or by different regions. Before we just into planning our hierarchies and virtual network designs, there are some limitations of the Azure networking that you need to be aware of. First of all, by default, we can have 50 virtual networks per subscription, up to a maximum of 500. You can have 1,000 subnets per virtual network.
If you need to change this, you'll need to contact Microsoft. We can have 100 network security groups per subscription and that can be increased to 400. And we can 200 network security group rules per network security group. And again, this can also be increased up to 500, as required. As always, please refer to the Azure documentation while planning and then again prior to deployment. Azure is a moving target and these limits may change. In Azure, we start thinking about our virtual network designs at the account and subscription levels first, and then we can start building our virtual networks and subnets.
In this example, we have a single account, with a single subscription and then four virtual networks. This is one of the simplest designs and a great place to start if you're new to Azure. You'll notice that we have a virtual network for app one prod and app one dev, and that repeats for app two as well. In this example, we have the same two apps, but we have configured the networks slightly differently. Here, we've created two subscriptions, one for each app. So, app one is in subscription one, and app two is in subscription two.
The advantage here is the resources are separated, and cannot affect the other resources in the other subscription. But you do have to manage the two subscriptions. You can connect these resources between the subscriptions, using a VPN gateway. Each of these subscriptions also contains two virtual networks. One for dev and one for prod. Another way to create a hierarchy, is to separate out our business units at the subscription level. Each business unit is its own entity with its own separate billing.
As we can see here, we have subscription one and subscription two and they are associated with business unit one and business unit two. And then from here, we can build out our virtual networks as required. And finally, we have the same two business units, but now we've associated the app to that business unit. And we have two virtual networks, prod and dev associated with those subscriptions, business unit and the app. Now that we have looked at some account subscription and virtual network design options, let's take a look at the possible subnet designs within the virtual networks.
But as with everything else in Azure, planning is the key. Keep in mind, you will lose five IP addresses in each subnet. You'll lose one to the subnet address, one to multicast and three to internal use. Also note, if you create a subnet and later realize it does not have enough addresses, you'll have to delete that subnet and all the following subnets and then recreate all of 'em. Trust me, this is not a fun process, so be aware of this limitation.
And finally, your virtual appliances and gateways require their own subnets. Now, let's review some network security group considerations before we start designing our subnets. We covered network security groups in detail in chapter four, but here is a quick recap. A network security group or NSG is simply a table with inbound and outbound rules for traffic. You can associate a network security group with a subnet or virtual machine NIC, when applied to the subnet, all of the resources in that subnet are ruled by that NSG.
And you can only have one NSG per subnet and it's this rule that makes the planning of your subnets and network security groups critical. And finally, do not apply a network security group to a VPN gateway or ExpressRoute subnet as it will block the flow of traffic. Now, let's move on to some possible subnet designs. First, we have our single subnet and each virtual machine NIC has a network security group assigned to it. This means you are managing each of the network security groups individually.
Next, we have multiple subnets by application. In this example, we broke down the apps into their own subnets and then applied the network security group to the virtual machine NIC. You'll notice here that we have NSG one and NSG two. This means we've applied the same network security group to those virtual machines, therefore we only have to manage the one network security group. But we are managing two subnets. Next, we have separated out our front and back ends into subnets and applied the network security group again to virtual machine NICs.
This separates the tiers of the application and it provides nice balance of subnets and network security groups. And in our last example, we have a subnet for each app and tier and network security group per subnet. This increases not only the number of subnets we have to manage, but it also increases the number of network security groups. We've covered several different options and it will be up to you to properly design environment. This is one area of your deployment where you do not want to cut corners.
The rest of your infrastructure rests on this design, so take the time and plan not only for today, but for the future.
- Designing virtual machines
- Selecting appropriate VM SKUs
- Designing template deployment
- Deploying ARM templates via PowerShell and CLI
- Designing for availability
- Designing Azure Virtual Networks
- Azure VPN and ExpressRoute architecture and design