Le transfert de données peut correspondre au trafic entrant dans une ressource Google Cloud (par exemple, une VM), sortant d'une région Google Cloud vers Internet ou entre deux ressources Google Cloud.

Une région est un ensemble de bâtiments gérés par Google dans un emplacement géographique, comme un campus de centres de données. Le trafic peut se déplacer comme suit :

• Dans les bâtiments de l'emplacement géographique qui utilisent toujours le réseau de Google (tarifs intrazone et intra-régional)
• Vers un autre bâtiment géré par Google dans un autre emplacement qui utilise toujours le réseau de Google (tarifs interrégionaux)
• Vers un emplacement non géré par Google via une connexion Cloud Interconnect (tarifs de Cloud Interconnect)
• Vers un emplacement non géré par Google sans une connexion Cloud Interconnect (tarifs de sortie Internet)

Le niveau Premium des niveaux de service réseau utilise le réseau backbone premium de Google pour transmettre le trafic à destination ou en provenance de vos utilisateurs externes. L'Internet public n'est généralement utilisé qu'entre l'utilisateur et le point d'entrée du réseau Google le plus proche.

Le niveau Standard des niveaux de service réseau utilise l'Internet public pour transmettre le trafic entre vos services et vos utilisateurs. L'Internet public fournit une qualité de service inférieur, mais il est plus économique que le niveau Premium.

Cette section concerne le trafic qui est transmis d'une VM Google Cloud à une autre. Le coût est attribué au projet de la VM qui envoie le trafic. Ces tarifs sont applicables aux VM Compute Engine, aux nœuds Google Kubernetes Engine (GKE) et aux VM exécutant un environnement flexible App Engine.

Les tarifs suivants s'appliquent pendant et après la période d'essai gratuit de Google Cloud. Pendant cette période, les tarifs sont imputés au crédit gratuit.

Transfert de données entre des VM lorsque la VM source et la VM de destination se trouvent dans des zones différentes de la même région Google Cloud

Transfert de données entre VM lorsque les VM source et de destination se trouvent dans des régions Google Cloud différentes Tous les prix sont indiqués en USD par Gio

Cette section concerne le trafic qui est transmis d'une VM Google Cloud à un service Google. Le coût est attribué au projet de la VM qui envoie le trafic. Ces tarifs sont applicables aux VM Compute Engine, aux nœuds Google Kubernetes Engine et aux VM exécutant un environnement flexible App Engine.

Les tarifs suivants s'appliquent pendant et après la période d'essai gratuit de Google Cloud. Pendant cette période, les tarifs sont imputés au crédit gratuit.

Le niveau Premium est sélectionné par défaut pour tous les transferts de données Google Cloud. Si vous souhaitez utiliser le niveau Standard, spécifiez-le de manière explicite.

Les tarifs suivants s'appliquent pendant et après la période d'essai gratuit de Google Cloud. Pendant cette période, les tarifs sont imputés au crédit gratuit.

Important : À partir du 1er février 2024, nous allons augmenter le prix de certains SKU pour le transfert de données Internet sortant de niveau Premium. Pour en savoir plus, consultez la page Changement de tarification pour le transfert de données.

Les tarifs de sortie de données sont appliqués par Gio distribué. Ils sont basés sur la géolocalisation source du trafic. Le trafic entrant reste gratuit.Les limites d'utilisation Always Free ne s'appliquent pas au niveau Standard.

Les adresses IP internes (statiques ou éphémères) sont gratuites.

Les adresses IP externes statiques et éphémères sont facturées conformément au tableau ci-dessous.

Si vous réservez une adresse IP externe statique et que vous ne l'attribuez pas à une ressource, telle qu'une instance de VM ou une règle de transfert, elle vous est facturée à un tarif plus élevé que les adresses IP externes statiques et éphémères utilisées.

Les adresses IP externes statiques attribuées à des règles de transfert ne vous sont pas facturées.

Les plages d'adresses IPv6 externes attribuées aux sous-réseaux ou les adresses IPv6 externes attribuées aux instances de VM ne vous sont pas facturées. Les adresses IPv6 régionales statiques (bêta) ne vous sont pas facturées.

Google Cloud considère qu'une adresse IP externe statique est utilisée si elle est associée à une instance de VM, que cette instance soit en cours d'exécution ou arrêtée. Si l'instance est supprimée ou si l'adresse IP est dissociée de l'instance, Google Cloud considère l'adresse IP statique comme non utilisée.

