Criar uma VM não é tão simples quanto parece
Criar uma instância de VM no Google Cloud Console leva menos de um minuto. Mas por trás dessa tela simples existe uma série de decisões: tipo de máquina, disco de inicialização, tags de rede, conta de serviço, script de inicialização, política de disponibilidade e comportamento de manutenção — dezenas de escolhas que moldam as características de execução da instância. Em um ambiente de desenvolvimento, os valores padrão geralmente são suficientes. Em produção, cada uma dessas escolhas determina diretamente o custo, a segurança e a disponibilidade.
O exame GCP-ACE não pergunta como clicar no assistente de criação de VM. Ele pergunta qual combinação de opções é mais adequada dado um conjunto específico de restrições. Este guia percorre os conceitos essenciais do Compute Engine que você precisa conhecer — pela perspectiva de um engenheiro que realmente opera esses recursos.
---
Opções de criação de instâncias e seleção do tipo de máquina
A primeira decisão ao criar uma VM é o tipo de máquina. O Compute Engine oferece tipos de máquina predefinidos e tipos de máquina personalizados.
| Família de máquinas | Propósito | Características | |--------------------|----------|----------------| | E2 | Propósito geral (otimizado para custo) | Cargas de trabalho Spot, servidores web de baixo custo, ambientes de desenvolvimento | | N2/N2D | Propósito geral (balanceado) | Aplicações de médio porte, bancos de dados | | C2/C3 | Otimizado para computação | HPC, servidores de jogos, processamento de alto desempenho | | M1/M2/M3 | Otimizado para memória | Bancos de dados em memória, SAP HANA, análise em grande escala | | A2/A3 | Otimizado para aceleradores | Treinamento de ML, cargas de trabalho intensivas em GPU | | T2D | Tau (eficiência em escala horizontal) | Cargas de trabalho de escalonamento horizontal, serviço web |
Os tipos de máquina personalizados permitem ajustar de forma independente a contagem de vCPU e a memória, possibilitando a otimização de custos para cargas de trabalho que não se encaixam exatamente nas famílias predefinidas.
A tabela abaixo resume as opções de criação de instâncias mais usadas e suas implicações operacionais.
| Opção | Descrição | Ponto de atenção | |-------|-----------|------------------| | Tags de rede | Aplica a VM a regras de firewall específicas | Erros de digitação nas tags impedem silenciosamente a aplicação de regras | | Conta de serviço | Concede à VM permissão para chamar APIs do GCP | Evitar usar a conta de serviço padrão em produção | | Script de inicialização | Executado automaticamente na inicialização | Pode ser armazenado no Cloud Storage e referenciado via | | Política de disponibilidade | Controla preemptibilidade e comportamento de reinicialização | Spot VMs não podem ser configuradas para reiniciar sempre | | Comportamento de manutenção | Migração ao vivo ou encerramento durante manutenção do host | Instâncias com GPU não suportam Migração ao vivo |
Os scripts de inicialização são especificados diretamente pela chave de metadados ou apontando para um caminho no Cloud Storage com . De dentro da instância, o servidor de metadados expõe valores em tempo de execução como ID da instância, zona e ID do projeto — úteis para autoconfiguração sem hardcoding.
---
Persistent Disk e Snapshots — O ciclo de vida dos dados
O armazenamento no Compute Engine é gerenciado de forma independente do ciclo de vida da VM. Ao excluir uma VM, os Persistent Disks anexados são retidos por padrão — mas o disco de inicialização é excluído junto com a VM. Essa assimetria é uma das armadilhas mais comuns no exame.
Tipos de Persistent Disk
| Tipo de disco | IOPS máx. | Throughput | Custo | Caso de uso principal | |--------------|-----------|------------|------|----------------------| | Standard HDD (pd-standard) | Baixo | Baixo | Mais barato | Dados frios, backups | | Balanced (pd-balanced) | Médio | Médio | Médio | Aplicações de propósito geral | | SSD (pd-ssd) | Alto | Alto | Alto | Bancos de dados, cargas de alto desempenho | | Extreme (pd-extreme) | Muito alto | Muito alto | Mais caro | Bancos de dados de alto desempenho, análise em tempo real |
Os discos Extreme usam IOPS provisionados — você especifica exatamente a quantidade de IOPS necessária. São excessivos para aplicações web típicas, mas adequados para grandes bancos de dados como SAP ou Oracle.
Snapshots vs Machine Images vs Imagens personalizadas
Esses três mecanismos de backup e replicação são frequentemente confundidos. Conhecer as distinções é fundamental.
| Mecanismo | Escopo | Localização | Uso principal | |-----------|--------|-------------|---------------| | Snapshot | Disco individual | Global | Backup incremental, replicação de disco | | Machine image | Todos os discos + configuração da VM | Global | Clone completo de VM, recuperação de desastres | | Imagem personalizada | Estado do SO do disco de inicialização | Global | Imagens base padrão, provisionamento baseado em templates |
Armadilha do exame: Snapshots são recursos globais — não estão vinculados a uma região. Os Persistent Disks, no entanto, são recursos zonais. Para mover um disco entre regiões, é necessário criar um snapshot e restaurá-lo em um novo disco na região de destino. O disco de inicialização é excluído por padrão quando uma VM é excluída, portanto, se a persistência de dados for importante, é necessário desabilitar explicitamente essa opção.
!Snapshot vs imagem de máquina vs imagem personalizada
Templates de instâncias e Managed Instance Groups (MIG)
A base da escalabilidade e alta disponibilidade no Compute Engine é o Managed Instance Group (MIG). Um MIG gerencia uma frota de VMs idênticas baseadas em um template de instância. O template é um projeto imutável que define o tipo de máquina, disco de inicialização, tags de rede, conta de serviço e outras configurações. Não pode ser modificado no local; as alterações exigem a criação de uma nova versão do template.
Zonal MIG vs Regional MIG
| Atributo | Zonal MIG | Regional MIG | |----------|-----------|-------------| | Posicionamento de instâncias | Zona única | Distribuídas em até 3 zonas de uma região | | Disponibilidade | Interrupção total se a zona falhar | Continua servindo se uma zona falhar | | SLA | Menor | 99,99% (multi-zona) | | Esgotamento de recursos | Não pode escalar se a zona ficar sem recursos | Pode obter recursos de outras zonas | | Melhor para | Requisitos com estado em zona única | Cargas sem estado e de alta disponibilidade |
Os MIGs expõem três capacidades principais: autoescalamento, Autohealing e atualizações progressivas.
O autoescalamento ajusta o número de VMs com base na utilização de CPU, carga HTTP, profundidade da fila do Pub/Sub ou métricas personalizadas do Cloud Monitoring. Definir valores mínimos e máximos de instâncias evita custos excessivos durante picos de tráfego.
O Autohealing funciona verificando continuamente um endpoint de saúde. Se uma VM falhar nas verificações de saúde HTTP, HTTPS ou TCP acima de um limite, o MIG a exclui automaticamente e a substitui por uma nova instância. Não confunda alertas do Cloud Monitoring com Autohealing. Alertas notificam pessoas; Autohealing toma ações de remediação automatizadas. Qualquer questão do exame que mencione recuperação automática de VM sem intervenção manual aponta para MIG + Autohealing.
As atualizações progressivas substituem as VMs de forma incremental com um novo template de instância. controla quantas instâncias adicionais podem ser criadas simultaneamente durante a atualização. controla quantas instâncias podem ficar offline ao mesmo tempo. Para implantações canary, é possível atualizar apenas um subconjunto de instâncias para o novo template, mantendo o restante na versão antiga.
---
Spot VM e estratégias de otimização de custos
Spot VM (anteriormente Preemptible VM) é a forma do Compute Engine de oferecer a capacidade de computação excedente do Google com descontos de até 60–91% em relação ao preço sob demanda. A contrapartida: o Google pode recuperar a instância a qualquer momento com apenas 30 segundos de aviso.
| Atributo | Spot VM | VM padrão | |----------|---------|----------| | Preço | Até 60–91% de desconto | Preço sob demanda | | Preemptível | Sim (aviso de 30 segundos) | Não | | Tempo máximo de execução | Ilimitado (mas pode ser interrompida a qualquer momento) | Ilimitado | | Reinicialização automática | Não disponível | Disponível | | Modelo de provisionamento | ou | Padrão |
Spot VMs são ideais para cargas de trabalho que toleram interrupções: processamento em lote, pipelines de dados, compilações de CI/CD e trabalhos de treinamento de ML. Não são adequadas para sistemas transacionais ou serviços que precisam manter disponibilidade contínua.
Um padrão comum é misturar Spot VMs e VMs padrão dentro de um único MIG. As Spot VMs lidam com a capacidade de pico enquanto as VMs padrão mantêm uma linha de base, de modo que a preempção de instâncias Spot não derruba completamente o serviço.
Os descontos por uso comprometido (committed use discounts) são outra alavanca de otimização de custos. Ao se comprometer com uma quantidade específica de vCPU e memória por um ou três anos, você recebe descontos de até 57%. Os compromissos se aplicam no nível do projeto dentro de uma região — não a VMs específicas — portanto, qualquer VM em execução nessa região se beneficia automaticamente do compromisso enquanto o uso de recursos estiver dentro da quantidade comprometida.
---
OS Login e os fundamentos de segurança de instâncias
Existem duas formas de acessar uma VM do Compute Engine via SSH: a abordagem de metadados de chave SSH e o OS Login.
| Atributo | Metadados de chave SSH | OS Login | |----------|----------------------|-----------| | Gerenciamento de chaves | Manual (registrar chaves públicas nos metadados) | Automático via Google Cloud IAM | | Trilha de auditoria | Limitada | Totalmente integrada ao Clou