La transferencia de datos puede ser tráfico que ingresa a un recurso de Google Cloud (p.ej., una VM), que sale de una región de Google Cloud hacia Internet o que se encuentra entre dos recursos dentro de Google Cloud.

Una región es un conjunto de edificios operados por Google en una ubicación geográfica, como un campus de centro de datos. El tráfico puede viajar de la siguiente manera:

• Dentro del conjunto de edificios en la ubicación, que siempre usó la red de Google (precios dentro de la zona y dentro de la región)
• A otro edificio operado por Google en otra ubicación, que siempre utilizó la red de Google (precios entre regiones)
• A una ubicación que Google no opera mediante una conexión de Cloud Interconnect (precios de Cloud Interconnect)
• A una ubicación que Google no opera no a través de una conexión de Cloud Interconnect (precios de transferencia de datos de salida de Internet)

El nivel Premium de los Niveles de servicio de red aprovecha la red troncal premium de Google para transportar el tráfico desde y hacia los usuarios externos. Por lo general, la Internet pública solo se utiliza entre el usuario y el punto de entrada de red más cercano de Google.

El nivel Estándar de los Niveles de servicio de red aprovecha la Internet pública para transportar el tráfico entre los servicios y los usuarios. Si bien el uso de la Internet pública brinda una menor calidad de servicio, es más económica que el nivel Premium.

En esta sección, se incluye el tráfico que sale de una VM de Google Cloud y se transfiere a otra VM de Google Cloud. El costo se atribuye al proyecto de la VM que envía el tráfico. Estos precios afectan las VM de Compute Engine, los nodos de Google Kubernetes Engine (GKE) y las VM que ejecutan el entorno flexible de App Engine.

Se aplican los siguientes precios durante y después del período de Prueba gratuita de Google Cloud. Durante este período, los precios se cobran en el importe del crédito de la prueba.

Transferencia de datos de VM a VM cuando la VM de origen y la de destino están en zonas diferentes de la misma región de Google Cloud

Transferencia de datos de VM a VM cuando las VMs de origen y destino están en diferentes regiones de Google Cloud. Todos los precios son por GiB en USD

En esta sección, se incluye el tráfico que sale de una VM de Google Cloud y se transfiere a un servicio de Google. El costo se atribuye al proyecto de la VM que envía el tráfico. Estos precios afectan las VM de Compute Engine, los nodos de Google Kubernetes Engine y las VM que ejecutan el entorno flexible de App Engine.

Se aplican los siguientes precios durante y después del período de Prueba gratuita de Google Cloud. Durante este período, los precios se cobran en el importe del crédito de la prueba.

El nivel Premium es el nivel predeterminado para todas las transferencias de datos de Google Cloud. Para usar el nivel Estándar, debes especificarlo de forma explícita.

Se aplican los siguientes precios durante y después del período de Prueba gratuita de Google Cloud. Durante este período, los precios se cobran en el importe del crédito de la prueba.

Importante: A partir del 1 de febrero de 2024, aumentaremos el precio de algunos SKU para la transferencia de datos de salida de Internet de nivel Premium. Para obtener más información, consulta Anuncio sobre el cambio de precios para la transferencia de datos.

El precio de transferencia de datos de salida es por GiB entregado. Los precios se basan en la ubicación geográfica de origen del tráfico. Todavía no se aplican cargos por la entrada.Los límites de uso del nivel Siempre gratuito no se aplican al nivel Estándar.

No se aplican cargos por las direcciones IP internas estáticas o efímeras.

Las direcciones IP externas estáticas y efímeras se cobran en función de la siguiente tabla.

Si reservas una dirección IP externa estática y no la asignas a un recurso, como una instancia de VM o una regla de reenvío, se te cobrará una tarifa más alta que por las otras direcciones IP externas estáticas y efímeras que estén en uso.

No se te cobra por las direcciones IP externas estáticas que se asignen a reglas de reenvío.

No se te cobra por los rangos de direcciones IPv6 externas que sean asignadas a subredes o direcciones IPv6 externas que sean asignadas a instancias de VM. No se te cobra por las direcciones IPv6 regionales estáticas (vista previa).

Google Cloud considera que una dirección IP externa estática está en uso si está asociada a una instancia de VM, ya sea que la instancia esté en ejecución o detenida. Si se borra la instancia o si se desvincula la dirección IP de la instancia, Google Cloud considera que la dirección IP estática no está en uso.

