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

Información general sobre los precios de red

Transferencia de datos

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)

Nivel premium

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.

Nivel Estándar

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.

Precios de transferencia de datos entrantes

Transferencia de datos interregionales

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.

Tarifas de transferencia de datos de Internet

Precios del nivel Premium

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.

Precios del nivel Estándar

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.

Precios de las direcciones IP internas

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

Precios de las direcciones IP externas

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).

En uso o no

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:

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.

Reglas de cortafuegos

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

Private Service Connect

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

Cargos para el consumidor

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.

Usar un punto final de Private Service Connect (regla de reenvío) para acceder a un servicio publicado

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.

Tratamiento de datos de consumidores

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 del productor

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

Acceso a servicios privados

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

Acceso a VPC sin servidor

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

Telemetría de red

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

• Registros de flujo de VPC
• Almacenamiento de registros de reglas de cortafuegos
• Almacenamiento de registros de Cloud NAT

Replicación de paquetes

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.

Balanceo de carga y reglas de reenvío

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.

Formas de reducir los costes del balanceador de carga de aplicación externo

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.

Precios de balanceador de carga de aplicación con NEG sin servidor

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.

Referencia de servicios entre proyectos con VPC compartida

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 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.

Ejemplos de precios de reglas de reenvío

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).

Calcular los cargos por balanceo de carga

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.

Balanceador de carga de aplicación interno

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.

Cargo por instancias de proxy

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.

Ejemplo de cálculo

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.

Cargo mínimo por instancias de proxy

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.

Cargo por procesamiento de datos

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.

Cargos de transferencia de datos entre regiones

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.

Referencia de servicios entre proyectos con VPC compartida

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.

Precios del balanceador de carga de aplicación interno con NEG sin servidor

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.

Cargos de NEGs de Internet regionales

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

Cargos de las políticas de autorización

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

Cargos por Google Cloud Armor y por los encabezados de solicitud personalizados

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.

Acceso global a los balanceadores de carga internos

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.

Reenvío de protocolos

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.

Certificados SSL

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

En este documento se detallan los precios de Google Cloud Armor y Google Cloud Armor Enterprise. Estos precios están activos.

Los recursos protegidos incluyen los siguientes tipos de backend en cada proyecto registrado; los backends cuentan como recursos protegidos en todos los tipos de puntos finales y balanceadores de carga cubiertos del proyecto registrado.

Tarifa por procesamiento de datos

La tarifa por tratamiento de datos de Cloud Armor Enterprise incluye los datos transferidos a Internet procedentes de todos los recursos protegidos de todos los proyectos registrados en Cloud Armor Enterprise. Cuando usas Cloud Armor Enterprise Annual, la tarifa por tratamiento de datos se factura a nivel de proyecto, pero el uso se agrega en todos los recursos protegidos de todos los proyectos registrados en Cloud Armor Enterprise Annual. Cuando usas Cloud Armor Enterprise Paygo, la tarifa por tratamiento de datos se factura y el uso se agrega a nivel de proyecto. La tarifa por tratamiento de datos de Cloud Armor Enterprise es independiente de la tarifa de Cloud Load Balancing.

Los precios se especifican por GiB transferido a Internet directamente o a través de un emparejamiento mediante operador y se cobran aparte de las tarifas de transferencia de datos. Por ejemplo, en el caso de las cargas de trabajo en las que se usa un balanceador de carga de Google Cloud compatible, la tarifa de tratamiento de datos mide los bits de transferencia a Internet a través de los puntos de conexión del balanceador de carga registrados, pero no mide el tráfico interregional interzonal asociado mediante la carga de trabajo subyacente. El cargo es de 0,05 USD por cada GiB de transferencia que llegue a los primeros 100 TiB y a 0,04 USD por GiB durante los próximos 400 TiB. Si el contenido que se sirve utiliza Cloud CDN y se considera almacenable en caché, se aplica la tarifa por procesamiento de datos de dicho servicio. En la siguiente tabla se incluyen los precios completos:

