Migração Oracle para AWS RDS: Guia de Decisão 2026

Migrar Oracle para a AWS é uma decisão que envolve muito mais do que escolher uma instância e fazer um Data Pump. Licenciamento, arquitetura, limitações do RDS e estratégia de migração — cada um desses pontos pode transformar um projeto simples em uma dor de cabeça cara.

Neste guia, vou te ajudar a tomar a decisão certa: quando usar RDS, quando usar EC2, como lidar com licenciamento, e como executar a migração com o menor downtime possível.

1. RDS Oracle vs Oracle no EC2: quando usar cada um

A primeira decisão é fundamental: RDS é um serviço gerenciado, EC2 é infraestrutura. Parecem similares, mas as implicações são enormes.

Escolha RDS quando:

• Não precisa de RAC — RDS não suporta Real Application Clusters
• Não precisa de acesso ao sistema operacional — RDS não oferece SSH
• Quer backups automáticos — RDS faz snapshots e point-in-time recovery nativamente
• Quer patches simplificados — A Amazon cuida dos patches de SO e oferece janelas de manutenção para patches Oracle
• O banco é Standard Edition (SE2) — RDS com License Included para SE2 pode ser muito econômico

Escolha EC2 quando:

• Precisa de RAC ou Data Guard customizado — Controle total da configuração
• Precisa de acesso ao SO — Scripts cron, agentes de monitoramento, ferramentas de terceiros
• Usa features do Enterprise Edition avançadas — Partitioning, Advanced Compression, In-Memory com configuração específica
• O banco é muito grande (multi-TB) — EC2 oferece mais flexibilidade de storage
• Precisa de Oracle 9i, 10g ou 11g — RDS não suporta versões legadas

2. Licenciamento Oracle na AWS

Este é o ponto onde mais vejo empresas errarem — e errarem caro. A Oracle tem regras de licenciamento específicas para cloud que não são as mesmas do on-premise.

BYOL (Bring Your Own License)

Você usa suas licenças Oracle existentes na AWS. É a opção mais comum para Enterprise Edition:

• No RDS: Cada vCPU RDS conta como 0.5 processador Oracle (com hyperthreading). Uma instância db.m5.2xlarge tem 8 vCPUs = 4 processadores Oracle = 4 licenças de processador.
• No EC2: As regras são similares, mas você pode desabilitar hyperthreading para reduzir a contagem de licenças — o que não é possível no RDS.
• Software Update License & Support precisa estar ativo para usar BYOL.

License Included (LI)

A licença Oracle já está embutida no preço por hora da instância RDS. Só disponível para Standard Edition Two (SE2) no RDS:

• Sem custo de licença separado — paga tudo por hora
• Ideal para bancos menores ou ambientes de dev/homologação
• Limitação: SE2 tem teto de 16 threads de CPU e não suporta RAC, Partitioning, etc.

3. Versões e features suportadas no RDS

O RDS Oracle suporta as versões 19c e 21c (e atualizações à medida que a Oracle lança). Mas nem tudo que funciona on-premise funciona no RDS:

• Não suportado: RAC, Oracle Streams, Spatial/Graph (parcial), APEX embutido
• Suportado: Data Guard (via Multi-AZ ou cross-region read replicas), tuning packs (AWR, ASH), Partitioning (com BYOL EE), TDE
• Parcialmente suportado: Oracle Enterprise Manager (precisa instalar em EC2 separado apontando para RDS)

Se seu ambiente usa alguma feature não suportada, a migração para RDS pode exigir refatoração — ou EC2 pode ser a melhor opção.

4. Estratégias de migração

Existem várias formas de mover um banco Oracle para a AWS. A escolha depende do tamanho do banco, tolerância a downtime e complexidade:

Data Pump (expdp/impdp)

A forma mais simples. Exporta o banco no ambiente de origem, transfere o dump para S3, importa no RDS:

• Prós: Simples, confiável, funciona com RDS e EC2
• Contras: Downtime proporcional ao tamanho do banco. Para bancos grandes (>100 GB), pode levar horas
• Melhor para: Bancos até 500 GB com janela de manutenção disponível

AWS DMS (Database Migration Service)

Migração contínua com replicação de dados em tempo real:

• Prós: Downtime mínimo (minutos), replicação contínua durante a migração
• Contras: Não replica DDL, sequences, grants e outros metadados automaticamente. Precisa de Oracle Supplemental Logging habilitado.
• Melhor para: Bancos grandes com exigência de downtime mínimo

RMAN + S3 (para EC2)

Restore de backup RMAN no EC2, com opção de usar Data Guard para sincronização contínua antes do cutover:

• Prós: Controle total, downtime de minutos com Data Guard
• Contras: Só funciona para EC2 (não RDS). Mais complexo de configurar.
• Melhor para: Ambientes Enterprise com alta disponibilidade

5. Dimensionamento correto da instância

Um erro clássico é pegar a configuração do servidor on-premise e mapear 1:1 para a AWS. Cloud funciona diferente.

• CPU: Não compare cores on-premise com vCPUs AWS diretamente. Um core físico on-premise tipicamente equivale a 2 vCPUs AWS. Comece conservador e ajuste.
• Memória: A SGA + PGA do Oracle precisa caber na memória da instância com folga. Reserve pelo menos 20% para o SO.
• Storage (EBS): Use gp3 para cargas gerais (3.000 IOPS base, escalável) ou io2 para workloads de I/O intenso. O tipo de storage faz mais diferença na performance Oracle que a CPU.

6. Os 7 erros mais comuns na migração

1. Não analisar licenciamento antes — Pode resultar em compliance issues caríssimas
2. Ignorar o character set — Diferenças entre AL32UTF8 e WE8ISO8859P1 causam problemas de dados corrompidos
3. Não testar performance pós-migração — As mesmas queries podem se comportar diferente no RDS. Colete baselines antes.
4. Subestimar a rede — A transferência de dados para a AWS depende da sua banda de internet. Para bancos grandes, considere AWS Snowball ou Direct Connect.
5. Não ajustar parâmetros de memória — SGA_TARGET e PGA_AGGREGATE_TARGET precisam ser recalculados para a instância AWS
6. Esquecer de testar o rollback — Sempre tenha um plano para voltar ao on-premise se a migração falhar
7. Migrar tudo de uma vez — Comece com ambientes de dev/homologação. Valide. Depois migre produção.

7. Checklist pré-migração

1. Análise de licenciamento Oracle concluída
2. Versão Oracle compatível com RDS (se for RDS)
3. Features em uso mapeadas e validadas
4. Sizing da instância definido com base em AWR
5. Tipo de storage EBS escolhido
6. Character set de origem e destino compatíveis
7. Estratégia de migração definida (Data Pump / DMS / RMAN)
8. Teste de performance com baseline on-premise
9. Plano de rollback documentado
10. Janela de manutenção agendada e comunicada

Se todos os 10 itens estão cobertos, sua migração tem tudo para ser bem-sucedida. Se faltam itens, cada um é um risco que pode custar caro. Precisa de ajuda profissional? Conheça nossa consultoria de migração Oracle para cloud.