A transferência de dados pode ser o tráfego que entra em um recurso do Google Cloud (por exemplo, VM), sai da região do Google Cloud para a Internet ou fica entre dois recursos no Google Cloud.

Uma região é um conjunto de edifícios operados pelo Google em uma localização geográfica, como um campus de data center. O tráfego pode se movimentar da seguinte maneira:

• No conjunto de edifícios do local, que sempre usou a rede do Google (preços intrazona e intrarregional).
• Para outro edifício operado pelo Google em outro local, que sempre usou a rede do Google (preço entre regiões).
• Para um local não operado pelo Google usando uma conexão do Cloud Interconnect (preços do Cloud Interconnect)
• Para um local não operado pelo Google que não usa uma conexão do Cloud Interconnect (preços de transferência de dados para fora pela Internet)

O nível Premium dos Níveis de serviço de rede usa o backbone premium do Google para transportar tráfego de e para seus usuários externos. A Internet geralmente é usada apenas entre o usuário e o ponto de entrada mais próximo da rede do Google.

O nível Standard dos Níveis de serviço de rede usa a Internet para transportar tráfego entre seus serviços e usuários. Embora usar a Internet pública forneça um serviço de qualidade inferior, é mais econômico do que o Nível Premium.

Esta seção abrange o tráfego que sai de uma VM do Google Cloud e vai para outra VM do Google Cloud. O custo é atribuído ao projeto da VM que está enviando o tráfego. Este preço afeta VMs do Compute Engine, nós do Google Kubernetes Engine (GKE) e VMs que executam o ambiente flexível do App Engine.

Os preços a seguir se aplicam durante e depois do período de teste gratuito do Google Cloud. Durante esse período, esses valores são cobrados com base no total de crédito do Teste gratuito.

Transferência de dados de VM para VM quando a VM de origem e a de destino estão em zonas diferentes da mesma região do Google Cloud

Transferência de dados de VM para VM quando as VMs de origem e de destino estão em regiões diferentes do Google Cloud. Todos os preços são por GiB em USD

Esta seção abrange o tráfego que sai de uma VM do Google Cloud e vai para um serviço do Google. O custo é atribuído ao projeto da VM que está enviando o tráfego. Este preço afeta VMs do Compute Engine, nós do Google Kubernetes Engine e VMs que executam o ambiente flexível do App Engine.

Os preços a seguir se aplicam durante e depois do período de teste gratuito do Google Cloud. Durante esse período, esses valores são cobrados com base no total de crédito do Teste gratuito.

O nível Premium é o nível padrão para todas as transferências de dados do Google Cloud. Para usar o nível Standard, é necessário especificá-lo explicitamente.

Os preços a seguir se aplicam durante e depois do período de teste gratuito do Google Cloud. Durante esse período, esses valores são cobrados com base no total de crédito do Teste gratuito.

Importante: a partir de 1º de fevereiro de 2024, vamos aumentar o preço de algumas SKUs para transferência de dados de Internet de saída no nível Premium. Para mais informações, consulte Anúncio de mudança de preços para transferência de dados.

O preço da transferência de dados para fora do Google é calculado pelos GiBs enviados. O preço se baseia na geolocalização do tráfego de origem. O preço de entrada ainda é gratuito.Os limites de uso do programa Sempre gratuito não se aplicam ao nível Standard.

Não há custos para endereços IP internos estáticos ou temporários.

As cobranças de endereços IP externos estáticos e temporários são feitas de acordo com a tabela a seguir.

Se você reservar um endereço IP externo estático e não atribuí-lo a um recurso, como uma instância de VM ou uma regra de encaminhamento, receberá uma cobrança com uma taxa maior que a dos endereços IP externos estáticos e temporários que estiverem em uso.

Você não é cobrado pelos endereços IP externos estáticos atribuídos a regras de encaminhamento.

Não são geradas cobranças pelos intervalos de endereços IPv6 externos atribuídos a sub-redes ou por endereços IPv6 externos atribuídos a instâncias de VM. Você não paga por endereços IPv6 regionais estáticos (Visualização).

O Google Cloud considera que um endereço IP externo está em uso quando ele está associado a uma instância de VM em execução ou interrompida. Se a instância for excluída, ou o endereço IP não estiver associado à instância, o Google Cloud considerará que o endereço IP estático não está em uso.

