Infrastructure as Code in AWS – Welches Tool ist das richtige für mich?

Infrastructure as Code (IaC) Technologien ermöglichen einen schnellen Aufbau und eine kosteneffiziente Verwaltung von Ressourcen in der Cloud.
Da jede Technologie für einen spezifischen Zweck optimiert wurde, kann die richtige Entscheidung darüber, welche Technologie für welchen Zweck eingesetzt werden soll, Ihnen eine Menge Frust & Kosten ersparen.
In diesem Artikel soll zum einen der Nutzen und die Funktionsweise von IaC in AWS allgemein erläutert und anschließend die gängigen IaC-Technologien miteinander verglichen werden.

• Was ist Infrastructure as Code und wofür brauche ich es?
• Funktionsweise IaC in AWS
• CloudFormation
• Terraform
• CDK
• Pulumi
• Persönliches Fazit

Was ist Infrastructure as Code und wofür brauche ich es?

Die Bereitstellung von IT-Infrastruktur bildet das zentrale Fundament für den Aufbau der IT-Landschaft eines Unternehmens.

Bei immer mehr neuen Anwendungen mit immer komplexeren Architekturen und steigenden Ressourcenbedarf ist es daher zwingend notwendig, dass die Bereitstellung & Verwaltung der IT-Infrastruktur möglichst effizient erfolgt, um Engpässe zu vermeiden und auch allgemein die Kosten gering zu halten.

Um diesen Anspruch gerecht zu werden, wurden im gesamten IT-Sektor in den letzten Jahren sehr breit Maßnahmen ergriffen, um den benötigten Aufwand für die Verwaltung der IT-Ressourcen stetig zu reduzieren.

Durch die Verwendung von Skripten gelang der erste große Durchbruch, da nun auch erste komplexere Systeme automatisiert und reproduzierbar erstellt werden konnten.
Mit dem verstärkten Aufkommen von APIs konnten diese Skripte schließlich genormt und zentral orchestriert werden, wodurch erste Softwareverbunde (wie z.B. ein Apache Cassandra Cluster) einfach und mit einem sehr geringen Aufwand komplett automatisiert erzeugt werden konnten.

Dennoch wachsen die Anforderungen weiterhin stetig:

• Softwareentwickler wünschen sich immer mehr Zugang zur Administration der Ressourcen
• Ganze IT-Landschaften müssen für Proof of Concepts innerhalb von kürzester Zeit erschaffen werden, ungewiss ob diese später weiter ausgebaut oder abgerissen werden müssen
• Multi-Region, Multi-Tenant & Multi-Environment Roll-Out Strategien sorgen für eine große Menge an Ressourcen, deren Management manuell nicht mehr möglich ist
• Kurze Entwicklungszyklen und moderne CI/CD Ansätze sind mit klassischen Prozessen eher umständlich umzusetzen
• […]

Um diesen Anforderungen gerecht zu werden, hat sich IaC als Technologie der Wahl durchgesetzt.
Durch IaC können selbst komplexe Architekturen mit mehreren Diensten in genormter, durch Mensch & Maschine lesbarer textueller Form (Code) definiert werden.
Je nach gewählter Umsetzung liegt der Code in Dokumenten (z.B. json, yaml, xml) oder einer beliebigen Programmiersprache vor.
Mit einem Interpreter wird der Code schließlich interpretiert und die im Code definierten Ressourcen erzeugt.
Durch Parameter lässt sich die Erstellung der Ressourcen flexibel definieren und steuern.
Der definierte Code lässt sich außerdem flexibel in Module paketieren und kann beispielsweise anschließend in beliebig vielen Environments wieder verwendet werden.
Da die komplette Infrastruktur über Dienstgrenzen hinweg einheitlich in Textform verwaltbar ist, verringert sich der administrative Aufwand aufgrund der einfacheren Verwaltung und hohen Wiederverwendbarkeit enorm. Gleichzeitig werden Fehler in manuelle Prozesse deutlich reduziert.

Funktionsweise IaC in AWS

Innerhalb von AWS gibt es eine Vielzahl verschiedener Dienste. (z.B. S3, EC2, DynamoDB)
Jeder dieser Dienste erfüllt einen dedizierten Zweck und verwaltet hierzu passende Ressourcen.
Eine Ressource wird zu einem gewissen Zeitpunkt erschaffen und kann zu einem späteren Zeitpunkt auch wieder gelöscht werden.
Jede Ressource für sich besitzt auch individuelle Attribute, welche gelesen und teils auch modifiziert werden können.
Bei manchen Objekten ist es sogar möglich, erweiterte Operationen durchzuführen.

