Google Cloud detecta egress; valide antes de mover dados

Para usar o Storage Intelligence Advisor, abra a página do produto no console do Google Cloud, selecione o projeto, a pasta ou a organização e examine Top findings. O serviço detecta aumentos de egress entre regiões, mas o alerta não determina sozinho se a arquitetura está errada: desça até o projeto e o bucket afetados e confirme quem acessou os dados, de onde e por quanto tempo.

Não aceite a recomendação como autorização para mover o bucket. Primeiro diferencie uma mudança permanente de uma carga planejada, estime todos os componentes do custo e verifique permissões, retenção, recuperação e VPC Service Controls. Sem essa validação, a relocação pode apenas deslocar o custo ou afastar os dados de outros consumidores.

Abra o painel no escopo que permita investigar

O procedimento oficial de visualização orienta escolher o recurso, consultar At a glance e abrir um cartão em Top findings. Em pastas e organizações, os cartões agregam os projetos afetados; ao entrar em um projeto, a investigação alcança os buckets com maiores aumentos e, nos detalhes do bucket, os prefixos e as contas de serviço que mais contribuíram para a mudança.

O Google indica o papel Storage Admin para reunir as permissões necessárias e admite papéis personalizados ou outros papéis predefinidos. Como Storage Admin é amplo, a recomendação editorial para ambientes com separação de funções é conceder apenas as permissões de leitura exigidas pelo painel e pelo Cloud Monitoring. Se a visão de pasta ou organização marcar projetos sem acesso, trate o resumo como incompleto; a ausência de dados não demonstra ausência de anomalias.

Decida conforme o tipo de finding

A visão geral oficial do Advisor define quatro findings: operações Classe A ou B elevadas em dados Coldline ou Archive, pico de erros 429, aumento de egress entre regiões e crescimento do volume armazenado acima da tendência dos últimos 30 dias. A mesma página esclarece que o VPC Service Controls protege a API do Advisor somente para recursos no nível de projeto, embora o produto também possa ser habilitado em pastas e organizações.

Operações em Coldline ou Archive: descubra quais prefixos e identidades concentram o aumento. Se uma rotina passou a acessar esses objetos frequentemente, compare a classe atual com uma classe adequada a leituras recorrentes. Se houve apenas uma reindexação ou restauração com término conhecido, uma troca permanente de classe pode ser desnecessária.
Erros 429: confronte o horário do pico com implantações e execuções em lote. Quando a taxa legítima cresceu abruptamente, aplique backoff exponencial e elevação gradual da carga. Se um único emissor explica o aumento, corrija-o antes de alterar o desenho de todos os consumidores.
Crescimento acima da tendência: separe ingestão esperada de acúmulo involuntário. Verifique versões não atuais, objetos temporários, retenção e políticas de ciclo de vida. Não programe exclusões ou transições sem confirmar as obrigações de retenção e o processo de restauração.
Egress entre regiões: identifique o bucket de origem, a região de cada consumidor, as identidades responsáveis e a duração do comportamento. A colocalização merece análise quando o acesso é recorrente; em migrações, contingências ou processamentos temporários, monitore o fim da carga antes de redesenhar.

Confirme o egress fora do alerta agregado

Comece pelo consumidor. Compare o horário do finding com mudanças de região, novos jobs, destinos de análise, rotinas de recuperação e implantações. O painel mostra a anomalia e seus principais contribuintes, mas a decisão exige relacioná-los aos registros de mudança e aos dados de cobrança da mesma janela.

Depois verifique a persistência. Um finding de atividade anterior confirma que houve um desvio em relação ao histórico, não que o padrão continuará. Observe pelo menos um ciclo operacional compatível com a carga — diário, semanal ou mensal — ou use a agenda do job para demonstrar que o acesso se repetirá.

Por fim, mapeie todos os leitores do bucket, não apenas o que gerou o maior pico. Processamento em lote, análise, restauração e ambientes de contingência podem estar em regiões diferentes. Aproximar o armazenamento do consumidor principal pode elevar a transferência ou a latência para os demais; nesses casos, mudar o processamento, reduzir leituras repetidas ou investigar os objetos acessados pode ser mais adequado que relocalizar o bucket.

Calcule o custo total da mudança

A seção de preços da relocação de buckets inclui cobrança pelos dados movidos, transferência entre regiões, operações Classe A por objeto e armazenamento simultâneo nas localizações de origem e destino durante o processo. Também podem existir cobranças de replicação quando o destino é uma região dupla ou multirregião; a própria página informa que a relocação não gera taxa de recuperação nem cobrança por exclusão antecipada na limpeza da origem.

Compare dois cenários para o mesmo horizonte: manter o padrão atual e executar a relocação. No primeiro, considere o egress recorrente, as operações e eventuais taxas de recuperação da classe de armazenamento. No segundo, some a movimentação, as operações por objeto, a duplicação temporária do armazenamento, a replicação aplicável e o custo futuro dos consumidores que permanecerem longe do novo destino.

Essa comparação precisa usar a quantidade de objetos, e não apenas o volume em bytes. Dois buckets com o mesmo tamanho podem gerar custos de operação diferentes se um deles contiver muito mais objetos. Inclua ainda a margem operacional para novas sincronizações de metadados enquanto a mudança estiver em andamento.

Separe diagnóstico, autorização e proteção

O finding reduz o espaço de investigação; ele não concede permissão para alterar localização, classe ou ciclo de vida. Antes da execução, registre o proprietário dos dados, os consumidores afetados, a janela da mudança, o procedimento de reversão e as restrições de residência, retenção e recuperação.

Para recursos protegidos por VPC Service Controls, faça a análise e a operação no nível do projeto dentro do perímetro. Visões de pasta e organização continuam dependendo de IAM e não passam a integrar automaticamente um perímetro. Também mantenha separadas as permissões para visualizar o diagnóstico e para modificar buckets.

Se a atividade é aprovada, temporária e tem término conhecido, monitore antes de mover.
Se um job, prefixo ou principal explica o pico, corrija o consumidor e meça novamente.
Se o padrão é recorrente, todos os consumidores foram mapeados e a economia futura supera o custo total da mudança, planeje a relocação com os proprietários dos dados.
Se faltam projetos, identidades, destinos, estimativas de cobrança ou validações de segurança, não execute a recomendação.

Google Cloud detecta egress inesperado — o alerta não corrige a arquitetura