La transferencia de datos puede ser el tráfico que entra en un recurso de Google Cloud (por ejemplo, una máquina virtual), sale de una región de Google Cloud hacia Internet o se transfiere entre dos recursos de Google Cloud.

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

• Por el conjunto de edificios de la ubicación, donde siempre se ha utilizado la red de Google (precios dentro y fuera de la misma región)
• A otro edificio operado por Google situado en otra ubicación, donde siempre se ha usado la red de Google (precios interregionales)
• A una ubicación no operada por Google a través de una conexión de Cloud Interconnect (precios de Cloud Interconnect)
• A una ubicación no operada por Google que no circula a través de una conexión de Cloud Interconnect (precios de transferencia de datos salientes por Internet)

En el nivel Premium de los niveles de servicio de red, el tráfico que tiene su origen y su destino en usuarios externos va por la excepcional red troncal de Google. Por lo general, la red pública de Internet solo se emplea entre el usuario y el punto de entrada en la red de Google más cercano.

En el nivel Estándar de los niveles de servicios de red, el tráfico entre tus servicios y los usuarios va por la red pública de Internet. En este caso, la calidad del servicio disminuye con respecto al nivel Premium, pero también lo hace el coste.

Esta sección trata sobre el tráfico que sale de máquinas virtuales de Google Cloud y llega a otras máquinas virtuales de Google Cloud. El coste se imputa al proyecto de la máquina virtual que envía el tráfico. Estos precios son aplicables a las máquinas virtuales de Compute Engine, los nodos de Google Kubernetes Engine (GKE) y las máquinas virtuales que ejecutan el entorno flexible de App Engine.

Los siguientes precios se aplican tanto durante el periodo de prueba sin coste económico de Google Cloud como después. Durante este periodo, se factura con cargo al crédito de la prueba sin coste económico.

Transferencia de datos entre máquinas virtuales cuando la máquina virtual de origen y la de destino están en zonas diferentes de la misma región de Google Cloud

Transferencia de datos entre máquinas virtuales cuando las máquinas virtuales de origen y de destino están en regiones de Google Cloud diferentes. Todos los precios son por GiB en USD

Esta sección trata sobre el tráfico que sale de máquinas virtuales de Google Cloud y llega a servicios de Google. El coste se imputa al proyecto de la máquina virtual que envía el tráfico. Estos precios son aplicables a las máquinas virtuales de Compute Engine, los nodos de Google Kubernetes Engine y las máquinas virtuales que ejecutan el entorno flexible de App Engine.

Los siguientes precios se aplican tanto durante el periodo de prueba sin coste económico de Google Cloud como después. Durante este periodo, se factura con cargo al crédito de la prueba sin coste económico.

El nivel premium es el predeterminado para todas las transferencias de datos de Google Cloud. Para utilizar el nivel estándar, debes especificarlo explícitamente.

Los siguientes precios se aplican tanto durante el periodo de prueba sin coste económico de Google Cloud como después. Durante este periodo, se factura con cargo al crédito de la prueba sin coste económico.

Importante: A partir del 1 de febrero del 2024, vamos a aumentar el precio de algunos SKUs de transferencia de datos de Internet de nivel Premium. Para obtener más información, consulta el artículo sobre anuncio de cambio de precios de la transferencia de datos.

Los precios de transferencia de datos se indican por GiB suministrado Este se basa en la geolocalización de origen del tráfico. El tráfico de entrada sigue siendo gratuito. Los límites de uso de Always Free no se aplican al nivel Estándar.

Las direcciones IP internas estáticas o efímeras no conllevan ningún cargo.

En la tabla siguiente se indica cómo se te cobra por las direcciones IP externas estáticas y efímeras.

Si reservas una dirección IP externa estática, pero no la asignas a ningún recurso, como una instancia de máquina virtual o una regla de reenvío, se te cobra una tarifa superior a la de las direcciones IP externas estáticas y efímeras que están en uso.

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

