AWS Cloud Engineering für den Mittelstand — Der komplette Leitfaden
AWS Cloud Engineering für den Mittelstand: Architektur, Kosten, Sicherheit und Migration – praxisnah erklärt mit konkreten Beispielen.
AWS Cloud Engineering für den Mittelstand — Der komplette Leitfaden
<p data speakable 89 % der deutschen Unternehmen nutzen Cloud Dienste — aber nur 35 % der Mittelständler setzen AWS systematisch auf (Quelle: Bitkom 2025). Der Rest betreibt Insellösungen ohne Infrastructure as Code, ohne Monitoring, ohne reproduzierbare Architektur. Das Ergebnis: unkontrollierte Kosten, Sicherheitslücken und Wissensmonopole bei einzelnen Mitarbeitern. Dieser Leitfaden zeigt, wie mittelständische Unternehmen AWS Cloud Engineering strukturiert angehen — von CDK basierter Infrastruktur über Kostenoptimierung und Security bis zur Migration bestehender Systeme. Alles DSGVO konform in der Frankfurt Region (eu central 1).</p
Warum AWS für den Mittelstand?
AWS ist mit einem Marktanteil von 31 Prozent (Stand: Gartner 2025) der weltweit führende Cloud Provider. Für den deutschen Mittelstand gibt es drei ausschlaggebende Argumente:
Frankfurt Region (eu central 1). AWS betreibt seit 2014 eine vollständige Region in Frankfurt am Main. Ihre Daten verlassen Deutschland nicht — ein entscheidender Punkt für DSGVO Konformität. AWS ist zertifizierter Auftragsverarbeiter nach Art. 28 DSGVO und bietet standardisierte Data Processing Agreements.
Managed Services statt Eigenbetrieb. AWS bietet über 200 Managed Services — von Datenbanken (RDS, DynamoDB) über Container (ECS, Fargate) bis zu KI Services (Bedrock, Textract, Comprehend). Sie betreiben keine Server, keine Datenbanken, kein Patching. AWS übernimmt das. Sie konzentrieren sich auf Ihre Geschäftslogik.
Pay as you go. Keine Vorabinvestitionen, keine Mindestlaufzeiten. Sie zahlen nur für das, was Sie nutzen — und können jederzeit skalieren. Das ist besonders für mittelständische Unternehmen attraktiv, die keine Millionenbudgets für IT Infrastruktur haben.
AWS vs. Azure vs. Google Cloud — kurz verglichen
| Kriterium | AWS | Azure | Google Cloud | | | | | | | Deutsche Region | Frankfurt (2014) | Frankfurt (2019) | Frankfurt (2021) | | Managed Services | 200+ | 200+ | 150+ | | KI Services (Foundation Models) | Bedrock (Claude, Llama, Mistral) | OpenAI Service | Vertex AI (Gemini) | | IaC Tool (nativ) | CDK (TypeScript, Python) | Bicep | Deployment Manager | | Serverless Reife | Hoch (Lambda seit 2014) | Mittel (Functions) | Mittel (Cloud Functions) | | Mittelstands Fokus DE | Stark (Partner Netzwerk) | Stark (MS Ökosystem) | Schwächer |
Für Unternehmen, die bereits Microsoft 365 nutzen, kann Azure eine logische Wahl sein. Für KI Workloads, Serverless Architekturen und maximale Service Breite ist AWS typischerweise die stärkste Plattform.
Die typische AWS Architektur für den Mittelstand
Eine gut strukturierte AWS Architektur für mittelständische Unternehmen folgt fünf Prinzipien:
1. Serverless first — Lambda, API Gateway, DynamoDB statt selbst betriebener Server 2. Infrastructure as Code — Jede Ressource in CDK definiert, versioniert in Git 3. Least Privilege — IAM Rollen mit minimalen Berechtigungen 4. Monitoring ab Tag 1 — CloudWatch, Alarme, Dashboards von Anfang an 5. Kostencontrolling — Budgets, Anomalie Erkennung, tagging basierte Zuordnung
Referenz Architektur: Dokumentenverarbeitung
Diese Architektur verarbeitet eingehende Dokumente (PDFs, Scans) vollautomatisch: Texterkennung mit Textract, KI Analyse mit Bedrock, Ergebnisse in S3 und DynamoDB, Benachrichtigung per E Mail oder Slack.
Kosten für diese Architektur: Bei 1.000 Dokumenten pro Monat liegen die AWS Kosten typischerweise bei 50–100 Euro — inklusive Textract, Bedrock, Lambda Ausführungen und Speicher. Kein Server, der rund um die Uhr läuft und Geld verbrennt.
Infrastructure as Code mit AWS CDK
Der größte Fehler, den ich bei Mittelstandskunden sehe: Infrastruktur wird manuell in der AWS Konsole zusammengeklickt. Das funktioniert für einen Prototypen — aber nicht für den Produktivbetrieb.
Warum? Weil niemand dokumentiert, was konfiguriert wurde. Weil eine zweite Umgebung (Staging, Test) nicht reproduzierbar ist. Und weil eine Änderung am Freitagnachmittag, die am Montag Probleme verursacht, nicht nachvollziehbar ist.
AWS CDK (Cloud Development Kit) löst dieses Problem. Sie definieren Ihre gesamte Infrastruktur in TypeScript (oder Python) — als Code, versioniert in Git, reviewbar im Pull Request, testbar vor dem Deployment.
Ein cdk deploy erstellt diese Ressource identisch in jedem AWS Account. Ein cdk diff zeigt Ihnen vorher, was sich ändern wird. Ein cdk destroy räumt alles wieder auf. Das ist der Unterschied zwischen professionellem Cloud Engineering und Klicken in der Konsole.
CDK vs. Terraform vs. CloudFormation
| Kriterium | AWS CDK | Terraform | CloudFormation | | | | | | | Sprache | TypeScript, Python, Java | HCL (eigene Sprache) | YAML/JSON | | Abstraktion | Hoch (Constructs) | Mittel | Niedrig | | Multi Cloud | Nein (AWS only) | Ja | Nein | | Lernkurve | Niedrig (bekannte Sprachen) | Mittel | Hoch (verbose YAML) | | Testing | Jest, pytest | terraform test | Keine native Tests | | Community Constructs | constructs.dev (1000+) | Terraform Registry | Begrenzt |
Für reine AWS Umgebungen empfehle ich CDK. Sie schreiben TypeScript — dieselbe Sprache wie Ihre Lambda Funktionen. Constructs wie cdk monitoring constructs erstellen ein vollständiges Monitoring Dashboard mit einer einzigen Zeile Code.
Kostenmanagement: AWS muss nicht teuer sein
Der häufigste Vorbehalt im Mittelstand: "Cloud ist zu teuer." Das stimmt — wenn Sie AWS wie ein Rechenzentrum betreiben. EC2 Instanzen, die 24/7 laufen, obwohl sie nur tagsüber gebraucht werden. RDS Datenbanken in Multi AZ, obwohl die Anwendung keine Hochverfügbarkeit braucht. NAT Gateways, die 35 Euro/Monat kosten und oft unnötig sind.
Serverless ändert die Gleichung fundamental. Lambda kostet nichts, wenn es nicht ausgeführt wird. DynamoDB On Demand berechnet nur tatsächliche Lese und Schreiboperationen. API Gateway kostet 1 Dollar pro Million Requests.
Kosten Optimierung in der Praxis
| Maßnahme | Typische Ersparnis | | | | | EC2 → Lambda/Fargate (wo möglich) | 40–70 % | | Reserved Instances für stabile Workloads | 30–60 % | | S3 Intelligent Tiering | 20–40 % auf Speicherkosten | | NAT Gateway → VPC Endpoints | 30–50 Euro/Monat pro Gateway | | Development Umgebungen abends abschalten | 60 % auf Dev Kosten | | Unused Resources aufräumen (EBS, EIPs, Snapshots) | Sofort messbar |
Kosten Controlling ab Tag 1
Drei AWS Services, die Sie am ersten Tag einrichten sollten:
1. AWS Budgets — Monatliches Budget mit Alarm bei 80 % und 100 % 2. Cost Anomaly Detection — KI basierte Erkennung ungewöhnlicher Kostenspitzen 3. Cost Explorer mit Tags — Kosten nach Projekt, Team oder Umgebung aufschlüsseln
Eine realistische monatliche AWS Rechnung für ein Mittelstandsunternehmen mit 3–5 Serverless Anwendungen: 200–800 Euro. Weniger als ein einziger dedizierter Server bei einem klassischen Hoster.
Sicherheit: AWS Shared Responsibility Model
Sicherheit in der Cloud folgt dem Shared Responsibility Model : AWS sichert die Infrastruktur (physische Rechenzentren, Netzwerk, Hypervisor). Sie sichern alles darüber — IAM Konfiguration, Verschlüsselung, Netzwerkregeln, Anwendungscode.
Die 10 wichtigsten Sicherheitsmaßnahmen
1. MFA auf Root Account — Pflicht, keine Diskussion 2. Kein Root Account im Alltag — Separater Admin User mit IAM Identity Center 3. Least Privilege IAM — Rollen mit minimalen Berechtigungen, keine Wildcards ( ) 4. VPC Isolation — Private Subnetze für Datenbanken und interne Services 5. Verschlüsselung überall — KMS für S3, RDS, DynamoDB, EBS (standardmäßig aktiviert) 6. CloudTrail — Lückenlose Protokollierung aller API Aufrufe (30+ Tage Retention) 7. GuardDuty — Automatische Bedrohungserkennung (einschalten und vergessen) 8. Security Hub — Zentrales Dashboard für Compliance und Findings 9. Config Rules — Automatische Prüfung der Konfiguration gegen Best Practices 10. VPC Endpoints — Services über private Verbindungen statt über das Internet ansprechen
Detaillierte Anleitungen zu IAM Setup, MFA Konfiguration und Kostenabsicherung finden Sie in meinem Artikel AWS Account richtig einrichten.
DSGVO Konformität auf AWS
Für DSGVO konforme KI Workloads gelten zusätzliche Anforderungen:
Region eu central 1 verwenden — Daten bleiben in Frankfurt Data Processing Agreement mit AWS abschließen (online verfügbar) Bedrock Data Policies aktivieren — kein Model Training mit Ihren Daten CloudTrail + S3 Access Logging für Audit Nachweise Datensparsamkeit — nur notwendige Daten verarbeiten
Monitoring und Observability
Eine Cloud Infrastruktur ohne Monitoring ist wie ein Auto ohne Tacho. Sie merken erst, dass etwas nicht stimmt, wenn es zu spät ist.
Die drei Säulen der Observability
Metriken (CloudWatch Metrics): CPU Auslastung, Memory, Request Latenz, Error Rate. Alarme bei Schwellwertüberschreitung — per E Mail, Slack oder PagerDuty.
Logs (CloudWatch Logs): Strukturierte Logs aus Lambda, ECS, API Gateway. Log Insights für SQL ähnliche Abfragen über Millionen von Log Einträgen.
Traces (AWS X Ray): Verteilte Traces über mehrere Services hinweg. Wo verbringt ein Request die meiste Zeit? Welcher Service ist der Flaschenhals?
Mit cdk monitoring constructs erstellen Sie ein vollständiges Monitoring Setup in wenigen Zeilen CDK Code — inklusive Dashboards, Alarme und Anomalie Erkennung für alle Ihre Services.
Migration: Vom On Premise in die Cloud
Die Migration bestehender Systeme in die Cloud ist der Punkt, an dem viele Mittelständler zögern. Verständlich — laufende Systeme anzufassen, birgt Risiken. Aber die Risiken des Nicht Migrierens sind größer: steigende Wartungskosten, fehlende Skalierbarkeit, Sicherheitslücken in veralteter Software.