No caso do endereço IP temporário, o Google Cloud considera que ele está em uso apenas quando a instância de VM associada está em execução. Quando a instância é interrompida ou excluída, o Google Cloud libera o endereço IP temporário e não o considera mais em uso.

Para verificar se um endereço IP externo estático está em uso, faça uma solicitação gcloud compute addresses list. Esse comando retorna uma lista de endereços IP externos estáticos e os status correspondentes:

Neste exemplo, o IPv4 address-1 está em uso, enquanto o IPv4 address-2 está reservado, mas não em uso. Ambos os endereços são cobrados de acordo com a tabela de preços de endereços IP externos neste documento.

Observação: se o mesmo endereço IP for atribuído a mais de uma regra de encaminhamento, o Google Cloud contará e adicionará cada uso do endereço à cota IN_USE_ADDRESSES, em vez de uma contagem exclusiva de objetos de endereço IP usados.

Para conferir os preços do Cloud Next Generation Firewall, consulte a página de preços do Cloud NGFW.

Os custos associados ao Private Service Connect variam de acordo com a configuração.

Como usar um endpoint do Private Service Connect (regra de encaminhamento) para acessar APIs do Google

Como usar um back-end do Private Service Connect (balanceador de carga) para acessar as APIs do Google

Back-ends do Private Service Connect usam um balanceador de carga para acessar as APIs do Google. Todos os preços do balanceador de carga se aplicam. O tráfego para NEGs do Private Service Connect que é direcionado a APIs do Google gera cobranças de balanceamento de carga para dados processados pelo balanceador de carga. No entanto, não há cobrança do Private Service Connect pelo tráfego de transferência de dados entre o NEG do Private Service Connect e as APIs do Google.

Para informações sobre preços do seu balanceador de carga, consulte os preços de balanceadores de carga de aplicativo externos globais ou balanceadores de carga de aplicativo internos.

Observação: os back-ends do Private Service Connect eram chamados de endpoints do Private Service Connect com controles de serviço HTTP(S) do consumidor.

Observação: para endpoints com acesso global, o projeto de produtor de serviços não é cobrado pela transferência de dados inter-regional, mesmo que os recursos do consumidor de serviço acessem o endpoint de outras regiões.

O Private Service Connect cria automaticamente um namespace do Diretório de serviços para registrar endpoints. Um único namespace padrão é usado para endpoints na mesma região de um projeto, a menos que você crie explicitamente namespaces adicionais. Para mais informações, consulte Preços do Diretório de serviços.

Como usar um back-end do Private Service Connect (balanceador de carga) para acessar um serviço publicado

Back-ends do Private Service Connect usam um balanceador de carga para acessar serviços publicados. Todos os preços do balanceador de carga se aplicam. O tráfego entre NEGs do Private Service Connect e serviços publicados pelo serviço gera cobranças de balanceamento de carga para dados processados pelo balanceador de carga e cobranças do Private Service Connect para tráfego de transferência de dados entre o NEG e o serviço publicado.

A tabela a seguir resume as cobranças aplicáveis para essa configuração.

Usar uma interface do Private Service Connect para acessar uma rede VPC de produtor ou consumidor

Diretório de serviços

O Private Service Connect cria automaticamente um namespace do Diretório de serviços para registrar endpoints ao acessar APIs do Google ou ao acessar serviços publicados. Um namespace padrão do Diretório de serviços é criado para os endpoints do Private Service Connect na mesma região de um projeto. Para mais informações, consulte os Preços do Diretório de serviços.

Os consumidores do Private Service Connect pagam pelo processamento de dados de consumidor de acordo com a tabela a seguir. O processamento de dados de consumidor é cobrado para entrada e saída.

Cobranças para publicar um serviço gerenciado usando um anexo de serviço do Private Service Connect

Não há cobranças horárias do Private Service Connect ou de transferência de dados para publicar serviços usando anexos de serviço. Os produtores são cobrados por qualquer taxa de balanceamento de carga incorrida no balanceador de carga publicado para os consumidores.