No se te cobra nada por los intervalos de direcciones IPv6 externos que se encuentren asignados a subredes o a instancias de máquina virtual. No se te cobra por las direcciones IPv6 regionales estáticas (en previsualización).

Google Cloud considera que una dirección IP externa estática está en uso si está asociada con una instancia de máquina virtual, independientemente de que la instancia se esté ejecutando o esté detenida. Si se ha eliminado la instancia o la dirección IP no está asociada a ella, 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 se está ejecutando la instancia de máquina virtual asociada. Al detener o eliminar la instancia, Google Cloud libera la dirección IP efímera y deja de considerar que está en uso.

Para comprobar si una dirección IP externa estática se está utilizando, realiza una solicitud de gcloud compute addresses list. Este comando devuelve una lista de direcciones IP externas estáticas y sus estados:

En este ejemplo, la dirección IPv4 address-1 está en uso y la dirección IPv4 address-2 está reservada, pero no se está usando. Las dos direcciones se facturan según la tabla de precios de las direcciones IP externas de este documento.

Nota: Si la misma dirección IP se ha asignado a más de una regla de reenvío, Google Cloud contabiliza y añade cada uso de la dirección IN_USE_ADDRESSES a la cuota, en lugar de un recuento único de objetos de dirección IP que se utilizan.

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

Los costes asociados a Private Service Connect varían en función de la configuración.

Usar un punto final de Private Service Connect (regla de reenvío) para acceder a las APIs de Google

Usar un backend de Private Service Connect (balanceador de carga) para acceder a las APIs de Google

Los servicios de Private Service Connect usan un balanceador de carga para acceder a las APIs de Google. Se aplican todos los precios del balanceador de carga. El tráfico a NEGs de Private Service Connect que se dirige a las APIs de Google incurre en cargos de balanceo de carga por los datos procesados por el balanceador de carga. Sin embargo, no se aplica ningún cargo 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 carga, consulta los precios de los balanceadores de carga de aplicación externos globales o de los balanceadores de carga de aplicación internos.

Nota: Anteriormente, los backends de Private Service Connect se denominaban puntos finales de Private Service Connect con controles de servicio HTTP o HTTPS de consumidor.

Nota: En el caso de los endpoints con acceso global, no se cobra al proyecto del productor de servicios por la transferencia de datos entre regiones, aunque los recursos de consumidor de servicios accedan al endpoint desde otras regiones.

Private Service Connect crea automáticamente un espacio de nombres del Directorio de servicios en el que puedes registrar los endpoints. Se utiliza un único espacio de nombres predeterminado para los endpoints que se encuentran en la misma zona de un proyecto, a menos que crees explícitamente otros espacios de nombres. Para obtener más información sobre los precios de Service Directory, consulta los precios de Directorio de servicios.

Usar un backend de Private Service Connect (balanceador de carga) para acceder a un servicio publicado

Los servicios de Private Service Connect usan un balanceador de carga para acceder a los servicios publicados. Se aplican todos los precios del balanceador de carga. El tráfico entre los NEGs de Private Service Connect y los servicios publicados de Private Service Connect genera tanto cargos de balanceo de carga por los datos procesados por el balanceador de carga como 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 que se aplican a esta configuración.

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

Directorio de servicios

Private Service Connect crea automáticamente un espacio de nombres de Directory de servicios para registrar los puntos finales cuando se accede a las APIs de Google o cuando se accede a los servicios publicados. Se crea un único espacio de nombres predeterminado de Directory de servicios para los puntos finales de Private Service Connect que se encuentran en la misma zona de un proyecto. Para obtener más información sobre los precios de Service Directory, consulta los precios de Directorio de servicios.

El tratamiento de datos de los consumidores de los consumidores se factura a los consumidores de Private Service Connect según la tabla siguiente. Se cobra por el procesamiento de datos de consumidores tanto de entrada como de salida.

