Wählen Sie das Betriebsmodell für jede Anwendung anhand von Last, Datenwegen und Verantwortlichkeiten. Eine Firma kann für ihre Fertigung eigene Hardware und für ihr Kundenportal einen Cloud-Dienst sinnvoll kombinieren.

Für Teams, die vor einer Neuanschaffung, Hosting-Verlängerung oder Cloud-Migration stehen und eine Entscheidung ohne pauschale Anbieterempfehlung treffen möchten.

Vier Modelle, die Angebote sauber unterscheiden sollten

Server kaufen bedeutet zunächst Eigentum an einem Gerät. Dieses kann im eigenen Technikraum oder gegen Standortkosten in einem Rechenzentrum stehen. Strom, Ersatzteile und der gesamte Lebenszyklus bleiben zu organisieren. Ein Kauf kann bei langfristig gleichmäßiger Last sinnvoll sein, bindet aber Kapital und setzt eine realistische Vorstellung von Kapazität und Nutzungsdauer voraus.

Bei einem gemieteten dedizierten Server stellt ein Anbieter die physische Maschine bereit. Wie schnell defekte Teile ersetzt werden, welcher Support verfügbar ist und ob das Betriebssystem betreut wird, steht im Vertrag. Ein virtueller Server teilt dagegen eine physische Plattform mit anderen Systemen. Seine zugesicherte Leistung und die Grenzen des Pakets müssen zur Anwendung passen.

Cloud kann solche virtuellen Maschinen bezeichnen, umfasst aber auch betreute Datenbanken, Objektspeicher und anwendungsnahe Dienste. Der Unterschied liegt deshalb nicht allein in der monatlichen Zahlung. Es geht darum, welche technische Arbeit Sie selbst ausführen und welche ein Dienst tatsächlich übernimmt. Ein Marketingwort wie „Managed“ beantwortet diese Frage ohne konkrete Leistungsbeschreibung nicht.

Sechs Fragen vor dem ersten Preisvergleich

Wie sieht die Last aus? Gleichmäßige interne Nutzung, saisonale Spitzen oder zeitlich begrenzte Projekte verlangen unterschiedliche Reserven.
Wo entstehen große Datenmengen? Wenn täglich Videodaten im Büro verarbeitet werden, zählt der Weg zur Rechenleistung ebenso wie die Rechenleistung selbst.
Was muss bei einem Internetausfall weiterarbeiten? Schreiben Sie die unverzichtbaren lokalen Abläufe konkret auf.
Wer betreibt das System? Erreichbarkeit, Vertretung und Fachkenntnisse gehören zur Entscheidung.
Wie viel Unterbrechung und Datenverlust sind tragbar? Das legt Sicherung und Wiederanlauf fest.
Wie kommen Daten und Anwendung später wieder heraus? Export, Formate, Identitäten und Wiederaufbau müssen gemeinsam funktionieren.

Die Antworten sollten pro Anwendung dokumentiert werden. Ein Dateidienst, eine Warenwirtschaft und ein öffentliches Portal haben häufig unterschiedliche Anforderungen. Wer alle drei mit derselben Begründung verschiebt, übersieht leicht eine lokale Abhängigkeit oder bezahlt für eine Flexibilität, die der gleichmäßig laufende Dienst gar nicht nutzt.

Eine Entscheidungsmatrix mit echten Gegenargumenten

Orientierung nach Betriebsmodell; konkrete Angebote können abweichen
Kriterium	Eigene Hardware	Gemieteter Server	Cloud-Dienste
Kapazität kurzfristig ändern	Ausbau oder weitere Hardware organisieren	Paketwechsel oder zusätzliche Maschine abstimmen	Je Dienst flexibel; Quoten und Architektur beachten
Lokaler Betrieb ohne Internet	Mit lokalen Abhängigkeiten planbar	Verbindung zum Rechenzentrum nötig	Verbindung zu entfernten Diensten nötig
Hardware-Verantwortung	Eigener Betrieb oder beauftragter Service	Anbieter gemäß Vertrag	Anbieter für seine Plattform
Anwendungsbetrieb	Eigenes Team oder Dienstleister	Oft eigene Aufgabe; Vertrag prüfen	Je Dienst teilweise übernommen
Zahlungsstruktur	Anschaffung plus laufender Betrieb	Regelmäßige Zahlung und Zusatzleistungen	Nutzung, Bereitstellung und mögliche Bindungen
Ablösung	Hardwarewechsel und Datenübernahme	Export und Wechsel des Hosts	Export plus Prüfung dienstspezifischer Abhängigkeiten

Gewichten Sie die Kriterien erst nach dem Anforderungsblatt. Wenn eine Maschine in der Fertigung bei einer unterbrochenen Internetleitung weiterarbeiten muss, ist das eine Grenze und keine kleine Punktzahl in einer Gesamtwertung. Innerhalb der verbleibenden Optionen können Aufwand, Kosten und Änderbarkeit gegeneinander abgewogen werden. Eine mathematische Rangliste soll fehlende Eignung nicht verdecken.

Drei Anwendungen, drei mögliche Entscheidungen

Beispiel eins: Ein Planungsbüro bearbeitet große Projektdateien fast vollständig an einem Standort. Die Datenübertragung zu entfernten Diensten ist im Test der größte Zeitfaktor. Ein lokaler Dateidienst mit eigenständig wiederherstellbarer externer Sicherung kann hier passen. Voraussetzung sind ein geeigneter Raum, Wartung und ein Ersatzplan. Die Entscheidung würde sich ändern, wenn das Team künftig überwiegend verteilt arbeitet.

