Wie Sie eine wartbare und hochverfügbare Azure Landing Zone aufbauen

So entwerfen, erstellen, implementieren und pflegen wir eine Azure Landing Zone für mehrere Regionen. Wir tun dies, während wir die Landing Zone wie eine Plattform als Produkt bereitstellen. In diesem Artikel finden Sie einige Tipps und Tricks, die Ihnen die Einrichtung Ihrer Landing Zone etwas erleichtern.

Was ist eine Azure Landing Zone?

Eine Azure Landing Zone ist eine vorkonfigurierte Umgebung innerhalb von Microsoft Azure, die eine sichere und skalierbare Grundlage für Ihre Cloud-Workloads bietet. Ihre Architektur ist modular und skalierbar, so dass Sie Konfigurationen und Kontrollen konsistent auf Ihre Ressourcen anwenden können. Sie nutzt Abonnements, um Anwendungs- und Plattformressourcen zu isolieren und zu skalieren(Was ist eine Azure Landing Zone?).

Jede Landing Zone, die wir erstellen, basiert auf dem Cloud Adoption Framework (CAF). Microsoft hat das Cloud Adoption Framework entwickelt, um die Cloud-Einführung für Azure-Kunden zu erleichtern. Es hilft dabei, das beste Geschäftsergebnis für die Cloud-Einführung zu erzielen. Das CAF ist eine Sammlung von Best Practices für die Einrichtung von Azure-Infrastrukturen. Es folgt den wichtigsten Designprinzipien in acht Designbereichen, um Anwendungsmigration, Modernisierung und Innovation in großem Maßstab zu ermöglichen.

Es gibt zwei Haupttypen von Landezonen:

1. Plattform Landing Zones: Diese bieten gemeinsame Dienste (wie Identität, Konnektivität und Verwaltung) für Anwendungen in Workload Landing Zones. Zentrale Teams verwalten sie, um die betriebliche Effizienz zu verbessern. Die Plattform Landing Zone wird als Hub bezeichnet
2. Workload Landing Zones: Dies sind Umgebungen, die für die Workloads bereitgestellt werden. Die Workload-Landing-Zone wird als Spoke bezeichnet.

Azure Ressourcenstruktur

Azure bietet vier Ebenen der Verwaltung: Verwaltungsgruppen, Abonnements, Ressourcengruppen und Ressourcen. Das folgende Diagramm zeigt die Beziehung zwischen diesen Ebenen.

Verwaltungsgruppen helfen Ihnen bei der Verwaltung von Zugriff, Richtlinien und Compliance für mehrere Abonnements. Alle Abonnements in einer Verwaltungsgruppe erben automatisch die für die Verwaltungsgruppe geltenden Einstellungen.

Abonnements verknüpfen Benutzerkonten logisch mit den Ressourcen. Unternehmen können Verwaltungsgruppen, Abonnements und Ressourcengruppen verwenden, um Kosten und die von Benutzern, Teams und Projekten erstellten Ressourcen zu verwalten. Jedes Abonnement hat Grenzen oder Quoten für die Anzahl der Ressourcen, die erstellt und verwendet werden können.

Ressourcengruppen sind logische Container, in denen Sie Azure-Ressourcen wie virtuelle Maschinen, Webanwendungen, Datenbanken und Speicherkonten bereitstellen und verwalten können.

Ressourcen sind Instanzen von Diensten, die Sie in einer Ressourcengruppe erstellen können, wie z.B. virtuelle Maschinen, Speicher und SQL-Datenbanken.

Landezone Entwurfsbereich's

Wir haben neun Kernbereiche für die Gestaltung, den Aufbau und die Pflege einer Azure Landing Zone definiert.

• Plattform Landezone / Hub Design
• Infrastruktur als Code
• Zero Trust Architektur
• Multi-Region
• Überwachung
• Alarmierung
• Networking
• Richtlinien und Leitplanken
• Aufzeichnungen zu Architekturentscheidungen (ADR)

Entwurf einer Landezone für Plattformen

Die Platform Landing Zones oder Hub besteht aus drei Teilen (Identität, Konnektivität und Verwaltung) und bietet gemeinsame Dienste für alle Anwendungsworkloads. Die meisten Hub-Ressourcen werden in jeder Region eingesetzt, um sicherzustellen, dass der Ausfall einer Region nicht die gesamte Landing Zone betrifft.

Der Verwaltungsteil des Hubs enthält alle Azure-Ressourcen für die Verwaltung der Azure Landing Zone. So gibt es beispielsweise zentrale Log-Analytics-Arbeitsbereiche für alle zentralen Log-Metriken und (Audit-)Ressourcen. Der Verwaltungsteil enthält auch ein zentrales Automatisierungskonto.

Der Konnektivitätsbereich des Hubs enthält alle Azure-Ressourcen, die für die Konnektivität benötigt werden. Hier befinden sich das virtuelle WAN und alle virtuellen Hubs sowie die Firewalls, die mit diesen Hubs verbunden sind, und natürlich die Express-Route-Schaltungen und die Peer-to-Site- und Site-to-Site-Gateways. Die privaten DNS-Zonen werden ebenfalls in der Konnektivitätskomponente implementiert. Sie sind der wichtigste Teil der Landing Zone und sorgen für die Sicherheit und den Betrieb des Datenverkehrs.

Der Identitätsteil ist der Ort, an dem sich Ihre Entra ID oder Domänencontroller befinden.

Infrastruktur als Code

Infrastructure as Code oder IaC ist eines der Grundprinzipien einer Landing Zone. Wir stellen jede Azure-Ressource mit Infrastructure as Code bereit. Wir tun dies aus den folgenden Gründen:

Ressourcenkonsistenz:
Stellen Sie sich vor, dass Sie fünfzehn Firewall-Regeln in zwei Regionen, Westeuropa (WE) und Nordeuropa (NE), einsetzen. Die manuelle Anwendung dieser Regeln erhöht das Risiko menschlicher Fehler, was zu inkonsistenten Firewall-Konfigurationen zwischen den Regionen führen kann. Die Verwendung von Infrastructure as Code (IaC) stellt sicher, dass die Regeln in beiden Regionen einheitlich eingesetzt werden.