En este documento se detallan los precios de Cloud IDS. Estos precios están activos. Los precios de esta página están en dólares estadounidenses (USD).

Si tienes pensado servir un gran volumen de contenido desde Cloud CDN (más de 500 TiB al mes), puedes ponerte en contacto con nosotros para hablar de los descuentos por volumen.

En este documento se detallan los precios de Cloud CDN.

Los precios de esta página están en dólares estadounidenses (USD). Si pagas en una moneda que no sea el dólar estadounidense, se aplicarán los precios que figuran para tu divisa en los SKU de Cloud Platform.

Estructura de precios

Notas sobre los precios

• El uso de red se calcula en gibibytes (GiB).
• Los cargos se acumulan por días, pero Cloud CDN los cobra al final del periodo de facturación. Para ver el uso que no se ha facturado, abre la consola de Google Cloud y ve a la página de facturación de tu proyecto.
• Los bytes medidos de transferencias de datos salientes o entrada en caché incluyen los encabezados de respuesta HTTP (después de la compresión, si procede) y el cuerpo de la respuesta, así como cualquier finalizador.

Ejemplo de precios

En el ejemplo siguiente se muestra una situación sencilla que podría darse si acabas de empezar a usar Cloud CDN.

Supongamos que tu patrón de uso de Cloud CDN durante un mes concreto es el siguiente:

La factura del mes se calcularía así:

En este documento se detallan los precios de Cloud Interconnect.

Si pagas en una moneda que no sea el dólar estadounidense, se aplicarán los precios que figuran para tu divisa en los SKU de Cloud Platform.

Transferencia de datos desde una red de VPC a través de una conexión de Cloud Interconnect

Norteamérica

En la siguiente tabla se muestran los precios para la zona geográfica de Norteamérica.

Europa, Oriente Medio y África (EMEA).

En la siguiente tabla se muestran los precios para la zona geográfica de Europa, Oriente Medio y África (EMEA).

Asia

En la siguiente tabla se muestran los precios para la zona geográfica de Asia.

Australia

En la tabla siguiente se muestran los precios para la zona geográfica de Australia.

Sudamérica

En la siguiente tabla se muestran los precios para la zona geográfica de Sudamérica.

Transferencia de datos entrantes a través de una conexión de Cloud Interconnect

Ejemplo de precios

En la siguiente tabla se muestra un ejemplo de patrón de uso de las conexiones de interconexión dedicada para un solo mes:

Transferencia de datos desde una red de VPC a través de una conexión de Cloud Interconnect

Norteamérica

En la siguiente tabla se muestran los precios para la zona geográfica de Norteamérica.

Europa, Oriente Medio y África (EMEAR)

En la siguiente tabla se muestran los precios para la zona geográfica de Europa, Oriente Medio y África (EMEAR).

Asia

En la siguiente tabla se muestran los precios para la zona geográfica de Asia.

Australia

En la tabla siguiente se muestran los precios para la zona geográfica de Australia.

Sudamérica

En la siguiente tabla se muestran los precios para la zona geográfica de Sudamérica.

Transferencia de datos entrantes a través de una conexión de Cloud Interconnect

Ejemplo de precios

En la siguiente tabla se muestra un ejemplo de patrón de uso de las conexiones de Partner Interconnect para un solo mes:

Transferencia de datos desde una red de VPC a través de una conexión de Cloud Interconnect

Norteamérica

En la siguiente tabla se muestran los precios para la zona geográfica de Norteamérica.

Europa, Oriente Medio y África (EMEAR)

En la siguiente tabla se muestran los precios para la zona geográfica de Europa, Oriente Medio y África (EMEAR).

Asia

En la siguiente tabla se muestran los precios para la zona geográfica de Asia.

Australia

En la tabla siguiente se muestran los precios para la zona geográfica de Australia.

Sudamérica

En la siguiente tabla se muestran los precios para la zona geográfica de Sudamérica.

Transferencia de datos entrantes a través de una conexión de Cloud Interconnect

Ejemplo de precios

En la siguiente tabla se muestra un ejemplo de patrón de uso de las conexiones de Cross-Cloud Interconnect para un solo mes:

