Cloud & DevOps für den Mittelstand — Migration, Architektur, Kosten 2026

Cloud und DevOps sind 2026 keine Strategie-Folie mehr, sondern Betriebspflicht. Die deutsche Mittelstands-Realität: Microsoft-Stack im Office, ein Rechenzentrum im Keller, ein zweites bei einem Co-Location-Anbieter, dazu zwei oder drei SaaS-Tools, deren Daten niemand vollständig im Blick hat. Wenn jetzt der Hardware-Refresh ansteht, das ERP modernisiert werden muss oder die Geschäftsführung „KI-fähig" werden will — dann führt kein Weg mehr an einer ehrlichen Cloud-Strategie vorbei. Dieser Leitfaden zeigt, wie eine fundierte Cloud- und DevOps-Reise für einen 50- bis 500-Personen-Mittelständler tatsächlich aussieht: vom ersten Workload-Audit über Migrations-Pattern, Infrastructure-as-Code, Kubernetes-Entscheidung, CI/CD-Aufbau und Observability bis zu FinOps-Disziplin und Cloud-Exit-Strategie. Mit echten Preisen, echten Tool-Versionen und ohne Marketing-Geschwätz.

Warum Cloud + DevOps 2026 für den Mittelstand unverzichtbar sind

Die treibende Frage ist nicht mehr „Cloud ja oder nein", sondern „wie Cloud, in welchem Tempo und mit welchem Betriebsmodell". Drei harte Faktoren erzwingen die Entscheidung. Erstens Hardware-Lebenszyklen: der typische Mittelständler hat 2019/2020 letztmals investiert, die Wartungsverträge laufen 2026/2027 aus, neue Server bei deutschen Distributoren sind seit der Halbleiter-Krise 30 bis 50 Prozent teurer als vor der Pandemie. Zweitens Personalkosten: ein vernünftiger Linux-Administrator kostet in Süddeutschland 75.000 bis 95.000 Euro plus Nebenkosten — eine Cloud-Plattform mit 30 Workloads betreibt sich mit 0,5 dieser Stelle, ein eigenes Rechenzentrum braucht 2 bis 3 Vollzeit-Kapazitäten allein für Patches, Backups und Hardware-Wechsel. Drittens Software-Vendor-Drift: SAP, Microsoft, Oracle, Atlassian — alle großen Anwendungs-Anbieter verschieben aktiv in die Cloud, lokale Lizenzen werden teurer oder eingestellt. Wer 2028 noch SAP on-Premise betreiben will, zahlt ein deutliches Premium gegenüber RISE with SAP.

Auf der anderen Seite stehen die typischen Mittelstands-Bremsen: ein gewachsenes ERP mit Custom-Erweiterungen, Datenschutz-Bedenken der Geschäftsführung, fehlende Cloud-Kompetenz im Team, und die berechtigte Sorge vor Kostenexplosion. Genau diese Punkte adressiert eine sauber geplante Cloud-und-DevOps-Strategie: schrittweise Migration statt Big-Bang, EU-Daten-Residenz per Konfiguration, Skill-Aufbau durch begleitende Coaching-Modelle, und ein verbindliches FinOps-Regime von Tag eins. Die Entscheidung lautet 2026 also nicht mehr ob, sondern wie diszipliniert.

Cloud-Modelle (Public, Private, Hybrid, Multi-Cloud) — wann was sinnvoll

Vier Architektur-Modelle dominieren den Markt, und jedes hat seinen Anwendungsfall.

Public Cloud bedeutet Multi-Tenant bei einem Hyperscaler (AWS, Azure, GCP) oder einem EU-souveränen Anbieter (IONOS, OVHcloud, STACKIT, T-Systems). Die Ressourcen werden gemeinsam genutzt, abgerechnet wird verbrauchsbasiert. Für 80 Prozent der Mittelstands-Workloads ist Public Cloud die richtige Wahl: keine Kapital-Investition, sofortige Verfügbarkeit, globale Regionen, ein riesiger Service-Katalog. Typische Bedenken (Daten-Residenz, Sicherheit, Lock-in) sind mit Disziplin lösbar — siehe weiter unten.

Private Cloud bedeutet dedizierte Infrastruktur, entweder im eigenen Rechenzentrum (VMware, OpenStack, Proxmox, Nutanix) oder als gemietete Single-Tenant-Umgebung bei einem Anbieter. Sinnvoll für Workloads mit harten Latenz-Anforderungen, sehr großen Datenmengen mit Egress-Kosten in der Public Cloud, oder regulatorischen Vorgaben, die Multi-Tenancy ausschließen. Der Aufwand für Hardware-Lifecycle, Patches und Kapazitätsplanung bleibt vollständig beim Kunden.