Observação: se os recursos usarem um endpoint com acesso global para acessar um serviço publicado de uma região diferente, o projeto de produtor de serviços não será cobrado pela transferência de dados inter-regional. Para informações sobre cobranças de projetos de consumidores de serviços, consulte Como usar um endpoint do Private Service Connect (regra de encaminhamento) para acessar um serviço gerenciado publicado.

Implantar um serviço usando mapas de conexão de serviço

Quando você implanta um serviço usando mapas de conexão de serviço, não há cobranças para o produtor pela implantação dos mapas. No entanto, o consumidor é cobrado pelo seguinte:

• Recursos implantados no projeto do consumidor pela automação de conectividade do serviço
• Como usar um endpoint do Private Service Connect para acessar um serviço publicado.

Quando você cria uma conexão de acesso a serviços particulares, não há cobranças por hora ou dados para a conexão em si. No entanto, você vai pagar pelos seguintes itens:

• Recursos provisionados na rede do produtor de serviços
• Tráfego de transferência de dados das suas VMs para a rede do produtor de serviços

O acesso VPC sem servidor tem os preços a seguir.

Os registros de rede vendidos geram cobranças. Você será cobrado pelos seguintes produtos:

Você é cobrado com base na quantidade de dados processados pelo espelhamento de pacotes. As regras de encaminhamento do Espelhamento de pacotes não são cobradas. Atualmente, não há cobrança adicional por VM para usar esse recurso. A tabela abaixo apresenta os custos relacionados aos dados processados pelo espelhamento de pacotes.

As tabelas de preços nesta seção se aplicam aos seguintes balanceadores de carga:

• Balanceadores de carga de rede de passagem interna e externa
• Balanceadores de carga de rede de proxy interno e externo
• Balanceadores de carga de aplicativo externos globais, clássicos e regionais

Para balanceadores de carga de aplicativo internos regionais e entre regiões, consulte a seção Balanceador de carga de aplicativo interno.

Para mais informações sobre as regras de encaminhamento do Private Service Connect, consulte a seção desse produto.

A tabela a seguir mostra os preços das regras de encaminhamento global. Não há cobranças de processamento de dados global. O processamento de dados é cobrado pela região, dependendo de onde o tráfego é processado.

A tabela a seguir mostra as cobranças por regra de encaminhamento regional e por processamento de dados de entrada e saída por região.

Os usuários do balanceador de carga de aplicativo externo global podem usar o Google Cloud Armor, o Cloud CDN ou ambos para minimizar o impacto das cobranças de processamento de dados de saída.

• Cloud CDN: objetos estáticos exibidos ao cliente a partir do cache não transitam pelo balanceador de carga. Uma estratégia de armazenamento em cache eficaz pode reduzir a quantidade de dados de saída que estão sendo processados pelo balanceador de carga e reduzir os custos. Para implementar o armazenamento em cache, é necessário entender qual parte do tráfego é estática e pode ser armazenada em cache. Para mais informações, consulte a documentação do Cloud CDN.
• Cloud Armor:se o aplicativo receber uma quantidade significativa de tráfego indesejado, implante o Cloud Armor para bloquear esse tráfego. As solicitações bloqueadas pelo Cloud Armor não transitam pelo balanceador de carga, o que reduz efetivamente a quantidade de dados de saída processados pelo balanceador de carga. O impacto nos custos depende da porcentagem de tráfego indesejado bloqueado pelas políticas de segurança do Cloud Armor implementadas.

Se o aplicativo puder ou precisar operar em uma única região, use o balanceador de carga de aplicativo externo regional. O balanceador de carga de aplicativo externo regional usa apenas o nível de rede Standard, que tem custos de transferência de dados de saída mais baixos e é uma opção econômica.

Se você estiver usando back-ends de NEG sem servidor com um balanceador de carga de aplicativo externo (global, regional ou clássico), as cobranças de balanceador de carga atuais serão aplicadas além das cobranças de computação sem servidor para back-ends do Cloud Run, do Cloud Run functions ou do App Engine, conforme aplicável. Se o Google Cloud Armor ou Cloud CDN forem usados, suas respectivas cobranças também se aplicarão.

