Heute geben wir einen Ausblick auf eine neue Funktion zur leichteren Entwicklung cloudneutraler Anwendungen: Workers VPC.
Es handelt sich um unsere Version der traditionellen Virtual Private Cloud (VPC). Diese wurde so modernisiert, dass sie für Netzwerke und Rechenleistung genutzt werden kann, die nicht an eine bestimmte Cloud-Region gebunden sind. Um den Wechsel zwischen verschiedenen Clouds beim Entwickeln zu erleichtern, wird dieses Angebot durch Workers VPC Private Links ergänzt. Damit wird Workers um zwei neue Optionen erweitert:
Die Bündelung der Ressourcen von Anwendungen auf Cloudflare in isolierten Umgebungen, sodass nur Ressourcen innerhalb der gleichen Workers VPC aufeinander zugreifen können. Auf diese Weise lässt sich Traffic zwischen Anwendungen (innerhalb einer „Workers VPC“) absichern und segmentieren.
Das Verbinden einer Workers VPC mit einer älteren VPC in einer Public Cloud oder Private Cloud (mit dem „Workers VPC Private Link“), damit Ihre auf Cloudflare und in privaten Netzwerken angesiedelten Ressourcen so aufeinander zugreifen können, als würden sie sich alle in einer einzigen VPC befinden.
Wechselseitige Verbindungen zwischen Cloudflare und externen Clouds dank Workers VPC und Workers VPC Private Link
Bei Verknüpfung mit einer externen VPC sorgt Workers VPC dafür, dass die zugrunde liegenden Ressourcen direkt adressierbar sind. Das erlaubt es Entwicklern von Applikationen, auf Anwendungsschicht zu arbeiten, ohne sich mit der darunter gelegenen Netzwerkschicht beschäftigen zu müssen. Sie können sich das Ganze als eine einzige VPC für sämtliche Clouds vorstellen, bei der eine Funktion zum Aufspüren aller Dienste integriert ist.
Wir sind dabei, Workers VPC auf Grundlage unserer bestehenden Produkte für private Netzwerke zu entwickeln, und wollen die Lösung im weiteren Jahresverlauf auf den Markt bringen. Um frühzeitig Feedback einzuholen und mehr über die Bedürfnisse unserer Kunden zu erfahren, möchten wir an dieser Stelle aber schon einmal einen Ausblick auf das Produkt geben.
Herausforderungen beim Entwickeln privater cloudneutraler Anwendungen
Wenn es um die Erstellung vielseitiger, zustandsbehafteter Anwendungen geht, entscheiden sich Entwickler immer häufiger für Workers als Plattform. Die ursprünglichen Edge-Anwendungsfälle von Workers haben wir schon längst hinter uns gelassen: Inzwischen werden weitere Bestandteile des Stacks modernisiert und man verlagert mehr Geschäftslogik auf Workers. So werden mit Workers etwa Anwendungen für eine Zusammenarbeit in Echtzeit geschaffen, die auf externe Datenbanken zugreifen, aber auch Applikationen, die geschützte API in großem Maßstab nutzen, sowie Model Context Protocol (MCP)-Server, die Geschäftslogik für Agenten offenlegen, die sich so nah wie möglich an den Endnutzern befinden.
Die letzte Hürde, die bei der Nutzung von externen Clouds noch besteht, ist die VPC. Virtual Private Clouds geben Ihnen zwar Sicherheit, sind aber bewusst so angelegt, dass sie gewaltige Hürden bei der Entwicklung von Anwendungen auf Workers schaffen. Unausgesprochen wird damit bezweckt, dass Kunden mehr ältere VPC einsetzen: Es handelt sich um eine weitere Taktik, mit der manche Cloudanbieter versuchen, die Daten und Anwendungen ihrer Kunden in Geiselhaft zu nehmen und diese an sich zu binden.
In vielen Gesprächen mit Kunden wurde uns gesagt, dass VPC ein Hemmschuh sind. Uns ist klar, warum das so ist: Die Verwendung von VPC wird von Unternehmen zwingend vorgeschrieben, und das aus gutem Grund. Um von Workers auf nicht öffentliche Ressourcen zuzugreifen, muss man entweder 1) neue öffentliche API erstellen, die zur Gewährleistung eines sicheren Zugangs eine Authentifizierung durchführen, oder 2) Cloudflare-Tunnel und Zero Trust für jede Ressource, auf die zugegriffen werden soll, einrichten und skalieren. Damit müssen bereits viele Bedingungen erfüllt sein, bevor man überhaupt mit der Entwicklungsarbeit beginnen kann.
Wir verfügen über die erforderlichen Speicher- und Rechenoptionen, um ein Produkt vollständig auf Workers zu erschaffen. Aber uns ist natürlich auch klar, dass Sie Ihre Anwendungen oder Daten nicht von heute auf morgen umziehen werden. Doch unserer Meinung nach sollten Sie zumindest die Möglichkeit haben, sich zur Erstellung moderner Anwendungen, KI-Agenten und weltweit nutzbarer Echtzeit-Applikationen mit Ihren bestehenden privaten API und Datenbanken für Workers zu entscheiden, wenn Sie dies möchten. Deshalb arbeiten wir an Workers VPC.
Wie mühsam es ist, rund um VPC Produkte zu entwickeln, haben wir am eigenen Leib erfahren. 2024 haben wir bei Hyperdrive Unterstützung für private Datenbanken eingeführt. Seitdem kann man mit Cloudflare-Tunneln als zugrundeliegende Netzwerklösung von Cloudflare Workers eine Verbindung zu Datenbanken herstellen, die in einer externen VPC angesiedelt sind. Als Direktverbindung funktioniert diese Lösung hervorragend. Allerdings sind ihr Grenzen gesetzt: Bei großen und komplexen Architekturen ist die Verwaltung und Skalierung eines Cloudflare-Tunnels für jede einzelnen Ressource in einer externen Cloud nicht leistbar.
Wir möchten deshalb eine kinderleichte Lösung für den Zugriff auf externe Cloud-Ressourcen anbieten, die mit der künftigen Modernisierung weiterer Workloads mit Workers Schritt halten kann. Dafür greifen wir auf unsere bei der Entwicklung von Magic WAN und Magic Cloud Networking gesammelten Erfahrungen zurück.
Mit Workers VPC erreichen VPC eine globale Dimension. Außerdem lassen sie sich über Workers VPC Private Links mit bestehenden privaten Netzwerken verbinden. Wir möchten Ihnen nämlich die Möglichkeit bieten, sichere, weltweit einsetzbare und cloudneutrale Anwendungen auf Workers zu erschaffen.
Eine globale VPC für weltweit einsetzbare, cloudneutrale Anwendungen
Die Einrichtung privater Netzwerke ist aufwendig, sie erstrecken sich über viele Abstraktionsebenen und für ihre Verwaltung werden ganze Teams benötigt. Kaum etwas ist so kompliziert wie die Pflege von Architekturen, die aus ihrem ursprünglichen Direktverbindungsnetzwerk herausgewachsen sind. Somit war uns klar, dass wir eine einfache Lösung für isolierte Umgebungen auf unserer Plattform bereitstellen mussten.
Bei Workers VPC handelt es sich naturgemäß um Virtual Private Clouds. Das heißt, dass damit isolierte Umgebungen von Workers und Ressourcen der Entwicklerplattform wie R2, Workers KV und D1 definiert werden können, die auf sichere Weise gegenseitig aufeinander zugreifen können. Andere Ressourcen in Ihrem Cloudflare-Konto haben dagegen keinen Zugriff darauf. Mit VPC kann festgelegt werden, welche Ressourcen-Gruppen mit bestimmten Anwendungen verknüpft sind. So lässt sich ein anwendungsübergreifender Zugriff auf Ressourcen verhindern.
Workers VPC ähneln herkömmlichen VPC, wurden aber für die Entwicklerplattform von Cloudflare neu gedacht. Der Hauptunterschied besteht in der Art und Weise, in der Workers VPC implementiert werden: Sie bauen nicht auf einem regionalen, IP-basierten Netzwerk auf, sondern sind für den globalen Maßstab konzipiert. Das Cloudflare-Netzwerk übernimmt die Isolierung der Ressourcen bei allen darin enthaltenen Rechenzentren.
Workers VPC verfügen wie traditionelle VPC über Funktionen zur reibungslosen Integration in herkömmliche Netzwerke. Auf diese Weise können Sie cloudneutrale Anwendungen erstellen, die niemals die Netzwerke verlassen, die Sie als vertrauenswürdig erachten. An dieser Stelle kommt Workers VPC Private Links ins Spiel.
Wie bei AWS PrivateLink und anderen VPC-zu-VPC-Modellen verbindet Workers VPC Private Links Ihre Workers VPC entweder über Standard-Tunnel per IPsec oder über Cloudflare Network Interconnect mit Ihrer externen Cloud. Wird ein Private Link hergestellt, können die Ressourcen beider Seiten direkt aufeinander zugreifen, ohne etwas über das öffentliche Internet offenzulegen – ganz so, als würde dies innerhalb einer einzigen, verbundenen VPC erfolgen.
Workers VPC Private Link stellt automatisch ein Gateway für IPsec-Tunnel oder Cloudflare Network Interconnect bereit und konfiguriert DNS zur Weiterleitung an Cloudflare-Ressourcen.
Um das zu ermöglichen, arbeiten Workers VPC und Private Links für die automatische Bereitstellung und Verwaltung der Ressourcen in der externen Cloud zusammen. Dadurch wird die Verbindung zwischen den beiden Netzwerken hergestellt und es werden die erforderlichen Ressourcen für bidirektionales Routing konfiguriert. Da wir wissen, dass manche Teams die volle Verantwortung für die Ressourcenbereitstellung behalten möchten, bietet Workers VPC Private Link bei Bedarf automatisch Terraform-Skripte zum Selbstausführen für die Bereitstellung von Ressourcen in externen Clouds an.
Workers VPC erkennt nach der Herstellung der Verbindung die Ressourcen in der externen VPC automatisch und sorgt dafür, dass sie in Form von Bindungen mit eindeutigen ID verfügbar sind. Über die Ressourcenbindung von Workers VPC gestellte Anfragen werden automatisch an die externe VPC übermittelt, wo (bei Verwendung von Ressourcen, auf die über den Hostnamen zugegriffen wird) die DNS-Auflösung erfolgt und die Anfragen an die gewünschte Ressource weitergeleitet werden.
Um beispielsweise von Cloudflare Workers eine Verbindung zu einer privaten API in einer externen VPC herzustellen, muss lediglich fetch() auf einer Bindung an eine benannte Workers VPC-Ressource aufgerufen werden:
const response = await env.WORKERS_VPC_RESOURCE.fetch("/api/users/342");In ähnlicher Weise sind Cloudflare-Ressourcen über eine standardisierte URL zugänglich, die von Workers VPC Private Link innerhalb einer privaten DNS-Ressource in der externen Cloud konfiguriert wurde. Würde man versuchen, über eine API in der VPC auf R2-Objekte zuzugreifen, könnte man die Anfrage an die vorgesehene URL senden:
const response = await fetch("https://<account_id>.r2.cloudflarestorage.com.cloudflare-workers-vpc.com");Das Beste an dieser Lösung ist, dass Workers VPC auf unserer bestehenden Plattform aufbaut und deshalb unsere Möglichkeiten im Bereich Netzwerk und Routing voll ausschöpft. So können Gebühren für ausgehenden Traffic gespart und Anwendungen mit globaler Reichweite entwickelt werden.
Ermöglicht wird dies erstens, indem Workers VPC Private Links Cloudflare Network Interconnect als zugrundeliegende Verbindungsmethode unterstützt, wodurch die Bandbreitenkosten reduziert werden und von niedrigeren Preisen für ausgehenden Traffic von externen Clouds profitiert wird. Zweitens weist Workers VPC von vornherein eine globale Dimension auf. Damit lassen sich Worker und Ressourcen überall dort ansiedeln, wo sie zur Gewährleistung einer optimalen Performance benötigt werden. So kann zur Maximierung der Anwendungsleistung etwa mit der Smart Placement-Funktion von Workers sichergestellt werden, dass Worker automatisch in einer Region angesiedelt werden, die der externen, regionalen VPC am nächsten liegt.
Eine Connectivity Cloud mit voller Bandbreite
Workers VPC wird einen großen Teil der Workloads frei, die derzeit noch fest an externe Clouds gebunden sind, ohne dass diese privaten Ressourcen dem öffentlichen Internet ausgesetzt werden müssen, um auf Workers Produkte zu entwickeln. Unsere Kunden haben uns von einigen Anwendungen berichtet, die sie mit Workers VPC auf Workers erschaffen wollen, zum Beispiel:
Schematische Darstellung der Architektur einer auf Workers und Durable Objects basierenden Echtzeit-Canvas-Anwendung, die auf eine private Datenbank und Container in einer externen VPC zugreift.
Nehmen wir an, Sie versuchen, auf Workers eine neue Funktion für Ihre Anwendung zu entwickeln. Darüber hinaus soll die Applikation mit Durable Objects um die Möglichkeit erweitert werden, in Echtzeit zusammenzuarbeiten. Außerdem verwenden Sie Container, weil Sie für die Verarbeitung von Live-Videos FFmpeg nutzen müssen. In jedem Fall benötigen Sie eine Möglichkeit, die Status-Updates in Ihrer bestehenden herkömmlichen Datenbank dauerhaft zu speichern und auf Ihre bestehenden API zuzugreifen.
Bislang hätten Sie möglicherweise eine separate API erstellen müssen, nur um Aktualisierungsvorgänge von Workers und Durable Objects abzuwickeln, doch jetzt können Sie unmittelbar auf die herkömmliche Datenbank zugreifen und den Wert direkt mit Workers VPC aktualisieren.
Das Gleiche gilt für Model Context Protocol (MCP)-Server. Wird ein MCP-Server auf Workers gebaut, soll eventuell eine bestimmte Funktion offengelegt werden, für die nicht sofort eine öffentliche API verfügbar ist – vor allem, wenn auf eine schnelle Markteinführung Wert gelegt wird. Mit Workers VPC können Sie neue Funktionen direkt auf Ihrem MCP-Server erstellen, die auf Ihren privaten API oder Datenbanken aufbauen, und so eine schnelle und sichere Bereitstellung ermöglichen.
Modellarchitektur für externe Cloud-Ressourcen, die auf Daten von R2, D1 und KV zugreifen.
Viele Entwicklerteams hinterlegen immer mehr Daten auf der Entwicklerplattform von Cloudflare. Sie speichern etwa KI-Trainingsdaten auf R2, weil dann keinerlei Kosten für ausgehende Daten anfallen, .Anwendungsdaten auf D1, da diese Lösung ein horizontales Sharding-Modell bietet, oder Konfigurationsdaten auf KV, um von einer weltweiten Leselatenz im einstelligen Millisekundenbereich zu profitieren.
Als Nächstes müssen Sie eine Möglichkeit bieten, die auf R2 gespeicherten Trainingsdaten von den Rechenaktionen in Ihrer externen Cloud zu nutzen, um LLM-Modelle zu trainieren oder ihnen den Feinschliff zu geben. Da Sie auf Nutzerdaten zugreifen, wird Ihnen von Ihrer IT-Sicherheitsabteilung die Verwendung eines privaten Netzwerks vorgeschrieben. Außerdem brauchen Sie für bestimmte Verwaltungs- oder Analysetätigkeiten Zugriff auf Nutzer- und Konfigurationsdaten auf D1 und KV, wofür Sie den Weg über das öffentliche Internet vermeiden möchten. Workers VPC ermöglicht direktes, privates Routing von Ihrer externen VPC zu Cloudflare-Ressourcen mit leicht zugänglichen Hostnamen aus dem automatisch konfigurierten privaten DNS.
Last but not least wollen wir uns noch ein Beispiel mit einem KI-Agenten anschauen – schließlich befinden wir uns gerade in der Developer Week 2025. Besagter KI-Agent baut auf Workers auf und nutzt Retrieval Augmented Generation (RAG), um die Ergebnisse des von ihm generierten Texts zu verbessern und gleichzeitig das Kontextfenster so klein wie möglich zu halten.
Sie verwenden PostgreSQL und Elasticsearch in Ihrer externen Cloud, da sich dort gerade Ihre Daten befinden und Sie ein Fan von pgvector sind. Für Workers haben Sie sich entschieden, weil Sie möglichst schnell Marktreife erreichen wollen. Jetzt brauchen Sie Zugriff auf Ihre Datenbank. Diese wiederum ist in einem privaten Netzwerk angesiedelt und über das öffentliche Internet nicht zugänglich.
Sie könnten zwar eine neue Version von Hyperdrive und Cloudflare Tunnel in einem Container bereitstellen, aber da Ihre Workers VPC bereits eingerichtet und verknüpft ist, können Sie direkt über Workers oder Hyperdrive auf die Datenbank zugreifen.
Und was, wenn dem Objektspeicher in Ihrer externen Cloud neue Dokumente hinzugefügt werden? Vielleicht möchten Sie ja einen Workload starten, um das neue Dokument zu verarbeiten, es in verschiedene Abschnitte zu unterteilen, Einbettungen dafür zu erhalten und den Status Ihrer Anwendung entsprechend zu aktualisieren, während Sie gleichzeitig Ihre Endnutzer in Echtzeit über den Stand des Vorgangs informieren.
In diesem Fall können Sie einen Workflow verwenden. Dieser wird durch eine Serverless-Funktion in der externen Cloud aktiviert, ruft dann das neue Dokument aus dem Objektspeicher ab, verarbeitet es bedarfsgemäß, verarbeitet und aktualisiert die Vektorspeicher in Postgres mit Ihrem bevorzugten Einbettungsanbieter (beispielsweise Workers AI) und aktualisiert schließlich den Status Ihrer Anwendung.
Dabei handelt es sich nur um einen von zahlreichen Workloads, von denen Sie vom ersten Tag an mit Workers VPC profitieren werden. Wir sind schon gespannt darauf, was Sie alles erschaffen werden, und freuen uns darauf, gemeinsam mit Ihnen weltweit nutzbare VPC Realität werden zu lassen.
Eine neue Ära für Virtual Private Clouds
Wir sind stolz darauf, dass Sie mit Workers VPC bald noch mehr auf Workers entwickeln werden können, und sind davon überzeugt, dass der private Zugriff auf Ihre API und Datenbanken in Ihren privaten Netzwerken neu definieren wird, was Sie auf Workers erschaffen können. Workers VPC ermöglichen den Zugriff auf Ihre privaten Ressourcen, was Sie in die Lage versetzt, schnellere und leistungsfähigere Anwendungen auf Workers bereitzustellen. Und wir werden natürlich sicherstellen, dass Container nativ in Workers VPC integriert werden können.
Wir entwickeln Workers VPC aktiv auf den Netzwerkprimitiven und Zugangswegen, mit denen wir Kundennetzwerke maßstabsgerecht verbinden. Geplant ist, im weiteren Jahresverlauf eine erste Vorschau auf das Produkt zu bieten.
Als Erstes wollen wir die Verbindung von Workers zu externen Clouds in Angriff nehmen, damit Sie mehr Anwendungen, die Zugriff auf private API und Datenbanken benötigen, mit Workers modernisieren können. Im Anschluss daran ist die Unterstützung von Datenverkehrsströmen in alle Richtungen und mehreren Workers VPC-Netzwerken vorgesehen. Wenn Sie an der Gestaltung von Workers VPC teilhaben möchten und Ihre Workloads aktuell an eine bestimmte Cloud gebunden sind, können Sie hier Ihr Interesse bekunden.