Cloud-Support antwortet nicht: Wann Sie einen echten Kubernetes-Partner brauchen

TL;DR

• Cloud-Provider-Support (AWS, Azure, GCP) endet an der Kubernetes-Grenze: Der Hyperscaler supportet seine Managed Control Plane, aber nicht Ihre Workloads, Helm Charts, Ingress-Konfiguration oder Monitoring-Probleme.
• Reaktionszeiten im Business-Support-Tier liegen bei 1-4 Stunden. Der erste Kontakt ist ein Ticket-System, nicht ein Mensch, der Ihren Cluster kennt.
• Der Support-Agent kennt Ihre Infrastruktur nicht: Jedes Ticket beginnt bei Null mit Informationssammlung, auch wenn der Cluster brennt.
• Ein spezialisierter Kubernetes-Partner kennt Ihren Cluster, hat Kontext und reagiert in 15-30 Minuten -- mit Loesungen statt mit Rueckfragen.
• Die Kombination aus Cloud-Provider fuer Infrastruktur und K8s-Partner fuer Betrieb liefert die beste Abdeckung.

Das Szenario: Freitagabend, 21 Uhr, Production ist down

Ihr E-Commerce-System laeuft auf einem EKS-Cluster bei AWS. Freitagabend, kurz vor dem Wochenende, fallen mehrere Pods in CrashLoopBackoff. Die Ingress-Route liefert 502-Fehler. Kunden sehen eine Fehlerseite, der Umsatz laeuft gegen Null.

Ihr Admin oeffnet ein Support-Ticket bei AWS mit Severity "Business Critical". Was passiert?

Timeline eines AWS-Support-Tickets (Business-Tier, realistisch):

21:00  Ticket eroeffnet: "EKS Pods CrashLoopBackoff, 502 auf Ingress"
21:08  Automatische Bestaetigungs-Mail: "Wir haben Ihr Ticket erhalten"
21:35  Erster Agent antwortet: "Koennen Sie bitte die Pod-Logs teilen?"
21:42  Sie senden kubectl-Logs
22:10  Agent: "Koennen Sie kubectl describe pod ausfuehren?"
22:15  Sie senden die Ausgabe
22:45  Agent: "Das scheint ein Application-Level-Problem zu sein.
        EKS Control Plane ist healthy. Wir koennen bei
        Application-Workloads leider nicht helfen."
23:00  Sie sind auf sich allein gestellt.

Vergangene Zeit: 2 Stunden
Ergebnis: Kein Ergebnis. Problem liegt ausserhalb des Support-Scope.
Geschaetzter Umsatzverlust: 4.000 - 20.000 EUR

Das ist kein Worst Case. Das ist der normale Ablauf. Und es liegt nicht daran, dass AWS schlechten Support liefert -- es liegt daran, dass der Cloud-Provider fuer etwas anderes verantwortlich ist als das, was Ihnen gerade Probleme macht.

Was Cloud-Provider-Support abdeckt -- und was nicht

Die Verantwortungsgrenze ist klar definiert, aber den meisten Kunden nicht bewusst:

Die Faustregel: Der Cloud-Provider supportet seine Infrastruktur bis zur Kubernetes-API. Alles, was Sie auf Kubernetes deployen -- also der gesamte Stack, der Ihr Geschaeft am Laufen haelt -- ist ausserhalb seines Scopes.

Support-Tiers der Hyperscaler: Was Sie wirklich bekommen

AWS Support

AWS Support Tiers fuer EKS:

Basic (kostenlos):
├── Zugang zu Dokumentation und Foren
├── Service Health Dashboard
└── Kein technischer Support
    Reaktionszeit: keine

Developer (29 USD/Monat):
├── E-Mail-Support waehrend Buerozeiten
├── 1 Kontaktperson
└── Allgemeine Architekturberatung
    Reaktionszeit: 12-24 Stunden

Business (min. 100 USD/Monat oder 10% der Rechnung):
├── 24/7-Support per Telefon und Chat
├── Unbegrenzte Kontaktpersonen
├── Infrastructure Event Management
└── Trusted Advisor
    Reaktionszeit: 1 Stunde (Production down)

Enterprise (min. 15.000 USD/Monat):
├── Alles aus Business
├── Technical Account Manager (TAM)
├── Concierge Support Team
├── Infrastructure Event Management
└── Well-Architected Reviews
    Reaktionszeit: 15 Minuten (Business critical)

