Fog Computing taucht in Architektur-Glossaren häufig als Vorstufe von Edge Computing auf – in der Praxis wird der Begriff aber kaum noch verwendet. Das BSI hat beide Begriffe in seiner Cyber-Sicherheitsempfehlung BSI-CS 148 sauber definiert und historisch eingeordnet. Wir fassen zusammen, was Fog Computing bedeutet, wie es sich von Cloud und Edge Computing unterscheidet und warum das BSI heute nur noch von Edge Computing mit innerer und äußerer Edge-Ebene spricht.
Das Wichtigste vorab
Fog Computing beschreibt serviceorientierte, verteilte Systeme zur Datenverarbeitung am Rand einer Cloud – 2017/2018 von NIST und dem Open Fog Consortium als Quasi-Standard geprägt. Edge Computing ist laut BSI die Weiterentwicklung davon: dieselbe Grundidee, aber außerhalb der Cloud und noch näher an den Endgeräten. In der Praxis hat sich der Fog-Begriff kaum durchgesetzt; das BSI selbst verwendet inzwischen ausschließlich „Edge Computing“ und unterscheidet stattdessen zwischen innerer und äußerer Edge-Ebene.
Was Fog Computing laut BSI bedeutet
Das BSI definiert Fog Computing als „serviceorientiertes Anbieten und Nutzen von verteilten Systemen zur Verarbeitung von Daten räumlich nah am Bedarf am Rande einer Cloud“. Wie beim Cloud Computing werden dabei Dienste aus den Servicemodellen SaaS, PaaS und IaaS angeboten – der Unterschied liegt im Ort: Fog-Dienste sind ortsgebunden, um Latenzen zu senken oder ortsabhängige Vorgaben wie den Datenschutz einzuhalten.
Zentral für diese Definition ist der Begriff „Rand der Cloud“: eine meist von den übrigen Cloud-Systemen getrennte Verarbeitungsumgebung, die geografische Vorteile, hohe Rechenleistung oder einen physischen Anker für Rechenaufgaben bietet. Sie kann technisch Teil einer Cloud sein oder außerhalb davon liegen, wird aber schematisch weiterhin der Cloud zugeordnet. „Verteilte Systeme“ wiederum bezeichnet nach BSI-Verständnis eine in sich abgeschlossene Ansammlung von IT-Systemen für Rechenleistung, Speicher, Netz und Managementfunktionen, die eine Aufgabe dynamisch und skalierbar erfüllen – in Anlehnung an die klassische Definition von Andrew S. Tanenbaum, wonach ein verteiltes System der Zusammenschluss unabhängiger Computer ist, die sich dem Benutzer als ein einziges System präsentieren.
Herkunft: NIST und das Open Fog Consortium
Der Begriff ist nicht neu: Bereits 2017 und 2018 beschrieben NIST und das Open Fog Consortium Fog Computing als eigenständige Quasi-Standard-Technologie – zunächst als Teil oder Ergänzung der Cloud, angeboten am Rand des Cloud-Verbunds. Aus Sicht des BSI ist Edge Computing die Weiterentwicklung dieses Ansatzes: Im Lauf der Jahre rückte die Technologie unter der neuen Bezeichnung näher an die Endgeräte heran, deren Daten in den Komponenten verarbeitet werden.
Cloud, Fog und Edge Computing im Vergleich
Die drei Begriffe unterscheiden sich vor allem darin, wo die Datenverarbeitung stattfindet und wie nah sie am tatsächlichen Bedarf liegt:
| Begriff | BSI-Definition | Verhältnis zur Cloud |
|---|---|---|
| Cloud Computing | „Das dynamisch an den Bedarf angepasste Anbieten, Nutzen und Abrechnen von IT-Dienstleistungen über ein Netz.“ | Zentralisierte Rechenzentren; Angebot und Nutzung ausschließlich über definierte Schnittstellen und Protokolle |
| Fog Computing | „Serviceorientiertes Anbieten und Nutzen von verteilten Systemen zur Verarbeitung von Daten räumlich nah am Bedarf am Rande einer Cloud.“ | Am Rand der Cloud, schematisch noch der Cloud zugeordnet |
| Edge Computing | „Bedarfsnahes, serviceorientiertes Anbieten und Nutzen von verteilten Systemen zur Verarbeitung von Daten außerhalb einer Cloud und räumlich nah am Bedarf.“ | Außerhalb der Cloud, näher an den Endgeräten als Fog Computing |
Warum überhaupt getrennt von der Cloud betrachten?
Für viele Anwendungsfälle reicht reines Cloud Computing aus – bei hoch spezialisierten, wiederkehrenden oder rechenintensiven Aufgaben ist die Auslagerung in zentrale Rechenzentren sogar der wirtschaftlichste Weg. Für drei Szenarien stößt der Cloud-Ansatz nach BSI-Einschätzung aber an Grenzen: Echtzeitanwendungen, bei denen die Latenz zum entfernten Rechenzentrum zu hoch ist; Anwendungen mit hohen Datenvolumina, deren Transport zum Verarbeitungsort und zurück hohe Transitkosten verursacht; und ortsabhängige Compliance-Vorgaben, etwa beim Datenschutz. Genau für diese Fälle verlagert der Fog- beziehungsweise Edge-Ansatz die Verarbeitung näher an den Ort des Bedarfs.
Das Schichtenmodell: von der Cloud bis zum Endgerät
Um Gefährdungen und Sicherheitsmaßnahmen strukturiert bewerten zu können, arbeitet das BSI mit einem vierschichtigen Modell:
- Endgeräte-Ebene: Kameras, Sensoren, Aktoren oder größere Geräte wie Fahrzeuge, landwirtschaftliche Maschinen, Laptops oder Smartphones, die Daten liefern oder Verarbeitungsergebnisse entgegennehmen.
- Innere Edge-Ebene: liegt im selben Netz wie die Endgeräte und stellt Dienste für schnelle, lokal sehr nahe Verarbeitung bereit – etwa für zeitkritische Steuerungen. Fremdadministrierte Edge-Komponenten müssen hier netztechnisch von den übrigen Endgeräten getrennt werden.
- Äußere Edge-Ebene: liegt außerhalb des Endgerätenetzes und der Cloud, reduziert Daten für die Cloud-Verarbeitung oder übernimmt ortsabhängige Aufgaben für die unteren Ebenen.
- Cloud-Ebene: klassische, dynamisch skalierbare Cloud-Dienste in Rechenzentren, direkt oder über Edge-Komponenten nutzbar.
Sowohl die innere als auch die äußere Edge-Ebene bestehen technisch meist aus sogenannten Cloudlets: Systemgruppen, die Cloud-ähnliche Dienste wie IaaS, PaaS und SaaS ortsgebunden anbieten. Das Carnegie Mellon Software Engineering Institute – Urheber des Begriffs – beschreibt ein Cloudlet als „data center in a box“, dessen Ziel es ist, „die Cloud näher zu bringen“: die mittlere Ebene einer dreistufigen Hierarchie aus Endgerät, Cloudlet und Cloud.
Warum das BSI heute nur noch von Edge Computing spricht
In der Praxis hat sich der Begriff Fog Computing kaum durchgesetzt. Das BSI zieht daraus in BSI-CS 148 eine klare Konsequenz: Für die sicherheitstechnische Bewertung eingesetzter Komponenten wird ausschließlich „Edge Computing“ verwendet. Die relevante Unterscheidung verläuft seitdem nicht mehr zwischen Fog und Edge, sondern zwischen innerer und äußerer Edge-Ebene – je nachdem, ob eine Komponente innerhalb des Endgerätenetzes liegt, außerhalb davon oder direkt in der Netztechnologie integriert ist, etwa bei 5G Multi-Access Edge Computing (MEC).
Warum die Abgrenzung für Unternehmen trotzdem relevant bleibt
Auch wenn der Fog-Begriff verschwindet, bleibt die dahinterliegende Architekturentscheidung real: Wer Daten näher am Ort des Bedarfs verarbeiten will – etwa bei Industrial IoT, bei IoT-Anwendungen für die Gesellschaft wie einer Smart-City-Verkehrssteuerung oder bei latenzkritischer Datenverarbeitung wie Hochfrequenzhandel –, muss festlegen, auf welcher Ebene welche Verantwortung liegt. BSI-CS 148 illustriert das Modell selbst an drei fiktiven, aber praxisnahen Beispielen genau aus diesen Bereichen. Für Edge Computing gilt dabei grundsätzlich dasselbe Shared-Responsibility-Modell wie beim Cloud Computing, und dieselben Standards greifen weiter: der C5-Kriterienkatalog, der IT-Grundschutz-Baustein OPS.2.2 „Cloud-Nutzung“, die ISO/IEC-27000-Reihe oder die Cloud Controls Matrix der Cloud Security Alliance.
Für die konkrete Umsetzung liefert BSI-CS 148 einen Praxisleitfaden mit Fragenkatalogen entlang des gesamten Lebenszyklus – Planung und Beschaffung, Einsatz sowie Ende der Nutzung –, ergänzt um eine Gefährdungsanalyse für typische Edge-spezifische Risiken wie physische Exposition, hohen Vernetzungsgrad und hohe Komplexität. Wer eine Fog- beziehungsweise Edge-Architektur plant, sollte diese Fragen vor der Anbieterauswahl beantworten können, nicht erst danach.
Quellen
- BSI: Edge und Fog Computing – Definitionen, Abgrenzung zur Cloud und Verweis auf die Cyber-Sicherheitsempfehlung BSI-CS 148.
- BSI-CS 148: Sichere Nutzung von Edge Computing, Version 1 vom 18. Dezember 2023 – Grundlagen, Technologie, Use Cases und Praxisleitfaden, abrufbar über die BSI-Themenseite.
Quellen abgerufen am 6. August 2026. Terminologie und Empfehlungen können sich mit künftigen BSI-Veröffentlichungen weiterentwickeln; dieser Beitrag ersetzt keine eigene Risikoanalyse für den Einzelfall.
