Azure encontra SAP: SAP on Azure explicado para o Microsoft Teams

By Mirko Peters · 2026-11-05

O que significa, na prática, rodar SAP no Microsoft Azure: máquinas virtuais e armazenamento certificados, a landing zone que você constrói primeiro, conectividade híbrida, os três caminhos de implantação e os erros que transformam um sistema SAP suportado em um sistema não suportado.

Automatically translated with AI from the original post. Read the English original

Como Microsoft MVP, passo a maior parte do meu tempo com pessoas que conhecem o Azure, o Entra ID e o Microsoft 365 a fundo e que, de repente, são solicitadas a "dar suporte à migração do SAP". Para muitas delas, o SAP parece um universo à parte, com vocabulário próprio. A boa notícia: o SAP no Azure é bem mais comum do que parece. Resume-se a duas regras. Fique dentro de configurações certificadas e construa a fundação antes de o primeiro sistema SAP entrar no ambiente. Este post percorre as duas, na ordem em que você realmente trabalharia.

O que SAP on Azure realmente significa

SAP on Azure significa que seus sistemas SAP rodam no Microsoft Azure. O banco de dados SAP HANA, os servidores de aplicação e os serviços centrais ficam em máquinas virtuais do Azure e utilizam o armazenamento e a rede do Azure. O software SAP em si não muda: o SAP S/4HANA continua sendo S/4HANA, o SAP NetWeaver continua sendo NetWeaver. Muda apenas a base por baixo.

Essa divisão mostra quem é responsável por cada parte. A Microsoft fornece a plataforma: máquinas virtuais, discos, redes, identidade e monitoramento. A SAP fornece a aplicação e o banco de dados, e você os opera da forma que a SAP espera. O ponto de encontro dos dois é a infraestrutura certificada no meio.

Vale separar isso de um segundo tema, relacionado. Copiar dados do SAP para o Azure a fim de gerar relatórios no Power BI ou no Microsoft Fabric é integração de dados, um trabalho útil, mas diferente. Rodar SAP no Azure significa que o próprio sistema de produção vive ali, processa suas transações ali e atende seus usuários a partir dali.

Se você quiser primeiro a visão geral da família de produtos SAP, a página de tópico sobre SAP no M365.FM reúne nosso conteúdo relacionado.

Por que "certificado" decide tudo

No mundo SAP, "roda no Azure" significa, na prática, "roda em um Azure certificado". A SAP e a Microsoft testam tipos específicos de máquinas virtuais e opções de armazenamento contra produtos e cenários SAP específicos, e somente essas combinações são suportadas. A Microsoft documenta as certificações e configurações SAP para o Azure e o software SAP suportado no Azure. Para o SAP HANA, o próprio HANA Hardware Directory da SAP é a lista oficial; para sistemas baseados em NetWeaver, a SAP Note 1928533 relaciona os tipos de VM do Azure suportados.

A certificação não é uma propriedade do Azure como um todo. É uma propriedade de uma VM específica, de uma opção de armazenamento específica e de um cenário SAP específico, alinhados entre si. Uma VM generosa, perfeita para uma aplicação web, pode simplesmente não estar na lista para o HANA. Se você a escolher mesmo assim, não economizou dinheiro: construiu um sistema que nenhum dos dois fornecedores precisa sustentar.

O mesmo raciocínio vale para o armazenamento. Discos gerenciados do Azure são o bloco básico do dia a dia, o Azure NetApp Files oferece armazenamento NFS usado em várias arquiteturas SAP, e o Azure Files em armazenamento premium (SSD) pode hospedar diretórios compartilhados. O nível padrão, mais barato, do Azure Files não é compatível com os compartilhamentos de alta disponibilidade dos serviços centrais do SAP, então a opção barata é a opção errada nesse caso. A Microsoft lista esses limites em seus cenários suportados para cargas de trabalho SAP em máquinas virtuais do Azure.

O hábito que evita a maioria dos problemas: antes de dimensionar qualquer máquina, abra a lista certificada para o seu produto SAP e cenário e projete a partir dela.

A landing zone que você constrói primeiro

Uma landing zone do Azure é a fundação que oferece identidade, rede, segurança e governança para cada carga de trabalho antes de qualquer coisa ser implantada nela. O Cloud Adoption Framework da Microsoft a divide em duas partes:

• Landing zone de plataforma: a base compartilhada, com grupos de gerenciamento, conectividade central, identidade, segurança e serviços de gerenciamento.
• Landing zones de aplicação (carga de trabalho): os ambientes individuais, normalmente desenvolvimento, teste e produção, cada um formado por assinaturas que herdam as salvaguardas da plataforma.

Para o SAP isso importa mais do que para a maioria das cargas de trabalho, porque o SAP sustenta finanças, cadeia de suprimentos e operações. Políticas, regras de rede e identidade devem existir antes que o primeiro sistema SAP entre no ambiente. Incluí-las depois significa mover recursos em torno de um sistema de negócio em produção.

A Microsoft oferece um acelerador de landing zone para SAP no Azure, com projetos de referência baseados em topologia de rede hub-and-spoke ou Azure Virtual WAN. O Azure Policy e a hierarquia de grupos de gerenciamento definem as salvaguardas, e cada sistema SAP então entra dentro delas. É isso que permite que o segundo e o terceiro sistemas SAP cheguem sem um novo debate sobre nomenclatura, acesso e regras de rede.

