Was ein Cloud Security Architect wirklich den ganzen Tag macht
Wenn Leute hören: Cloud Security Architect, denken die meisten an jemanden, der den ganzen Tag Firewall-Regeln schreibt.
Das stimmt nicht. Ich schreibe Firewall-Regeln vielleicht zehn Prozent der Zeit - und auch das meistens nicht direkt, sondern als Terraform oder YAML, das dann von einem CI/CD-Pipeline ausgerollt wird.
Was ich den größten Teil des Tages mache, ist etwas anderes. Ich erkläre das hier, weil ich die Frage oft gestellt bekomme: von Studierenden, die überlegen, in welche Richtung sie sich entwickeln wollen, von Führungskräften, die nicht wissen, was sie eigentlich einstellen, wenn sie eine solche Stelle ausschreiben, und von Kollegen aus anderen Disziplinen, die sich fragen, was die Architektur-Leute eigentlich den ganzen Tag treiben.
Was den Großteil der Zeit ausmacht
Zuhören, bevor ich etwas vorschlage. Ein CISO erklärt mir, was ihn nachts wachhält. Das ist keine Rhetorik - das ist der erste Schritt, bevor ich irgendeinen AWS-Dienst empfehle. Wer mit einer fertigen Lösung in ein Gespräch geht, bevor er das Problem kennt, baut an den falschen Dingen. Das Risikobild ist immer kontextabhängig: Ein DAX-Konzern mit 40 AWS-Accounts hat andere Prioritäten als ein Mittelständler, der gerade seinen ersten Account aufgesetzt hat.
Abwägungen klarlegen. Mehr Kontrolle oder mehr Geschwindigkeit: Beides kostet etwas. Das ist keine negative Aussage - das ist die zentrale Aussage jedes Architektur-Gesprächs. Ein Zero-Trust-Netzwerkmodell erhöht die Sicherheit. Es macht auch das Onboarding neuer Services aufwändiger. Beides ist wahr. Meine Aufgabe ist nicht, eine Seite zu verkaufen, sondern die Abwägung transparent zu machen, damit die richtige Person - meistens nicht ich - eine fundierte Entscheidung treffen kann.
Compliance-Nachweise bauen, die ein Prüfer akzeptiert. BSI C5:2026 ist kein Selbstzweck. Es ist der Rahmen, in dem viele meiner Kunden operieren. Die technische Frage ist: Welche AWS-Konfigurationen, Logs und Kontrollen brauchen wir, damit ein unabhängiger Auditor bescheinigt, dass diese Umgebung die Anforderungen erfüllt? Das ist ein anderes Problem als "Wie schütze ich die Umgebung?" - es ist die Übersetzungsarbeit zwischen technischer Realität und prüfbarer Dokumentation. Diese Arbeit wird oft unterschätzt, bis der erste Audit kommt.
Architekturen dokumentieren, die in 18 Monaten noch verstanden werden. Von Leuten, die heute nicht im Raum sind. Das klingt nach Projektmanagement-Hygiene. Ist aber eine Kernkompetenz: Architektur-Entscheidungen, die man nicht dokumentiert, werden sechs Monate später neu diskutiert - meistens unter schlechteren Bedingungen. Ein Architecture Decision Record (ADR) ist nicht Bürokratie. Er ist das Langzeitgedächtnis des Systems.
Verstehen, was jemand bauen will, bevor die Architektur existiert. Das ist die Arbeit, die am wenigsten sichtbar ist und am meisten zählt. Wenn ein Entwicklungsteam sagt "Wir wollen eine serverless Data Pipeline bauen", ist meine erste Frage nicht "Welcher AWS-Dienst?", sondern: Wer greift auf die Daten zu? Mit welcher Klassifizierung? Aus welcher Jurisdiktion? Gibt es DSGVO-Relevanz? Haben wir die IAM-Struktur, die das abbildet? Architektur ohne diese Fragen produziert technische Lösungen für das falsche Problem.
YAML und Terraform schreiben. Vielleicht zehn Prozent. Das ist die sichtbarste Tätigkeit und der kleinste Zeitanteil.
Was ich gebaut habe
Bei Tallence AG baue ich konkrete Produkte: BSI C5:2026-fähige Cloud-Umgebungen für Unternehmen, AWS Managed Services Angebote für Brownfield-Accounts, und den Cloud Governance Accelerator - eine Control-Tower-basierte Landing Zone, die Governance-Anforderungen von Anfang an mitbringt statt sie nachzurüsten.
Parallel habe ich ein vollständiges SaaS-Produkt gebaut - alleine, mit AWS Kiro als agentischem Entwicklungspartner, in 52 Tagen, mit über 292.000 Netto-Codezeilen. Das war kein Expertenexperiment zum Selbstzweck. Es war eine direkte Antwort auf eine Kundenfrage: Wie schnell kann man heute mit agentic AI ein produktionsreifes Tool liefern? Die Antwort ist: schneller als die meisten Teams glauben.
Das zeigt etwas über die Rolle: Man bewegt sich zwischen Architektur-Entscheidungen auf Unternehmensebene und konkreter technischer Umsetzung. Wer nur eines der beiden kann, kann den Job machen - aber nicht gut.
Die drei Sprachen des Jobs
Was den Markt für Cloud Security Architekten prägt, ist eine Kombination, die selten vollständig in einer Person zusammenkommt.
Technisch: AWS-Dienste auf Tiefe kennen. Nicht alle, aber die relevanten: IAM, Control Tower, Organizations, Security Hub, GuardDuty, CloudTrail, Security Lake, VPC-Networking. Tiefe bedeutet: ich weiß nicht nur, was der Dienst kann, sondern wie er in einem konkreten Compliance-Kontext konfiguriert werden muss.
Compliance: BSI C5:2026, NIS2, DORA - nicht als Lexikon im Kopf, aber als Kontext für Architektur-Entscheidungen. Was bedeutet der C5-Anforderungsbereich "Kryptographie und Schlüsselmanagement" für meine KMS-Konfiguration? Welche NIS2-Anforderungen treffen auf meine Cloud-Umgebung zu? Das ist keine Security-Engineering-Frage. Das ist eine Architektur-Frage mit Compliance-Kontext.
Business: Risiko, Kosten, Geschwindigkeit in eine Sprache übersetzen, die Entscheider verstehen. Nicht jedes Security-Feature hat denselben ROI. Nicht jede Compliance-Anforderung braucht die teuerste Lösung. Ein guter Architect kann erklären, was eine Entscheidung kostet - nicht nur in Euro, sondern in Wartungsaufwand, in Abhängigkeiten, in Risiko.
Diese Kombination ist selten. Das erklärt, warum der Markt für Cloud Security Architekten so eng ist - und warum Jobbeschreibungen für diese Rollen oft entweder zu technisch oder zu vage sind.
Mein Weg: PO zu Architect
Ich werde oft gefragt, wie ich in die Rolle gekommen bin - weil mein Weg nicht dem Standardpfad folgt.
Ich habe als Product Owner bei Deutsche Telekom und T-Systems gearbeitet, auf dem Magenta Gaming Projekt ab 2020. Kein klassischer Developer-Hintergrund, der sich zum Architekten hochgearbeitet hat. Der Übergang kam durch die Arbeit an echten Projekten: AWS-Zertifizierungen als strukturiertes Framework (inzwischen zehn), Hands-on-Arbeit mit realen Infrastrukturen, und - das ist der Teil, der im Lebenslauf nicht gut sichtbar ist - ein PO-Hintergrund, der das Verständnis von Kundenanforderungen trainiert hat.
Was ein PO gut kann: Anforderungen verstehen, bevor man anfängt zu bauen. Priorisieren unter Unsicherheit. Mit Stakeholdern sprechen, die verschiedene Sprachen sprechen. Das sind genau die Fähigkeiten, die einen Cloud Security Architect von einem Cloud Security Engineer unterscheiden.
Der klassische Weg ist Developer → Architect. Mein Weg war PO → Architect. Beide funktionieren. Was zählt: ein Verständnis für Systeme von Ende zu Ende, nicht das Schreiben jeder einzelnen Schicht selbst.
Was das für die Frage nach dem Job bedeutet
Wenn ein CIO oder CISO eine Cloud Security Architect Stelle besetzt, suchen sie meistens jemanden, der AWS kennt. Was sie brauchen, ist jemand, der AWS kennt und das Unternehmen versteht. Das sind zwei verschiedene Dinge.
Die technischen Skills sind erlernbar - mit Zeit und den richtigen Zertifizierungen. Das Verständnis dafür, was ein Unternehmen schützen muss, welche Compliance-Anforderungen bindend sind, und wo die Abwägung zwischen Kontrolle und Geschwindigkeit für diesen Kunden richtig liegt: das kommt aus Erfahrung und aus Zuhören.
Wenn jemand fragt "Was macht ein Cloud Security Architect den ganzen Tag?", ist die ehrlichste Antwort: Er sorgt dafür, dass die richtigen Entscheidungen zur richtigen Zeit getroffen werden - mit dem richtigen Kontext. Das YAML schreibt er auch. Aber das ist der kleinste Teil.
Ich bin offen für Fragen zu diesem Thema - ob ihr über eine Stelle nachdenkt, eine solche Stelle besetzen wollt, oder verstehen wollt, was Cloud Security Architektur in einem konkreten Unternehmenskontext bedeutet. Direkt vernetzen oder kommentieren.