Hybrid Cloud kombiniert beide Welten — typisches Muster im DACH-Mittelstand: ERP und Datenbank-Cluster on-premise, Web-Frontends, Analytics-Workloads und Dev-/Test-Umgebungen in Public Cloud, verbunden über VPN oder Direct Connect / ExpressRoute. Hybrid ist die realistische Migration-Zwischenstufe für die meisten Mittelständler — selten ein dauerhaftes Zielbild, sondern eine 3- bis 5-Jahres-Übergangsphase.

Multi-Cloud bedeutet bewusste Nutzung von mindestens zwei Hyperscalern. Die Marketing-Begründung („Vendor-Lock-in vermeiden") trägt selten, weil echte Portabilität teuer ist und Multi-Cloud die Betriebskomplexität multipliziert. Echte Multi-Cloud-Gründe sind: ein bestimmter Service ist nur bei einem Anbieter verfügbar (Vertex AI für ML-Modelle, AWS Outposts für Edge, Azure für M365-Integration), regulatorische Trennung zwischen Geschäftsfeldern, oder Geo-Redundanz auf Cloud-Anbieter-Ebene. Für 95 Prozent der Mittelständler ist Single-Cloud die richtige Wahl, ergänzt durch klare Exit-Vorbereitung.

Die drei Hyperscaler: AWS vs Azure vs GCP — Stärken im DACH-Markt

Die drei großen US-Anbieter unterscheiden sich nicht primär in den Grundfunktionen — Compute, Storage, Datenbank, Netzwerk liefern alle drei in vergleichbarer Qualität. Die Unterschiede liegen in der Tiefe der spezialisierten Dienste und den natürlichen Synergien mit dem bestehenden Stack.

Amazon Web Services (AWS) hat den breitesten Service-Katalog (über 240 Dienste in 2026), die reifste Drittanbieter-Integration und die meisten Lern-Ressourcen. Stärken: EC2 mit der größten Instanz-Vielfalt, S3 als De-facto-Standard für Object Storage, Lambda als Pionier-Serverless-Plattform, RDS und Aurora als Datenbank-Workhorses. Schwäche: AWS ist gefühlt das amerikanischste Erlebnis — Konsole nur teilweise auf Deutsch, Support standardmäßig in Englisch, Identitäts-Integration mit Active Directory aufwendig.

Microsoft Azure ist die natürliche Wahl für DACH-Mittelständler mit Microsoft-Stack. Wer bereits Active Directory, Microsoft 365, Windows Server und SQL Server einsetzt, spart durch Azure Hybrid Benefit 20 bis 40 Prozent gegenüber AWS — die Lizenzen können in die Cloud mitgenommen werden. Stärken: Entra ID (vormals Azure AD) als Identity-Hub, native Integration mit M365, Azure Arc für Hybrid-Management, und ein deutsches Frontend (Konsole, Doku, Support). Schwächen: Service-Stabilität historisch volatiler als AWS, Service-Naming wird häufiger umbenannt (was Doku schnell veraltet).

Google Cloud Platform (GCP) ist der kleinste, aber technologisch ambitionierteste der drei. Stärken: BigQuery als analytisches Powerhouse (häufig genannt der einzige Grund, GCP überhaupt zu nutzen), Vertex AI mit Zugang zu Gemini-Modellen und Open-Source-LLMs, Anthos für Hybrid-Kubernetes, und eine angenehm konsistente API-Architektur. Schwächen: kleinerer Service-Katalog, weniger DACH-Partnerschaften, Marketing-Präsenz in Deutschland deutlich schwächer.

Pragmatische Faustregel für DACH-Mittelständler 2026: Microsoft-Stack-Häuser nutzen Azure, daten-lastige Workloads gehen zu GCP, für breite Service-Vielfalt und beste Drittanbieter-Integration wählen Sie AWS. Wenn keine dieser drei Gründe klar trägt, ist Azure für die meisten DACH-Mittelständler der vernünftige Default — schlicht, weil die Microsoft-Identität bereits steht.

Cloud-Migration-Strategien (Lift-and-Shift, Re-Platform, Re-Architect, 6 R's)

Die etablierte Migrations-Taxonomie kommt ursprünglich von Gartner und wurde von AWS popularisiert: die „6 R's". Jeder Workload bekommt eine der sechs Migrations-Strategien zugeordnet, basierend auf Geschäftswert, technischer Reife und Modernisierungs-Potenzial.

Retire — der einfachste Fall: der Workload wird abgeschaltet. Bei jeder ehrlichen Migrations-Inventur stellt sich heraus, dass 5 bis 15 Prozent der Server überhaupt nicht mehr aktiv genutzt werden. Die zugehörigen Lizenzen, Backups und Wartungs-Kosten entfallen sofort. Erfahrungsgemäß die Kategorie mit dem besten ROI pro Stunde Analyse.

Retain — der Workload bleibt vorerst on-premise. Gründe: regulatorische Beschränkung, Latenz zu lokalen Maschinen, anstehende Abkündigung, oder schlicht ungelöste Lizenz-Fragen. „Retain" ist legitim, sollte aber mit Wiedervorlage-Datum versehen werden — sonst bleibt der Server für immer Sonderfall.

Rehost (Lift-and-Shift) — der Workload wird unverändert in die Cloud verschoben, typischerweise als VM. Tooling: AWS Application Migration Service, Azure Migrate, Google Migrate to Virtual Machines. Vorteil: schnellste Migration, geringstes Risiko. Nachteil: keine Cloud-Kostenoptimierung, kein Modernisierungs-Gewinn. Sinnvoll für Workloads, die in 3 bis 5 Jahren ohnehin abgelöst werden.

Replatform — der Workload wird mit minimalen Änderungen modernisiert. Klassisches Muster: SQL-Server-Datenbank von eigener VM auf Azure SQL Managed Instance, IIS-Webserver auf Azure App Service, Linux-Anwendung in Docker-Container. Patching, Backup und Hochverfügbarkeit übernimmt der Cloud-Anbieter. Bester Kompromiss aus Aufwand und Modernisierungs-Gewinn — empfohlen für 40 bis 60 Prozent eines typischen Migrations-Portfolios.

Repurchase — der Workload wird durch eine SaaS-Variante ersetzt. Lokale CRM wird Salesforce, eigene HR-Software wird Personio, On-Prem-Sharepoint wird Microsoft 365, eigene Helpdesk-Software wird Zendesk oder Freshdesk. Schnell umzusetzen, oft mit fühlbarem Funktions-Sprung — aber Datenmigration und Schnittstellen-Anpassung sind nicht zu unterschätzen.

Refactor / Re-Architect — der Workload wird grundlegend neu gebaut, typischerweise als Container- oder Serverless-Architektur. Monolithische Anwendung wird in Microservices geschnitten, Batch-Jobs werden Lambda-Funktionen, On-Premise-Message-Queue wird Managed Service. Hoher Aufwand (oft 6 bis 18 Monate pro Workload), aber strategisch wertvoll für Kern-Anwendungen mit langer Lebensdauer.

In der Praxis ergibt eine ehrliche Migrations-Inventur ein Portfolio etwa folgender Form: 10 Prozent Retire, 15 Prozent Retain, 25 Prozent Rehost (schnelles Tempo), 35 Prozent Replatform (das Rückgrat), 10 Prozent Repurchase, 5 Prozent Refactor. Diese Verteilung dauert für einen typischen Mittelständler-Bestand 6 bis 18 Monate und kostet zwischen 60.000 und 250.000 Euro Beratungs- und Migrations-Leistung.

Infrastructure-as-Code (Terraform, Pulumi, OpenTofu, CDK)

Infrastructure-as-Code (IaC) bedeutet: jede Cloud-Ressource — VM, Subnet, Datenbank, IAM-Rolle, Firewall-Regel — wird als versionierter Code beschrieben, geprüft und automatisch ausgerollt. Ohne IaC ist seriöser Cloud-Betrieb 2026 nicht möglich. Klicken in der Konsole erzeugt Drift, vergessene Ressourcen und fehlende Audit-Spur.

Terraform (HashiCorp, ab Version 1.5 unter der Business Source License BSL) ist seit zehn Jahren der Marktführer mit der breitesten Provider-Abdeckung (über 4.000 offizielle und Community-Provider in 2026). Stärke: deklarative HCL-Syntax, riesiges Ökosystem, robuste State-Verwaltung mit Terraform Cloud, Spacelift oder Self-Hosted-Backends in S3. Schwäche: die BSL-Lizenz-Verschiebung 2023 hat viele Open-Source-Projekte und EU-Behörden zur Migration gezwungen.

OpenTofu ist der Linux-Foundation-Fork von Terraform 1.5 unter der ursprünglichen MPL 2.0. API-kompatibel zu Terraform, kann bestehende Terraform-State-Files und -Module direkt nutzen. Für neue Projekte unter EU-Beschaffungs-Regeln oder Open-Source-Pflichten ist OpenTofu 2026 die pragmatische Wahl. Provider-Abdeckung leicht hinter Terraform, aber alle Hyperscaler werden unterstützt.

Pulumi verwendet echte Programmiersprachen statt HCL — TypeScript, Python, Go, .NET, Java. Vorteil: native Schleifen, Bedingungen, Modularisierung mit Sprach-Konstrukten, gute Test-Möglichkeiten mit Standard-Frameworks. Sinnvoll für Entwickler-getriebene Teams mit komplexer Infrastruktur-Logik. Nachteil: kleinere Community, weniger Beispiele, höhere Einstiegshürde.

AWS CDK, Azure Bicep und Google Cloud Deployment Manager sind die hersteller-spezifischen Werkzeuge. CDK kompiliert TypeScript/Python in CloudFormation-Templates, Bicep ist eine deutlich angenehmere Abstraktion über ARM-Templates. Beide sind für Single-Cloud-Setups exzellent, scheitern aber an Multi-Cloud-Anforderungen. Für DACH-Mittelständler mit Azure-Stack ist Bicep eine ernste Alternative zu Terraform — kürzere Lernkurve, native Tool-Integration.

Unsere Empfehlung für 2026: OpenTofu mit AzureRM- oder AWS-Provider als Default, ergänzt durch Atlantis oder Terraform Cloud für Plan-Approval-Workflow, und tflint plus Checkov als Pre-Commit-Validierung. Wer Microsoft-only fährt und keine Multi-Cloud-Sorge hat, ist mit Bicep ebenfalls gut bedient.

Container & Kubernetes — wann sinnvoll, wann übertrieben

Kubernetes ist die unbestrittene Plattform für Container-Orchestrierung in 2026 — und gleichzeitig das Tool mit dem höchsten Hype-zu-Praxis-Verhältnis im Mittelstand. Die ehrliche Frage ist nicht „brauchen wir Kubernetes", sondern „brauchen wir die Betriebskomplexität, die Kubernetes mitbringt".

Wann Kubernetes sinnvoll ist: wenn Sie 20 oder mehr eigenständige Services betreiben, Multi-Region-Verfügbarkeit benötigen, hybride Workloads zwischen Cloud und On-Premise portabel halten wollen, oder eine ausgeprägte Microservice-Architektur fahren. In diesen Fällen liefert Kubernetes echte Werte: einheitliche Deployment-API, automatisches Service-Discovery, Self-Healing, Rolling-Updates ohne Downtime.

Wann Kubernetes übertrieben ist: wenn Sie weniger als 10 Services haben, nur eine Region brauchen, und das Team nicht bereits Container-Erfahrung mitbringt. Der Betriebsaufwand eines produktiven Kubernetes-Clusters liegt realistisch bei 0,5 bis 1 Vollzeit-Stelle — Cluster-Upgrades alle 4 Monate, Network-Policy-Pflege, Certificate-Rotation, RBAC, Storage-CSI-Treiber. Wer diesen Aufwand nicht stemmen kann, läuft mit veralteten Clustern (und damit unsicher).

Die Container-Alternativen sind 2026 reif und für viele Mittelständler die bessere Wahl: AWS App Runner (Container ohne Orchestrator-Sichtbarkeit, Auto-Scaling, HTTPS-Termination), Azure Container Apps (basierend auf Kubernetes und KEDA, aber als PaaS abstrahiert), Google Cloud Run (Pionier des Container-Serverless), und für reine Web-Workloads App Service bzw. AWS Elastic Beanstalk. Diese Dienste liefern 80 Prozent des Container-Nutzens bei 20 Prozent der Betriebskomplexität.

Wenn Kubernetes die richtige Wahl ist, dann Managed-Kubernetes statt Self-Hosted: AWS EKS, Azure AKS, Google GKE — die Kontrollebene wird vom Cloud-Anbieter betrieben, Sie kümmern sich nur um die Worker-Knoten und Workloads. GKE Autopilot geht noch einen Schritt weiter und übernimmt auch die Worker-Node-Verwaltung. Self-Hosted-Kubernetes (kubeadm, k3s, RKE2) hat 2026 nur noch in sehr speziellen Hybrid- oder Edge-Szenarien einen Platz.

Ergänzend zur Kubernetes-Wahl: Helm als Paket-Manager (Standard für die meisten Open-Source-Komponenten), Kustomize für Environment-Overlays, External Secrets Operator für die Anbindung an HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault, und Cilium als Container Network Interface mit integrierter Network-Policy- und Observability-Schicht.

CI/CD-Pipelines (GitHub Actions, GitLab CI, Jenkins, ArgoCD)

Continuous Integration und Continuous Deployment sind das zentrale Nervensystem moderner Software-Lieferung. Jeder Commit wird automatisch getestet, jeder Merge erzeugt ein Artefakt, jedes Artefakt ist potenziell deploybar. Im Mittelstand sehen wir 2026 vier dominierende Tooling-Familien.

GitHub Actions ist der De-facto-Standard für Teams, die ohnehin GitHub als Code-Hoster nutzen. Stärken: enge Integration mit Pull-Requests, riesiger Marketplace an Open-Source-Actions, einfache YAML-Syntax, gute Secrets-Verwaltung mit Environments und OpenID-Connect-Federation zu AWS/Azure/GCP (keine langlebigen Schlüssel mehr nötig). Schwäche: Self-Hosted-Runner-Setup für sensible Workloads ist nicht trivial.

GitLab CI liefert eine vergleichbare Pipeline-Funktionalität mit den Vorteilen einer integrierten Plattform (Issues, Merge-Requests, Container-Registry, Package-Registry, Security-Scanning, alles in einem). Für Mittelständler mit On-Premise-Anforderung ist die selbst-gehostete GitLab-Community- oder Enterprise-Edition eine ernste Wahl, gerade wenn EU-Daten-Residenz ein harter Punkt ist.

Jenkins ist in vielen Mittelstands-Häusern noch im Einsatz, oft historisch gewachsen. Stärken: maximale Flexibilität, riesige Plugin-Bibliothek. Schwächen: hoher Wartungsaufwand, Plugin-Sicherheits-Updates müssen aktiv gepflegt werden, deklarative Pipeline-Definition ist nachträglich aufgesetzt und fühlt sich nie ganz richtig an. Wer 2026 Jenkins neu einführen will, sollte sich gut begründen können — für die meisten Neuanlagen sind GitHub Actions oder GitLab CI klar überlegen.

ArgoCD und Flux sind die zwei dominanten GitOps-Werkzeuge für Kubernetes-Deployments. Sie ergänzen die klassische CI (Build, Test, Push ins Image-Repository) um eine deklarative CD-Schicht: der gewünschte Cluster-Zustand liegt in Git, ein Agent im Cluster synchronisiert kontinuierlich gegen Git. Vorteile: vollständige Audit-Spur, automatische Rollbacks per Git-Revert, niemand braucht direkten kubectl-Zugriff auf Produktion. Für Teams mit mehr als drei Entwicklern und Kubernetes-Einsatz ist GitOps 2026 Best Practice.

Pflicht-Bestandteile einer ernsthaften Pipeline 2026: Unit-Tests mit Coverage-Gate, statische Code-Analyse (SonarQube, GitHub CodeQL, semgrep), Software-Composition-Analysis für Third-Party-Abhängigkeiten (Dependabot, Renovate, Snyk), Container-Image-Scan (Trivy, Grype), Infrastructure-Drift-Check (Checkov, tfsec, terrascan), und signierte Artefakte über Cosign oder Sigstore. Wer diese Bausteine nicht hat, liefert 2026 keine compliance-fähige Software-Pipeline.

Reepa Solutions Approach — Cloud-Migrations + DevOps-Coaching

Unser typisches Mandat folgt vier Bausteinen. Discovery (4 bis 8 Wochen): vollständige Workload-Inventur, Kategorisierung nach den 6 R's, Architektur-Skizze, Ziel-Kostenkalkulation, Risiko-Register. Liefert die belastbare Entscheidungsgrundlage statt vager Schätzungen. Foundation (4 bis 6 Wochen): Cloud-Landing-Zone mit IAM, Netzwerk, Logging, Backup-Policies, Cost-Management — die Plattform-Basis, auf der alle weiteren Workloads landen. Migrations-Sprints (2 bis 6 Wochen pro Welle): jeweils 5 bis 15 Workloads in einer Welle, mit Test- und Cutover-Plan. Operations-Übergabe (4 bis 8 Wochen): SRE-Praktiken, Runbooks, On-Call-Rotation, Post-Mortem-Format, FinOps-Dashboard.

Ergänzend bieten wir Cloud-Security-Validierung über unsere Plattform Reepa Security — wir prüfen Ihre Cloud-Konfiguration kontinuierlich auf Misconfiguration (IAM-Übervergaben, öffentliche S3-Buckets, fehlende Verschlüsselung, offene Security-Groups). Mehr dazu im Kapitel „Sicherheit in der Cloud" und im Cybersecurity-Pillar.

Observability + Monitoring (Prometheus, Grafana, OpenTelemetry, Datadog)

Observability — die Fähigkeit, das Verhalten eines Systems von außen zu verstehen — ruht 2026 auf drei Säulen: Metriken (numerische Zeitreihen wie Request-Rate, Fehler-Rate, Latenz), Logs (textuelle Ereignis-Aufzeichnungen) und Traces (verteilte Aufruf-Ketten zwischen Services). Wer eine dieser drei Säulen vernachlässigt, fliegt blind, wenn es brennt.

Open-Source-Stack: Prometheus für Metriken, Grafana für Visualisierung und Alarme, Loki oder OpenSearch für Logs, Tempo oder Jaeger für Traces. Verbunden über OpenTelemetry als hersteller-neutrales Instrumentierungs-Standard. Vorteil: kein Vendor-Lock-in, EU-Daten-Residenz garantiert (Self-Hosted), günstig bei großen Daten-Volumina. Nachteil: Sie müssen den Stack selber betreiben — typisch 0,3 bis 0,5 Vollzeit-Kapazität.

Managed-SaaS: Datadog, Grafana Cloud, New Relic, Honeycomb, Dynatrace. Vorteil: sofortige Verfügbarkeit, fertige Dashboards, integrierte AI-Korrelation, kein Betriebs-Overhead. Nachteil: Kosten skalieren mit Daten-Volumen — bei größeren Workloads schnell vier- bis fünfstellig pro Monat. Außerdem US-Anbieter mit Schrems-II-Implikationen für sensitive Daten.

Cloud-native: CloudWatch (AWS), Azure Monitor, Google Cloud Operations. Reicht für Basis-Überwachung der Cloud-Ressourcen selbst, wird aber bei Application-Performance-Monitoring schnell teuer und unhandlich. Für eine echte Cross-Service-Trace-Analyse sind die Cloud-Native-Tools 2026 noch nicht auf Datadog-Niveau.

Unsere Empfehlung für DACH-Mittelständler: OpenTelemetry als Instrumentierungs-Schicht (zukunftssicher, vendor-neutral), darunter wahlweise Open-Source-Stack (für Kostenkontrolle) oder Grafana Cloud (für minimal Betriebsaufwand bei moderaten Volumina). Datadog ist exzellent, aber preislich nur bei größeren Mittelständlern (ab 200 Personen) attraktiv.

Unabhängig vom Tool: definieren Sie Service-Level-Objectives (SLOs) — messbare Verfügbarkeits- und Latenz-Ziele pro kritischem Service — und überwachen Sie diese kontinuierlich. Ein SLO „99,5 Prozent Verfügbarkeit über 30 Tage" ist 2026 Pflicht-Bestandteil jeder produktiven Anwendung. Aus dem SLO leiten sich Alarm-Schwellen und Error-Budgets ab — ohne dieses Fundament wird Monitoring zum Symptom-Schauspiel.

FinOps — Cloud-Kosten unter Kontrolle bekommen

Die häufigste Cloud-Enttäuschung im Mittelstand: nach 12 Monaten ist die Rechnung doppelt so hoch wie kalkuliert. Die Ursachen sind selten dramatisch — meistens schleichende Vergessenheit. Unbenutzte VMs, ungelöschte Snapshots, übergroße Instanzen, S3-Buckets im teuren Standard-Tier, Datenbank-Backups in voller Größe statt inkrementell. FinOps ist die Disziplin, die genau das verhindert.

Drei FinOps-Hebel liefern in unserer Projekt-Erfahrung 80 Prozent der Einsparungen.

Right-Sizing. Die meisten Cloud-Instanzen sind 30 bis 50 Prozent überdimensioniert — typisch ein t3.large, der nur 15 Prozent CPU nutzt, oder eine D8s_v5, die seit Monaten Single-Digit-Auslastung zeigt. Tools: AWS Compute Optimizer, Azure Advisor, Google Recommender. Verfahren: 30 Tage Auslastung beobachten, auf die nächstkleinere Instanz reduzieren, eine Woche überwachen, gegebenenfalls weitere Reduktion. Einsparung typisch 25 bis 40 Prozent.

Reserved Instances / Savings Plans. Für stabile Workloads (Produktions-Datenbanken, Always-On-Services) buchen Sie ein- oder dreijährige Reservierungen statt On-Demand. Rabatte: AWS Savings Plans bis 72 Prozent, Azure Reserved VM Instances bis 65 Prozent, GCP Committed Use Discounts bis 70 Prozent. Voraussetzung: stabile Baseline-Last. Wer Reservierungen auf volatile Workloads ansetzt, zahlt für nicht-genutzte Kapazität.

Storage-Tiering und Cleanup. S3 Intelligent-Tiering bewegt selten genutzte Objekte automatisch in günstigere Klassen (40 bis 95 Prozent Ersparnis gegenüber Standard). Azure Cool und Archive vergleichbar. Hinzu kommt der klassische Cleanup: alte EBS-Snapshots, ungenutzte Disk-Images, vergessene Lambda-Versionen, alte Container-Images in der Registry. Typisch 10 bis 15 Prozent jeder Cloud-Rechnung sind reiner Ressourcen-Müll.

Ergänzend braucht es Cost-Allocation per Tagging (jede Ressource trägt Kostenstelle, Projekt, Owner als Tag — sonst keine Zurechnung möglich), Budget-Alarme auf Konto- und Projekt-Ebene, und ein monatliches FinOps-Review mit den verantwortlichen Teams. Werkzeuge: AWS Cost Explorer plus Cost Anomaly Detection, Azure Cost Management, GCP Cost Management, oder herstellerneutral Vantage, Cloudability, CloudHealth.

Sicherheit in der Cloud (kurze Einordnung)

Cloud-Sicherheit ist ein eigenes Thema, das wir im vollständigen Cybersecurity-Pillar ausführlich behandeln. An dieser Stelle die für Cloud- und DevOps-Verantwortliche wichtigsten Punkte in komprimierter Form.

Shared-Responsibility-Modell: der Cloud-Anbieter ist für die Sicherheit „der Cloud" verantwortlich (Hardware, Hypervisor, Netzwerk-Backbone, Datacenter). Sie sind für die Sicherheit „in der Cloud" verantwortlich (IAM-Konfiguration, Daten-Verschlüsselung, Anwendungs-Härtung, Netzwerk-Regeln). Wer das Modell nicht kennt, geht falsche Annahmen ein — etwa dass „die Cloud sicher ist".

Die typischen Cloud-Misconfiguration-Klassiker aus unseren Audits: öffentlich lesbare S3-Buckets mit personenbezogenen Daten, IAM-Rollen mit AdministratorAccess und ohne MFA, Lambda-Funktionen mit hardcoded Secrets, Security-Groups mit 0.0.0.0/0 auf Management-Ports, deaktivierte CloudTrail- oder Activity-Logs, fehlende Verschlüsselung auf RDS- und EBS-Volumes. Jeder einzelne Punkt ist mit IaC und einer CSPM-Lösung (Cloud Security Posture Management) automatisch prüfbar — Reepa Security übernimmt diese Validierung als kontinuierliche Plattform.

Identitäts-Pflicht: 2026 darf in einer Produktiv-Cloud niemand mehr mit langlebigen Zugriffsschlüsseln arbeiten. AWS IAM Identity Center, Azure Entra ID und Google Cloud Identity in Kombination mit Workload Identity Federation und OIDC ersetzen statische Schlüssel durch kurzlebige Tokens. CI/CD-Pipelines authentifizieren über OpenID-Connect-Federation, Mitarbeiter über SSO mit MFA. Wer 2026 noch Access-Keys verteilt, hat ein Sicherheits-Problem mit Ablaufdatum.

DSGVO + Datenresidenz EU

Die Frage „dürfen wir personenbezogene Daten überhaupt in der Cloud verarbeiten" ist 2026 lösbar — aber nicht mit Klick-and-Forget-Setup. Drei Schichten müssen sauber sein.

Auftragsverarbeitungs-Vertrag (AVV). Für jeden Cloud-Anbieter, der personenbezogene Daten in Ihrem Auftrag verarbeitet, brauchen Sie einen AVV nach Artikel 28 DSGVO. AWS, Azure, Google und die EU-souveränen Anbieter liefern Standard-AVVs. Die Standard-Vertragsklauseln (SCC) der EU-Kommission von 2021 sind die rechtliche Grundlage für den Transfer in die USA — sie müssen explizit einbezogen werden.

Daten-Residenz. Konfigurieren Sie Region-Beschränkungen technisch: AWS-Organisationsservice mit Service Control Policies, Azure Policy mit erlaubten Regionen, GCP Organization Policy Constraints. Daten verlassen den EU-Wirtschaftsraum nicht ohne explizite Genehmigung. Bei den meisten Workloads reichen die EU-Regionen Frankfurt, Dublin, Amsterdam, Paris oder Zürich vollständig aus.

Schrems-II-Risiko. Selbst bei EU-Region-Wahl bleibt das theoretische Risiko, dass US-Behörden über den CLOUD Act Zugriff auf Daten der US-Mutter-Konzerne anfordern. Für hochsensitive Daten gibt es drei Pfade: a) EU-souveräne Anbieter (IONOS, OVHcloud, STACKIT, T-Systems Open Sovereign Cloud), b) Customer-Managed-Keys mit Bring-Your-Own-Key — der Cloud-Anbieter kann die Daten technisch nicht entschlüsseln, c) Hybrid-Setup mit den sensitivsten Workloads on-premise und nur weniger kritische Workloads in der Public Cloud.

