zurück zum Artikel

Das quelloffene Entwicklerframework Cloud Development Kit dient dem Erstellen von Infrastruktur und lässt sich unter anderem mit TypeScript nutzen.

Infrastructure as Code (IaC) ist eine verbreitete Best Practice, bei der Code – statt manueller Prozesse – die Infrastruktur verwaltet und provisioniert. Dafür kommen bekannte Werkzeuge wie AWS CloudFormation oder Terraform zum Einsatz. Eines haben fast alle Werkzeuge gemeinsam: Sie nutzen eine Konfigurationssprache wie YAML zum Beschreiben der Infrastruktur. Damit gehen einige Herausforderungen einher, denn lückenhafte IDE-Unterstützung und umfangreiche Templates reduzieren die Übersichtlichkeit und Produktivität. In den letzten Jahren ist eine alternative Herangehensweise populär geworden. Eine neue Generation von IaC-Werkzeugen erlaubt es, Infrastruktur mit universellen Programmiersprachen zu beschreiben. Ein praktisches Beispiel stellt einen bekannten Vertreter näher vor: das Cloud Development Kit, kurz CDK. 

Was ist das Cloud Development Kit?

Das CDK ist ein Open-Source-Framework zum Definieren von Infrastruktur mithilfe bekannter Programmiersprachen wie Python, Java, Go, JavaScript und TypeScript. Nachfolgend liegt der Fokus auf dem Verwenden des CDK mit TypeScript. Die 2012 veröffentlichte Programmiersprache ist ein Superset von JavaScript und hebt sich vor allem durch ihre statische Typisierung ab.

Das Beschreiben der Infrastruktur mit Programmcode erlaubt TypeScript-Entwicklerinnen und -Entwicklern, in ihrer bekannten Entwicklungsumgebung zu arbeiten und auf hilfreiche Funktionen wie Autovervollständigung und Inline-Dokumentation zurückzugreifen. Zudem bietet das CDK zusätzliche Abstraktionen, genannt Constructs, zum Aufsetzen der Infrastruktur.

Funktionsweise des CDK

Nun geht es an das Verwenden des Cloud Development Kit, um Infrastruktur auf AWS zu modellieren. Hierzu ist es nötig, eine CDK-Anwendung in der gewünschten Programmiersprache zu schreiben, beispielsweise TypeScript. Eine CDK-Anwendung kann mehrere Stacks, also Gruppierungen von Infrastruktur, enthalten. Innerhalb eines Stacks instanziiert der Entwickler oder die Entwicklerin eine Reihe von Klassen, die die eigentliche Infrastruktur repräsentieren, wie beispielsweise eine virtuelle Maschine mit Amazon EC2 oder einen Objektspeicher wie Amazon S3. Diese Klassen heißen Constructs (siehe Abbildung 1). Sie können die Infrastruktur mit sinnvollen Voreinstellungen aufsetzen und typische Konfigurationen per Funktionsaufruf aktivieren. Das beschleunigt das Definieren der gesamten Infrastruktur und macht es leichter, Best Practices zu befolgen. Constructs können unterschiedlich komplex sein und entweder einzelne Infrastrukturkomponenten enthalten oder sogar ganze Architekturen. 

Danach wird das CDK CLI verwendet, um den Anwendungscode in ein CloudFormation-Template zu übersetzen. AWS CloudFormation ist ein Service, um Infrastruktur auf AWS deklarativ zu beschreiben und auszurollen. Das CDK CLI sendet das Template zum CloudFormation-Dienst, um die eigentliche Infrastruktur zu erstellen (siehe Abbildung 2). Das Interessante bei diesem Prozess ist, dass das CDK auf bestehende IaC-Werkzeuge aufsetzt.

Anwendungsbereiche für das CDK

