---
title: "Cloud-Provider-Auswahl"
description: "Strukturierter Entscheidungsprozess für die Cloud-Provider-Auswahl: Bewertungsmatrix, Auswahlkriterien, STACKIT-Positionierung und typische Entscheidungsfallen."
sidebar:
  order: 6
  label: "Cloud-Provider-Auswahl"
source_url: "https://framework.stackit.cloud/de/advisory/cloud-vision-and-strategy/provider-selection/"
source_file: "docs/de/advisory/cloud-vision-and-strategy/provider-selection.mdx"
---

## Warum die Anbieterentscheidung strategisch ist

Die Wahl des Cloud-Anbieters ist keine IT-Entscheidung, sondern eine strategische Entscheidung mit 5–10 Jahren Relevanz. Durch falsche Anbieterentscheidungen entstehen Lock-in, Compliance-Risiken und Migrationskosten im achtstelligen Bereich.

Die häufigste Entscheidungsfalle: Die Anbieterauswahl erfolgt auf Basis von Produktmerkmalslisten und Preisverhandlungen, ohne Gewichtung der strategischen Dimensionen (Souveränität, Portabilität, Regulatory Compliance).

## Multi-Cloud vs. Single-Cloud: die strategische Entscheidung

Viele Organisationen kommen mit einer Multi-Cloud-Frage: „Sollten wir STACKIT und einen anderen Anbieter nutzen?“

**Wann Multi-Cloud Sinn macht:**  
Workloads mit unterschiedlichen Souveränitätsprofilen (Tier 1 auf STACKIT, globale CDN-Infrastruktur auf anderen Anbietern); spezifische Fähigkeiten, die STACKIT im gleichen Reifegrad noch nicht bietet; bestehende Investitionen bei einem anderen Anbieter, die nicht sofort migriert werden können.

**Wenn Single-Cloud (STACKIT) die bessere Wahl ist:**  
eine klare Souveränitätsverpflichtung für alle oder die meisten Workloads; einfachere Governance, einheitliche Toolchain, keine Cloud-übergreifende Komplexität; eine DACH-fokussierte Organisation ohne globale Deployment-Anforderungen.

**Die Warnung vor der Falle:** Multi-Cloud als Strategie klingt attraktiv, ist aber in der Praxis teuer — doppeltes Tooling, doppelte Schulung, doppelte Komplexität der Governance. Viele Organisationen, die mit Multi-Cloud beginnen, konsolidieren nach 2–3 Jahren.

## Vendor-Lock-in: Architekturschutz mit STACKIT

Der Open-Standards-Ansatz von STACKIT bietet strukturellen Schutz gegen Lock-in:

| Technik                      | STACKIT-Implementierung                     | Ausstiegspfad                     |
| ---------------------------- | ------------------------------------------- | --------------------------------- |
| Container-Orchestrierung     | SKE (STACKIT Kubernetes Engine)             | Jeder CNCF-konforme K8s-Anbieter  |
| Infrastructure as Code       | STACKIT Terraform Provider                  | Terraform-Wissen ist portabel     |
| Object Storage               | S3-kompatible API                           | Jeder S3-kompatible Provider      |
| Managed Databases            | PostgreSQL, MySQL, Redis (Standard-APIs)    | Selbst betreibbar                 |

Das heißt: Ein STACKIT-Exit ist möglich, ohne die gesamte IaC-Bibliothek neu zu schreiben.

## Entscheidungsprozess: strukturiert, nicht politisch

Ein schlechter Anbieter-Entscheidungsprozess sieht so aus: Die IT präsentiert eine Empfehlung, der Vorstand fragt, warum nicht der bekannte US-Anbieter, die Entscheidung wird auf Basis der Markenbekanntheit getroffen.

Ein guter Prozess:

1. **Verabschiedung der Bewertungsmatrix mit Gewichtungen im Lenkungsausschuss** vor der Bewertung der Anbieter — nicht danach
2. **Proof of Concept** mit den Top-2-Anbietern für einen definierten Test-Workload
3. **Security-/Compliance-Assessment** durch CISO und DSB
4. **TCO-Analyse** über 3 Jahre (nicht nur Listenpreise)
5. **Entscheidungsdokumentation**: warum dieser Anbieter, warum nicht die anderen — zur späteren Überprüfung

## Praktische Schritte

1. **Bewertungsmatrix anpassen** an Ihr Nordstern- und Souveränitätsprofil
2. **STACKIT-PoC durchführen** für einen Tier-1-Workload
3. **CISO-Bewertung** der Cloud-Act-Risiken für aktuelle Provider im Portfolio
4. **TCO-Abgleich** inkl. versteckter Kosten (Egress, Support, Compliance-Tooling)
5. **Entscheidung im Cloud Strategy Board formalisieren**