Grundlagen & Einstieg

Cloud-Administrator werden: Was sich ändert, wenn du aus dem Rechenzentrum kommst

Der größte Teil deines Wissens bleibt wertvoll, du greifst nur nicht mehr selbst zu. Netzwerk, Identitäten, Sicherung und Kapazitätsplanung gibt es weiterhin, sie liegen hinter Schnittstellen statt hinter Racks. Wirklich neu sind zwei Dinge: Jede Änderung kostet ab der ersten Minute Geld, und du beschreibst sie in Dateien statt sie zu klicken. Wer diese beiden Punkte annimmt, ist in drei bis sechs Monaten arbeitsfähig.

5 Kapitel mit allen Befehlen
Einsteigerin in die Cloud-Administration an zwei Monitoren mit Dashboards
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum der Umstieg mehr Umdenken als Nachlernen ist

Wer aus dem eigenen Rechenzentrum kommt, bringt genau das mit, was in der Cloud knapp ist: ein Gefühl dafür, wie Systeme im Betrieb kaputtgehen. Trotzdem fühlt sich der erste Monat wie ein Rückschritt an. Die gewohnten Handgriffe fehlen, der Weg zum Ziel führt über Konsolen, Kommandozeilen und Vorlagen, und für jedes bekannte Konzept gibt es zwei neue Namen, je nach Anbieter. Das Wissen ist nicht entwertet, es ist nur anders verpackt und heißt anders.

Der eigentliche Bruch liegt woanders. Im Rechenzentrum ist Kapazität gekauft und ein Fehler kostet Zeit. In der Cloud ist Kapazität gemietet und ein Fehler kostet ab der ersten Minute Geld. Eine vergessene Testumgebung, eine zu groß gewählte Datenbank oder ein NAT-Gateway, durch das versehentlich der gesamte Sicherungsverkehr läuft, tauchen erst auf der Monatsrechnung auf. Kostenbewusstsein ist damit keine kaufmännische Nebensache, sondern ein Teil der Betriebsverantwortung, der vorher niemandem gehörte.

Der zweite Bruch ist die Arbeitsweise. Was im Portal zusammengeklickt wird, lässt sich weder nachvollziehen noch identisch in einer zweiten Umgebung aufbauen noch nach einem Zwischenfall wiederherstellen. Deshalb ist Infrastructure as Code in der Cloud keine Kür für große Häuser, sondern die Arbeitsgrundlage. Terraform, Bicep oder CloudFormation ersetzen die Dokumentation, die vorher niemand gepflegt hat. Wer diesen Schritt aufschiebt, hat nach einem Jahr eine Umgebung, die keine einzelne Person mehr vollständig kennt.

Miniatur-Szene: Treppe aus drei Stufen hinauf zu einer schwebenden Cloud, Laptop und Wegweiser

Der Umstieg in fünf Etappen

  1. 01 Dienst- und Preismodell des Anbieters verstehen
  2. 02 Konto, Zugang und Rollen sauber einrichten
  3. 03 Erste Umgebung über die Kommandozeile aufbauen
  4. 04 Dieselbe Umgebung als Code beschreiben und wiederholen
  5. 05 Überwachung, Sicherung und Kostenkontrolle ergänzen
Was du mitnimmst

Was bleibt, was wegfällt, was neu dazukommt

Der Umstieg gelingt schneller, wenn du dein vorhandenes Wissen sortierst statt es infrage zu stellen. Ein großer Teil gilt unverändert weiter, ein kleinerer Teil wird ersetzt, und der wirklich neue Anteil ist überschaubar.

Was unverändert wertvoll bleibt

Netzwerkverständnis ist in der Cloud sogar wichtiger als vorher, weil Adressbereiche, Routen und Namensauflösung dort nicht sichtbar verkabelt sind. Dasselbe gilt für Sicherungs- und Wiederanlaufkonzepte, für Berechtigungsmodelle, für Fehlersuche unter Last und für die Fähigkeit, eine Störung strukturiert einzugrenzen. Auch Skripting und Linux-Kenntnisse zahlen sich unmittelbar aus, weil die meisten Arbeitslasten weiterhin Linux sind.

Was wegfällt

Hardwarebeschaffung, Verkabelung, Firmwarestände, Hypervisor-Betrieb und der nächtliche Tausch defekter Netzteile. Damit verschwindet auch ein Teil der Planung, denn Kapazität wird nicht mehr für drei Jahre gekauft, sondern bei Bedarf angefordert. Was bleibt, ist eine andere Form von Grenze: Kontingente je Konto und Region, die du kennen musst, bevor ein Rollout mitten in der Nacht daran scheitert.