Das Cloud Development Kit ist Open Source und in großen Teilen treibt eine offene Community seine Entwicklung voran. Heute existiert das CDK in verschiedenen Varianten, die jeweils unterschiedliche Clouds beziehungsweise Plattformen programmieren können. Initial hatte AWS es als AWS CDK ins Leben gerufen [1]. Wie der Name erahnen lässt, liegt hier der Fokus auf der Modellierung von Infrastruktur und der Nutzung von Diensten in der AWS Cloud. Die Kernkomponenten von CDK verwendeten weitere Open-Source-Projekte wieder, um Kubernetes-Anwendungen (cdk8s) [2] und Ressourcen mit Terraform (cdktf) [3] mit dem gleichen Programmiermodell aufsetzen zu können. Damit deckt das CDK-Ökosystem eine sehr breite Auswahl an Plattformen ab. Wie beim AWS CDK generiert das zugehörige CLI die Templates aus dem geschriebenen Programmcode. Diese Templates lassen sich dann mit den nativen Funktionen der jeweiligen Werkzeuge beziehungsweise Plattformen ausführen. cdk8s synthetisiert YAML-Dateien, die das Kubernetes-Kommandozeilenwerkzeug kubectl direkt lesen und anwenden kann. cdktf synthetisiert Terraform-Templates im JSON-Format.

Infrastruktur erstellen in einem Praxisbeispiel

Dass das CDK mehr ist als die Übersetzung von Programmcode in Templates für CloudFormation, Kubernetes oder Terraform, demonstriert ein praktisches Beispiel. Es zeigt, wie die Constructs als Abstraktionen dienen können, um mit wenigen Zeilen Programmcode Architekturen mit sinnvollen Standardkonfigurationen aufzubauen.

Die Beispielarchitektur besteht aus einem Application Load Balancer, der über das Internet erreichbar ist. Er verteilt HTTP-Anfragen an eine Amazon EC2 Auto Scaling Group. Die Definition dieser Architektur mit Berücksichtigung einiger Best Practices schlägt sich – beim Verwenden von CloudFormation – in über 300 Zeilen YAML nieder. Es stellt sich die Frage, warum eine einfache Architektur schon so viele Zeilen Code benötigt. Die Antwort liegt darin, dass das in Abbildung 3 dargestellte Diagramm eine vereinfachte Sicht ist, die eine Menge zusätzlich zu definierender Objekte und Einstellungen unterschlägt (siehe Abbildung 4).

Zum einen ist eine Amazon Virtual Private Cloud (VPC), die private Netzwerkumgebung, zu konfigurieren. Das erfordert viele Entscheidungen: Welcher IP-Adressbereich soll zum Einsatz kommen? Wie viele Subnetze soll es geben? In wie vielen Availability Zones, also diskreten Rechenzentren innerhalb einer AWS-Region, sind Subnetze zu erstellen? Gibt es öffentliche Subnetze, die vom Internet erreichbar sind, und private, die es nicht sind? Auf all diese Fragen gibt es Antworten in Form von Best Practices, die entweder bekannt oder zunächst zu recherchieren sind. Damit aber nicht genug: Zum anderen ist es anschließend nötig, die Einzelkomponenten zu konfigurieren und miteinander zu verbinden. So braucht es für die Kommunikation zwischen Subnetzen und mit dem Internet jeweils Routing-Tabellen. Je nachdem, ob es sich um ein öffentliches oder privates Subnetz handelt, enthalten die Routing-Tabellen eine Route zum Internet oder zum Network-Address-Translation-(NAT)-Gateway. Das NAT-Gateway benötigt noch eine Elastic IP, also eine öffentliche IP-Adresse, mit der es im Internet die privaten Hosts vertritt. 

Für den Application Load Balancer und die Auto-Scaling-Gruppe sind ebenfalls zusätzliche Objekte und Einstellungen anzulegen. Ein Aspekt sind die Security Groups, die als virtuelle Firewalls fungieren und entsprechend mit Regeln für ein- und ausgehenden Datenverkehr zu versehen sind. Die Vielzahl an Konfigurationsmöglichkeiten ist der Grund, warum eine auf den ersten Blick einfache Architektur zu einem über 300 Zeilen langen CloudFormation-Template wird.

Wie das CDK mit 30 Zeilen Code zum Ziel kommt

Um herauszufinden, wie sich das AWS CDK im Vergleich schlägt, sind zuerst einige Voraussetzungen zu erfüllen. Diese sind gut nachvollziehbar auf der Website des CDK Workshop [4] aufgelistet, die auch generell als Einstieg in das CDK sehr zu empfehlen ist. Unter anderem muss das AWS CLI installiert und ein AWS-Account vorhanden sein, wobei auch ein kostenloser Account ausreicht [5]. Als weitere Voraussetzung muss Node.js in einer aktuellen Version installiert sein.

Das CDK CLI lässt sich dann über den Node Package Manager npm installieren. Der nachfolgende Befehl weist npm an, die CDK-Programmbibliothek und das CLI global, also von überall verfügbar, zu installieren:

