# Platform Foundations

> Deklarative Infrastruktur, Sicherheitsgrenzen und Recovery als gemeinsame Plattformverantwortung.

Track: [Cloud Infrastructure & Platform Engineering](https://physar.tech/learn/cloud-infra)  
Kanonische Fassung: https://physar.tech/learn/cloud-infra/platform-foundations  
Stand: 2026-07-30  
Interaktiver Teil: 8 Checks (nur im Browser)

## Infrastruktur ist ein versioniertes Produkt

### Deklarativ statt Erinnerung

Infrastructure as Code macht gewünschte Zustände überprüfbar, wiederholbar und reviewbar. Es ersetzt nicht die Architekturentscheidung, aber es reduziert Drift und schafft einen nachvollziehbaren Wiederherstellungsweg.

Deklarativ heißt: du beschreibst den **Zielzustand**, das Werkzeug ermittelt den Weg dorthin. Der Nutzen entsteht aber erst im Regelkreis — beschreiben, prüfen, begrenzt anwenden, den tatsächlich erreichten Zustand mit dem beschriebenen vergleichen und Abweichungen zurückführen.

Zielzustand beschreiben → Diff reviewen → Begrenzt anwenden → Erreichten Zustand vergleichen → **Wirkung gegen Erfolgskriterium prüfen** → Abweichung zurückführen

Die beiden Prüfschritte beantworten **verschiedene** Fragen, und beide müssen gestellt werden. Der Zustandsabgleich fragt: **Stimmt die Konfiguration?** — deckt sich das Laufende mit dem Beschriebenen. Die Wirkungsprüfung fragt: **Verhält sich das System wie erwartet?** — treffen Kommunikation, Fehlerraten und Ressourcenwirkung das vorher festgelegte Erfolgskriterium. Eine sauber angewandte Änderung kann trotzdem die falsche gewesen sein, und nur die zweite Frage bemerkt das.

> **Merksatz:** Was nur in einer Konsole existiert, ist kein belastbarer Betriebsvertrag.

### Plattformgrenzen

|  |  |
| --- | --- |
| Grenze | Frage |
| Identity | Wer darf welche Änderung oder Laufzeitaktion ausführen? |
| Netzwerk | Welche Kommunikationswege sind ausdrücklich erlaubt? |
| Ressourcen | Welche Anfrage darf wie viel Kapazität beanspruchen? |
| Mandant | Welche Daten und Ausfälle dürfen sich niemals kreuzen? |

Diese vier Grenzen fallen selten zusammen — jede ist eine eigene Entwurfsfrage mit eigener Antwort und einem eigenen Instrument. Wer sie mit einem einzigen groben Instrument beantwortet, etwa indem er zwei Workloads schlicht in dieselbe Umgebung legt, löst eine Frage und öffnet drei andere.

- **Identity** — eine Rolle im Umfang der Aufgabe, nicht die vorhandene Adminrolle.
- **Netzwerk** — ein Pfad zum benötigten Ziel und Port, nicht ein gemeinsames Netz.
- **Ressourcen** — geprüfte Kapazität und ein Kontingent für die zusätzliche Last.
- **Mandant** — getrennte Daten und getrennte Ausfälle, nicht dieselbe Umgebung.

> **Merksatz:** Erreichbarkeit ist keine Berechtigung. Ein offener Netzpfad beantwortet die Identitätsfrage nicht — und eine Rolle ersetzt keinen Netzpfad.

Die Mandantengrenze hat zwei Seiten. **Daten:** eine Kopie von Produktionsdaten in einer schwächer geschützten Umgebung ist eine zweite Produktionsdatenhaltung — mit denselben Pflichten bei Zugriff, Aufbewahrung und Löschung. **Ausfälle:** jede Komponente, die zwei Mandanten oder zwei Umgebungen gemeinsam nutzen, verbindet ihre Ausfälle. Ein Wartungsfenster, ein Versionswechsel oder eine Überlast trifft dann beide zugleich. Kontingente dämpfen die Lastkopplung, sie heben den gemeinsamen Ausfall aber nicht auf.

> **Einordnung:** Die Aufteilung in genau diese vier Grenzen ist ein Lernmodell dieses Kurses, kein Standard. Anbieter schneiden ihre Kontrollen anders zu — die Trennschärfe der **Fragen** überlebt jeden Anbieterwechsel, die Kästchen nicht.

### Drift und die Richtung der Rückführung

Drift ist die Differenz zwischen dem beschriebenen und dem laufenden Zustand. Sie entsteht fast immer legitim: jemand behebt um drei Uhr nachts eine Störung direkt in der Konsole. Ein solcher Notfalleingriff ist erlaubt — er ist nur noch nicht fertig.

> **Merksatz:** Nicht Drift ist das Problem, sondern **unbemerkte** Drift. Nach einem Notfalleingriff lautet die Frage nicht ob zurückgeführt wird, sondern in welche **Richtung**.

- Der Eingriff war richtig und eng geschnitten: in die Beschreibung übernehmen, reviewen, anwenden.
- Der Eingriff war absichtlich grob, weil unter Zeitdruck niemand die genaue Grenze kannte: die minimal ausreichende Variante bestimmen, diese beschreiben, anwenden — und den zu weiten Rest entfernen.
- Der Eingriff war falsch oder ist nicht mehr nötig: zurückbauen und den Rückbau ebenfalls verifizieren.
- Was nie trägt: die Ressource dauerhaft von der Automatisierung ausnehmen. Das macht die Abweichung dauerhaft und unsichtbar, statt sie aufzulösen.

Der Notfallzustand ist also **nicht automatisch** der gewünschte Zustand. Ihn ungeprüft in Code zu gießen führt eine Ausnahme über den Review-Pfad in die Dauerregel ein.

### Nachweis statt Annahme

Eine Beschreibung ist keine Messung. Die Frage „läuft alles so, wie es beschrieben ist?“ lässt sich nur mit einem Vergleich beantworten — nicht mit einem Verweis auf den Prozess.

|  |  |
| --- | --- |
| Artefakt | Was es tatsächlich belegt |
| Beschreibung im Repository | Absicht und Freigabe — nicht die Wirklichkeit. |
| Grüner Lauf der Automatisierung | Dass zu **diesem Zeitpunkt** angewendet wurde — nicht, dass seither nichts verändert wurde. |
| Abgleich laufender Zustand gegen Beschreibung | Dass **heute** keine Abweichung besteht. |
| Änderungsprotokoll der Plattform-API | Wer wann außerhalb des vorgesehenen Wegs geändert hat. |

> **Merksatz:** Ein Nachweis ist ein **Vergleich**. Ein einzelner Zustand ohne Sollwert und ohne Zeitachse ist ein Screenshot, kein Beleg.

Die beiden tragenden Artefakte ergänzen sich: der Abgleich zeigt **dass** etwas abweicht, das Änderungsprotokoll zeigt **wie** es dazu kam. Wer nur eines hat, kann entweder nicht handeln oder nicht lernen.

### Recovery ist ein Produktmerkmal

Verfügbarkeit und Wiederherstellung beginnen mit Anforderungen: Wie lange darf Ausfall dauern und wie viel Datenverlust ist akzeptabel? Daraus folgen Architektur, Backups, Replikation und getestete Wiederanläufe.

|  |  |
| --- | --- |
| RTO — Recovery Time Objective | Maximal zulässige Dauer, die eine Funktion offline sein darf. |
| RPO — Recovery Point Objective | Maximal zulässiger Zeitraum, aus dem Daten verloren gehen dürfen. |

Beide Werte sind Geschäftsentscheidungen, keine Messwerte des Ist-Betriebs. Erst wenn sie je Funktion feststehen, lässt sich begründet zwischen den Mustern wählen: Sicherung und Wiederherstellung, vorgehaltene Minimalumgebung, mitlaufendes Standby oder mehrere aktive Regionen. In dieser Reihenfolge sinkt die erwartete Ausfalldauer, und Kosten wie Betriebsaufwand steigen.

> **Trade-off:** Mehr Redundanz kostet Geld und Betriebsaufwand. Ziele wie RTO und RPO machen diesen Trade-off explizit.

> **Merksatz:** Ein nie ausgeführter Wiederanlauf ist eine Behauptung. Belastbar wird er erst durch eine gemessene Übung — Dauer bis zur fachlichen Nutzbarkeit und tatsächlich erreichter Datenstand. Eine erfolgreiche Sicherung ist kein Nachweis einer erfolgreichen Wiederherstellung.

### Nächste Checks

Gleich entscheidest du diese Achsen selbst. Achte jeweils darauf, welche Grenze wirklich gefragt ist und welcher Beleg die Aussage trägt.

- Den gewünschten Zustand statt einen manuellen Hotfix wählen
- Eine Plattformänderung von der Absicht bis zum Rückweg ordnen
- Identität, Netz, Ressourcen und Mandant als getrennte Entwurfsfragen behandeln
- Einen Notfalleingriff aus der Konsole in die richtige Richtung zurückführen
- Recovery-Ziele vor der Architekturwahl festlegen statt danach
- Den laufenden Zustand belegen statt ihn anzunehmen
- Datenkreuzung und Ausfallkopplung zwischen Umgebungen getrennt schließen
- Einen zugesagten Wiederanlauf messbar nachweisen

## Quellen

- Google Cloud: Infrastructure as Code — https://cloud.google.com/discover/what-is-infrastructure-as-code
- Google Cloud Architecture Center: Disaster Recovery Planning Guide — https://cloud.google.com/architecture/dr-scenarios-planning-guide
- AWS Well-Architected Framework, Reliability Pillar: Design Principles — https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-principles.html
- AWS Well-Architected Framework, Security Pillar: Detection — https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html
- NIST SP 800-145: The NIST Definition of Cloud Computing (Resource Pooling, Multi-Tenant-Modell) — https://csrc.nist.gov/pubs/sp/800/145/final
- AWS Well-Architected Framework, Security Pillar: SEC03-BP02 Grant least privilege access — https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html
- Einordnung: Die Aufteilung in genau vier Plattformgrenzen (Identität, Netz, Ressourcen, Mandant) ist eine didaktische Synthese dieses Kurses. Belegt sind die Einzelprinzipien, nicht die Vierteilung als Standard.
- AWS Whitepaper: Disaster Recovery of Workloads on AWS — Disaster Recovery Options in the Cloud — https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html
- Google Cloud: Infrastructure Reliability Guide — Building Blocks (Definition Failure Domain) — https://cloud.google.com/architecture/infra-reliability-guide/building-blocks
- Einordnung: Die Quellen definieren Fehlerdomäne und Multi-Tenant-Modell. Die Übertragung auf die Kopplung zweier Umgebungen über eine geteilte Datenbank ist eine Ableitung dieses Kurses.
- AWS Whitepaper: Disaster Recovery of Workloads on AWS — Testing Disaster Recovery — https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/testing-disaster-recovery.html