Day in the Life of a Cloud Engineer

Du willst wissen, wie ein Arbeitstag als Cloud Engineer wirklich aussieht, nicht die Version von der Karriereseite. Die ehrliche Antwort: viel mehr Abstimmung, viel mehr Dokumentation und deutlich weniger Terraform schreiben, als du denkst. Hier ist ein realistischer Tag auf Mid-Level, plus die Unterschiede zu Junior und Senior.

Ich beschreibe einen typischen Dienstag. Kein besonderer Tag, kein Incident, keine Produktneinführung. Genau so läuft die meiste Zeit ab.

Der Morgen: Tickets, Slack, erste Priorität#

08:15 Uhr. Laptop auf, Slack zu, erstmal die Nacht sichten. In der Regel liegen drei bis fünf neue Nachrichten im Team-Channel und ein bis zwei Alerts im Monitoring. Die meisten sind kein Notfall. Eine Pipeline ist rot gelaufen, weil ein Secret abgelaufen ist. Das ist in zehn Minuten gefixt.

08:45 Uhr. Standup, 15 Minuten geplant, in Wirklichkeit oft 20. Du sagst, woran du arbeitest, wo du hängst, was andere wissen müssen. Danach klärt sich noch eine Kleinigkeit im Anschluss, die in der Runde zu lang gedauert hätte.

Ab 09:15 Uhr beginnt das, was im Kalender als Deep Work steht. Realistisch sind das 60 bis 90 Minuten am Stück, bevor die nächste Unterbrechung kommt. In dieser Zeit arbeitest du an einem Ticket, das etwas Tieferes braucht: zum Beispiel eine bestehende AWS-Landschaft so umzubauen, dass die Datenbank in ein anderes VPC migriert, ohne dass die Anwendung merklich ausfällt.

Der Satz "ohne dass die Anwendung merklich ausfällt" ist der eigentliche Auftrag. Das Schreiben der Terraform-Dateien ist die einfache Hälfte. Die schwierige Hälfte ist der Plan, wie du das machst, wer informiert werden muss und was du tust, wenn es schiefgeht.

Vormittag: die Tools, die du wirklich täglich brauchst#

Ein Cloud Engineer arbeitet nicht den ganzen Tag in der Cloud-Konsole. Tatsächlich sitzt die meiste Arbeit in anderen Oberflächen.

Das sind die Tools, die in fast jedem Team täglich vorkommen:

• Ein Terminal, meist mit zsh oder bash, für alles was schnell gehen muss
• Terraform oder ein vergleichbares Infrastructure-as-Code-Werkzeug, für reproduzierbare Infrastruktur
• Git und eine Plattform wie GitHub oder GitLab, inklusive Code-Reviews
• Ein CI/CD-System, zum Beispiel GitHub Actions, GitLab CI oder Jenkins
• Ein Monitoring-Stack, häufig Prometheus mit Grafana oder die Cloud-eigenen Dienste
• Kubernetes, meist kubectl, seltener ein Dashboard
• Ein Secrets-Manager, weil Passwörter in Konfigurationsdateien ein echtes Problem sind
• Slack, Jira oder Linear, und ein Wiki wie Confluence oder Notion

Was überrascht: Der größte Zeitaufwand geht an Dokumentation und Kommunikation. Nicht an Code. Wer das nicht mag, wird in diesem Job unglücklich.

Mittag bis Nachmittag: Reviews, Abstimmung, Kontextwechsel#

Nach dem Mittag läuft ein Code-Review an. Du liest einen Pull Request, der eine neue S3-Bucket-Policy einführt. Du kommentierst zwei Stellen: einmal fehlt eine explizite Verschlüsselungskonfiguration, einmal ist die Bucket-Policy zu weit gefasst. Das dauert keine 20 Minuten, spart dem Team aber später eine Diskussion mit dem Security-Team.