Skalierbarkeit oder einfache Bereitstellung:
Stellen Sie sich die Bereitstellung von fünf virtuellen Maschinen vor. Welcher Ansatz ist skalierbarer und leichter zu verwalten: die manuelle Einrichtung jeder einzelnen VM oder die Verwendung von Infrastructure as Code (IaC) zur Bereitstellung aller fünf? Wir werden uns immer für Letzteres entscheiden. Mit IaC können Sie die VM einmal definieren und mehrfach bereitstellen. Durch die Verwendung von IaC stellen Sie sicher, dass jede Instanz identisch ist, und verringern das Fehlerrisiko.

Versionskontrolle:
Wir legen die IaC-Konfiguration in einem Versionskontrollsystem wie GIT ab. Wir tun dies, um den Überblick über die vorgenommenen Änderungen zu behalten, und auch, um die Arbeit der anderen überprüfen zu können, insbesondere wenn wir etwas in der Produktion einsetzen oder ändern. Die Versionskontrolle ermöglicht es Ihnen auch, Änderungen in einer separaten Umgebung wie der Sandbox zu testen, bevor Sie sie in die Produktion übernehmen. All diese Vorteile erreichen wir durch die Kombination von Versionskontrolle und IaC.

Terraform

Wir bauen fast jede Azure Landing Zone mit Terraform als IaC-Framework auf. Wir werden nicht ins Detail gehen, warum, aber dies sind die Hauptgründe:

• Leicht zu verstehen
• Kann über Cloud-Ressourcen hinaus automatisieren
• Findbare Talente auf dem Markt

Es ist jedoch wichtig zu wissen, dass wir Terraform auf eine sehr eigenwillige Weise verwenden. Zum Beispiel teilen wir den Terraform-Code in Module, Vorlagen und Lösungen auf. Dieser Ansatz stellt sicher, dass jeder Teil der Infrastruktur modular und wiederverwendbar ist. Indem wir Terraform in Module, Vorlagen und Lösungen aufteilen, sorgen wir für eine saubere Trennung der Bereiche, verbessern die Skalierbarkeit und rationalisieren Upgrades.

Module:
Module sind vordefinierte, eigenwillige Ressourcendefinitionen. Ein Beispiel dafür ist eine virtuelle Maschine (VM). Allerdings muss nicht jede Ressourcendefinition ein Modul sein. Wenn Ihr Modul keine sinnvolle Abstraktion oder Meinungsbildung bietet, sollte es nicht existieren. Vermeiden Sie die Erstellung von Thin Wrappern, da sie die Komplexität unnötig erhöhen. Außerdem sollten Module keine anderen Module konsumieren, da eine flache Modulstruktur die Codeverwaltung vereinfacht und die Komplexität von Änderungen verringert.

Was ist ein Thin Wrapper in Terraform? Ein Thin Wrapper ist ein Modul, das wenig bis gar keinen Mehrwert bietet. Es ermöglicht Ihnen, alle Einstellungen als Variablen zu übergeben, ohne eine interne Logik oder Abstraktion hinzuzufügen. Im Grunde genommen umhüllt es eine Ressourcendefinition nur leicht, weshalb es auch als "Thin Wrapper" bezeichnet wird.

Jedes Modul ist ein separates Repository und hat ein Beispiel. Wir verwenden dieses Beispiel, um das Modul zu testen oder als Schnellstart für diejenigen, die es verwenden möchten. Jedes Mal, wenn wir ein Modul erstellen oder aktualisieren, gibt unsere Pipeline eine neue Version frei. Wenn Sie Module in Vorlagen oder Lösungen verwenden, wird eine Versionsnummer angegeben. Diese Nummer entspricht einem der freigegebenen Module. So können wir verwalten und kontrollieren, wann und wie wir die von uns verwendeten Module aktualisieren. Weitere Einzelheiten hierzu finden Sie im Abschnitt über die Bereitstellung auf mehreren Ebenen.

Templates:
Templates sind eine Kombination aus Modulen und Ressourcendefinitionen. Sie stellen häufig verwendete Einsatzmuster dar. Ein Beispiel dafür ist eine virtuelle Maschine mit Backup-Agenten und bei Bedarf noch mehr. Templates sind wie Module. Sie sollten Templates nicht erneut verwenden, damit Codeänderungen einfach bleiben.

Vorlagen sind wie Module in separaten Repositories untergebracht und werden bei der Erstellung oder Änderung versioniert.

Lösungen:
Lösungen stellen einsatzfähige Azure-Ressourcen für ein bestimmtes Projekt dar.

Sie tun dies, indem sie entweder Module oder Vorlagen verwenden oder Ressourcendefinitionen direkt aufrufen.

Wenn Sie diese drei Gruppen kombinieren, entsteht eine Struktur wie in der Abbildung unten. Sie können sehen, dass Module Ressourcendefinitionen verbrauchen. Die Vorlage kann Module und Ressourcendefinitionen verbrauchen. Und schließlich können Lösungen aus Ressourcendefinitionen, Modulen und Vorlagen bestehen.

Terraform Zustand

Terraform verwendet die Statusdatei (terraform.tfstate), um den Überblick über die verwalteten Ressourcen zu behalten. Sie fungiert als Quelle der Wahrheit für die Infrastruktur und speichert Informationen über den aktuellen Zustand der verwalteten Infrastruktur. Die Statusdatei stellt sicher, dass Terraform einen genauen und konsistenten Überblick über die Infrastruktur hat, was für korrekte Aktualisierungen und Änderungen unerlässlich ist. Die Statusdatei hilft Terraform dabei, die Abhängigkeiten von Ressourcen zu verstehen und stellt sicher, dass Ressourcen in der richtigen Reihenfolge erstellt, aktualisiert oder zerstört werden. Bei jedem Einsatz sperrt Terraform die Statusdatei, so dass nur die geplanten Änderungen angewendet werden können und zwei Einsätze zur gleichen Zeit verhindert werden. Die Statusdatei wird dezentral in einem Azure-Storage-Konto gespeichert. Auf diese Weise kann die Statusdatei von allen Teammitgliedern genutzt werden, was kollaborative Arbeitsabläufe ermöglicht.

Die Statusdatei kann jedoch sensible Informationen enthalten (z.B. Ressourcen-IDs, Geheimnisse). Um sie zu schützen, müssen geeignete Sicherheitsmaßnahmen wie Verschlüsselung und eingeschränkter Zugriff auf das Speicherkonto getroffen werden.

{
backend "azurerm" {
container_name = "tfstate"
key = "vm.terraform.tfstate"
resource_group_name = "rg-state-prod-we-001"
storage_account_name = "mystorageaccount"
subscription_id = "12345678-aa99-bb88-55cc-098765432123"
}

required_version = "~> 1.1, <= 1.8.1"

required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "3.92.0"
}
}
}

