Si votre organisation utilise un VPC partagé, vous pouvez connecter directement les services de l'environnement standard App Engine à votre réseau VPC partagé en utilisant l'accès au VPC sans serveur. Cela permet à un service d'environnement standard d'accéder aux ressources de votre réseau VPC partagé, par exemple des instances de VM Compute Engine, des instances Memorystore ou toute autre ressource disposant d'une adresse IP interne.
Les connecteurs d'accès au VPC sans serveur entraînent des frais mensuels. Pour en savoir plus, consultez les tarifs de l'accès au VPC sans serveur.
Si votre organisation n'utilise pas le VPC partagé, consultez la section Se connecter à un réseau VPC.
Comparaison des méthodes de configuration
Pour le VPC partagé, les connecteurs d'accès au VPC sans serveur peuvent être configurés de deux manières différentes. Vous pouvez configurer des connecteurs dans chaque projet de service disposant de ressources d'environnement standard devant accéder à votre réseau, ou configurer des connecteurs partagés dans le projet hôte. Chaque méthode présente des avantages.
Projets de service
Voici les avantages de la création de connecteurs dans les projets de service :
- 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.createpour le projet hôte doit toujours gérer les règles de pare-feu du connecteur.
Pour configurer des connecteurs dans des projets de service, consultez la section Configurer des connecteurs dans des projets de service.
Projet hôte
Avantages de la création de connecteurs dans le projet hôte :
- 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 utilise 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.
Pour configurer des connecteurs dans le projet hôte, consultez la section Configurer des connecteurs dans le projet hôte.