15.7 Cloud-Betrieb, Monitoring, Skalierung und Kostenkontrolle
Cloud-Dienste müssen auch nach der Einrichtung betrieben, überwacht und optimiert werden.
Cloud bedeutet nicht:
einmal erstellen
und nie wieder anfassen
Cloud-Betrieb umfasst:
- Monitoring
- Logging
- Alarmierung
- Kostenkontrolle
- Skalierung
- Patchmanagement
- Backup-Prüfung
- Sicherheitsprüfung
- Rechteprüfung
- Dokumentation
- Automatisierung
- Störungsbehandlung
Merksatz:
Cloud-Ressourcen brauchen laufenden Betrieb wie lokale IT-Systeme.
Warum Cloud-Betrieb wichtig ist
Cloud-Ressourcen lassen sich schnell erstellen.
Das ist ein Vorteil, kann aber auch ein Risiko sein.
Typische Probleme:
Ressourcen werden vergessen.
Kosten steigen unbemerkt.
Logs sind nicht aktiviert.
Backups werden nicht getestet.
Sicherheitsregeln sind zu breit.
Benutzerrechte bleiben zu lange bestehen.
Dienste laufen dauerhaft,
obwohl sie nicht mehr gebraucht werden.
Merksatz:
Cloud-Flexibilität braucht Kontrolle.
Cloud-Betrieb einfach erklärt
Beim Cloud-Betrieb geht es darum, Cloud-Dienste dauerhaft zuverlässig, sicher und wirtschaftlich zu betreiben.
Dazu gehören Fragen wie:
Läuft der Dienst?
Ist der Dienst erreichbar?
Ist die Leistung ausreichend?
Gibt es Sicherheitsereignisse?
Werden Kosten eingehalten?
Funktionieren Backups?
Sind Ressourcen richtig dimensioniert?
Sind Rechte korrekt?
Gibt es unnötige Ressourcen?
Merksatz:
Cloud-Betrieb verbindet Technik,
Sicherheit
und Kosten.
Monitoring
Monitoring bedeutet:
Systeme und Dienste werden laufend überwacht.
Ziel:
Probleme früh erkennen,
bevor Benutzer stark betroffen sind.
Überwacht werden zum Beispiel:
Verfügbarkeit
CPU-Auslastung
RAM-Auslastung
Speicherplatz
Netzwerkverkehr
Antwortzeiten
Fehlerquoten
Datenbanklast
Zertifikatsablauf
Backupstatus
Kosten
Merksatz:
Monitoring zeigt,
ob Systeme gesund laufen.
Metriken
Metriken sind messbare Werte.
Beispiele:
CPU in Prozent
RAM-Verbrauch
freier Speicherplatz
Anfragen pro Sekunde
Antwortzeit in Millisekunden
Fehlerrate
Netzwerkdurchsatz
Anzahl aktiver Benutzer
Datenbankverbindungen
Warteschlangenlänge
Merksatz:
Metriken liefern messbare Zustandswerte.
Logs
Logs sind Ereignisprotokolle.
Sie zeigen, was in einem System passiert ist.
Beispiele:
Benutzeranmeldung
API-Aufruf
Fehler in Anwendung
Firewall blockiert Verbindung
Admin ändert Rolle
Backup schlägt fehl
Datenbank meldet Fehler
Ressource wird gelöscht
Merksatz:
Logs zeigen Ereignisse und helfen bei Fehlersuche.
Monitoring und Logging unterscheiden
| Begriff | Frage | Beispiel |
|---|---|---|
| Monitoring | Wie geht es dem System gerade? | CPU 90 %, Dienst nicht erreichbar |
| Logging | Was ist passiert? | Benutzer hat Firewall-Regel geändert |
Merksatz:
Monitoring zeigt Zustand.
Logs zeigen Ereignisse.
Alarmierung
Alarmierung bedeutet:
Bei bestimmten Ereignissen oder Grenzwerten wird automatisch gewarnt.
Beispiele:
CPU über 90 %
Speicher fast voll
Dienst nicht erreichbar
Backup fehlgeschlagen
viele fehlgeschlagene Logins
Kostenlimit fast erreicht
Zertifikat läuft bald ab
ungewöhnlich viel Datenverkehr
Merksatz:
Alarmierung macht Probleme sichtbar,
bevor sie übersehen werden.
Schwellwert
Ein Schwellwert ist ein Grenzwert, ab dem eine Aktion ausgelöst wird.
Beispiel:
Wenn CPU länger als 10 Minuten über 85 % liegt,
Alarm auslösen.
Oder:
Wenn Monatskosten 80 % des Budgets erreichen,
Warnung senden.
Merksatz:
Schwellwerte steuern,
wann gewarnt oder reagiert wird.
Alert Fatigue
Alert Fatigue bedeutet:
Es gibt so viele Alarme,
dass wichtige Alarme übersehen werden.
Ursachen:
zu niedrige Schwellwerte
zu viele unwichtige Alarme
keine Priorisierung
Alarme ohne Handlungsempfehlung
wiederholte Fehlalarme
Schutz:
Alarme sinnvoll priorisieren
nur relevante Alarme erstellen
klare Zuständigkeiten festlegen
Alarme regelmäßig überprüfen
Merksatz:
Zu viele schlechte Alarme sind selbst ein Problem.
Dashboard
Ein Dashboard zeigt wichtige Betriebswerte übersichtlich an.
Beispiele:
Verfügbarkeit
Auslastung
Fehlerquote
Kosten
offene Alarme
Backupstatus
Zertifikate
Sicherheitsereignisse
aktive Ressourcen
Merksatz:
Dashboard = Überblick über wichtige Zustände.
Cloud-Logging aktivieren
Viele Cloud-Dienste erzeugen Logs nur dann vollständig, wenn Logging aktiviert oder richtig konfiguriert ist.
Wichtig:
Audit-Logs aktivieren
Netzwerklogs aktivieren
Anwendungslogs aktivieren
Firewall-Logs aktivieren
Load-Balancer-Logs aktivieren
Aufbewahrung festlegen
Zugriff auf Logs schützen
Merksatz:
Nicht vorhandene Logs helfen im Fehlerfall nicht.
Audit-Logs
Audit-Logs dokumentieren administrative Aktionen.
Beispiele:
Benutzer erstellt
Rolle geändert
VM gelöscht
Firewall geöffnet
Speicher öffentlich gemacht
API-Schlüssel erzeugt
MFA deaktiviert
Backup gelöscht
Merksatz:
Audit-Logs zeigen,
wer was wann geändert hat.
Flow Logs
Flow Logs zeigen Netzwerkverbindungen als Metadaten.
Typische Angaben:
Quelle
Ziel
Port
Protokoll
Zeit
Aktion
Datenmenge
Schnittstelle
Wichtig:
Flow Logs zeigen meist nicht den vollständigen Inhalt der Pakete.
Merksatz:
Flow Logs helfen bei Netzwerk- und Firewall-Analyse.
Log-Aufbewahrung
Logs sollten nicht beliebig kurz oder beliebig lange gespeichert werden.
Zu klären:
Wie lange werden Logs benötigt?
Gibt es rechtliche Vorgaben?
Enthalten Logs personenbezogene Daten?
Wer darf Logs lesen?
Wie werden Logs geschützt?
Wann werden Logs gelöscht?
Merksatz:
Log-Aufbewahrung braucht Sicherheits- und Datenschutzkonzept.
Zentrales Logging
Bei mehreren Cloud-Diensten sollten Logs zentral gesammelt werden.
Vorteile:
bessere Übersicht
einfachere Suche
Korrelation von Ereignissen
Sicherheitsanalyse
Nachvollziehbarkeit
Alarmierung
weniger Insellösungen
Merksatz:
Zentrales Logging erleichtert Betrieb und Sicherheitsanalyse.
SIEM
SIEM steht für:
Security Information and Event Management
Ein SIEM sammelt Sicherheitslogs aus verschiedenen Quellen und wertet sie aus.
Ziel:
Angriffe erkennen
verdächtige Muster finden
Alarme erzeugen
Ereignisse korrelieren
Nachweise liefern
Merksatz:
SIEM hilft bei zentraler Sicherheitsüberwachung.
Cloud-Kostenkontrolle
Cloud-Kosten können schnell steigen, wenn Ressourcen unkontrolliert genutzt werden.
Kosten entstehen zum Beispiel durch:
laufende virtuelle Maschinen
Speicher
Datenbanken
Backups
Snapshots
Netzwerkverkehr
Load Balancer
öffentliche IP-Adressen
Logs
Monitoring
Lizenzen
Support
Datenübertragung zwischen Regionen
Merksatz:
Cloud-Kosten entstehen nicht nur durch Server.
Pay as you go
Pay as you go bedeutet:
bezahlt wird nach Nutzung.
Beispiele:
pro Stunde
pro Sekunde
pro GB
pro Anfrage
pro Benutzer
pro Datenübertragung
pro Ausführung
Vorteil:
flexibel
Risiko:
Fehlkonfiguration oder Dauerbetrieb kann teuer werden.
Merksatz:
Pay as you go braucht Überwachung.
Budget
Ein Budget legt fest, wie viel Geld für Cloud-Ressourcen geplant ist.
Beispiele:
Monatsbudget für Projekt
Budget für Testumgebung
Budget für Abteilung
Budget für gesamte Cloud-Plattform
Wichtig:
Budget allein stoppt nicht immer automatisch Kosten.
Oft braucht man zusätzlich Alarme oder Sperren.
Merksatz:
Budget macht Kosten sichtbar und planbar.
Kostenalarm
Ein Kostenalarm warnt, wenn Kosten einen bestimmten Wert erreichen.
Beispiele:
50 % des Monatsbudgets erreicht
80 % des Monatsbudgets erreicht
ungewöhnlicher Kostenanstieg
unerwarteter Dienst verursacht Kosten
Merksatz:
Kostenalarme verhindern nicht alles,
aber sie machen Kosten früh sichtbar.
Kostenstelle
Eine Kostenstelle ordnet Kosten einem Bereich zu.
Beispiele:
Projekt
Abteilung
Kunde
Umgebung
Team
Anwendung
In der Cloud erfolgt diese Zuordnung oft über:
Tags
Labels
Ressourcengruppen
Abonnements
Accounts
Projekte
Merksatz:
Kosten müssen verursachergerecht zugeordnet werden.
Tagging
Tagging bedeutet:
Ressourcen werden mit Metadaten markiert.
Beispiele:
Projekt = CRM
Umgebung = Produktion
Verantwortlicher = IT-Betrieb
Kostenstelle = 4711
Ablaufdatum = 2026-12-31
Schutzbedarf = vertraulich
Vorteile:
Kosten zuordnen
Ressourcen finden
Verantwortliche erkennen
Automatisierung ermöglichen
Aufräumen erleichtern
Merksatz:
Tags machen Cloud-Ressourcen verwaltbar.
Untagged Resources
Untagged Resources sind Ressourcen ohne Tags.
Problem:
Verantwortlicher unklar
Kostenstelle unklar
Zweck unklar
Aufräumen schwierig
Sicherheitsbewertung schwieriger
Lebenszyklus unklar
Merksatz:
Ressourcen ohne Tags sind im Betrieb schwer kontrollierbar.
Rightsizing
Rightsizing bedeutet:
Ressourcen passend dimensionieren.
Beispiel:
Eine VM hat 16 vCPU und 64 GB RAM,
nutzt aber dauerhaft nur 5 %.
Dann ist sie wahrscheinlich zu groß.
Maßnahmen:
kleinere Instanz wählen
Datenbankklasse anpassen
Speicherklasse ändern
ungenutzte Ressourcen löschen
Lastverhalten prüfen
Merksatz:
Rightsizing senkt Kosten durch passende Größe.
Overprovisioning
Overprovisioning bedeutet:
Ressourcen sind größer bereitgestellt,
als tatsächlich benötigt.
Beispiele:
zu große VM
zu teure Datenbankklasse
zu viel reservierter Speicher
zu viele laufende Instanzen
unnötig hohe Performanceklasse
Merksatz:
Overprovisioning kostet unnötig Geld.
Underprovisioning
Underprovisioning bedeutet:
Ressourcen sind zu klein dimensioniert.
Folgen:
langsame Anwendung
Ausfälle
hohe Antwortzeiten
Datenbankengpässe
Fehler bei Lastspitzen
schlechte Benutzererfahrung
Merksatz:
Zu klein spart kurzfristig Geld,
kann aber Betrieb stören.
Auto Scaling
Auto Scaling bedeutet:
Ressourcen werden automatisch erhöht oder reduziert.
Beispiel:
Bei hoher Last werden zusätzliche Instanzen gestartet.
Bei geringer Last werden Instanzen beendet.
Vorteile:
bessere Anpassung an Last
weniger manuelle Eingriffe
bessere Verfügbarkeit
Kosten können optimiert werden
Merksatz:
Auto Scaling passt Ressourcen automatisch an Last an.
Horizontale Skalierung
Horizontale Skalierung bedeutet:
Es werden mehr Instanzen hinzugefügt.
Beispiel:
statt 1 Webserver
laufen 3 Webserver
Vorteil:
Last kann verteilt werden
Ausfallsicherheit steigt
gut mit Load Balancer kombinierbar
Merksatz:
Horizontal skalieren = mehr Systeme.
Vertikale Skalierung
Vertikale Skalierung bedeutet:
Ein einzelnes System wird größer gemacht.
Beispiel:
VM bekommt mehr CPU
VM bekommt mehr RAM
Datenbank bekommt größere Leistungsklasse
Vorteil:
oft einfacher
Nachteil:
Grenze durch maximale Größe
eventuell Neustart nötig
einzelnes System bleibt kritischer
Merksatz:
Vertikal skalieren = stärkeres System.
Horizontale und vertikale Skalierung vergleichen
| Skalierungsart | Bedeutung | Beispiel |
|---|---|---|
| horizontal | mehr Instanzen | drei Webserver statt einer |
| vertikal | größere Instanz | mehr CPU und RAM für eine VM |
Merksatz:
Horizontal = mehr.
Vertikal = stärker.
Scale Out und Scale Up
Scale Out bedeutet:
horizontal skalieren
Scale Up bedeutet:
vertikal skalieren
Beispiele:
Scale Out:
mehr App-Instanzen starten
Scale Up:
größere Datenbankklasse wählen
Merksatz:
Scale Out = mehr Instanzen.
Scale Up = größere Instanz.
Scale In und Scale Down
Scale In bedeutet:
Instanzen reduzieren
Scale Down bedeutet:
einzelne Instanz verkleinern
Beispiele:
Scale In:
von 5 Webservern auf 2 Webserver reduzieren
Scale Down:
VM von großer auf kleinere Größe ändern
Merksatz:
Scale In reduziert Anzahl.
Scale Down reduziert Größe.
Skalierungsregel
Eine Skalierungsregel legt fest, wann skaliert wird.
Beispiele:
Wenn CPU länger als 10 Minuten über 70 %,
dann eine Instanz hinzufügen.
Wenn Warteschlange mehr als 100 Nachrichten hat,
dann Worker erhöhen.
Wenn CPU länger niedrig,
dann Instanz entfernen.
Merksatz:
Skalierung braucht sinnvolle Regeln.
Skalierung ist nicht nur CPU
Skalierung kann abhängig sein von:
CPU
RAM
Anzahl Anfragen
Antwortzeit
Warteschlangenlänge
Datenbankverbindungen
Netzwerkdurchsatz
Fehlerrate
Benutzerzahl
Zeitplan
Merksatz:
CPU ist nur eine mögliche Skalierungsmetrik.
Load Balancer und Skalierung
Bei horizontaler Skalierung verteilt ein Load Balancer den Verkehr.
Ablauf:
neue Instanz startet
Health Check prüft Instanz
Load Balancer nimmt Instanz auf
Verkehr wird verteilt
Wenn Instanz ungesund ist, wird sie nicht genutzt.
Merksatz:
Auto Scaling und Load Balancer arbeiten oft zusammen.
Health Check im Betrieb
Ein Health Check prüft, ob ein Dienst gesund ist.
Beispiele:
HTTP 200 auf /health
TCP-Port erreichbar
Datenbankverbindung möglich
Anwendung meldet Status „ok“
Merksatz:
Health Check sollte echte Dienstfähigkeit prüfen,
nicht nur offenen Port.
Hochverfügbarkeit
Hochverfügbarkeit bedeutet:
Ein Dienst bleibt möglichst verfügbar,
auch wenn einzelne Komponenten ausfallen.
Mittel:
mehrere Instanzen
mehrere Zonen
Load Balancer
Replikation
automatischer Neustart
Monitoring
Backup
Notfallplan
Merksatz:
Hochverfügbarkeit muss geplant und getestet werden.
Verfügbarkeitszone
Eine Verfügbarkeitszone ist ein getrenntes Rechenzentrumssegment innerhalb einer Region.
Vorteil:
Fällt eine Zone aus,
können andere Zonen weiterarbeiten.
Cloud-Dienste sollten für hohe Verfügbarkeit oft über mehrere Zonen verteilt werden.
Merksatz:
Mehrere Zonen erhöhen Ausfallsicherheit innerhalb einer Region.
Region
Eine Region ist ein geografischer Standort eines Cloud-Anbieters.
Regionen beeinflussen:
Latenz
Datenstandort
Verfügbarkeit
Kosten
Datenschutz
Compliance
Merksatz:
Region bewusst nach Technik,
Recht
und Kosten auswählen.
Disaster Recovery
Disaster Recovery bedeutet:
Wiederherstellung nach schwerem Ausfall.
Beispiele:
Region fällt aus
Datenbank beschädigt
Ransomware-Angriff
Fehlkonfiguration löscht Ressourcen
kritischer Dienst fällt aus
Dazu braucht man:
Backups
Wiederherstellungsplan
Ersatzumgebung
Dokumentation
Tests
klare Zuständigkeiten
Merksatz:
Disaster Recovery muss vor dem Notfall geplant werden.
RTO im Cloud-Betrieb
RTO steht für:
Recovery Time Objective
Es beschreibt, wie lange ein Dienst maximal ausfallen darf.
Beispiel:
RTO = 2 Stunden
Dann soll der Dienst innerhalb von 2 Stunden wieder verfügbar sein.
Merksatz:
RTO beschreibt erlaubte Wiederherstellungszeit.
RPO im Cloud-Betrieb
RPO steht für:
Recovery Point Objective
Es beschreibt, wie viel Datenverlust maximal akzeptiert wird.
Beispiel:
RPO = 15 Minuten
Dann dürfen höchstens Daten der letzten 15 Minuten verloren gehen.
Merksatz:
RPO beschreibt erlaubten Datenverlust.
RTO und RPO im Betrieb vergleichen
| Begriff | Frage |
|---|---|
| RTO | Wie lange darf der Dienst ausfallen? |
| RPO | Wie viele Daten dürfen verloren gehen? |
Merksatz:
RTO = Zeit bis Wiederherstellung.
RPO = Datenverlust bis Wiederherstellungspunkt.
Patchmanagement in der Cloud
Auch Cloud-Systeme brauchen Updates.
Wer verantwortlich ist, hängt vom Service-Modell ab.
IaaS:
Kunde patcht Betriebssystem und Anwendung.
PaaS:
Anbieter patcht Plattform,
Kunde patcht Anwendung und Abhängigkeiten.
SaaS:
Anbieter patcht Anwendung,
Kunde prüft Einstellungen,
Benutzer
und Sicherheit.
Merksatz:
Patchverantwortung hängt vom Cloud-Modell ab.
Wartungsfenster
Ein Wartungsfenster ist ein geplanter Zeitraum für Änderungen oder Updates.
Ziel:
Änderungen kontrolliert durchführen
Benutzer informieren
Ausfallzeit planen
Rollback vorbereiten
Risiken reduzieren
Merksatz:
Wartungsfenster schaffen planbare Änderungen.
Change Management
Change Management bedeutet:
Änderungen werden geplant,
geprüft,
freigegeben,
umgesetzt
und dokumentiert.
Cloud-Beispiele:
neue Firewall-Regel
größere Datenbankklasse
neue Region
neue Rolle
neue Backup-Regel
neue Skalierungsregel
neues Deployment
Merksatz:
Cloud-Änderungen brauchen Kontrolle und Dokumentation.
Rollback
Rollback bedeutet:
Eine Änderung wird zurückgenommen.
Beispiele:
vorherige Anwendungsversion wiederherstellen
alte Konfiguration laden
Snapshot zurücksetzen
Firewall-Regel zurücknehmen
Deployment rückgängig machen
Merksatz:
Jede kritische Änderung braucht einen Rückweg.
Automatisierung im Cloud-Betrieb
Cloud-Betrieb wird häufig automatisiert.
Beispiele:
Ressourcen automatisch bereitstellen
Backups automatisch erstellen
Skalierung automatisch durchführen
Alarme automatisch auslösen
Tests automatisch starten
Deployments automatisch ausrollen
ungenutzte Ressourcen automatisch stoppen
Merksatz:
Automatisierung reduziert manuelle Fehler,
braucht aber gute Regeln.
Infrastructure as Code
Infrastructure as Code wird oft abgekürzt:
IaC
Dabei wird Infrastruktur nicht manuell im Portal zusammengeklickt, sondern als Code beschrieben.
Beispiele:
Netzwerke
Subnetze
Firewall-Regeln
virtuelle Maschinen
Datenbanken
Rollen
Speicher
Load Balancer
Vorteile:
wiederholbar
dokumentiert
versionierbar
prüfbar
automatisierbar
Merksatz:
IaC beschreibt Infrastruktur als Code.
Configuration Drift
Configuration Drift bedeutet:
Die tatsächliche Konfiguration weicht von der geplanten Konfiguration ab.
Ursachen:
manuelle Änderungen
Notfalländerungen
unterschiedliche Umgebungen
unvollständige Dokumentation
fehlende Automatisierung
Problem:
Fehlersuche wird schwieriger.
Sicherheit kann unbemerkt schlechter werden.
Merksatz:
Configuration Drift entsteht durch ungeplante Abweichungen.
CI/CD im Cloud-Betrieb
CI/CD steht für:
Continuous Integration
Continuous Delivery
oder
Continuous Deployment
Ziel:
Änderungen werden automatisiert gebaut,
getestet
und bereitgestellt.
Cloud-Bezug:
Anwendungen werden schneller und kontrollierter ausgeliefert.
Rollbacks können einfacher werden.
Tests werden automatisiert.
Infrastruktur kann mitbereitgestellt werden.
Merksatz:
CI/CD automatisiert Entwicklung,
Test
und Bereitstellung.
Blue-Green Deployment
Blue-Green Deployment bedeutet:
Es gibt zwei Umgebungen.
Blue:
aktuelle produktive Version
Green:
neue Version
Nach erfolgreichem Test wird der Verkehr auf die neue Umgebung umgeschaltet.
Vorteil:
schneller Rollback möglich
Merksatz:
Blue-Green reduziert Risiko bei neuen Versionen.
Canary Deployment
Canary Deployment bedeutet:
Eine neue Version wird zuerst nur für einen kleinen Teil der Benutzer freigegeben.
Wenn keine Probleme auftreten, wird der Anteil erhöht.
Vorteil:
Fehler betreffen zunächst nur wenige Benutzer.
Merksatz:
Canary testet neue Versionen schrittweise im Echtbetrieb.
Cloud-Betriebsdokumentation
Dokumentiert werden sollten:
Zweck der Ressource
Verantwortlicher
Kostenstelle
Umgebung
Datenklasse
Netzverbindungen
Backup-Regeln
Monitoring
Alarme
Wiederherstellungsplan
Sicherheitsregeln
Änderungen
Abhängigkeiten
Merksatz:
Was nicht dokumentiert ist,
ist im Betrieb schwer beherrschbar.
Runbook
Ein Runbook ist eine Schritt-für-Schritt-Anleitung für wiederkehrende Betriebsaufgaben.
Beispiele:
Dienst neu starten
Backup wiederherstellen
Zertifikat erneuern
Alarm bearbeiten
Instanz skalieren
Failover auslösen
Benutzerzugriff prüfen
Merksatz:
Runbooks helfen,
im Betrieb einheitlich zu handeln.
Incident Response
Incident Response bedeutet:
Vorgehen bei Sicherheitsvorfällen oder größeren Störungen.
Schritte:
erkennen
bewerten
eindämmen
beseitigen
wiederherstellen
dokumentieren
verbessern
Cloud-Beispiele:
kompromittierter API-Schlüssel
öffentlich freigegebener Speicher
ungewöhnliche Kosten
Adminzugang missbraucht
Datenabfluss
Ransomware
Merksatz:
Incident Response muss vorbereitet sein,
bevor ein Vorfall passiert.
Service Level Agreement
Service Level Agreement wird abgekürzt:
SLA
Ein SLA beschreibt zugesicherte Servicequalität.
Beispiele:
Verfügbarkeit
Reaktionszeit
Supportzeit
Wiederherstellungszeit
Leistungswerte
Merksatz:
SLA beschreibt,
welche Leistung zugesichert wird.
SLO
SLO steht für:
Service Level Objective
Ein SLO ist ein internes oder technisches Ziel für einen Dienst.
Beispiel:
99,9 % erfolgreiche Anfragen pro Monat
Antwortzeit unter 300 ms für 95 % der Anfragen
Merksatz:
SLO beschreibt ein Ziel für Servicequalität.
SLI
SLI steht für:
Service Level Indicator
Ein SLI ist ein Messwert, mit dem ein SLO bewertet wird.
Beispiele:
Verfügbarkeit
Fehlerrate
Antwortzeit
Durchsatz
Latenz
Merksatz:
SLI ist der Messwert,
SLO ist das Ziel.
SLA, SLO und SLI vergleichen
| Begriff | Bedeutung |
|---|---|
| SLA | vertragliche Zusage |
| SLO | Zielwert für Dienstqualität |
| SLI | Messwert zur Bewertung |
Merksatz:
SLI misst.
SLO setzt Ziel.
SLA ist Zusage.
Cloud-Fehlersuche im Betrieb
Bei Cloud-Störungen systematisch prüfen:
Was ist betroffen?
Seit wann?
Wurde etwas geändert?
Welche Region?
Welche Zone?
Welche Ressource?
Welche Logs?
Welche Metriken?
Welche Abhängigkeiten?
Welche Kostenänderung?
Welche Alarme?
Welche Benutzer betroffen?
Merksatz:
Störungen immer mit Zeit,
Änderung
Metriken
Logs
und Abhängigkeiten prüfen.
Typische Betriebsprobleme in der Cloud
Häufige Probleme:
Dienst nicht erreichbar
Zertifikat abgelaufen
Speicher voll
Datenbank überlastet
Kosten steigen plötzlich
Backup fehlgeschlagen
Load Balancer hat keine gesunden Ziele
Security Group falsch geändert
API-Schlüssel kompromittiert
Rechte zu breit vergeben
Region oder Zone gestört
Skalierung greift nicht
Merksatz:
Cloud-Betrieb betrifft Verfügbarkeit,
Sicherheit
Leistung
und Kosten.
Checkliste: Cloud-Betrieb
Monitoring aktivieren.
Logs aktivieren.
Alarme einrichten.
Kostenalarme setzen.
Tags pflegen.
Verantwortliche dokumentieren.
Backups prüfen.
Restore-Tests durchführen.
Rechte regelmäßig prüfen.
Ressourcen richtig dimensionieren.
ungenutzte Ressourcen löschen.
Patchverantwortung klären.
Runbooks erstellen.
Änderungen dokumentieren.
Incident Response vorbereiten.
Merksatz:
Cloud-Betrieb braucht regelmäßige Kontrolle.
Typische IHK-Fragen
In AP1 und AP2 kann zum Beispiel gefragt werden:
- Warum braucht Cloud Monitoring?
- Was ist der Unterschied zwischen Monitoring und Logging?
- Was ist ein Kostenalarm?
- Warum ist Tagging sinnvoll?
- Was bedeutet Rightsizing?
- Was ist Overprovisioning?
- Was ist Auto Scaling?
- Was ist horizontale Skalierung?
- Was ist vertikale Skalierung?
- Was ist ein Health Check?
- Was ist der Unterschied zwischen RTO und RPO?
- Was ist Infrastructure as Code?
- Was bedeutet Configuration Drift?
- Was ist ein Runbook?
- Was bedeutet Incident Response?
- Was ist der Unterschied zwischen SLA, SLO und SLI?
- Warum ist Cloud nicht automatisch wartungsfrei?
Typische Prüfungsfallen
Cloud ist nicht wartungsfrei.
Monitoring zeigt Zustand.
Logs zeigen Ereignisse.
Ohne Logs keine gute Fehlersuche.
Zu viele Alarme können schaden.
Kosten entstehen auch durch Speicher,
Traffic,
Logs
und Snapshots.
Pay as you go braucht Kontrolle.
Tags helfen bei Kosten und Verantwortung.
Untagged Resources sind problematisch.
Rightsizing spart Kosten.
Overprovisioning kostet unnötig Geld.
Underprovisioning stört Betrieb.
Auto Scaling braucht sinnvolle Regeln.
Horizontal bedeutet mehr Instanzen.
Vertikal bedeutet größere Instanz.
Hochverfügbarkeit muss geplant werden.
Cloud ist nicht automatisch hochverfügbar.
RTO betrifft Wiederherstellungszeit.
RPO betrifft Datenverlust.
Patchverantwortung hängt vom Service-Modell ab.
Change Management gilt auch in der Cloud.
Rollback vor Änderung planen.
IaC macht Infrastruktur wiederholbar.
Configuration Drift vermeiden.
Runbooks helfen im Betrieb.
SLA,
SLO
und SLI nicht verwechseln.
Wichtige Begriffe kurz erklärt
| Begriff | Kurze Erklärung |
|---|---|
| Cloud-Betrieb | laufende Verwaltung von Cloud-Diensten |
| Monitoring | Überwachung von Zuständen |
| Metrik | messbarer Wert |
| Logging | Protokollierung von Ereignissen |
| Audit-Log | Protokoll administrativer Aktionen |
| Flow Log | Netzwerkverbindungsdaten |
| Alarmierung | automatische Warnung |
| Schwellwert | Grenzwert für Alarm oder Aktion |
| Alert Fatigue | Überforderung durch zu viele Alarme |
| Dashboard | Übersicht wichtiger Werte |
| SIEM | zentrale Sicherheitslog-Auswertung |
| Kostenkontrolle | Überwachung und Steuerung von Kosten |
| Pay as you go | Abrechnung nach Nutzung |
| Budget | geplanter Kostenrahmen |
| Kostenalarm | Warnung bei Kostenüberschreitung |
| Kostenstelle | Zuordnung von Kosten |
| Tagging | Metadaten an Ressourcen |
| Rightsizing | passende Ressourcengröße |
| Overprovisioning | zu große Ressourcen |
| Underprovisioning | zu kleine Ressourcen |
| Auto Scaling | automatische Anpassung von Ressourcen |
| horizontale Skalierung | mehr Instanzen |
| vertikale Skalierung | größere Instanz |
| Scale Out | horizontal erweitern |
| Scale Up | vertikal vergrößern |
| Health Check | Prüfung der Dienstgesundheit |
| Hochverfügbarkeit | hohe Verfügbarkeit trotz Fehler |
| Disaster Recovery | Wiederherstellung nach schwerem Ausfall |
| RTO | maximale Wiederherstellungszeit |
| RPO | maximaler Datenverlust |
| Patchmanagement | Verwaltung von Updates |
| Change Management | kontrollierte Änderungen |
| Rollback | Änderung zurücknehmen |
| IaC | Infrastructure as Code |
| Configuration Drift | Abweichung von Soll-Konfiguration |
| CI/CD | automatisierte Bereitstellung |
| Runbook | Betriebsanleitung |
| Incident Response | Reaktion auf Vorfälle |
| SLA | vertragliche Servicezusage |
| SLO | Zielwert für Servicequalität |
| SLI | Messwert für Servicequalität |
IHK-sichere Kurzformulierung
Cloud-Betrieb umfasst die laufende Überwachung, Protokollierung, Alarmierung, Kostenkontrolle, Skalierung, Wartung, Sicherheitsprüfung und Dokumentation von Cloud-Diensten. Monitoring zeigt den aktuellen Zustand eines Systems, während Logging Ereignisse und Änderungen nachvollziehbar macht. Kostenkontrolle ist wichtig, weil Cloud-Ressourcen nach Nutzung abgerechnet werden und auch Speicher, Netzwerkverkehr, Backups, Logs, Snapshots und Lizenzen Kosten verursachen können. Auto Scaling passt Ressourcen automatisch an Last an. Horizontale Skalierung bedeutet mehr Instanzen, vertikale Skalierung bedeutet größere Instanzen. Für Ausfallsicherheit sind Hochverfügbarkeit, Backups, RTO, RPO, Runbooks, Change Management und Incident Response wichtig.
Merksätze
Cloud ist nicht wartungsfrei.
Cloud-Betrieb braucht Monitoring.
Monitoring zeigt Zustand.
Logs zeigen Ereignisse.
Audit-Logs zeigen Adminaktionen.
Flow Logs zeigen Netzwerkverbindungen.
Alarmierung macht Probleme sichtbar.
Zu viele Alarme können wichtige Alarme verdecken.
Dashboard gibt Überblick.
SIEM wertet Sicherheitslogs zentral aus.
Cloud-Kosten aktiv überwachen.
Pay as you go braucht Kontrolle.
Kosten entstehen auch durch Traffic,
Speicher,
Logs
und Snapshots.
Budget planen.
Kostenalarme setzen.
Tags pflegen.
Untagged Resources vermeiden.
Rightsizing spart Kosten.
Overprovisioning kostet unnötig.
Underprovisioning gefährdet Betrieb.
Auto Scaling passt Ressourcen an.
Horizontal = mehr Instanzen.
Vertikal = stärkere Instanz.
Scale Out = mehr.
Scale Up = größer.
Load Balancer verteilt Last.
Health Check prüft Dienstgesundheit.
Hochverfügbarkeit planen.
Cloud ist nicht automatisch hochverfügbar.
Region und Zone bewusst wählen.
Disaster Recovery vorher planen.
RTO = Wiederherstellungszeit.
RPO = Datenverlust.
Patchverantwortung hängt vom Service-Modell ab.
Änderungen dokumentieren.
Rollback vor Änderung planen.
IaC beschreibt Infrastruktur als Code.
Configuration Drift vermeiden.
CI/CD automatisiert Bereitstellung.
Runbooks helfen im Betrieb.
Incident Response vorbereiten.
SLI misst.
SLO setzt Ziel.
SLA ist Zusage.