Una máquina virtual en la misma región que una vinculación de VLAN mediante un enrutamiento dinámico de VPC regional o global

Nota: El modo de enrutamiento dinámico que utilices no afectará al precio.

En este escenario, existen dos regiones dentro de Norteamérica: us-west1 y us-east1. Estas regiones usan el enrutamiento dinámico regional de VPC que proporciona Cloud Router. No importa qué modo de enrutamiento dinámico utilices.

Solicitas una conexión de Cloud Interconnect que se ejecute desde tu ubicación on‑premise a San José (SJC) y creas dos vinculaciones de VLAN a través de esa conexión. Una vinculación de VLAN se dirige a la región us-east1 y la otra, a us-west1.

Si envías tráfico de una máquina virtual en us-east1 o de una máquina virtual en us-west1 a tu ubicación on-premise a través de tu conexión de Cloud Interconnect en SJC, se te cobrarán las siguientes tarifas:

• Gastos de transferencia de datos de salida de Cloud Interconnect en Norteamérica, ya que es donde se encuentra la conexión.
• No se aplican cargos de transferencia de datos de región a región, ya que las máquinas virtuales utilizan una vinculación de VLAN de la misma región.

Nota: Salvo que habilites el enrutamiento dinámico global para tu red de VPC mediante Cloud Router, las regiones sin una vinculación de VLAN no tendrán acceso a tu conexión de Cloud Interconnect. Esto también significa que no se te pueden aplicar gastos de transferencia de datos intercontinentales accidentalmente si tienes regiones ubicadas en diferentes continentes.

Una máquina virtual en el mismo continente, pero en una región diferente de una vinculación de VLAN mediante un enrutamiento dinámico de VPC global

En este escenario, tienes máquinas virtuales en dos regiones ubicadas en Norteamérica: us-west1 y us-east1. Has habilitado el enrutamiento dinámico global para tu red de VPC mediante Cloud Router. El enrutamiento dinámico global permite que una o más máquinas virtuales ubicadas en una región puedan usar las vinculaciones de VLAN que se encuentran en otra región.

Solicita una conexión de Cloud Interconnect que se ejecute desde tu ubicación on‑premise a San José (SJC) y crea una vinculación de VLAN a través de esa conexión a us‑west1. Después, envía tráfico desde una máquina virtual en us-east1 a tu ubicación on-premise a través de la vinculación de VLAN ubicada en us-west1. Se te cobrarán las siguientes tarifas:

• Gastos de transferencia de datos de una región a otra para reenviar tráfico de us-east1 a la vinculación de VLAN en us-west1. La vinculación de VLAN en us-west1 se considera la fuente de tráfico.
• Los gastos de transferencia de datos de Cloud Interconnect para Norteamérica por el tráfico desde la región us-west1 hasta la ubicación on-premise.

Una máquina virtual en un continente diferente de una vinculación de VLAN mediante un enrutamiento dinámico de VPC global

Este escenario es el mismo que el del ejemplo anterior, solo que en este una región, us-west1, se encuentra en Norteamérica y la otra, asia-east1, en Asia. El envío de tráfico entre regiones en diferentes continentes genera tarifas de transferencia de datos entre regiones más caras.

La única forma de enviar tráfico desde asia-east1 a través de Cloud Interconnect en Norteamérica es habilitar el enrutamiento dinámico de VPC global. Esto hace que la vinculación de VLAN en us-west1 esté disponible para las máquinas virtuales en todas las regiones de tu red de VPC. Se te cobrarán las siguientes tarifas:

• Gastos de transferencia de datos de región a región intercontinentales para el reenvío de tráfico desde asia-east1 a us-west1.
• Los gastos de transferencia de datos de Cloud Interconnect para Norteamérica por el tráfico desde la región us-west1 hasta la ubicación on-premise.

Una máquina virtual en un continente diferente de una vinculación de VLAN mediante un emparejamiento entre redes de VPC

