Infrastructure as Code (IaC)
Ein entscheidender Faktor für eine erfolgreiche Cloud-Transformation
Der Ansatz "Infrastructure as Code" (kurz: IaC) hat den Umgang mit Cloud-Ressourcen im Zuge der Automatisierung über die letzten Jahre revolutioniert – Eigentlich! Doch in zahlreichen Kundenprojekten konnten wir feststellen, dass Unternehmen für die Verwaltung ihrer Cloud-Infrastruktur immer noch weitestgehend auf die Weboberfläche des jeweiligen Cloud-Anbieters zurückgreifen und die Umgebung regelrecht "zusammenklicken".
Doch mit wachsender Cloud-Nutzung, Komplexität sowie Skalierung der Umgebung stößt dieser manuelle Ansatz der Ressourcen-Verwaltung rasch an seine Grenzen. Was der Ansatz von IaC in Bezug auf die Cloud als Paradigmenwechsel beinhaltet, welche Herausforderungen von Unternehmen dabei zu bewältigen sind und warum es Sinn macht, insbesondere in der frühen Phase der Cloud-Transformation, einen hohen Grad der Automatisierung zu verfolgen, beschreiben die nachfolgenden Kapitel.
Paradigmenwechsel in der Cloud-Infrastruktur – Vom Click zum Code
Über die letzten Jahrzehnte wurde die IT-Infrastruktur von Unternehmen, insbesondere in den lokalen (On-premises-)Umgebungen im eigenen Rechenzentrum, in den größten Teilen manuell verwaltet. Das bedeutet, dass die Infrastrukturverantwortlichen Personen im Falle einer Änderung ein IT-Ticket erstellten und die Administratoren daraufhin die gewünschte Änderung per Klick in Verwaltungsportalen umsetzten. Das Betriebssystem wurde manuell auf virtuellen Maschinen (VMs) oder per Image installiert, Netzwerkkonfigurationen und Änderungen über grafische Interfaces oder Kommandozeile und Skripte wie PowerShell und Bash vorgenommen. Firewalls, Load Balancer oder Storage-Systeme wurden einzeln konfiguriert, meist ohne zentral dokumentierte Prozesse. Jede Änderung barg das Risiko von Inkonsistenzen, war fehleranfällig, schlecht dokumentiert und oft nur unzureichend reproduzierbar. Oftmals gab es nur wenige Leute im Unternehmen, welche genau diese Tätigkeiten durchführen konnten, was zu einer Verzögerung in der Bereitstellung führte oder im Falle von Krankheit oder eines Arbeitgeberwechsel ein großes Loch hinterlassen hat. Dies führte dazu, dass viele Prozesse zur Verwaltung der IT-Infrastruktur häufig sehr fragmentiert, skriptspezifisch und schwer wartbar waren. Diese manuelle Herangehensweise war Langezeit für diese "statische" IT-Infrastruktur der Unternehmen praktikabel, solange sie selten geändert wurde, Ressourcen monatelang bis jahrelang existierten (z. B. Virtuelle Maschinen) und das Deployment in noch vertretbarem Maßstab erfolgte [1].
Mit dem Wechsel von Unternehmen in die Cloud änderten sich in den IT-Abteilungen zwar die Werkzeuge, nicht aber zwangsläufig die Methoden der Infrastrukturverwaltung. Die webbasierten Portale der Public-Cloud-Anbieter wie Microsoft Azure, Amazon Web Services (AWS) oder Google Cloud Platform (GCP) luden Administratoren förmlich dazu ein, Ressourcen schnell und bequem über grafische Oberflächen bereitzustellen. Doch mit der Bequemlichkeit kamen alte bzw. bekannte Probleme zurück. Ressourcen wurden individuell bzw. einzeln angelegt, Konfigurationen unterschieden sich – auch wenn nur geringfügig, Dokumentation fehlte und die Nachvollziehbarkeit, was genau getan wurde und warum, litt. In wachsender Cloud-Infrastruktur wurde es zunehmend schwieriger, den Überblick zu behalten und Konsistenz sicherzustellen. Dieses Phänomen wird auch – manchmal etwas abschätzig – als "ClickOps"bezeichnet.
Der Ansatz von IaC ist weit mehr als nur ein technologischer Fortschritt oder ein reines Werkzeug.
Die Art und Weise, wie Cloud-Ressourcen in Unternehmen bereitgestellt und verwaltet werden, hat sich grundlegend gewandelt und einen regelrechten Paradigmenwechsel vollzogen – weg von manuellen ClickOps-Prozessen hin zu repetitiven, versionierbaren und automatisierten Abläufen. Cloud-Infrastrukturen unterscheiden sich grundlegend von klassischen On-premises-Rechenzentren. Ressourcen werden über standardisierte und durchgängige Schnittstellen wie beispielsweise Azure REST API bereitgestellt. Dadurch entfällt die Notwendigkeit, unterschiedliche Hersteller-APIs zu integrieren oder proprietäre Schnittstellen zu berücksichtigen. Cloud-Ressourcen sind zudem typischerweise kurzlebig – sie existieren oft nur für Stunden, Tage oder wenige Wochen. Dadurch können die Ressourcen in der Cloud "dynamisch" skaliert werden, etwa zur Lastverteilung bei Bedarfsspitzen einer Applikation oder zur Kostensenkung. Der manuelle Verwaltungsaufwand wächst jedoch exponentiell mit der steigenden Anzahl der Ressourcen, Komplexität der IT-Landschaft sowie der Dynamik von Änderungen und wird schnell unbeherrschbar [2].
Genau an dieser Stelle kommt der Ansatz von "Infrastructure as Code" ins Spiel. Die einst manuellen Tätigkeiten werden nun in Code übersetzt, der die gewünschte Cloud-Infrastruktur vollständig beschreibt. Dieser Code ist versionierbar und wird automatisiert per CI/CD-Pipeline ausgerollt. So lassen sich beliebig viele Cloud-Ressourcen konsistent, wiederholend sowie fehlerfrei entlang ihres Lebenszyklus verwalten. Der Ansatz von IaC ist weit mehr als nur ein technologischer Fortschritt oder ein reines Werkzeug. Er steht sinnbildlich für einen grundlegenden Wandel im Umgang mit IT-Infrastruktur, weg von manuellen Einzelkonfigurationen, hin zu einem systematischen, skalierbaren und standardisierten Vorgehen. In der Praxis bedeutet das nicht nur eine neue Arbeitsweise und ein grundsätzliches Umdenken für das Operations-Team in einem Unternehmen, sondern auch eine engere Verzahnung und Zusammenarbeit mit der Softwareentwicklung – ganz im Sinne von DevOps [3]. Infrastrukturanpassungen werden nicht mehr ad-hoc über die Weboberfläche einer Cloud-Plattform vorgenommen, sondern gezielt über Pull Requests, automatisierte Tests und Pipelines gesteuert. Allerdings ist der Weg dorthin nicht ganz ohne Hürden und je nach technischer Affinität und Vorkenntnissen der IT-Mitarbeiter mit vielen Herausforderungen für die Teams gepflastert. Doch wer heute moderne Cloud-Infrastrukturen effizient, sicher und nachvollziehbar im Enterprise-Umfeld betreiben möchte, kommt an IaC nicht vorbei. Mehr noch – dieser Ansatz ist die Grundlage für eine moderne, agile und zukunftsfähige IT eines Unternehmens im Hinblick auf die gestiegenen Anforderungen durch die Cloud-Transformation.
Was ist "Infrastructure as Code" (IaC)?
Im Kern bedeutet Infrastructure as Code nichts anderes, als dass die gesamte IT-Infrastruktur vom Fundament bis zur Spitze wie ein großes, versionierbares Softwareprojekt behandelt wird. Dies wird auch als "End-to-end"-Automation bezeichnet. Für klassische Systemadministratoren mag dieser Ansatz zunächst ungewohnt oder sogar abschreckend wirken, schließlich verstehen sich viele nicht als "typische" Softwareentwickler. Jedoch ist diese Sorge meist unbegründet, denn wer durch operative Administrationstätigkeiten bereits mit PowerShell, Bash oder anderen Skriptsprachen vertraut ist, wird sich auch in der Welt von IaC schnell zurechtfinden. Die Konzepte sind klar strukturiert, Werkzeuge gut dokumentiert und der Einstieg fällt durch die zahlreich verfügbaren Beispiele leichter, als es zunächst den Anschein hat. Statt also Bedenken zu haben, müssen die IT-Teams die Chancen erkennen, denn IaC ermöglicht es, gewohnte bzw. wiederkehrende Abläufe zu automatisieren, Fehlerquellen zu reduzieren und die eigene Arbeit langfristig effizienter und nachvollziehbarer zu gestalten.
Bei der Umsetzung des IaC-Ansatzes wird jede Cloud-Ressource – ohne Ausnahme – per Code definiert, sofern diese für den Betrieb der Infrastruktur oder für die bereitgestellten Anwendungen erforderlich ist. Die provisionierten Cloud-Services können sich hierbei je nach Anwendungsfall unterscheiden und reichen von der Konfiguration von Netzwerken sowie der Bereitstellung von virtuellen Maschinen, Speicherkonten, Datenbanken bis hin zur Integration von Sicherheits- und Monitoring-Lösungen. Alles mit dem Ziel, eine konsistente, automatisierte und reproduzierbare Infrastruktur per IaC bereitzustellen.
Dabei ist es wichtig, die beiden grundlegenden IaC-Ansätze "deklarativ" und "imperativ" zu unterscheiden.
Deklarativer Ansatz:
Beim deklarativen Ansatz wird der gewünschte Zielzustand der Infrastruktur beschrieben. Es ist dabei unerheblich, wie genau dieser erreicht wird. Entscheidend ist lediglich, was am Ende vorhanden sein soll (Definition des "What?"). Der Administrator definiert also das gewünschte Ziel bzw. Ergebnis, nicht den Weg dorthin.
Ein einfaches Beispiel zeigt, wie mithilfe von HashiCorp Terraform eine Ressourcengruppe in Microsoft Azure erstellt werden kann:
resource "azurerm_resource_group" "example" {
name = "rg-weu-hub-network-dev-001"
location = "westeurope"
}Wird dieser Code ausgeführt, vergleicht Terraform den aktuellen Ist-Zustand in der Cloud mit dem definierten Soll-Zustand im Code. Beim ersten Durchlauf sorgt Terraform somit für die Erstellung der spezifizierten Ressourcengruppe. Wurde diese jedoch in einem vorhergehenden Lauf ("Run") bereits angelegt, erkennt das IaC-Tool beim darauffolgenden Lauf keine Änderungen, da die Infrastruktur sich bereits im vom Code definierten Zustand befindet. Dieses Verhalten wird als idempotent bezeichnet.
Ändert sich jedoch beispielsweise der Name der Ressourcengruppe im Code, so wird die bestehende Gruppe gelöscht und durch eine neue ersetzt. Dabei werden auch sämtliche darin enthaltenen Ressourcen entfernt und neu aufgebaut. Dieser sogenannte "Blast Radius" kann erhebliche Auswirkungen haben, weshalb potenzielle Risiken und Abhängigkeiten (sog. "Dependencies") zwischen den Ressourcen im Vorfeld sorgfältig bedacht werden müssen.
Imperativer Ansatz
Im Gegensatz zum deklarativen Ansatz wird beim imperativen Vorgehen nicht beschrieben, wie die Infrastruktur am Ende aussehen soll. Stattdessen müssen als Abfolge explizite Schritt-für-Schritt-Anweisungen definiert werden, die genau festlegen, wie der gewünschte Zustand erzeugt oder verändert wird (Definition des "How?").
Die Erstellung einer Ressourcengruppe in Microsoft Azure über die Azure CLI kann hierbei als Beispiel für den imperativen Ansatz herangezogen werden:
az group create
--name rg-weu-hub-network-dev-001
--location westeuropeWird dieser Befehl in einer initialen Cloud-Umgebung ausgeführt, erstellt dieser die im Code definierte Ressourcengruppe. Wird jedoch derselbe Befehl ein zweites Mal ausgeführt wird, so erscheint eine Fehlermeldung, dass die zu erstellende Ressourcengruppe bereits vorhanden ist bzw. existiert. Der imperative Ansatz zeigt somit im Vergleich zum deklarativen kein idempotentes Verhalten.
Wird eine Ressourcengruppe (RG) bei der Erstellung falsch benannt und enthält bereits zahlreiche Ressourcen, gestaltet sich eine nachträgliche Korrektur als aufwändig und fehleranfällig. Zwar kann die Ressourcengruppe über den imperativen Ansatz neu erstellt und die ursprüngliche Ressourcengruppe mit Command az group delete gelöscht werden, doch bringt dies erhebliche Herausforderungen mit sich. Alle bisher genutzten Ressourcen in der RG müssen nun neu erstellt und konfiguriert werden, was in den verwendeten Deployment-Skripten eine zusätzliche Logik erfordert, um Fehler abzufangen und den aktuellen Zustand der Infrastruktur zu prüfen.
Im Vergleich ergeben sich hauptsächlich durch die vorhandene Idempotenz des deklarativen Ansatzes folgende Vorteile:
- Vorhersagbarkeit: Der Ablauf ist klar definiert, unerwartete Änderungen bleiben aus. Abhängigkeiten zwischen den Cloud-Ressourcen werden im Hintergrund über entsprechende "Dependency Graphs" automatisch generiert und verwaltet.
- Sicherheit: Doppelte Ressourcen und Konfigurationsfehler werden vermieden.
- Integration: Optimal für CI/CD-Pipelines und wiederholbare Deployments geeignet. Der Code bildet immer einen konsistenten und ganzheitlichen Zustand der Cloud-Infrastruktur ab.
Das Ziel von Infrastructure as Code ist die automatisierte, versionierbare und konsistente Bereitstellung von IT-Infrastruktur. Durch den Verzicht auf manuelle Eingriffe und Freigabeprozesse wird eine zuverlässige und reproduzierbare Systemumgebung geschaffen, die sich problemlos in verschiedene Regionen und Szenarien ausrollen lässt. Mit wenigen Parametern wie "Name" und der "SKU" (Stock Keeping Unit) können Workloads in kurzer Zeit über vordefinierte Code-Vorlagen per IaC bereitgestellt werden. Dabei ist es entscheidend, von Anfang an auf bewährte Best Practices zu setzen und die Infrastruktur so zu gestalten, dass wiederholbare und skalierbare Deployments möglich sind, unabhängig in welcher Region oder Anzahl die Ressourcen benötigt werden.
Die Beweggründe für den Einsatz von IaC können je nach Unternehmen variieren:
- Automatisierung: Beschleunigt Bereitstellungsprozesse und reduziert manuelle Eingriffe.
- Konsistenz & Wiederholbarkeit: Stellt sicher, dass Infrastruktur immer identisch aufgebaut wird, in jeder Umgebung.
- Versionierung: Änderungen sind versioniert, nachvollziehbar, überprüfbar und bei Bedarf einfach rückgängig zu machen.
- Skalierbarkeit: Schnelle Anpassungen sowie das Erweitern der gesamten Umgebung werden erleichtert.
- Fehlerreduktion: Minimiert Risiken durch standardisierte, getestete Konfigurationen. Gleicher Code liefert beim Ausführen das gleiche Ergebnis, im Vergleich zu manuellen Prozessen.
- Transparenz: Schafft Klarheit über Infrastrukturzustände und deren Änderungen.
Best Practices für Infrastructure as Code (IaC)
Um das volle Potenzial von Infrastructure as Code auszuschöpfen und typische Fehlerquellen zu vermeiden, ist die Einhaltung bewährter Best Practices unerlässlich. IaC ermöglicht die Automatisierung und Standardisierung der Infrastrukturbereitstellung, birgt jedoch auch Risiken, wenn Prozesse und Strukturen nicht konsequent in Unternehmen umgesetzt werden. Gerade in komplexen Unternehmensumgebungen mit mehreren IT-Teams und vielfältigen Anforderungen ist es deshalb wichtig, klare Regeln und Methoden für IaC zu etablieren.
Die folgenden Best Practices bilden die Grundlage für einen erfolgreichen, sicheren und skalierbaren Einsatz von IaC. Sie helfen dabei, Fehler zu minimieren, die Wartbarkeit zu erhöhen und die Zusammenarbeit zwischen Entwicklungs-, Betriebs- und Sicherheitsteams zu verbessern. So lassen sich stabile und reproduzierbare Deployments sicherstellen, die den wachsenden Anforderungen in einem Unternehmen gerecht werden.
- Etablierung einer zentralen Module Library:
Eine zentrale Modulbibliothek im Unternehmen fördert die Wiederverwendbarkeit, Konsistenz und Wartbarkeit von IaC-Komponenten. Bei einem Modul handelt es sich um eine wiederverwendbare Code-Einheit, die eine bestimmte Infrastrukturkomponente oder ein Set von Cloud-Ressourcen kapselt und über Parameter steuerbar macht. Mittels einer Module Library können standardisierte Module organisationsweit bzw. teamübergreifend genutzt und kontinuierlich verbessert werden, wodurch doppelte Entwicklungsarbeit vermieden wird (Prinzip: "Don’t repeat yourself (DRY)"). Zudem erleichtert eine solche Bibliothek das Einhalten von Unternehmensrichtlinien und Best Practices, da alle IT-Teams auf geprüfte und freigegebene Module zugreifen. Als Alternative bieten sich vorgefertigte Open-Source-Module (z. B. Azure Verified Modules mit Terraform) an, die direkt verwendet und bei Bedarf flexibel an projektspezifische Anforderungen angepasst werden können. - Trennung von Code, Konfiguration und Umgebung:
Eine klare Trennung zwischen Infrastrukturdefinition und Umgebungsparametern (z. B. Dev, Test und Prod) ist grundlegend für eine strukturierte Projektorganisation. Dies fördert die Wiederverwendbarkeit des Codes, minimiert Fehlerquellen und erleichtert das Management über verschiedene Umgebungen hinweg. Zusätzlich empfiehlt es sich, Infrastrukturkomponenten wie Netzwerk, Firewall oder DNS in separaten Layern zu gliedern. So bleibt die Architektur flexibel und kann leichter an sich ändernde Zuständigkeiten innerhalb des Unternehmens angepasst werden. Details zur Konfiguration mit Terraform werden unter [4] erklärt und graphisch dargestellt. - Versionskontrolle und Code-Reviews etablieren:
IaC-Files sollten genau wie Application-Code behandelt werden. Das bedeutet beispielsweise Verwaltung in einem Git-Repository, strukturierte Branch-Strategie, Pull Requests und Validierungen. Änderungen bleiben nachvollziehbar, überprüfbar und revisionssicher, was die Grundlage für stabile und sichere Deployments bildet. - Einschränkung von Portalzugriffen auf Read Only:
Zur Sicherstellung der Konsistenz und Nachvollziehbarkeit sollte die manuelle Veränderung von Ressourcen über die webbasierte Oberfläche eines Cloud-Hyperscaler vermieden werden. Direkte Benutzerzugriffe über das Cloud-Portal sollten daher grundsätzlich nur mittels Leserechten "Read Only" vorgenommen werden. Änderungen an der Infrastruktur erfolgen ausschließlich über dedizierte Service Principals (SPs) im Rahmen des CI/CD-Prozesses. - Sorgfältiges State-Management:
Beim Einsatz deklarativer Tools wie Terraform ist das State File ein zentraler Bestandteil der Infrastrukturverwaltung. Es speichert den aktuellen Zustand der bereitgestellten Cloud-Ressourcen und dient als Referenz für zukünftige Änderungen. Eine sichere, zentrale und konsistente Verwaltung dieses Zustands ist daher essenziell. Bereits zu Beginn sollte ein Remote-Backend etwa ein Azure-Storage Account eingerichtet werden, idealerweise mit aktivierter State-Locking-Funktion, Blob-Versionierung und einem regelmäßigen Backup-Konzept, um parallele Zugriffe zu verhindern und potenziellen Datenverlust auszuschließen. Alternativ bietet Terraform Enterprise eine integrierte Lösung für State-Management, die neben zentraler Speicherung auch erweiterte Funktionen wie Team-Kollaboration, Richtlinienverwaltung und integrierte Sicherheit bereitstellt. - Sicherer Umgang mit Secrets:
Der Schutz sensibler Daten wie Passwörter, Zugangsschlüssel und Zertifikaten ist ein wesentlicher Aspekt bei der Implementierung des IaC-Ansatzes. Secrets sollten niemals direkt im Code oder im Versionskontrollsystem gespeichert werden. Stattdessen empfiehlt sich die Nutzung spezialisierter Secret-Management-Lösungen wie Azure Key Vault, HashiCorp Vault oder AWS Secrets Manager. Diese Systeme ermöglichen eine sichere Speicherung, rollenbasierte Zugriffskontrolle sowie eine automatische Rotation der darin enthaltenen Objekte. - Modul-Testing bei Provider-Updates:
Mit der regelmäßigen Veröffentlichung neuer Versionen eines IaC-Providers (z. B. AzureRM, AWS, etc.) ist es entscheidend, die eingesetzten Module kontinuierlich zu testen, um deren Kompatibilität und Funktionsfähigkeit sicherzustellen. Automatisierte Tests, idealerweise in Form von Integrations- oder End-to-End-Tests, sollten fester Bestandteil des Entwicklungsprozesses sein und bei jeder neuen Provider-Version automatisiert ausgeführt werden. Dadurch können Inkompatibilitäten und Fehler frühzeitig erkannt, Ausfälle vermieden und stabile Deployments gewährleistet werden. - Klare Trennung der Service Principals (SPs):
Für eine sichere und übersichtliche Verwaltung von Berechtigungen sollten unterschiedliche Service Principals strikt nach Verantwortungsbereichen getrennt werden. Beispielsweise muss ein Service Principal ausschließlich für das Deployment der Netzwerk-Infrastruktur zuständig sein, während ein anderer nur für das Ausrollen der Applikations- oder Governance-Ressourcen zuständig ist. Diese Trennung unterstützt das Prinzip der minimalen Rechtevergabe ("Least Privilege") und erhöht die Sicherheit von Aktionen innerhalb der Cloud-Umgebung, auch über unterschiedliche Umgebung (z. B. Dev, Test und Prod) hinweg.
Auf den IT-Tagen im Dezember hält Stefan Rapp einen Vortrag zum Thema
"Infrastructure as Code – Cloud-Automatisierung meistern".
Die Konferenz findet vom 08. - 11.12.2025 in Frankfurt statt.
Fazit
Die Einführung von Infrastructure as Code (IaC) markiert einen grundlegenden Wandel in der Art und Weise, wie IT-Infrastrukturen in der Cloud entworfen, bereitgestellt und betrieben werden – weg von manuellem "ClickOps", fehleranfälligen Einzelaktionen hin zu einem standardisierten, konsistenten und zuverlässigen Prozess. Was auf den ersten Blick wie ein rein technisches Upgrade erscheint, entpuppt sich in der Praxis oft als tiefgreifende Transformation mit erheblichen Auswirkungen auf Organisation, Prozesse und vor allem auf die Unternehmenskultur.
Zwar überzeugen die technischen Vorteile von IaC – Automatisierung, Wiederholbarkeit und Versionierbarkeit – schnell, doch liegt die eigentliche Herausforderung häufig nicht nur im Tooling selbst, sondern auch in der Veränderung von Denk- und Arbeitsweisen. Viele Unternehmen unterschätzen, dass IaC nicht nur ein neues Toolset, sondern ein echter Paradigmenwechsel ist. Infrastruktur wird fortan wie Software behandelt – geplant, getestet, provisioniert und im jeweiligen IT-Team verantwortet.
Eine erfolgreiche Einführung des IaC-Ansatzes erfordert daher weit mehr als den Einsatz moderner Technologien. Sie verlangt nach klaren Strategien, standardisierten Prozessen, gezieltem Enablement der Mitarbeitenden sowie einer engen Zusammenarbeit zwischen Entwicklung, Betrieb und IT-Sicherheit. Nur wenn dieser Wandel im Unternehmen als ganzheitliches Vorhaben verstanden und gesteuert wird, kann IaC sein volles Potenzial entfalten.
Die Einführung von Infrastructure as Code markiert einen grundlegenden Wandel weg von manuellem "ClickOps".
Wer IaC langfristig und strukturiert etabliert, schafft nicht nur eine solide Grundlage für stabile, skalierbare und sichere Deployments, sondern fördert auch eine moderne, agile und teamübergreifende Arbeitsweise – ganz im Sinne einer nachhaltigen Cloud-Transformation. Infrastructure as Code ist damit für ein Unternehmen kein Selbstzweck, sondern ein entscheidender Enabler für Effizienz, Transparenz und Zukunftsfähigkeit in der IT und deren Cloud-Infrastrukturen.
- Adacor: Infrastructure as Code: Verwaltung von Infrastruktur per Code
- Rapid7: Was ist Infrastructure-as-Code (IaC)?
- Kief Morris – Infrastructure as Code: Dynamic Systems for the Cloud Age, O’Reilly, 2nd Edition, 2020
- Mr. Azure: Mastering Cloud Automation on Azure – The Power of IaC!
