Migrando um app transacional da AWS para a OCI: desenhando a VCN isolada (CIDR, NSGs e as pegadinhas de São Paulo)

Fase 0: a rede vem antes da carga

Numa migração AWS→OCI de uma aplicação transacional, a tentação é começar pelo cluster. Errado: a VCN (Virtual Cloud Network) é a fundação. Erros de CIDR, sub-rede ou NSG só aparecem quando a app já está rodando — e aí o custo de corrigir é alto. Desenhamos a malha inteira primeiro, isolada, com OKE/ARM desde o início.

Decisão 1: o CIDR que não pode dar overlap

Escolhemos 10.1.0.0/20 para a VCN — deliberadamente fora de 10.0.0.0/16. Se um dia houver peering com outra rede (a da AWS, durante a coexistência, ou uma VCN futura), CIDRs sobrepostos tornam o peering impossível. Escolher o range pensando no futuro é grátis agora e caríssimo depois.

CIDR é decisão de uma via: trocar depois significa recriar sub-redes e reendereçar tudo. Pense no peering futuro antes de digitar o primeiro /20.

Decisão 2: São Paulo tem uma só Availability Domain

A região SA-SAOPAULO-1 da OCI tem apenas 1 AD. Diferente de regiões com 3 ADs, você não distribui resiliência entre ADs — distribui entre Fault Domains dentro da única AD. Quem desenha esperando multi-AD se frustra; o padrão de alta disponibilidade aqui é fault-domain-aware, não AD-aware.

Decisão 3: o Service Gateway atende por um prefixo inesperado

Para o tráfego interno alcançar serviços da OCI (Object Storage, etc.) sem sair para a internet, usa-se o Service Gateway. A pegadinha: em São Paulo, o service CIDR label é all-gru-services-in-oracle-services-network — não SA-SAOPAULO. Apontar a route rule para o label errado faz o tráfego simplesmente não rotear, sem erro óbvio.

# listar os service CIDR labels disponíveis na região (achar o 'gru')
oci network service list --query "data[].{name:name,cidr:\"cidr-block\"}" --output table

# route rule do Service Gateway usa o label 'all-gru-services...', não 'SA-SAOPAULO'
oci network route-table update --rt-id ocid1.routetable.oc1..aaaaEXAMPLE \
  --route-rules '[{"destination":"all-gru-services-in-oracle-services-network",
                   "destinationType":"SERVICE_CIDR_BLOCK",
                   "networkEntityId":"ocid1.servicegateway.oc1..aaaaEXAMPLE"}]'

A matriz de 4 NSGs

Em vez de Security Lists amplas, usamos Network Security Groups por camada, com a regra de menor privilégio — o banco só aceita conexão do NSG da app:

nsg-lb    : ingress 80,443  de 0.0.0.0/0           (load balancer público)
nsg-app   : ingress 3000, 30000-32767 (NodePort),    de nsg-lb
            10250 (kubelet)            de dentro da VCN
nsg-wp    : ingress 2028 (SSH custom), 9100 (Prometheus) de IPs de ops
nsg-db    : ingress 3306              SOMENTE de nsg-app/nsg-wp  (sem 0.0.0.0/0)

NSG referenciando NSG (origem = outro NSG, não um CIDR) é o que torna a malha à prova de mudança de IP: escalar a app não exige reabrir o banco para um novo range.

Bônus: a imagem amd64 que não sobe no nó ARM

O cluster OKE é ARM (Ampere). A imagem que rodava no ECS era amd64-only (runtimePlatform nulo no task definition). No nó ARM, o pod fica em CrashLoopBackOff com exec format error. O fix é rebuildar multi-arch — assunto recorrente quando se migra de x86 para Ampere:

docker buildx build --platform linux/arm64 -t registry.example.com/myapp/app:arm64 --push .

Lições

1. Desenhe a VCN antes de qualquer workload. CIDR, sub-redes e NSGs são fundação; corrigir com app no ar é caro.

2. CIDR pensando no peering futuro. Evite overlap com 10.0.0.0/16; um /20 fora da faixa hoje salva o peering amanhã.

3. São Paulo = 1 AD, resiliência por Fault Domain. Não desenhe esperando multi-AD; distribua entre fault domains.

4. Service Gateway usa o label 'all-gru-services'. Apontar para SA-SAOPAULO faz o tráfego não rotear, silenciosamente.

Conclusão

Migração de nuvem que começa pelo container começa pelo telhado. A rede certa — CIDR sem overlap, resiliência por fault domain, Service Gateway no label certo e 4 NSGs de menor privilégio — é o que faz o resto da migração ser previsível em vez de uma sequência de surpresas regionais.