Zero Trust Architektur

Dieses Prinzip befürwortet einen Sicherheitsansatz, bei dem Dienste innerhalb der Cloud nicht automatisch Benutzern oder anderen Diensten vertrauen, unabhängig von deren Netzwerk oder Standort. Stattdessen wird der Schwerpunkt auf eine kontinuierliche Überprüfung und Authentifizierung gelegt, wobei der Zugriff auf einer Need-to-know-Basis gewährt wird. Unternehmen, die eine Zero Trust-Architektur implementieren, stärken ihre Sicherheitslage, indem sie die Risiken eines unbefugten Zugriffs und einer Datenverletzung wirksam eindämmen. Zu den wichtigsten Aspekten dieses Prinzips gehören:

Kontinuierliche Überprüfung:
Die in der Landing Zone implementierte Zero Trust Architecture stellt sicher, dass jede Zugriffsanfrage kontinuierlich überprüft wird, unabhängig vom Standort oder Netzwerk des Benutzers. Dies umfasst mehrere Authentifizierungs- und Autorisierungsebenen, einschließlich der Überprüfung der Benutzeridentität, der Überprüfung des Gerätezustands und kontextbezogener Informationen wie Standort und Verhaltensmuster.

Least Privilege Access:
Der Zugriff auf Ressourcen innerhalb der Landing Zone erfolgt nach dem Prinzip der geringsten Privilegien. Benutzern werden die minimal notwendigen Privilegien gewährt, um die ihnen zugewiesenen Aufgaben auszuführen, und die Zugriffsrechte werden kontinuierlich bewertet und auf der Grundlage sich ändernder Anforderungen oder Rollen angepasst. Dies minimiert die Angriffsfläche und mindert die potenziellen Auswirkungen kompromittierter Konten.

Mikro-Segmentierung:
Die Landing Zone implementiert Mikro-Segmentierung, um Sicherheitsgrenzen innerhalb der Umgebung zu schaffen. Durch die Unterteilung des Netzwerks in kleinere Segmente, von denen jedes über Zugangskontrollen verfügt, kann der Datenverkehr effektiv kontrolliert und isoliert werden. Dieser Ansatz schränkt die seitlichen Bewegungen im Falle eines Sicherheitsverstoßes ein und reduziert so die Auswirkungen auf das Gesamtsystem.

Management-Gruppen

Für beide Arten von Landing Zones werden mehrere Standard-Verwaltungsgruppen eingerichtet. Die Platform Landing Zone ist unter der Verwaltungsgruppe "Azure Platform Services" verfügbar, und jeder der drei Teile der Landing Zone hat seine eigene Verwaltungsgruppe.

Eine Verwaltungsgruppe "Landing Zone" wird für die Workload-Landing Zone erstellt. Unterhalb dieser Gruppen wird eine Verwaltungsgruppe pro geografischer Region, z. B. "EMEA", eingerichtet. Eine Verwaltungsgruppe pro Azure-Region wird eingesetzt, um maximale Flexibilität zu gewährleisten, z.B. in Westeuropa. Bei Bedarf können Sie pro Azure-Region zwischen Produktion und Nicht-Produktion unterscheiden.

Abonnements

Jeder Teil der Landezone hat sein eigenes Abonnement. Dies gilt sowohl für die drei Teile der Landing Zone der Plattform als auch für die Landing Zone der Workloads. Die Abonnements werden gemäß den Zero-Trust-Prinzipien nicht zwischen Workloads geteilt. Bei einer Landing Zone in mehreren Regionen erhält jede Region ihr eigenes Abonnement zum Hosten des Workloads. Diese Segmentierung hilft auch im Falle einer regionalen Katastrophe. Nur die betroffene Region wird nicht verfügbar sein, nicht die gesamte Landing Zone.

Natürlich gibt es auch globale Ressourcen wie das virtuelle WAN. Globale Ressourcen werden nur einmal bereitgestellt. Für diese Ressourcen sind weiterhin ein Abonnement und eine Ressourcengruppe erforderlich. Zur Bereitstellung wählen Sie einfach das Abonnement Ihrer Wahl, um diese Ressourcen bereitzustellen.

Mehrere Regionen

Wenn Sie eine Landing Zone einrichten, müssen Sie die Anzahl der benötigten Regionen berücksichtigen. Haben Sie eine Anwendung, die eine 24x7-Betriebszeit erfordert? Haben Sie Benutzer rund um den Globus? Gibt es besondere Anforderungen an die Datenspeicherung? Gibt es Vorschriften für Beschwerden? Die Beantwortung dieser Fragen gibt Ihnen mehr Aufschluss darüber, welche Regionen Sie benötigen.

Neben der Anzahl der Regionen ist es auch wichtig, die Ressourcen zu überprüfen, die Sie verwenden möchten. Nicht jede Azure-Region enthält die gleichen Ressourcen. Wählen Sie also eine Region, in der die benötigten Ressourcen verfügbar sind. Und nicht zuletzt sollten Sie sich Gedanken über die Kapazität machen, die Sie benötigen. Eine beliebte Region ist z.B. Westeuropa. Es kann vorkommen, dass aufgrund der hohen Nachfrage die Kapazitäten knapp werden, so dass Sie vielleicht eine weniger beliebte Region wählen können, die ebenfalls Ihren Anforderungen entspricht.

Überwachung

Die Überwachung ist ein wesentlicher Bestandteil der beiden Landezonen. Ohne sie können Sie nicht sehen, was in Ihrer Landschaft vor sich geht. Alle Ressourcen, die wir bereitstellen, erhalten auch Diagnoseeinstellungen. In der Landing Zone für Workloads erhält jeder Workload seinen eigenen Arbeitsbereich für die Protokollanalyse, der zur genauen Überwachung des Workloads verwendet werden kann. Denken Sie daran, dass wir in der Landing Zone mit Isolierung arbeiten, so dass ein gemeinsamer Protokollanalyse-Arbeitsbereich für mehrere Workloads zu Problemen bei der gemeinsamen Nutzung von Daten führen kann.