Este escenario es similar al ejemplo anterior, pero ahora hay dos redes de VPC conectadas a través del emparejamiento entre redes de VPC. Al enviar el tráfico entre regiones, el precio es el mismo que en el ejemplo anterior que usa enrutamiento dinámico global.

Envías tráfico desde us-east4 a tu red on-premise a través de Cloud Interconnect en Asia con el emparejamiento entre redes de VPC. Se te cobrarán las siguientes tarifas:

• Gastos de transferencia de datos de región a región intercontinentales desde us-east4 hasta asia-northeast1.
• Los cargos de transferencia de datos de Cloud Interconnect para Asia por el tráfico desde la región asia-northeast1 hasta tu ubicación on‑premise.

Un producto o servicio de Google Cloud que no es de máquina virtual en una ubicación que no es una vinculación de VLAN mediante un enrutamiento dinámico de VPC global

Además de los escenarios anteriores, se aplicarán gastos de transferencia de datos de Cloud Interconnect al tráfico enviado desde un producto o servicio de Google Cloud que no sea una máquina virtual a tu ubicación on‑premise a través de una vinculación de VLAN. Tendrás que pagar los gastos de transferencia de datos del producto para llegar a la región de la vinculación de VLAN y, a continuación, abonar los gastos de salida de transferencia de datos de Cloud Interconnect según el continente en el que se encuentre la conexión.

Nota: Para obtener información sobre los gastos de salida de otros productos de Google Cloud no descritos en este ejemplo, consulta la página de precios de ese producto.

En el ejemplo siguiente se describen los gastos de tráfico saliente de un segmento de Cloud Storage ubicado en una región de Norteamérica diferente de la región en la que se encuentra la vinculación de VLAN.

En este caso, tienes recursos en dos regiones ubicadas en Norteamérica: us-west1 (Oregón) y northamerica-northeast1 (Montreal). Has habilitado el enrutamiento dinámico global para tu red de VPC mediante Cloud Router.

Solicita una conexión de Cloud Interconnect que se ejecute desde tu ubicación on‑premise a San José (SJC) y crea una vinculación de VLAN a través de esa conexión a us‑west1. A continuación, envía tráfico desde un segmento de Cloud Storage en northamerica-northeast1 a tu ubicación on‑premise a través de la vinculación de VLAN ubicada en us‑west1. Se te cobrarán las siguientes tarifas:

• El coste de transferencia de datos de Cloud Storage para reenviar tráfico desde un segmento de Cloud Storage en northamerica-northeast1 a una vinculación de VLAN en us-west1.
• Gastos de transferencia de datos de Cloud Interconnect en Norteamérica por el tráfico de la región us-west1 a tu ubicación on-premise, ya que ahí es donde se encuentra la conexión de Cloud Interconnect.

Si el segmento de Cloud Storage se encuentra en un continente distinto al de la vinculación de VLAN, tendrás que pagar los gastos de transferencia de datos intercontinentales de Cloud Storage para llegar a la vinculación de VLAN en us-west1.

Para obtener una lista completa de escenarios de precios de Cloud Storage, consulta la página de precios de Cloud Storage.

Cloud Router es un servicio gratuito. Los costes generales de red se aplican al tráfico del plano de control (BGP) y, en la mayoría de los casos, son mínimos.

Para obtener más información sobre estos costes, consulta la sección de precios generales de red de la documentación sobre la nube privada virtual (VPC).

A grandes rasgos, los cargos de Cloud VPN se componen de:

• Cargo por hora por cada pasarela de Cloud VPN; este cargo está determinado, en parte, por el número de túneles vinculados a la pasarela, así como por su ubicación
• Cargo mensual por el tráfico IPsec
• Cargo por hora de cualquier dirección IP externa asignada a una pasarela VPN, pero no la use un túnel

Para saber más sobre el servicio, consulta la información general sobre Cloud VPN.

Nota: Los túneles VPN se facturarán según el estado en que se encuentren .

Escenarios de precios

Si quieres saber cómo se aplican los precios de Cloud VPN, consulta los siguientes ejemplos.

Pasarela us-central1 a un centro de datos