Hier eine kleine Übersicht zum besseren Verständnis:

Dienst	Objekte	Eigenschaften	Aktion
S3	S3 Bucket	Name, Versionierungsrichtlinie, Verschlüsslungsrichtlinie	PutObject (Datei Upload)
EC2	EC2 Instanz	IAM Rolle, Basis-Image-AMI, Netzkonfiguration	StartInstances (Start von einer oder mehreren Instanzen)
DynamoDB	Tabelle	Name, Bereitstellungsmodus, Primärschlüssel	Query (Durchsuchung der Tabelle)

Jeder AWS Dienst bietet genormte Schnittstellen (APIs) an, um diese Ressourcen einheitlich zu erzeugen, zu lesen und zu löschen – wobei jede Ressource individuell über eine eigene ID, die sogenannte “ARN”, adressiert werden kann.

Alle IaC Toolings machen sich dieses Prinzip zunutze.
Innerhalb des Codes werden Ressourcen mit ihren Wunscheigenschaften in einem Zielzustand definiert.
Durch Ausführung des Codes durch den Interpreter wird der Zielzustand über die AWS-API mit dem aktuellen Zustand im Zielsystem abgeglichen und Maßnahmen ergriffen, sofern der Zielzustand mit dem aktuellen Ist-Zustand nicht übereinstimmt.

Wenn nun z.B. ein S3 Bucket mit dem Namen mein.super.s3.bucket im Zielzustand existieren soll und bei der Interpretation festgestellt wird, dass dieser im Zielsystem noch nicht vorhanden ist, wird dieser erzeugt.

Neben IaC gibt es auch noch das Konfigurationsmanagement (KM), wobei sich das IaC stärker um das Bereitstellen von Ressourcen und das KM stärker um die Verwaltung dieser kümmert.

Per IaC würde man z.B. einen virtuellen Server bereitstellen, während man per KM regelmäßig überprüft, ob auf diesem Server veraltete Software installiert ist.

Beide Technologien bieten allerdings in der Regel auch Funktionalitäten für den jeweils anderen Anwendungsfall. Hierfür sind sie in der Regel aber weniger stark optimiert und umständlich zu bedienen.

Hier eine kleine Übersicht gängiger IaC und KM Technologien:

IaC	KM
AWS CloudFormation	Ansible
Terraform	Chef
AWS CDK	Puppet
Pulumi	AWS Config

Im Folgenden wird ausschließlich auf die IaC Toolings eingegangen.

CloudFormation

AWS hat 2010 den Dienst “CloudFormation” veröffentlicht, welches als Grundpfeiler der nativen IaC Toolings innerhalb von AWS fungiert.
CloudFormation verwendet wahlweise YAML oder JSON Dokumente, sogenannte CloudFormation Templates, um die Infrastruktur abzubilden und spiegelt die AWS Ressourcen ziemlich direkt wider.
Auf CloudFormation aufbauend wurden über die Zeit weitere Technologien entwickelt, um die Bereitstellung der Ressourcen weiter zu optimieren.

So wurde z.B. AWS SAM geschaffen um Toolings des Serverless Stacks (API-Gateway, Lambda, DynamoDB, Cognito …) vereinfacht zu repräsentieren.

Das Cloud Development Kit (CDK) nutzt ebenfalls CloudFormation Templates. Der Code wird allerdings nicht durch JSON oder YAML umgesetzt, sondern kann stattdessen in Java, C#, JavaScript, TypeScript, Python und Go abgebildet werden, wobei das Angebot stetig erweitert wird – dazu später mehr.

Bei AWS Elastic Beanstalk (PaaS) und AWS Amplify(BaaS) handelt es sich wiederum um zwei komplett eigene Technologie-Stacks, welche CloudFormation für die Verwaltung der darunter liegenden Infrastruktur nutzen.

Des Weiteren existieren viele weitere Direktintegration wie z.B. zu AWS CodePipeline, AWS Service Catalog oder auch AWS Marketplace, wodurch CloudFormation innerhalb der AWS Welt optimal integriert ist.

Um Ressourcen über CloudFormation bereitzustellen, muss ein CloudFormation Template definiert werden – hierfür kann jeder Texteditor Ihrer Wahl verwendet werden.
Das Template beinhalten unter anderem Ressourcen, Parameter und Outputs. (Mehr Infos dazu hier: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-anatomy.html)

So sieht ein beispielhaftes Template aus, welches …