Infrastructure as Code ist die neue Grundfertigkeit

Ressourcen werden beschrieben, nicht geklickt. Terraform ist anbieterübergreifend verbreitet, Bicep ist der schlanke Weg für reines Azure, CloudFormation der hauseigene Weg bei AWS. Wichtiger als das Werkzeug ist die Gewohnheit: Jede Änderung läuft über eine Datei in der Versionsverwaltung, ein Prüflauf zeigt vorher, was passieren wird, und die Umgebung ist jederzeit reproduzierbar.

Identität ersetzt den Netzwerkrand

Im Rechenzentrum schützt die Firewall, in der Cloud entscheidet die Rolle. Wer welche Ressource anfassen darf, wird über Rollen, Richtlinien und kurzlebige Anmeldedaten geregelt, nicht über Standort und Kabel. Auf der AWS-Seite heißt das IAM, auf der Microsoft-Seite Entra ID mit rollenbasierter Zugriffssteuerung. Beides zu beherrschen ist kein Spezialthema der Sicherheitsabteilung, sondern Tagesgeschäft.

Kosten sind Betriebsdaten

Ein Cloud-Administrator liest die Kostenaufstellung genauso regelmäßig wie die Auslastungsgrafik. Dazu gehören die Kennzeichnung aller Ressourcen, Budgetalarme, das Erkennen ungenutzter Datenträger und öffentlicher Adressen sowie das Wissen, welche Dienste nach Anfragen und welche nach Laufzeit abrechnen. Diese Aufgabe hatte im Rechenzentrum niemand, und sie steht heute in Stellenausschreibungen ausdrücklich drin.

Ein Anbieter reicht für den Anfang

Lerne einen Anbieter richtig, statt zwei halb. Die Konzepte übertragen sich danach in wenigen Wochen, weil Netzwerk, Identität, Speicher und Rechenleistung überall dieselben Fragen stellen. Welcher es wird, entscheidet meistens das Umfeld: Wo Microsoft 365 und Active Directory stehen, führt der Weg über Azure, in stark automatisierten Umgebungen mit viel Linux häufiger über AWS.

Tutorial

Die ersten Wochen in einer Cloud-Umgebung, Schritt für Schritt

Der größte Teil deines Wissens bleibt wertvoll, wirklich neu sind zwei Dinge: Jede Änderung kostet ab der ersten Minute Geld, und du beschreibst sie in Dateien, statt sie zu klicken. Genau das üben die folgenden Schritte: anmelden und den Bestand lesen, eine erste Umgebung von Hand anlegen, sie anschließend als Code beschreiben, Rechte und Grenzen verstehen und am Ende wieder aufräumen. Die Befehle stehen für Azure und für AWS nebeneinander, und alle Beispiele laufen in einer Übungsumgebung.

01

Schritt 1: Zugang einrichten und den Bestand lesen

Bevor du etwas anlegst, verschaffst du dir Klarheit darüber, wo du gerade bist. Beide Anbieter beantworten die Frage, wer du bist und was schon existiert, in wenigen Befehlen.

Anmelden und den eigenen Kontext prüfen
# Azure
az login
az account show --output table
az account list --output table
az group list --output table

# AWS: Anmeldung ueber IAM Identity Center statt ueber Zugriffsschluessel
aws configure sso
aws sts get-caller-identity
aws ec2 describe-regions --query 'Regions[].RegionName' --output text

Mach dir az account show und aws sts get-caller-identity zum ersten Reflex. Der häufigste Anfängerfehler ist, in der falschen Subskription oder im falschen Konto zu arbeiten, und beide Befehle klären das in einer Sekunde.

Bestand abfragen, ohne durch das Portal zu klicken
# Azure Resource Graph: alle virtuellen Maschinen mit Groesse und Region
az graph query -q "Resources
  | where type =~ 'microsoft.compute/virtualmachines'
  | project name, location, properties.hardwareProfile.vmSize" --output table

# AWS: laufende Instanzen samt Typ und Zone
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType,Placement.AvailabilityZone]' \
  --output table

az graph query braucht die Erweiterung resource-graph, die beim ersten Aufruf angeboten wird. Über den Resource Graph fragst du alle Subskriptionen gleichzeitig ab, während az resource list je Subskription einzeln arbeitet und bei größeren Umgebungen spürbar länger dauert.