npm install -g aws-cdk

Als Nächstes sollte das Bootstrapping [6] erfolgen. Dabei handelt es sich um das Erstellen von Zusatzdiensten, die das CDK für seine Arbeit benötigt. Dieses Bootstrap-Kommando bereitet den AWS-Account für die Nutzung des CDK vor:

cdk bootstrap

In einem beliebigen Ordner lässt sich dann das eigentliche CDK-Projekt in TypeScript erstellen. Dazu dient der init-Befehl, der das Grundgerüst einer CDK-Anwendung in einer Programmiersprache nach Wahl erstellt. Diese Codezeile erzeugt ein Grundgerüst für eine CDK-Anwendung in TypeScript:

cdk init sample-app --language typescript

Dreh- und Angelpunkt ist die *-stack.ts-Datei im Ordner lib (die Bezeichnung hängt vom Namen des Projektordners ab). Hier ist bereits ein Stack, also eine Gruppierung von Diensten und Infrastruktur, vordefiniert. Über den init-Befehl wurde hier bereits ein Beispiel-Stack mit einem Amazon SNS Topic und angeschlossener Amazon SQS Queue angelegt. Der Inhalt der Datei wird nun mit dem in Listing 1 gezeigten Code ersetzt. Das vollständige, lauffähige Projekt steht auf GitHub zur Verfügung [7]. 

/*!
 * Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
 * SPDX-License-Identifier: MIT-0
*/

import { Duration, Stack, StackProps, CfnOutput } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as ec2 from 'aws-cdk-lib/aws-ec2'
import * as autoscaling from 'aws-cdk-lib/aws-autoscaling'
import * as loadbalancing from 'aws-cdk-lib/aws-elasticloadbalancingv2'
const fs = require('fs');

export class WebAppStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const vpc = new ec2.Vpc(this, 'MyVPC')

    const asg = new autoscaling.AutoScalingGroup(this, 'MyASG', {
      vpc: vpc,
      instanceType: ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE3, ec2.InstanceSize.MICRO),
      machineImage: ec2.MachineImage.latestAmazonLinux({ generation: ec2.AmazonLinuxGeneration.AMAZON_LINUX_2022 }),
      vpcSubnets: vpc.selectSubnets({ subnetType: ec2.SubnetType.PRIVATE_WITH_NAT }),
      minCapacity: 2
    })

    asg.addUserData(fs.readFileSync('scripts/install.sh', 'utf8'))

    const alb = new loadbalancing.ApplicationLoadBalancer(this, 'MyALB', {
      vpc: vpc,
      internetFacing: true
    })

    const listener = alb.addListener('HttpListener', {
      port: 80
    })

    listener.addTargets('Targets', {
      port: 80,
      targets: [asg]
    })

    listener.connections.allowDefaultPortFromAnyIpv4('Allow access to port 80 from the internet.')

    new CfnOutput(this, 'Hostname', { value: alb.loadBalancerDnsName })

  }
}

Listing 1: Etwa 30 Zeilen TypeScript-Code definieren einen Stack aus VPC, Auto Scaling Group und Application Load Balancer.

Der Name der Klasse (in Listing 1 WebAppStack) wird vom Namen des Projektordners abgeleitet und kann daher lokal anders lauten. Das Listing ist entsprechend anzupassen, damit es nicht zu Fehlern kommt. Zusätzlich wird im Projektordner noch ein neuer Ordner namens scripts angelegt, darin eine Datei mit dem Namen install.sh erstellt und diese mit dem Inhalt aus Listing 2 abgespeichert.

#!/bin/bash -xe

# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: MIT-0

yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
usermod -a -G apache ec2-user
chown -R ec2-user:apache /var/www
chmod 2775 /var/www
find /var/www -type d -exec chmod 2775 {} \;
find /var/www -type f -exec chmod 0664 {} \;
echo '<html><head><title>Hello World!</title></head><body><p>Hello World!</p></body></html>' > /var/www/html/index.html

Listing 2: Ein Bash-Skript installiert den Apache-HTTP-Server, konfiguriert ihn als dauerhaft laufenden Dienst und fügt eine statische HTML-Seite hinzu.

