AZ-700 Designing and Implement Azure Networking Study SUPER Guide!

Key Concepts

Virtual Network, Subnets, Public IPs (Basic & Standard), Public IP Prefix, VNet Peering (Regional & Global), Gateway Transit, User Defined Routing (UDR), Route Tables, NAT Gateway, Network Security Groups (NSG), Service Endpoints, Private Endpoints, Azure Firewall, Azure Bastion, Web Application Firewall (WAF), Azure Front Door, Application Gateway, Load Balancers (Internal & External, Basic & Standard, Regional & Global), Traffic Manager, ExpressRoute, VPN Gateway, Virtual WAN, DNS (Azure DNS, Private DNS Zones), Network Watcher, Traffic Analytics, Connection Monitor.

Basics

Virtual Networks (VNets)

• A VNet exists within a specific subscription and region. It cannot span regions or subscriptions.
• It's a regional construct, spanning all availability zones within a region.
• VNets are Layer 3 constructs (IP-based), supporting TCP, UDP, and ICMP. Broadcast, multicast, and GRE encapsulation are not supported.
• Defined by one or more private IP blocks (RFC 1918 ranges like 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), but can also use public IP blocks brought to Azure, which are still treated as private.
• Can optionally include IPv6 ranges (dual-stack).

Subnets

• Subnets are segments of the VNet's IP space.
• Each subnet has an IPv4 CIDR range and optionally an IPv6 range (always /64).
• Subnets also span availability zones and are regional.
• Subnet IP ranges must come from the VNet's IP range and cannot overlap.
• Azure reserves five IP addresses in each subnet: the network address, the broadcast address, the default gateway, and two DNS addresses. This means the smallest usable subnet is a /29, providing three usable IP addresses.
• Resources (VMs, AKS, App Services, etc.) are placed into subnets and receive private IP addresses via DHCP from the Azure fabric.
• IP addresses can be assigned dynamically or statically (DHCP reservation).

Example: A VNet with address space 10.0.0.0/16 can have subnets like 10.0.1.0/24 and 10.0.2.0/24.

Public IPs

Public IP Addresses

• Azure uses its own public IP addresses; you cannot bring your own for use as public IPs.
• Public IPs are regional resources and cannot be moved between regions.

Public IP Sku's

• Basic:
  • Dynamic or static assignment.
  • Open by default (requires NSGs to lock down).
  • No availability zone support.
  • Some amount is free.
• Standard:
  • Static only.
  • Locked down by default (requires NSGs to allow traffic).
  • Availability zone support.
  • Required by many services and must match the SKU of associated resources (e.g., load balancers).

Public IP Usage

• Used to expose services to the internet.
• Can be linked directly to a resource (instance-level), but typically used with load balancing solutions for resilience and scalability.
• Load balancers can be Layer 4 (TCP/UDP) or Layer 7 (HTTP/HTTPS).

Public IP Prefix

• A contiguous block of public IPs that can be reserved in advance.
• Can be assigned to resources like NAT Gateways.

VNet Peering

VNet Peering Overview

• Connects VNets, enabling resources in different VNets to communicate with each other using the Azure backbone.
• Supports both regional (same region) and global (different regions) peering.
• Cannot peer across different Azure clouds (e.g., commercial to China or US Gov).
• A peering connection consists of two peering links, one in each direction.
• Requires appropriate permissions to establish peering, especially across subscriptions.

Key Considerations

• IP spaces of peered VNets cannot overlap.
• Peering is not transitive. VNets peered to a central hub do not automatically have connectivity between them.
• To enable transitive routing, you can either create a mesh network (peering between all VNets) or route traffic through a central hub using network virtual appliances (NVAs) like Azure Firewall.

Gateway Transit

• Allows spokes to use the VPN or ExpressRoute gateway in the hub VNet to connect to on-premises networks.
• Requires enabling "Allow Gateway Transit" on the hub VNet peering and "Use remote gateways" on the spoke VNet peering.
• Only one remote gateway can be used.
• If a VNet has its own gateway, it cannot use a remote gateway.

Allow Forwarded Traffic

• Enables a hub VNet to forward traffic from a spoke VNet to another destination, typically used with NVAs.
• Requires enabling "Allow forwarded traffic from remote virtual network" on the peering.

User Defined Routing (UDR)

Route Tables

• Allow customization of routing behavior within a VNet.
• A route table is a set of routes that define how traffic should be routed.
• Can be used to direct traffic to NVAs, the internet, or other VNets.
• Route tables are linked to subnets and must be in the same region as the VNet.

Route Configuration

• Routes specify a destination prefix and a next hop type (e.g., virtual appliance, internet, virtual network gateway).
• The next hop can be an IP address on a different subnet or even a different VNet.
• To route traffic through an NVA, create a route with the destination prefix and the NVA's IP address as the next hop.

Effective Routes

• The effective routes for a network interface card (NIC) show the actual routes being used, including default routes, routes added by peering, service endpoints, private endpoints, and user-defined routes.
• Can be used to verify that traffic is being routed as expected.

Example: To send all traffic from a subnet to an Azure Firewall with an IP address of 10.0.1.4, create a route table with a route for 0.0.0.0/0 and a next hop of 10.0.1.4, then link the route table to the subnet.

NAT Gateway

(The transcript ends abruptly, so the summary cannot be completed.)

Conclusion

(The transcript ends abruptly, so the conclusion cannot be completed.)