• als Parameter einen Bucket-Name erwartet (Parameter “NameOfBucket”).
• einen passenden für Webhosting konfigurierten S3 Bucket erzeugt (Ressource “S3Bucket”).
• die öffentliche URL des erstellten Buckets zur Verfügung stellt (Output “WebsiteURL”).

AWSTemplateFormatVersion: 2010-09-09

Parameters:
  NameOfBucket:
    Type: String
    Description: Enter the name of the bucket to create.

Resources:
  S3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      AccessControl: PublicRead
      WebsiteConfiguration:
        IndexDocument: index.html
        ErrorDocument: error.html
      BucketName: 
        Ref: NameOfBucket

Outputs:
  WebsiteURL:
    Value: !GetAtt 
      - S3Bucket
      - WebsiteURL
    Description: URL for website hosted on S3

Dieses Template kann nun über den CloudFormation Service eingelesen werden, wodurch ein “Stack” erzeugt wird.
Dieser Stack bildet den Lebenszyklus der Ressourcen ab und sorgt dafür, dass diese erzeugt werden. Sobald der Stack gelöscht wird, werden die zugrundeliegenden Ressourcen ebenfalls abgerissen.

Somit könnte man mit dem obenstehenden Template beliebig viele Stacks und jeweils einen individuellen S3 Bucket erzeugen – durch Löschen des jeweiligen Stacks, werden die Ressourcen wiederum entfernt.

Um eine einzelne Teilressource zu löschen oder anzupassen, muss das zugehörige Template abgeändert und anschließend als “ChangeSet” an CloudFormation übergeben werden. Wird das ChangeSet ausgeführt, aktualisiert CloudFormation Ihren Stack mit den gewünschten Änderungen.

