Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page explique comment envoyer du trafic sortant depuis un service ou une tâche Cloud Run vers un réseau VPC partagé, autorisant l'accès aux instances de VM Compute Engine, aux instances Memorystore et à toute autres ressources avec une adresse IP interne.
La connexion à un réseau VPC partagé peut être configurée de différentes manières:
Sortie VPC directe
Vous pouvez utiliser la sortie VPC directe pour envoyer du trafic vers un réseau VPC partagé sans avoir besoin de connecteurs d'accès au VPC sans serveur. Pour configurer le trafic de sortie (trafic sortant) sans connecteur, consultez Sortie VPC directe avec un réseau VPC partagé.
Connecteurs d'accès au VPC sans serveur
Si vous devez utiliser des connecteurs d'accès au VPC sans serveur, vous pouvez les configurer dans des projets de service de VPC partagé disposant de ressources Cloud Run nécessitant un accès à votre réseau. Vous pouvez également Configurez des connecteurs partagés dans le projet hôte de VPC partagé. Chaque méthode présente des avantages.
Projets de service
Avantages de la création de connecteurs dans les projets de service VPC partagé:
Isolation : chaque connecteur dispose d'une bande passante dédiée et n'est pas affecté par l'utilisation de la bande passante des connecteurs dans d'autres projets de service. Cela est utile si l'un de vos services rencontre des pics de trafic ou si vous devez vous assurer que chaque projet de service n'est pas affecté par l'utilisation de connecteurs dans d'autres projets de service.
Rejets de débit : tous les coûts liés aux connecteurs sont associés au projet de service contenant le connecteur. Cela facilite les rejets de débit.
Sécurité : permet de respecter le "principe du moindre privilège".
Les connecteurs doivent être autorisés à accéder aux ressources du réseau VPC partagé qu'ils doivent atteindre. En créant un connecteur dans le projet de service, vous pouvez limiter les accès aux services du projet à l'aide de règles de pare-feu.
Indépendance des équipes : limite la dépendance vis-à-vis de l'administrateur du projet hôte.
Les équipes peuvent créer et gérer les connecteurs associés à leur projet de service. Un utilisateur disposant du rôle Administrateur de sécurité Compute Engine ou d'un rôle Identity and Access Management (IAM) personnalisé avec l'autorisation compute.firewalls.create pour le projet hôte doit toujours gérer les règles de pare-feu du connecteur.
Avantages de la création de connecteurs dans le projet hôte de VPC partagé:
Gestion centralisée du réseau : s'aligne sur le modèle de VPC partagé qui centralise les ressources de configuration réseau dans le projet hôte.
Espace d'adressage IP : conserve une plus grande partie de votre espace d'adresses IP. Les connecteurs nécessitent une adresse IP pour chaque instance. Ainsi, le nombre de connecteurs et le nombre d'instances dans chaque connecteur est réduit et cela requiert moins d'adresses IP. C'est une bonne solution si vous craignez de manquer d'adresses IP.
Maintenance : réduit la maintenance, car chaque connecteur que vous créez peut être utilisé par plusieurs projets de service. C'est une bonne solution si vous craignez des frais de maintenance.
Coût d'inactivité : réduit le temps d'inactivité du connecteur et les coûts associés. Les connecteurs entraînent des frais même lorsqu'ils ne diffusent pas de trafic (consultez la page Tarifs). Le fait d'avoir moins de connecteurs peut réduire la quantité de ressources que vous payez lorsque vous ne diffusez pas de trafic, en fonction du type de connecteur et du nombre d'instances. Cette méthode est souvent rentable si votre cas d'utilisation implique un grand nombre de services et si ceux-ci sont rarement utilisés.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[],[],null,["# Connect to a Shared VPC network\n\nThis page describes how to send egress (outbound) traffic from a Cloud Run\nservice or job to a [Shared VPC](/vpc/docs/shared-vpc) network, allowing\naccess to Compute Engine VM instances, Memorystore instances, and any\nother resources with an internal IP address.\n\nIf your organization does not use Shared VPC, see\n[Send traffic to a standard VPC network](/run/docs/configuring/connecting-vpc).\n\nComparison of configuration methods\n-----------------------------------\n\nConnecting to a Shared VPC network can be configured in different ways:\n\n#### Direct VPC egress\n\nYou can use Direct VPC egress to send traffic to a Shared VPC network\nwithout the need for Serverless VPC Access connectors. To set up egress\n(outbound) traffic without a connector, see\n[Direct VPC egress with a Shared VPC network](/run/docs/configuring/shared-vpc-direct-vpc).\n\n#### Serverless VPC Access connectors\n\nIf you need to use Serverless VPC Access connectors, you can set them\nup in [Shared VPC](/vpc/docs/shared-vpc) service projects that have\nCloud Run resources needing access to your network, or you can\nset up shared connectors in the Shared VPC host project. There are\nadvantages to each method. \n\n### Service projects\n\nAdvantages of creating connectors in the Shared VPC service projects:\n\n- **Isolation:** Each connector has dedicated bandwidth and is unaffected by bandwidth use of connectors in other service projects. This is good if you have a service that experiences spikes in traffic or if you need to ensure that each service project is unaffected by connector use of other service projects.\n- **Chargebacks:** Charges incurred by connectors are associated with the service project containing the connector. This enables easier chargebacks.\n- **Security:** Allows you to follow the \"principle of least privilege.\" Connectors must be granted access to the resources in your Shared VPC network that they need to reach. By creating a connector in the service project, you can limit what the services in the project can access by using firewall rules.\n- **Team independence:** Reduces dependency on the host project administrator. Teams can create and manage the connectors associated with their service project. A user with the Compute Engine [Security Admin](/compute/docs/access/iam#compute.securityAdmin) role or a custom [Identity and Access Management (IAM)](/iam) role with the [`compute.firewalls.create`](/compute/docs/reference/rest/v1/firewalls/insert#iam-permissions) permission enabled for the host project must still manage firewall rules for the connector.\n\nTo set up connectors in service projects, see\n[Configure connectors in service projects](/run/docs/configuring/shared-vpc-service-projects).\n\n### Host project\n\nAdvantages of creating connectors in the Shared VPC host project:\n\n- **Centralized network management:** Aligns with the Shared VPC model of centralizing network configuration resources in the host project.\n- **IP address space:** Preserves more of your IP address space. Connectors require an IP address for each instance, so having fewer connectors, and fewer instances in each connector, uses fewer IP addresses. This is good if you are concerned about running out of IP addresses.\n- **Maintenance:** Reduces maintenance because each connector you create can be used by multiple service projects. This is good if you are concerned about maintenance overhead.\n- **Cost for idle time:** Can reduce the amount of connector idle time and associated cost. Connectors incur costs even when they are not serving traffic (see [pricing](/vpc/pricing#serverless-vpc-pricing)). Having fewer connectors can reduce the amount of resources you pay for when not serving traffic, depending on your connector type and number of instances. This is often cost-effective if your use case involves a large number of services and the services are used infrequently.\n\nTo set up connectors in the host project, see\n[Configure connectors in the host project](/run/docs/configuring/shared-vpc-host-project).\n| **Tip:** For a side-by-side comparison, see [Compare Direct VPC egress and VPC connectors](/run/docs/configuring/connecting-vpc)."]]
