Platform Engineering auf AWS: IDPs die wirklich genutzt werden

Einleitung: Warum Platform Engineering jetzt relevant ist

Gartner prognostiziert, dass bis 2026 80 % der großen Software-Engineering-Organisationen eigene Platform-Engineering-Teams etablieren — gegenüber 45 % im Jahr 2022 (Gartner, 2025). Platform Engineering ist damit kein Trend mehr, sondern eine strategische Notwendigkeit.

Der Treiber: Wachsende Cloud-Komplexität. Nach der Migration auf AWS stehen Unternehmen vor der Herausforderung, hunderte von Services, Accounts und Pipelines konsistent zu betreiben. Jedes Entwicklungsteam einzeln zu enablen, skaliert nicht. Eine Internal Developer Platform abstrahiert diese Komplexität und gibt Entwicklern Self-Service-Zugang — ohne Kontrollverlust.

Für DACH-Unternehmen kommt ein weiterer Faktor hinzu: Fachkräftemangel im Cloud-Bereich. Wenn jedes Team sein eigenes Infrastruktur-Setup pflegt, entstehen Silos, Inkonsistenzen und unnötiger Overhead. Platform Engineering löst dieses Problem durch Standardisierung und Wiederverwendung.

Begriffsklärung: IDP, Developer Portal und Platform Engineering

Internal Developer Platform (IDP)

Ein internes Produkt, das Entwicklern Self-Service-Zugang zu Infrastruktur, Deployments, Umgebungen und Konfigurationen bietet. Die IDP abstrahiert die Komplexität der darunterliegenden Cloud-Infrastruktur und ermöglicht es Teams, eigenständig zu arbeiten — ohne Tickets an Plattform-Teams.

Developer Portal

Die Benutzeroberfläche einer IDP. Ein Developer Portal wie Backstage zentralisiert Service-Kataloge, API-Dokumentation, Team-Informationen und Deployment-Status in einer einheitlichen Oberfläche.

Platform Engineering

Die Disziplin, interne Plattformen als Produkt zu konzipieren, zu bauen und zu betreiben. Platform Engineers behandeln Entwickler als Kunden und optimieren für Developer Experience, nicht für Feature-Completeness.

Golden Path