Jede Region verfügt jedoch über einen Arbeitsbereich für die Protokollanalyse in der Landing Zone der Plattform. Diese Protokollanalyse-Workspaces sind mit Sentinel verbunden, dem SIEM-Tool in Azure, das Bedrohungen und verdächtige Aktivitäten erkennt. Um sicherzustellen, dass wir Sentinel auch für alle Arbeitslasten nutzen können, sind alle Protokollanalyse-Arbeitsbereiche für die Anwendungen mit dem zentralen Arbeitsbereich verbunden. Dadurch kann Sentinel Aktivitäten in der gesamten Landing Zone erkennen. Mehr über Sentinel können Sie hier lesen: Was ist Microsoft Sentinel?

Alarmierung

Alarme sind für die Überwachung unverzichtbar; sie lösen aktiv aus, wenn etwas passiert. Das Erstellen von Alarmen kann viel Arbeit machen. Häufig stellt sich die Frage: "Worauf sollen wir einen Alarm auslösen? Sie können die Azure Monitor Baseline Alerts (AMBA) verwenden, um mit der Implementierung von Alarmen in der Landing Zone zu beginnen. Dieses GitHub-Repository enthält eine Vielzahl von Richtlinien, die Alarme für eine Vielzahl von Ressourcen in Azure auslösen. Sie können es hier finden: Azure Monitor Baseline-Warnungen.

Die AMBA-Richtlinien werden ausgelöst, wenn eine neue Ressource bereitgestellt wird, und es werden automatisch Warnmeldungen erstellt. So erhalten Sie zum Beispiel für jede Express-Routenschaltung Warnungen, um die Abgabe von Paketen zu überwachen. Und wenn Sie diese Warnungen z.B. mit einer Aktionsgruppe verbinden, die eine Nachricht in einem Slack-Kanal oder Teams-Chat postet, haben Sie einen guten Ausgangspunkt. Seien Sie natürlich ein wenig vorsichtig. Die Richtlinien könnten Alarme auslösen, die zu oft ausgelöst und benachrichtigt werden, so dass Sie sie optimieren müssen, bis Sie damit zufrieden sind, wann und wie oft die Alarme ausgelöst werden.

Networking

Hub and Spoke Netzwerkarchitektur

Die Hub-and-Spoke-Netzwerkarchitektur bildet das Rückgrat der Landing Zone und ermöglicht ein strukturiertes und skalierbares Netzwerkdesign. Der Hub der Landing Zone ist ein zentraler Verbindungspunkt sowohl für die Speichen als auch für die entfernten Standorte. In einer Hub-and-Spoke-Architektur wird der gesamte Verkehr, der die Speiche verlässt, über den Hub geleitet. Innerhalb des Hubs wird der gesamte Datenverkehr ständig überwacht und überprüft. Auf diese Weise kann nur vertrauenswürdiger Verkehr die Speiche verlassen und betreten.

Sie können das Modell der Nabe und der Speichen leicht mit einem Flugplatz vergleichen. Die Nabe ist die zentrale Halle, und die Speichen sind die Flugzeuge. Um ein anderes Flugzeug zu besteigen, müssen Sie die zentrale Halle durchqueren, um das andere Flugzeug zu erreichen. Sie können durch den Zoll gehen, müssen aber beim Einsteigen in das andere Flugzeug erneut Ihre Bordkarte vorzeigen.

Die Verwendung eines Hub-and-Spoke-Modells erleichtert die zentrale Verwaltung von Kernressourcen, was auch kosteneffizient ist. Die Verwendung verschiedener Speichen für unterschiedliche Arbeitslasten verbessert die Sicherheit, da jede Speiche über eine eigene Zugriffskontrolle verfügt. Standardmäßig können die Speichen nicht miteinander kommunizieren; wir können dies bei Bedarf zulassen. Und schließlich bleibt Ihre Landing Zone mit diesem Modell skalierbar. Die Architektur kann wachsen, wenn weitere Speichen hinzugefügt werden, um verschiedene Arbeitslasten oder Teams zu unterstützen, ohne die Kernstruktur zu ändern.

Virtuelles WAN

Wenn Sie eine Azure Landing Zone haben, benötigen Sie möglicherweise eine Verbindung zwischen mehreren Regionen und entfernten Standorten. Um die Verbindung zwischen all diesen Ressourcen leichter zu pflegen, können Sie ein virtuelles Wan verwenden. Innerhalb dieses virtuellen Wans müssen Sie virtuelle Hubs erstellen. Es empfiehlt sich, einen virtuellen Hub für die Azure-Region zu erstellen. Jedes in dieser Region erstellte Netzwerk ist mit dem virtuellen Hub verbunden (oder gepeert). Das virtuelle WAN verwendet BGP, um die Routen aller Netzwerke, die mit den virtuellen Hubs verbunden sind, zu fördern. Das virtuelle WAN verwendet diese Routing Intent-Einstellungen, um die Routen an die angeschlossenen virtuellen Netzwerke weiterzuleiten. Da der gesamte Verkehr zwischen den Speichen den Hub durchläuft und alle Netzwerke miteinander verbunden sind, kann der Verkehr problemlos zwischen den Speichen fließen.

Firewall

Firewalls spielen eine entscheidende Rolle bei der Gewährleistung der Netzwerksicherheit in der Landing Zone. Als Teil des Architekturdesigns werden Azure-Firewalls eingesetzt und mit jedem virtuellen Hub verbunden. Dies zentralisiert die Firewall-Funktionen und sorgt für eine konsistente Sicherheitslage in der gesamten Umgebung.

Es wird eine Premium Azure Firewall eingesetzt, die standardmäßig maximale Sicherheitsfunktionen bietet. Dies ermöglicht die Verwendung fortgeschrittener Sicherheitsfunktionen, wie z.B.:

• System zur Erkennung und Verhinderung von Eindringlingen
• TLS-Prüfung
• URL-Filterung

Standardmäßig wird der gesamte Datenverkehr im Rahmen der Zero-Trust-Architektur blockiert. Datenverkehr, der zwischen Workloads fließt, muss zu den Firewall-Richtlinien hinzugefügt werden. Firewall-Regeln werden als Teil der Infrastruktur betrachtet. Änderungen an diesen Firewall-Regeln müssen über Infrastructure as Code und die CI/CD-Pipelines vorgenommen werden. Dieser Ansatz stellt sicher, dass Änderungen an den Firewall-Regeln unter Anwendung des Vier-Augen-Prinzips und der Versionskontrolle genehmigt werden müssen.

Routing

Neben der Netzwerksicherheit wird die Firewall auch als nächster Hop für alle Netzwerke verwendet. Die Teilnetze innerhalb des virtuellen Netzwerks verfügen alle über eine Routing-Tabelle. Die Standardregel in dieser Routing-Tabelle lautet, dass der gesamte Datenverkehr an die Firewall weitergeleitet wird. Auf diese Weise durchläuft der Datenverkehr den virtuellen Hub und damit das virtuelle WAN.