Bei Listing 2 handelt es sich um Installationsskript, das beim ersten Start der EC2-Instanzen einen Webserver installiert und eine "Hello World!"-HTML-Seite hinterlegt. Beim Zugriff auf diesen lässt sich später nachvollziehen, dass die EC2-Instanzen wie gewünscht laufen und das Beispiel "Ende zu Ende" funktioniert. 

Um den Stack in der Cloud aufzusetzen, müssen nun nur noch zwei Dinge geschehen: Zunächst ist es nötig, den TypeScript-Code zu kompilieren. Dafür ist bereits ein passendes Skript hinterlegt. Das build-Kommando aktiviert das vorgegebene Skript zum Kompilieren des TypeScript-Codes zu JavaScript:

npm run build

Danach lässt sich der Stack per CDK CLI in der Cloud installieren. Das deploy-Kommando weist das CDK an, den in TypeScript definierten Stack in der Cloud aufzubauen:

cdk deploy

Im Verlauf wird das CDK CLI sicherheitsrelevante Änderungen auflisten und fragen, ob es die Änderungen anwenden soll. Nach der Bestätigung übergibt das CLI das synthetisierte CloudFormation-Template an den gleichnamigen Cloud-Service zur Umsetzung. Der Aufbau der einzelnen Komponenten lässt sich weiterhin auf der Kommandozeile verfolgen, bis das CLI die Fertigstellung meldet. Am Ende erscheint eine Variable Hostname als Ausgabe, die den DNS-Namen des Load Balancer darstellt. Sie lässt sich in den Browser eingeben, um die Test-Website anzuzeigen. Der Zugriff sollte per HTTP erfolgen, HTTPS wurde für dieses Beispiel nicht konfiguriert. Zu Beginn kann es dabei vorkommen, dass ein HTTP-Code den Fehler 502 zurückgibt, weil die EC2-Instanzen noch nicht bereit sind oder die Installation des Webservers noch nicht abgeschlossen ist. In diesem Fall sollte nach einigen Minuten ein erneuter Versuch erfolgen.

Das synthetisierte Template lässt sich im Order cdk.out als Datei mit der Endung .template.json inspizieren. Dieses Template ist aufgrund zusätzlicher Metadaten, die das CDK benötigt, mit rund 1000 Zeilen sogar noch länger als die zuvor erwähnten 300 Zeilen. Tatsächlich wurden aber nur etwa 30 Zeilen TypeScript-Code zu dem Projekt hinzugefügt. Das CDK hat das Template dann automatisch generiert. Das ist möglich, weil in die verwendeten Constructs viele sinnvolle Standardeinstellungen bereits eingebaut sind und die zusätzlichen Hilfsfunktionen typische Konfigurationsmuster abkürzen.

Der Code im Detail

Es folgt eine detaillierte Erklärung zum Code des Stacks. Zuerst sind einige Abhängigkeiten einzufügen, darunter mehrere AWS Construct Libraries [8] (Listing 3).

import { Duration, Stack, StackProps, CfnOutput } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as ec2 from 'aws-cdk-lib/aws-ec2'
import * as autoscaling from 'aws-cdk-lib/aws-autoscaling'
import * as loadbalancing from 'aws-cdk-lib/aws-elasticloadbalancingv2'
const fs = require('fs');

Listing 3: Die importierten AWS Construct Libraries für EC2, Auto Scaling und Load Balancing sind Teil der CDK-Hauptbibliothek.

Die AWS Construct Libraries enthalten die bereits erwähnten Constructs-Klassen, die die Infrastruktur repräsentieren. Eine Besonderheit ist, dass Constructs unterschiedlich komplex beziehungsweise intelligent sein können. Diese Eigenschaft heißt Layer. Layer-1-Constructs entsprechen genau der Ressource aus dem IaC-Werkzeug CloudFormation und umfassen keine zusätzlichen Funktionen. Layer-2-Constructs sind deutlich interessanter: Sie repräsentieren ebenfalls AWS-Ressourcen, bieten aber eine höhere Abstraktion mit Standardwerten, typischen Konfigurationsmustern und Hilfsfunktionen. Im Beispiel aus Listing 1 sind hauptsächlich Constructs vom Typ Layer 2 vorhanden. Wie einfach es Layer-2-Constructs machen, Infrastruktur zu definieren und sinnvoll zu konfigurieren, zeigt die folgende Zeile in der Constructor-Funktion des Stacks. Dank eingebauter, sinnvoller Voreinstellungen lässt sich ein privates Netzwerk (VPC) mit nur dieser einen Zeile Code erstellen:

const vpc = new ec2.Vpc(this, 'MyVPC')

Das vpc Construct übernimmt das Erstellen und Konfigurieren der Virtual Private Cloud (VPC), also des privaten Netzwerks. Beim Eintippen in der eigenen IDE macht die Inline-Dokumentation deutlich [9], was das Construct leistet. So setzt es ohne weiteres Zutun eine VPC nach Best Practices mit privaten und öffentlichen Subnetzen über mehrere Availability Zones auf. Nur zwei Parameter sind zwingend zu übergeben: eine Referenz zum darüber liegenden Construct (oft ist das der Stack) und ein eindeutiger Name. Generell benötigen alle Constructs diese beiden Parameter.

Als Nächstes wird die Auto Scaling Group definiert. Wie für die VPC wird dazu eine Construct-Klasse instanziiert, nur sind diesmal einige zusätzliche Parameter zu übergeben (Listing 4).

    const asg = new autoscaling.AutoScalingGroup(this, 'MyASG', {
      vpc: vpc,
      instanceType: ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE3, ec2.InstanceSize.MICRO),
      machineImage: ec2.MachineImage.latestAmazonLinux({ generation: ec2.AmazonLinuxGeneration.AMAZON_LINUX_2022 }),
      vpcSubnets: vpc.selectSubnets({ subnetType: ec2.SubnetType.PRIVATE_WITH_NAT }),
      minCapacity: 2
    })

Listing 4: Hilfsfunktionen und vordefinierte Enums vereinfachen die Definition der Auto Scaling Group.

Zum einen ist das vpc-Objekt erforderlich. Zum anderen müssen die Angabe des Instanztyps und die des zu startenden Images folgen. Das Beispiel verwendet den Burstable-Typ [10], der besonders kostengünstig ist. Als Image kommt das neueste Amazon Linux 2022 [11] zum Einsatz. Es ist nicht nötig, die Konfigurationswerte händisch auszuschreiben. Stattdessen stehen Hilfsfunktionen wie InstanceType.of() und MachineImage.latestAmazonLinux() zur Verfügung, die Enums wie InstanceClass.BURSTABLE3 aufnehmen. Das reduziert Fehler und die für das Suchen nach korrekten Werten benötigte Dauer.

Zudem wird noch angegeben, in welchen Subnetzen die EC2-Instanzen laufen sollen. Auch hierfür gibt es eine praktische Hilfsfunktion selectSubnets(), um die privaten Subnetze explizit auszuwählen. Zuletzt wird mittels minCapacity noch festgelegt, dass mindestens zwei Instanzen zu jeder Zeit aktiv sein sollen.

Als Nächstes folgt das Hinzufügen des Installationsskripts für den Webserver als User Data [12] für die Autoscaling Group. Die Instanzen führen beim Hochfahren das übergebene Skript aus, um den Webserver zu installieren. Dafür bietet die AutoScalingGroup-Klasse eine passende Hilfsfunktion.

asg.addUserData(fs.readFileSync('scripts/install.sh', 'utf8'))

Die Funktion addUserData() erwartet einen String, aber das Skript ist als separate Datei gespeichert. Deswegen kommt die eingebaute fs-Bibliothek von Node.js zum Einsatz, um die Datei zuvor zu lesen. Für Node.js-Entwicklerinnen und -Entwickler ist das intuitiv. 

Jetzt fehlt nur noch der Application Load Balancer, um die Architektur zu vervollständigen. Dem ApplicationLoadBalancer-Construct wird erneut die VPC übergeben. Zudem wird der Load Balancer so konfiguriert, dass er aus dem Internet erreichbar ist. Danach sind mehrere Hilfsfunktionen daran beteiligt, die Ports des Load Balancer mit den Instanzen der Auto Scaling Group zu verknüpfen. So öffnet addListener() den HTTP-Port am Load Balancer, und addTargets() verknüpft ihn mit den entsprechenden Ports der EC2-Instanzen. Zuletzt konfiguriert allowDefaultPortFromAnyIpv4() die Security Groups so, dass eingehender Datenverkehr aus dem Internet erlaubt ist (Listing 5).

const alb = new loadbalancing.ApplicationLoadBalancer(this, 'MyALB', {
      vpc : vpc,
      internetFacing : true
    })
    
    const listener = alb.addListener('HttpListener', {
      port: 80
    })
    
    listener.addTargets('Targets', {
      port: 80,
      targets: [asg]
    })
    
    listener.connections.allowDefaultPortFromAnyIpv4('Allow access to port 80 from the internet.')