02

Schritt 2: Die erste Umgebung anlegen

Netzwerk zuerst, Rechenleistung danach. Diese Reihenfolge gilt in der Cloud genauso wie im Rechenzentrum, nur legst du das Netz in Sekunden an statt in Wochen.

Azure: Ressourcengruppe, Netz und Maschine
az group create --name rg-lab --location germanywestcentral

az network vnet create --resource-group rg-lab --name vnet-lab \
  --address-prefixes 10.20.0.0/16 \
  --subnet-name snet-app --subnet-prefixes 10.20.1.0/24

az vm create --resource-group rg-lab --name vm-app01 \
  --image Ubuntu2404 --size Standard_B2s \
  --vnet-name vnet-lab --subnet snet-app \
  --public-ip-address "" --generate-ssh-keys

--public-ip-address "" legt die Maschine bewusst ohne öffentliche Adresse an, der Zugang läuft dann über Azure Bastion oder eine bestehende Verbindung ins Netz. Eine automatisch vergebene öffentliche Adresse ist die häufigste unbeabsichtigte Öffnung nach außen.

AWS: dasselbe mit VPC, Sicherheitsgruppe und Instanz
aws ec2 create-vpc --cidr-block 10.30.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=vpc-lab}]'

aws ec2 create-subnet --vpc-id vpc-0123456789abcdef0 --cidr-block 10.30.1.0/24

aws ec2 create-security-group --group-name sg-app \
  --description "App-Schicht" --vpc-id vpc-0123456789abcdef0

aws ec2 run-instances --image-id ami-0123456789abcdef0 \
  --instance-type t3.small --subnet-id subnet-0123456789abcdef0 \
  --security-group-ids sg-0123456789abcdef0 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Umgebung,Value=lab},{Key=Kostenstelle,Value=4711}]'

Kennzeichne jede Ressource schon beim Anlegen. Kostenstellen nachträglich zu ergänzen, ist Fleißarbeit für Wochen, und ohne Kennzeichnung lässt sich die Rechnung später nicht auf Teams aufteilen. Wie daraus ein durchgehender Prozess wird, steht unter FinOps einführen.

03

Schritt 3: Vom Klick zum Code

Alles, was du bis hier von Hand angelegt hast, gehört anschließend in eine Datei. Erst dann ist die Umgebung wiederholbar, prüfbar und vollständig löschbar.

main.tf
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "lab" {
  name     = "rg-lab"
  location = "germanywestcentral"

  tags = {
    umgebung     = "lab"
    kostenstelle = "4711"
  }
}

Der Zustand von Terraform gehört nicht auf den Laptop. Lege ihn in einem Speicherkonto oder in einem S3-Bucket mit Versionierung und Sperre ab, sobald mehr als eine Person arbeitet, sonst überschreiben sich zwei gleichzeitige Läufe gegenseitig und der Zustand passt nicht mehr zur Wirklichkeit.

Der immer gleiche Dreiklang
terraform init
terraform plan -out=tfplan      # zeigt vorher, was passieren wuerde
terraform apply tfplan          # fuehrt genau diesen Plan aus

terraform destroy               # raeumt die Uebungsumgebung vollstaendig ab

# Azure ohne Zustandsdatei, direkt gegen die Ressourcenverwaltung
az deployment group create --resource-group rg-lab \
  --template-file main.bicep --parameters umgebung=lab

plan -out und danach apply mit genau dieser Datei ist die Gewohnheit, die dich vor Überraschungen schützt. Ein apply ohne gespeicherten Plan kann etwas anderes tun, als du im Prüflauf gesehen hast, weil sich die Umgebung zwischenzeitlich geändert haben kann.

Für reines Azure ist Bicep die schlankere Alternative, weil es ohne eigene Zustandsdatei auskommt und direkt gegen die Ressourcenverwaltung arbeitet. Terraform lohnt sich, sobald mehrere Anbieter oder Dienste außerhalb der Cloud dazukommen. Welches Werkzeug bei euch passt, hängt weniger an der Sprache als an der Anzahl der Zielsysteme, siehe dazu den Vergleich der Werkzeuge für Infrastructure as Code.

04

Schritt 4: Rechte vergeben und Grenzen kennen

In der Cloud ersetzt die Rollenzuweisung den Zugang zum Serverraum. Vergib Rechte auf der kleinstmöglichen Ebene und über Gruppen statt über Personen.

