Blog
Azure IP-Adressverwaltung (IPAM) und warum sie wichtig ist

Dieser Artikel ist Teil der XPRT. Magazin Nr. 21
Azure Virtual Network Manager
Bevor wir uns mit dem IP-Adressmanagement (IPAM) befassen, sollten Sie wissen, dass es sich hierbei um eine Funktion des Azure Virtual Network Managers (AVNM) handelt. Der Azure Virtual Network Manager ist ein zentraler Verwaltungsdienst, der dabei hilft, Netzwerkkonnektivität und -sicherheit über mehrere Abonnements und Regionen hinweg in großem Maßstab zu koordinieren und zu steuern. Er ermöglicht es Landing-Zone-Teams, wie z. B. CCoE- und Plattform-Teams, Netzwerktopologien – einschließlich Hub-and-Spoke- und Mesh-Konfigurationen – zu erstellen und zu verwalten, indem automatisch Peering-Beziehungen zwischen virtuellen Netzwerken hergestellt werden.
Der Azure Virtual Network Manager stellt Regeln für Sicherheitsadministratoren bereit, die als globale Sicherheitsrichtlinienebene fungieren und Netzwerksicherheitsanforderungen durchsetzen, bevor Netzwerksicherheitsgruppen ausgewertet werden. Dies ermöglicht die Implementierung verbindlicher Sicherheitskontrollen, die auf untergeordneten Ebenen nicht außer Kraft gesetzt werden können.
Bei der Zuordnung zu einer Verwaltungsgruppe bietet der Azure Virtual Network Manager Transparenz und Kontrolle über die gesamte Azure-Umgebung hinweg und ermöglicht so unternehmensweit einheitliche Netzwerkrichtlinien. Der Azure Virtual Network Manager arbeitet regional, was bedeutet, dass Ressourcen in bestimmten Azure-Regionen bereitgestellt werden, um sie an den Standort der verwalteten virtuellen Netzwerke anzupassen.
Azure-IP-Adressverwaltung
Azure IP Address Management (IPAM) ist eine Funktion, mit der Benutzer private IP-Adressbereiche in ihrer gesamten Cloud-Infrastruktur effektiver planen, nachverfolgen und verwalten können, anstatt sich auf manuelle Tabellenkalkulationen, Wiki-Seiten oder benutzerdefinierte Skripte zur Nachverfolgung von IP-Adressbereichen zu verlassen. Diese manuellen Nachverfolgungsmethoden sind in der Regel bereits in dem Moment veraltet, in dem Netzwerkänderungen vorgenommen werden, was dazu führt, dass mehrere Teams unwissentlich virtuelle Netzwerke mit sich überschneidenden Adressräumen bereitstellen. Dies führt zu Verbindungsstörungen, die umfangreiche Fehlerbehebungsmaßnahmen und eine Neugestaltung des Netzwerks erfordern.
IPAM führt ein hierarchisches Pool-System ein, in dem Sie einen Stamm-Pool definieren können, der den gesamten Adressraum repräsentiert, beispielsweise „ 10.0.0.0/8 “. Dieser kann anschließend in untergeordnete Pools mit einer Tiefe von bis zu sieben Ebenen unterteilt werden, um Organisationsstrukturen wie Plattformdienste, Produktions-Landing-Zones und Nicht-Produktions-Landing-Zones abzubilden.
Wenn Teams neue virtuelle Netzwerke bereitstellen, müssen Sie einen IPAM-Pool zuweisen, der je nach der angeforderten Kapazität nicht überlappende CIDR-Blöcke aus dem entsprechenden Pool zuweist. Wenn diese Netzwerke später gelöscht werden, fließt ihr Adressraum automatisch und ohne manuellen Eingriff zurück in den Pool, um wiederverwendet zu werden. Für IP-Bereiche, die außerhalb der direkten Kontrolle von Azure liegen, wie z. B. lokale Netzwerke, Virtual-WAN-Hubs, private AWS-Clouds oder VMware-Cloud-Subnetze, unterstützt IPAM statische CIDR-Reservierungen, die diese Adressen innerhalb der Pools beanspruchen, um eine versehentliche Zuweisung zu verhindern und gleichzeitig eine genaue Bestandsverfolgung zu gewährleisten.
IPAM funktioniert ebenso wie der Azure Virtual Network Manager regional, was bedeutet, dass in bestimmten Azure-Regionen erstellte Pools nur Ressourcen in denselben Regionen Adressen zuweisen können. Dies entspricht dem Architekturmodell von Azure und erfordert in der Regel parallele Pool-Strukturen über alle Bereitstellungsregionen hinweg.
IPAM lässt sich über das Azure-Portal, Terraform oder andere Infrastructure-as-Code-Tools in virtuelle Netzwerkumgebungen integrieren. Dadurch können Teams einfach festlegen, wie viele IP-Adressen sie benötigen, anstatt verfügbare CIDR-Blöcke manuell auszuwählen. Gleichzeitig bieten integrierte Überwachungsfunktionen einen vollständigen Überblick über die Poolauslastung, den belegten und freien Speicherplatz sowie darüber, welche Ressourcen welche Präfixe nutzen.
Einrichtung des Azure Virtual Network Managers für IPAM
Für alle Beispiele in diesem Artikel verwenden wir Terraform; andere Infrastructure-as-Code-Tools funktionieren auf dieselbe Weise.
Registrierung von Ressourcenanbietern (Gültigkeitsbereich der Verwaltungsgruppe)
Da der Azure Virtual Network Manager auf eine Verwaltungsgruppe beschränkt ist, muss der „ Microsoft.Network “-Anbieter auf derselben Ebene der Verwaltungsgruppe registriert werden. Dadurch können die AVNM- und IPAM-Funktionen in allen Abonnements innerhalb der Verwaltungsgruppe genutzt werden; dies ist eine gängige Voraussetzung, die bei der Bereitstellung über Terraform leicht übersehen werden kann.
data "azurerm_management_group" "this" {
name = "MyManagementGroup"
}
resource "azapi_resource_action" "resource_providers" {
type = "Microsoft.Management/managementGroups@2021-04-01"
resource_id = data.azurerm_management_group.this.id
action = "providers/Microsoft.Network/register"
method = "POST"
}
Azure Virtual Network Manager-Instanz
Der nächste Schritt besteht darin, die AVNM-Instanz in der Zielregion zu erstellen, in der Sie IPAM-Ressourcen verwalten möchten. Der Standort ist von Bedeutung, da AVNM eine regionale Ressource ist und die Netzwerkressourcen entsprechend dieser Region verwaltet.
resource "azurerm_network_manager" "network_manager" {
depends_on = [azapi_resource_action.resource_providers]
name = "nw-prod-weu-001"
description = "Network manager in west europe"
location = "westeurope"
resource_group_name = "rg-network-manager-prod-we-001"
scope {
management_group_ids = [data.azurerm_management_group.this.id]
}
}
Indem der Netzwerkmanager auf die Verwaltungsgruppe beschränkt wird, kann er IP-Adressen (und Netzwerkkonfigurationen) für alle Abonnements innerhalb dieser Gruppe verwalten. Dies ermöglicht eine zentralisierte Steuerung des IPAM und erlaubt es gleichzeitig einzelnen Teams, Netzwerke bereitzustellen, ohne dass es zu Überschneidungen im Adressraum kommt.
IP-Adresspools (IPAM-Pools) definieren
Mit dem Network Manager können Sie die IP-Adresspools definieren. Stellen Sie sich Pools als den Bestand Ihres privaten Adressraums vor. Sie beginnen mit einem einzigen Pool der obersten Ebene (Root-Pool), der den gesamten Adressbereich abdeckt, und unterteilen diesen Bereich anschließend in kleinere untergeordnete Pools, die widerspiegeln, wie Ihre Organisation Netzwerke nach Funktion, Umgebung oder Zuständigkeit segmentiert.
- Root-Pool: Bezeichnet den Adressraum der obersten Ebene, der Ihnen gehört und den Sie von IPAM verwalten lassen möchten (beispielsweise
10.0.0.0/xx). Dies ist der übergeordnete Adressbereich, aus dem sich alle anderen Zuweisungen ableiten. - Unterpools: Unterteilen Sie den Root-Bereich in logische Segmente, damit Teams aus einem abgegrenzten Bereich zuweisen können, ohne sich gegenseitig zu behindern. Zu den gängigen Mustern gehören:
- Plattform/gemeinsam genutzte Dienste (zentrale Infrastruktur, Identitätsmanagement, Überwachung)
- Landungszonen (anwendungsspezifische Netzwerke wie Produktions- und Nicht-Produktionsnetzwerke)
Diese Hierarchie sorgt für eine übersichtliche Organisation Ihres Adressraums, sorgt für die Einhaltung von Grenzen und erleichtert die Erstellung von Berichten zur Auslastung nach Bereichen. Zudem ermöglicht sie die Delegation von Befugnissen, da Teams Zugriff auf bestimmte untergeordnete Pools statt auf den gesamten Adressraum gewährt werden kann.
Der folgende Codeausschnitt erstellt einen solchen IPAM-Stamm-Pool. Der Wert „ address_prefixes “ sollte den vollständigen CIDR-Bereich darstellen, über den Sie verfügen (beispielsweise 10.0.0.0/8), und der Pool ist an die AVNM-Instanz gebunden, sodass IPAM die Zuweisungen durchsetzen und die Auslastung verfolgen kann.
resource "azurerm_network_manager_ipam_pool" "root_ipam" {
name = "ipam-root-prod-weu-001"
location = "westeurope"
network_manager_id = azurerm_network_manager.network_manager.id
display_name = "ipam-root-prod-weu"
address_prefixes = "10.0.0.0/8"
}
Der folgende Ausschnitt zeigt einen untergeordneten Pool, der den Stammbereich in ein kleineres, begrenzte Segment unterteilt (beispielsweise einen Plattform- oder Shared-Services-Bereich). Die Zeile „ parent_pool_name “ verknüpft ihn mit dem Stammpool, und die Zeile „ address_prefixes “ definiert die für dieses Segment reservierten CIDR-Bereiche. Selbstverständlich muss der Adressbereich innerhalb des Bereichs des übergeordneten Pools liegen.
resource "azurerm_network_manager_ipam_pool" "child_pool" {
name = "ipam-pl-prod-weu-001"
location = "westeurope"
parent_pool_name = azurerm_network_manager_ipam_pool.root_ipam.name
network_manager_id = azurerm_network_manager.network_manager.id
display_name = "ipam-platform-prod-weu"
address_prefixes = "10.0.0.0/10"
}
Wie die Pools zusammenwirken
Wenn der Stamm-Pool „ 10.0.0.0/8 “ lautet und Sie untergeordnete Pools anlegen – Plattform: „ 10.0.0.0/10 “ und Landing-Zonen: „ 10.64.0.0/10 “ –, dann erzwingt IPAM strenge Grenzen, sodass jede Zuweisung aus dem Plattform-Pool innerhalb von „ 10.0.0.0/10 “ bleiben muss und jede Zuweisung aus dem Landing-Zonen-Pool innerhalb von „ 10.64.0.0/10 “ bleiben muss.
Diese Trennung stellt sicher, dass Teams, die in verschiedenen Bereichen arbeiten, unabhängig voneinander Adressraum anfordern können, ohne dass es zu Überschneidungen kommt. In der Praxis bedeutet dies, dass ein Team, das gemeinsame Dienste bereitstellt, sicher neue VNets im Segment „Platform“ erstellen kann, während Anwendungsteams ihre Netzwerke im Segment „Landing Zones“ aufbauen – und das alles ohne manuelle Koordination. Das Ergebnis sind ein vorhersehbares Wachstum, eine einfachere Fehlerbehebung sowie ein zentraler Überblick darüber, wie die einzelnen Segmente des Adressraums über Abonnements und Umgebungen hinweg genutzt werden.
Reservierung externer IP-Bereiche als statische CIDRs
IPAM kann Adressbereiche, die bereits außerhalb der IPAM-Kontrolle genutzt werden, mithilfe statischer CIDR-Zuweisungen innerhalb eines Pools nachverfolgen. Dies ist nützlich für jeden Adressraum, der für IPAM sichtbar sein muss, jedoch nicht direkt von Azure-Ressourcen zugewiesen wird, wie beispielsweise lokale Netzwerke, Virtual-WAN-Hubs, private AWS-Clouds oder Umgebungen von Drittanbietern.
Diese statischen Einträge sind keiner Azure-Ressource zugeordnet; sie dienen als Platzhalter, um die Erfassung der freien und belegten Adressen durch IPAM korrekt zu halten, und diese Adressbereiche werden nicht versehentlich zugewiesen. In der Praxis bedeutet dies, dass Sie den externen CIDR-Bereich innerhalb des entsprechenden Pools „reservieren“ und so verhindern, dass IPAM ihn an ein neues VNet vergibt, während der Bereich weiterhin in den Auslastungsberichten und bei der Kapazitätsplanung berücksichtigt wird.
Integration virtueller Netzwerke: Automatische IP-Zuweisung
Normalerweise erfordert eine Terraform-Anweisung wie „ azurerm_virtual_network “ oder „ azurerm_subnet “ die explizite Angabe von „ address_space “ oder „ address_prefixes “. Mit IPAM können Sie diese Angabe weglassen und Azure einen geeigneten, nicht überlappenden CIDR-Block aus einem Pool zuweisen lassen.
Anstatt einen CIDR-Block wie 10.1.0.0/24 oder 10.2.0.0/24 manuell anzugeben, können Sie das Feld für den Adressbereich leer lassen und IPAM mitteilen, wie viele IP-Adressen Sie benötigen. IPAM wählt dann automatisch einen verfügbaren Bereich aus dem angegebenen Pool aus, der Ihren Anforderungen entspricht.
Dies wird erreicht, indem Sie den Block „ ip_address_pool “ verwenden, um eine automatische Zuweisung durch IPAM anzufordern. Der Parameter „ number_of_ip_addresses “ gibt die von Ihnen benötigte Größe an (beispielsweise 256 Adressen für ein „ /24 “), und IPAM ermittelt einen geeigneten, nicht überlappenden CIDR-Block innerhalb der Grenzen des Pools und weist diesen dem VNet zu.
Beispiel:
data "azurerm_network_manager" "network_manager" {
name = "nw-prod-weu-001"
resource_group_name = "rg-network-manager-prod-we-001"
}
data "azurerm_network_manager_ipam_pool" "ipam_pool" {
name = "ipam-pl-prod-weu-001"
network_manager_id = data.azurerm_network_manager.network_manager.id
}
resource "azurerm_virtual_network" "vnet" {
# ...existing code...
address_space = null
ip_address_pool {
id = data.azurerm_network_manager_ipam_pool.ipam_pool.id
number_of_ip_addresses = 256
}
# ...existing code...
}
resource "azurerm_subnet" "subnets" {
# ...existing code...
address_prefixes = null
ip_address_pool {
id = data.azurerm_network_manager_ipam_pool.ipam_pool.id
number_of_ip_addresses = 64
}
# ...existing code...
}
Zugriffsrechte mit einer benutzerdefinierten IPAM-Rolle delegieren
IPAM unterstützt die rollenbasierte Zugriffskontrolle (RBAC), und standardmäßig stellt Azure eine integrierte Rolle „IPAM-Pool-Benutzer“ bereit. Diese Rolle gewährt umfassende Lese- und Schreibberechtigungen, die in bestimmten Szenarien möglicherweise über Ihren tatsächlichen Bedarf hinausgehen. Wenn Sie Benutzern die Anzeige der IPAM-Pool-Eigenschaften eines virtuellen Netzwerks oder Subnetzes ermöglichen möchten, verfügt die integrierte Rolle über zu viele Berechtigungen.
Leider gibt es keine reine Lesezugriffsrolle. Daher ermöglicht Ihnen eine benutzerdefinierte Rollendefinition, genau den Lesezugriff zu gewähren, der erforderlich ist, um die Poolauslastung über alle Netzwerke hinweg zu überwachen, ohne dass die Gefahr versehentlicher Änderungen besteht.
resource "azurerm_role_definition" "ipam_reader" {
name = "Custom Role IPAM Reader"
scope = data.azurerm_management_group.this.id
permissions {
actions = [
"Microsoft.Network/networkManagers/ipamPools/*/read",
"Microsoft.Network/networkManagers/ipamPools/*/action"
]
not_actions = [
"Microsoft.Network/networkManagers/ipamPools/associateResourcesToPool/action",
"Microsoft.Network/networkManagers/ipamPools/allocateAzureResource/action",
"Microsoft.Network/networkManagers/ipamPools/allocateNonAzureResource/action",
"Microsoft.Network/networkManagers/ipamPools/allocateResourcePrefixes/action",
"Microsoft.Network/networkManagers/ipamPools/disassociateResourcesFromPool/action"
]
data_actions = []
}
}
Diese benutzerdefinierte Rolle gewährt Einblick in Pools und Zuweisungen, verhindert jedoch ausdrücklich, dass Benutzer Ressourcen zuweisen, Netzwerke mit Pools verknüpfen oder den Adressraum ändern. Benutzern, denen diese Rolle zugewiesen wurde, steht es frei, die Eigenschaften von Pools einzusehen, Auslastungskennzahlen zu überprüfen und zu erkennen, welche Netzwerke und Ressourcen welche Präfixe beanspruchen. Damit eignet sich diese Rolle ideal für die schreibgeschützte Kapazitätsplanung und für Audits.
Diese Rollendefinition mag auf den ersten Blick kontraintuitiv erscheinen, da sie eine weit gefasste */action-Berechtigung enthält und anschließend versucht, die riskanten Teile mit not_actions „rückgängig zu machen“.
In einer idealen Welt würden Sie lediglich Folgendes gewähren: .../read zum Lesen von Pool-Eigenschaften und sonst nichts. In der Praxis scheint sich Azure IPAM jedoch nicht wie eine reine „Read-Only = ausschließlich Lesevorgänge“-API-Oberfläche zu verhalten. Mehrere „leseähnliche“ Funktionen (Portal-Blades, Auflistung von Zuweisungen, Durchsuchen von Zuordnungen, einige GET/List-Abläufe) scheinen unter der Haube als Aktionsoperationen implementiert zu sein. Wir gehen davon aus, dass dies in naher Zukunft angepasst wird. Derzeit gehen wir davon aus, dass dieses Problem darauf zurückzuführen ist, dass sich IPAM noch in der Preview-Phase befindet.
Für diese benutzerdefinierte Rolle ist eine Ausnahmegenehmigung für die Zuweisung von Richtlinien wie ISO 27001:2013 und CIS Benchmark erforderlich.
Was Sie vor dem Start beachten sollten
Planen Sie die Hierarchie Ihres IP-Adressraums, bevor Sie Pools anlegen. Bevor Sie mit der Implementierung von IPAM beginnen, sollten Sie die Struktur Ihres IP-Adresspools sorgfältig planen. Berücksichtigen Sie dabei Ihre organisatorischen Grenzen, Teamstrukturen, regionalen Bereitstellungen und das erwartete Wachstum. Eine gut durchdachte Hierarchie verhindert kostspielige Nacharbeiten und stellt sicher, dass die Pools mit der tatsächlichen Art und Weise übereinstimmen, wie Ihr Unternehmen Netzwerke verwaltet und bereitstellt.
Die Zuordnung zu regionalen Pools ist von Bedeutung, da IPAM-Pools regionsspezifisch sind. Bitte beachten Sie, dass IPAM-Pools Adressen nur an virtuelle Netzwerke und Ressourcen in derselben Azure-Region zuweisen können. Das bedeutet: Wenn Sie in mehreren Regionen bereitstellen, müssen Sie in jeder Region parallele Poolstrukturen erstellen. Planen Sie Ihre regionale Bereitstellungsstrategie frühzeitig, um Unklarheiten darüber zu vermeiden, welche Pools welche Regionen verwalten, und um einheitliche Namenskonventionen über alle Regionen hinweg sicherzustellen.
Überwachen Sie die Auslastung mithilfe von IPAM-Ansichten, um den zugewiesenen und den freien Speicherplatz einzusehen. Überprüfen Sie regelmäßig die Auslastung Ihres IPAM-Pools, um zu verstehen, wie der Adressraum genutzt wird, und um festzustellen, welche Ressourcen welche Präfixe belegen. Diese Transparenz hilft Ihnen dabei, fundierte Entscheidungen zur Kapazitätsplanung zu treffen, vorherzusagen, wann Pools möglicherweise zur Neige gehen, und ineffiziente oder verwaisten Zuweisungen zu identifizieren, die zurückgewonnen werden könnten. Richten Sie Überwachungs-Dashboards und Warnmeldungen ein, um Auslastungstrends im Zeitverlauf zu verfolgen.
Bitte beachten Sie die Kosten, da es sich bei AVNM um einen kostenpflichtigen Dienst handelt. Für den Azure Virtual Network Manager fallen Gebühren an; insbesondere bei IPAM richten sich die Kosten nach der Anzahl der aktiven verwalteten IP-Adressen. Berücksichtigen Sie diese Kosten in Ihrem gesamten Cloud-Budget und bei Ihrer Kostenmodellierung, insbesondere bei groß angelegten Bereitstellungen mit Hunderten von virtuellen Netzwerken. Überwachen Sie die Anzahl Ihrer verwalteten IP-Adressen, um Kostentreiber zu erkennen und Ihre Pool-Zuweisungen entsprechend zu optimieren.
Migration zu IPAM Die Migration von statischen Adressbereichen zu IPAM kann in drei Schritten erfolgen. Trennen Sie zunächst alle bestehenden VNets und Subnetze, indem Sie abhängige Ressourcen, Peering-Beziehungen und Netzwerkrichtlinien entfernen; zweitens: Stellen Sie die Verbindung zu IPAM her, indem Sie Ihre Pool-Hierarchie erstellen, externe Bereiche als statische CIDRs reservieren und Ihre „Infrastructure-as-Code“ so aktualisieren, dass sie auf Pools statt auf fest codierte Adressräume verweist; schließlich: Stellen Sie die Verbindung wieder her, indem Sie Netzwerke mit automatischer IPAM-Zuweisung neu bereitstellen, Peering- sowie Hub-and-Spoke-Topologien wiederherstellen und Workloads erneut zuordnen. Obwohl es sich nur um drei Schritte handelt, kann die Migration aller VNets zu IPAM recht aufwendig und zeitintensiv sein. Wenn Sie also von Anfang an mit IPAM beginnen können, lassen sich viele Migrationsaufwände vermeiden.
Fazit
Azure IPAM bietet Struktur, Automatisierung und Governance für einen der fehleranfälligsten Aspekte der Cloud-Netzwerkumgebung: die Verwaltung privater Adressräume in großem Maßstab. Durch die Kombination von Azure Virtual Network Manager mit hierarchischen IP-Pools, statischen CIDR-Reservierungen und der Integration von „Infrastructure as Code“ können Sie sich überschneidende Adressbereiche vermeiden, Netzwerkbereitstellungen vereinfachen und einen klaren Überblick darüber gewinnen, wie der Adressraum über Teams, Umgebungen und Regionen hinweg genutzt wird.
Kurz gesagt: Azure IPAM trägt dazu bei, die manuelle Nachverfolgung durch einen skalierbaren, geregelten und zukunftsfähigen Ansatz für die Verwaltung von Netzwerkadressen zu ersetzen.
Referenzen
Verfasst von
Victor de Baare
Victor de Baare is a developer with a deep passion for building systems that make work more efficient and straightforward. He thrives under pressure, persistently working towards his goals regardless of the challenge. He finds joy in whisky, food, gaming, and board games. He continues to inspire and innovate, making significant contributions to technology and efficiency.
Unsere Ideen
Weitere Blogs
Contact



