Estratégias multinuvem com o Azure

Várias nuvens significa operar cargas de trabalho em mais de um provedor de nuvem — por exemplo, usar Azure para a maioria dos serviços e também AWS para uma plataforma específica de aprendizado de máquina ou Google Cloud para análises no BigQuery. As organizações adotam várias nuvens para: evitar a dependência de um único fornecedor, aproveitar os serviços líderes de cada provedor, cumprir requisitos contratuais ou regulatórios que evitem a dependência de um único provedor ou porque fusões e aquisições reuniram empresas que haviam padronizado o uso de nuvens diferentes. Atualmente, o uso de várias nuvens é comum em grandes empresas.

O uso de várias nuvens introduz desafios operacionais significativos: proliferação de competências — as equipes precisam ter experiência em várias plataformas de nuvem. Governança inconsistente — cada nuvem tem ferramentas diferentes de IAM, políticas e conformidade. Complexidade de segurança — diferentes modelos de ameaças, diferentes serviços de segurança e diferentes registros de auditoria. Gerenciamento de custos — portais de cobrança separados, unidades de preço diferentes e nenhuma visão unificada dos custos entre os provedores. Complexidade de rede — o tráfego entre nuvens gera custos de saída e latência. A Microsoft resolve muitos desses desafios com o Azure Arc e o suporte a várias nuvens no Defender for Cloud.

O mesmo agente de máquina conectada do Azure Arc que integra servidores locais também funciona em máquinas virtuais executadas no AWS EC2, no Google Cloud Compute Engine ou em qualquer outra nuvem. Depois de registradas no Arc, essas máquinas virtuais aparecem junto dos recursos nativos do Azure no portal do ARM. Pode aplicar o Azure Policy, usar o Azure Monitor com as mesmas consultas KQL e visualizar recomendações de segurança do Defender for Cloud para máquinas virtuais da AWS e do GCP — sem sair do portal do Azure nem aprender ferramentas específicas da AWS.

O Microsoft Defender for Cloud oferece conectores nativos para AWS e Google Cloud Platform. Ao conectar sua conta da AWS ou seu projeto do GCP, o Defender for Cloud pode avaliar a postura de segurança de instâncias EC2, buckets do S3, bancos de dados RDS e recursos do GCP usando a mesma estrutura Secure Score usada para o Azure. Ele mapeia as descobertas para padrões como o CIS AWS Foundations Benchmark e detecta configurações incorretas (buckets do S3 acessíveis publicamente e funções do IAM permissivas demais), exibindo-as junto das recomendações do Azure em um único painel.

O Azure Cost Management + Billing pode ingerir custos da AWS conectando o AWS Cost and Usage Report (CUR) a um Azure Connector. Isso exibe os gastos da AWS junto dos gastos do Azure em uma visão unificada de análise de custos, permitindo comparações e alocação de custos entre nuvens. Pode criar orçamentos e alertas que abrangem ambos os provedores e aplicar a mesma estratégia de marcação para atribuição ou repasse de custos. Essa visibilidade dos custos em várias nuvens é valiosa para equipes de FinOps que gerenciam gastos em vários provedores a partir de um único painel.

Muitas estratégias para várias nuvens usam o Kubernetes como camada de abstração executada da mesma forma em qualquer nuvem. O AKS no Azure, o EKS na AWS e o GKE no GCP executam o Kubernetes padrão. O Kubernetes habilitado para Azure Arc pode gerenciar todos eles a partir do Azure, aplicando implantações baseadas em GitOps e o Azure Policy (OPA Gatekeeper) de forma consistente. Imagens de contêiner armazenadas no Azure Container Registry podem ser extraídas por clusters Kubernetes de qualquer nuvem, tornando o Azure ACR um hub natural de registro de imagens para várias nuvens.

Uma Azure Landing Zone é um ambiente pré-configurado que implementa práticas recomendadas de governança, identidade, segurança e rede. Ao adotar várias nuvens, as organizações ampliam o conceito de landing zone para definir padrões aplicáveis a todos os provedores. O Cloud Adoption Framework (CAF) da Microsoft inclui orientações para várias nuvens sobre como estruturar hierarquias de grupos de gerenciamento, convenções de nomenclatura e estratégias de marcação que funcionem de maneira consistente, independentemente de o recurso estar no Azure, na AWS ou no ambiente local.

Conectar cargas de trabalho do Azure e da AWS (ou do GCP) exige uma rede entre nuvens. Padrões comuns: túneis VPN entre o Azure VPN Gateway e um AWS Virtual Private Gateway ou uma VPN do GCP — uma opção simples, mas com largura de banda limitada e latência variável. SD-WAN de terceiros (por exemplo, Megaport e Equinix Fabric) — cria circuitos privados entre nuvens semelhantes ao ExpressRoute. Integração na camada de aplicação — os serviços se comunicam por HTTPS através de endpoints públicos (a opção mais simples, mas que usa a Internet). Os custos de largura de banda de saída na AWS e no GCP tornam cara a transferência de grandes volumes de dados entre nuvens.

O Microsoft Entra ID pode atuar como provedor de identidade (IdP) para acesso a várias nuvens. Na AWS, pode configurar o Entra ID como IdP SAML 2.0 do AWS IAM Identity Center, permitindo que os usuários acessem o console da AWS com suas credenciais do Entra ID e MFA — sem usuários separados do AWS IAM. No GCP, também é possível configurar uma federação semelhante. Isso centraliza a governança de identidades — admissões, transferências e desligamentos são gerenciados no Entra ID, e o acesso é propagado automaticamente para todos os provedores de nuvem.

As práticas de FinOps (Operações Financeiras de Nuvem) tornam-se mais complexas em ambientes com várias nuvens, pois cada provedor tem modelos de preços, mecanismos de desconto e granularidade de cobrança diferentes. Práticas recomendadas: padronizar a marcação em todos os provedores para alocação de custos; usar o conector da AWS do Azure Cost Management + Billing para obter visibilidade unificada; estabelecer uma equipe de FinOps que compreenda Instâncias Reservadas (Azure), Savings Plans (AWS/Azure) e Committed Use Discounts (GCP); e realizar análises regulares de custos entre provedores, comparando o custo de cargas de trabalho equivalentes.

O uso de várias nuvens pode criar problemas se não for gerenciado com cuidado. Padrões inadequados comuns a evitar: uso acidental de várias nuvens — usar várias nuvens sem uma estratégia provoca proliferação descontrolada e aumento de custos. Sobrecarregar as competências — exigir que todos os engenheiros sejam especialistas em todas as nuvens; em vez disso, designe responsáveis pela nuvem de cada plataforma. Segurança inconsistente — aplicar linhas de base de segurança diferentes em cada nuvem; use o Azure Arc e o Defender for Cloud para impor a consistência. Ignorar os custos de saída — a transferência de dados entre nuvens é cobrada de acordo com as tarifas de saída dos provedores e pode surpreender as equipes de FinOps.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) apresentados nesta lição.

Nesta lição, você aprendeu que: o Azure Arc amplia o gerenciamento do Azure para máquinas virtuais da AWS e do GCP usando o mesmo agente de máquina conectada; os conectores do Microsoft Defender for Cloud para várias nuvens apresentam descobertas de segurança entre provedores em um Secure Score unificado; e a federação do Microsoft Entra ID permite o logon único nos consoles da AWS e do GCP a partir de uma única identidade corporativa. Isso conclui o curso Azure Hybrid and Multi-Cloud — a seguir, você conhecerá o Well-Architected Framework para avaliar e melhorar suas arquiteturas do Azure.