Sonstiges:
Über den CloudFormation Designer können alle Ressourcen eines Templates grafisch dargestellt und auch modifiziert werden. Dadurch lässt sich auch für CloudFormation Unerfahrene der Zugang erleichtern. (Mehr Infos dazu hier: https://docs.aws.amazon.com/de_de/AWSCloudFormation/latest/UserGuide/working-with-templates-cfn-designer.html)

Über QuickLinks können eigene erzeugte Templates (z.B. für das Deployment einer WordPress Instanz) anderen sehr einfach zugänglich gemacht werden. (Mehr Infos dazu hier: https://aws.amazon.com/de/blogs/devops/construct-your-own-launch-stack-url/)

Terraform

Im Gegensatz zu CloudFormation handelt es sich bei Terraform nicht um eine native Lösung von AWS, sondern um ein IAC Softwaretool, welches von HashiCorp 2014 erstmals als Open Source Lösung veröffentlicht wurde.
Terraform ist breiter aufgestellt und deckt durch sogenannte “Provider” eine Vielzahl verschiedener public Cloud Anbieter (z.B. AWS / Google / Microsoft) aber auch private Cloud Software Lösungen (z.B. Kubernetes, Cloud Foundry, OpenStack) ab. Das die Technologie nicht AWS spezifisch ist, macht sie umso interessanter.
Aktuell werden von HashiCorp, das Unternehmen hinter Terraform, knapp 1500 Umgebungen unterstützt.
Als Dateiformat wird hier auf die von HashiCorp selbst entwickelte Konfigurationssprache “HashiCorp configuration language” (HCL) gesetzt, wobei wahlweise auch json verwendet werden kann.
Der Code wird in sogenannten Modulen gespeichert.
Bei Modulen handelt es sich um ein lokales Verzeichnis, welche Dateien mit der Endung .tf beinhaltet.

So sieht ein beispielhaftes Template aus, welches …

• als Parameter einen Bucket-Name erwartet (Variable “NameOfBucket”).
• einen passenden für Webhosting konfigurierten S3 Bucket erzeugt (Ressource “S3Bucket”).
• die öffentliche URL des erstellten Buckets zur Verfügung stellt (Output “WebsiteURL”).

provider "aws" {
  region = "eu-central-1"
}

variable "NameOfBucket" {
    description = "Enter the name of the bucket to create."
    type = string
}

resource "aws_s3_bucket" "S3Bucket" {
  bucket = "${var.NameOfBucket}"
  acl    = "public-read"
  website {
    index_document = "index.html"
    error_document = "error.html"
  }
}


output "WebsiteURL" {
  value = aws_s3_bucket.state_management.website_endpoint
}

Das Deployment von Terraform passiert komplett per Kommandozeile. Hierfür muss die CLI lokal installiert werden. (Mehr Infos dazu unter: https://learn.hashicorp.com/tutorials/terraform/install-cli?in=terraform/aws-get-started)

Nachdem die CLI installiert ist, kann im jeweiligen Verzeichnis des Modules der Befehl terraform init ausgeführt werden – hierdurch werden alle für das Modul nötige Abhängigkeiten installiert.
Durch Ausführung von terraform validate kann die Syntax der Dokumente validiert werden.
Per terraform plan können die definierten Ressourcen mit den aktuellen Ressourcen im Zielsystem verglichen und ein sogenannter Änderungsplan erzeugt werden, welcher alle durchzuführenden Änderungen beschreibt.
Per terraform apply werden die Änderungen dann tatsächlich im Zielsystem durchgeführt und die erstellten Ressourcen zu Synchronisationszwecken in einer .tfstate Datei abgespeichert.
Sollten die Ressource nicht mehr benötigt werden, genügt ein terraform destroy um alle Ressourcen zu entfernen.

Hier eine kompakte Übersicht über die wichtigsten Befehle:

Befehl	Beschreibung
Terraform Init	Installation von Abhängigkeiten
Terraform Validate	Grobvalidation
Terraform Plan	Abgleich der definierten Ressourcen mit aktuellen Ressourcen im Zielsystem und Erstellung eines Änderungsplans
Terraform Apply	Ausführung eines Änderungsplans und damit Erstellung bzw. Änderung von Ressourcen
Terraform Destroy	Löschung aller verknüpften Ressourcen

Somit lässt sich sehr schnell ein neues Modul zum Erstellen & Bearbeiten von AWS Infrastruktur aufsetzen. Durch Kopieren des Modules in ein neues Verzeichnis lässt sich der geschriebene Code wieder verwenden. Noch besser ist es allerdings, das Modul in einem GitHub Repository abzuspeichern, um später noch einfacher darauf zugreifen zu können. (Mehr Infos dazu hier: https://www.terraform.io/docs/language/modules/develop/index.html)

Sonstiges: Da es sich bei Terraform um ein CLI optimiertes Tooling handelt, können hier noch einige Zusatzfunktionen hinzuprogrammiert werden. Die HCL bietet viele weiterer Zusatzfunktionalitäten und auch Cloud gehostete Toolings zur Verwaltung der Module werden angeboten.

CDK

Bei der AWS CDK handelt es sich um Open-Source Programmiersprachen Bibliotheken welche technologisch auf CloudFormation aufbaut.
Statt direkt CloudFormation Templates zu definieren, wird hier allerdings mithilfe einer Programmiersprache der Wahl (Aktuell: JavaScript, TypeScript, C#, F#, Python, Go, Java) die Infrastruktur beschrieben und anschließend in ein CLoudFormation Template übersetzt.

Nach Installation des AWS CDK Toolkits (Mehr Infos dazu hier: https://docs.aws.amazon.com/cdk/latest/guide/hello_world.html) kann es schon losgehen.
Zuerst wird ein leeres Verzeichnis benötigt (z.B. Sample), in welchem der Befehl cdk init app --language {language} (für {language} bitte csharp, fsharp, go, java, javascript, python oder typescript einsetzen) ausgeführt wird. In diesem Fall wurde C# als Beispiel ausgewählt.

cdk init app --language csharp

Die CDK erzeugt anschließend eine passende Ordnerstruktur und legt alle für die Entwicklung notwendigen Dateien an.

Innerhalb einer eigenen Ableitung der Basisklasse “Stack” können dann beliebig Ressourcen definiert werden.

So sieht eine beispielhafte Klasse aus, welche …

• als Parameter einen Bucket-Name erwartet (TryGetContext “uploadBucketName”).
• einen passenden für Webhosting konfigurierten S3 Bucket erzeugt (Bucket “MyBucket”).
• die öffentliche URL des erstellten Buckets zur Verfügung stellt (CfnOutput “WebsiteURL”).

public class SampleStack : Stack
{
    internal SampleStack(
        Construct scope,
        string id,
        IStackProps props = null)
        : base(scope, id, props)
    {
        var bucketName = this.Node.TryGetContext("uploadBucketName");
        var myBucket = new Bucket(this, bucketName.ToString(), new BucketProps()
        {
            WebsiteErrorDocument = "index.html",
            WebsiteIndexDocument = "index.html",
            AccessControl = BucketAccessControl.PUBLIC_READ,
        });
        new CfnOutput(this, "WebsiteURL", new CfnOutputProps() { Value = myBucket.BucketWebsiteUrl });
    }
}

Mit cdk synth kann man sich optional das zu generierende CloudFormation Template anzeigen lassen. Mit cdk deploy wird ein CloudFormation Template erzeugt und anschließend per CloudFormation deployed. Via cdk destroy kann der komplette Stack gelöscht werden.

Hier eine kompakte Übersicht über die wichtigsten Befehle:

Befehl	Beschreibung
cdk init	Initialisiert ein neues Projekt in einem leeren Verzeichnis
cdk synth	Erstellt ein CloudFormation Template
cdk deploy	Deployed ein CloudFormation Template
cdk diff	Prüft, welche Änderungen durch ein Deployment durchgeführt werden würden
cdk destroy	Löschung aller verknüpften Ressourcen

Zur Wiederverwendung des Codes können mehrere Klassen in ein sogenanntes Construct zusammengefasst werden. (Mehr Infos dazu hier: https://docs.aws.amazon.com/cdk/latest/guide/constructs.html)
Anschließend können diese wiederum, in ein zu der Programmiersprache passendes Paket geschnürt und dann beliebig verteilt werden. (In C# z.B. als Nuget Package)

Falls mehrere Environments benötigt werden, sollten diese innerhalb der gleichen Anwendung definiert werden. Ein dediziertes Deployment kann anschließend per CLI erfolgen.

Pulumi

Bei Pulimi handelt es sich um ein Open-Source Projekt, welches von der Pulumi Corporation entwickelt und betrieben wird.
Ziel von Pulumi ist es IaC grenzenlos für alle Programmiersprachen (Aktuell: JavaScript, VB, F#, TypeScript, C#, Python, Go) und für möglichst viele public, wie auch private Cloud Anbieter, zu ermöglichen.
Zur Anbindung dieser nutzt Pulumi sogenannte Pakete – ein Paket bündelt hierbei die Funktionalitäten, die zur Anbindung des Cloud Anbieters nötig sind.
Die Pakete sind über die in der Programmiersprache üblichen Paketverwaltung (z.B. Nuget bei .NET) zugänglich.

Für die Verwaltung beliebig vieler Ressourcen mit einem einzigen Pulumi Account ist die Nutzung immer kostenlos.
Wenn die Ressourcen allerdings von einem Team mit mehreren Pulumi Accounts verwaltet werden (was bei mehreren Administratoren notwendig ist), fallen Gebühren an.
Vereinfacht ausgedrückt, fallen pro verwalteter Ressource (z.B. ein S3 Bucket, DynamoDB Tabelle) eine Verwaltungsgebühr (0.00025 USD pro Stunde, entspricht 0,186 USD pro Monat) an, wobei ein Freibetrag von 37,5 USD pro Monat gegengerechnet wird.
Abzüglich des Freibetrags können somit ca. 200 Ressourcen kostenlos verwaltet werden, während bei 450 Ressourcen ca. 50 USD pro Monat an Gebühren anfallen.

Nach Installation der Pulumi CLI (Mehr Infos dazu hier: https://www.pulumi.com/docs/get-started/aws/begin/) kann es eigentlich schon losgehen.
Als Erstes wird ein leeres Ordner Verzeichnis benötigt (z.B. “Sample”), in dem anschließend der Befehl pulumi new ausgeführt werden kann, über einen Dialog kann man dann das passende Beispielprojekt wählen.
Da ich am meisten Erfahrung in C# Entwicklung besitze, habe ich hier csharp gewählt.

Sofern Pulumi vorher noch nicht verwendet worden ist, wird man aufgefordert einen Pulumi Account zu erzeugen.
Dieser wird benötigt, da in Pulumi die State-Verwaltung der Ressourcen komplett serverseitig erfolgt.

Die Pulimi CLI erzeugt anschließend eine passende Ordnerstruktur und legt alle für die Entwicklung nötigen Dateien an.

Innerhalb einer eigenen Ableitung der Basisklasse “Stack” können dann beliebig Ressourcen definiert werden.

So sieht eine beispielhafte Klasse aus, welche …

• als Parameter einen Bucket-Name erwartet (TryGetContext “uploadBucketName”).
• einen passenden für Webhosting konfigurierten S3 Bucket erzeugt (Bucket “MyBucket”).
• die öffentliche URL des erstellten Buckets zur Verfügung stellt (CfnOutput “WebsiteURL”).

class MyStack : Stack
{
    public MyStack()
    {
        var config = new Pulumi.Config();
        var bucketName = config.Require("NameOfBucket");

        var myBucket = new Bucket(bucketName, new BucketArgs() {
            Website = new BucketWebsiteArgs { ErrorDocument = "index.html", IndexDocument = "index.html" },
            Acl = "public-read"
        });

        this.WebsiteURL = myBucket.WebsiteEndpoint;
    }

    [Output]
    public Output<string> WebsiteURL { get; set; }
}

Durch Ausführung von pulumi preview kann man sich optional das zu generierende CloudFormation Template anzeigen lassen, mit pulumi up werden die definierten Ressourcen deployed und mit pulumi destroy werden die erzeugten Ressourcen zerstört.

Befehl	Beschreibung
pulumi new	Initialisiert ein neues Projekt in einem leeren Verzeichnis
pulumi config	Definition von Variablen
pulumi preview	Prüft, welche Änderungen durch ein Deployment durchgeführt werden würden
pulumi up	Deployed die definierten Ressourcen
pulumi destroy	Löschung aller verknüpften Ressourcen

Über die Pulumi-WEB-UI können alle verwalteten Stacks & Ressourcen zusätzlich noch grafisch dargestellt und verwaltet werden.

Zur Wiederverwendung des Codes kann dieser abhängig von der Programmiersprache zu passenden Paketen geschnürt und dann beliebig verteilt werden. (In C# z.B. als Nuget Package)

Falls mehre Environments benötigt werden, sollten diese innerhalb der gleichen Anwendung definiert werden. Ein dediziertes Deployment kann anschließend per CLI erfolgen.

Sonstiges: Bei der Entwicklung der Pakete bedient sich Pulumi um einen genialen Trick. Teile der von Ihnen zur Verfügung gestellten Pakete basieren auf dem Quellcode der Terraform Provider. Somit ist zu erwarten, dass sich die Menge, der von Pulumi zur Verfügung gestellten Pakete an den verfügbaren Terraform Providern annähert und diese evtl. sogar zukünftig übertrifft.

Persönliches Fazit

Egal wie man es dreht und wendet: Alle vier Toolings eignen sich hervorragend für einen produktiven Einsatz. Je nachdem, welches Knowhow im Team existiert, eignen sich manche der Toolings besser als andere. Entwickler tun sich vermutlich mit der CDK oder Pulumi leichter, während sich Administratoren eher mit CloudFormation oder Terraform wohler fühlen. Wenn außer AWS noch andere Cloud Anbieter oder Cloud Technologien innerhalb von AWS verwaltet müssen (z.B. Kubernetes Knoten in einem EKS Cluster), sind Terraform & Pulumi definitiv CloudFormation & der CDK vorzuziehen.

Basis Wissen in CloudFormation ist ein absolutes Muss als AWS Administrator und es eignet sich sehr gut für kleinere Deployments. Bei größeren Infrastrukturen oder Infrastruktur Verbünden über mehrere AWS Regionen oder AWS Accounts hinweg, sehe ich CloudFormation nicht als das Tool der Wahl, da die Verwaltung gerade durch die bessere Paketierung in allen anderen IaC Toolings deutlich leichter fällt.

Über die CDK können die CloudFormation Templates in einer Programmiersprache der Wahl entwickelt werden, wodurch Entwicklern ein leichterer Einstieg gelingt. Da der Code im Verhältnis zu CloudFormation deutlich einfacher wiederverwendet werden kann, erhöht sich hier die Produktivität enorm. Dennoch ist man weiterhin an die Limitierungen von CloudFormation gebunden, da die AWS CDK auf CloudFormation basiert.

Terraform ist aktuell das zurecht am weitesten verbreitete Toolings im IaC Bereich. Auch ohne Programmierkenntnisse ist man in der Lage Infrastruktur über Anbieter Grenzen hinweg beliebig zu erstellen und zu verwalten. Die HCL ist aktuell nicht jedermanns Liebling, allerdings keineswegs komplex und nach etwas Eingewöhnung relativ leicht bedienbar.

Auch wenn Pulumi noch relativ jung ist und als einziges Tool für den kollaborativen Einsatz innerhalb eines Teams nicht kostenlos nutzbar ist, hat es wohl das größte Potential zukünftig Spitzenreiter zu werden. Durch die breite Auswahl an nutzbaren Programmiersprachen und die Kompatibilität zu verschiedenen Cloud Infrastruktur Anbietern bietet es eine große Flexiblität. Außerdem erhält man zusätzlich eine zentrale Übersicht über die Infrastruktur inklusive Abhängigkeitsdiagramm.