Precios de Cloud Load Balancing

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 externos a nivel mundial 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.
• Google Cloud Armor: si tu aplicación recibe una cantidad significativa de tráfico no deseado, puedes desplegar Google Cloud Armor para bloquearlo. Las solicitudes que bloquea Google 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 Google 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 Google Cloud Armor con la referencia de servicios entre proyectos:
• Los cambios en la suscripción relacionados con Google Cloud Armor Enterprise se atribuyen a la cuenta de facturación que especificaste durante el registro. Si quieres usar la misma suscripción de Google 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 Google Cloud Armor Enterprise.
• Cuando se usa la referencia de servicios entre proyectos, algunas funciones de Google Cloud Armor Enterprise, como la telemetría y la respuesta frente a DDoS, requieren que el nivel de Google 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. Haz clic en "Añadir a la estimación".
3. Selecciona o busca "Redes".
4. Selecciona "Cloud Load Balancing" como tipo de servicio.
5. Selecciona una región en el menú desplegable.
6. Introduce el número de reglas de reenvío que creas adecuado.
7. 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
• Cantidad de 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 al 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 alguna política de Google 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 Google 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.