Private Endpunkte

Private Endpunkte in Azure sind eine Netzwerkschnittstelle, die Sie privat und sicher mit einem von Azure Private Link betriebenen Dienst verbindet. Private Endpunkte verwenden eine private IP-Adresse aus Ihrem virtuellen Netzwerk (VNet), wodurch der Dienst effektiv in Ihr VNet eingebunden wird. So können Sie auf den Dienst zugreifen, ohne ihn dem öffentlichen Internet auszusetzen. Der Datenverkehr nutzt nicht das Microsoft-Backbone oder das öffentliche Internet, um sich zu verbinden, wodurch die Latenzzeit verringert und die Netzwerksicherheit verbessert wird.

DNS

Ein entscheidender Teil des Routings des gesamten Datenverkehrs zwischen den Workloads ist DNS. In Azure können Sie die Azure Private DNS-Zonen verwenden, um Ihr DNS einzurichten. Wir haben bereits erwähnt, dass die Firewall nicht nur sicherheitsrelevant ist; sie kann auch als DNS-Proxy verwendet werden. Damit die Firewall als DNS-Proxy fungieren kann, müssen die DNS-Server für alle virtuellen Netzwerke auf die (private) IP-Adresse der regionalen Firewall eingestellt werden, und Sie müssen die DNS-Einstellungen und den DNS-Proxy innerhalb der Firewall-Richtlinie aktivieren.

Private DNS-Zonen

Alle privaten DNS-Zonen werden im Konnektivitätsbereich des Hubs bereitgestellt. Diese DNS-Zonen müssen für alle Workloads in der Landing Zone global verfügbar sein. Alle erstellten privaten Endpunkte müssen über eine DNS-Konfiguration verfügen, die sie mit der privaten DNS-Zone verbindet. Damit dies funktioniert, wird eine Richtlinieninitiative eingesetzt. Diese Initiative überwacht die Bereitstellung privater Endpunkte und fügt die DNS-Konfiguration der richtigen privaten DNS-Zone hinzu.

resource "azurerm_management_group_policy_assignment" "deploy_private_dns_zones" {
name = "deploy_private_dns_zones"
display_name = "Configure Azure PaaS services to use private DNS zones"
policy_definition_id = "/providers/Microsoft.Management/managementGroups/XebiaRoot/providers/Microsoft.Authorization/policySetDefinitions/Deploy-Private-DNS-Zones"
management_group_id = azurerm_management_group.this.id
# Both location and identity are needed for resource changes when the policy contains "modify" or "deployIfNotExists" effects.
location = var.policy_location
identity {
type = "UserAssigned"
identity_ids = [
azurerm_user_assigned_identity.policy_assignment.id
]
}
parameters = <<PARAMETERS
{
# var.central_dns_zone contains the subscription id and the resource group name
"azureFilePrivateDnsZoneId" : {
"value": "/subscriptions/${split("/", var.central_dns_zones)[0]}/resourceGroups/${split("/", var.central_dns_zones)[1]}/providers/Microsoft.Network/privateDnsZones/privatelink.afs.azure.net"
},

... <long list="" of="" dns="" parameters=""> ..</long>

}
PARAMETERS
}

DNS-Weiterleitungsregeln

Standardmäßig verwendet die DNS-Einstellung in der Firewall-Richtlinie Azure DNS zur Auflösung der Adressen. Es besteht die Möglichkeit, einen eigenen DNS-Server bereitzustellen, wenn Azure DNS nicht ausreicht. Eine Möglichkeit, dies zu tun, ist das Hinzufügen privater DNS-Resolver. Ein privater DNS-Resolver hat einen eingehenden Endpunkt mit einer IP-Adresse; diese Adresse muss der benutzerdefinierte DNS-Proxy-Forwarder auf der Firewall sein. Wenn Sie zum Beispiel einen benutzerdefinierten Domänencontroller für eine bestimmte Domäne haben, müssen Sie dem DNS-Resolver auch einen Regelsatz hinzufügen. Der Datenverkehr wird an die definierte Adresse weitergeleitet, wenn die Regel mit dem angeforderten DNS übereinstimmt.

Richtlinien oder Leitplanken

Richtlinien oder Leitplanken werden in den Bereitstellungsprozess integriert, um Compliance und Governance sicherzustellen. Diese Leitplanken werden anhand von vordefinierten Regeln und Richtlinien überprüft, um sicherzustellen, dass die bereitgestellte Infrastruktur und die Workloads mit den Sicherheits-, Compliance- und Governance-Anforderungen übereinstimmen.

Azure bietet eine Reihe von Richtlinieninitiativen, wie ISO 27001/27002, CIS (Center for Information Security) und NIST. Zusätzlich zu den Standardrichtlinien können benutzerdefinierte Richtlinien wie die Security Frameworks zu den Richtlinien in der Landing Zone hinzugefügt werden.

Die Richtlinien werden für die entsprechenden Verwaltungsgruppen festgelegt, um sicherzustellen, dass die Richtlinien für alle Verwaltungsgruppen und Abonnements (Speichen und ihre Ressourcen) aktiv sind.

Alle Ressourcen müssen dem Leitplankenansatz folgen, der ihnen innerhalb definierter Grenzen ein gewisses Maß an Freiheit gewährt. Dieser Ansatz schafft ein Gleichgewicht zwischen Flexibilität und Konformität, indem er Leitplanken in Form von Richtlinien und Vorgaben festlegt. Diese Leitplanken halten die Landing Zones in Schach und sorgen dafür, dass die Umgebungen angepasst werden können, ohne die festgelegten Richtlinien zu verletzen.

Richtlinien werden als Code mit Json geschrieben und mit Terraform bereitgestellt, was Versionskontrolle und automatisierte Bereitstellung durch CI/CD-Pipelines ermöglicht. Dieser Ansatz vereinfacht die Aktualisierung von Richtlinien und sorgt für Konsistenz in den Landing Zones. Da wir Richtlinien als Code behandeln, können wir sie leicht verwalten, aktualisieren und durchsetzen.