Imagina que tienes una pasarela de VPN en us-central1. Esta pasarela utiliza dos túneles para conectarse a un centro de datos on‐premise en Iowa.

Todos los meses, envías 2 tebibytes (TiB) de datos a través del túnel desde tu red de nube privada virtual (VPC) a tu centro de datos. Al mismo tiempo, envías 2 TiB en la otra dirección: desde el centro de datos hasta tu red de VPC.

Además, tu pasarela usa una dirección IP externa reservada.

En la siguiente tabla se muestran los cargos que se producirían durante un mes de 30 días con esta configuración.

Pasarela asia-northeast1 a un centro de datos y otra red de VPC

Imagina que tu proyecto tiene una red de VPC llamada Red A, que incluye una pasarela de VPN en asia-northeast1. Esta pasarela utiliza dos túneles para conectarse a un centro de datos on‐premise de Tokio. Además, esta pasarela utiliza dos túneles para conectarse a la red B, otra red VPC de tu proyecto. La pasarela de la red B se encuentra en europe-west6.

El uso mensual de los datos es el siguiente:

• Los usuarios de la red A descargan 10 TiB de datos de Cloud Storage y los envían al centro de datos de Tokio.
• Las redes A y B se envían unos 20 TiB de datos.

Tanto la pasarela asia-northeast1 como la europe-west6 usan direcciones IP externas reservadas.

Además, tienes una tercera pasarela de VPN en southamerica-east1. Creaste esta pasarela hace varios meses y le asignaste una dirección IP externa reservada, pero nunca has configurado un túnel para esta pasarela.

En la siguiente tabla se muestran los cargos que aplicaría esta configuración durante un mes de 30 días.

Network Connectivity Center

En este documento se describen los precios de Network Connectivity Center.

Network Connectivity Center es un modelo de eje y radio para gestionar la conectividad de red de Google Cloud. Con este modelo, las redes de nube privada virtual y las redes on‑premise se conectan a un eje de Network Connectivity Center usando radios con recursos de radio de Google Cloud compatibles vinculados a dichas redes.

Para obtener más información sobre Network Connectivity Center, consulta la información general de Network Connectivity Center.

Precios actuales

En las siguientes secciones, se describen los precios actuales de Network Connectivity Center.

Hubs y radios

En la siguiente tabla se describen los cargos por los hubs y radios. Las horas de radio se refieren al número de horas de un mes en las que la conexión de audio está activa.

Se te exime de pagar los cargos por horas de radio hasta un máximo de tres radios de VPN y tres de Cloud Interconnect.

Nota: A veces, los radios de Cloud Interconnect se denominan radios de vinculación de VLAN.

Transferencia de datos

La transferencia de datos hace referencia a cualquier tráfico que fluya entre un conjunto de radios híbridos conectados al Network Connectivity Center.

El tráfico de transferencia de datos de Network Connectivity Center es distinto del tráfico de entrada y de salida, que entra o sale de la red de Google. Por el contrario, la transferencia de datos de Network Connectivity Center puede hacer ambas cosas: puede llegar y salir de la red de Google, ya que se trata de tráfico que se intercambia entre dos nodos de una red en malla híbrida.

Los cargos por transferencia de datos se basan en los gibibytes (GiB) de tráfico al mes.

Redes de datos avanzadas

Las redes de datos avanzadas (ADN) son la tarifa de procesamiento que se aplica a todo el tráfico que se envía desde un altavoz a través de un hub.

El cargo de ADN es de 0,02 USD por gibibyte (GiB) al mes.

Actualmente, este cargo se aplica al tráfico entre radios de VPC. Los cargos de ADN por radios híbridos no se aplican actualmente.

Ejemplo de precios

Redes de datos avanzadas

En este ejemplo, una empresa tiene dos redes globales de nube privada virtual (VPC), VPC-1 y VPC-2, que conecta mediante radios de VPC a su hub de Network Connectivity Center. Cada VPC se encuentra en un proyecto distinto del proyecto de hub.

Cada mes, la VPC 1 envía 10 TiB de datos a la VPC 2, y la VPC 2 envía 5 TiB de datos a la VPC 1.

