Protegendo Máquinas no Azure VMware Solution com Azure Firewall
O Azure VMware Solution oferece três opções principais de conectividade outbound para a Internet. A primeira é o Managed SNAT, opção padrão e totalmente gerenciada pela plataforma, em que o próprio AVS realiza a tradução de endereços (SNAT) para permitir o acesso à Internet. Essa abordagem é simples e não requer configuração adicional, porém não oferece controle sobre os endereços IP públicos utilizados. A segunda opção é o uso de Public IPs no NSX-T Edge, onde o administrador atribui endereços públicos diretamente ao edge do ambiente AVS. Com isso, o tráfego de saída das máquinas virtuais utiliza esses IPs específicos, permitindo maior controle, ideal para cenários em que é necessário manter IPs fixos ou previamente autorizados em listas de acesso externas. Por fim, há a opção de rotear o tráfego via rede Azure (ou Azure Virtual WAN), em que uma rota padrão é anunciada por meio do ExpressRoute, direcionando o tráfego de saída para uma rede Azure que contém NVAs, Azure Firewall ou proxies. Essa abordagem oferece o maior nível de controle e segurança, pois permite aplicar inspeção, políticas e NAT centralizados, de forma integrada à arquitetura de rede do cliente. Neste artigo será demonstrado em um ambiente de laboratório como utilizar o Virtual Wan com Azure Firewall para inspeção do tráfego de saída das Vms em um segmento do AVS A arquitetura do laboratório. Virtual Wan com Azure Firewall ER Gateway conectado ao Express Route do Azure VMware Solution Os passos necessários são: Configuração da opção de Internet Connectivity do AVS Habilitar a propagação da Rota no Vwan Configuração do Routing Intent Configuração do Azure VMware Solution. Acesse o Private Cloud no portal do Azure e certifique que a opção abaixo esteja selecionada. Fazendo um "dump" das rotas no T0 do NSX, é possível verificar que não temos a rota default sendo propagada. Portanto não temos conectividade para internet a partir da máquina VM1 que está no AVS. Habilitando a propagação da Rota default no Virtual Wan Devemos agora habilitar a propagação da rota default pelo Virtual Wan , e para isso é necessário editar a conexão do Express Route do AVS, conectado ao Hub do Vwan . Habilite a propagação da Rota default Routing Intent O Routing Intent no Azure Virtual WAN é um recurso que simplifica e automatiza o roteamento de tráfego dentro do hub do Virtual WAN. Ele define como o tráfego entre redes (VNets, branches, e Internet) deve ser direcionado, sem necessidade de configurar manualmente tabelas de rotas complexas Observação: Em geral, no Brasil, caso já exista um Express Route On-premises, o Routing Intent já deve estar ativado para permitir o tráfego na comunicação com o Express Route do AVS, devido a não disponibilidade na região do Brasil do Express Route Global Reach Nas configurações do HUB, habilite o Routing Intent. Fazendo um novo "dump"das rotas BGP no NSX, agora é possível observar a rota default sendo propagada. Testando a partir da VM no AVS Conforme esperado é o mesmo IP público do meu Firewall no Vwan Nos Logs do Azure Firewall, comprovamos que o tráfego da VM (10.145.0.10) realmente está passando pelo Azure Firewall Referências: https://learn.microsoft.com/en-us/azure/azure-vmware/disable-internet-access
Zonas de Disponibilidade no Azure: Entendendo a Diferença entre Zonas Lógicas e Físicas
O que é o mapeamento de zonas do Azure (Zona Lógica vs Zona Física) No Azure, as Zonas de Disponibilidade (AZs) são agrupamentos de datacenters fisicamente separados dentros de uma mesma região. Cada zona possui infraestrutura independente - energia, refrigeração e rede - garantindo alta disponibilidade e resiliência. Porém, há uma distinção entre: Tipo de Zona Definição Zona Lógica Identificador exibido no portal do Azure (AZ1, AZ2, AZ3). Zona Física Grupo real de datacenters. O mapeamento entre lógica e física varia por assinatura O mapeamento entre zonas lógicas e físicas não é fixo. Isso significa que: AZ1 na assinatura A pode ser fisicamente igual à AZ3 na assinatura B. Sem verificação, você pode estar executando produção e DR na mesma infraestrutura física, anulando os benefícios da separação. Esse comportamento é intencional e inspirado no modelo da AWS, que também não garante consistência entre zonas lógicas em diferentes contas. Qual o objetivo desse design? A motivação por trás desse mapeamento dinâmico é: Distribuir a carga de consumo de forma mais eficiente entre os datacenters. Evitar hotspots e garantir resiliência operacional. Permitir flexibilidade de alocação conforme a capacidade física disponível. Esse modelo ajuda a balancear o uso da infraestrutura global, sem expor diretamente a topologia física aos clientes — o que também reforça a segurança e abstração da plataforma. Essa distinção é essencial: a zona lógica AZ1 em uma assinatura pode, na prática, ser a mesma zona física que a AZ3 em outra. Sem uma verificação adequada, o cliente pode acabar executando cargas de produção e de DR (Disaster Recovery) na mesma infraestrutura física, o que anula os benefícios esperados da separação entre zonas. Exemplo prático de risco Vamos considerar o seguinte cenário de um cliente: Produção: AZ1 e AZ2 em uma assinatura A DR: AZ3 em outra assinatura B, na mesma região O cliente acredita estar distribuindo suas cargas entre três zonas distintas. No entanto, ao verificar o mapeamento real, encontra a seguinte saída: [ { "logicalZone": "1", "physicalZone": "brazilsouth-az3" }, { "logicalZone": "2", "physicalZone": "brazilsouth-az1" }, { "logicalZone": "3", "physicalZone": "brazilsouth-az2" } ] Neste exemplo, a AZ3 lógica está mapeada para a AZ2 física, que já está sendo usada na produção. Ou seja, não há separação física real. Como verificar o mapeamento de zonas? Para evitar esse problema, é essencial verificar o mapeamento entre zonas lógicas e físicas em cada assinatura. Use o seguinte comando via Azure CLI: az rest --method get \ --uri "/subscriptions/<subscription-id>/locations?api-version=2022-12-01" \ --query "value[?name=='<region-name>'].{displayName: displayName,name: name,availabilityZoneMappings: availabilityZoneMappings }" \ -o json Substitua <subscription-id> e <region-name> (ex: brazilsouth) conforme necessário. Veja abaixo um exemplo de saída obtida no meu ambiente de laboratório, onde tenho duas assinaturas. Vou executar o mapeamento de zonas entre elas para a região Brazil South. Na primeira subscription 1 temos o seguinte mapeamento. Zona lógica: 1 – Zona Física: brazilsouth-az1 Zona lógica: 2 – Zona Física: brazilsouth-az2 Zona lógica: 3 – Zona Física: brazilsouth-az3 Na segunda subscription 2 temos o seguinte mapeamento. Zona lógica: 1 – Zona Física: brazilsouth-az3 Zona lógica: 2 – Zona Física: brazilsouth-az1 Zona lógica: 3 – Zona Física: brazilsouth-az2 Resumindo: Se minha estratégia de DR envolve o uso das zonas lógicas 1 e 2 na subscription 1, pois elas estão mapeadas fisicamente para as zonas AZ1 e AZ2, então, na subscription 2 destinada ao DR, devo utilizar a zona lógica 1 — já que, nessa assinatura, ela está mapeada fisicamente para a AZ3. Boas práticas Sempre verifique o mapeamento entre zonas lógicas e físicas antes de definir sua estratégia de DR. Evite assumir que AZ1, AZ2 e AZ3 representam zonas físicas distintas entre diferentes assinaturas. Considere utilizar regiões diferentes para DR quando a separação física for um requisito crítico. Documente e compartilhe o mapeamento com sua equipe de arquitetura e operações para garantir alinhamento e evitar riscos. Referência oficial Para mais detalhes, consulte a documentação oficial da Microsoft: https://learn.microsoft.com/en-us/azure/availability-zones/az-overview Comparing AWS and Azure regions and zones - Azure Architecture Center | Microsoft LearnPasso a Passo para Criar um Filtro de Tag no FinOps Hub
Recentemente, publiquei um blog sobre implementação e gerenciamento de custos do Azure usando FinOps Hub no formato FOCUS. Confira aqui. Agora, vou explicar como criar um filtro de Tag no FinOps Hub para otimizar a gestão de custos. 1. Acesse o Dashboard CostSummary do FinOps Hub Primeiro, abra o seu dashboard CostSummary do FinOps Hub. Esta versão que estamos trabalhando seria a V0.4. Em seguida, clique na aba de Resources. Você vai notar na tabela que existe uma coluna de Tag, porém ela não está formatada e não possui um filtro. O objetivo é corrigir a coluna e adicionar um filtro de tag para centro de custo. As Tags são referentes ao meu ambiente. De acordo com a figura abaixo, selecione a opção para transformar dados e adicionaremos o filtro de tag. 2. Navegue até a Seção de Filtragem No painel principal, localize e clique em CostDetails. Em seguida, encontre a coluna x_TagsDictionary, clique no item ao lado do nome e selecione a Tag centro_de_custo. No meu exemplo, também adicionei a Tag Environment. Antes de clicar em OK, desmarque a opção "Use original column name as prefix." E em seguida clique em OK 3. Selecione "Criar Novo Filtro" Ao clicar em OK, serão adicionadas mais duas colunas, centro_de_custo e Environment, conforme ilustrado no exemplo abaixo. Em seguida clique em Close & Apply 4. Criação do Fitro de Tag Na View de Resources, copie e cole o filtro de subscription com Ctrl+C e Ctrl+V e arraste-o para perto da view de Total Savings. 5. Alterar o Filtro Subscription para Filtro de Tag Selecione o filtro Subscription e, em Data, localize a tag centro_de_custo. Arraste o item centro_de_custo para field e depois exclua o Field Subscription. 6. Nova View para o Filtro Centro de Custo A visualização será parecida com o exemplo a seguir 7. Alterar a Tabela para fitrar por Tag Centro De Custo Precisamos agora modificar a tabela para aplicar o filtro ao centro de custo. Selecione a tabela e encontre no campo Data a tag centro_de_custo. Arraste o item centro_de_custo nas Colunas, como mostrado abaixo, e remova Tags da coluna. Com essas etapas concluídas, você deve ter uma nova visualização que reflete o filtro aplicado ao centro de custo. Essa configuração permitirá uma análise mais detalhada e específica, facilitando a identificação de gastos associados a cada centro de custo. Finalmente, salve as alterações feitas e atualize o dashboard para garantir que todas as modificações foram aplicadas corretamente. Agora, ao utilizar o filtro de centro de custo, você poderá visualizar apenas os dados relevantes conforme sua necessidade, tornando a análise financeira mais eficiente e direcionada.Como Implementar e Gerenciar Seus Custos do Azure com FinOps Hub no Formato FOCUS 🚀
Neste artigo ensino o passo a passo como você pode implementar e gerenciar eficientemente os custos do Azure utilizando o FinOps Hub. Além disso, mostro como aplicar o formato FOCUS, que é um padrão unificado para todas as clouds!Inspeção do tráfego destinado aos Private Endpoints para o Azure Firewall ou NVA
Este artigo possui a finalidade de demonstrar como podemos inspecionar o tráfego com destino aos recursos de Private Endpoint para o Azure Firewall ou NVA. O que é private Endpoint? Um private Endpoint fornece um endereço IP privado para uma lista de serviços de plataforma na Azure permitindo a comunicação privada com estes recursos.Monitorando Recursos Criados na Azure com Kusto Query Language (KQL) e Log Analytics
O monitoramento de atividades em nuvem é essencial para garantir a segurança, o desempenho e a conformidade das implantações na Microsoft Azure. A tabela AzureActivity, disponível no serviço Log Analytics, fornece informações detalhadas sobre todas as atividades realizadas em uma assinatura do Azure, incluindo criação de recursos, atualizações e exclusões. Usando a Linguagem de Consulta Kusto (KQL), podemos filtrar e analisar esses registros para obter insights valiosos sobre os recursos recém-criados.Provisionando um Azure Kubernetes Services (AKS) com AGIC + SSL
Um dos principais desafios ao implantar aplicativos em contêineres é fornecer uma maneira confiável e segura para que os usuários externos acessem esses aplicativos. É aqui que o Azure Application Gateway Ingress Controller (AGIC) desempenha um papel fundamental. O AGIC atua como um controlador de ingresso, direcionando o tráfego externo para os serviços corretos dentro do cluster AKS, tornando mais fácil e seguro o acesso a aplicativos em contêineres.Engenharia de Confiabilidade no Microsoft Azure (Realiability)
O pilar de confiabilidade do Well-Architected Framework concentra-se na capacidade do sistema de se recuperar automaticamente de falhas e gerenciar mudanças de forma segura e eficiente. Isso envolve a implementação de práticas e padrões para garantir que os sistemas sejam altamente disponíveis, resilientes e confiáveis.Adicionar sub-rede para um nodePool do AKS usando plugin Azure CNI
O Plugin de rede CNI usado nos ambientes produtivos requer um bom planejamento para os clusters do Azure Kubernetes Services (AKS) para que evitar a exaustão de endereço IP fornecido pela sub-rede do cluster devido ao crescimento do ambiente tendo a necessidade de recriar o cluster para atender essa demanda. Este artigo irá guiar sobre este cenário no qual encontramos em muitos ambientes produtivos com a possibilidade de adicionar um novo bloco de endereçamento IP da rede virtual do AKS e dedicá-la para um conjunto de node pool.