Google Cloud considère qu'une adresse IP éphémère est utilisée uniquement si l'instance de VM associée est en cours d'exécution. Lorsque l'instance est arrêtée ou supprimée, Google Cloud libère l'adresse IP éphémère et ne la considère plus comme utilisée.

Vous pouvez vérifier si une adresse IP externe statique est utilisée en effectuant une requête gcloud compute addresses list. Cette commande renvoie une liste d'adresses IP externes statiques et leurs états :

Dans cet exemple, l'adresse IPv4 address-1 est utilisée, tandis que l'adresse IPv4 address-2 est réservée, mais n'est pas utilisée. Les deux adresses sont facturées conformément au tableau Tarifs des adresses IP externes de ce document.

Remarque : Si la même adresse IP est attribuée à plusieurs règles de transfert, Google Cloud compte et ajoute chaque utilisation de l'adresse dans le champ IN_USE_ADDRESSES au lieu d'utiliser un nombre unique d'objets d'adresses IP utilisés.

Pour en savoir plus sur les tarifs de Cloud Next Generation Firewall, consultez la page Tarifs de Cloud NGFW.

Les coûts associés à Private Service Connect varient en fonction de la configuration.

Utiliser un point de terminaison Private Service Connect (règle de transfert) pour accéder aux API Google

Utiliser un backend Private Service Connect (équilibreur de charge) pour accéder aux API Google

Les backends Private Service Connect utilisent un équilibreur de charge pour accéder aux API Google. Tous les tarifs des équilibreurs de charge s'appliquent. Le trafic vers les NEG Private Service Connect qui est acheminé vers les API Google entraîne des frais d'équilibrage de charge pour les données traitées par l'équilibreur de charge. Toutefois, Private Service Connect ne facture pas le trafic de transfert de données entre le NEG Private Service Connect et les API Google.

Pour connaître les tarifs applicables à votre équilibreur de charge, consultez les tarifs des équilibreurs de charge d'application externes globaux ou des équilibreurs de charge d'application internes.

Remarque : Les backends Private Service Connect étaient auparavant appelés points de terminaison Private Service Connect avec contrôles de service HTTP(S) client.

Remarque : Pour les points de terminaison avec accès mondial, le projet producteur de service n'est pas facturé pour les transferts de données interrégionaux, même si les ressources consommatrices de service accèdent au point de terminaison depuis d'autres régions.

Private Service Connect crée automatiquement un espace de noms Annuaire des services pour enregistrer les points de terminaison. Un seul espace de noms par défaut est utilisé pour les points de terminaison d'une même région d'un projet, sauf si vous créez explicitement des espaces de noms supplémentaires. Pour en savoir plus sur les tarifs de l'annuaire des services, consultez la page Tarifs de l'annuaire des services.

Utiliser un backend Private Service Connect (équilibreur de charge) pour accéder à un service publié

Les backends Private Service Connect utilisent un équilibreur de charge pour accéder aux services publiés. Tous les tarifs des équilibreurs de charge s'appliquent. Le trafic entre les NEG Private Service Connect et les services publiés Private Service Connect entraîne des frais d'équilibrage de charge pour les données traitées par l'équilibreur de charge et des frais Private Service Connect pour le trafic de transfert de données entre le NEG et le service publié.

Le tableau suivant récapitule les frais applicables à cette configuration.

Utiliser une interface Private Service Connect pour accéder à un réseau VPC producteur ou consommateur

Annuaire des services

Private Service Connect crée automatiquement un espace de noms de l'annuaire des services pour enregistrer les points de terminaison lorsque vous accédez aux API Google ou accédez aux services publiés. Un espace de noms Service Directory par défaut est créé pour les points de terminaison Private Service Connect dans la même région d'un projet. Pour en savoir plus sur les tarifs de l'annuaire des services, consultez la page Tarifs de l'annuaire des services.

Les clients de Private Service Connect sont facturés pour le traitement de leurs données, selon le tableau suivant. Le traitement des données des consommateurs est facturé pour les transferts entrants et sortants.

Frais liés à la publication d'un service géré à l'aide d'un rattachement de service Private Service Connect

Aucuns frais horaires ni frais de transfert de données Private Service Connect ne sont facturés pour la publication de services via des rattachements de service. Les producteurs sont facturés pour les frais d'équilibrage de charge engagés sur l'équilibreur de charge publié auprès des consommateurs.

