Es gibt zwei Wege, jemand anderen Ihre Infrastruktur betreiben zu lassen. Beim ersten kaufen Sie Cloud von ihm: Er hält die Provider-Konten, er bekommt die Rechnung, Sie bekommen eine aufgeschlagene Rechnung und eine Support-Adresse. Beim zweiten - Bring Your Own Cloud, meist als BYOC abgekürzt - behalten Sie Ihre eigenen Konten bei Hetzner, AWS oder OVHcloud, Ihren eigenen Vertrag, Ihre eigene Rechnung, und gewähren einer Management-Plattform begrenzte Credentials, um sie in Ihrem Auftrag zu betreiben. Die beiden Modelle sehen sich in einer Demo ähnlich und verhalten sich an dem Tag, an dem Sie aussteigen wollen, überhaupt nicht gleich.

Das Reseller-Modell ist kein Betrug; es ist ein legitimes Geschäft mit echten Vorteilen, vor allem einer einzigen Rechnung und einer einzigen Stelle für Beschwerden. Was Sie aufgeben, ist weniger sichtbar. Ihre vertragliche Beziehung besteht mit dem Reseller, nicht mit dem Provider, also ist das SLA, das Sie tatsächlich durchsetzen können, dessen SLA. Committed-Use-Rabatte, Startup-Credits und verhandelte Preise laufen alle über ihn. Und die Ressourcen-Identität, das Konto, in dem die Server tatsächlich leben, gehört jemand anderem - was bedeutet, dass Gehen eine Migration ist, keine Kündigung.

Was Sie behalten, wenn Sie den Vertrag behalten

Unter BYOC bleibt die Provider-Beziehung dort, wo ein Anwalt sie erwarten würde. Die Instanzen liegen in Ihrem Konto. Die Support-Tickets eröffnen Sie selbst. Die Rechnung kommt in dem Format, das Ihr Finance-Team bereits abgleicht, von einem Unternehmen, bei dem Sie bereits eine Due-Diligence-Prüfung durchgeführt haben, unter einer Jurisdiktion, über die Sie bereits nachgedacht haben. Wenn Ihre Compliance-Haltung davon abhängt, wer einen Dienst rechtlich betreibt - was nach Schrems II die interessante Frage ist, nicht wo die Server physisch stehen -, haben Sie durch die Einführung einer Control Plane kein zusätzliches Glied in diese Kette eingefügt.

Der Exit-Test macht den Unterschied konkret. Was passiert, wenn die Management-Plattform über Nacht verschwindet? Unter Resale liegen Ihre Server in einem Konto, das Sie nicht kontrollieren, und die Antwort involviert Anwälte. Unter BYOC laufen die Server genau so weiter, wie sie sind; Sie haben eine Konsole, ein Inventar und etwas Automatisierung verloren, was ärgerlich ist, aber nicht existenzbedrohend. Diese Asymmetrie ist mehr wert als jede Feature-Liste, und sie ist das Erste, was Sie prüfen sollten, bevor Sie irgendetwas unterschreiben.

Was BYOC von der Plattform verlangt

Der Preis dieses Modells ist, dass die Plattform nun echte Produktions-Credentials für Konten hält, die ihr nicht gehören. Diese Verpflichtung muss wörtlich genommen werden. Credentials sind at rest mit AES-256-GCM verschlüsselt, auf eine einzelne Organisation begrenzt, niemals über Tenants hinweg geteilt, und werden niemals in einer API-Antwort zurückgegeben - die Felder sind auf dem Weg hinaus genauso privat wie auf dem Weg hinein verschlüsselt. Jede dieser Anforderungen ist langweilig, bis sie in dem Moment interessant wird, in dem ein gewöhnlicher List-Endpoint gebeten wird, einen Credential-Datensatz zu serialisieren.

Dann gibt es den Fehlermodus, den niemand einplant. Ein Provisioning-Job kommt ohne angehängtes Credential an: ein Bug, ein Race, eine Nachricht von einer älteren Version eines Services. Das verlockende Verhalten ist, auf das eigene Provider-Token der Plattform zurückzufallen, damit der Job durchläuft. Wir haben dieses Verhalten einmal ausgeliefert, und es tat genau das, was es immer tun würde - erstellte eine echte Maschine im eigenen Konto der Plattform, abgerechnet an die falsche Partei, unsichtbar im Inventar des Kunden. Der Default ist jetzt fail-closed. Ein Job ohne Credential wird abgelehnt, und das Fallback zu aktivieren erfordert ein explizites Environment-Flag.

