# Oracle HA na AWS: FSx for ONTAP como Alavanca de Modernização Gradual

O sinal mais relevante neste ciclo para arquitetos que ainda carregam workloads Oracle críticos não é abandoná-los — é orquestrá-los com primitivos cloud-native que entregam HA real sem forçar uma reescrita. FSx for NetApp ONTAP muda a equação de armazenamento para Oracle na AWS de forma concreta. Este briefing analisa o que muda na prática, os trade-offs reais e como posicionar essa camada dentro de uma estratégia de modernização gradual.

- URL: https://fernando.moretes.com/blog/oracle-ha-com-fsx-ontap-e-modernizacao-gradual

- Markdown: https://fernando.moretes.com/blog/oracle-ha-com-fsx-ontap-e-modernizacao-gradual/article.md?lang=pt

- Published: 2026-06-06T00:00:00.000Z

- Category: AWS & Cloud

- Tags: oracle, fsx-ontap, high-availability, migration, financial-grade, storage, modernization, aws

- Reading time: 10 min

- Source: [Oracle HA with FSx for NetApp ONTAP](https://aws.amazon.com/blogs/architecture/)

---

Existe uma categoria de workload que nenhum roadmap de modernização consegue eliminar no prazo prometido: Oracle em produção, em ambiente financeiro, com SLA de 99,99% e auditoria regulatória sobre cada transação. Depois de 16 anos transitando entre engenharia e arquitetura de soluções, aprendi que a resposta honesta para esse cenário não é 'migre para Aurora' — é 'reduza o risco operacional hoje e abra a janela de modernização amanhã'. O sinal recente do AWS Architecture Blog sobre Oracle HA com FSx for NetApp ONTAP é exatamente essa janela: uma combinação de primitivos cloud-native que entrega HA de nível enterprise sem exigir que você abandone Oracle Data Guard, ASM ou os contratos de licença que seu CFO já amortizou. Este briefing decompõe o que essa arquitetura realmente oferece, onde ela falha se mal configurada, e como posicioná-la como primeiro movimento de uma estratégia de modernização incremental — não como destino final.

## Números que definem o contexto

- **~0.2ms** — Latência de I/O com FSx ONTAP Multi-AZ em NVMe-oF (iSCSI/NFS). Comparável a SAN on-premises de última geração; suficiente para OLTP Oracle com redo log em volume dedicado
- **RPO < 20s** — RPO com SnapMirror síncrono entre AZs + Oracle Data Guard. SnapMirror síncrono garante zero data loss no nível de bloco; Data Guard adiciona proteção lógica contra corrupção
- **60-70%** — Redução de custo de armazenamento vs. io2 Block Express provisionado para Oracle. FSx ONTAP com thin provisioning e deduplicação inline elimina o over-provisioning típico de IOPS reservados

## O Problema Real: Por Que Oracle HA na AWS Sempre Foi Difícil

Oracle em alta disponibilidade tem requisitos de armazenamento que não casam bem com o modelo de disco efêmero/EBS da AWS clássica. O ASM (Automatic Storage Management) exige acesso direto a dispositivos de bloco com baixa latência e comportamento previsível de I/O. O Data Guard, em modo Maximum Availability, precisa que o redo log seja confirmado no standby antes de retornar ao primário — o que amplifica qualquer variação de latência entre zonas. O resultado histórico era uma escolha entre três males: (1) usar EBS io2 com IOPS super-provisionados para compensar a variabilidade, inflando custos em 3-4x; (2) aceitar um RPO degradado operando Data Guard em modo Maximum Performance; ou (3) manter o Oracle on-premises e apenas 'estender' para AWS via Direct Connect, perdendo os benefícios de elasticidade.

O FSx for NetApp ONTAP muda essa equação porque é um serviço gerenciado que expõe semântica de SAN enterprise — snapshots consistentes, replicação baseada em bloco com SnapMirror, thin provisioning, deduplicação e compressão inline — sobre infraestrutura AWS Multi-AZ. A diferença crítica em relação ao EBS é que o ONTAP trata o volume como uma entidade de primeira classe com garantias de consistência no nível do sistema de arquivos, não apenas no nível do bloco. Para Oracle, isso significa que um snapshot ONTAP captura um estado consistente do datafile sem exigir o modo `BEGIN BACKUP` — reduzindo a janela de risco durante backups e simplificando o runbook de recovery.

## Arquitetura Oracle HA com FSx for ONTAP — Modernização Gradual em Camadas

Fluxo de dados e replicação entre camadas primária, standby e modernização incremental. SnapMirror replica blocos entre AZs; Data Guard protege contra corrupção lógica; a camada de modernização consome snapshots ONTAP para analytics e eventual migração.

### 🟦 AZ-1 — Primary

- EC2 R7i.8xlarge Oracle DB Primary (compute)
- FSx ONTAP Data + Redo Volumes (storage)
- ASM Diskgroup iSCSI LUN (storage)

### 🟩 AZ-2 — Standby

- EC2 R7i.8xlarge Oracle DB Standby (compute)
- FSx ONTAP Mirror Volumes (storage)

### 🔒 Security & Networking

- NLB DB Endpoint (network)
- KMS CMK Volume Encryption (security)
- Security Groups iSCSI Port 3260 (security)

### 🚀 Modernization Layer

- ONTAP Snapshot Export to S3 (storage)
- AWS Glue ETL / Schema Evolve (compute)
- Aurora PostgreSQL Target (future) (data)

### Fluxos

- ec2_primary -> asm_primary: iSCSI LUN mount
- asm_primary -> ontap_primary: ASM I/O
- ontap_primary -> ontap_standby: SnapMirror Sync
- ec2_primary -> ec2_standby: Data Guard Redo
- nlb -> ec2_primary: Active connection
- nlb -> ec2_standby: Failover target
- kms -> ontap_primary: CMK encryption
- kms -> ontap_standby: CMK encryption
- sg -> ec2_primary: iSCSI allow
- ontap_primary -> snap_export: Snapshot clone → S3
- snap_export -> glue: ETL pipeline
- glue -> aurora: Schema migration

## Configuração Concreta: O Que Realmente Importa na Camada de Armazenamento

A armadilha mais comum que vejo em implementações Oracle/FSx é tratar o FSx ONTAP como um NAS genérico e montar tudo via NFS v3. Para Oracle em produção financeira, o protocolo correto é iSCSI com LUNs dedicados por diskgroup ASM — um para dados (DATA), um para redo log (REDO) e um para FRA (Fast Recovery Area). A separação não é cosmética: ela permite políticas de QoS distintas por volume ONTAP, e o redo log em particular se beneficia de um volume com `tiering-policy none` (sem movimentação para capacidade fria) e `snapshot-policy none` (snapshots do redo são inúteis e consomem espaço).

No nível do FSx, o deployment Multi-AZ cria automaticamente um par ativo/passivo de file servers com replicação síncrona via SnapMirror entre AZs. O ponto crítico de configuração é o `preferred-subnet` e o `standby-subnet` — eles devem estar em AZs distintas com rotas simétricas via Transit Gateway ou VPC peering, nunca via Internet Gateway. A latência entre AZs na mesma região AWS é tipicamente 1-2ms; com SnapMirror síncrono, isso se traduz em ~2-4ms de overhead adicional no commit do redo — aceitável para OLTP, mas precisa ser medido com `AWR` antes de ir para produção.

Para criptografia, o caminho correto é KMS com CMK gerenciada pelo cliente, com `kms:GenerateDataKeyWithoutPlaintext` restrito por condição `aws:SourceVpc` — impedindo que a chave seja usada fora da VPC do banco. Combine isso com `aws:RequestedRegion` para prevenir exfiltração cross-region acidental. O FSx ONTAP suporta criptografia em repouso por padrão, mas a CMK precisa ser explicitamente configurada na criação do filesystem — não é retroativa.

## O Que Muda Para Arquitetos com Este Sinal

- **HA Oracle deixa de ser um problema de IOPS provisionados**: FSx ONTAP com QoS adaptativa elimina o over-provisioning defensivo de io2 — o custo de armazenamento cai 60-70% sem degradar SLA.
- **Snapshots ONTAP como primitivo de modernização**: Um clone de snapshot ONTAP pode ser montado em read-only por uma instância Glue/EMR para ETL incremental sem impactar o primário — isso é a fundação de uma estratégia de migração zero-downtime.
- **Data Guard + SnapMirror não são redundantes**: SnapMirror protege contra falha de infraestrutura (hardware, AZ); Data Guard protege contra corrupção lógica (bug de aplicação, truncamento acidental). As duas camadas são complementares, não substituíveis.
- **O runbook de failover muda**: Com FSx Multi-AZ, o failover de armazenamento é automático e transparente para o Oracle (o endpoint iSCSI não muda). O failover do Data Guard ainda é manual ou requer Oracle Observer — combine os dois para RTO < 60s.
- **Licenciamento Oracle na AWS tem nuances**: EC2 com BYOL Oracle SE2/EE conta vCPUs, não sockets. R7i.8xlarge tem 32 vCPUs = 16 cores Oracle. Dimensione para caber no modelo de licença antes de escolher o instance type — o erro aqui custa mais do que toda a infraestrutura.
- **Observabilidade precisa cobrir três camadas**: CloudWatch para métricas FSx (VolumeReadOps, StorageCapacityUtilization), AWR/ASH para Oracle interno, e OpenTelemetry para correlacionar latência de aplicação com eventos de storage — sem as três, o diagnóstico de incidente leva horas.

## Posicionamento Estratégico: FSx ONTAP como Primeiro Movimento, Não Como Destino

O erro de framing mais perigoso que ouço em comitês de arquitetura é tratar a migração Oracle/FSx como um projeto de infraestrutura isolado. Ela não é. É o primeiro movimento de uma sequência de três atos que, se bem orquestrada, leva a um estado final onde Oracle é opcional — não obrigatório.

**Ato 1 — Estabilizar**: Migrar Oracle para EC2 + FSx ONTAP Multi-AZ com Data Guard. O objetivo não é modernizar; é eliminar o risco operacional do hardware on-premises e ganhar snapshots ONTAP como primitivo de backup/clone. Neste ato, você não toca em schema, não muda drivers de aplicação, não questiona o modelo de dados. KPIs: RTO < 60s, RPO < 20s, custo de armazenamento -60%.

**Ato 2 — Instrumentar**: Com o Oracle estável na AWS, você tem acesso a snapshots ONTAP que podem ser clonados em segundos e montados em instâncias de análise. Use isso para alimentar um pipeline Glue que lê os datafiles Oracle via JDBC (não via snapshot de bloco — o JDBC garante consistência transacional) e escreve em S3 em formato Parquet. Esse pipeline é o embrião do seu data mesh: ele separa o dado operacional do dado analítico sem tocar no primário.

**Ato 3 — Migrar Incrementalmente**: Com o pipeline Glue funcionando, você tem visibilidade real do schema Oracle — dependências, tipos de dados, procedures que precisam ser reescritas. Agora a conversa com o time de desenvolvimento sobre migração para Aurora PostgreSQL ou RDS Oracle tem dados concretos: quais tabelas têm volume alto, quais procedures são críticas, qual o custo de reescrever cada módulo. A decisão de migrar deixa de ser política e vira engenharia.

Esse sequenciamento importa porque cada ato entrega valor independente. Se o Ato 3 nunca acontecer por restrição regulatória ou política, você ainda saiu do on-premises, reduziu custo e ganhou HA real. O risco de um big-bang migration — que é a alternativa — é que se ele falhar no Ato 3, você perdeu tudo.

> **Armadilha de Licenciamento: O Custo Invisível Que Afunda o Business Case:** Oracle conta núcleos físicos para licenciamento BYOL na AWS, mas a AWS publica um fator de conversão: 1 vCPU = 0,5 núcleo Oracle para instâncias com Hyper-Threading. Um R7i.16xlarge tem 64 vCPUs = 32 núcleos Oracle. Se você migrou de um servidor on-premises com 2 sockets × 8 cores = 16 núcleos Oracle, você acabou de dobrar sua exposição de licença sem perceber. Sempre calcule o Oracle Processor Core Factor antes de escolher o instance type. Para ambientes financeiros com auditoria de licença, considere Dedicated Hosts para ter controle explícito sobre o número de sockets físicos — o custo do host dedicado pode ser menor do que a multa de auditoria.

## Observabilidade e Operação: O Que o CloudWatch Não Te Conta Sobre Oracle

A lacuna mais crítica em operações Oracle/FSx que encontro em revisões de Well-Architected é a ausência de correlação entre métricas de storage e eventos internos do Oracle. CloudWatch entrega métricas FSx excelentes — `VolumeReadLatency`, `VolumeWriteLatency`, `StorageCapacityUtilization`, `NetworkThroughput` — mas elas não falam com o AWR (Automatic Workload Repository) do Oracle. Quando um DBA reporta 'o banco está lento', você precisa saber se o gargalo é I/O de storage (FSx), contenção de latch interno (Oracle), ou latência de rede entre aplicação e banco.

A solução que implemento é um pipeline de três camadas: (1) CloudWatch com alarmes em `VolumeReadLatency > 1ms` por 5 minutos consecutivos — isso dispara um SNS que notifica o time de operações antes que o usuário perceba; (2) um script Python em Lambda que consulta `V$SYSMETRIC` e `V$ACTIVE_SESSION_HISTORY` via JDBC a cada 60 segundos e publica métricas customizadas no CloudWatch com dimensões `WaitClass` e `Event` — isso mapeia os wait events Oracle para métricas CloudWatch; (3) OpenTelemetry no middleware de aplicação que propaga `trace_id` até o driver JDBC, permitindo correlacionar uma requisição HTTP lenta com o wait event Oracle específico que a causou.

Para FSx especificamente, o `StorageCapacityUtilization` acima de 80% é um sinal crítico — o ONTAP começa a degradar performance de thin provisioning acima desse threshold. Configure um alarme CloudWatch com ação automática de expansão de volume via AWS CLI (`aws fsx update-volume --volume-id ... --ontap-configuration TieringPolicy=...`). O FSx ONTAP suporta expansão online sem downtime — use isso como parte do runbook de capacity management.

## Lentes Well-Architected para Oracle HA com FSx ONTAP

- **security**: CMK KMS com condição aws:SourceVpc + aws:RequestedRegion. Security Groups restringindo porta iSCSI 3260 apenas para os ENIs das instâncias Oracle. VPC Endpoints para FSx eliminando tráfego pela Internet. CloudTrail com data events para o filesystem FSx.
- **reliability**: FSx Multi-AZ com SnapMirror síncrono + Data Guard Maximum Availability entrega RTO < 60s e RPO < 20s. Teste o failover mensalmente com AWS Fault Injection Simulator (FIS) simulando falha de AZ — não confie apenas no runbook teórico.

## Anti-Padrões Que Destroem o Business Case

- **Montar tudo via NFS v3**: NFS v3 não suporta locking adequado para Oracle datafiles. Use iSCSI para DATA e REDO, NFS v4.1 apenas para backups e exports.
- **Usar snapshot ONTAP como substituto do Data Guard**: Snapshots protegem contra falha de infraestrutura, não contra corrupção lógica. Um `DELETE FROM orders WHERE 1=1` sem WHERE clause é replicado pelo SnapMirror antes que você perceba.
- **Não calcular Oracle Core Factor antes de escolher instance type**: Dobrar o número de núcleos Oracle por acidente em uma migração pode custar mais em licença do que toda a infraestrutura AWS por ano.
- **Habilitar tiering automático no volume de redo log**: O redo log precisa de latência sub-millisecond. Tiering para S3 introduz latência de recuperação de objetos que pode causar falha de commit. `tiering-policy none` é obrigatório para REDO.
- **Tratar a migração Oracle/FSx como projeto de infraestrutura isolado**: Sem o pipeline Glue/S3 do Ato 2, você apenas replicou o problema on-premises para a nuvem com custo diferente. O valor real está na modernização incremental que os snapshots ONTAP habilitam.

> **O Insight Contra-Intuitivo: Duas Camadas de Replicação São Mais Baratas do Que Uma:** A reação instintiva ao ver SnapMirror + Data Guard juntos é 'estamos pagando duas vezes pela mesma coisa'. Na prática, é o oposto. SnapMirror síncrono elimina a necessidade de provisionar IOPS extras no standby para manter o redo apply em dia — o storage já está replicado. Data Guard em Maximum Availability com redo log no FSx ONTAP tem overhead de rede menor do que em EBS porque o ONTAP absorve a variabilidade de latência localmente. O custo total das duas camadas é menor do que o custo de um único EBS io2 super-provisionado que tenta fazer o trabalho das duas.

## O Horizonte: Quando Oracle Vira Opcional

A pergunta que todo CTO financeiro me faz depois de ver essa arquitetura é: 'quando conseguimos sair do Oracle de vez?' A resposta honesta é que depende de três variáveis que não são técnicas: (1) o volume de stored procedures PL/SQL com lógica de negócio embutida — que precisa ser reescrita, não migrada; (2) os contratos de licença Oracle em vigor — que podem ter cláusulas de penalidade por saída antecipada; e (3) a tolerância regulatória para mudança de banco de dados em sistemas de registro.

O que a arquitetura FSx ONTAP + Glue + S3 faz é transformar essas três variáveis de bloqueadores absolutos em variáveis gerenciáveis. O pipeline Glue do Ato 2 entrega um inventário vivo do schema Oracle — você sabe exatamente quantas procedures existem, quais são chamadas com frequência, quais podem ser substituídas por lógica de aplicação. Isso transforma a conversa de 'migrar o banco' para 'migrar módulo por módulo', com cada módulo tendo um business case independente.

Em ambientes financeiros que acompanhei, o caminho mais comum é manter Oracle para o core transacional (ledger, posições, liquidação) e migrar para Aurora PostgreSQL os módulos periféricos (relatórios regulatórios, onboarding, KYC). Isso reduz a exposição de licença Oracle em 40-60% sem tocar nos sistemas de maior risco. O FSx ONTAP permanece como camada de armazenamento para o Oracle residual, e o pipeline Glue alimenta o data mesh com dados de ambos os bancos — criando uma camada analítica unificada que não depende de qual banco relacional está por baixo.

Esse é o estado final realista: não 'zero Oracle', mas 'Oracle como escolha, não como prisão'. E FSx ONTAP é a infraestrutura que torna esse horizonte alcançável sem um big-bang que nenhum regulador financeiro aprovaria.

> **Nota do Curador:** Na prática, o que eu faria primeiro é implementar o pipeline de observabilidade de três camadas antes de qualquer migração — CloudWatch, V$SYSMETRIC via Lambda, e OpenTelemetry no middleware. Sem essa linha de base, você não tem como provar que a migração melhorou (ou não degradou) a performance, e em ambiente financeiro regulado, essa prova é tão importante quanto o SLA. A lição mais cara que aprendi em projetos Oracle/cloud é que o problema raramente é o banco — é a ausência de dados para diagnosticar o banco. FSx ONTAP resolve o problema de armazenamento de forma elegante, mas a observabilidade é o que te salva às 3h da manhã durante um incidente de produção.

## Veredicto: Adote Como Primeiro Movimento, Não Como Solução Final

FSx for NetApp ONTAP com Oracle Data Guard em Multi-AZ é a arquitetura de HA Oracle mais madura disponível na AWS hoje — e o sinal do AWS Architecture Blog confirma que a AWS está investindo nessa direção. Para arquitetos em ambientes financeiros, a recomendação é clara: use essa combinação como o Ato 1 de uma estratégia de modernização em três atos. Ela entrega RTO < 60s, RPO < 20s, redução de 60-70% no custo de armazenamento, e — mais importante — abre a janela para modernização incremental via snapshots ONTAP e pipelines Glue sem exigir um big-bang. O risco de não agir é continuar pagando o custo operacional e de licença de um Oracle on-premises que cada vez mais dificulta a adoção de arquiteturas modernas. O risco de agir é gerenciável se você sequenciar corretamente os três atos e instrumentar a observabilidade antes de migrar. Comece pelo Ato 1 este trimestre.

## Referências

- [AWS Architecture Blog: Oracle HA with FSx for NetApp ONTAP](https://aws.amazon.com/blogs/architecture/)
- [FSx for NetApp ONTAP — User Guide: iSCSI Configuration](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/supported-fsx-clients.html)
- [Oracle Data Guard Concepts and Administration](https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/)
- [AWS Well-Architected Framework — Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)
- [Oracle Licensing on AWS — Processor Core Factor Table](https://aws.amazon.com/windows/resources/licensing/oracle/)
- [FSx ONTAP — Monitoring with CloudWatch](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/monitoring_overview.html)
- [AWS Fault Injection Simulator — Chaos Engineering for RDS/EC2](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
- [Data Mesh: Delivering Data-Driven Value at Scale — Zhamak Dehghani](https://www.oreilly.com/library/view/data-mesh/9781492092384/)