Remarque : Si les ressources utilisent un point de terminaison avec accès global pour accéder à un service publié depuis une région différente de celle du service, le projet producteur de service n'est pas facturé pour le transfert de données interrégional. Pour en savoir plus sur les frais des projets consommateurs de services, consultez la section Utiliser un point de terminaison Private Service Connect (règle de transfert) pour accéder à un service géré publié.

Déployer un service à l'aide de cartes de connexion de service

Lorsque vous déployez un service à l'aide de mappages de connexions au service, le déploiement des mappages de connexions au service eux-mêmes n'est pas facturé au producteur. Toutefois, les éléments suivants sont facturés au consommateur :

• Ressources déployées dans le projet client via l'automatisation de la connectivité des services
• Utiliser un point de terminaison Private Service Connect pour accéder à un service publié

Lorsque vous créez une connexion d'accès aux services privés, aucuns frais horaires ni frais de données ne sont facturés pour la connexion elle-même. Cependant, les éléments suivants vous sont facturés :

• Ressources que vous provisionnez dans le réseau du producteur de services
• trafic de transfert de données de vos VM vers le réseau du producteur de service

L'accès au VPC sans serveur est facturé comme suit.

Les journaux réseau vendus génèrent des frais. Vous êtes facturé pour les produits suivants :

La quantité de données traitées par mise en miroir de paquets vous est facturée. En revanche, vous ne payez pas les règles de transfert pour la mise en miroir de paquets. Actuellement, aucuns frais supplémentaires par VM ne sont facturés pour l'utilisation de la mise en miroir de paquets. Les coûts correspondant aux données traitées par mise en miroir de paquets sont décrits dans le tableau suivant.

Les tableaux de tarification de cette section s'appliquent aux équilibreurs de charge suivants :

• Équilibreurs de charge réseau passthrough internes et externes
• Équilibreurs de charge réseau proxy internes et externes
• Équilibreurs de charge d'application externes mondiaux, classiques et régionaux

Pour les équilibreur de charge d'application internes régionaux et interrégionaux, consultez la section "Équilibreur de charge d'application interne".

Pour les règles de transfert Private Service Connect, consultez la section Private Service Connect.

Le tableau suivant indique les tarifs des règles de transfert globales. Aucuns frais de traitement des données globaux ne sont facturés. Le traitement des données est facturé par région, en fonction de l'emplacement où le trafic est traité.

Le tableau suivant indique les frais applicables aux règles de transfert régionales, ainsi que les frais de traitement des données entrantes et sortantes par région.

Les utilisateurs d'un équilibreur de charge d'application externe global peuvent utiliser Google Cloud Armor, Cloud CDN ou les deux pour minimiser l'impact des frais de traitement des données sortantes.

• Cloud CDN : les objets statiques diffusés au client à partir du cache ne passent pas par l'équilibreur de charge. Une stratégie de mise en cache efficace réduit la quantité de données sortantes traitées par l'équilibreur de charge et réduire vos coûts. Pour implémenter le cache, vous devez comprendre quelle partie de votre trafic est statique et peut être mise en cache. Pour en savoir plus, consultez la documentation Cloud CDN.
• Cloud Armor : si votre application reçoit une quantité importante de trafic indésirable, vous pouvez déployer Cloud Armor pour le bloquer. Les requêtes bloquées par Cloud Armor ne transitent pas par l'équilibreur de charge, ce qui réduit efficacement la quantité de données sortantes traitées par l'équilibreur de charge. L'impact sur vos coûts dépend du pourcentage de trafic indésirable bloqué par les stratégies de sécurité Cloud Armor que vous avez mises en œuvre.

Si votre application peut fonctionner dans une seule région ou doit fonctionner dans une seule région, vous pouvez utiliser l'équilibreur de charge d'application externe régional. L'équilibreur de charge d'application externe régional n'utilise que le niveau de réseau Standard, qui présente l'avantage d'être moins onéreux en termes de frais de transfert de données sortants.

Si vous utilisez des backends NEG sans serveur avec un équilibreur de charge d'application externe (mondial, régional ou classique), les frais d'équilibrage de charge existants s'appliqueront en plus des frais de calcul sans serveur pour les backends Cloud Run, Cloud Functions ou App Engine, le cas échéant. Si Google Cloud Armor ou Cloud CDN est utilisé, les frais correspondants seront également appliqués.

