Eigene Infrastruktur statt Cloud: wann es sich lohnt

Eigene Infrastruktur statt Cloud: die Entscheidung dreht sich an vier Stellschrauben

Wenn heute jemand ein Softwareprodukt baut, landet es fast automatisch in der Cloud. Du klickst dir bei AWS, Hetzner oder Google einen Server zusammen, deployst, fertig. Diese Voreinstellung ist gut begründet, und meistens würde ich sie auch wählen. Trotzdem gibt es eine Handvoll Situationen, in denen eigene oder dedizierte Hardware nicht nur eine Option ist, sondern die klar bessere Entscheidung. Um zu erkennen, welcher Fall bei dir vorliegt, hilft es, vier Stellschrauben einzeln anzuschauen: was es kostet, wie viel Kontrolle du brauchst, wo deine Daten liegen müssen, und wie dein Lastprofil über den Tag aussieht. Erst wenn man diese vier auseinanderhält, hört die Diskussion auf, eine Glaubensfrage zu sein.

Vorweg eine Begriffsklärung, weil die Wörter oft durcheinandergehen. Cloud meint hier geteilte, virtualisierte Ressourcen, die du pro Stunde oder pro Anfrage mietest und in Minuten hoch- und runterskalierst. Eigene Infrastruktur ist das andere Ende: Hardware, die dir gehört oder die du langfristig dediziert mietest, in einem Rechenzentrum oder im eigenen Serverraum. Dazwischen liegt ein breites Feld, dedizierte Root-Server, Colocation, Bare-Metal auf Abruf. Die Entscheidung ist also kein Schalter, sondern ein Schieberegler.

Was die Cloud wirklich kostet: der Preis für Elastizität

Der entscheidende Punkt bei den Kosten ist nicht der Stundenpreis einer Instanz, sondern wofür du diesen Preis bezahlst. Du bezahlst für Elastizität. Eine Cloud-Maschine kann in dem Moment existieren, in dem du sie brauchst, und verschwinden, sobald die Last weg ist. Dieses Versprechen, jederzeit mehr oder weniger zu bekommen, ist die eigentliche Ware. Und es ist eine teure Ware, wenn du sie nicht nutzt.

Rechne es an deinem eigenen Auslastungsmuster durch. Ein Server, der rund um die Uhr läuft und konstant ausgelastet ist, zahlt den vollen Cloud-Aufschlag für eine Flexibilität, die er nie abruft. Genau dort kippt die Rechnung. Dedizierte Hardware mit vergleichbarer Leistung kostet pro Monat oft einen Bruchteil dessen, was die On-Demand-Cloud für dieselbe Dauerlast verlangt. Die Bandbreite ist gross, je nach Anbieter und Konfiguration liegt der Faktor schnell im Bereich von drei bis fünf, bei GPU-lastigen Workloads kann er noch deutlich höher ausfallen.

Die Cloud spielt ihre Kosten dagegen aus, wenn deine Last schwankt. Ein Shop, der vor Weihnachten das Zehnfache an Traffic sieht und im Februar fast schläft. Ein Batch-Job, der einmal pro Nacht für zwei Stunden viel Rechenleistung braucht. In solchen Mustern zahlst du nur für die Spitzen, die du wirklich nutzt, und sparst dir die Hardware, die elf Monate im Jahr Strom verbraucht und Wert verliert. Cloud verkauft Elastizität, eigene Hardware verkauft Auslastung. Wer eine konstant hohe Grundlast hat, kauft mit der Cloud etwas, das er gar nicht braucht.

Ein Posten, der gern übersehen wird, ist der ausgehende Datenverkehr. Cloud-Anbieter machen die Daten billig rein und teuer raus. Wer grosse Mengen ausliefert, Videos, Modelle, Backups, zahlt am Egress mehr, als die Rechenleistung selbst kostet. Bei dedizierter Hardware ist Traffic oft pauschal oder grosszügig inkludiert. Das gehört in jede Kostenrechnung, sonst vergleichst du nur die halbe Rechnung.

