So in this next section we're going to be talking about virtual networks. We're going to talk about implementing and managing virtual networks, integrating on-premises virtual networks with the Azure virtual networks, and also monitoring and troubleshooting virtual networks. We'll look at Azure security groups and Azure DNS, implementing Azure load balancer. So first we're going to be looking at implementing and managing virtual networks. So the Azure VNet is the same as a VPC in AWS. It's a virtual network, and when you're deciding on going to Azure you need to plan just like you do when you're setting up a on-premises network. Now the VNet is nothing really different. It's just that you're defining or dealing with a software-defined network. There are some constraints, you can only have 1,000 VNets in your Azure subscription. But you can have multiple subscriptions, like we learned in previous modules. Now we'll learn later on about VNet connections we have, which one of them is called VNet peering. You can have a maximum of ten VNet peerings within your subscription. The smallest CIDR address you can have is /29, which supports 6 clients. And the largest is /8, which will support up to 16 million clients. Just like our on-premises environment, we need IP addresses to allow identification of our clients. We have our private IP addresses that are accessible within the VNet, across the VPN, or Expressroute. To enable the connect externally to a VNet we need to have a public IP address. Now, this can be static or dynamic. The default is dynamic, but can be changed to a static. The public IP address is purchase and needs to be a requested. There's a limited amount of IPv4 addresses available, so it's why they need to be requested. We ran out of public IPv4 addresses about three years ago. Eventually, we'll need to go to IPv6, but not yet. Microsoft has enough supply of public IP addresses because they keep recycling them. Let's take a look at the public IP address. The public IP addresses can be used for internal communications between the Azure services. Now, their only way to provide external communications is over the Internet. You can use IPv4 or/and also IPv6 for public IP addresses, but for IPv6 it's limited. IPv6 can only be used for external load balancers at the moment. When the Azure resource is started up or created, Azure will assign a public IP address to the virtual network interface of the VNet. When an outbound connection is initiated, Azure will map the private IP address to the public IP address. That's source network address translation, or is what is known as SNAT. Azure assigns the public IP address to the network interface when the resource is created or started. SNAT will occur when the outbound connection is established. Return traffic to the resource is also permitted. So how are PIPs used? They're used to provide access to VMs externally. They're are also located on external load balancers, VPN gateways, and also application gateways. Now, you are limited to 60 PIPs per subscription, and also 20 of those can be static. The first five static IP addresses are free to use. Now, the private IP address supports both IPv4 and IPv6. The support for IPv6 is limited at this point and can be configured with dynamic assigned private IP addresses using DHCP or statically assigned. IPv6 addresses are only available when assigning to an external load balancer at the moment where the front end IP address is an IPv4 address, and then the back end is an IPv6 address. Private IP addresses are typically used for VMS, internal load balancers, and application gateways. The VPN is also always Internet-facing, it cannot have a private IP address. There is a maximum of 4096 private IP addresses per VNet. You can create multiples of VNets. The maximum is 50 VNets per subscription. Now if you need additional VNets, you can always request these from Microsoft. You would just open a support request to raise the limit.