Cargos por publicar un servicio gestionado mediante un archivo adjunto de servicio de Private Service Connect

Private Service Connect no cobra cargos por hora ni por transferencia de datos al publicar servicios mediante vinculaciones de servicio. Se les cobra a los productores cualquier cargo de equilibrio de carga que se genere en el balanceador de carga que se publica para los consumidores.

Nota: Si los recursos usan un punto de terminación con acceso global para acceder a un servicio publicado desde una región distinta a la del servicio, no se cobrará al proyecto del productor de servicios por la transferencia de datos entre regiones. Para obtener información sobre los cargos de los proyectos de consumidores de servicios, consulta el artículo Usar un punto final de Private Service Connect (regla de reenvío) para acceder a un servicio gestionado publicado.

Desplegar un servicio mediante mapas de conexión de servicio

Cuando despliegas un servicio mediante mapas de conexión de servicio, no se aplican cargos de productor por el despliegue de los mapas de conexión de servicio en sí. Sin embargo, se le cobra al consumidor lo siguiente:

• Recursos que se despliegan en el proyecto de cliente mediante la automatización de la conectividad de los servicios
• Usar un punto final de Private Service Connect para acceder a un servicio publicado

Cuando creas una conexión de acceso a servicios privados, no se aplican cargos por hora ni por datos por la conexión en sí. Sin embargo, se te cobra por lo siguiente:

• Recursos que aprovisionas en la red del productor de servicios
• Tráfico de transferencia de datos desde tus máquinas virtuales a la red del productor de servicios

Los precios de Acceso a VPC sin servidor son los siguientes:

Se aplican cargos por los registros de red vendidos. Concretamente, se realizan cobros por los siguientes productos:

Se te cobra por la cantidad de datos que procesa la replicación de paquetes, pero no por sus reglas de reenvío. No se aplican cargos adicionales por máquina virtual por usar la replicación de paquetes. En la siguiente tabla se indica el coste de los datos procesados por la replicación de paquetes.

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

• Balanceadores de carga de red de paso a través internos y externos
• Balanceadores de carga de red de proxy interno y externo
• Balanceadores de carga de aplicación externos globales, clásicos y regionales

Para acceder a los balanceadores de carga de aplicación internos regionales y entre regiones, consulta la sección Internal Application Load Balancer.

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

En la siguiente tabla se muestran los precios de las reglas de reenvío globales. No se aplican cargos por el tratamiento de datos global. El tratamiento de datos se factura por región, en función de dónde se procese el tráfico.

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

Los usuarios del balanceador de carga de aplicación externo global pueden usar Google Cloud Armor, Cloud CDN o ambos para minimizar el impacto de los cargos por tratamiento de datos salientes.

• Cloud CDN: los objetos estáticos que se sirven al cliente desde la caché no transitan por el balanceador de carga. Una estrategia de almacenamiento en caché eficaz reduciría la cantidad de datos salientes que procesa el balanceador de carga y, por tanto, los costes. Para implementar el almacenamiento en caché, es necesario saber qué parte de tu tráfico es estático 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 desplegar Cloud Armor para bloquearlo. Las solicitudes que bloquea Cloud Armor no pasan por el balanceador de carga, por lo que se reduce la cantidad de datos salientes que procesa el balanceador de carga. El impacto en tus costes depende del porcentaje de tráfico no deseado que se bloquea con las políticas de seguridad de Cloud Armor que has implementado.

Si tu aplicación puede funcionar en una única región o debe hacerlo en una única región, puedes usar el balanceador de carga de aplicación externo regional. El balanceador de carga de aplicación externo regional solo usa el nivel de red Standard, que tiene cargos de transferencia de datos salientes más bajos, por lo que es una opción rentable.