No entanto, você não será cobrado por transferências de dados de saída sem servidor. Apenas as taxas de transferência de dados de saída da Internet se aplicam. As cobranças de transferência de dados de saída do Cloud Functions, de tráfego de rede de saída do App Engine e de transferência de dados do Cloud Run não se aplicam a solicitações transmitidas de um balanceador de carga de aplicativo externo (usando NEGs sem servidor) para um serviço do Cloud Run functions, do App Engine ou do Cloud Run.

Revise os pontos a seguir para entender como os projetos e as contas de faturamento são cobrados por SKUs de rede quando você usa a referência de serviço entre projetos.

• As cobranças relacionadas ao Cloud Load Balancing sempre são atribuídas ao projeto em que a regra de encaminhamento está configurada (projeto de serviço A na figura 1). Isso inclui cobranças por regras de encaminhamento, dados de entrada processados e dados de saída processados pelo balanceador de carga de aplicativo externo global. Revise os preços básicos do Cloud Load Balancing.
• A transferência de dados para fora do Google da rede para a Internet nos níveis Premium e Standard sempre é atribuída ao projeto em que a regra de encaminhamento está configurada (projeto de serviço A na Figura 1). Consulte os preços de transferência de dados de rede.
• Se você configurar o Cloud CDN em um serviço de back-end referenciado por um mapa de URL usando a referência de serviço entre projetos, todos os encargos do Cloud CDN para conteúdo armazenável em cache (transferência de dados de saída de cache, pesquisa de cache, preenchimento de cache) serão sempre atribuídos ao projeto que contém o serviço de back-end com o Cloud CDN ativado (projeto de serviço B na Figura 1), e não ao projeto que configurou as regras de encaminhamento. Consulte os preços do Cloud CDN.
• Se você configurar o Google Cloud Armor em um serviço de back-end referenciado por um mapa de URL usando a referência de serviço entre projetos, todos os encargos relacionados ao Google Cloud Armor serão atribuídos ao projeto que contém o serviço de back-end com o Google Cloud Armor ativado (projeto de serviço B na figura 1), e não ao projeto que configurou as regras de encaminhamento. Confira os preços do Google Cloud Armor. Especificamente, todas as cobranças do nível padrão e do nível Enterprise do Google Cloud Armor são atribuídas ao projeto de serviço B.

As considerações adicionais a seguir também se aplicam quando você usa o Cloud Armor com referência de serviço entre projetos:

• As mudanças na assinatura relacionadas ao Cloud Armor Enterprise são atribuídas à conta de faturamento que você especificou durante a inscrição. Se você quiser usar a mesma assinatura do Cloud Armor Enterprise em vários projetos para incluir todos os serviços de back-end referenciados usando a referência de serviço entre projetos, inclua todos os projetos de serviço relevantes como parte da mesma conta de faturamento do Cloud Armor Enterprise.
• Quando você usa a referência de serviço entre projetos, alguns recursos oferecidos no Cloud Armor Enterprise, como a telemetria e a resposta a DDoS, exigem a inscrição no nível do Cloud Armor Enterprise para o projeto de regras de encaminhamento do front-end e os projetos de serviços de back-end.

O Google Cloud cobra pelas regras de encaminhamento criadas para o balanceamento de carga ou outros usos, como o espelhamento de pacotes.

Os exemplos a seguir usam preços em US$:

É possível criar até cinco regras de encaminhamento pelo preço de US$ 0,025/hora. Por exemplo, se você criar uma regra de encaminhamento, será cobrado US$ 0,025/hora. Se você tiver três regras de encaminhamento, ainda será cobrado US$ 0,025/hora. No entanto, se você criar 10 regras de encaminhamento, a cobrança será assim:

• Cinco regras de encaminhamento = US$ 0,025/hora
• Cada regra de encaminhamento adicional = US$ 0,01/hora

US$ 0,025/hora por cinco regras + (cinco regras adicionais * US$ 0,01/hora) = US$ 0,075/hora

Para a maioria dos casos de uso do balanceamento de carga, somente uma regra de encaminhamento é necessária por balanceador de carga.

No Google Cloud, a cobrança pelas regras de encaminhamento globais e regras de encaminhamento regionais é feita separadamente e por projeto. Por exemplo, se você usar uma regra de encaminhamento global e outra regional em dois projetos separados (ou seja, quatro no total), a cobrança será de US$ 0,10/hora (4 x US$ 0,025/hora).