En el caso de una dirección IP efímera, Google Cloud considera que la dirección está en uso solo si la instancia de VM asociada está en ejecución. Cuando la instancia se detiene o se borra, Google Cloud libera la dirección IP efímera y ya no la considera en uso.

Puedes verificar si una dirección IP externa estática se encuentra en uso mediante una solicitud gcloud compute addresses list. Mediante este comando, se muestra una lista de direcciones IP externas estáticas y sus estados:

En este ejemplo, la dirección IPv4 address-1 está en uso, mientras que la dirección IPv4 address-2 está reservada, pero no se encuentra en uso. Ambas direcciones se cobran en función de la tabla de precios de direcciones IP externas de este documento.

Nota: Si se asigna la misma dirección IP a más de una regla de reenvío, Google Cloud cuenta y agrega cada uso de la dirección hacia la cuota IN_USE_ADDRESSES en lugar de realizar un recuento único de los objetos de dirección IP que se usan.

Para obtener los precios de Cloud Next Generation Firewall, consulta la página de precios de Cloud NGFW.

Los costos asociados a Private Service Connect varían según la configuración.

Usa un extremo de Private Service Connect (regla de reenvío) para acceder a las API de Google

Usa un backend de Private Service Connect (balanceador de cargas) para acceder a las APIs de Google

Los backends de Private Service Connect usan un balanceador de cargas para acceder a las APIs de Google. Se aplican todos los precios del balanceador de cargas. El tráfico a los NEG de Private Service Connect que se dirige a las APIs de Google genera cargos de balanceo de cargas por los datos procesados por el balanceador de cargas. Sin embargo, no hay cargos de Private Service Connect por el tráfico de transferencia de datos entre el NEG de Private Service Connect y las APIs de Google.

Para obtener información sobre los precios de tu balanceador de cargas, consulta los precios de los balanceadores de cargas de aplicaciones externos globales o los balanceadores de cargas de aplicaciones internos.

Nota: Antes, los backends de Private Service Connect se denominaban extremos de Private Service Connect con controles de servicio de HTTP(S) de consumidor.

Nota: Para los extremos con acceso global, no se cobra la transferencia de datos interregional al proyecto del productor de servicios, incluso si los recursos del consumidor de servicios acceden al extremo desde otras regiones.

Private Service Connect crea automáticamente un espacio de nombres del Directorio de servicios para registrar extremos. Se usa un único espacio de nombres predeterminado para los extremos en la misma región de un proyecto, a menos que crees explícitamente espacios de nombres adicionales. Para obtener más información sobre los precios del Directorio de servicios, consulta Precios del Directorio de servicios.

Usa un backend de Private Service Connect (balanceador de cargas) para acceder a un servicio publicado

Los backends de Private Service Connect usan un balanceador de cargas para acceder a los servicios publicados. Se aplican todos los precios del balanceador de cargas. El tráfico entre los NEG de Private Service Connect y los servicios publicados de Private Service Connect genera cargos de balanceo de cargas por datos procesados por el balanceador de cargas y cargos de Private Service Connect por el tráfico de transferencia de datos entre el NEG y el servicio publicado.

En la siguiente tabla, se resumen los cargos aplicables para esta configuración.

Usar una interfaz de Private Service Connect para acceder a una red de VPC de productor o consumidor

Directorio de servicios

Private Service Connect crea automáticamente un espacio de nombres del Directorio de servicios para registrar extremos cuando accedes a las APIs de Google o cuando accedes a servicios publicados. Se crea un espacio de nombres del Directorio de servicios predeterminado único para los extremos de Private Service Connect en la misma región de un proyecto. Para obtener más información sobre los precios del Directorio de servicios, consulta Precios del Directorio de servicios.

A los consumidores de Private Service Connect se les cobra el procesamiento de datos del consumidor según la siguiente tabla. El procesamiento de datos de consumidores se cobra de forma entrante y saliente.

Cargos para publicar un servicio administrado a través de un adjunto de servicio de Private Service Connect

No hay cargos por hora ni por transferencia de datos de Private Service Connect para publicar servicios a través de adjuntos de servicio. A los productores se les cobra por cualquier cargo de balanceo de cargas que se genere en el balanceador de cargas que se publica para los consumidores.

