Sizing de migração baseado em métricas reais: por que um EC2 de 8 vCPU virou 4 OCPUs (e as armadilhas do MySQL gerenciado)

Sizing por métrica, não por instinto

Migrar é a hora certa de parar de pagar por capacidade que ninguém usa. O servidor de origem era um EC2 c6g.2xlarge (8 vCPU), mas a CPU média no CloudWatch era 6,6% — o equivalente a ~0,5 vCPU efetivo. Dimensionar o destino pela métrica real, não pela instância antiga, derrubou a VM para um A1.Flex de 4 OCPU / 16 GB, com folga de sobra.

# CPU média/pico do EC2 de origem no período (base do sizing)
aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0aaaa1111aaaa1111 \
  --start-time 2026-03-01T00:00:00Z --end-time 2026-04-01T00:00:00Z \
  --period 86400 --statistics Average Maximum --query 'Datapoints[].{d:Timestamp,avg:Average,max:Maximum}' --output table

Para o banco (RDS db.t3.large), as métricas que importam não são só CPU: pico de CPU 99,7%, pico de conexões 202, e storage usando 9 GB de 30. CPU saturando + conexões altas = o banco é o gargalo, e o sizing do MySQL gerenciado (MDS) tinha que respeitar isso.

Armadilha 1: shapes e versões em EOL

Dois EOLs quase passaram batido no provisionamento do MySQL Database Service:

Shape VM.Standard.E2.1 em EOL → usar a família MySQL.2 (shape dedicado do MDS), não um shape de computação genérico em fim de vida.

MySQL 8.0 em EOL (abril/2026) → provisionar já em 8.4.8 LTS (suporte até 2032). Migrar para uma versão que morre em meses é retrabalho garantido.

Armadilha 2: a policy que precisa estar no tenancy root

Ao criar o MDS com NSGs (--nsg-ids), o comando falhou com AuthorizationFailed — mesmo com o usuário tendo permissão no compartment. O motivo: o serviço MySQL precisa gerenciar a rede em nome do usuário, e essa policy tem que estar no TENANCY ROOT, não no compartment:

# policy no nível do TENANCY (root), não do compartment:
Allow service mysql to manage virtual-network-family in tenancy

# e o usuário precisa de:
NETWORK_SECURITY_GROUP_UPDATE_MEMBERS

AuthorizationFailed no OCI raramente é "falta permissão no compartment". Para serviços gerenciados que tocam sua rede (MDS, OKE, LB), a policy de service é no tenancy root.

Armadilha 3: IP efêmero não vira reservado

O IP privado que o MDS recebe por padrão é efêmero e não converte para reservado. Para ter um endereço estável (que o app aponta sem medo), o caminho é deletar e recriar como RESERVED, referenciando o private-ip-id:

oci network private-ip update --private-ip-id ocid1.privateip.oc1..aaaaEXAMPLE \
  --vnic-id ocid1.vnic.oc1..aaaaEXAMPLE   # padrão efêmero não converte
# → criar um RESERVED novo e reapontar o app para ele

O MDS leva 15–25 minutos para chegar a ACTIVE — planeje a janela. Depois do cutover de DB, validamos a integridade comparando a contagem de registros (ex.: 12.636 posts) origem × destino antes de liberar tráfego.

Lições

1. Dimensione pelo CloudWatch, não pela instância antiga. 8 vCPU a 6,6% de média = capacidade desperdiçada; a métrica real define o destino.

2. Cheque EOL de shape E de versão. Provisione em LTS (MySQL 8.4) e em shape suportado (MySQL.2); migrar para algo em EOL é retrabalho.

3. Policy de service gerenciado é no tenancy root. AuthorizationFailed com NSG = falta 'Allow service mysql to manage virtual-network-family in tenancy'.

4. Valide a contagem antes de liberar tráfego. Comparar registros origem×destino pós-cutover é o check barato que evita perda silenciosa.

Conclusão

Migração é o melhor momento para alinhar capacidade ao uso real — um EC2 de 8 vCPU rodando a 6,6% não precisava de 8 vCPU. Mas o MySQL gerenciado cobra seu pedágio em pegadinhas: shapes/versões em EOL, uma policy de service que mora no tenancy root, e um IP efêmero que não converte. Métrica para dimensionar, checklist para não tropeçar.