Blog Post

Azure Networking Blog
7 MIN READ

Optimize Azure Landing Zone with Azure Virtual Network Manager IP Address Management

jl-ms's avatar
jl-ms
Icon for Microsoft rankMicrosoft
Oct 03, 2024

Optimize Azure Landing Zone with Azure Virtual Network Manager IP Address Management

 

What you will learn from this blog

This blog explores how Azure Landing Zones and IP Address Management (IPAM) in Azure Virtual Network Manager work together to streamline IP address management. Azure Landing Zones provide a scalable environment for deploying applications, while IPAM automates and simplifies IP planning and allocation across Azure, on-premises, and other clouds. By combining them, organizations can ensure efficient, conflict-free IP address usage, enhance security, and accelerate application deployments. The blog offers practical steps and examples for implementing this integrated solution, helping you optimize your Azure network infrastructure.

 

IP Address Management (IPAM) in Azure Virtual Network Manager (AVNM)

Azure IP Address Management (IPAM) is a feature in Azure Virtual Network Manager that simplifies managing IP addresses across your Azure environments, on-premises setups, and even other cloud providers. It helps you organize your IP addresses and Classless Inter-Domain Routings (CIDRs) efficiently and set clear rules for assigning them. With IPAM, you can automate the process of assigning IP addresses to virtual networks (VNets), which eliminates the need for cumbersome spreadsheets or custom tools.

This automation speeds up the process of launching new applications or expanding existing ones by allowing quick requests, registrations, and assignments of IP address spaces from your organization's pools to your VNets within seconds. This removes the need for manual requests or tickets to the network team, improving overall provisioning times.

 

VNets are the foundation of private networking in Azure, enabling services like Virtual Machines to communicate securely with each other, the internet, or on-premises networks. When setting up a VNet, you'll define an IP address space that can include both public and private ranges (such as those defined by RFC 1918 and RFC 6598).

 

Azure IPAM supports network administrators by ensuring non-overlapping IP prefixes and automating the assignment of IP addresses to Azure resources within these subnets.

 

Key Components and Functionalities

IP Address Pools

IP Address Pools are central to IPAM, serving as logical containers that group IP address ranges. They enable efficient and organized management of IP address spaces across Azure resources.

  • Creation and Organization: Network admins can create pools with defined address spaces and sizes, allowing for planned and organized IP address usage.
  • Hierarchy: Pools can be structured in a hierarchy, enabling the division of larger pools into smaller, more manageable units for granular control.
  • IPv4 and IPv6 Support: IPAM can handle both IPv4 and IPv6 addresses, accommodating diverse networking needs.

Allocation

  • Resource Assignment: CIDRs from specific pools can be assigned to Azure resources like virtual networks, making it easier to track address usage.
  • Static CIDR Allocation: Admins can allocate static CIDRs for IPs not currently in use within Azure or for resources not yet supported by IPAM, which is helpful for managing IP spaces in on-premises or other cloud environments.
  • CIDR Release: When associated resources are deleted, allocated CIDRs are automatically released back to the pool, ensuring efficient utilization of the IP space.

Delegation

  • Permission Management: Administrators can delegate permissions to other users for utilizing IPAM pools, allowing controlled access and management while democratizing pool allocation.
  • Visibility and Tracking: Delegated permissions provide access to view usage statistics and resource lists for specific pools, improving transparency and collaborative management.

By leveraging these features, AVNM's IPAM helps organizations maintain a clear overview of their IP address utilization, streamline address allocation processes, and ensure efficient use of available IP spaces across their Azure network infrastructure.

 

Azure Landing zone and IPAM

Azure Landing Zone is Azure’s recommended framework and facilitates s, allowing efficient management and scaling for application migrations and new development. This framework grants application teams (DevOps) the appropriate Role-Based Access Control (RBAC) permission that meet their application requirements while ensuring compliance and security, as set by the Platform (Sec/NetOps) team.

Azure network architectures often follow a "hub and spoke" model, featuring a central hub VNet for shared network services and multiple spoke VNets where workloads are deployed. Within an application landing zone subscription, typically one, but sometimes multiple, VNets are created, with assigned IP address spaces to support application deployment. Proper planning for IP address allocation across these VNets is crucial to avoid overlap between on-premises locations and Azure regions, as overlapping IP spaces can lead to conflicts. This process can be simplified using AVNM.

 

IPAM offers multiple use cases, and here's how you can manage your organization's IP planning. Start by creating a Virtual Network Manager instance with the scope set to the intermediate root management group, like Contoso in the example below. This setup allows you to define address pools across all virtual networks and subnets within your Azure Landing Zone hierarchy, enabling subscription democratization for application landing zone owners and teams.

As a network admin, you can efficiently plan and organize IP address usage by defining pools with specific address spaces and sizes. These pools group CIDRs logically for different networking purposes. In our example with Contoso, the Platform and Application teams have distinct responsibilities, maintaining separation of duties. While these teams may vary by organization, they often share the same network infrastructure. IPAM is ideal for allowing both teams to manage their parts of the network while providing visibility to authorized members and preventing IP overlapping. These teams can use IPAM to simplify allocating larger, contiguous IP blocks for specific workloads. It also makes it easy to identify where IP ranges are deployed, aiding troubleshooting and planning.

 