{
"name": "DenyCreationTagWithCertainValues",
"managementGroupId": null,
"properties": {
"displayName": "Custom - Allow resource creation if tag value in allowed values",
"policyType": "Custom",
"mode": "All",
"description": "Allows resource creation if the tag is set to one of the following values.",
"metadata": {
"version": "1.1.0",
"category": "Xebia Custom - General"
},
"parameters": {
"tagName": {
"type": "String",
"metadata": {
"displayName": "Tag Name",
"description": "Name of the tag, such as 'Environment'"
}
},
"tagValues": {
"type": "Array",
"metadata": {
"displayName": "Tag Values",
"description": "Values of the tag, such as 'PROD', 'TEST', 'QA', etc."
}
}
},
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Resources/subscriptions/resourceGroups"
},
{
"not": {
"field": "[concat('tags[', parameters('tagName'), ']')]",
"in": "[parameters('tagValues')]"
}
}
]
},
"then": {
"effect": "Deny"
}
}
}
}

Unternehmensskala

Wenn Sie eine Landezone bauen, wollen Sie das Rad nicht neu erfinden. Dies gilt auch für viele "Best Practice"-Richtlinien. Das Azure-Team unterhält ein Repository mit allen Best Practices für die Landing Zone eines Unternehmens. Neben allen möglichen Beispielen für den Einsatz der Landing Zone enthält es auch eine Menge Richtliniendefinitionen und Richtlinieninitiativen. Sie können sie hier finden: Enterprise-Scale

Zuweisungen

Wie bereits erwähnt, werden Richtlinien einer Verwaltungsgruppe zugewiesen. Viele Richtliniendefinitionen oder Initiativen enthalten Eingabevariablen. Diese Variablen können verwendet werden, um die Richtlinie nach Ihren Wünschen zu optimieren und abzustimmen. Sie könnten zum Beispiel die "Wirkung" einer Richtlinie auf "Prüfen" statt auf "Verweigern" setzen. Dadurch wird immer noch angezeigt, wenn Ressourcen nicht konform sind, aber eine Bereitstellung wird nicht blockiert. Es gibt viele Parameter, die Sie einstellen können, also verwenden Sie sie mit Bedacht.

resource "azurerm_management_group_policy_assignment" "inherittagvalues" {
name = "inherittagvalues"
display_name = "Xebia - Configure - Inherit Tagging Values"
policy_definition_id = "/providers/Microsoft.Management/managementGroups/XebiaRoot/providers/Microsoft.Authorization/policySetDefinitions/InheritTaggingFromResourceGroup"
management_group_id = azurerm_management_group.this.id
# Both location and identity are needed for resource changes when the policy contains "modify" or "deployIfNotExists" effects.
# for this assignment location does not matter it will only inherit the tags from the resource group
location = var.policy_location
identity {
type = "UserAssigned"
identity_ids = [
azurerm_user_assigned_identity.policy_identity.id
]
}
}

Ausnahmeregelungen

Manchmal ist es nicht möglich, die Ressourcen richtlinienkonform zu machen. Falls erforderlich, können Sie bestimmte Richtlinien für bestimmte Ressourcen, Ressourcengruppen, Abonnements und Ereignisverwaltungsgruppen ausnehmen. Ausnahmen sind eine Möglichkeit, Richtlinien auszuschließen und sicherzustellen, dass nur relevante Richtlinien gemeldet werden.

# Exemption Network Watchers resource location matches resource group location on connectivity subscription
resource "azurerm_resource_group_policy_exemption" "exemption_nww_location" {
name = "exemption_nww_location"
resource_group_id = azurerm_resource_group.network_watcher.id
policy_assignment_id = "/providers/Microsoft.Management/managementGroups/123456-7890-0987-1234-123456789098/providers/Microsoft.Authorization/policyAssignments/LocationMatch"
exemption_category = "Mitigated"
}

Aufzeichnungen zu Architekturentscheidungen (ADR)

Dies ist ein kleiner Seitenschritt zu den Landezonen, aber es ist ein wichtiges Konzept, das beim Bau einer Landezone oder eines anderen Produkts nützlich ist. Ein Architectural Decision Record (ADR) ist ein Dokument, in dem eine wesentliche architektonische Entscheidung zusammen mit ihrem Kontext und ihren Konsequenzen festgehalten wird. Es ist eine Möglichkeit, die Gründe für Entscheidungen zu dokumentieren und sicherzustellen, dass die Argumentation für zukünftige Referenzen erhalten bleibt. Dies kann besonders nützlich sein, wenn Entscheidungen revidiert werden oder wenn neue Teammitglieder verstehen müssen, warum bestimmte Entscheidungen getroffen wurden.

ADR besteht aus:

• Titel: Ein kurzer, beschreibender Name für die Entscheidung.
• Kontext: Hintergrundinformationen und die Problemstellung, die zu der Entscheidung geführt hat.
• Entscheidung: Die tatsächliche Entscheidung, die getroffen wurde.
• Konsequenzen: Die positiven und negativen Folgen der Entscheidung.
• Status: Der aktuelle Status der Entscheidung (z.B. vorgeschlagen, akzeptiert, veraltet).

Stellen Sie sicher, dass Sie die ADRs an einem zentralen Ort aufbewahren, damit jeder sie lesen und verstehen kann, warum bestimmte Entscheidungen getroffen wurden. Eine ADR ist nicht etwas, das niemals geändert werden kann; sie ist nur eine Möglichkeit, das Warum zu verstehen.

# ADR 1: Use PostgreSQL for the Database

## Context
Our application needs a robust, scalable, and open-source database solution.

## Decision
We will use PostgreSQL as our primary database.

## Consequences
- Positive:
- PostgreSQL is highly reliable and has strong community support.
- It supports advanced features like JSONB, which can be useful for our application.
- Negative:
- Team members need to get familiar with PostgreSQL-specific features and configurations.

Deployment

Workload Landing Zone Einsatz

Was passiert also, wenn ein Workload-Team ein Abonnement benötigt? Wäre es klug, ihnen manuell ein Abonnement zu geben und sie herausfinden zu lassen, wie man es richtig einrichtet? Wahrscheinlich nicht. Wenn Sie einem Workload-Team beim Start helfen möchten, sollten Sie ihm besser den Einstieg in Azure erleichtern. Das hilft nicht nur dem Team, sondern auch Ihnen, um sicherzustellen, dass alles konform und verbunden ist, wenn das Team das Abonnement erhält.