Toutefois, vous ne serez pas facturé pour les transferts de données sortants sans serveur. Seuls les tarifs de transfert de données sortantes Internet s'appliquent. Les frais de transfert de données sortant des fonctions Cloud Run, les frais de trafic réseau sortant d'App Engine et les frais de transfert de données de Cloud Run ne s'appliquent pas aux requêtes envoyées depuis un équilibreur de charge d'application externe (via des NEG sans serveur) vers un service Cloud Run, App Engine ou Cloud Run.

Passez en revue les points suivants pour comprendre comment les projets et les comptes de facturation sont facturés pour les SKU de mise en réseau lorsque vous utilisez le référencement de service interprojet.

• Les frais liés à Cloud Load Balancing sont toujours attribués au projet dans lequel la règle de transfert est configurée (projet de service A dans la figure 1). Cela inclut les frais pour les règles de transfert, les données entrantes traitées et les données sortantes traitées par l'équilibreur de charge d'application externe global. Consultez les principaux éléments des tarifs de Cloud Load Balancing.
• Les transferts de données Internet en sortie pour les niveaux Premium et Standard sont toujours attribués au projet dans lequel la règle de transfert est configurée (projet de service A dans la figure 1). Consultez les tarifs du transfert de données sur le réseau.
• Si vous configurez Cloud CDN sur un service de backend référencé par un mappage d'URL à l'aide du référencement de service interprojet, tous les frais Cloud CDN pour le contenu pouvant être mis en cache (transfert de données vers l'extérieur du cache, recherche dans le cache, remplissage du cache) sont toujours attribués au projet qui contient le service de backend activé pour Cloud CDN (projet de service B dans la figure 1), et non au projet qui a configuré les règles de transfert. Consultez les tarifs de Cloud CDN.
• Si vous configurez Google Cloud Armor sur un service de backend référencé par un mappage d'URL à l'aide du référencement de service interprojet, tous les frais liés à Google Cloud Armor sont attribués au projet qui contient le service de backend activé pour Google Cloud Armor (projet de service B dans la figure 1), et non au projet qui a configuré les règles de transfert. Consultez les Tarifs de Google Cloud Armor. Plus précisément, tous les frais Google Cloud Armor Standard Tier et Cloud Armor Enterprise Tier sont attribués au projet de service B.

Les points supplémentaires suivants s'appliquent également lorsque vous utilisez Cloud Armor avec le référencement de service interprojet :

• Les modifications d'abonnement liées à Cloud Armor Enterprise sont attribuées au compte de facturation que vous avez spécifié lors de l'inscription. Si vous souhaitez utiliser le même abonnement Cloud Armor Enterprise pour plusieurs projets afin d'inclure tous les services de backend référencés à l'aide du référencement de services interprojets, assurez-vous d'inclure tous les projets de service pertinents dans le même compte de facturation Cloud Armor Enterprise.
• Lorsque vous utilisez le référencement de service interprojet, certaines fonctionnalités proposées dans Cloud Armor Enterprise, telles que la télémétrie DDoS et la réponse DDoS, nécessitent l'enregistrement au niveau Cloud Armor Enterprise pour le projet de règle de transfert de frontend et les projets de service de backend.

Google Cloud facture les règles de transfert, qu'elles soient créées pour l'équilibrage de charge ou pour d'autres utilisations, telles que la mise en miroir de paquets.

Dans les exemples suivants, les tarifs sont indiqués en USD :

Vous pouvez créer jusqu'à cinq règles de transfert au prix de 0,025 $/heure. Par exemple, si vous créez une règle de transfert, vous payez 0,025 $/heure. Si vous créez trois règles de transfert, vous payez toujours 0,025 $/heure. Toutefois, si vous créez 10 règles de transfert, leur coût est calculé comme suit :

• 5 règles de transfert = 0,025 $/heure
• Chaque règle de transfert supplémentaire = 0,01 $/heure

0,025 $/heure pour 5 règles + (5 règles supplémentaires x 0,01 $/heure) = 0,075 $/heure

Pour la plupart des cas d'utilisation de l'équilibrage de charge, vous n'avez besoin que d'une règle de transfert par équilibreur de charge.

Les règles de transfert globales et les règles de transfert régionales sont facturées séparément et par projet dans Google Cloud. Par exemple, si vous utilisez une règle de transfert globale et une règle de transfert régionale dans deux projets distincts (soit quatre règles au total), vous payez 0,10 $/heure (4 x 0,025 $/heure).

Pour estimer les frais du service d'équilibrage de charge, procédez comme suit :

1. Accédez au simulateur de coût.
2. Cliquez sur l'onglet Cloud Load Balancing.
3. Sélectionnez une région dans le menu déroulant.
4. Indiquez le nombre estimé de règles de transfert.
5. Saisissez le montant estimé pour le trafic réseau traité par mois.

Exemple :

• Iowa
• Nombre de règles de transfert : 10
• Données entrantes traitées par l'équilibreur de charge : 2 048 Go
• Coût total estimé : 71,13 $ pour un mois

Le coût de transfert de données Internet sortant pour l'envoi des réponses depuis les backends n'est pas inclus dans cet exemple.

Les frais suivants s'appliquent aux équilibreurs de charge d'application internes régionaux et interrégionaux. Des frais de transfert de données interrégional supplémentaires s'appliquent également à l'équilibreur de charge d'application interne interrégional.

Les équilibreurs de charge basés sur Envoy évoluent automatiquement le nombre de proxys disponibles pour gérer votre trafic en fonction de vos besoins en termes de trafic. Les frais d'instances de proxy sont basés sur le nombre d'instances de proxy nécessaires pour répondre à vos besoins en termes de trafic. Chaque proxy supplémentaire entraîne des frais horaires supplémentaires selon les tarifs indiqués dans la grille tarifaire.

Le nombre de proxys alloués à votre équilibreur de charge est calculé en fonction de la capacité mesurée nécessaire pour gérer votre trafic sur une période de 10 minutes. Durant cette période, nous observons la plus haute valeur enregistrée pour :

• Le nombre de proxys nécessaires pour répondre aux besoins en bande passante de votre trafic. Chaque instance de proxy peut gérer jusqu'à 18 Mo par seconde. Nous surveillons la bande passante totale nécessaire et divisons ce total par la bande passante que peut gérer une instance de proxy.
• Le nombre de proxys nécessaires pour gérer les connexions et les requêtes. Nous comptons le total de chacune des ressources suivantes et divisons cette valeur par ce que peut gérer une instance de proxy :
• 600 nouvelles connexions HTTP ou 150 nouvelles connexions HTTPS par seconde
• 3 000 connexions actives
• 1 400 requêtes par seconde*

* Une instance de proxy peut gérer 1 400 requêtes par seconde si Cloud Logging est désactivé. Si vous activez Logging, votre instance de proxy ne peut pas gérer autant de requêtes par seconde. Par exemple, la journalisation de l'intégralité des requêtes réduit la capacité de gestion des requêtes du proxy à 700 requêtes par seconde. Vous pouvez configurer Logging de manière à échantillonner un pourcentage inférieur du trafic. Cela vous permet de répondre à vos besoins d'observabilité tout en contrôlant vos coûts.

Sur une période de 10 minutes, 180 Mo par seconde de données passent par l'équilibreur de charge.180 Mo par seconde / 18 Mo par seconde et par instance de proxy = 10 instances de proxy

Sur cette même période, 300 nouvelles connexions HTTPS sont établies toutes les secondes, 3 000 connexions sont actives et 2 800 requêtes sont envoyées par seconde :

300 nouvelles connexions HTTPS par seconde / 150 nouvelles connexions HTTPS par seconde et par instance de proxy = 2 instances de proxy ; 3 000 connexions actives / 3 000 connexions actives par instance de proxy = 1 instance de proxy ; 2 800 requêtes par seconde / 1 400 requêtes par seconde et par instance de proxy = 2 instances de proxy.

Cela implique un total de 5 instances de proxy. Ce nombre est inférieur aux 10 instances de proxy nécessaires pour gérer la bande passante. Par conséquent, les frais d'instances de proxy pour cette période de 10 minutes seraient calculés comme suit :

10 instances de proxy * 0,025 $ par instance de proxy et par heure * (10 minutes / (60 minutes par heure)) = 0,0417 $.

La facturation est calculée en fonction de la capacité mesurée nécessaire pour répondre à vos besoins en termes de trafic, et non du nombre d'instances de proxy qui établissent des connexions avec vos backends. Vous pouvez donc être facturé pour un nombre d'instances de proxy différent de celui affiché dans votre infrastructure.

Pour assurer des performances et une fiabilité optimales, chaque équilibreur de charge se voit attribuer au moins trois instances de proxy dans la région Google Cloud où l'équilibreur de charge est déployé. Ces instances de proxy sont attribuées même si l'équilibreur de charge ne gère aucun trafic. Après avoir déployé une règle de transfert (avec un schéma d'équilibrage de charge INTERNAL_MANAGED), des frais d'instances de proxy commencent à vous être facturés. Toute règle de transfert supplémentaire entraîne des frais d'instance de proxy, tel que décrit précédemment (en d'autres termes, trois instances de proxy supplémentaires par règle de transfert).

Des frais horaires minimaux d'instances de proxy s'appliquent aux trois instances de proxy attribuées à votre équilibreur de charge. Par exemple, pour la région Google Cloud us-central1, les frais minimaux sont calculés comme suit :

3 instances de proxy * 0,025 $ par proxy et par heure = 0,075 $par heure.

Comme indiqué précédemment, ces instances de proxy peuvent chacune gérer un certain volume de trafic. Dès que vos besoins en termes de trafic dépasseront la capacité de ces trois instances de proxy, vous serez facturé pour les instances de proxy nécessaires pour gérer tout trafic supplémentaire.

Les frais de traitement des données sont calculés en mesurant le volume total de données pour les requêtes et les réponses traitées par votre équilibreur de charge durant le cycle de facturation. Ces frais varient en fonction de votre utilisation, et il n'y a pas de montant minimal.

Des frais de transfert de données interrégionaux s'appliquent si vous utilisez un équilibreur de charge d'application interne interrégional. Par exemple, si vous avez un déploiement d'équilibreur de charge d'application interne interrégional dans lequel le client, le proxy Envoy et le backend se trouvent dans des régions distinctes, vous verrez les frais de transfert de données interrégionaux pour chaque saut séparément (client <-> proxy Envoy et proxy Envoy <-> backend). Pour réduire ces frais de transfert de données interrégionaux, vous pouvez déployer des proxies Envoy dans plusieurs régions.

Pour le traitement des données, l'utilisation horaire de l'instance de proxy et le transfert de données interzones des VM, c'est le projet de règle de transfert qui est facturé.

Si vous utilisez des backends NEG sans serveur pour un équilibreur de charge d'application interne, des frais d'équilibrage de charge d'application interne seront appliqués en plus des frais de calcul sans serveur pour Cloud Run.

Les NEG Internet régionaux nécessitent l'utilisation d'une passerelle Cloud NAT, ce qui entraîne des frais supplémentaires. Vous serez facturé pour le transfert de données Internet et l'utilisation de Cloud NAT pour tout trafic envoyé vers et depuis le sous-réseau proxy uniquement d'Envoy, ainsi que pour le trafic de vérification de l'état. Toutefois, les frais liés à l'équilibreur de charge ne s'appliquent qu'au trafic de requêtes des utilisateurs.

Les passerelles Cloud NAT allouées à Cloud Load Balancing entraînent des frais horaires équivalents à ceux d'un réseau comportant plus de 32 instances de VM. Pour en savoir plus, consultez la page Tarifs de Cloud NAT.

Les règles d'autorisation sont disponibles sans frais d'utilisation pendant toute la durée de la version Preview.

Si une stratégie Cloud Armor est associée à un service de backend, vous pouvez utiliser la fonctionnalité d'en-têtes personnalisés avec ce service de backend, sans frais supplémentaires.

Si aucune stratégie Cloud Armor n'est associée au service de backend qui utilise la fonctionnalité d'en-têtes de requête personnalisés, les frais appliqués sont les suivants : 0,75 $pour 1 000 000 de requêtes HTTP(S) par mois et par compte. Vous êtes facturé uniquement pour les 666 666 667 premières requêtes par mois et par compte.

L'accès mondial permet aux instances clientes de n'importe quelle région d'accéder à votre équilibreur de charge interne. Si l'accès mondial est activé pour une règle de transfert, des frais de transfert de données interrégional supplémentaires sont facturés lorsque le trafic est envoyé vers ou depuis un client situé dans une région différente de celle de l'équilibreur de charge.

L'accès mondial est généralement disponible pour les équilibreurs de charge réseau passthrough internes, les équilibreurs de charge d'application internes régionaux et les équilibreurs de charge réseau proxy internes régionaux.

Le transfert de protocole est facturé au même tarif que l'équilibrage de charge. Des frais s'appliquent à la règle de transfert ainsi qu'aux données entrantes traitées par l'instance cible.

Les certificats SSL autogérés et gérés par Google sont gratuits.