A nuvem híbrida no Azure combina três frentes: conectar a rede local com Azure VPN Gateway ou Azure ExpressRoute, gerenciar servidores existentes com Azure Arc e rodar infraestrutura local em hardware validado com Azure Local. A implementação segue assessment, conectividade, identidade com Microsoft Entra ID, onboarding em lotes e governança contínua.
A nuvem híbrida no Azure é o modelo em que parte dos recursos da empresa continua fora das regiões do Azure e passa a ser conectada, gerenciada e governada por serviços da Microsoft. A implementação se organiza em três frentes: conectar a rede local ao Azure, estender a gestão do Azure aos servidores que ficam onde estão, com o Azure Arc, e rodar infraestrutura com consistência Azure dentro da empresa, com o Azure Local.
Este roteiro parte de uma decisão já tomada: a empresa vai manter uma parte do ambiente fora do Azure, e o que resta é implementar com ordem, requisitos e responsáveis definidos.
Para o CEO e o CFO, o roteiro mostra o que cada etapa exige em decisão, dependência externa e risco. Para a equipe de TI, serve de ordem de trabalho.
Como planejar a nuvem híbrida no Azure antes de implementar
O planejamento define três coisas antes de qualquer instalação: o que existe hoje, qual produto Azure cobre cada necessidade e como o ambiente local conversa com o Azure. Erro aqui vira retrabalho quando já há servidores conectados.
Assessment: inventário, classificação de cargas e requisitos de continuidade
O assessment é o levantamento que sustenta todas as decisões seguintes. Ele precisa entregar, no mínimo, estes itens:
- inventário de servidores, sistemas e dependências entre eles;
- requisitos de latência e de dados de cada carga;
- RTO e RPO por carga: o tempo de parada e a perda de dados que cada sistema suporta;
- confirmação de que as regras de residência e soberania permitem os locais de réplicas e backups;
- definição de quem é dono de hardware, plataforma, cargas, identidade, segurança e rede.
Um plano de controle comum reduz as diferenças entre os ambientes, mas não elimina tarefas específicas de cada plataforma. Sem esse levantamento, a escolha de conectividade e de hardware vira palpite, e o custo aparece depois.
Qual abordagem usar: Azure Arc, Azure Local ou conectividade com cargas no Azure
As três frentes resolvem problemas diferentes e podem ser combinadas. A própria Microsoft afirma que uma solução híbrida pode reunir mais de uma abordagem, e que o Azure Arc não transforma a plataforma subjacente em Azure Local.
| Frente | O que resolve | Requisito principal |
|---|---|---|
| Azure VPN Gateway ou Azure ExpressRoute | Comunicação entre cargas que rodam no Azure e cargas que ficam no ambiente local | Dispositivo VPN local compatível ou circuito contratado com provedor |
| Azure Arc | Gestão no Azure de servidores, clusters Kubernetes e bancos de dados que continuam onde estão | Agente instalado em cada servidor e saída de rede liberada |
| Azure Local | Infraestrutura com consistência Azure dentro da empresa | Hardware validado de parceiros Microsoft |
O Azure Arc projeta no Azure Resource Manager recursos que rodam fora do Azure: servidores Windows e Linux, físicos ou virtuais, clusters Kubernetes, SQL Server e VMs em VMware vCenter e System Center Virtual Machine Manager. Os servidores não mudam de lugar e passam a ser gerenciados com as políticas, a segurança e o monitoramento do Azure.
Cargas que fazem sentido no Azure podem ser migradas, mas essa é uma alternativa, não uma etapa deste roteiro. Quem já tem servidor funcionando pode gerenciá-lo com o Azure Arc sem trocar o hardware. Quem precisa de infraestrutura local nova recorre ao Azure Local.
Conectividade e identidade: VPN Gateway, ExpressRoute e Microsoft Entra ID
A escolha entre Azure VPN Gateway e Azure ExpressRoute troca simplicidade por previsibilidade. O VPN Gateway cria um túnel criptografado com IPsec/IKE pela internet pública. A configuração é mais simples e não exige provedor, mas a empresa mantém o dispositivo VPN local compatível. O SLA de 99,9% cobre apenas o gateway, não o caminho pela internet. Em topologia padrão, chega a 10 Gbps agregados, conforme o SKU.
O ExpressRoute entrega uma conexão privada, redundante e dedicada, por meio de um provedor de conectividade, com até 10 Gbps por circuito e latência mais previsível. O preço dessa previsibilidade é a dependência externa: a contratação exige coordenação com o provedor. O peering privado não é criptografado por padrão: a criptografia exige MACsec ou IPsec sobre o ExpressRoute.
Na prática, a VPN serve como caminho simples ou de contingência, e o ExpressRoute atende as cargas que não toleram variação de latência. Escolher VPN para uma carga que exige previsibilidade é erro de projeto. Escolher ExpressRoute sem considerar o provedor ignora uma dependência externa que o cronograma precisa absorver.
A identidade vem antes de ligar tudo. O Microsoft Entra ID unifica o acesso aos recursos do Azure e aos recursos Arc, e o controle de acesso baseado em função (RBAC) deve valer desde o primeiro servidor. Para a diretoria, isso responde a uma pergunta de governança: quem pode alterar o quê, e onde isso fica registrado.
Implementação da nuvem híbrida no Azure com Azure Arc e Azure Local
A implementação acontece em três etapas: conectar os servidores existentes, implantar o Azure Local onde houver infraestrutura nova e aplicar governança sobre tudo.
Etapa 1: conectar servidores com Azure Arc
O ponto de entrada mais comum é o Azure Arc-enabled servers, que gerencia servidores físicos e VMs na rede corporativa ou em outro provedor. Para conectar, instala-se o agente Azure Connected Machine, manualmente ou em escala por um método de implantação. Cada máquina conectada recebe um Resource ID e pode entrar em um grupo de recursos do Azure.
O requisito crítico é a rede. O agente faz conexões de saída pela porta TCP 443, em HTTPS com TLS, e por padrão usa a rota padrão para a internet. O firewall precisa liberar os service tags e os endpoints da documentação vigente da Microsoft. Descobrir o bloqueio só depois da instalação é um erro comum desta etapa.
Duas opções reduzem a exposição. O Azure Arc gateway diminui a quantidade de endpoints que precisam ser liberados no firewall. O Azure Arc private link scope evita o uso de redes públicas, embora alguns endpoints sigam públicos.
O onboarding deve ser em lotes pequenos, começando por um grupo piloto, com política e monitoramento ligados desde o primeiro servidor.
O agente envia um heartbeat a cada 5 minutos. Sem ele, o status muda para Disconnected em 15 a 30 minutos. Uma máquina que passa 45 dias desconectada pode ficar Expired e só volta a ser gerenciada depois de desconexão e nova conexão feitas pelo administrador.
Etapa 2: implantar o Azure Local onde houver infraestrutura local nova
O Azure Local, nome atual do antigo Azure Stack HCI, é a solução de infraestrutura da Microsoft que estende o Azure ao ambiente do cliente, com o Azure Arc como plano de controle. Roda em hardware validado, adquirido de parceiros OEM Microsoft e listado no catálogo de soluções do Azure Local. A empresa e seus parceiros operam instalação, hardware e integração de rede locais.
O tipo de implantação define o tamanho do projeto:
- hiperconvergida, com clusters de 1 a 16 máquinas;
- desagregada, com até 64 máquinas e SAN;
- multi-rack, para centenas de máquinas.
Nas implantações hiperconvergida e desagregada, as cargas suportadas incluem Azure Local VMs, AKS, SQL Server e Azure Virtual Desktop. Comprar hardware sem checar o catálogo e o tipo de implantação é um erro comum desta etapa.
No modo conectado, o plano de controle fica no Azure. Se a conexão cai, o hardware e as VMs existentes continuam rodando, mas os recursos que dependem da nuvem ficam indisponíveis. Nas implantações hiperconvergidas, a sincronização com o Azure precisa ocorrer ao menos uma vez a cada 30 dias. Passado esse prazo, o ambiente entra em funcionalidade reduzida e deixa de criar VMs. Em unidade com internet instável, a conexão é parte do projeto.
Etapa 3: aplicar governança e segurança
Com os servidores representados no Azure, a governança passa a usar as mesmas ferramentas para o ambiente local e para o Azure. Cada uma cobre uma função:
- Azure Policy, com a machine configuration, audita as configurações dos servidores;
- Microsoft Defender for Cloud protege os servidores com o Microsoft Defender for Endpoint, e a integração com o Microsoft Sentinel também está disponível;
- Azure Monitor, com o Azure Monitor Agent e o Log Analytics, reúne logs e métricas, e o VM insights mostra o comportamento das máquinas;
- Azure Update Manager cuida das atualizações de sistema operacional.
O Azure Arc também conecta o Azure Automation, o Change Tracking e o Inventory aos servidores. Para a gestão, a mesma política do Azure passa a valer para os servidores Arc.
Operar, proteger e controlar custos depois da implementação
A operação começa quando o ambiente está conectado e governado, e envolve monitoramento, atualização, continuidade, custo e responsabilidade por camada.
Monitoramento, atualização e continuidade
O Azure Monitor e o Log Analytics sustentam o monitoramento contínuo, e o Azure Update Manager mantém o calendário de atualizações. As duas tarefas seguem rotina definida, não a memória de quem opera.
Na continuidade, o Azure Site Recovery é uma opção para replicar VMs do Azure Local para o Azure. Replicação e backup só valem se forem testados. A Microsoft recomenda testar restauração e failover contra os objetivos de RTO e RPO definidos no assessment.
O plano também precisa prever a queda de conexão: o procedimento de contingência deve dizer quais serviços seguem funcionando e quem decide o que fazer.
De que se compõe o custo e quem opera cada camada
O custo da nuvem híbrida no Azure se divide por serviço. No Azure Arc em servidores, os recursos de controle básicos não têm custo adicional: grupos de gerenciamento e tags, Azure Resource Graph, RBAC, modelos e extensões. Os serviços do Azure usados sobre esses servidores, como o Defender for Cloud e o Azure Monitor, são cobrados conforme o preço de cada um.
O Azure Local é cobrado por núcleo físico das máquinas locais, mais o consumo de serviços adicionais do Azure, e as cobranças entram na assinatura Azure existente. A conta do CFO vai além dessa linha. No CAPEX entram hardware e integração de rede. No OPEX, software, suporte, energia, refrigeração, espaço, conectividade, backup e ciclo de vida do hardware.
A divisão de responsabilidades definida no assessment precisa virar rotina: quem cuida do hardware, da rede, da plataforma, das cargas, da identidade e da segurança. Camada sem responsável nomeado é tarefa que ninguém executa.
Como a Qualiserve conduz Assessment, Setup, Sustentação e Evolução
A Qualiserve, parceira Microsoft de serviços gerenciados com 20 anos de mercado, trabalha em quatro fases: Assessment, Setup, Sustentação e Evolução. O Assessment mapeia servidores, sistemas e dependências, define o caminho (Azure Arc, Azure Local, conectividade ou uma combinação) e desenha a implantação por fases. A empresa tem NOC próprio, que monitora mais de 20.000 dispositivos.
Quem quiser começar pode conversar com a Qualiserve sobre um assessment do seu ambiente. O contato pode ser feito pelo formulário do site.
Perguntas frequentes sobre implementação de nuvem híbrida no Azure
O Azure Stack HCI ainda existe?
O nome mudou: o Azure Stack HCI passou a se chamar Azure Local, anunciado no Ignite 2024. Clientes existentes migraram sem custo, e preço, licenciamento e suporte permaneceram os mesmos, segundo a Microsoft.
Um proxy deixa o agente do Azure Arc mais seguro?
Não. O proxy é opcional e não torna o agente mais seguro, porque o tráfego já é criptografado com TLS.
Por quanto tempo vale a credencial de um servidor Arc?
A credencial da identidade gerenciada vale até 90 dias e é renovada a cada 45.
O Azure Local funciona em modo desconectado?
Existe o modo desconectado, mas ele exige o Azure Local 2602 ou posterior e critérios de elegibilidade rígidos. Para uma PME, é exceção. O caminho normal é o modo conectado.
Rodar o Azure Local garante conformidade com a LGPD ou soberania de dados?
Não. A própria Microsoft afirma que rodar localmente não satisfaz esses requisitos por si só. É preciso avaliar controle, identidade, atualização e suporte.
Um parceiro de serviços gerenciados consegue operar os servidores conectados ao Azure Arc?
Sim, a gestão pode ser delegada. O Azure Arc-enabled servers é compatível com o Azure Lighthouse, serviço de gestão delegada do Azure, o que permite a um parceiro de serviços gerenciados operar o ambiente conforme as permissões do cliente.