Nota: Si los recursos usan un extremo con acceso global para acceder a un servicio publicado desde una región diferente a la del servicio, no se cobra la transferencia de datos interregional al proyecto del productor de servicios. Para obtener información sobre los cargos del proyecto del consumidor del servicio, consulta Usa un extremo de Private Service Connect (regla de reenvío) para acceder a un servicio administrado publicado.

Implementa un servicio con mapas de conexión de servicios

Cuando implementas un servicio con mapas de conexión de servicios, no hay cargos de productor por implementar los mapas de conexión de servicios en sí. Sin embargo, se le cobra al consumidor por lo siguiente:

• Recursos que se implementan en el proyecto del consumidor a través de la automatización de la conectividad de servicios
• Usa un extremo de Private Service Connect para acceder a un servicio publicado.

Cuando creas una conexión de acceso privado a servicios, no hay cargos por hora ni por datos para la conexión en sí. Sin embargo, se te cobrará por lo siguiente:

• Recursos que aprovisionas en la red del productor de servicios
• Tráfico de transferencia de datos de tus VMs a la red del productor de servicios

El acceso a VPC sin servidores tiene los siguientes precios.

Los registros de terceros de red generan cargos. Se cobran los siguientes productos:

Se te cobrará según la cantidad de datos que se procesen mediante la duplicación de paquetes. No se te cobrarán las reglas de reenvío de la duplicación de paquetes. En la actualidad, no hay un costo adicional por VM por usar la Duplicación de paquetes. En la siguiente tabla, se indican los costos de los datos procesados mediante la duplicación de paquetes.

Las tablas de precios de esta sección se aplican a los siguientes balanceadores de cargas:

• Balanceadores de cargas de red de transferencia internos y externos
• Balanceadores de cargas de red del proxy interno y externo
• Balanceadores de cargas de aplicaciones externos globales, clásicos y regionales

Para los balanceadores de cargas de aplicaciones internos regionales y entre regiones, consulta la sección Balanceador de cargas de aplicaciones interno.

Para ver las reglas de reenvío de Private Service Connect, consulta la sección de Private Service Connect.

En la siguiente tabla, se muestran los precios de las reglas de reenvío globales. No hay cargos globales por el procesamiento de datos. El procesamiento de datos se cobra por región, según dónde se procese el tráfico.

En la siguiente tabla, se muestran los cargos por reglas de reenvío regionales y los cargos por procesamiento de datos entrantes y salientes por región.

Los usuarios del balanceador de cargas de aplicaciones externo global pueden usar Google Cloud Armor, Cloud CDN o ambos para minimizar el impacto de los cargos de procesamiento de datos salientes.

• Cloud CDN: Los objetos estáticos que se entregan al cliente desde la caché no pasan a través del balanceador de cargas. Una estrategia eficaz de almacenamiento en caché puede reducir la cantidad de datos salientes que procesa el balanceador de cargas y disminuir tus costos. Para implementar el almacenamiento en caché, es necesario comprender qué parte de tu tráfico es estática y se puede almacenar en caché. Para obtener más información, consulta la documentación de Cloud CDN.
• Cloud Armor: Si tu aplicación recibe una cantidad significativa de tráfico no deseado, puedes implementar Cloud Armor para bloquearlo. Las solicitudes que bloquea Cloud Armor no pasan a través del balanceador de cargas, lo que reduce de forma eficaz la cantidad de datos salientes que procesa el balanceador de cargas. El impacto en tus costos depende del porcentaje de tráfico no deseado que bloquean las políticas de seguridad de Cloud Armor que implementaste.

Si tu aplicación puede operar en una sola región o se requiere que opere en una sola región, puedes usar el balanceador de cargas de aplicaciones externo regional. El balanceador de cargas de aplicaciones externo regional solo usa el nivel de red Estándar, que tiene tarifas de transferencia de datos saliente más bajas por lo que es una opción rentable.

Si estás usando backends de NEG sin servidores con un balanceador de cargas de aplicaciones externo (global, regional o clásico), se aplicarán los cargos existentes del balanceador de cargas, además de los cargos de computación sin servidores para Cloud Run, Cloud Run Functions o backends de App Engine, según corresponda. Si se utiliza Google Cloud Armor o Cloud CDN, también se aplican los cargos respectivos.

