Aujourd'hui, nous vous présentons en avant-première une nouvelle fonctionnalité permettant de faciliter le développement d'applications multicloud : VPC Workers.
Le service Workers VPC constitue notre version du VPC (Virtual Private Cloud, cloud privé virtuel) traditionnel, modernisée pour une plateforme réseau et de calcul non liée à une seule région cloud. La solution Workers VPC Private Links vient compléter l'ensemble afin de faciliter encore le développement au sein des clouds. Conjointement, ces deux services permettent à Workers de bénéficier de deux nouvelles fonctionnalités :
un moyen de regrouper les ressources de vos applications sur Cloudflare au sein d'environnements isolés, dans lesquels seules les ressources résidant au sein d'un VPC Workers peuvent se connecter les unes aux autres, afin de vous permettre de sécuriser et de segmenter le trafic entre applications (un « VPC Workers ») ;
un moyen de connecter un VPC Workers à un VPC traditionnel au sein d'un cloud privé, de manière à permettre à vos ressources Cloudflare d'accéder à vos ressources présentes dans des réseaux privés et inversement, comme si elles résidaient au sein d'un VPC unique (le « Workers VPC Private Link », lien privé vers un VPC Workers).
Les services Workers VPC et Workers VPC Private Link assurent une connectivité bidirectionnelle entre Cloudflare et les clouds externes
Lorsqu'il est lié à un VPC externe, le VPC Workers rend les ressources sous-jacentes directement adressables, de sorte que les développeurs d'applications puissent raisonner au niveau de la couche applicative, sans descendre au niveau de la couche réseau. Vous pouvez considérer la solution comme un VPC unifié entre les clouds, disposant d'une fonctionnalité intégrée d'identification des services.
Nous développons activement le service Workers VPC en nous appuyant sur nos produits de connectivité réseau privée existants et prévoyons de le déployer plus tard au cours de l'année 2025. Nous souhaitions simplement vous en présenter un aperçu le plus tôt possible afin d'avoir vos retours et d'en apprendre davantage sur vos besoins.
Le développement d'applications multicloud privées s'avère difficile
Les développeurs choisissent de plus en plus Workers comme plateforme de prédilection pour concevoir des applications riches et dynamiques. Nous avons largement dépassé les scénarios d'utilisation initiaux de Workers : vous modernisez désormais une plus grande partie de votre pile et déplacez de plus en plus votre logique métier vers Workers. Vous choisissez Workers pour développer des applications collaboratives en temps réel qui accèdent à vos bases de données externes, des applications à grande échelle qui s'appuient sur vos API sécurisées et des serveurs MCP (Model Context Protocol, protocole de modèle de contexte) qui exposent votre logique métier à des agents situés aussi près que possible de vos utilisateurs finaux.
Vous êtes désormais confrontés à la dernière barrière qui continue de vous maintenir au sein des clouds externes : le VPC. Les clouds privés virtuels vous proposent tranquillité d'esprit et sécurité, mais ils ont été intelligemment conçus pour ajouter délibérément de nouveaux obstacles infranchissables au développement d'applications sur Workers. Il s'agit là d'un intérêt dissimulé et tacite qui vous pousse à utiliser davantage de VPC d'ancienne génération : c'est-à-dire, encore un autre moyen pour les clouds de captivité de retenir vos données et vos applications en otage, afin de vous enfermer.
Dans toutes les discussions que nous avons eues avec vous, vous n'avez pas cessé de nous répéter que « les VPC sont un frein ». Nous l'avons compris : les politiques de votre entreprise imposent le VPC et ce pour de bonnes raisons ! Aussi, pour accéder aux ressources privées depuis Workers, vous devez soit 1) développer de nouvelles API publiques qui se chargent de l'authentification afin d'assurer un accès sécurisé, soit 2) configurer et faire évoluer vos services Cloudflare Tunnel et Zero Trust pour chaque ressource à laquelle vous souhaitez accéder. Ce schéma implique un grand nombre d'étapes à franchir avant de pouvoir commencer à développer.
Si nous disposons effectivement des options de stockage et de calcul nécessaires pour vous permettre de développer intégralement sur Workers, nous comprenons également que vous ne procéderez pas à la migration de vos applications ou de vos données du jour au lendemain ! Nous pensons néanmoins que vous devriez au moins bénéficier de la liberté de choisir Workers dès aujourd'hui pour développer des applications modernes, des agents IA et des applications mondiales en temps réel à l'aide de vos API et de vos bases de données privées existantes. C'est pourquoi nous développons la solution Workers VPC.
Nous avons directement constaté les difficultés liées au développement de solutions autour de VPC. En 2024, nous avons lancé la prise en charge des bases de données privées pour Hyperdrive. Cette fonctionnalité vous a permis de vous connecter à des bases de données situées au sein d'un VPC externe depuis Cloudflare Workers, en utilisant Cloudflare Tunnel comme solution réseau sous-jacente. En tant que solution point à point, celle-ci fonctionne parfaitement ! Toutefois, cette solution a ses limites : la gestion et l'évolution d'un Cloudflare Tunnel pour chaque ressource de votre cloud externe ne sont en effet pas viables pour les architectures complexes et de grande envergure.
Nous souhaitons vous proposer une solution extrêmement simple pour vous permettre de débloquer l'accès à vos ressources sur cloud externe, d'une manière qui évolue à mesure que vous modernisez davantage vos charges de travail avec Workers. De même, nous mettons à profit l'expérience que nous retirons du développement des services Magic WAN et Magic Cloud Networking pour rendre l'opération possible.
Nous faisons donc passer les VPC au niveau mondial grâce à Workers VPC, tandis que Workers VPC Private Links vous permet de les connecter à vos réseaux privés existants. Nous pensons en effet que vous devriez disposer de la liberté de développer des applications sécurisées, mondiales et multicloud sur Workers.
Les applications multicloud mondiales ont besoin d'un VPC mondial
Les réseaux privés sont complexes à mettre en place. Ils s'étendent sur de nombreuses couches d'abstraction et des équipes entières sont nécessaires pour les gérer. Peu de tâches aussi complexes que la gestion d'architectures sont parvenues à dépasser le réseau point à point initial ! Nous savions donc que nous devions proposer une solution simple pour les environnements isolés sur notre plateforme.
Les VPC Workers sont, par définition, des clouds privés virtuels. Ils vous permettent ainsi de définir des environnements isolés de Workers et de ressources de la plateforme pour développeurs (comme R2, Workers KV et D1), capables d'accéder de manière sécurisée les uns aux autres. Les autres ressources de votre compte Cloudflare n'y ont pas accès. Les VPC vous permettent de spécifier certains ensembles de ressources associées à certaines applications et d'assurer l'absence d'accès aux ressources entre les applications.
Les VPC Workers représentent l'équivalent du VPC existant, repensés pour la plateforme de développement Cloudflare. La principale différence réside dans la manière dont les VPC Workers sont mis en œuvre. Plutôt que d'être bâtis sur une connectivité réseau régionale, basée sur l'adresse IP, les VPC Workers sont conçus pour avoir une portée mondiale, le réseau Cloudflare se chargeant d'isoler les ressources dans l'ensemble de ses datacenters.
En outre, comme vous pouvez l'attendre de VPC traditionnels, les VPC Workers disposent de capacités de connectivité réseau qui leur permettent de s'intégrer de manière fluide aux réseaux traditionnels, afin de vous permettre de développer des applications multicloud qui ne quittent jamais les réseaux auxquels vous faites confiance. C'est là que Workers VPC Private Links entre en jeu.
Comme AWS PrivateLink et d'autres approches VPC à VPC, la solution Workers VPC Private Links connecte votre VPC Workers à votre cloud externe à l'aide de tunnels standard sur IPsec ou de Cloudflare Network Interconnect. Lorsqu'un Private Link est établi, les ressources de chaque côté peuvent accéder directement les unes aux autres, sans s'exposer sur l'Internet public, comme s'il s'agissait d'un VPC unique et connecté.
Le service Workers VPC Private Link met automatiquement une passerelle en place pour les tunnels IPsec ou Cloudflare Network Interconnect et configure le DNS pour le routage vers les ressources Cloudflare.
Pour rendre l'opération possible, les solutions VPC Workers et Private Links agissent de concert pour provisionner et gérer automatiquement les ressources au sein de votre cloud externe. Ce mode opératoire établit la connexion entre les deux réseaux et configure les ressources nécessaires au routage bidirectionnel. En outre, comme nous savons que certaines équipes souhaitent conserver l'entière responsabilité en matière de provisionnement des ressources, Workers VPC Private Link peut automatiquement vous proposer des scripts Terraform afin de provisionner des ressources sur cloud externe que vous pouvez exécuter vous-même.
Une fois la connexion établie, Workers VPC détectera automatiquement les ressources situées dans votre VPC externe et les mettra à disposition sous forme de liaisons dotées d'ID uniques. Les requêtes effectuées par le biais de la liaison de ressources VPC Workers seront automatiquement routées vers votre VPC externe, où la résolution DNS s'effectuera (si vous utilisez des ressources accessibles par nom d'hôte), avant leur acheminement vers la ressource attendue.
Ainsi, pour vous connecter de Cloudflare Workers à une API privée au sein d'un VPC externe, il vous suffira d'effectuer un appel fetch() sur une liaison vers une ressource VPC Workers nommée :
const response = await env.WORKERS_VPC_RESOURCE.fetch("/api/users/342");De même, les ressources Cloudflare sont accessibles via une URL normalisée et configurée au sein d'une ressource DNS privée sur votre cloud externe par Workers VPC Private Link. Si vous cherchiez à accéder à des objets R2 depuis une API située au sein de votre VPC, vous pourriez adresser la requête à l'URL attendue :
const response = await fetch("https://<account_id>.r2.cloudflarestorage.com.cloudflare-workers-vpc.com");Cerise sur le gâteau, puisque le service Workers VPC est bâti sur notre plateforme existante, il tire pleinement parti de nos capacités de connectivité réseau et de routage pour réduire les frais de trafic sortant et vous permettre de développer des applications à l'échelle mondiale.
Tout d'abord, en prenant en charge Cloudflare Network Interconnect comme méthode de connexion sous-jacente, la solution Workers VPC Private Links peut vous aider à réduire vos coûts de bande passante en tirant avantage des réductions sur les frais de trafic sortant de votre cloud externe. Deuxièmement, le service VPC Workers étant mondial par nature, vos Workers et vos ressources peuvent être placés là où c'est nécessaire afin de garantir des performances optimales. La fonctionnalité Smart Placement (Placement intelligent) de Workers, par exemple, vous permet de faire en sorte que vos Workers soient automatiquement placés dans la région la plus proche de votre VPC régional externe, afin d'optimiser les performances des applications.
Un cloud de connectivité de bout en bout
La solution Workers VPC débloque de vastes pans de vos charges de travail actuellement enfermées au sein de clouds externes, sans vous contraindre à exposer ces ressources privées à l'Internet public pour développer sur Workers. Vous trouverez ci-dessous des exemples concrets d'applications que, d'après vos témoignages et vos retours, vous attendez avec impatience de développer sur Workers grâce à Workers VPC :
Exemple d'architecture d'application Canvas en temps réel basée sur Workers et Durable Objects accédant à une base de données privée et à un conteneur au sein d'un VPC externe.
Imaginons que vous essayez de développer une nouvelle fonctionnalité pour votre application sur Workers. Vous souhaitez également ajouter une fonctionnalité de collaboration en temps réel à celle-ci grâce à Durable Objects. Enfin, votre application devra également utiliser le service Containers, car vous devez accéder à FFmpeg pour le traitement de vidéos en direct. Dans chaque scénario, vous devez disposer d'un moyen de conserver les mises à jour d'état au sein de votre base de données traditionnelle existante et d'accéder à vos API existantes.
Alors que dans le passé, vous auriez peut-être dû développer une API distincte uniquement pour gérer les opérations de mise à jour depuis Workers et Durable Objects, vous pouvez désormais accéder directement à la base de données traditionnelle et mettre à jour les valeurs directement depuis Workers VPC.
Il en va de même pour les serveurs MCP ! Si vous développez un serveur MCP sur Workers, vous risquez d'exposer certaines fonctionnalités qui ne sont pas immédiatement disponibles sous forme d'API publiques, notamment si le délai de mise sur le marché est important. Grâce à Workers VPC, vous pouvez développer, directement au sein de votre serveur MCP, de nouvelles fonctionnalités basées sur vos API ou vos bases de données privées. Ce mode opératoire vous permet de déployer vos applications rapidement et en toute sécurité.
Exemple d'architecture de ressources cloud externes accédant aux données depuis R2, D1 et KV.
De nombreuses équipes de développement déplacent de plus en plus de données sur la plateforme pour développeurs Cloudflare, qu'il s'agisse de stocker des données d'entraînement d'IA sur R2 du fait de l'efficacité de la solution en termes de frais de trafic sortant, de données d'application dans D1 grâce au modèle de partitionnement horizontal du service ou de données de configuration dans KV pour ses performances en matière de latence en lecture au niveau mondial (qui s'élèvent à un seul chiffre, en millisecondes).
Vous devez désormais trouver un moyen d'utiliser les données d'entraînement (issues du traitement effectué dans votre cloud externe) que vous stockez dans R2 afin d'entraîner ou d'affiner vos LLM. Comme vous accédez aux données de vos utilisateurs, vous devez utiliser un réseau privé, car vos équipes de sécurité vous l'imposent. De la même manière, vous devez accéder aux données des utilisateurs et aux données de configuration dans D1 et KV afin d'effectuer certaines tâches d'administration ou d'analyse et vous devez y parvenir en évitant l'Internet public. Le service Workers VPC permet le routage direct et privé depuis votre VPC externe vers vos ressources Cloudflare, avec des noms d'hôte facilement accessibles depuis votre DNS privé automatiquement configuré.
Pour finir, prenons l'exemple d'un agent IA. Après tout, c'est la Developer Week 2025 ! Cet agent IA est basé sur Workers et s'appuie sur la génération augmentée par récupération (Retrieval Augmented Generation, RAG) pour améliorer les résultats du texte généré, tout en minimisant la fenêtre de contexte.
Vous utilisez PostgreSQL et Elasticsearch dans votre cloud externe, car c'est là que vos données résident actuellement et que vous êtes un fan de pgvector. Vous avez décidé d'utiliser Workers, car vous souhaitez bénéficier d'une mise sur le marché rapide et devez désormais accéder à votre base de données. Une fois encore, votre base de données se situe sur un réseau privé et s'avère inaccessible depuis l'Internet public.
Vous pouvez provisionner une nouvelle instance de Hyperdrive et de Cloudflare Tunnel dans un conteneur, mais comme votre VPC Workers est déjà configuré et lié, vous pouvez accéder directement à la base de données avec Workers ou Hyperdrive.
Et si vous deviez ajouter de nouveaux documents à votre espace de stockage d'objets dans votre cloud externe ? Que diriez-vous de lancer un flux de travail pour traiter le nouveau document, le fragmenter, y réaliser des incorporations (embeddings) et mettre à jour l'état de votre application en conséquence, tout en communiquant des informations en temps réel sur l'état du flux de travail à vos utilisateurs finaux ?
Dans ce cas, vous pouvez utiliser la fonctionnalité Workflows, déclenchée par une fonction serverless au sein du cloud externe. Le Workflow récupèrera alors le nouveau document dans le stockage d'objets, le traitera selon les besoins, utilisera votre fournisseur d'incorporation préféré (Workers AI ou n'importe quel autre fournisseur) pour traiter et mettre à jour les magasins de vecteurs dans Postgres, puis mettra à jour l'état de votre application.
Nous savons que ces quelques exemples de charges de travail bénéficieront de Workers VPC dès le premier jour. Nous avons hâte de voir ce que vous allez développer et sommes impatients de travailler avec vous pour faire des VPC mondiaux une réalité.
Une nouvelle ère pour les clouds privés virtuels
Nous sommes extrêmement enthousiastes à l'idée de vous permettre d'utiliser Workers VPC pour développer davantage sur Workers. Nous pensons que l'accès privé à vos API et aux bases de données situées au sein de vos réseaux privés redéfinira ce que vous pouvez développer sur Workers. Le service VPC Workers débloque l'accès à vos ressources privées afin de vous permettre de déployer des applications plus rapides et plus performantes sur Workers. Bien entendu, nous allons veiller à ce que Containers s'intègre nativement à Workers VPC.
Nous développons activement Workers VPC en nous appuyant sur les composantes primitives de connectivité réseau et les accès directs (on-ramps) que nous utilisons pour connecter les réseaux de nos clients à grande échelle. Notre objectif est de vous proposer un aperçu anticipé un peu plus tard au cours de l'année 2025.
Nous prévoyons d'aborder la connectivité de Workers vers les clouds externes en premier lieu, afin de vous permettre de moderniser davantage d'applications nécessitant un accès à vos API et vos bases de données privées depuis Workers, avant d'étendre la prise en charge des flux de trafic à directionnalité totale et de plusieurs réseaux VPC Workers. Si vous souhaitez façonner la vision de Workers VPC et que vous disposez de charges de travail emprisonnées au sein d'un cloud traditionnel, n'hésitez pas à nous faire part de votre intérêt pour la solution ici.