En la siguiente tabla se describen los cargos que se aplicarán durante un mes de 30 días.

Transferencia de datos

En este ejemplo, una empresa conecta dos radios del dispositivo router a su eje de Network Connectivity Center. Un radio representa una oficina de Los Ángeles (us-west2). Otra representa una oficina de Bombay (asia-south1).

Cada mes, la oficina de EE. UU. transfiere 5 TiB de datos a la oficina de Asia, y la oficina de Asia, 5 TiB a la oficina de EE. UU.

En la siguiente tabla se describen los cargos que se aplicarán durante un mes de 30 días.

Precios de otros recursos de Google Cloud

Los precios de esta página no incluyen los cargos por otros recursos y productos de Google Cloud que puedas usar junto con Network Connectivity Center. Por ejemplo:

• Si utilizas radios del dispositivo router, pagas por los recursos subyacentes de Compute Engine.
• Si utilizas radios de vinculación de VLAN, pagas por los recursos subyacentes de Cloud Interconnect.
• Si utilizas radios VPN, pagas por los recursos subyacentes de Cloud VPN.

Dispositivo router

Los precios de los dispositivos router forman parte del precio de Network Connectivity Center. Para obtener más información al respecto, consulta la sección de precios de Network Connectivity Center.

Para obtener más información sobre estos costes, consulta la sección de precios generales de red de la documentación sobre la nube privada virtual.

Los precios de Cloud NAT se basan en el uso siguiente:

• Un precio por hora para la pasarela de NAT que se basa en el número de instancias de máquina virtual que usan esa pasarela. La tarifa por hora está limitada a 32 instancias de máquina virtual. Las pasarelas que sirven a un número de instancias superior al número máximo se cobran a la tarifa máxima por hora.
• Google Cloud contabiliza las instancias de máquina virtual que obtienen una asignación de NAT como si usaran esa pasarela. La pasarela de NAT ejecuta la NAT de origen (SNAT) para el tráfico de transferencia de datos de los recursos que no tienen direcciones IP externas y la NAT de destino (DNAT) para los paquetes de entrada que llegan como respuesta a los paquetes de salida.
• Un coste por GiB de la transferencia de datos que procesa la pasarela. El precio del tratamiento de datos es el mismo en todas las regiones. También se aplican costes de transferencia de datos para enviar el tráfico de la máquina virtual fuera de la red.
• Un precio por hora por cada dirección IP externa estática o efímera que usa una pasarela NAT.

El coste total por ejecutar una pasarela de NAT y transferir el tráfico a través de ella se calcula de la siguiente manera:

Coste total por utilizar la pasarela = coste por hora de usar la pasarela de NAT

+ coste por cada GiB de datos que procesa la pasarela

+ Coste por hora de las direcciones IP externas que utiliza la pasarela

+ costes de transferencia de datos del tráfico que sale de la red

Ejemplo de precios

La siguiente tabla muestra el coste mensual estimado de una sola pasarela de NAT que utiliza direcciones IP externas para servir a un número diferente de instancias de VM. En ambos casos, la pasarela se ejecuta durante 720 horas en un ciclo de facturación.

Precios del almacenamiento de registros

Consulta los precios del almacenamiento de registros de NAT en la sección de precios de la telemetría de red.

Se aplicarán los precios estándar de Cloud Logging, BigQuery o Pub/Sub.

En el modelo de precios de Cloud DNS, los cargos se realizan de forma mensual y por zonas (independientemente de si las utilizas o no). Además, debes pagar las consultas que se realicen a tus zonas.

Si pagas en una moneda que no sea el dólar estadounidense, se aplicarán los precios que figuran para tu divisa en los SKU de Cloud Platform.

Note: No hay ningún nivel gratuito en Cloud DNS.

Tabla de precios

Los precios siguientes se aplican a todos los tipos de zonas: públicas, privadas y de reenvío. A la hora de calcularlos, se suman todos los tipos de zona; por ejemplo, si tienes 10 de cada tipo (públicas, privadas y de reenvío), los precios se basan en el total de 30 zonas. También se suman todas las consultas, independientemente del tipo de zona que utilices.