Sin embargo, no se te cobrará la transferencia de datos saliente sin servidores. Solo se aplican las tarifas de transferencia de datos saliente de Internet. No se aplican cargos por la transferencia de datos saliente de Cloud Run Functions, cargos por el tráfico de red saliente de App Engine ni cargos por transferencia de datos de Cloud Run a las solicitudes que se pasan de un balanceador de cargas de aplicaciones externo (con NEG sin servidores) a un servicio de Cloud Run Functions, App Engine o Cloud Run.

Revisa los siguientes puntos para comprender cómo se les cobra a los proyectos y las cuentas de facturación por los SKU de herramientas de redes cuando usas la referencia de servicio entre proyectos.

• Los cargos relacionados con Cloud Load Balancing siempre se atribuyen al proyecto en el que se configura la regla de reenvío (proyecto de servicio A en la figura 1). Esto incluye los cargos por las reglas de reenvío, los datos entrantes procesados y los datos salientes procesados por el balanceador de cargas de aplicaciones externo global. Revisa los conceptos básicos de los precios de Cloud Load Balancing.
• La transferencia de datos externa de Internet de red para el nivel Premium y el nivel Estándar siempre se atribuye al proyecto en el que se configura la regla de reenvío (proyecto de servicio A en la figura 1). Revisa los precios de la transferencia de datos de red.
• Si configuras Cloud CDN en un servicio de backend al que hace referencia un mapa de URL con la referencia de servicio entre proyectos, todos los cargos de Cloud CDN por contenido almacenable en caché (transferencia de datos externa de caché, búsqueda de caché, llenado de caché) siempre se atribuyen al proyecto que contiene el servicio de backend habilitado para Cloud CDN (proyecto de servicio B en la figura 1), y no al proyecto que configuró las reglas de reenvío. Revisa los precios de Cloud CDN.
• Si configuras Google Cloud Armor en un servicio de backend al que hace referencia un mapa de URL con la referencia de servicio entre proyectos, todos los cargos relacionados con Google Cloud Armor se atribuyen al proyecto que contiene el servicio de backend habilitado para Google Cloud Armor (proyecto de servicio B en la figura 1), y no al proyecto que configuró las reglas de reenvío. Revisa los precios de Google Cloud Armor. Específicamente, todos los cargos del nivel Estándar de Google Cloud Armor y del nivel Enterprise de Cloud Armor se atribuyen al proyecto del servicio B.

Las siguientes consideraciones adicionales también se aplican cuando usas Cloud Armor con la referencia del servicio entre proyectos:

• Los cambios en la suscripción relacionados con Cloud Armor Enterprise se atribuyen a la cuenta de facturación que especificaste durante la inscripción. Si quieres usar la misma suscripción a Cloud Armor Enterprise en varios proyectos para incluir todos los servicios de backend a los que se hace referencia con la referencia del servicio entre proyectos, asegúrate de incluir todos los proyectos de servicios relevantes como parte de la misma cuenta de facturación de Cloud Armor Enterprise
• Cuando usas la referencia del servicio entre proyectos, algunas funciones que se ofrecen en Cloud Armor Enterprise, como la telemetría de DDoS y la respuesta ante DDoS, requieren la inscripción en el nivel Enterprise de Cloud Armor tanto para el proyecto de la regla de reenvío de frontend como para los proyectos de servicio de backend.

Google Cloud cobra por las reglas de reenvío, sin importar si se crean para el balanceo de cargas o para otros usos, como la duplicación de paquetes.

Los ejemplos siguientes usan precios de EE.UU.:

Puedes crear hasta 5 reglas de reenvío al precio de $0.025 por hora. Por ejemplo, si creas una regla de reenvío, se te cobra $0.025 por hora. Si tienes 3 reglas de reenvío, también se te cobra $0.025 por hora. Sin embargo, si tienes 10 reglas de reenvío, se te cobra de la siguiente manera:

• 5 reglas de reenvío = $0.025 por hora
• Cada regla de reenvío adicional = $0.01 por hora

$0.025 por hora por 5 reglas + (5 reglas adicionales * $0.01 por hora) = $0.075 por hora

Solo necesitarás una regla de reenvío por balanceador de cargas para la mayoría de los casos prácticos de balanceo de cargas.

Google Cloud cobra por las reglas de reenvío globales y regionales por separado y, también, por proyecto. Por ejemplo, se te cobrará $0.10 por hora (4 x $0.025 por hora) si usas una regla de reenvío global y una regional en dos proyectos distintos (cuatro reglas en total).