We'll guide you on how to set up your Azure Landing Zone within a single Azure region and across multiple regions using IPAM below.

 

Single-region scenario

To demonstrate how IPAM can be used for creating an Azure Landing Zone in a single-region setup, start by creating a root pool with a /16 address space. From this root pool, allocate a /22 to the Platform Pool and a /18 to the Application Pool, and assign each team the necessary RBAC permissions, like the "IPAM user" role. The NetOps/Platform team can then allocate a /24 for the Identity VNet and a /23 for the Connectivity VNet, while the application team sets up VNets for their applications and specialized workloads (such as Databricks and AKS) from their assigned pool.

 

 

Multi-region scenario

In a more advanced scenario, you can use a multi-region setup to help prevent disruptions and data loss from events affecting an entire region, such as natural disasters, by providing a secondary region for backup and recovery, ensuring higher SLAs.

 

By using a super net (which combines multiple contiguous CIDRs into a single, larger network represented by one CIDR), IPAM allows you to allocate consistent IP address ranges across regions, offering a clear and efficient addressing scheme for the Platform team to manage and troubleshoot.

 

For instance, you can use IPAM to create a Root Pool with a /12 address space as a super net, from which two regional pools are established, each with a /16 allocation. From each regional pool, Platform and Application pools are then created, just like in the previous example, enabling respective teams to set up their VNets as shown in the diagram.

 

 

How to create IPAM via Azure portal

Here’s how to use IPAM through the Azure portal:

 

Create an AVNM Instance: Start by creating an Azure Virtual Network Manager instance at the intermediate root management group level, as mentioned earlier. Once the AVNM resource is created, go to the "IP address pools" blade.

Create an IP Address Pool: On the IP address pools page, click "Create" to set up a new pool.

Select a Parent Pool: When choosing a parent pool, selecting "None" indicates that this will be a new root pool. Otherwise, the pool will be a child of the selected parent pool.

Assign IP Address Space: Define the IP address space(s) for the pool. If it's a child pool, its address space must be within the range of the parent pool. You can assign multiple IP address spaces to a pool.

Manage Allocations: Navigate to the pool's page and select the "Allocations" section. Here, you can:

  • Create child pools
  • Associate resources with the pool
  • Allocate static CIDRs

In our example of Azure Landing Zone creation, we assigned a child pool per Azure Landing Zone application, as shown in the figure below.

We previously created a hub and spoke as recommended in the CAF (Cloud Adoption Framework) documentation and associate the resources to the parent pool as shown in the figure below.

You can reserve static CIDRs for on-premises resources or other cloud IPs to ensure these IPs remain unused in Azure, keeping Contoso’s on-premises environment safe. 

It is advisable to verify the remaining IP address allocations, as illustrated in the image below.

Automatic CIDR Assignment: Instead of specifying a CIDR manually, you can let IPAM automatically assign a non-overlapping CIDR by selecting an IPAM pool and specifying the size for the VNet.  

 

 

How to create a VNet Using Infrastructure as Code

You can also create a VNet from the ALZ-app1 pool using an ARM template and Bicep. In the sample ARM template below, instead of specifying a specific address prefix, you provide the ID of a pool and the number of IP addresses you need. For example, you can request a VNet with 65,536 IPs from the pool because there are 65,536 IPs (2^16) in a /16 address range.

 

 

 

To learn more about how to use build your Azure Landing Zone using Azure Virtual Network Manager, please refer to Azure Virtual Network Manager in Azure Landing Zone.

 

Updated Oct 22, 2024
Version 3.0
  • perry230's avatar
    perry230
    Copper Contributor

    Nice feature, but how can this be used together with an Infrastructure-as-Code solution like Bicep or Terraform? In the case of IaC, the IP addresses are maintained in source code or some kind of configuration (for automation purposes) and not in a visual representation like this one.

  • Cloudplumber's avatar
    Cloudplumber
    Copper Contributor

    As this is a preview feature IaC might not be available. The existing AVM for the network manager is lacking functionality regarding this. I think this is a good extension to the feature set of the product, but for GA an IaC integration should be in place.  

    • jl-ms's avatar
      jl-ms
      Icon for Microsoft rankMicrosoft

      Thank you for your feedback. For IaC for IPAM, please see the section titled "How to Create a VNet Using Infrastructure as Code."

  • phuvo's avatar
    phuvo
    Copper Contributor

    This feature is new feature but did not populate in Asia region

  • Jagunjunior's avatar
    Jagunjunior
    Copper Contributor

    Hello Team,I like to ask a question that been confusing me.

     

    We have a VWan hub and spoke network topology implemented as part of our Azure landing Zone.

     

    For a fact we defined a routing intent on the hub to traverse via the Azure Firewall seating on the hub , what I understand by this is traffic the hits the hub will sure be routed passing through the Azure FW.  I know that such traffic from on-premise that hits the hub is directed towards the FW , as well as inter spoke traffice ,traffic that leaves spoke A and goes to Spoke be has to traverse via the hub and in  turn goes to the FW. My confusion is intra spoke traffic (traffic within a single spoke, say a vm in spoke A,subnect A accessing a storage in same spoke A but subnet B ),Will this traffice going of the spoke to traverse vua the hub but the routing intent?