Listing 5: Die "sprechenden" Hilfsfunktionen des CDK lassen die eigentliche Intention schneller erkennen.

Die letzte Zeile des Stacks ist nicht zwingend notwendig, vereinfacht es aber, den Hostnamen des Load Balancer zu erfahren. Die Klasse CfnOutput ermöglicht es, nach dem Deployment des CloudFormation-Templates weitere Informationen über die Infrastruktur auszugeben. In diesem Fall soll der Wert für die selbsterklärende Eigenschaft loadBalancerDnsName als Ausgabe erscheinen. Mit der nachfolgenden Zeile gibt das CDK CLI nach Fertigstellung der Infrastruktur in der Cloud den Hostnamen des Load Balancer aus:

    new CfnOutput(this, 'Hostname', {value:
alb.loadBalancerDnsName})

Haben klassische IaC-Werkzeuge ausgedient?

Im Beispiel entsteht mit dem Cloud Development Kit eine Infrastruktur in 30 Zeilen, die in einem traditionellen IaC-Werkzeug mindestens 300 Zeilen beansprucht. Sind damit die Tage von CloudFormation und Terraform gezählt? Die Antwort ist ein klares Nein. Das CDK ist insbesondere für Kenner einer der unterstützten Programmiersprachen wie TypeScript interessant. Zudem hat das Beispiel gezeigt, dass Constructs mächtige Abstraktionen sind, die das Erstellen einer Architektur schneller und in höherer Qualität ermöglichen. Trotzdem bleiben die bestehenden, deklarativen Werkzeuge wie CloudFormation und Terraform relevant. Für sie gibt es unzählige Informationsquellen und bestehendes Know-how. Teams sollten also nach ihren Fähigkeiten und Vorlieben wählen, statt einem Mandat für ein bestimmtes Werkzeug zu folgen.

Erste eigene Schritte mit dem Cloud Development Kit

Das CDK ermöglicht es, Infrastruktur mit universellen Programmier- statt Konfigurationssprachen zu beschreiben. Ob das CDK für den eigenen Anwendungsfall interessant ist, lässt sich am einfachsten durch einen Test herausfinden. Dafür bietet sich der bereits erwähnte CDK-Workshop [13] als Einstieg an. Das Construct Hub [14] bietet Erweiterungen für alle drei Arten des CDK. Zu guter Letzt lohnt sich ein tieferer Einstieg in die Open-Source-Community hinter dem Cloud Development Kit. Hier ist beispielsweise der CDK Day [15] als eine von der Community organisierte, jährliche Veranstaltung zu empfehlen. Die einzelnen Vorträge werden aufgezeichnet und sind auf YouTube abrufbar [16].

Robert Hoffmann
hat zuvor bei der Deutschen Telekom als Lead Architect für Cloud-native Sprachassistenten gearbeitet, aktuell ist er Solutions Architect bei AWS und unterstützt die weltweit größten Sportmarken bei ihrer Reise in der Cloud. Er beschäftigt sich am liebsten mit Cloud-nativen Apps, Observability und dem Data Mesh.

(mai [17])

URL dieses Artikels:
https://www.heise.de/-7264489

Links in diesem Artikel:
[1] https://aws.amazon.com/de/cdk/
[2] https://cdk8s.io/
[3] https://www.terraform.io/cdktf
[4] https://cdkworkshop.com/15-prerequisites.html
[5] https://portal.aws.amazon.com/billing/signup
[6] https://docs.aws.amazon.com/de_de/cdk/v2/guide/bootstrapping.html
[7] https://github.com/aws-samples/aws-cdk-web-app-example
[8] https://docs.aws.amazon.com/cdk/api/v2/docs/aws-construct-library.html
[9] https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2.Vpc.html#initializer
[10] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html
[11] https://aws.amazon.com/de/linux/amazon-linux-2022
[12] https://docs.aws.amazon.com/de_de/AWSEC2/latest/UserGuide/user-data.html
[13] https://cdkworkshop.com/15-prerequisites.html
[14] https://constructs.dev/
[15] https://www.cdkday.com/
[16] https://www.youtube.com/c/cdkday
[17] mailto:mai@heise.de

Copyright © 2022 Heise Medien