Beispiel zwei: Ein öffentliches Buchungsportal hat unregelmäßige Spitzen und ein kleines internes IT-Team. Eine betreute Anwendungsplattform samt Datenbank kann Aufgaben abnehmen, sofern die Software darauf ausgelegt ist. Dafür müssen Kosten pro Buchung, Datenexport und die Grenzen des Dienstes geprüft werden. Ein rund um die Uhr gleich großer virtueller Server wäre zwar ebenfalls Cloud, schöpft diese Möglichkeit aber nicht automatisch aus.

Beispiel drei: Eine interne Anwendung läuft stabil und mit gut bekanntem Bedarf. Das Unternehmen möchte keinen Serverraum betreiben, hat aber einen Dienstleister für Betriebssystem und Anwendung. Ein gemieteter dedizierter oder passend zugesicherter virtueller Server kann den Aufwand überschaubar halten. Zu prüfen bleiben der tatsächliche Wiederanlauf, die Anbindung der Mitarbeitenden und der vertragliche Umfang des Hardwareersatzes.

Wer macht Updates, Sicherungen und Wiederherstellungen?

AWS ordnet bei EC2 unter anderem das Gastbetriebssystem und die installierte Anwendung dem Kunden zu. Der Anbieter betreibt die darunterliegende Infrastruktur. Bei anderen Diensten verschiebt sich die Aufteilung. Übertragen Sie dieses Prinzip auf jedes Angebot und lassen Sie Zuständigkeiten je Schicht benennen. AWS: Shared Responsibility Model ↗

Ein gutes Betriebsblatt nennt für Hardware, Betriebssystem, Datenbank, Anwendung, Benutzerzugänge und Sicherung jeweils eine verantwortliche Rolle. Dazu kommen Vertretung, Reaktionszeiten und das Vorgehen bei Änderungen. Vermeiden Sie Formulierungen wie „macht vermutlich der Hoster“. Genau diese Lücke fällt sonst erst auf, wenn eine Datenbank wiederhergestellt werden muss und beide Seiten nur für einen Teil zuständig sind.

RTO beschreibt das Ziel für die Wiederherstellungsdauer, RPO den tolerierbaren Datenverlust in Zeit. Diese Ziele werden aus dem Geschäft abgeleitet. Die AWS-Dokumentation unterscheidet entsprechend zwischen Verfügbarkeit einzelner Komponenten und der Wiederherstellung einer vollständigen Anwendung nach einem größeren Ausfall. AWS: Planung der Disaster Recovery ↗

Flexibilität hat einen Wert, Bindung hat Folgen

Eine kurzfristig abschaltbare Testumgebung muss nicht nach derselben Rechnung beschafft werden wie eine Datenbank, die jahrelang durchläuft. AWS beschreibt unterschiedliche Preismodelle für veränderliche Last, kurzfristige Nutzung und längerfristige Verbrauchszusagen. Eine Verpflichtung kann die Kosten senken, aber nur, wenn die zugesagte Nutzung tatsächlich anfällt. Ein Rabatt ersetzt keine Bedarfsprognose. AWS: Preismodell an den Workload anpassen ↗

Fordern Sie für jede Variante eine Kalkulation mit denselben Datenmengen, Laufzeiten, Sicherungsfristen und Betreuungsaufgaben an. Rechnen Sie zusätzlich einen Monat mit höherem Bedarf sowie das Ende des Vertrags. Bei eigenen Systemen gehört der Hardwaretausch hinein; bei externen Diensten gehören Export, Transfer und Neuaufbau hinein. Ein vermeintlich niedriger Einstiegspreis kann im vollständigen Zeitraum anders aussehen.

Portabilität durch einen kleinen Exportversuch belegen

Eine Download-Schaltfläche beweist noch keine Wechselmöglichkeit. Exportieren Sie in einem Test einen repräsentativen Datenbestand samt benötigter Konfiguration und spielen Sie ihn in einer getrennten Zielumgebung ein. Prüfen Sie, ob Beziehungen, Berechtigungen, Anhänge und Zeitstempel erhalten bleiben. Bei einer Anwendung kommen Datenbankschema, benötigte Dienste und die Zuordnung von Benutzerkonten hinzu.

Messen Sie auch die Dauer. Ein hypothetischer Export von 2 TB über eine effektiv verfügbare Verbindung mit 100 Mbit/s benötigt rein rechnerisch rund 44,4 Stunden für die Übertragung, wenn dezimale Einheiten zugrunde liegen. Vorbereitung, Prüfung und Unterbrechungen kommen hinzu. Das kann für einen Archivumzug akzeptabel sein, für einen kurzfristigen Wiederanlauf jedoch nicht. Exportfähigkeit und Wiederherstellbarkeit sind deshalb getrennt zu testen.

Mit einem begrenzten Pilot entscheiden

Wählen Sie eine repräsentative Anwendung und testen Sie die favorisierte Variante unter realistischen Bedingungen. Der Pilot braucht vorab messbare Kriterien: Antwortzeiten bei vereinbarter Nutzerzahl, vollständige Sicherung, Wiederanlauf innerhalb des Ziels und ein nachvollziehbarer Monatskostenbericht. Definieren Sie außerdem den Rückweg, bevor produktive Daten verschoben werden.

Nach dem Test sollte die Entscheidung in einem kurzen Dokument stehen: gewähltes Modell, übernommene Verantwortlichkeiten, Kostenannahmen, akzeptierte Einschränkungen und nächste Prüfung. Die beste Architektur ist diejenige, die das Team zuverlässig betreiben und später verändern kann. Das kann je Anwendung ein anderes Modell sein, solange Übergänge und Zuständigkeiten klar bleiben.