SQL Server na Nuvem: Diferenças Reais Entre AWS, OCI e Azure

Clientes migrando SQL Server para a nuvem costumam nos perguntar qual provedor "faz mais sentido". A resposta raramente é sobre preço de instância — depende do modelo de serviço que cada nuvem oferece para SQL Server, que varia muito mais do que parece à primeira vista. Neste artigo, comparamos como AWS, OCI e Azure entregam SQL Server hoje, com foco no que muda na operação do dia a dia de quem administra o banco.

1. Três modelos de serviço, não três "versões da mesma coisa"

Antes de comparar recursos, vale entender que as três nuvens não competem no mesmo nível de abstração:

• AWS oferece SQL Server principalmente como banco gerenciado (PaaS) via Amazon RDS — você não tem acesso ao sistema operacional por padrão.

• Azure oferece um espectro: da VM com controle total (IaaS) até o Managed Instance, que é PaaS com compatibilidade quase completa com o motor on-premises.

• OCI não tem um serviço PaaS nativo equivalente ao RDS ou ao Managed Instance para SQL Server. A oferta é baseada em máquinas virtuais — você monta e opera o ambiente, com a Oracle fornecendo a infraestrutura e, em alguns casos, imagens prontas no Marketplace.

Essa diferença de modelo é o fator que mais deveria pesar na decisão — mais do que comparação de preço por vCPU.

2. AWS — Amazon RDS for SQL Server

RDS for SQL Server é um serviço totalmente gerenciado: a AWS cuida de provisionamento, patch de SO e engine, backup automatizado e failover.

Versões e edições suportadas: Enterprise, Standard, Web, Developer e Express, nas versões 2014, 2016, 2017, 2019, 2022 e 2025. Deve-se verificar a região e a versão que será instalada, pois, nem todas as versões e edições são suportadas em todos as regiões.

Alta disponibilidade: Multi-AZ via SQL Server Database Mirroring (DBM) ou via Always On Availability Groups (Multi-AZ com AGs está disponível desde 2022, incluindo Standard Edition a partir da versão 2017). Pontos importantes sobre essa configuração:

• A instância secundária não aceita leitura — diferente do padrão de read replica de outros engines no RDS.

• Não é possível renomear um banco enquanto o Multi-AZ está ativo (é preciso desativar, renomear, reativar).

• O listener do Availability Group não suporta autenticação Kerberos.

• Não é possível parar (stop) uma instância RDS SQL Server configurada em Multi-AZ.

Limitações operacionais relevantes:

• Sem acesso ao sistema operacional por padrão — não há RDP/SSH para o host.

• Portas reservadas pelo serviço, que não podem ser usadas pela instância: 1234, 1434, 3260, 3343, 3389, 47001 e 49152–49156.

• O limite de processadores efetivamente utilizados pela edição Standard segue o limite da própria Microsoft para essa edição (historicamente 24 núcleos / 4 soquetes / 128 GB de RAM para versões pré-2025 — vale conferir o guia de licenciamento SQL Server 2025 que publicamos recentemente, já que a Microsoft ampliou esses limites na Standard a partir da versão 2025).

RDS Custom for SQL Server: é a opção intermediária para quem precisa de acesso ao SO sem abrir mão de boa parte da automação do RDS. Permite acesso via Systems Manager ou RDP para instalar patches, habilitar CLR, configurar linked servers heterogêneos ou ultrapassar o limite padrão de 100 bancos por instância — mas o modelo de responsabilidade compartilhada passa a exigir que você mesmo cuide do patch de SO, e mudanças manuais no SO feitas após a criação da instância não são persistentes em todos os cenários. OBS: O comportamento exato de persistência de alterações de SO no RDS Custom pode variar por tipo de operação — confirme na documentação da AWS antes de planejar uma migração que dependa disso.

SQL Server em VM EC2 da AWS (IaaS): você instala e administra o SQL Server como faria on-premises. Controle total sobre patch, recovery model, Agent, linked servers, SSRS e SSIS nativos. É a opção mais indicada para lift-and-shift rápido de ambientes que dependem de recursos não suportados no RDS normal. Toda a responsabilidade de HA/DR (Always On, FCI, log shipping), patch e backup é sua. OBS: Embora não seja necessariamente um RDS, eu coloquei aqui na lista, pois, a Azure oferece algo parecido, com nome diferente.