Standardmäßig wird also für jedes neue Abonnement, das mit dem Virtual Hub verbunden ist, ein virtuelles Netzwerk mit den korrekten Routentabellen auf den beiden von uns erstellten Subnetzen eingerichtet. Das virtuelle Netzwerk verfügt auch über die richtigen DNS-Einstellungen. Auf diese Weise wird sichergestellt, dass die Verbindung hergestellt ist und bereits funktioniert. Ich kann Ihre Gedanken nachvollziehen, aber was ist, wenn ich mehr Subnetze benötige? Es steht Ihnen frei, die Netzwerkgröße anzugeben und bei Bedarf weitere Subnetze hinzuzufügen.

Neben dem virtuellen Netzwerk stellen wir einen Key Vault, ein Speicherkonto, einen Log Analytics-Arbeitsbereich und eine Standardbenachrichtigung zur Verfügung. Alle Ressourcen sind standardmäßig konform und werden mit IaC bereitgestellt. Die Ressourcen, Abonnements und Verwaltungsgruppen werden mit IaC bereitgestellt. Bei Bedarf können wir sogar Ausnahmeregelungen für Ressourcen einrichten. Alle diese Ressourcen sind das, was wir als "Spoke Canvas" bezeichnen.

Jetzt haben wir also eine Verwaltungsgruppe, ein Abonnement und Ressourcen, aber wir brauchen noch eine weitere Sache: Berechtigungen. Mit unserer Zero-Trust-Einrichtung verwenden wir die geringsten Berechtigungen für alle. Um dies zu erreichen, erhält das Team eine Gruppe "Leser" und eine Gruppe "Eigentümer". Die Gruppe "Leser" enthält alle Mitglieder des Teams. Die Eigentümergruppe enthält standardmäßig keine Mitglieder. Wenn ein Vorfall eintritt, werden manchmal mehr Berechtigungen benötigt. Privileged Identity Management (PIM) kann Ihnen dabei helfen. PIM bietet Ihnen die Möglichkeit, für einen kurzen Zeitraum erhöhte Berechtigungen zu erhalten. Die "neueste" Einrichtung ist die Verwendung von Gruppen. In unserem Fall können Sie, wenn Sie Mitglied der Lesergruppe sind, in die Eigentümergruppe "pinnen", um Ihre temporären Berechtigungen zu erhalten. PIM erfordert einen Grund und eine (dringend empfohlene) Genehmigung, um aktiv zu werden.

Was ist eine Arbeitslast? Ein Workload ist im Allgemeinen definiert als eine Anwendung oder ein Wertstrom.

Mehrschichtiger Einsatz

Wie bereits beschrieben, geben wir eine neue Version eines Moduls oder einer Vorlage frei, wenn wir den Code darin ändern. Diese Versionen werden dann entweder von Vorlagen oder Lösungen verwendet. Wir verwenden die semantische Versionierung. Dieses Schema verwendet drei durch einen Punkt getrennte Zahlen - MAJOR, MINOR und PATCH. Damit wird der Grund für die Änderungen mitgeteilt, z.B. 2.1.3.

Damit wollen wir verhindern, dass Module/Vorlagen im großen Stil aktualisiert werden. Nehmen wir ein Beispiel: Wir haben eine Vorlage namens Windows Virtual Machine. Leider müssen wir in der nächsten Version eine grundlegende Änderung vornehmen. Ohne Versionierung würden alle Lösungen, die diese Vorlage verwenden, automatisch die neue Version verwenden. Dies würde zu einer unterbrochenen Pipeline führen, da wir eine bahnbrechende Änderung eingeführt haben. Mit versionierten Vorlagen und Modulen können wir jedoch steuern, wann ein Upgrade durchgeführt werden soll. Wenn eine wichtige Änderung auftritt, können wir den Code ändern, bevor wir die neueste Version auswählen.

Dieses Konzept führt jedoch zu einem gewissen Overhead. Wenn 30 Vorlagen und 100 Lösungen auf ein einziges Modul angewiesen sind, müssen wir Versionsänderungen in 130 Repositories aktualisieren und zusammenführen. Glücklicherweise können wir uns eine effektive Methode aus der Softwareentwicklung ausleihen, die automatische Aktualisierung von Abhängigkeiten. Dieses Tool durchsucht Ihre Repositories, um zu prüfen, ob eine Abhängigkeit (z.B. ein Terraform-Modul) auf dem neuesten Stand ist. Ist dies nicht der Fall, erzeugt es automatisch eine Pull-Anfrage mit der notwendigen Versionsänderung. Theoretisch könnten wir mit automatisierten Tests Patch-Updates und möglicherweise sogar kleinere Versionsänderungen vollständig automatisieren.

Wenn Sie Terraform oder eine andere Sprache zur Bereitstellung Ihrer Infrastruktur verwenden, wünschen Sie sich schnelle und kleine Bereitstellungen. Als wir die Landing Zone eingeführt haben, haben wir auch die drei Teile (Konnektivität, Verwaltung und Identität) vorgestellt. Stellen Sie sich vor, Sie haben eine Pipeline, mit der Sie alle Teile in einem Rutsch bereitstellen können. Das mag für eine einzelne Region in Ordnung sein, aber was würde passieren, wenn Sie acht Regionen hätten? Wollen Sie alle acht Bereiche gemeinsam bereitstellen? Die Antwort auf diese Frage lautet wahrscheinlich "Nein".

Das Konzept der mehrschichtigen Bereitstellung hilft uns hier weiter. Bei einer mehrschichtigen Bereitstellung unterteilen Sie Ihre Bereitstellung in kleinere Teile, die wir Schichten nennen. In diesem Fall unterteilen wir die Landing Zone in fünf Teile: Baseline, Konnektivität, Verwaltung, Identität und Diagnose. In der Baseline werden einige Basisressourcen bereitgestellt, die wir für die Einrichtung der anderen Teile der Landing Zone benötigen, z. B. die DNS-Zonen. In der Verbindungs-, Verwaltungs- und Identitätsschicht werden alle erforderlichen Ressourcen für diese Teile der Landing Zone bereitgestellt. In der Diagnoseschicht werden alle Diagnoseeinstellungen für die Ressourcen bereitgestellt.

Diese Schicht kann für jede Region separat bereitgestellt werden. Statt einer großen Bereitstellung haben wir jetzt also acht mal fünf, also vierzig kleine Bereitstellungen. Ich höre Sie schon denken: Wo ist da der Unterschied? Ich muss immer noch darauf warten, dass die gesamte Pipeline fertiggestellt wird. Und wenn wir es dabei belassen, dann haben Sie recht.