Puedes usar etiquetas para clasificar las zonas según te convenga y utilizarlas después para ver desgloses por etiquetas en tus facturas.

Precio de las consultas

Precios de las zonas gestionadas

El uso de Cloud DNS no implica ningún cargo por transferencia de datos salientes.

Precios de las comprobaciones del estado

Ejemplo de precios

En la siguiente tabla se muestran algunos ejemplos de patrones de uso de Cloud DNS y de posibles costes mensuales:

Ejemplo de precio posterior a la disponibilidad general (GA) para comprobaciones del estado

En este documento se detallan los precios de Extensiones de servicios.

Se aplican los siguientes cargos por las llamadas de atención de las extensiones de servicio en Cloud Load Balancing. Es posible que se apliquen otros cargos relevantes por la transferencia de datos para el tráfico entre regiones y cualquier recurso de computación al otro lado de la llamada.

Resumen de precios

Nota: El 7 de septiembre del 2023, Squarespace adquirió todos los registros de dominios y cuentas de cliente asociadas de Google Domains. Para obtener más información sobre cómo afecta este cambio a Cloud Domains, consulta las funciones de Cloud Domains que se van a retirar, las preguntas frecuentes sobre Google Domains y las preguntas frecuentes sobre la compra de Google Domains por parte de Squarespace.

Los dominios se registran en incrementos de un año. Al registrar un dominio, te comprometes a pagar el año completo. Los dominios se renuevan automáticamente. Si tu dominio se renueva en Cloud Domains, se te cobrarán los 12 meses posteriores a la fecha de renovación. Si quieres dejar de pagar por tu dominio o no quieres que se renueve automáticamente, consulta el artículo Desactivar la renovación automática de un nombre de dominio.

Nota: Si usas Cloud DNS, se te cobrará el coste del DNS por separado Para obtener más información sobre el coste de Cloud DNS, visita la página de precios de Cloud DNS.

Precios por terminación de dominio

Los precios varían en función de las terminaciones de dominio (TLD), que se muestran en la tabla de precios. Por ejemplo, si compras example.com, example.charity y example.wiki, el coste anual de cada dominio será diferente porque las terminaciones de dominio .com, .charity y .wiki tienen precios distintos. El precio anual de cada dominio que registres se añade al total de facturación. Consulta el ejemplo de precios.

Cloud Domains no admite los siguientes tipos de dominios:

• Dominios premium
• Dominios que requieren una notificación de marca

Modelos de facturación

Advertencia: La transferencia de un dominio registrado de un registrador de dominio externo a Cloud Domains se ha retirado. Para obtener más información, consulta el artículo sobre la discontinuación de las funciones de Google Domains.

Facturación de suscripciones (para cuentas de facturación de Cloud fuera de Brasil)

El modelo de facturación de suscripciones te cobra el importe anual del dominio al mes siguiente de haber registrado, renovado o transferido tu dominio. Se aplica a todos los dominios de Cloud Domains que se hayan registrado, renovado o transferido en la versión de disponibilidad general.

Los cargos de Cloud Domains aparecen en tu factura en la sección Cargos que no son específicos de un proyecto porque están vinculados a la cuenta de facturación de Cloud.

El modelo de facturación de suscripciones no se incluye en el programa de descuentos para empresas.

Facturación de compromisos (para cuentas de facturación de Cloud en Brasil)

Si tu cuenta de facturación de Cloud tiene una dirección de Brasil, el modelo de facturación de compromisos te cobrará la doceava parte del coste total cada mes durante los 12 meses siguientes hasta que caduque el dominio. Se aplica a todos los dominios de Cloud Domains que se hayan registrado, renovado o transferido en la versión de disponibilidad general.

Los cargos de Cloud Domains aparecen en tu factura en la sección Cargos que no son específicos de un proyecto porque están vinculados a la cuenta de facturación.

El modelo de facturación de suscripciones no se incluye en el programa de descuentos para empresas.