Wo Multi-Provider-BYOC schwierig wird

Ein Provider ist eine Integration; elf sind ein Taxonomie-Problem. Sencai steuert aktuell Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamais Linode und Oracle Cloud, plus On-Premise- und Bare-Metal-Server über einen Host-Agent. Jeder davon hat sein eigenes Authentifizierungsmodell, sein eigenes Quota-System, sein eigenes Vokabular und seine eigene Meinung dazu, ob eine Firewall zu einer Maschine, einem Netzwerk oder einem Projekt gehört. Das zu normalisieren, ohne dabei zu lügen, ist der größte Teil des Engineerings.

Die Linie, die wir zu halten versuchen, ist, dass die Control Plane den Provider selbst bedient, nicht eine Kopie davon. Wenn Sie in Sencai ein Netzwerk, eine Firewall-Regel oder eine DNS-Zone erstellen, geht der Aufruf an die API des Providers, und das Objekt existiert dort - sichtbar in dessen Konsole, löschbar mit dessen CLI, real für jeden, der noch nie von uns gehört hat. Eine Plattform, die Absicht nur in ihrer eigenen Datenbank festhält, erzeugt ein sehr überzeugendes Inventar von Dingen, die vielleicht gar nicht existieren.

Billing folgt derselben Logik. Weil die Rechnung beim Provider bleibt, ist es nicht die Aufgabe der Plattform, Sie zu berechnen. Ihre Aufgabe ist Attribution und Kontrolle. Spend wird pro Organisation und Projekt über jedes verbundene Konto hinweg erfasst, mit von Ihnen gesetzten Caps, sodass die Frage „was hat die Batch-Pipeline letzten Monat gekostet“ eine einzige Antwort hat statt vier Exporte in vier Formaten. Das ist auch der Teil, den BYOC gegenüber Resale wirklich schwieriger macht, denn es gibt kein einzelnes Ledger zum Auslesen - die Zahlen müssen pro Provider abgerufen und abgeglichen werden.

Für wen Bring Your Own Cloud gedacht ist

BYOC passt zu Teams mit einer bereits bestehenden Umgebung und bereits realen Rahmenbedingungen: ein paar hundert über drei Jahre angesammelte Maschinen, eine Jurisdiktionsanforderung vom Einkaufsteam eines Kunden, ein Provider-Mix, der einfach entstanden ist, statt geplant zu sein. Es passt schlechter, wenn Sie bei null anfangen, genau eine Rechnung wollen und keine Meinung dazu haben, wo irgendetwas läuft. Ein Reseller oder ein einzelner Hyperscaler wird einfacher sein, und Sie sollten die einfachere Sache nehmen. Niemand braucht eine Multi-Cloud-Control-Plane für ein Konto und elf Server.

Zwei Dinge werden unter BYOC schärfer und verdienen bewusstes Design statt guter Absichten. Das erste ist Isolation: Credentials gehören zu einer Organisation, Mitgliedschaft entsteht durch Einladung, und Rollen entscheiden, wer Geld ausgeben oder eine Firewall anfassen darf - denn der Blast-Radius hier ist ein echtes Produktionskonto, keine Sandbox. Das zweite ist der Audit-Trail. Jede Aktion, die die Plattform in Ihrem Auftrag ausführt, sollte append-only aufgezeichnet werden, mit dem Actor, der Ressource und einer Correlation-ID, in einer exportierbaren Form. Sie delegieren den Betrieb, also ist die Aufzeichnung dieses Betriebs das, was Sie haben, statt ihn selbst durchgeführt zu haben.

Also, die Fragen, die es sich lohnt, jedem zu stellen, der Ihnen Bring Your Own Cloud verkauft. Wessen Name steht auf dem Providervertrag? Was genau kann das Credential, das Sie übergeben haben, und können Sie es weiter einschränken? Was passiert mit der laufenden Infrastruktur, wenn Sie morgen aufhören, sie zu bezahlen? Können Sie das Log von allem exportieren, was sie innerhalb Ihrer Konten getan haben, und es unabhängig prüfen? Gute Antworten auf diese vier Fragen sind das, was das Auslagern Ihres Betriebs vom Auslagern Ihrer Infrastruktur unterscheidet - und nur eines von beiden lässt sich an einem Dienstag rückgängig machen.