Ein vordefinierter, optimaler Weg für häufige Aufgaben (z. B. „neuen Microservice deployen"). Golden Paths sind opinionated — sie schränken bewusst ein, um Geschwindigkeit und Konsistenz zu maximieren.

Warum IDPs scheitern: Die fünf häufigsten Fehler

Bevor wir über Technologie sprechen, ist es entscheidend zu verstehen, warum so viele IDP-Initiativen nicht die erwarteten Ergebnisse liefern (platformengineering.org, 2024):

1. Kein Produkt-Mindset: Die Plattform wird als technisches Projekt behandelt statt als internes Produkt. Niemand übernimmt Product Ownership. Entwickler sehen ein Sammelsurium aus Scripts statt einer durchdachten Lösung.
2. Over-Engineering statt MVP: Statt ein konkretes Problem zu lösen (z. B. Self-Service-Environments), wird eine „fertige" Plattform designed. Scope Creep ohne frühen Stakeholder-Input ist die Folge.
3. Fehlender Developer Buy-in: Development-Teams, die an eigene Workflows gewöhnt sind, sehen Standardisierung als Einschränkung statt Enablement. Ohne frühes Feedback wird die Plattform an den Bedürfnissen vorbei gebaut.
4. Falsche Metriken: Feature-Anzahl statt Developer Experience. Erfolgreiche Plattformen messen Lead Time, Deployment Frequency und Developer Satisfaction — nicht die Anzahl integrierter Tools.
5. Mangelnde Wartung: Auch nach starkem initialen Adoption kann die Plattform verfallen. Verzögerte Upgrades, fehlende Integrationen neuer AWS-Services und technische Schulden führen zu Frustration und Abkehr.

Der AWS-Stack für Platform Engineering

AWS bietet ein umfassendes Ökosystem für den Aufbau einer IDP. Die Referenzarchitektur basiert auf vier Schichten:

AWS CDK als Infrastruktur-Abstraktionsschicht

AWS CDK (Cloud Development Kit) ist das Fundament jeder AWS-nativen IDP. CDK ermöglicht es Platform-Teams, höherwertige Abstractions (L3 Constructs) zu erstellen, die Best Practices für Sicherheit, Networking und Compliance einbetten (AWS DevOps Blog, 2024).

Ein Entwicklungsteam muss dann nicht mehr wissen, wie ein VPC mit Private Subnets, NAT Gateways und Security Groups konfiguriert wird. Es instanziiert stattdessen ein CompanyVpc-Construct, das alle Unternehmensstandards bereits enthält.

AWS Service Catalog für Self-Service mit Governance

AWS Service Catalog ist der zentrale Baustein für governance-konformes Self-Service (AWS Cloud Operations Blog, 2025). Platform-Teams definieren Produkte — vorkonfigurierte Infrastruktur-Templates — die Entwickler über ein Portal oder API bereitstellen können. Jedes Produkt durchläuft automatisch Sicherheits- und Compliance-Checks.

Der Workflow: Platform-Team erstellt CDK-basierte Templates → veröffentlicht sie als Service-Catalog-Produkte → Entwickler provisionieren über Self-Service → Governance wird automatisch durchgesetzt.

Backstage als Developer Portal

Backstage, von Spotify 2020 als Open Source veröffentlicht, hat sich zum De-facto-Standard für Developer Portals entwickelt. Auf AWS wird Backstage typischerweise auf Amazon EKS oder ECS deployt (AWS Open Source Blog).

Backstage zentralisiert:

• Software Catalog: Alle Services, APIs, Libraries und Teams an einem Ort
• Golden Paths: Templates für häufige Aufgaben (neuer Service, neue Pipeline)
• TechDocs: Dokumentation direkt neben dem Code
• Plugins: Integration mit AWS Service Catalog, CloudWatch, CodePipeline

AWS-Implementierungsperspektive: Schritt für Schritt

Der Aufbau einer IDP auf AWS folgt einem iterativen Ansatz. Die folgende Reihenfolge hat sich in der Praxis bewährt:

1. Foundation Layer (Woche 1–4): Multi-Account-Struktur mit AWS Organizations, Landing Zone via AWS Control Tower, zentrale CDK-Constructs-Library für VPC, IAM, Logging
2. Self-Service Layer (Woche 5–8): Service-Catalog-Produkte für die häufigsten Infrastruktur-Patterns (ECS-Service, Lambda-Function, RDS-Datenbank), CDK Pipelines für automatisiertes Deployment der Templates
3. Developer Portal (Woche 9–12): Backstage-Instanz auf EKS/ECS, Integration mit Service Catalog, Software Catalog mit bestehenden Services befüllen, Golden-Path-Templates für die Top-3-Anwendungsfälle
4. Observability & Feedback (kontinuierlich): CloudWatch Dashboards pro Team, Deployment-Metriken (Lead Time, Frequency), Developer-Satisfaction-Surveys als Input für Iteration

Zentrale AWS-Dokumentation für den Einstieg: Building an Internal Developer Platform on AWS (AWS Prescriptive Guidance).

Enterprise-Adoptionsmuster: Platform as Product

Gartner betont den Shift von zentralisierter Ausführung zu plattformgeführtem Enablement (Gartner, 2025). Statt als Execution-Layer für andere Teams zu agieren, bauen Plattform-Teams Shared Capabilities, die Produkt-Teams direkt konsumieren.

Erfolgreiche Enterprise-Adoption folgt einem klaren Muster:

• Product Ownership: Ein dedizierter Product Owner verantwortet Roadmap, Priorisierung und Stakeholder-Kommunikation
• Developer as Customer: Regelmäßige User Research, Feedback-Loops und NPS-Messungen
• MVP-First: Ein Problem lösen, dann iterieren. Nicht Feature-Completeness anstreben
• Internal Marketing: Die Plattform aktiv promoten, Onboarding-Sessions, Champions in Entwicklungsteams identifizieren
• Metriken: DORA-Metriken (Lead Time, Deployment Frequency, Change Failure Rate, MTTR) als Erfolgsindikatoren

CloudBees-Forschung zeigt: 83 % der befragten Organisationen haben Platform Engineering in irgendeiner Form adoptiert — 20 % vollständig, 44 % in Umsetzung, 19 % in Planung (CloudBees, 2025).

Storm Reply Perspektive: Platform Engineering Delivery

Storm Reply begleitet DACH-Unternehmen beim Aufbau von Internal Developer Platforms auf AWS — von der Strategie bis zum laufenden Betrieb. Als AWS Premier Consulting Partner mit DevOps- und Cloud-Operations-Kompetenz verbindet Storm Reply technische Exzellenz mit dem organisatorischen Verständnis, das für erfolgreiche Plattform-Initiativen entscheidend ist.

Der Storm-Reply-Ansatz für Platform Engineering:

• Assessment: Bestandsaufnahme der aktuellen Developer Experience, Pain Points und Infrastruktur-Patterns
• Blueprint: Architektur-Design der IDP auf Basis der konkreten Anforderungen — nicht „one size fits all"
• MVP-Delivery: Erste funktionsfähige Plattform in 8–12 Wochen, fokussiert auf den größten Hebel
• Enablement: Wissenstransfer, damit interne Teams die Plattform eigenständig weiterentwickeln

Besonderer Sweetspot: Storm Reply hat umfangreiche Erfahrung mit CDK-basierten Infrastruktur-Abstraktionen, Service-Catalog-Implementierungen und Backstage-Deployments auf EKS — die drei Kernbausteine einer AWS-nativen IDP.

Praxisanwendungsfälle im DACH-Kontext

Platform Engineering löst in DACH-Unternehmen konkrete Herausforderungen:

Automotive: Account-Vending mit Self-Service

In der Automobilindustrie ist die sichere, automatisierte Bereitstellung von AWS-Accounts ein zentraler Use Case. Storm Reply implementierte für Audi ein automatisiertes, serverloses Account-Provisioning-System, das konzernweite Sicherheitsstandards durchsetzt und gleichzeitig Self-Service ermöglicht — mit über 285 erfolgreich implementierten Projekten und 4.000+ aktiven Nutzern.

Healthcare: Compliance-konforme Entwicklungsumgebungen

Für regulierte Branchen wie Pharma ist die Kombination aus Self-Service und Compliance entscheidend. Storm Reply unterstützte Exom Group bei der Migration der Genius Suite™ zu Amazon EKS — mit hochverfügbarer Infrastruktur, Zero-Downtime Security-Patching und verschlüsselten Backups. Ein Platform-Engineering-Ansatz hätte hier die Standardisierung der EKS-Konfigurationen über alle Umgebungen hinweg ermöglicht.

IoT/Manufacturing: Standardisierte Deployment-Patterns

In IoT-Szenarien mit vielen ähnlichen Workloads profitieren Unternehmen von Golden Paths. Die modulare IIoT-Plattform CONiQ Cloud, die Storm Reply mit Schenck Process realisierte, zeigt das Muster: standardisierte, serverlose Module, die über einen Self-Service-Katalog bereitgestellt werden.

Regulatorische Aspekte (EU/DACH)

Platform Engineering hat direkte Implikationen für Compliance in regulierten Umgebungen:

• DSGVO: Eine IDP kann Data-Classification-Policies direkt in Infrastruktur-Templates einbetten. Service-Catalog-Produkte stellen sicher, dass personenbezogene Daten automatisch in der EU-Region verbleiben.
• BSI C5: Für Container-Workloads auf EKS/ECS können Platform-Teams BSI-C5-konforme Baseline-Konfigurationen als Golden Paths bereitstellen — Verschlüsselung, Logging und Access Control sind standardmäßig aktiv.
• NIS2: Die NIS2-Richtlinie fordert dokumentierte Incident-Response-Prozesse. Eine IDP mit integrierter Observability (CloudWatch, X-Ray) und definierten Runbooks erfüllt diese Anforderungen systematisch.
• EU Cyber Resilience Act: Software-Supply-Chain-Sicherheit wird Pflicht. CDK-Constructs können SBOM-Generierung und Vulnerability-Scanning als festen Bestandteil der Build-Pipeline einbetten.

Vorteile und Herausforderungen

Vorteile

• Developer Velocity: Self-Service-Environments in Minuten statt Tagen — Entwickler warten nicht auf Infrastruktur
• Konsistenz: Alle Teams nutzen dieselben, geprüften Infrastruktur-Patterns
• Compliance by Default: Sicherheits- und Compliance-Regeln sind in die Plattform eingebettet, nicht nachträglich aufgesetzt
• Skalierbarkeit: Neue Teams werden in Stunden statt Wochen produktiv
• Reduced Cognitive Load: Entwickler konzentrieren sich auf Business-Logik, nicht auf Infrastruktur-Komplexität

Herausforderungen und Limitierungen

• Initiale Investition: Ein dediziertes Platform-Team (3–5 Engineers) ist notwendig — die Plattform baut sich nicht „nebenbei"
• Organisatorischer Wandel: Platform Engineering verändert Verantwortlichkeiten. Change Management ist entscheidend
• Maintenance-Last: Eine IDP muss kontinuierlich gepflegt werden — neue AWS-Services, Security-Patches, Upgrades
• Adoption-Risiko: Ohne Developer-Buy-in wird die Plattform zur Shelf-Ware. Frühes Feedback ist nicht optional
• Abstraktions-Tradeoff: Zu viel Abstraktion nimmt Entwicklern Kontrolle, zu wenig Abstraktion bringt keinen Mehrwert. Die Balance ist kritisch

Ausblick: Platform Engineering 2026 und darüber hinaus

Platform Engineering entwickelt sich in mehrere Richtungen weiter:

• AI-native Platforms: Gartner prognostiziert, dass bis 2030 AI-native Entwicklungsplattformen dazu führen, dass 80 % der Organisationen große Software-Teams in kleinere, KI-unterstützte Teams umwandeln (Gartner, 2025). IDPs werden AI-Agents als First-Class-Citizens integrieren.
• FinOps-Integration: Plattformen werden Pre-Deployment-Cost-Gates implementieren, die Services blockieren, die wirtschaftliche Schwellenwerte überschreiten (platformengineering.org, 2025).
• Democratisierung: Platform Engineering ist nicht mehr nur für Tech-Giganten. Auch mittelständische Unternehmen in DACH können mit dem richtigen Partner einen tragfähigen MVP in wenigen Wochen aufbauen.

Häufige Fragen (FAQ)

Was ist eine Internal Developer Platform (IDP)?

Eine Internal Developer Platform ist ein internes Produkt, das Entwicklern Self-Service-Zugang zu Infrastruktur, Deployments und Konfigurationen bietet. Sie abstrahiert Komplexität und ermöglicht es Teams, eigenständig Umgebungen bereitzustellen — ohne Tickets an Plattform-Teams.

Warum scheitern viele IDPs?

Rund 70 % der Initiativen kämpfen mit Adoption. Hauptgründe: fehlender Produkt-Mindset, Over-Engineering statt MVP, kein Developer-Buy-in, mangelnde Wartung und falsche Metriken (Feature-Anzahl statt Developer Experience).

Welche AWS-Services bilden den Kern einer IDP?

AWS CDK für Infrastruktur-Abstraktion, AWS Service Catalog für Self-Service-Kataloge, Backstage auf Amazon EKS als Developer Portal, AWS CodePipeline für CI/CD und Amazon CloudWatch für Observability.

Wie lange dauert der Aufbau einer IDP auf AWS?

Ein MVP lässt sich in 8–12 Wochen aufbauen — fokussiert auf ein konkretes Problem. Der vollständige Ausbau zur unternehmensweiten Plattform ist ein kontinuierlicher Prozess über 6–18 Monate.