In Azure, we can have two types of IP addresses, private and public. Public addresses can be accessed over the internet. Private addresses are from the VNet address space and are used for private communication on private networks. Addresses can be assigned to a resource or can exist as a separate resource.

Create a public IP address

Public IP Address can be created as a separate resource or created during the creation of some other resources (a VM, for example). Therefore, a public IP can exist as part of a resource or as a standalone resource.

The Stock Keeping Unit (SKU) can be either Basic or Standard. The main differences are that Standard is closed to inbound traffic by default (inbound traffic must be whitelisted in NSGs) and that Standard is zone redundant. Another difference is that a Standard SKU public IP address has a static assignment, while a Basic SKU can be either static or dynamic. You can choose either the IPv4 or IPv6 version for the IP address, or both, but choosing IPv6 will limit you to a dynamic assignment for the Basic SKU and static assignment for the Standard SKU.

The DNS Name Label is optional—it can be used to resolve the endpoint if dynamic assignment is selected. Otherwise, there is no point in creating a DNS label, as an IP address can always be used to resolve the endpoint if static assignment is selected.

Network Security Group (NSG) is a built-in tool for network control that allow us to control incoming and outgoing traffic on an NIC or at the subnet level. They contain sets of rules that allow or deny specific traffic to specific resources or subnets in Azure. An NSG can be associated with either a subnet (by applying security rules to all resources associated with the subnet) or an NIC, which is done by applying security rules to the VM associated with the NIC.

Create an NSG

As a first step to more effectively control network traffic, we are going to create a new NSG. The NSG deployment can be initiated during a VM deployment. This will associate the NSG to the NIC associated with the deployed VM. In this case, the NSG is already associated with the resource, and rules defined in the NSG will apply only to the associated VM.

If the NSG is deployed separately, it is not associated and the rules that are created within it are not applied until an association has been created with the NIC or the subnet. When it is associated with a subnet, the NSG rules will apply to all resources on the subnet.

Azure Virtual Machine depends on virtual networking, and during the creation process, we need to define the network settings.

Create VMs

When a VM is created, a Network Interface Card (NIC) is created in the process. An NIC is used as a sort of interconnection between the VM and the VNet. A NIC is assigned a private IP address by the network. As an NIC is associated with both the VM and the VNet, the IP address is used by the VM. Using this IP address, the VM can communicate over a private network with other VMs (or other Azure resources) on the same network.

Additionally, NICs and VMs can be assigned public IP addresses as well. A public address can be used to communicate with the VM over the internet, either to access services or to manage the VM.

View VM network settings

After an Azure VM is created, we can review the network settings in the VM pane. Networking information is displayed in several places, including in the VM’s network settings. Additionally, each Azure resource has a separate pane and exists as an individual resource, so we can view these settings in multiple places. However, the most complete picture of VM network settings can be found in the VM pane and the NIC pane.

Azure Virtual Network represents your local network in the cloud. It enables other Azure resources to communicate over a secure private network without exposing endpoints over the internet.

Create a VNet

We deploy VNets to resource group under subscription in the Azure data center that we choose. Region and Subscription are important parameters; we will only be able to attach Azure resources to this VNet if they are in the same subscription and region as the Azure data center.

The address space option defines the number of IP addresses that will be available for our network. It uses the Classless Inter-Domain Routing (CIDR) format and the largest range we can choose is /8. In the portal, we need to create an initial subnet and define the subnet address range. The smallest subnet allowed is /29 and the largest is /8 (however, this cannot be larger than the VNet range). For reference, the range 10.0.0.0/8 will create an address range of 167772115 IP addresses (from 10.0.0.0 to 10.255.255.255) and 10.0.0.0/29 will create a range of 8 IP addresses (from 10.0.0.0 to 10.0.0.7).

Add a subnet

In addition to adding subnets while creating a VNet, we can add additional subnets to our network at any time. A single VNet can have multiple subnets defined. Subnets cannot overlap and must be in the range of the VNet address range. For each subnet, four IP addresses are saved for Azure management and cannot be used. Depending on the network settings, we can define the communication rules between subnets in the VNet.

Update corresponding versions

Update package name + package version:

• setup.py;
• requirements.py3.Linux.txt;
• requirements.py3.Darwin.txt;
• requirements.py3.Windows.txt;

Update resource type + api version:

• _shared.py (latest);

Setup development environment

Install expected Python packages:

1

$ azdev setup -c -r ./azure-cli-extensions