Rolle auf die Ressourcengruppe statt auf die Subskription
SCOPE=$(az group show --name rg-lab --query id -o tsv)
GRUPPE=$(az ad group show --group 'team-app' --query id -o tsv)

az role assignment create \
  --assignee-object-id "$GRUPPE" \
  --assignee-principal-type Group \
  --role "Virtual Machine Contributor" \
  --scope "$SCOPE"

az role assignment list --scope "$SCOPE" --output table

Rechte auf Subskriptionsebene sind bequem und im Audit nicht zu rechtfertigen. Sie später zurückzunehmen, kostet deutlich mehr Abstimmung, als sie von Anfang an auf Ressourcengruppen zu begrenzen. Auf der AWS-Seite gilt dasselbe für Richtlinien mit Resource: "*".

Bekannte Begriffe und ihre Entsprechung bei beiden Anbietern

Im RechenzentrumAzureAWS
VLAN und SubnetzVNet mit SubnetzVPC mit Subnetz
Firewallregel am PortNetzwerksicherheitsgruppeSicherheitsgruppe und Network ACL
Standortkopplung über MPLSExpressRoute oder VPN GatewayDirect Connect oder Site-to-Site VPN
Active DirectoryEntra ID, für klassisches AD zusätzlich Domain ServicesIAM Identity Center, AD Connector
SAN-VolumeManaged DiskEBS-Volume
DateifreigabeAzure FilesAmazon EFS oder FSx
BandsicherungAzure Backup mit Recovery Services TresorAWS Backup
AusweichrechenzentrumVerfügbarkeitszone und RegionAvailability Zone und Region
05

Schritt 5: Überwachen, sichern, abräumen

Der letzte Schritt ist der, den Umsteigende am häufigsten vergessen. Was du zum Üben angelegt hast, läuft weiter und wird abgerechnet, bis du es aktiv löschst.

Kosten ansehen und die Übungsumgebung abräumen
# AWS: was kostet gerade welcher Dienst?
aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# Azure: bestehende Budgets pruefen
az consumption budget list --output table

# Uebungsumgebung vollstaendig entfernen
az group delete --name rg-lab --yes --no-wait
terraform destroy

Das Löschen über die Ressourcengruppe ist in Azure der zuverlässigste Weg, weil verwaiste Datenträger, Netzwerkschnittstellen und öffentliche Adressen mitgehen. In AWS gibt es diese Klammer nicht, dort räumst du über CloudFormation-Stacks oder über Terraform ab, sonst bleiben Reste liegen, die weiter abgerechnet werden.

Die ersten neunzig Tage

  • Mit den Grundlagen des gewählten Anbieters anfangen, nicht mit der Administratorprüfung.Ohne Dienst-, Regions- und Preismodell im Kopf lernst du Befehle auswendig, statt Entscheidungen zu verstehen. Zwei Tage Grundlagen sparen später Wochen an Missverständnissen.
  • Ein eigenes Übungskonto mit eigenem Budgetalarm anlegen.Üben in der Produktivumgebung ist der schnellste Weg zu einem Zwischenfall. Der Budgetalarm verhindert, dass eine vergessene Maschine über den Urlaub hinweg mehrere hundert Euro kostet.
  • Jede Übung zweimal machen, einmal im Portal und einmal als Code.Das Portal erklärt die Zusammenhänge, der Code macht sie wiederholbar. Wer nur klickt, kann nichts übergeben, wer nur kopiert, versteht die Fehlermeldungen nicht.
  • Kostenaufstellung und Kontingente wöchentlich ansehen.Beides ist gegenüber dem Rechenzentrum neu und beides bringt Rollouts zu Fall. Eine Viertelstunde pro Woche reicht, um die Fallen zu kennen, bevor sie zuschnappen.
  • Eine Zertifizierung als Zielmarke setzen, aber erst nach der ersten eigenen Umgebung.Die Vorbereitung ordnet vorhandenes Wissen. Ohne eigene Berührung mit der Plattform lernst du Fragenkataloge, und das hält weder im Fachgespräch noch im Betrieb.
Gut zu wissen

