Wann die Cloud der falsche Ort ist

Für Shop und CRM bleibt die Cloud der Default. In Produktion, Energie, Logistik und Handel entscheiden Latenz, Datenhoheit, Bandbreite und Ausfallsicherheit, welcher Teil des Workloads lokal laufen muss.

Verwandt:Wenn Werkshalle und Rechenzentrum ein Netz werden  /  Starre RZ-Verträge treffen fließendes EnEfG

Die Cloud war nie als Antwort auf alles gedacht

Der Weg in die zentrale Cloud war eine rationale Entscheidung. Statt Rechenleistung an vielen Orten vorzuhalten, bündelt man sie an wenigen, elastisch skalierbaren Standorten und kauft sich damit Betriebskomfort, Skalierung und einen kalkulierbaren Kostenblock. Für einen Onlineshop, ein CRM oder ein Data-Warehouse ist das nach wie vor die richtige Wahl. Die Annahme, jeder Workload folge derselben Logik, hält der Praxis aber nicht stand.

Sobald Daten dort entstehen, wo physische Prozesse laufen, dreht sich die Rechnung. Eine Produktionslinie, ein Umspannwerk, ein Logistikzentrum oder ein Einzelhandelsstandort erzeugt Datenströme, deren Wert an Ort und Zeit gebunden ist. Diese Ströme erst hunderte Kilometer weit zu schicken, um eine Entscheidung zurückzubekommen, ist in vielen Fällen technisch unnötig und ökonomisch teuer. Edge Computing verschiebt die Verarbeitung dorthin zurück, wo sie gebraucht wird. Die eigentliche Aufgabe ist nicht, sich für ein Lager zu entscheiden, sondern jeden Workload nach klaren Kriterien einzuordnen.

Die entscheidende Frage lautet, welcher Teil eines Workloads wohin gehört. Edge und Cloud sind ein Kontinuum.

Vier harte Kriterien verschieben die Verarbeitung an die Edge

Latenz. Wo eine Maschine in Millisekunden reagieren muss, verbietet sich der Umweg über ein entferntes Rechenzentrum. Qualitätsprüfung im Takt der Fertigung, Steuerung fahrerloser Transportsysteme oder Schutzfunktionen in der Energietechnik brauchen geschlossene Regelkreise vor Ort. Der Rückkanal in die Cloud kostet hier Zeit, die der Prozess nicht hat.

Datenhoheit. Personenbezogene, sicherheitsrelevante oder regulierte Daten unterliegen Vorgaben, wo sie liegen und wer sie verarbeiten darf. Bleibt die Verarbeitung am Standort, bleibt die Kontrolle über den Datenpfad nachvollziehbar. Das ist im DACH-Raum weniger eine Komfort- als eine Compliance-Frage.

Bandbreitenkosten. Kameras, Sensorik und Messtechnik erzeugen Rohdaten in einem Volumen, das sich nicht wirtschaftlich in die Cloud spiegeln lässt. Die Edge filtert, aggregiert und schickt nur das Relevante weiter. So sinkt die Übertragungslast und der laufende Kostenblock für Anbindung und Speicher.

Ausfallsicherheit. Ein Standort, dessen Betrieb bei jeder gestörten Leitung stillsteht, ist schlecht gebaut. Lokale Verarbeitung hält kritische Funktionen am Laufen, auch wenn die Verbindung zur Zentrale kurz wegbricht. Für Fertigung, Handel und Versorgung ist das der Unterschied zwischen Weiterarbeiten und Stillstand.

Die Workload-Matrix trennt lokale von zentralen Aufgaben

Die vier Kriterien oben reichen für die Richtung. Für die Feinaufteilung pro Workload kommen Rechenintensität und Betrieb hinzu. Kein Kriterium entscheidet allein; die Häufung zeigt, wohin ein Workload gehört.

Der Souveränitäts-Faktor in DACH

Im deutschsprachigen Raum verschiebt sich die Kalkulation durch einen Faktor, der in globalen Cloud-Debatten oft untergeht: Datenhoheit ist hier kein Randthema. Regulatorik, Betriebsvereinbarungen und der Anspruch, den Verarbeitungsort nachweisen zu können, machen aus einer technischen Frage eine strategische. Wer sensible Prozessdaten am Standort verarbeitet, muss nicht erst begründen, warum sie ein fernes Rechenzentrum nie verlassen haben.

Das gilt besonders für Branchen mit langer Anlagenlebensdauer und tiefer Fertigungstiefe. Industrie, Energie und Gesundheitswesen halten Daten vor, deren Weg durch die Infrastruktur belegbar bleiben soll. Edge Computing liefert diesen Nachweis baulich mit: Die Verarbeitung endet dort, wo sie beginnt. Für DACH-Organisationen mit Nachweispflicht ist das oft der härtere Grund als jede Latenzmessung.

Aufteilung statt Entweder-oder

Man kann einwenden, Edge sei teuer im Betrieb: viele Standorte, viele kleine Systeme, verteilte Wartung. Der Einwand stimmt, verfehlt aber den Punkt. Niemand baut sein Data-Warehouse an die Maschine. Die tragfähige Architektur teilt den Workload auf. Zeitkritische Verarbeitung, Vorfilterung und lokale Regelung laufen an der Edge, während Aggregation, Langzeitanalyse und Training zentral bleiben. Die Edge entscheidet in Echtzeit, die Cloud lernt über die Zeit.

Diese Aufteilung begrenzt Datenübertragung und hält zentrale Ressourcen für die Aufgaben frei, die sie tatsächlich benötigen. Wer nur das Relevante in die Cloud schickt, zahlt weniger für Übertragung und Speicher und gewinnt zugleich Ausfallsicherheit vor Ort. Der Fehler liegt nicht darin, Cloud zu nutzen, sondern darin, sie als Standardziel für jeden Datenstrom zu setzen, ohne die Frage nach dem richtigen Ort überhaupt zu stellen.

Der erste Schritt: ein Workload-Raster

Am Anfang steht zuerst eine Inventur und danach die Technologieentscheidung. Jeder relevante Datenstrom kommt auf eine Liste und wird gegen die vier Kriterien geprüft: Wie hart ist die Latenzanforderung, wie sensibel sind die Daten, wie groß ist das Rohdatenvolumen und was passiert bei gestörter Verbindung. Aus dieser Einordnung ergibt sich die Aufteilung fast von selbst.

Der Rest ist Disziplin. Statt einer pauschalen Cloud-first- oder Edge-first-Doktrin gilt die Regel, jeden neuen Workload einmal durch das Raster zu schicken, bevor er landet. Das kostet in der Planung etwas Zeit und spart im Betrieb Latenz, Bandbreite und regulatorischen Aufwand. Edge Computing ist damit die Korrektur einer Pauschalannahme und damit komplementär zur Cloud. Nicht alles gehört in die Cloud. Der Unterschied lässt sich vorher wissen.

Häufig gestellte Fragen

Bildquelle: KI-generiert (Juli 2026)