Si decides transferir un dominio registrado a otro registrador durante los 12 meses posteriores a la fecha de registro, renovación o transferencia a Cloud Domains, se te cobrará una tarifa de cancelación. La tarifa de cancelación es igual a la parte sin facturar del coste anual del dominio.

Facturación de dominios recién registrados

Al registrar un dominio con Cloud Domains, te comprometes a pagar un año completo de registro.

Facturación de dominios transferidos

Cuando transfieres un dominio desde otro proveedor, la facturación se realiza de la siguiente forma:

• Se mantiene el tiempo de registro actual con tu proveedor original.
• Una vez realizada la transferencia, el plazo de registro se amplía un año.
• Se te facturará el periodo ampliado de inmediato.
• No se te volverá a facturar hasta que tu dominio esté a punto de caducar y deba renovarse.

Los dominios que transfieras utilizarán la facturación de suscripciones o de compromisos.

Ejemplo

En los siguientes ejemplos se explica cómo funciona la facturación de los dominios transferidos.

• Si queda un mes de registro antes de realizar la transferencia, se te facturará un año en el momento de transferir el dominio. El siguiente evento de facturación tras la transferencia es la renovación del dominio, 13 meses (1 mes + 1 año) después de la transferencia.
• Si al dominio le quedan dos años de registro antes de realizar la transferencia, el siguiente evento de facturación es de tres años (2 años + 1 año).

Facturación de renovaciones

Los dominios renovados se facturan mediante la facturación de suscripciones o de compromisos.

Advertencia: La exportación de un dominio registrado de Cloud Domains a Google Domains se ha retirado. Para obtener más información, consulta el artículo sobre la discontinuación de las funciones de Cloud Domains.

Para desactivar la renovación automática, consulta el artículo Desactivar la renovación automática de un nombre de dominio. Para gestionar individualmente la cuenta de facturación de un dominio (externa a un proyecto de Google Cloud), debes transferirla a un registrador externo. Sin embargo, si ya has registrado un dominio con Cloud Domains y decides transferirlo a un tercero antes de que acabe el periodo de 12 meses, seguirás pagando por el dominio durante el tiempo restante. La frecuencia de facturación depende del modelo de facturación de tu recurso.

Para obtener más información sobre las renovaciones, consulta las preguntas frecuentes sobre la compra de Google Domains por parte de Squarespace.

Es obligatorio usar Cloud Domains para gestionar la facturación de los dominios que hayas registrado con el servicio.

Uso gratuito

Cloud Domains no ofrece uso gratuito para el registro de dominios. Consulta la página de cuotas para obtener más información al respecto.

Tabla de precios

SKUs de facturación

A la hora de buscar SKUs adecuados para el modelo de facturación correspondiente a tu registro, transferencia o renovación, utiliza los siguientes enlaces:

• Todos los SKUs de Cloud Domains
• SKUs de facturación de suscripciones
• SKUs de facturación de compromisos
• SKUs de cancelación

Ejemplo de precios

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

Ejemplo 1

Facturación de suscripciones: compras un dominio .com por 12 USD. En la próxima factura mensual se te cobrarán 12 USD. El próximo cargo se hará un año después de que se renueve el dominio por 12 USD.

Facturación de compromisos: compras un dominio .com por 12 USD. En la próxima factura mensual se te cobrará 1 USD y pagarás 1 USD cada ciclo de facturación mensual hasta que caduque el dominio. Si decides eliminar el dominio después de que se te haya facturado un total de 5 meses (5 USD en total), se te cobrará una tarifa de cancelación de 7 USD, de forma que el importe facturado total sea de 12 USD.

Ejemplo 2

Imagina que has registrado tres dominios: example.charity, example.wiki y example.info.

El precio es:

.charity = 30 USD al año

.wiki = 28 USD al año

.info = 12 USD al año

Coste de la suscripción = 30 USD + 28 USD + 12 USD = 70 USD al año

Facturación de compromisos = 1/12 del precio anual (70 USD/12 = 5,83 USD/mes)