Praxis-Empfehlung für die meisten Mittelständler: Hyperscaler in EU-Region, dokumentierter AVV mit SCC, Customer-Managed-Keys für die kritischsten Daten-Klassen, Datenschutz-Folgenabschätzung für Workloads mit hohem Risiko. Das ist 2026 rechtssicher umsetzbar und für die meisten Geschäftsmodelle ausreichend.

Was kostet eine Cloud-Migration 2026

Die Frage ist berechtigt und verdient eine ehrliche Antwort. Wir geben Orientierung in realen Zahlen für einen typischen Mittelständler mit 20 bis 50 Workloads, 50 bis 200 Mitarbeitern.

Discovery und Migrations-Plan: 12.000 bis 30.000 Euro für die vollständige Inventur, 6-R-Kategorisierung, Ziel-Architektur-Skizze und Business-Case. Dauer: 4 bis 8 Wochen. Lohnt sich auch dann, wenn die Migration anschließend mit einem anderen Partner umgesetzt wird — die Entscheidungsgrundlage ist Gold wert.

Foundation (Landing Zone): 15.000 bis 40.000 Euro für die Basis-Cloud-Plattform mit IAM, Netzwerk-Topologie, Logging-Hub, Backup-Strategie, FinOps-Setup. Einmal-Investition, danach betreibt sich die Plattform weitgehend selbst.

