O que é VPC (Virtual Private Cloud) e por que sua aplicação precisa de uma

O que é VPC? É a decisão que define o que pode falar com o quê na sua rede, antes que um incidente decida isso por você. Uma VM pública com banco de dados na mesma sub-rede não é um erro isolado. É uma decisão de arquitetura que ninguém tomou de propósito.

Ela nasce assim: o projeto sobe rápido, o deploy funciona, e a pergunta “quem pode falar com quem nessa rede” fica para depois. O problema é que “depois” costuma chegar via incidente, não via code review.

Erro humano respondeu por 26% dos vazamentos de dados em 2025, segundo o relatório Cost of a Data Breach da IBM. Breaches com dados espalhados por múltiplos ambientes de nuvem custaram em média US$ 5,05 milhões, o valor mais alto entre todas as categorias do estudo.

Não é exploração de zero-day que domina esse cenário. É rede mal desenhada deixando serviço interno acessível de onde ele nunca deveria estar.

VPC resolve exatamente essa classe de problema. Não como camada extra de segurança, mas como decisão estrutural: o que é público, o que é privado, e que caminho os dados percorrem entre um e outro.

O que é uma VPC, na prática

Uma Virtual Private Cloud é um ambiente de rede dedicado dentro de uma nuvem maior, com faixa de IP privado própria e um roteador virtual que decide o que trafega entre sub-redes e o que sai para a internet.

A diferença para uma rede isolada comum está na hierarquia. Rede isolada tradicional opera sozinha, com um único roteador, sem camadas internas. VPC permite dividir esse espaço em tiers, cada um com uma função e um nível de exposição diferente.

Três tiers típicos de uma aplicação web: a camada de entrada (público), a camada de aplicação (onde roda o front-end e a lógica de negócio) e o banco de dados. Sem VPC, essas VMs vivem na mesma rede plana, e qualquer uma enxerga qualquer outra por padrão.

Com VPC, o roteamento vira regra, não convenção. O load balancer fala com a aplicação. A aplicação fala com o banco. O banco não fala com a internet, ponto.

Blast radius é o raio de estrago de um comprometimento. Numa rede plana, comprometer o front-end deixa o atacante a um salto do banco. Numa VPC bem desenhada, ele fica preso no tier de aplicação, que é privado, sem rota direta para o tier de dados, que é o que importa.

Por que a maioria dos incidentes de segurança começa na rede, não no código?

O incidente mais comum não exige zero-day. Exige só um bucket configurado como público “temporariamente” e nunca revertido, ou uma VM com IP público por conveniência de debug que ninguém tirou depois.

O Data Breach Investigations Report 2025, da Verizon, encontrou elemento humano em 60% das violações confirmadas naquele ano, entre erro de configuração, uso indevido de credencial e engenharia social. Rede mal desenhada entra exatamente nessa categoria: ninguém precisou invadir nada, só usar uma porta que já estava aberta.

O modelo de responsabilidade compartilhada em cloud é direto: o provedor cuida do datacenter e do hardware. Quem usa a nuvem responde pela configuração de rede, IAM e criptografia dentro dela.

VPC ausente, ou mal desenhada, é a configuração incorreta mais estrutural que existe. Ela não é um item a mais na lista de hardening. É o que decide se um erro em uma camada vira exposição total ou fica contido numa só.

A pergunta certa antes de subir algo em produção não é “essa VM está segura”. É: se essa VM for comprometida, o que mais fica exposto?

Como desenhar os tiers de uma VPC

Um desenho funcional de VPC segue geralmente três a quatro camadas, cada uma com uma regra clara de acesso.

Tier público. Onde vive apenas a infraestrutura de roteamento e entrada: Load Balancers, Gateways de API e NAT Gateways. Instâncias de computação (mesmo as de front-end) devem sempre ficar em tiers privados, recebendo requisições exclusivamente por intermédio desse Load Balancer. Tudo neste tier atua como uma barreira e é tratado como potencialmente exposto.

Tier de aplicação. Onde roda a lógica de negócio, os workers e as instâncias de front-end. Recebe tráfego do tier público apenas via Load Balancer, com regras específicas. Sai para fora só via NAT gateway, sem porta de entrada exposta.