Die meisten Mittelstaendler haben Business-Support. Das bedeutet: 1 Stunde Reaktionszeit bei Production-Ausfall. Aber "Reaktionszeit" heisst: Jemand bestaetigt Ihr Ticket. Nicht: Jemand hat Ihr Problem geloest.

Azure Support

Azure Support Tiers:

Basic (kostenlos):
├── Billing-Support
├── Dokumentation
└── Kein technischer Support

Developer (29 USD/Monat):
├── E-Mail-Support waehrend Buerozeiten
└── Reaktionszeit: 8 Stunden (Severity B)

Standard (100 USD/Monat):
├── 24/7-Support per Telefon und E-Mail
└── Reaktionszeit: 1 Stunde (Severity A)

Professional Direct (1.000 USD/Monat):
├── Alles aus Standard
├── Technische Beratung
├── Webinare
└── Reaktionszeit: 1 Stunde (Severity A) + Eskalationsmanagement

Premier (individuell):
├── Designated Support Engineer
├── On-Site-Support moeglich
└── Reaktionszeit: 15 Minuten (Critical)

Die 5 Pain Points mit Hyperscaler-Support

Pain Point 1: Kein Kontext ueber Ihre Infrastruktur

Jedes Mal, wenn Sie ein Ticket oeffnen, muessen Sie Ihre gesamte Cluster-Architektur erklaeren. Der Support-Agent sieht nicht Ihren Cluster. Er kennt nicht Ihre Deployment-Strategie, Ihre Network Policies oder Ihre Monitoring-Konfiguration.

Typischer Informationsfluss bei einem Cloud-Support-Ticket:

Ticket 1 (Sie):     "Pods CrashLoopBackoff auf EKS"
Antwort 1 (Agent):  "Welche EKS-Version? Node-Typ? Region?"
Ticket 2 (Sie):     "EKS 1.31, m5.xlarge, eu-central-1"
Antwort 2 (Agent):  "Koennen Sie kubectl describe pod senden?"
Ticket 3 (Sie):     [20 Zeilen YAML-Output]
Antwort 3 (Agent):  "Sehen Sie OOMKilled Events? Das ist kein EKS-Problem,
                      das ist eine Resource-Limit-Konfiguration Ihrer App."
Ticket 4 (Sie):     "Ja, aber warum passiert das ploetzlich?"
Antwort 4 (Agent):  "Application-Level-Debugging liegt ausserhalb
                      unseres Support-Scope."

Vergangene Zeit: 3-6 Stunden (je nach Ticketaufkommen)
Ergebnis: Verweis auf Application-Level

Ein Kubernetes-Partner, der Ihren Cluster kennt, haette in 15 Minuten gesehen: "Der Memory-Verbrauch ist nach dem letzten Deployment gestiegen. Das neue Release hat ein Memory Leak. Rollback auf die vorherige Version, dann Debugging am Montag."

Pain Point 2: Scope-Grenzen mitten im Incident

Der Cloud-Provider-Support arbeitet strikt innerhalb seines Verantwortungsbereichs. Das ist organisatorisch nachvollziehbar -- aber waehrend eines Incidents ist es verheerend.

In jedem dieser Faelle liegt das Problem in der Kubernetes-Schicht -- nicht in der Cloud-Infrastruktur. Der Cloud-Provider kann bestaetigen, dass seine Dienste funktionieren. Den eigentlichen Fehler finden muss jemand anderes.

Pain Point 3: Eskalation ist schwierig

Bei Enterprise-Support haben Sie einen Technical Account Manager (TAM). Bei Business-Support haben Sie ein Ticket-System. Wenn Sie eskalieren wollen, muessen Sie:

1. Das Ticket als "Severity 1" markieren
2. Begruenden, warum es Business-kritisch ist
3. Warten, bis ein Senior-Agent uebernimmt
4. Dem Senior-Agent nochmal alles erklaeren

Dieser Prozess dauert Stunden. Bei einem spezialisierten Kubernetes-Partner rufen Sie an und sprechen mit jemandem, der Ihren Cluster letzte Woche gewartet hat.

Pain Point 4: Sprachbarriere und Zeitzonen

AWS- und Azure-Support fuer den Business-Tier ist ueberwiegend auf Englisch. Das ist fuer die meisten IT-Teams handhabbar -- aber waehrend eines kritischen Incidents um 3 Uhr morgens moechten Sie Ihr Problem nicht in einer Fremdsprache erklaeren.