Migrations-Sprints: Pro Workload kalkulieren Sie als Faustregel — Rehost 1.500 bis 4.000 Euro, Replatform 4.000 bis 12.000 Euro, Refactor 8.000 bis 60.000 Euro. Bei einem typischen Portfolio (50 Prozent Replatform, 30 Prozent Rehost, 15 Prozent Repurchase, 5 Prozent Refactor) landen Sie für 30 Workloads bei 120.000 bis 300.000 Euro Beratungs- und Migrations-Leistung über 6 bis 12 Monate.

Laufende Cloud-Kosten: nach erfolgreicher Migration mit sauberem Right-Sizing und Reserved Instances liegen die monatlichen Cloud-Verbrauchskosten typischerweise bei 60 bis 80 Prozent der vorherigen On-Premise-TCO (Total Cost of Ownership inkl. Hardware-Abschreibung, Strom, Kühlung, Wartung, Personal). Ohne FinOps-Disziplin können sie auch leicht 120 Prozent erreichen — der Unterschied ist die Disziplin, nicht die Cloud.

DevOps-Coaching: 1.500 bis 4.000 Euro pro Tag für begleitendes Pair-Working, Workshops, Architektur-Reviews. Wir empfehlen 20 bis 40 Coaching-Tage über die gesamte Migrations-Phase — das sichert die Wissens-Übergabe und macht Sie vom Partner unabhängig.

Häufige Fragen

Vertiefende Artikel & Cases

Diese Pillar deckt den Überblick ab — für die operative Tiefe verweisen wir auf die spezialisierten Artikel pro Themenbereich. Jeder Artikel ist eigenständig nutzbar und greift wieder auf diesen Cloud-und-DevOps-Guide zurück.

Aus unseren Projekten

Hakan Akcan · Gründer & Geschäftsführer Reepa Solutions

IT-Sicherheits- und Cloud-Architekt mit über zehn Jahren Erfahrung. Begleitet seit 2018 Cloud-Migrationen für DACH-Mittelständler und entwickelt mit seinem Team Reepa Security als kontinuierliche Cloud-Audit-Plattform. Schreibt regelmäßig über AWS, Azure, GCP, Kubernetes und FinOps.

Geprüft am: 22. Mai 2026 · Mehr über Hakan