- Create and configure virtual networks and subnets
- Create and configure virtual network peering
- Configure private and public IP addresses
- Configure user-defined network routes
- Configure Azure DNS
Virtual networks represent your network in the cloud. Working with the VNet service within Azure is similar to working with a traditional network on-prem, but there are some added benefits:
- Availability
- Network isolation
- Scalability
VNets allow us to:
- Link other VNets within either the same or different regions for private communication.
- Allow VMs to connect securely using the internet.
- Create private connections between VMs and other Azure services.
- Extend on-prem architecture to the cloud, providing hybrid solutions.
We manage address spaces, both on-prem and in the cloud, with the CIDR block. Azure, however, uses both private and public addresses that must be specified upon creating a VNet.
- IP addresses assigned to your org's resources will be assigned from the address space.
Best practice is to ensure your address space doesn't overlap with others in the org, otherwise, conflicts will arise upon connecting VNets to eachother or while establishing a hybrid connection.
Subnetting helps segment addresses, or different workloads, while enhancing the address allocation in an efficient manner. Once the VNet has been segmented, we can deploy resources to specific subnets.
- Note: this is where we can configure network security groups (NSGs).
We can determine the CIDR block depending on how many hosts we want deployed to the subnet.
- Note: subnets should not cover the entire address space of the VNet, we will want to plan ahead by reserving some IP addresses to use in the future.
When it comes to VNets, regions are always scoped to one region or location, but other networks in different regions can still be connected.
- VPN gateways and VNet peering can be used to connect VNets in different locations/regions.
- Note: the region will be chosen during the creation of a VNet and any VMs deployed to the VNet will be in the same region as the VNet.
- If we need to move a VNet to another region, Azure Resource Mover will need to be used.
- Create and configure network security groups (NSGs) and application security groups (ASGs)
- Evaluate effective security rules
- Implement Azure Bastion
- Configure service endpoints
- Configure private endpoints
- Configure Azure Application Gateway
- Configure an internal or public load balancer
- Troubleshoot load balancing
An availability set is a logical grouping of virtual machines hosting your application. These consist of update domains (UDs) and fault domains (FDs). Each VM you create will have a UD and FD that's associated with it.
- Note: you can have up to 3 FDs and 20 UDs.
- The default number of UDs is 5. If you create more than 5 VMs, the 6th VM will be placed on the 1st UD, the 7th on the 2nd UD, and so on.
Deploying multiple instances of your app will help you achieve High Availability (HA), which removes the risk of a single point of failure.
FDs represent a set of VMs that have the same network switch, A/C, and power.
- Note: you can only configure up to 3 FDs, which is the default value when setting up availability sets.
UDs represent a group of VMs and the host, which can be updated & rebooted at the same time.
- Note: only one UD will be rebooted at a time during scheduled maintenanc, such as patching, firmware updates, etc.
- While one is being rebooted, 30mins is required before the next scheduled task will begin on another domain.
Creating availability sets can be done using:
- Azure portal
- Azure PowerShell
- Azure CLI
Information required to create availability sets:
- Subscription
- Resource group
- Name
- Region
- Number of FDs
- Number of UDs
- Disk alignment (use of managed disks)
Each Azure region has unique physical locations. These locations are called zones and make up one or more datacenters that has its own power, networking, and cooling. Deploying apps to multiple zones can provide protection from datacenter failure as we can create instances in different zones within a region.
- If a zone suffers an outage, instances will be deployed in different zones to maintain availability.
When creating a VM, you can select which zone to deploy to.
Note: Availability zones can help improve SLAs of your applications.
Azure Load Balancer is a network load balancer, and operates at layer 4 of the OSI model.
To distribute incoming requests across multiple instances of our apps we can use this service. Our app can be deployed to VMs or Virtual Machine Scale Sets (VMSS). It allows us to ensure high availability (HA) is achieved by spreading the requests across multiple instances.
- Inbound and outbound traffic is supported.
- Relies on load balancing rules & health probes to distribute traffic to backend servers. - Load balancing rules will determine how the traffic is distributed across backend servers. - Health probes will ensure the backend server is capable of handling the request(s). However, if the health cannot be determined, the requests will not be distributed to the server.
Public
- These will have a public IP address & internet facing.
- The IP address and port number get mapped to the private IP and port number of VMs in the backend pool.
- Note: load balancer rules allow us to configure port numbers and handle different types of traffic.
Internal
- These will have a private IP address for all communication and will not be exposed to the internet.
- The IP address can only be reached by resources in the same VNet, from on-prem using VPN, or through peered networks.
- Monitor on-premises connectivity
- Configure and use Azure Monitor for networks
- Use Azure Network Watcher
- Troubleshoot external networking
- Troubleshoot virtual network connectivity