3. Azure — três caminhos possíveis

Azure é a única das três nuvens que oferece um espectro completo de opções para SQL Server.

SQL Server em VM do Azure (IaaS): você instala e administra o SQL Server como faria on-premises. Controle total sobre patch, recovery model, Agent, linked servers, SSRS e SSIS nativos. É a opção mais indicada para lift-and-shift rápido de ambientes que dependem de recursos não suportados no Managed Instance. Toda a responsabilidade de HA/DR (Always On, FCI, log shipping), patch e backup é sua. OBS: equivalente a uma EC2 com SQLServer isntalado na AWS.

Azure SQL Managed Instance (PaaS): compatibilidade quase completa (a Microsoft usa o termo "near 100%") com o motor SQL Server, rodando dentro de uma VNet dedicada. A Microsoft gerencia patch, backup automatizado e alta disponibilidade.

• SLA de 99,99% nos tiers General Purpose e Business Critical; sobe para 99,995% com zona-redundância habilitada (Business Critical desde 2022; General Purpose passou a suportar zona-redundância a partir de junho de 2025, segundo a documentação da Microsoft).

• Business Critical usa tecnologia Always On Availability Groups internamente, com armazenamento local replicado entre réplicas. General Purpose usa modelo de armazenamento remoto (compute e storage separados).

• SSIS é suportado via Azure-SSIS Integration Runtime — não é a mesma experiência de rodar SSIS nativo em uma VM.

• Backup manual para blob (BACKUP TO URL) tem restrições: backups diferenciais, de log e file snapshot não são suportados nesse modo manual, já que o serviço já faz backup automático gerenciado. Convém verificar detalhes exatos dessa restrição antes de desenhar uma estratégia de backup híbrida — a documentação da Microsoft muda com frequência nessa área.

Azure SQL Database: vale mencionar rapidamente porque também aparece nas comparações, mas é um nível de abstração diferente (banco único ou elastic pool, não uma instância completa) — normalmente não é a opção equivalente quando o objetivo é migrar uma instância SQL Server existente sem redesenho de aplicação. Alguns projetos que usamos este ambiente para redução considerável de custo em aplicações legado, exigiram um certo nível de re-escrita dos códigos e unificação de bancos. Ou seja, é uma opção com algumas restrições.

4. OCI — Oracle Cloud Infrastructure

Este é o ponto que mais surpreende quem vem de AWS ou Azure: a OCI não tem um serviço PaaS gerenciado para SQL Server. As opções são:

Imagens do Oracle Cloud Marketplace: compute instances pré-configuradas com SQL Server, publicadas pela Oracle ou por parceiros, algumas com licença incluída (license included) e outras BYOL. É possível, por exemplo, encontrar uma listagem ativa de "SQL Server 2019 Standard on Windows Server 2019". O catálogo completo de versões disponíveis no Marketplace muda com frequência — confirme diretamente em cloudmarketplace.oracle.com quais versões e edições estão publicadas no momento do projeto, antes de assumir que uma versão específica (ex: 2022) está disponível como imagem pronta.

Self-managed em compute instance ou bare metal: você provisiona a VM (ou bare metal) e instala o SQL Server com sua própria licença (BYOL), como faria em qualquer infraestrutura própria. Esse é hoje o caminho mais comum para quem quer uma versão específica não coberta pelo Marketplace.

Licenciamento: a Microsoft permite License Mobility through Software Assurance para mover licenças elegíveis para a OCI, em hosts bare metal ou ambientes virtualizados especificados pela Oracle. Porém, as regras de elegibilidade de License Mobility mudam por tipo de licença e por atualização dos termos da Microsoft — não assuma elegibilidade sem confirmar com o time de licenciamento antes de orçar o projeto.

Alta disponibilidade: não existe um recurso gerenciado equivalente ao Multi-AZ do RDS ou ao HA automático do Managed Instance. A própria Oracle documenta uma arquitetura de referência para montar Always On Availability Groups manualmente sobre compute instances da OCI, usando o OCI Load Balancer para o listener do AG — ou seja, é você (ou nós) quem desenha e opera essa HA, não um recurso "ligar e usar".