GPU-Last: das stärkste Argument für eigene Hardware

Wenn es einen Fall gibt, bei dem sich eigene Hardware fast aufdrängt, dann ist es dauerhafte GPU-Last. KI-Training und Inferenz auf eigenen Modellen brauchen Grafikkarten, und gute GPUs sind in der Cloud unter den teuersten Ressourcen überhaupt. Eine leistungsfähige GPU-Instanz pro Stunde gemietet, über Wochen durchlaufend, summiert sich zu Beträgen, für die du die Karte mehrfach hättest kaufen können.

Wir haben das selbst durchgespielt. Für unsere Arbeit mit lokaler KI-Last hat sich eine dedizierte GPU-Maschine gerechnet, weil die Auslastung hoch und planbar war. Sobald du eine GPU nicht stundenweise für ein Experiment brauchst, sondern als dauerhaft laufende Komponente, dreht sich die Logik. Die Karte amortisiert sich über die Monate, in denen sie ohnehin gerechnet hätte, und du bezahlst keinen Aufschlag mehr für eine Verfügbarkeit, die du dauernd in Anspruch nimmst.

Der Haken: Kaufst du die GPU, trägst du auch das Risiko. Geht die Karte kaputt, ist sie kaputt. Veraltet die Generation, sitzt du auf alter Hardware, während in der Cloud längst die nächste verfügbar ist. Diese Abwägung, Einsparung gegen Bindung an eine Hardware-Generation, ist bei GPUs schärfer als irgendwo sonst, weil sich die Karten schnell weiterentwickeln. Für eine stabile Inferenz-Last über ein bis zwei Jahre geht die Rechnung trotzdem fast immer zugunsten eigener Hardware auf.

Kontrolle und Datenstandort: wenn der Mietserver nicht reicht

Kosten sind die eine Seite. Die andere ist, was du bei einem Mietserver gar nicht erst entscheiden kannst. In der geteilten Cloud teilst du dir die physische Maschine mit anderen, du hast keinen Zugriff auf die Hardware-Ebene, und du bist an die Regionen und Garantien des Anbieters gebunden. Für die meisten Produkte ist das kein Problem. Für manche ist es ein Ausschlusskriterium.

Das häufigste handfeste Thema ist der Datenstandort. Wenn du Gesundheitsdaten, Personaldaten oder andere besonders schützenswerte Informationen verarbeitest, willst du oder musst du oft garantieren, dass diese Daten die Schweiz oder zumindest die EU nicht verlassen. Mit einem grossen US-Anbieter wird das schnell knifflig, selbst wenn die Region formal in Europa liegt, weil die rechtliche Zugriffslage am Mutterkonzern hängt. Eine dedizierte Maschine in einem Schweizer Rechenzentrum macht diese Frage einfach: Du weisst, wo die Bits physisch liegen, und kannst es nachweisen. Das ist weniger eine Kostenfrage als eine der Beweisbarkeit gegenüber Kunden und Aufsicht.

Kontrolle hat noch eine zweite Dimension, den Lock-in. Je tiefer du dich in die proprietären Dienste eines Anbieters einbaust, seine Datenbanken, seine Queue, seine Funktionsplattform, desto schwerer kommst du wieder raus. Das ist kein Argument gegen die Cloud an sich, aber ein Grund, die Architektur portabel zu halten. Wie man sich diese Tür offenhält, ohne auf Komfort zu verzichten, behandeln wir ausführlicher unter Vendor-Lock-in vermeiden. Eigene Infrastruktur löst das Lock-in-Problem nebenbei mit, weil portabler Standard-Stack auf gemieteter Hardware kaum etwas hat, woran du kleben bleibst.

Wann die Cloud klar gewinnt, und das ist der Normalfall