Mantendo o SAP conectado ao seu data center

Levar o SAP para o Azure raramente significa deixar tudo para trás. A maioria dos ambientes continua híbrida por muito tempo, então a conectividade é a ponte que os mantém unidos.

A principal opção privada é o Azure ExpressRoute, uma conexão privada dedicada entre o seu data center e o Azure, em vez de tráfego pela internet pública. Quando o ExpressRoute não está disponível, a VPN site a site é a alternativa. De qualquer forma, a conexão normalmente termina no hub central ou no Virtual WAN, e a rede virtual do SAP acessa esse ponto a partir dali. Dentro do Azure, um projeto típico de SAP separa as camadas de aplicação e de banco de dados em sub-redes próprias, protegidas por grupos de segurança de rede, tabelas de rotas e um firewall.

A identidade merece uma análise cuidadosa, porque é aqui que as equipes Microsoft costumam fazer suposições. O Microsoft Entra ID é excelente para single sign-on em aplicações SAP. Mas sistemas SAP NetWeaver e S/4HANA rodando em Windows não usam contas do Entra ID para a própria aplicação SAP. Eles ainda esperam o Active Directory Domain Services, seja estendido a partir do ambiente on-premises, seja fornecido pelo Microsoft Entra Domain Services. Autenticação de login e diretório do sistema operacional são duas histórias diferentes.

Suas três opções de implantação

Não existe um único jeito certo de implantar o SAP no Azure. Escolha o caminho que combina com a forma como a sua equipe opera.

1. Máquinas virtuais do Azure puras. Você gerencia o sistema operacional, a instalação do SAP, os patches e o monitoramento por conta própria. Controle máximo, trabalho máximo. Boa escolha quando há competência em SAP e Azure dentro da equipe.
2. Azure Center for SAP solutions. Um serviço do Azure que torna o SAP uma carga de trabalho de primeiro nível. Ele pode criar a infraestrutura e instalar o software SAP para sistemas de servidor único, distribuídos e distribuídos com alta disponibilidade, ou registrar sistemas SAP que já rodam no Azure. Cada sistema se torna uma Virtual Instance for SAP solutions, uma visão lógica do SID, dos serviços centrais, do banco de dados e dos servidores de aplicação. A partir daí, você acompanha a integridade e o status, inicia e para o sistema, executa verificações de qualidade com base nas melhores práticas e acompanha os dados de monitoramento. Os detalhes estão na visão geral do Azure Center for SAP solutions.
3. SAP on Azure deployment automation framework. Uma abordagem de infraestrutura como código, de código aberto, para equipes que querem implantações repetíveis, versionadas e um fluxo de trabalho de DevOps.

Uma regra simples de decisão: controle total e habilidades sólidas apontam para VMs simples; uma configuração guiada, com um único lugar para gerenciar o sistema, aponta para o Azure Center for SAP solutions; muitos sistemas implantados da mesma forma apontam para o automation framework.

Erros comuns

As primeiras migrações mais dolorosas costumam seguir um padrão: uma etapa que parecia opcional.

• Tratar a certificação como burocracia. Um tipo de VM ou de armazenamento sem certificação transforma um sistema suportado em um sistema não suportado, e você normalmente descobre isso no pior momento.
• Pular a landing zone. "Adicionamos a governança depois" raramente acontece, e reajustar regras de identidade e rede em torno de um sistema SAP em produção é lento e arriscado.
• Presumir que o Entra ID substitui o Active Directory em sistemas SAP baseados em Windows. Não substitui.
• Projetar a conectividade por último. Dividir a camada de aplicação SAP e a camada de banco de dados entre o ambiente local e o Azure, ou entre regiões do Azure, não é suportado.
• Presumir que tudo roda no Azure. O Azure VMware Solution geralmente não é uma plataforma suportada para hospedar cargas de trabalho SAP, e as SAP HANA Large Instances não são mais oferecidas a novos clientes.
• Usar o Azure Site Recovery para o banco de dados. O Azure Site Recovery não é suportado para a camada de banco de dados SAP; use a replicação nativa do banco de dados, como o SAP HANA System Replication, para recuperação de desastres.

Cada um desses pontos é onde os limites de suporte da Microsoft e da SAP deixam de coincidir. Os limites não existem para atrapalhar você; eles marcam a área em que ambos os fornecedores vão responder pelo seu sistema.

Conclusão: a ordem das operações

Se você se lembrar de apenas uma coisa, lembre-se da sequência. Defina o que o sistema SAP precisa em desempenho, disponibilidade e recuperação. Construa a landing zone. Conecte a rede e o diretório de volta ao seu data center. Escolha quanto você quer gerenciado: VMs simples, Azure Center for SAP solutions ou o automation framework. Escolha computação e armazenamento certificados. Depois, projete a alta disponibilidade e a recuperação de desastres com base nos próprios recursos do banco de dados.

Você não precisa mover tudo de uma vez. Começar com um sistema mostra onde sua landing zone está fraca e onde sua equipe precisa de apoio, enquanto os riscos ainda são pequenos. Para profissionais da Microsoft, o SAP no Azure não é um mundo estranho. É um conjunto de decisões normais de engenharia, com a certificação como a única regra que você nunca quebra.