Glücklicherweise können wir, da wir die Ebenen erstellt haben, etwas Gescheites mit diesen Ebenen machen. Wir nennen das eine Matrix-Bereitstellung. Bei einer Matrix-Bereitstellung führen Sie nur die Ebenen aus, die geändert wurden. Um die Änderung zu erkennen, müssen Sie ein Skript erstellen, das die Änderungen für die neue Bereitstellung findet.
Wenn Sie IaC verwenden, benötigen Sie auch Git als Versionskontrollwerkzeug. Git verfügt über viele leistungsstarke und praktische Funktionen, von denen eine es Ihnen ermöglicht, die geänderten Dateien zu erhalten. Wenn sich also eine Datei in der Identitätsbereitstellung ändert, können wir auf der Grundlage dieser Änderung nur die Identitätsschichten ausführen, was unsere Bereitstellung wesentlich einfacher macht.

Lassen Sie uns nun einen Blick auf unsere acht Umgebungen werfen. Wenn sich in Westeuropa etwas ändert, wollen Sie dann auch alle anderen sieben Umgebungen ausführen? Wenn wir unsere mehrschichtige Bereitstellung mit den Umgebungen, die wir haben, kombinieren und beide in eine Matrix-Bereitstellung packen, werden wir am Ende nur Westeuropa oder nur Nordeuropa ausführen, weil wir dort etwas geändert haben. Auf diese Weise sparen wir bei der Bereitstellung der Landing Zones eine Menge Zeit.

Innersource

Microsoft Azure verfügt über viele verschiedene Dienste, so dass nicht alle Bausteine verfügbar sein werden. Um sicherzustellen, dass die Teams unterstützt werden, wird das Prinzip von Innersource angewendet. Wenn kein Baustein verfügbar ist oder vorhandene Bausteine aktualisiert werden müssen, können Teams Terraform-Vorlagen und -Module im Repository des Plattformteams ändern oder hinzufügen. Das Plattformteam prüft, ob die geänderten oder hinzugefügten Vorlagen für alle Richtlinien gelten (Vier-Augen-Prinzip) und genehmigt die Merge-Anfrage. Nach der Genehmigung der Änderungen wird eine neue Version der Vorlage freigegeben. So hat das Plattformteam die vollständige Kontrolle über die Bausteine, ohne selbst alles ändern zu müssen.

Agenten oder Läufer

Wenn Sie IaC verwenden, benötigen Sie schließlich einige Tools, um den Code auf Azure bereitzustellen. Die Waffen der Wahl sind GitHub oder Azure DevOps. Beide verwenden Agenten/Läufer, um das IaC auszuführen und Ihre Ressourcen in Azure bereitzustellen. Bei den Agenten oder Läufern handelt es sich in der Regel um virtuelle Maschinen, die in Azure gehostet werden. Und das bringt uns zu einem spannenden Teil. Sie benötigen ein Abonnement, um Ihre Agenten auf einer virtuellen Maschine zu hosten, aber um Ihren Code bereitzustellen, benötigen Sie einen Agenten. Dieses Henne-Ei-Problem lässt sich lösen, indem Sie zunächst das Abonnement von Hand und die virtuelle Maschine von Ihrem lokalen Laptop aus mit Terraform erstellen.

Hinweis: Nach jeder Bereitstellung werden die Agenten/Läufer gesäubert, um sicherzustellen, dass kein Code auf dem Agenten "zurückbleibt", der sensible Informationen enthält. Dies steht auch im Einklang mit den Zero-Trust-Prinzipien der Landing Zone

Es gibt noch eine Sache, an die Sie denken müssen. Der Ort, an dem Sie Ihre Läufer einsetzen. Sollen sie sich außerhalb oder innerhalb der Landezone befinden? Wenn Sie sie außerhalb der Landing Zone einsetzen, können Sie die Ressourcen bereitstellen, aber wenn Sie einen Speichercontainer innerhalb eines Speicherkontos oder ein Geheimnis im Schlüsseltresor benötigen, wird es nicht so einfach sein. Denken Sie daran, dass die Firewall die Landing Zone abschließt, private Verbindungen verwendet und Netzwerke isoliert. Wenn Sie sie jedoch innerhalb der Landing Zone einsetzen und sie Teil des Netzwerks werden, ist dieses Problem gelöst. Wenn Sie jedoch mehrere Landing Zones erstellen können, z.B. eine Sandbox zum Herumspielen, eine nicht produktive Landing Zone zum Testen und eine produktive Landing Zone, benötigen Sie auch Agenten in jeder Landing Zone. Wenn Sie nur einen Agenten in der Produktionslandezone haben, kann dieser keine Verbindung zur Sandbox-Landezone herstellen und umgekehrt.

Am Ende hatten wir Agenten innerhalb und außerhalb der Landing Zone, um sicherzustellen, dass wir alles tun konnten, was wir brauchten. Denken Sie daran, dass Sie auch Ihre Arbeitsabläufe in GitHub und Pipelines in Azure DevOps einrichten müssen, damit Azure DevOps weiß, welcher Agent zu verwenden ist. Das kann ein unterschiedlicher Agent für Sandbox, Produktion und Produktion sein.

Fazit

Eine neue Azure Landing Zone von Grund auf zu erstellen ist eine Menge Arbeit. Es kann schwierig sein, herauszufinden, wo man anfangen soll und wie man die Einrichtung vornimmt. Der wichtigste Schritt besteht darin, zu bestimmen, was Sie brauchen. Die folgenden Schritte dienen dazu, die Landing Zone langsam aufzubauen. Tun Sie es in kleinen Schritten, denn das Einzige, was Sie von einem großen Knall haben, ist ein großer Knall. In diesen kleinen Schritten können Sie vielleicht eine Ressource nach der anderen einsetzen. Es wird viel einfacher sein, mit diesen Änderungen umzugehen und sie jederzeit anzupassen. Und glauben Sie uns, Sie werden es nicht beim ersten Mal richtig machen; es wird immer etwas geben, das nicht wie erwartet funktioniert. Sie werden auch feststellen, dass Sie mit dem Bau einer Landezone nie wirklich 'fertig' sind. Es wird immer Bedarf für Verbesserungen geben.

Dieser Artikel soll Ihnen dabei helfen, Ihre Landing Zone einzurichten und Ihnen einen Einblick geben, wie wir es gemacht haben.

Viel Spaß beim Bauen!

Dieser Artikel ist Teil von XPRT.#17. Laden Sie das Magazin hier herunter.