Danach ein Termin, den es in jeder größeren Firma gibt: ein Architekturgespräch mit dem Entwicklerteam. Es geht darum, wie eine neue Microservice-Applikation deployed werden soll. Du erklärst, warum ihr nicht für jeden Service ein eigenes Cluster aufsetzen solltet, und warum Managed Services zwar teurer aussehen, aber personell günstiger sind. Das ist ein Gespräch, in dem du viel erklärst und wenig baust.

14:30 Uhr. Dann kommt die Phase, die den Tag kippen kann. Ein Alert, diesmal nicht harmlos. Ein Dienst antwortet nicht mehr, das Dashboard zeigt hohe Latenzen. Jetzt zählt, wie ruhig du arbeiten kannst. Du schaust zuerst auf die Metriken, dann auf die letzten Deployments, dann auf die Logs. In den meisten Fällen ist ein Deployment von heute Morgen die Ursache, auch wenn es "nur eine kleine Änderung" war. Rollback, kurz prüfen, Ticket aufmachen, sauber dokumentieren.

So ein Incident kostet leicht zwei Stunden. Danach ist der geplante Deep-Work-Block für den Tag weg. Das ist normal, kein Versagen.

Was Neue am meisten überrascht#

Drei Dinge, die fast jeder Anfänger unterschätzt.

Erstens: Der Anteil an Meetings. Auf Mid-Level gehen 20 bis 30 Prozent der Woche für Abstimmung, Reviews und Gespräche drauf. Wer dachte, den Tag über am Bildschirm zu sitzen und Infrastruktur zu bauen, wird enttäuscht.

Zweitens: Wie viel Wissen implizit ist. Viele Abläufe stehen nirgends geschrieben, sondern leben in Köpfen oder in alten Slack-Verläufen. Deine Aufgabe ist es, dieses Wissen sichtbar zu machen. Das ist undankbar und wird selten gewürdigt, macht dich aber langfristig wertvoll.

Drittens: Wie selten etwas wirklich neu gebaut wird. Die meiste Arbeit besteht darin, bestehende Systeme zu pflegen, langsam zu verbessern und Fehler zu vermeiden. Wer ständig Neues will, muss entweder in ein junges Team oder in eine Position mit mehr Gestaltungsspielraum.

Was ändert sich von Junior zu Senior#

Als Junior bekommst du meist klar umrissene Tickets: eine neue Policy hier, eine kleine Pipeline dort. Du arbeitest Aufgaben ab, die jemand anderer grob beschrieben hat. Deep Work hast du viel, dafür wenig Einfluss auf die Richtung.

Auf Mid-Level kommt Verantwortung dazu. Du schreibst nicht mehr nur Code, du entscheidest mit, wie etwas gebaut wird. Du schreibst Konzepte, erklärst sie anderen, und du wirst gebeten, Fehler von anderen zu finden, bevor sie in Produktion gehen.

Als Senior verschiebt sich der Tag nochmal deutlich. Meetings nehmen weiter zu, oft 40 Prozent oder mehr. Dafür entscheidest du über Architektur, priorisierst technische Schulden und schützt das Team vor unnötiger Arbeit. Viel Terraform schreiben wirst du kaum noch. Wer Senior werden will, weil er dann mehr bauen kann, hat die Rechnung ohne den Job gemacht.

Zur Orientierung: Die Gehälter für Cloud Engineers in Deutschland liegen laut verbreiteten Angaben grob zwischen 55.000 und 85.000 Euro brutto im Jahr, je nach Erfahrung, Region und Verantwortung. Senior- und Lead-Rollen gehen darüber hinaus. Die Spannen variieren stark, prüfe immer die aktuellen offiziellen Quellen und aktuelle Stellenanzeigen. Ein Blick in aktuelle Cloud-Engineer-Stellenanzeigen zeigt dir, was in deiner Region konkret gefordert wird.

So bereitest du dich realistisch vor#