Tier de dados. Banco, cache, filas. Acessível só pelo tier de aplicação, nunca diretamente pelo público. Recebe a camada mais restritiva de todas, porque um vazamento aqui já é catastrófico.

Tier de gestão, opcional mas recomendado. Bastion hosts e ferramentas de administração, acessados só via VPN ou IP fixo.

A régua para saber se a segmentação está certa: cada tier deveria sobreviver ao comprometimento do tier anterior sem dano direto. Se o front-end comprometido dá acesso automático ao banco, a segmentação não está cumprindo a função dela.

Como uma VM fica online sem IP público? O papel do NAT gateway

VM sem IP público não significa VM sem internet. É aqui que mora a confusão mais comum de quem está desenhando isso pela primeira vez.

NAT gateway permite que uma VM no tier privado inicie conexões de saída, como baixar uma dependência ou chamar uma API externa, sem ter IP público próprio e sem aceitar conexão de entrada vinda de fora.

A VM fala com o mundo. O mundo não fala com ela.

Toda VM que precisa buscar dados na internet externa deve estar atrás de um NAT Gateway, e não com IP público direto. Já para acessar serviços internos da própria nuvem, como um Object Storage ou um banco gerenciado, a melhor prática é usar VPC Endpoints, que roteiam o tráfego por uma rede estritamente privada, sem passar pelo NAT.

Autoscaling quebra a segmentação de uma VPC?

Autoscaling e VPC precisam estar alinhados, ou a escala vira risco. Uma instância nova, subindo automaticamente num pico de demanda, precisa nascer já no tier correto, com as mesmas regras de rede da original.

Quando isso não acontece, o resultado é configuration drift: a instância nova sobe num tier errado, ou com regra de segurança mais permissiva do que deveria.

Infraestrutura como código resolve essa lacuna. Definir a VPC via Terraform, com tiers, rotas e security groups em código versionado, elimina a variação manual que costuma abrir esse tipo de brecha.

Topologia de rede como código é revisável em pull request, testável antes de produção, e reproduzível sem depender de alguém lembrar de clicar no lugar certo no painel.

VPC na Locaweb Cloud: o que muda na prática

Locaweb Cloud tem VPC networking nativo. A segmentação em tiers já é parte do produto, não uma configuração extra para montar por cima.

Quatro pontos mudam o cálculo de quem desenha essa arquitetura:

• Egress sem custo adicional. Tráfego de saída entre tiers e para a internet não é cobrado por byte.
• Load balancer sem custo por regra. Adicionar mais uma regra de roteamento não vira item de fatura separado.
• Autoscaling com 2 zonas de disponibilidade e SLA de 99,9%. A instância nova replica a topologia de rede da original.
• Suporte a Terraform via starter kit oficial no GitHub. A VPC pode ser declarada em código desde o primeiro dia.

A Tray, hoje parceira do mesmo grupo da Locaweb, estimou economia de R$ 45 mil por mês em infraestrutura ao migrar para esse modelo.

Nada disso elimina a necessidade de desenhar a segmentação com cuidado. Elimina o atrito de montar a base da VPC do zero.

Checklist antes de ir para produção

Seis perguntas para confirmar antes de considerar uma aplicação pronta:

1. O banco de dados tem IP público? Se sim, por quê?
2. Existe alguma instância de computação (inclusive de front-end) no tier público, em vez de atrás do Load Balancer?
3. Uma instância comprometida no tier de aplicação roteia diretamente para o tier de dados?
4. As regras de security group são específicas por porta e origem, ou existe alguma regra ampla “aceitar tudo” esquecida?
5. A topologia de rede está em código, ou só na cabeça de quem configurou originalmente?
6. Instâncias de autoscaling nascem no tier e com as regras corretas, sem intervenção manual?

Qualquer resposta duvidosa significa que a rede ainda não está pronta, mesmo com a aplicação no ar. Funcionar e estar bem desenhado são coisas diferentes.

Depois de entender os tiers e o que cada um protege, o próximo passo é desenhar a sua. Criar uma VPC agora no Locaweb Cloud começa direto no painel, com os tiers configuráveis desde a primeira VM.

FAQ – Perguntas frequentes sobre VPC