Para estimar as cobranças do balanceamento de carga, siga as etapas:

1. Acesse a calculadora de preços.
2. Na guia Cloud Load Balancing.
3. No menu suspenso, selecione a região.
4. Insira o número aproximado de regras de encaminhamento.
5. Digite a quantidade mensal estimada de tráfego de rede processado.

Exemplo:

• Iowa
• Número de regras de encaminhamento: 10
• Tratamento de dados de entrada pelo balanceador de carga: 2.048 GiB
• Custo total estimado: USD 71,13 por 1 mês

Esse exemplo não inclui o custo de transferência de dados para fora do Google para a Internet do envio de respostas dos back-ends.

As cobranças a seguir se aplicam a balanceadores de carga de aplicativo internos regionais e entre regiões. Alguns custos de transferência de dados entre regiões também se aplicam ao balanceador de carga de aplicativo interno entre regiões.

Os balanceadores de carga baseados em Envoy fazem o escalonamento automático do número de proxies disponíveis para lidar com seu tráfego com base nas necessidades específicas. A taxa de instância de proxy é baseada no número de instâncias de proxy necessárias para atender às suas necessidades de tráfego. Cada proxy adicional gera uma taxa por hora adicional de acordo com os preços indicados na tabela de preços.

O número de proxies alocados para o balanceador de carga é calculado com base na capacidade medida necessária para lidar com seu tráfego em um período de 10 minutos. Durante esse tempo, analisamos o maior valor de:

• número de proxies necessários para atender às necessidades de largura de banda do seu tráfego. Cada instância de proxy pode processar até 18 MB por segundo. Monitoramos a largura de banda total necessária e dividimos esse total pela largura de banda que uma instância de proxy pode suportar.
• O número de proxies necessários para processar conexões e solicitações. Contamos o total de cada um dos seguintes recursos e dividimos cada valor pelo que uma instância de proxy pode processar:
• 600 (HTTP) ou 150 (HTTPS) conexões novas por segundo
• 3.000 conexões ativas
• 1.400 solicitações por segundo*

* Uma instância de proxy pode processar 1.400 solicitações por segundo se o Cloud Logging estiver desativado. Se você ativa o Cloud Logging, sua instância de proxy pode processar menos solicitações por segundo. Por exemplo: gerar registros de 100% das solicitações diminui a capacidade de processamento de solicitações do proxy para 700 solicitações por segundo. Você pode configurar o Cloud Logging para analisar uma porcentagem menor de tráfego. Isso permite que você atenda às suas necessidades de observabilidade enquanto controla seu custo.

Em um período de 10 minutos, 180 MB por segundo de dados são transmitidos pelo balanceador de carga. 180 MB por segundo / 18 MB por segundo por instância de proxy = 10 instâncias de proxy

Durante o mesmo período, 300 novas conexões HTTPS são estabelecidas por segundo, 3.000 conexões estão ativas e 2.800 solicitações são enviadas por segundo:

300 novas conexões HTTPS por segundo / 150 novas conexões HTTPS por segundo por instância de proxy = 2 instâncias de proxy 3.000 conexões ativas / 3.000 conexões ativas por instância de proxy = 1 instância de proxy 2.800 solicitações por segundo / 1.400 solicitações por segundo por instância de proxy = 2 instâncias de proxy.

Isso se resume a 5 instâncias de proxy. Esta quantidade é inferior às 10 instâncias de proxy necessárias para atender à largura de banda. Assim, a taxa de instância de proxy para este período de 10 minutos seria calculada da seguinte maneira:

10 instâncias de proxy * US$ 0,025 por instância de proxy por hora * (10 minutos / (60 minutos por hora)) = US $0,0417.

O faturamento é calculado com base na capacidade medida necessária para atender às suas necessidades de tráfego, não no número de instâncias de proxy que estão estabelecendo conexões com seus back-ends. Assim, você pode ser cobrado por um número diferente de instâncias de proxy do que você vê em sua infraestrutura.