Jetzt die andere Richtung, denn sie betrifft die grosse Mehrheit. Für die meisten Produkte, besonders am Anfang, ist die Cloud nicht nur die bequeme, sondern die richtige Wahl. Drei Gründe wiegen schwer.

Erstens kennst du dein Lastprofil noch gar nicht. Ein frisches Produkt hat unbekannten Traffic. Du weisst nicht, ob du zehn oder zehntausend Nutzer bekommst, und du willst diese Wette nicht mit gekaufter Hardware eingehen. Die Cloud lässt dich klein anfangen und mitwachsen, ohne im Voraus zu investieren. Wann der Punkt kommt, an dem Skalierung überhaupt zum Thema wird, schauen wir uns unter wann SaaS skalieren genauer an.

Zweitens bekommst du in der Cloud Betriebsleistung geschenkt, die du sonst selbst aufbauen müsstest. Managed-Datenbanken mit automatischen Backups, Lastverteiler, Ausfallsicherheit über mehrere Standorte. Das alles auf eigener Hardware sauber hinzubekommen, ist Arbeit, und Arbeit kostet Zeit, die du am Anfang besser ins Produkt steckst.

Drittens, und das ist der unterschätzte Punkt: Eigene Hardware muss jemand betreiben. Eine Maschine im Rechenzentrum kümmert sich nicht selbst um Sicherheitsupdates, Überwachung, Wiederanlauf nach einem Ausfall. Das ist kein Nebenher, das ist eine eigene Disziplin. Wer den Betrieb unterschätzt, spart bei der Miete und zahlt bei den Nächten drauf, in denen etwas um drei Uhr ausfällt und niemand da ist, der die Maschine kennt. Was so ein Minimum an verlässlichem Betrieb umfasst, von Monitoring bis Backups, steht unter Monitoring, Backups, Alerting als Minimum.

Deshalb lautet meine Standardempfehlung: Starte in der Cloud. Wechsle erst, wenn du ein konkretes, gemessenes Lastprofil hast, das den Wechsel rechtfertigt, eine konstant hohe Grundlast, teure Dauer-GPUs oder eine harte Datenstandort-Anforderung. Bis dahin ist eigene Hardware vorzeitige Optimierung.

Der Mittelweg, den die meisten übersehen

Die Debatte wird oft als Entweder-oder geführt, dabei liegt die beste Antwort häufig dazwischen. Du kannst die berechenbare Grundlast auf eine günstige dedizierte Maschine legen und die Cloud nur für Spitzen und für die Dienste behalten, bei denen ihr Komfort den Aufpreis wert ist. Genau diese gemischte Aufteilung, was selbst betreiben, was managed beziehen, ist meist die wirtschaftlichste, und wir gehen sie unter Hosting selbst vs. managed im Detail durch.

Entscheidend ist, dass jemand diese Abwägung mit echten Zahlen macht und nicht mit Bauchgefühl. Genau hier hilft, dass wir bei Wertstifter eigene Produkte wie Wortfreunde und Reazon nicht nur bauen, sondern auch betreiben. Wir spüren die Cloud-Rechnung jeden Monat selbst und wissen, wo der Aufpreis sich lohnt und wo er Geld verbrennt. Diese Betriebserfahrung steckt in unserem Produkt-Betrieb, und sie ist der Grund, warum wir die Infrastruktur-Frage nüchtern beantworten und nicht nach dem teuersten Weg.

Die kurze Faustregel zum Mitnehmen: Schwankt deine Last, gewinnt die Cloud. Ist sie konstant hoch oder steckt sie in dauerhafter GPU-Rechnung, lohnt sich eigene Hardware. Und sobald Datenstandort oder Nachweisbarkeit ins Spiel kommen, entscheidet nicht der Preis, sondern die Anforderung. Wer diese drei Fragen für sich beantwortet, braucht keine Glaubensdiskussion mehr.