Wenn du in den Job willst, nimm diese Punkte ernst:

• Lerne ein Cloud-System richtig kennen, nicht alle drei oberflächlich
• Übe Infrastructure as Code, bis du ein bestehendes Projekt lesen und ändern kannst
• Lerne, wie CI/CD-Pipelines funktionieren, inklusive Debugging wenn sie scheitern
• Übe dich darin, technische Sachverhalte in einfachen Sätzen zu erklären
• Bau dir ein kleines Projekt, das du im Gespräch zeigen kannst, inklusive was schiefging
• Lies Stellenanzeigen genau, und nutze dafür einen Job-Description-Decoder, um Anforderungen sauber zu zerlegen
• Prüfe deinen Lebenslauf auf ATS-Kompatibilität, zum Beispiel mit dem kostenlosen ATS-Checker

Und lies dich ein. Auf dem Karriereblog findest du Material zu Gehaltsverhandlung, Bewerbungsprozessen und technischen Interviews, das über Standard-Ratschläge hinausgeht.

Ein Beispiel aus dem echten Arbeitsleben#

Nehmen wir eine Aufgabe, die in fast jedem Team vorkommt: Ein Entwicklerteam will seine Logs länger aufbewahren, weil sie bei Fehlern brauchbar sind. Als Junior bekommst du das als Ticket, mit der Vorgabe "Logs 90 Tage statt 30 Tage".

Ein Mid-Level Cloud Engineer macht daraus mehr. Er prüft erst die Kosten, weil 90 Tage Logs je nach Volumen teuer werden können. Er schlägt vor, Warnstufen zu trennen: Error-Logs 180 Tage, Info-Logs 30 Tage. Er dokumentiert die Entscheidung im Wiki, damit das Security-Team später nachvollziehen kann, warum so entschieden wurde. Und er baut es in Terraform so, dass das nächste Team es wiederverwenden kann.

Der Unterschied ist nicht die Technik. Der Unterschied ist, dass du über den Tellerrand der Aufgabe hinausdenkst.

Häufige Fragen#

Wie viel eines Arbeitstags geht wirklich für Meetings drauf?

Auf Mid-Level sind es typisch 20 bis 30 Prozent der Arbeitszeit, auf Senior-Niveau oft mehr. Wie viel genau hängt stark von der Firmengröße, der Teamstruktur und davon ab, wie viel Abstimmung mit anderen Abteilungen nötig ist.

Muss ich als Cloud Engineer programmieren können?

Ja, aber du wirst selten klassische Anwendungsentwicklung machen. Es geht eher um Skripte, Infrastructure-as-Code, Pipelines und das Lesen und Reparieren von Code anderer. Wer Grundkenntnisse in Python, Bash oder Go hat, hat es leichter.

Welche Cloud sollte ich zuerst lernen?

Nimm eine, meist AWS, Azure oder Google Cloud, und lerne sie richtig kennen. Tiefe in einem System ist im Gespräch mehr wert als oberflächliches Wissen über alle drei. Welche genau hängt davon ab, welche in deiner Wunschregion gefragt ist.

Wie stressig sind Incidents und Rufbereitschaften?

Es gibt Phasen mit hohem Druck, besonders wenn Produktionssysteme ausfallen. Viele Stellen haben eine Rufbereitschaft, die zusätzlich vergütet wird oder werden sollte. Wie intensiv das ist, variiert stark, frag im Gespräch konkret danach.

Wie lange dauert der Einstieg vom Quereinstieg bis zur ersten Stelle?

Das hängt sehr von deinem Vorwissen ab. Mit IT-Erfahrung sind oft sechs bis zwölf Monate gezielte Vorbereitung realistisch, ohne Vorerfahrung deutlich länger. Verlasse dich nicht auf pauschale Versprechen von Kursanbietern, sondern prüfe anhand realer Stellenanzeigen, was wirklich verlangt wird.