Para garantir o desempenho e a confiabilidade ideais, cada balanceador de carga é alocado em pelo menos três instâncias de proxy na região do Google Cloud onde o balanceador de carga é implantado. Essas instâncias de proxy são alocadas mesmo que o balanceador de carga não processe tráfego. Depois que uma regra de encaminhamento (com esquema de balanceamento de carga INTERNAL_MANAGED) é implantada em seu projeto, você começa a acumular taxas de instância de proxy. Regras de encaminhamento adicionais geram taxas de instância de proxy adicionais conforme descrito anteriormente (em outras palavras, três instâncias de proxy adicionais por regra de encaminhamento).

As três instâncias de proxy que são alocadas ao seu balanceador de carga resultam em uma taxa mínima por hora de instância de proxy. Por exemplo, para a região us-central1 do Google Cloud, a taxa mínima é calculada da seguinte maneira:

3 instâncias de proxy * US$ 0,025 por proxy por hora = US $0,075 por hora.

Conforme descrito anteriormente, essas instâncias de proxy podem cada uma processar uma certa quantidade de tráfego. Assim que seu tráfego precisar ultrapassar a capacidade dessas três instâncias de proxy, você irá gerar custos para as instâncias de proxy necessárias para processar qualquer tráfego adicional.

A taxa de processamento de dados é calculada medindo o volume total de dados para solicitações e respostas processadas por seu balanceador de carga durante o ciclo de faturamento. Essa taxa varia de acordo com o uso, e não há taxa mínima para processamento de dados.

As cobranças por transferência de dados entre regiões se aplicam se você estiver usando um balanceador de carga de aplicativo interno entre regiões. Por exemplo, se você tiver uma implantação do balanceador de carga interno de aplicativo entre regiões em que o cliente, o proxy Envoy e o back-end estiverem em regiões separadas, as cobranças de transferência de dados entre regiões vão aparecer para cada salto separadamente (cliente <-> proxy Envoy e proxy Envoy <-> back-end). Para reduzir essas cobranças de transferência de dados entre regiões, implante proxies do Envoy em várias regiões.

Para processamento de dados, uso de instância de proxy por hora e transferência de dados de VM entre zonas, o projeto da regra de encaminhamento é cobrado.

Se você estiver usando back-ends de NEG sem servidor para um balanceador de carga de aplicativo interno, as cobranças atuais de balanceador de carga de aplicativo interno serão aplicadas além das cobranças de computação sem servidor do Cloud Run.

Os NEGs regionais da Internet exigem o uso de um gateway do Cloud NAT, o que gera cobranças adicionais. Você será cobrado pela transferência de dados para fora da Internet e pelo uso do Cloud NAT para qualquer tráfego enviado de e para a sub-rede somente de proxy do Envoy e pelo tráfego de verificação de integridade. No entanto, as cobranças do balanceador de carga se aplicam apenas ao tráfego de solicitações de usuários.

Os gateways Cloud NAT alocados para o Cloud Load Balancing geram cobranças por hora equivalentes a uma rede com mais de 32 instâncias de VM. Para detalhes, consulte Preços do Cloud NAT.

As políticas de autorização são oferecidas sem taxas de uso durante a visualização;

Se um serviço de back-end tiver uma política do Cloud Armor associada a ele, é possível usar o recurso de cabeçalhos de solicitação personalizados com esse serviço sem nenhuma taxa adicional.

Se um serviço de back-end que usa o recurso de cabeçalhos de solicitação personalizados não tiver uma política do Cloud Armor associada a ele, haverá cobrança de US $0,75 a cada 1.000.000 solicitações HTTP(S) por mês por conta. Você receberá cobranças apenas pelas primeiras 666.666.667 solicitações por mês por conta.

O acesso global permite que as instâncias de cliente de qualquer região acessem seu balanceador de carga interno. Se uma regra de encaminhamento tiver o acesso global ativado, serão incorridos custos adicionais de transferência de dados entre regiões quando o tráfego for enviado de ou para um cliente em uma região diferente do balanceador de carga.

O acesso global está disponível para balanceadores de carga de rede de passagem interna, balanceadores de carga de aplicativo internos regionais e balanceadores de carga de rede de proxy interno regional.

A taxa de encaminhamento do protocolo é cobrada da mesma forma que o balanceamento de carga. Há uma cobrança para a regra de encaminhamento e outra para os dados de entrada processados pela instância de destino.

Não há cobrança para certificados SSL autogerenciados e gerenciados pelo Google.