Ausserdem sitzt der Support-Agent moeglicherweise in einer anderen Zeitzone. Die Antwort auf Ihr Ticket kommt, wenn in deren Zeitzone jemand verfuegbar wird -- nicht unbedingt, wenn Sie die Antwort brauchen.

Pain Point 5: Keine proaktive Wartung

Cloud-Provider-Support ist reaktiv. Sie oeffnen ein Ticket, wenn etwas kaputt ist. Niemand schaut sich proaktiv Ihren Cluster an und sagt: "In zwei Wochen laufen Ihre Zertifikate ab" oder "Ihr etcd waechst ungewoehnlich schnell".

Ein Kubernetes-Partner mit Monitoring-Zugang sieht diese Probleme, bevor sie kritisch werden.

Welche naechtlichen Incidents dabei typischerweise auftreten, zeigt unser Production-Ausfall-Notfallplan.

Der Vergleich: Cloud-Provider-Support vs. Kubernetes-Partner

Die Kosten des Kubernetes-Partners sind hoeher. Aber der Vergleich ist unfair, weil der Cloud-Provider-Support und der Kubernetes-Partner unterschiedliche Dinge liefern. Der Cloud-Provider-Support ist keine Alternative zum Kubernetes-Partner -- er ist eine Ergaenzung.

Wann Cloud-Provider-Support ausreicht

Nicht jedes Unternehmen braucht einen dedizierten Kubernetes-Partner. Cloud-Provider-Support kann ausreichen, wenn:

• Sie nur die Managed Control Plane nutzen (EKS, AKS, GKE) und wenige einfache Workloads fahren
• Ihr internes Team 3+ erfahrene Kubernetes-Engineers hat
• Ihre SLA-Anforderungen bei maximal 99,5% liegen
• Sie keine 24/7-Verfuegbarkeit garantieren muessen
• Incidents waehrend der Geschaeftszeiten passieren (unrealistisch, aber moeglich bei internen Applikationen)

Fuer die meisten 300-1.000-MA-Unternehmen mit kundenrelevanten Workloads auf Kubernetes ist der Cloud-Provider-Support allein nicht ausreichend.

Wie sich Managed Services im Vergleich zu Inhouse-Betrieb rechnen, zeigt der Managed Service vs. Inhouse Vergleich.

Das optimale Setup: Cloud-Provider + K8s-Partner

Die beste Loesung ist nicht "entweder oder", sondern eine klare Aufgabenteilung:

# support-architektur.yaml
# Optimale Support-Struktur fuer Mittelstaendler
apiVersion: v1
kind: ConfigMap
metadata:
  name: support-setup
data:
  cloud-provider-support: |
    Tier: Business (AWS) / Standard (Azure)
    Zustaendig fuer:
      - Control Plane Health und Incidents
      - Node-Provisionierung und -Probleme
      - Cloud-Networking (VPC, Load Balancer, DNS)
      - Cloud-Storage (EBS, Azure Disk)
      - IAM und Cloud-Security
      - Billing und Kostenoptimierung
    Eskalation: Nur fuer Cloud-Infrastruktur-Probleme

  kubernetes-partner: |
    Tier: Managed Service mit SLA
    Zustaendig fuer:
      - Kubernetes-Stack (alles oberhalb der Control Plane)
      - Workload-Betrieb und Troubleshooting
      - Monitoring, Alerting, Log-Aggregation
      - Cluster-Upgrades und Maintenance Windows
      - Security Patching und Compliance
      - 24/7 On-Call und Incident Response
      - Proaktive Wartung und Optimierung
    Eskalation: Erster Ansprechpartner bei ALLEN K8s-Problemen

  eskalationsprozess: |
    Level 1: Kubernetes-Partner (Reaktion in 15 Min)
    Level 2: Cloud-Provider-Support (wenn Infrastruktur betroffen)
    Level 3: Gemeinsame Analyse (Partner + Cloud-Provider)

In der Praxis bedeutet das: Wenn etwas kaputtgeht, rufen Sie immer zuerst den Kubernetes-Partner an. Dieser entscheidet, ob ein Cloud-Provider-Ticket noetig ist -- und oeffnet es bei Bedarf in Ihrem Namen, mit den richtigen technischen Details und der richtigen Severity.

Worauf Sie bei der Partnerwahl achten sollten

Nicht jeder Kubernetes-Dienstleister ist ein guter Betriebspartner. Pruefen Sie diese Punkte:

Kubernetes-Partner Bewertungskriterien:

Technische Kompetenz:
├── [ ] Team hat CKA/CKS-Zertifizierungen
├── [ ] Erfahrung mit Ihrem Cloud-Provider (AWS/Azure/GCP)
├── [ ] Referenzen in vergleichbarer Groesse und Branche
├── [ ] Eigene Tooling-Kompetenz (Prometheus, ArgoCD, Velero)
└── [ ] Nachweisbare Incident-Response-Erfahrung

SLA und Verfuegbarkeit:
├── [ ] 24/7-Erreichbarkeit vertraglich garantiert
├── [ ] Reaktionszeiten definiert (15-30 Min fuer Critical)
├── [ ] MTTR-Ziele vereinbart
├── [ ] Eskalationsprozeduren dokumentiert
└── [ ] Vertragsstrafen bei SLA-Verletzung

Zusammenarbeit:
├── [ ] Deutschsprachiger Support
├── [ ] Dedizierter Ansprechpartner (nicht nur Ticket-System)
├── [ ] Regelmaessige Reviews (monatlich/vierteljaehrlich)
├── [ ] Wissenstransfer an Ihr Team inkludiert
└── [ ] Transparente Dokumentation aller Aenderungen

Sicherheit:
├── [ ] DSGVO-konforme Datenverarbeitung
├── [ ] Zugangskonzept mit Audit-Trail
├── [ ] Kein permanenter Admin-Zugriff (Just-in-Time)
└── [ ] NDA und Vertraulichkeitsvereinbarung

Die Unterschiede zwischen Freelancern und Managed-Service-Partnern erklaert der Freelancer vs. Managed Service Vergleich.

Kosten im Kontext: Was kostet ein Incident?

Die Support-Kosten muessen im Verhaeltnis zu den Kosten eines ungloesten Incidents betrachtet werden:

Kostenvergleich: Support-Optionen vs. Incident-Kosten

Cloud-Provider-Support (Business-Tier):
├── Monatliche Kosten:                    100 - 500 EUR
├── MTTR bei K8s-Workload-Problem:        4 - 12 Stunden
├── Kosten pro Incident (Downtime):       6.000 - 120.000 EUR
└── Jaehrlich (bei 4 Incidents):          24.000 - 480.000 EUR

Kubernetes-Partner (Managed Service):
├── Monatliche Kosten:                    3.000 - 6.000 EUR
├── MTTR bei K8s-Workload-Problem:        30 - 90 Minuten
├── Kosten pro Incident (Downtime):       750 - 9.000 EUR
└── Jaehrlich (bei 4 Incidents):          3.000 - 36.000 EUR

Break-Even-Rechnung:
├── Managed-Service-Mehrkosten/Jahr:      ~45.000 EUR
├── Eingesparte Downtime-Kosten/Jahr:     21.000 - 444.000 EUR
└── ROI: Ab dem 2. vermiedenen Incident positiv

Diese Rechnung beruecksichtigt nur die direkten Downtime-Kosten. Nicht eingerechnet: Reputationsschaden, verlorene Kundenvertraege und die psychische Belastung Ihres Teams.

Was ein naechtlicher Ausfall Ihr Unternehmen konkret kostet, rechnet der 24/7-Betriebsguide durch.

Checkliste: Brauchen Sie einen Kubernetes-Partner?

Beantworten Sie diese Fragen ehrlich:

Ab drei Mal "Partner notwendig" sollten Sie das Gespraech mit einem Kubernetes-Dienstleister fuehren.

Fazit

Cloud-Provider-Support ist gut -- fuer das, wofuer er gedacht ist: Cloud-Infrastruktur. Er ist nicht gedacht fuer den Betrieb Ihres Kubernetes-Stacks, das Debugging Ihrer Workloads oder die Reaktion auf Incidents, die ausserhalb der Cloud-Infrastruktur liegen.

Wenn Kubernetes fuer Ihr Geschaeft relevant ist -- und das ist es, wenn kundenrelevante Applikationen darauf laufen -- dann brauchen Sie einen Partner, der den gesamten Stack versteht. Nicht weil der Cloud-Provider schlecht ist, sondern weil seine Aufgabe eine andere ist.

Der Cloud-Provider liefert die Strasse. Der Kubernetes-Partner faehrt das Auto.

Sie wollen wissen, wo Ihre aktuelle Support-Abdeckung Luecken hat? In einem 30-minuetigen Gespraech analysieren wir Ihre Situation und zeigen, was ein dedizierter Kubernetes-Partner konkret liefern wuerde -- Termin vereinbaren.