Sigue estos pasos para calcular los cargos por balanceo de cargas:

1. Ir a la calculadora de precios
2. En la pestaña Cloud Load Balancing.
3. Selecciona una región del menú desplegable.
4. Ingresa la cantidad estimada de reglas de reenvío.
5. Ingresa la cantidad mensual estimada de tráfico de red que se procesará.

Por ejemplo:

• Iowa
• Cantidad de reglas de reenvío: 10
• Datos de entrada procesados por el balanceador de cargas: 2,048 GiB
• Costo total estimado: $71.13 por 1 mes

En este ejemplo, no se incluye el costo de transferencia de datos externa de Internet que se cobra por enviar respuestas desde los backends.

Los siguientes cargos se aplican tanto a los balanceadores de cargas de aplicaciones internos regionales como a los balanceadores de cargas de aplicaciones internos entre regiones. Algunos cargos de transferencia de datos entre regiones adicionales también se aplican al balanceador de cargas de aplicaciones interno entre regiones.

Los balanceadores de cargas basados en Envoy escalan automáticamente la cantidad de proxies disponibles para administrar el tráfico según tus necesidades de tráfico. El cargo de instancia del proxy se basa en la cantidad de instancias de proxy necesarias para satisfacer tus necesidades de tráfico. Cada proxy adicional genera un cargo adicional por hora de acuerdo con los precios indicados en la tabla de precios.

La cantidad de proxies asignados a tu balanceador de cargas se calcula según la capacidad medida necesaria para administrar el tráfico durante un período de 10 minutos. Durante este período, observamos el valor más alto que se obtiene en los siguientes supuestos:

• La cantidad de proxies necesarios para ofrecer un servicio que se adapte a las necesidades de ancho de banda del tráfico. Cada instancia de proxy puede administrar hasta 18 MB por segundo. Supervisamos el ancho de banda total necesario y dividimos ese total por el ancho de banda que una instancia de proxy puede admitir.
• La cantidad de proxies necesarios para administrar las conexiones y las solicitudes. Contamos la cantidad total de cada uno de los siguientes recursos y dividimos cada valor por lo que una instancia de proxy puede administrar:
• 600 (HTTP) o 150 (HTTPS) conexiones nuevas por segundo
• 3,000 conexiones activas
• 1,400 solicitudes por segundo*

* Una instancia de proxy puede administrar 1,400 solicitudes por segundo si Cloud Logging está inhabilitado. Si habilitas Logging, la instancia de proxy puede administrar menos solicitudes por segundo. Por ejemplo: registrar el 100% de las solicitudes disminuye la capacidad de control de solicitudes del proxy a 700 solicitudes por segundo. Puedes configurar Logging para realizar muestras de un porcentaje menor de tráfico. Esto te permite satisfacer tus necesidades de observabilidad mientras controlas los costos.

En un período de 10 minutos, 180 MB por segundo de datos pasan por el balanceador de cargas. 180 MB por segundo / 18 MB por segundo por instancia de proxy = 10 instancias de proxy

Durante este mismo período, se establecen 300 conexiones HTTPS nuevas por segundo, 3,000 conexiones están activas y se envían 2,800 solicitudes por segundo:

300 conexiones HTTPS nuevas por segundo / 150 conexiones HTTPS nuevas por segundo por instancia de proxy = 2 instancias de proxy 3,000 conexiones activas / 3,000 conexiones activas por instancia de proxy = 1 instancia de proxy 2,800 solicitudes por segundo / 1,400 solicitudes por segundo por instancia de proxy = 2 instancias de proxy.

Esto suma hasta 5 instancias de proxy. Esta cantidad es menor que las 10 instancias de proxy necesarias para entregar el ancho de banda. Por lo tanto, el cargo de instancia de proxy para este período de 10 minutos se calcularía de la siguiente manera:

10 instancias de proxy * $0.025 por instancia de proxy por hora * (10 minutos / (60 minutos por hora)) = $0.0417.

La facturación se calcula según la capacidad medida necesaria para satisfacer tus necesidades de tráfico y no según la cantidad de instancias de proxy que establecen conexiones con los backends. Por lo tanto, es posible que se te facture por una cantidad diferente de instancias de proxy de la que se ve en tu infraestructura.