Häufige Fragen zu Cloud-Administration

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Wie lange dauert der Umstieg realistisch?
Mit Vorerfahrung aus dem Rechenzentrum und ein paar Stunden pro Woche brauchst du etwa drei bis sechs Monate, bis du eine überschaubare Umgebung eigenständig betreibst. Der Grundlagenkurs klärt Dienst- und Preismodell in zwei Tagen, der Administratorkurs die tägliche Arbeit in vier bis fünf. Den Rest macht Übung an einer eigenen Umgebung. Wer nur Kurse besucht und nie selbst etwas anlegt, bleibt hängen, weil die Fehlermeldungen der Anbieter selten erklären, was gemeint ist. Rechne fest damit, dass ein Drittel der Zeit auf Netzwerk und Berechtigungen entfällt.
Brauche ich Programmierkenntnisse?
Entwickeln musst du nicht, lesen und ändern schon. Der Alltag besteht aus Kommandozeile, YAML- oder HCL-Dateien, gelegentlich PowerShell oder Bash und dem Umgang mit Git. Wer im Rechenzentrum bereits Skripte gepflegt hat, bringt genug mit. Tatsächlich neu zu lernen sind zwei Dinge: Versionsverwaltung als Arbeitsweise und der Umgang mit einem Prüflauf vor der Änderung. Beides ist in ein bis zwei Wochen erlernbar und danach das wichtigste Werkzeug, weil jede Änderung an der Umgebung darüber läuft.
AWS oder Azure zuerst?
Entscheide nach dem Umfeld, nicht nach Sympathie. Wo Microsoft 365, Active Directory und Windows Server das Rückgrat bilden, ist Azure der kürzere Weg, weil Identitäten und Verwaltung ohnehin dorthin zeigen. In Umgebungen mit viel Linux, Containern und Automatisierung ist AWS häufiger gesetzt. Beherrschst du einen Anbieter, überträgt sich der Großteil in wenigen Wochen, weil Netz, Identität, Speicher und Rechenleistung überall dieselben Fragen stellen. Beide gleichzeitig zu lernen, verlängert den Einstieg dagegen spürbar und bringt in Bewerbungsverfahren nichts.
Ist eine Zertifizierung für den Einstieg nötig?
Nötig nicht, hilfreich schon, und zwar aus zwei Gründen. Erstens ordnet die Vorbereitung Wissen, das man sich sonst lückenhaft zusammensucht. Zweitens ist sie in Bewerbungsverfahren ein belastbarer Nachweis, gerade beim Wechsel aus einer anderen Rolle. Der übliche Weg führt über eine Grundlagenzertifizierung und danach über die Administratorstufe, bei Microsoft also AZ-900 und AZ-104. Setz die Prüfung aber hinter die erste eigene Umgebung, nicht davor. Wer Fragenkataloge lernt, ohne je eine Ressource angelegt zu haben, fällt spätestens im Fachgespräch auf.
Verliert meine Erfahrung aus dem Rechenzentrum an Wert?
Sie gewinnt eher, sie wird nur anders abgerufen. Adressplanung, Namensauflösung, Wiederanlaufkonzepte, Berechtigungsmodelle und strukturierte Fehlersuche sind in der Cloud genauso nötig, oft sogar strenger, weil kein Kabel mehr sichtbar macht, wie etwas verbunden ist. An Bedeutung verlieren Hardwarewissen und Hypervisor-Betrieb. Dafür kommen Kostenverantwortung und die Gewohnheit dazu, Änderungen als Code zu beschreiben. In gemischten Umgebungen, und das sind die meisten deutschen Häuser, ist genau diese Kombination aus beiden Welten gefragt.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Rückmeldung aus dem Kurs „Ansible Kompaktkurs“
Der Kurs hat sein Ziel erreicht. Der Trainer konnte die Inhalte gut rüberbringen und der Praxisanteil und die Übungsumgebung war sehr gut.
Rückmeldung aus dem Kurs „Terraform mit Azure – Der kompakte Praxiskurs für Ihren Cloud-Erfolg“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Den Umstieg mit einem Plan angehen statt mit Videos

Auf dem Microsoft-Weg beginnt der Pfad mit AZ-900 für die Grundlagen und führt über AZ-104 zur Rolle des Azure-Administrators. Auf der AWS-Seite starten die meisten mit AWS Cloud Practitioner Essentials, vertiefen mit AWS Technical Essentials und steigen mit Cloud Operations on AWS in den Betrieb ein. Wer lieber anbieterübergreifend einsteigt, findet in den technischen Grundlagen zu Amazon Web Services den Überblick. Alle Kurse laufen Live-Online oder in Präsenz. Sag uns, wo du herkommst, dann sortieren wir den Weg gemeinsam.