Resumo operacional: na OCI, o modelo de responsabilidade é essencialmente o mesmo de rodar SQL Server em qualquer VM própria — patch, backup, HA e DR são 100% seus (ou do parceiro que opera o ambiente), independente de a imagem ter vindo do Marketplace ou de instalação manual.

5. Comparativo direto

Modelo de serviço

• AWS (RDS): PaaS gerenciado

• Azure (Managed Instance): PaaS quase completo

• Azure (VM): IaaS

• OCI: IaaS

Acesso ao sistema operacional

• AWS (RDS): Não (RDS Custom oferece acesso parcial)

• AWS (EC2): Sim

• Azure (Managed Instance): Não

• Azure (VM): Sim

• OCI: Sim

Alta disponibilidade nativa gerenciada

• AWS (RDS): Sim (Multi-AZ)

• AWS (EC2): Não - você mesmo monta (Always On, FCI, Log Shipping)

• Azure (Managed Instance): Sim

• Azure (VM): Não — você mesmo monta (Always On, FCI, log shipping)

• OCI: Não — você mesmo monta

Compatibilidade com o engine on-premises

• AWS (RDS): Alta, com restrições típicas de PaaS

• AWS (EC2): Total

• Azure (Managed Instance): Quase total

• Azure (VM): Total

• OCI: Total

SSIS/SSRS nativos

• AWS (RDS): Não

• AWS (EC2): Sim

• Azure (Managed Instance): SSIS via Azure-SSIS Integration Runtime; SSRS não suportado

• Azure (VM): Sim

• OCI: Sim

Modelo de licenciamento

• AWS (RDS): Incluído no preço da instância (License Included) ou BYOL

• AWS (EC2): Licend Included ou BYOL

• Azure (Managed Instance): Incluído ou BYOL via Azure Hybrid Benefit

• Azure (VM): BYOL ou pay-as-you-go

• OCI: License included (imagens do Marketplace) ou BYOL

  
  

6. Qual escolher

• Lift-and-shift rápido, com dependência de recursos legados (SSIS nativo, CLR, linked servers heterogêneos, jobs customizados): VM no Azure, VM EC2 na AWS, ou RDS Custom for SQL Server na AWS se quiser manter parte da automação gerenciada.

• Reduzir esforço operacional ao máximo, sem abrir mão de HA: RDS for SQL Server (AWS) ou Azure SQL Managed Instance — a escolha entre os dois costuma depender de qual nuvem já hospeda o resto da aplicação.

• Ambiente já concentrado em OCI (por exemplo, por causa de outras cargas Oracle Database): SQL Server via Marketplace ou self-managed, aceitando que HA, patch e backup serão desenhados e operados por você — ou pela Siltech.

• Portabilidade de licença já paga (BYOL): as três nuvens suportam, mas vale confirmar com o time de licenciamento as regras específicas de License Mobility para cada uma antes de comprometer o orçamento.

  
  

Conclusão

A pergunta "qual nuvem é melhor para SQL Server" tem menos a ver com preço e mais com quanto controle operacional você quer manter. AWS entrega o modelo mais gerenciado, com menos acesso e mais automação. Azure é a única que oferece o espectro completo, do full-managed ao full-control, dentro da mesma nuvem. OCI, hoje, exige que você (ou seu parceiro de infraestrutura) assuma a operação do zero, com o benefício de rodar ao lado de outras cargas Oracle na mesma plataforma.

Precisa avaliar qual modelo se encaixa no seu ambiente? Nossa equipe pode analisar seu cenário atual e recomendar a arquitetura mais adequada.

Contato: contato@siltechconsult.com.br — www.siltechconsult.com.br

Aviso: as informações técnicas deste artigo têm como base a documentação oficial da AWS, Microsoft e Oracle, verificadas em julho de 2026. Vale lembrar que alguns detalhes mudam com frequência (versões suportadas, catálogo de imagens, regras de licenciamento) e devem ser confirmados na documentação oficial antes de qualquer decisão de projeto.