Para asegurar un rendimiento y una confiabilidad óptimos, cada balanceador de cargas se asigna a un mínimo de tres instancias de proxy en la región de Google Cloud donde se implementa el balanceador de cargas. Estas instancias de proxy se asignan incluso si el balanceador de cargas no controla tráfico. Después de que se implementa una regla de reenvío (con esquema de balanceo de cargas INTERNAL_MANAGED) en tu proyecto, comienzas a acumular cargos por instancia de proxy. Las reglas de reenvío adicionales generan cargos adicionales por instancia de proxy como se describió antes (en otras palabras, tres instancias de proxy adicionales por regla de reenvío).

Las tres instancias de proxy que se asignan a tu balanceador de cargas dan como resultado un cargo por hora mínimo por instancia de proxy. Por ejemplo, para la región de us-central1 de Google Cloud, el cargo mínimo se calcula de la siguiente manera:

3 instancias de proxy * $0.025 por proxy por hora = $0.075 por hora.

Como se describió antes, cada una de estas instancias de proxy puede administrar una cantidad determinada de tráfico. Una vez que las necesidades de tráfico superen la capacidad de estas tres instancias de proxy, se generarán costos por las instancias de proxy necesarias para administrar cualquier tráfico adicional.

El cargo de procesamiento de datos se calcula a través de la medición del volumen total de datos de las solicitudes y las respuestas que procesa el balanceador de cargas durante el ciclo de facturación. Este cargo escala de acuerdo con el uso y no hay cargo mínimo por el procesamiento de datos.

Los cargos por transferencia de datos entre regiones se aplican si usas un balanceador de cargas de aplicaciones interno entre regiones. Por ejemplo, si tienes una implementación de balanceador de cargas de aplicaciones interno entre regiones en la que el cliente, el proxy de Envoy y el backend se encuentran en regiones separadas, verás los cargos de transferencia de datos entre regiones para cada salto por separado (cliente <-> proxy de Envoy y proxy de Envoy <-> backend). Para reducir estos cargos de transferencia de datos entre regiones, puedes implementar proxies de Envoy en varias regiones.

En el caso del procesamiento de datos, el uso de instancias de proxy por hora y la transferencia de datos de VM entre zonas, se cobra el proyecto de regla de reenvío.

Si estás usando backends de NEG sin servidores para un balanceador de cargas de aplicaciones interno, se aplicarán los cargos existentes del balanceador de cargas de aplicaciones interno, además de los cargos de procesamiento sin servidores para Cloud Run.

Los NEG de Internet regionales requieren el uso de una puerta de enlace de Cloud NAT, lo que genera cargos adicionales. Se te cobrará por la transferencia de datos externa de Internet y el uso de Cloud NAT para cualquier tráfico enviado desde y hacia la subred de solo proxy de Envoy, y para el tráfico de verificación de estado. Sin embargo, los cargos del balanceador de cargas solo se aplican al tráfico de solicitudes de usuarios.

Las puertas de enlace Cloud NAT asignadas para Cloud Load Balancing generan cargos por hora equivalentes a una red con más de 32 instancias de VM. Para obtener más información, consulta Precios de Cloud NAT.

Las políticas de autorización se ofrecen sin tarifas por uso durante todo el período de la vista previa.

Si un servicio de backend tiene asociada una política de Cloud Armor, puedes usar la función de encabezados de solicitud personalizados con ese servicio sin que se te cobre nada adicional por esa función.

Si un servicio de backend que usa la función de encabezados de solicitud personalizados no tiene asociada una política de Cloud Armor, los cargos son de $0.75 por 1,000,000 de solicitudes HTTP(S) por mes y por cuenta. Solo se te cobran las primeras 666,666,667 solicitudes por mes y por cuenta.

El acceso global permite que las instancias de cliente de cualquier región accedan al balanceador de cargas interno. Si una regla de reenvío tiene el acceso global habilitado, se incurren en cargos adicionales por transferencia de datos entre regiones cuando se envía tráfico desde o hacia un cliente en una región diferente a la del balanceador de cargas.

Por lo general, el acceso global está disponible para los balanceadores de cargas de red de transferencia internos, los balanceadores de cargas de aplicaciones internos regionales y los balanceadores de cargas de red de proxy internos regionales.

El reenvío de protocolos se cobra con la misma tarifa que el balanceo de cargas. Se aplican cargos por la regla de reenvío y un cargo por los datos entrantes que procesa la instancia de destino.

No se aplican cargos por los certificados SSL autoadministrados o administrados por Google.