O App Hosting requer um projeto que esteja no plano de preços Blaze de pagamento por uso. Nesse plano de preços, seu projeto tem os seguintes limites sem custo financeiro para os produtos do Google Cloud invocados pelo App Hosting:
| Produto | Recurso | Sem custos financeiros | Cobrado (pelo uso além dos limites sem custo financeiro) |
|---|---|---|---|
| App Hosting | Largura de banda de saída | 10 GiB / mês | US$ 0,15 / GiB em cache US$ 0,20 / GiB não armazenado em cache |
| Artifact Registry | Armazenamento | 0,5 GB/mês | US$ 0,10 / GB / mês para mais de 0,5 GB |
| Saída | Sem custo financeiro | Consulte os preços do Artifact Registry para ver uma lista completa de preços de saída | |
| Cloud Run | CPU | 180 mil vCPU-segundos | US$ 0,00002400 / vCPU-segundo |
| Memória | 360 mil GiB-segundos | US$ 0,00000250 / GiB-segundo | |
| Solicitações | 2 milhões de solicitações | US$ 0,40 / milhão de solicitações | |
| Cloud Build | Minutos de build | 2.500 minutos de build | US$ 0,006 / minuto de build |
| Cloud Logging | Armazenamento do Logging | 50 GiB / projeto / mês | US$ 0,50/GiB |
| Retenção de registros | Sem custo financeiro por 30 dias | US$ 0,01 / GiB / mês para registros retidos por mais de 30 dias | |
| Secret Manager | Versões de secret ativas | 6 versões / mês | US$ 0,06 por versão/local |
| Operações de acesso | 10.000 operações / mês | US$ 0,03 por 10.000 operações | |
| Notificações de rotação | 3 rotações/mês | US$ 0,05 por rotação | |
| Cloud Storage1 | Standard Storage2 | 5 GB por mês | US$ 0,020 por GB ao mês |
| Operações de classe A2 | 5.000 | US$ 0,0050 por 1.000 operações | |
| Operações de classe B2 | 50.000 | US$ 0,0004 por 1.000 operações | |
| Transferência de dados2 | 100 GB da América do Norte para cada destino de transferência de dados do Google Cloud (exceto Austrália e China) | US$ 0,02 / GB para a América do Norte US$ 0,02 / GB para a Europa US$ 0,08/GB para a Ásia |
1Cloud Storage é usado apenas ao implantar de uma origem local com a CLI Firebase ou ao fazer upload de um arquivo compactado no console do Firebase.
2Cloud Storage As cotas do nível Sempre sem custo financeiro se aplicam apenas aos back-ends do App Hosting em US-CENTRAL1.
O uso sem custo financeiro é agregado entre projetos por conta de faturamento e é redefinido todos os meses. Você só recebe cobranças pelo uso que ultrapassar os limites.
Calcular custos
Seu projeto do Firebase App Hosting vai gerar custos quando você exceder as cotas sem custo financeiro do plano de preços Blaze de pagamento por uso. Você vai receber cobranças pelos seguintes itens de linha do Firebase App Hosting:
Largura de banda de saída não armazenada em cache refere-se aos dados transferidos diretamente dos servidores de origem do serviço do Firebase App Hosting para atender às solicitações dos usuários. Os servidores de origem estão localizados entre o serviço Cloud Run de um back-end do App Hosting e o Cloud CDN. Isso ocorre quando o conteúdo solicitado ainda não está armazenado no cache do Cloud CDN (ou seja, não está em cache). Consequentemente, o servidor de origem precisa buscar os dados e enviá-los ao usuário.
Esse processo gera custos por dois motivos principais:
- Preenchimento de caches do Cloud CDN: quando um usuário solicita conteúdo não armazenado em cache, isso aciona um processo para buscar esses dados no servidor de origem e armazenar uma cópia no cache do Cloud CDN para solicitações futuras. Essa transferência inicial de dados da origem para a CDN contribui para o custo geral.
- Transferência de dados para o usuário final: quando o conteúdo estiver disponível (diretamente da origem ou da CDN após o preenchimento inicial do cache), ele precisará ser transmitido para o dispositivo do usuário final no destino solicitado. Essa transferência de dados também contribui para o custo.
Largura de banda de saída em cache se refere aos dados transferidos em gibibytes dos caches do Cloud CDN para o dispositivo do usuário final no destino solicitado.
Consulte Armazenar conteúdo do app em cache para saber como otimizar o desempenho com o Cloud CDN.
Você também vai receber cobranças pelo uso dos produtos do Google Cloud que seu back-end usa:
- Cloud Run
- Cloud Build
- Artifact Registry
- Secret Manager
- Cloud Logging
- Cloud Storage
As faixas de preços exatas desses itens de linha podem ser consultadas na nossa página de preços.
Exemplos de faturamento
O custo de execução de um app da Web dinâmico no App Hosting pode variar muito dependendo de fatores como tráfego, configurações de ambiente de execução e tamanho da resposta. Os custos no nosso exemplo se baseiam em determinadas suposições sobre esses fatores.
Tráfego e tamanho da resposta
Depois que o app atingir a cota mensal sem custo financeiro, cada visita ao site vai gerar custos. Esses custos não são fixos. Eles dependem de fatores como o número de solicitações em segundo plano acionadas por cada visita, a capacidade de computação necessária para criar a resposta e o tamanho dela. Algumas solicitações são mais caras do que outras. Por exemplo, provavelmente vai custar mais para exibir uma página cheia de imagens ou dados complexos do que um arquivo HTML simples. Da mesma forma, gerar uma página dinamicamente no servidor geralmente é mais caro do que exibir uma versão em cache de uma CDN.
Para estimar os custos do seu app de forma eficaz, considere algumas métricas importantes:
- Solicitações por visita: quantas solicitações individuais uma visita típica de usuário aciona? Lembre-se de que um "carregamento de página" geralmente envolve muitas solicitações subjacentes de recursos, como imagens, CSS e JavaScript.
- Tamanho médio da resposta: qual é o tamanho típico dos dados enviados de volta para cada solicitação?
- Latência média de resposta: quanto tempo leva para o app responder a uma solicitação, em média?
É possível estimar esses valores inspecionando os registros de solicitação do app no console do Google Cloud. Nossos exemplos de cálculo de custo pressupõem o seguinte:
| Características do tráfego | |
|---|---|
| ~Solicitações faturadas por visita única | 10 |
| Tamanho médio da resposta (KiB) | 400 |
| Latência média de resposta (ms) | 1000 |
| Taxa de ocorrência em cache | 50% |
Configurações do ambiente de execução
| Configurações de Cloud Run1 | |
|---|---|
| Limite de CPU (vCPU) | 1 |
| Limite de memória (MiB) | 512 |
| Simultaneidade (solicitações) | 80 |
| minInstances | 0 |
| maxInstances | 100 |
1 Estes são os valores padrão fornecidos por App Hosting. É possível verificar a configuração do Cloud Run para cada lançamento visualizando os detalhes da revisão do Cloud Run. Na guia Lançamentos no console do Firebase, passe o cursor sobre um lançamento e selecione o menu de três pontos. Em seguida, selecione "Ver revisão do Cloud Run".
Outras suposições
| Uso do projeto | |
|---|---|
| Método de implantação | GitHub |
| Builds por mês | 20 |
| Minutos por build | 8 |
| Retenção de registros | < 30 dias |
| Versões de secret | < 6 versões |
| Tamanho da imagem do Artifact Registry (MB) | 380 |
Exemplo de fatura
Com essas suposições, podemos extrapolar os seguintes custos para este cenário de exemplo. Com 10 mil visitas, praticamente não há custos. Os custos começam a ser significativos a partir de 1 milhão de visitas, em que uma visita é uma solicitação ao app iniciada por um usuário.
| SKU | Preço | Unidade | Nível sem custo financeiro | Uso de 10 mil visitas | Custo de 10 mil visitas | Uso de 1 milhão de visitas | Custo de 1 milhão de visitas |
|---|---|---|---|---|---|---|---|
| Cloud Run - CPU | US$ 0,00 |
vCPU por segundo | 180.000,00 |
1250 |
US$ 0,00 |
125000 |
US$ 0,00 |
| Cloud Run: memória | US$ 0,00 |
GiB por segundo | 360.000,00 |
625 |
US$ 0,00 |
62500 |
US$ 0,00 |
| Cloud Run: solicitações | US$ 0,40 |
Milhões de solicitações de SSR | 2,00 |
0,05 |
US$ 0,00 |
5 |
US$ 1,20 |
| Cloud Build: minutos de build | US$ 0,006 |
minuto de build | 2.500,00 |
160 |
US$ 0,00 |
160 |
US$ 0,00 |
| Artifact Registry: armazenamento | US$ 0,10 |
GiB (armazenados) | 0,50 |
0,6 |
US$ 0,01 |
0,6 |
US$ 0,01 |
| App Hosting: largura de banda de saída sem cache | US$ 0,20 |
GiB | 10 |
2 |
US$ 0,00 |
200 |
US$ 39,00 |
| App Hosting: largura de banda de saída em cache | US$ 0,15 |
GiB | 2 |
US$ 0,00 |
200 |
US$ 29,25 |
|
| Secrets Manager: versões ativas de secrets | US$ 0,06 |
versões | 6,00 |
6,00 |
US$ 0,00 |
6,00 |
US$ 0,00 |
| Secret Manager: operações de acesso | US$ 0,03 |
10 mil operações | 1.0 |
0,10 |
US$ 0,00 |
5,00 |
US$ 0,12 |
| Secrets Manager: notificações de rotação | US$ 0,05 |
rotações | 3,00 |
0,00 |
US$ 0,00 |
0,00 |
US$ 0,00 |
| Cloud Logging: armazenamento de registros | US$ 0,50 |
GiB | 50,00 |
0,50 |
US$ 0,00 |
50,00 |
US$ 0,00 |
| Cloud Logging: retenção de registros | US$ 0,01 |
GiB / mês | 30 dias | US$ 0,00 |
US$ 0,00 |
||
| Total | 0,01 |
US$ 69,58 |
Cálculos
| SKU | Unidade | Como calcular o uso |
|---|---|---|
| Cloud Run: CPU | vCPU por segundo | Segundos de vCPU = vCPU por instância * latência média de resposta por solicitação * número de visitas * solicitações faturadas por visita / número de solicitações simultâneas |
| Cloud Run: memória | GiB por segundo | GiB-segundos = GiB por instância * latência média de resposta por solicitação * número de visitas * solicitações faturadas por visita / número de solicitações simultâneas |
| Cloud Run: solicitações | Milhões de solicitações de SSR | Solicitações de SSR em milhões = (nº de visitas * solicitações faturadas por visita / 1 milhão) * (1 - taxa de ocorrência em cache) |
| Cloud Build: minutos de build | minuto de build | minutos de build = número de builds * minutos por build |
| Artifact Registry: armazenamento 1 | GiB (armazenados) | GiB (armazenado) = 2 * tamanho da imagem |
| App Hosting: largura de banda sem cache | GiB | GiB sem cache= (1 - taxa de ocorrência em cache) * (nº de visitas * solicitações faturadas por visita * largura de banda de saída por solicitação) |
| App Hosting: largura de banda em cache | GiB | GiB em cache = taxa de ocorrência em cache * (número de visitas * solicitações faturadas por visita * largura de banda de saída por solicitação) |
1 O App Hosting limpa automaticamente as imagens mais antigas em Artifact Registry, mantendo as imagens de builds bem-sucedidos nos últimos 14 dias (e sempre mantendo pelo menos os cinco builds bem-sucedidos mais recentes, além do build ativo). Consulte Política de limpeza de build.