Si utilizas backends de grupos de puntos finales de red (NEG) sin servidor con un balanceador de carga de aplicaciones externo (global, regional o clásico), se te cobrará el balanceador de carga según la tarifa vigente, además de los cargos por computación sin servidor de los backends de Cloud Run, Cloud Run functions o App Engine, según corresponda. Además, si utilizas Google Cloud Armor o Cloud CDN, se cobran aparte.

Sin embargo, no se te cobrará por la transferencia de datos salientes sin servidor. Solo se aplican las tarifas de transferencia de datos salientes de Internet. No se aplican cargos de transferencia de datos salientes de Cloud Run functions, de tráfico de red saliente de App Engine ni de transferencia de datos de Cloud Run a las solicitudes transferidas de un balanceador de carga de aplicaciones externo (con NEG sin servidor) a servicios de Cloud Run functions, App Engine o Cloud Run.

Consulta los siguientes puntos para saber cómo se facturan los SKUs de red a los proyectos y las cuentas de facturación cuando usas la referencia de servicios entre proyectos.

• Los cargos relacionados con Cloud Load Balancing siempre se atribuyen al proyecto en el que se ha configurado la regla de reenvío (el proyecto de servicio A de 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 carga de aplicaciones externo global. Consulta información básica sobre los precios de Cloud Load Balancing.
• La salida de datos de Internet de red de los niveles premium y estándar siempre se atribuye al proyecto en el que se haya configurado la regla de reenvío (el proyecto de servicio A de la figura 1). Consulta los precios de la transferencia de datos por red.
• Si configuras Cloud CDN en un servicio backend al que hace referencia un mapa de URL mediante la referencia de servicios entre proyectos, todos los cargos de Cloud CDN por contenido almacenable en caché (transferencia de datos de caché, búsqueda en caché y llenado de caché) se atribuyen siempre 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. Consulta los precios de Cloud CDN.
• Si configuras Google Cloud Armor en un servicio de backend al que hace referencia un mapa de URL mediante la referencia de servicios 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 (el proyecto de servicio B de la figura 1), y no al proyecto que configuró las reglas de reenvío. Consulta los precios de Google Cloud Armor. En concreto, todos los cargos de Google Cloud Armor en el nivel Standard y en el nivel Enterprise se atribuyen al proyecto de servicio B.

Ten en cuenta lo siguiente cuando uses Cloud Armor con la referencia de servicios entre proyectos:

• Los cambios en la suscripción relacionados con Cloud Armor Enterprise se atribuyen a la cuenta de facturación que especificaste durante el registro. Si quieres usar la misma suscripción de Cloud Armor Enterprise en varios proyectos para incluir todos los servicios de backend referenciados mediante la referencia de servicios entre proyectos, asegúrate de incluir todos los proyectos de servicios pertinentes en la misma cuenta de facturación de Cloud Armor Enterprise.
• Cuando se usa la referencia de servicios entre proyectos, algunas funciones de Cloud Armor Enterprise, como la telemetría y la respuesta frente a DDoS, requieren que el nivel de Cloud Armor Enterprise se registre tanto en el proyecto de reglas de reenvío de la interfaz como en los proyectos de servicios de backend.

Google Cloud cobra por las reglas de reenvío que se crean para el balanceo de carga o para otros usos, como replicar paquetes.

En los siguientes ejemplos se utilizan precios de EE. UU.:

Puedes crear hasta 5 reglas de reenvío por el precio de 0,025 USD/hora. Por ejemplo, si creas 1 regla de reenvío, se te cobran 0,025 USD por hora. Si creas 3 reglas de reenvío, se te cobrará la misma cantidad. Sin embargo, si tienes 10 reglas de reenvío, se te cobrará lo siguiente:

• 5 reglas de reenvío = 0,025 USD por hora
• Cada regla de reenvío adicional = 0,01 USD por hora

0,025 USD/hora por 5 reglas + (5 reglas adicionales * 0,01 USD/hora) = 0,075 USD por hora

En la mayoría de los casos, basta con una regla de reenvío por cada balanceador de carga.

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

Para calcular los cargos por balanceo de carga:

1. Ir a la calculadora de precios.
2. Ve a la pestaña Cloud Load Balancing.
3. Selecciona una región en el menú desplegable.
4. Introduce el número de reglas de reenvío que creas adecuado.
5. Introduce la cantidad de tráfico de red que calculas que se procesará al mes.

Por ejemplo:

• Iowa
• Número de reglas de reenvío: 10
• Datos de entrada procesados por el balanceador de carga: 2048 GiB
• Coste total estimado: 71,13 USD por 1 mes

En este ejemplo no se incluye el coste de salida de datos de Internet correspondiente al envío de respuestas desde los backends.

Los siguientes cargos se aplican tanto al balanceadores de carga de aplicaciones internos regionales como a los balanceadores de carga de aplicaciones internos entre regiones. También se aplican algunos cargos adicionales por transferencia de datos entre regiones al balanceador de carga de aplicación interno entre regiones.

Los balanceadores de carga basados en Envoy escalan automáticamente el número de proxies disponibles para gestionar el tráfico en función de tus necesidades El cargo por instancias de proxy depende de cuántas hagan falta para gestionar el tráfico. Con cada proxy de más, se te factura otra hora según los precios indicados en la tabla anterior.

El número de proxies asignados a tu balanceador de carga se calcula en función de la capacidad medida que se necesita para gestionar el tráfico en un periodo de 10 minutos. Tomamos el mayor de estos valores en dicho periodo:

• Número de proxies necesarios para servir el ancho de banda del tráfico. Cada instancia de proxy puede gestionar hasta 18 MB por segundo. Monitorizamos el ancho de banda total necesario y lo dividimos por el ancho de banda que admite la instancia de proxy.
• Número de proxies necesarios para gestionar las conexiones y las solicitudes. Sumamos el total de cada uno de los recursos siguientes y dividimos cada suma por el valor que puede gestionar la instancia de proxy:
• 600 o 150 conexiones nuevas (HTTP o HTTPS, respectivamente) por segundo
• 3000 conexiones activas
• 1400 solicitudes por segundo*

* Las instancias de proxy pueden gestionar 1400 solicitudes por segundo si Cloud Logging está inhabilitado. Si habilitas Logging, la cifra disminuye. Por ejemplo, si registras absolutamente todas las solicitudes, la capacidad del proxy se reduce a 700 solicitudes por segundo. Una opción es configurar Logging para que muestree un porcentaje menor de tráfico. De ese modo, cumples tus requisitos de observabilidad y mantienes el coste bajo control.

En un periodo de 10 minutos, se transfieren 180 MB de datos por segundo a través del balanceador de carga: 180 MB por segundo/18 MB por segundo por instancia de proxy = 10 instancias de proxy

En ese mismo periodo, se establecen 300 nuevas conexiones HTTPS por segundo, hay 3000 conexiones activas y se envían 2800 solicitudes por segundo:

300 nuevas conexiones HTTPS por segundo / 150 nuevas conexiones HTTPS por segundo por instancia de proxy = 2 instancias de proxy 3000 conexiones activas / 3000 conexiones activas por instancia de proxy = 1 instancia de proxy 2800 solicitudes por segundo / 1400 solicitudes por segundo por instancia de proxy = 2 instancias de proxy.

La suma asciende a 5 instancias de proxy, Menos que las 10 instancias de proxy necesarias para servir el ancho de banda. Por lo tanto, para calcular el cargo por instancias de proxy durante este periodo de 10 minutos, se hace esta operación:

10 instancias de proxy × 0,025 USD por instancia de proxy por hora × (10 minutos ÷ (60 minutos por hora)) = 0,0417 USD.

Para calcular la factura, se tiene en cuenta la capacidad medida que se necesita para gestionar el tráfico, no el número de instancias de proxy que establecen conexiones con los backends. Por eso, quizá no veas en la factura las mismas instancias que ves en tu infraestructura.

Para que el rendimiento y la fiabilidad sean óptimos, a cada balanceador de carga se le asignan al menos tres instancias de proxy de la región de Google Cloud donde está desplegado. Esas instancias se asignan aunque el balanceador de carga no gestione nada de tráfico. En cuanto despliegas una regla de reenvío con el esquema de balanceo de carga INTERNAL_MANAGED, se empiezan a devengar cargos por las instancias de proxy. Cuantas más reglas de reenvío, más cargos por ese concepto (según lo que hemos explicado antes); en suma, por cada regla de reenvío, tres instancias de proxy más.

Las tres instancias de proxy que se asignan al balanceador de carga tienen un cargo mínimo de instancia de proxy por hora. Por ejemplo, en la región us-central1 de Google Cloud, el cargo mínimo se calcularía así:

3 instancias de proxy × 0,025 USD por proxy/hora = 0,075 USD por hora.

Como decíamos antes, cada una de esas instancias de proxy puede gestionar una cantidad determinada de tráfico. Si el tráfico supera dicha capacidad, se te cobra por las instancias de proxy de más que hagan falta para gestionarlo.

Para calcular este cargo, se mide el volumen total de datos de las solicitudes y las respuestas que ha procesado el balanceador de carga durante el ciclo de facturación. El importe depende del uso y no se aplica ningún cargo mínimo.

Los cargos de transferencia de datos entre regiones se aplican si usas un balanceador de carga de aplicación interno que abarque varias regiones. Por ejemplo, si tienes una implementación de balanceador de carga de aplicación interna en varias regiones en la que el cliente, el proxy de Envoy y el backend se encuentran en regiones distintas, verás los cargos de transferencia de datos entre regiones por cada salto por separado (cliente <-> proxy de Envoy y proxy de Envoy <-> backend). Para reducir estos cargos por 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 entre máquinas virtuales de diferentes zonas, el cargo se hace al proyecto de la regla de reenvío.

Si utilizas backends de grupos de puntos finales de red (NEG) sin servidor con un balanceador de carga de aplicaciones interno, se te cobrará por el balanceador de carga de aplicaciones interno según la tarifa vigente, además de los cargos por computación sin servidor de Cloud Run.

Los NEGs de Internet regionales requieren el uso de una pasarela de Cloud NAT, lo que conlleva cargos adicionales. Se te cobrará por la transferencia de datos de salida de Internet y el uso de Cloud NAT de todo el tráfico que se envíe desde y hacia la subred solo de proxy de Envoy, así como por el tráfico de comprobación de estado. Sin embargo, los cargos del balanceador de carga solo se aplican al tráfico de solicitudes de usuario.

Las pasarelas de Cloud NAT asignadas para Cloud Load Balancing conllevan cargos por hora equivalentes a los de una red con más de 32 instancias de máquina virtual. Consulta más información en la página de precios de Cloud NAT

Las políticas de autorización están disponibles sin tarifas de uso durante la vista previa.

En los servicios de backend que tienen asociada una política de Cloud Armor, puedes utilizar la función de encabezados de solicitud personalizados sin ningún cargo adicional.

En los servicios de backend que usan la función de encabezados de solicitud personalizados y no tienen asociada ninguna política de Cloud Armor, se cobra 0,75 USD por cada millón de solicitudes HTTP o HTTPS por mes y cuenta. Solo se te cobrarán las primeras 666.666.667 solicitudes por mes y cuenta.

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

El acceso mundial suele estar disponible para los balanceadores de carga de red con paso a través internos, los balanceadores de carga de aplicaciones internos regionales y los balanceadores de carga de red con proxy internos regionales.

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

No se aplican cargos por los certificados SSL autogestionados o de cuya gestión se ocupe Google.