Design Azure AI Landing Zones for production at scale
If you’re moving beyond AI experiments, you need more than great models; you need a foundation you can trust. Azure AI Landing Zones enable secure, scalable AI deployment with proven architectures and governance. Learn how to use Landing Zones as your production-ready blueprint for deploying AI applications and agents with built-in guardrails for networking, identity, security, and cost control. Get insights to help you apply the Cloud Adoption Framework and the Azure Well-Architected Framework to design platforms that support innovation without sacrificing compliance. Walk away knowing how to accelerate time-to-production using validated architectures, infrastructure as code (IaC), and seamless integration with your enterprise environment. How do I participate? Select Add to Calendar to save the date, then click the Attend button to save your spot, receive event reminders, and participate in the Q&A. Not able to attend live? This session will be recorded and available on demand shortly after airing. Don't see Attend or Add to Calendar? Sign in to the Tech Community to join the conversation. This session is part of Path to production for agents: a Microsoft Azure AI Tech Accelerator. View the full agenda for more actionable strategies to help you deliver secure, compliant, and high-performing AI solutions across your organization.The Microsoft Azure Infra Summit 2026 Schedule Is Live.
Hello Folks, I promised the full agenda would drop soon. Today’s the day. The schedule is locked in, the approved sessions are on the board, and I want to walk you through what three days of deep-technical, engineering-led Azure content looks like. A quick refresher before we get into the content: this event is free, it’s virtual, and it’s built by engineering for engineering. Most sessions are at the L300–L400 level, which means we’re skipping the marketing slide and getting straight to the architecture, the gotchas, and the “here’s what actually happens in production” stories you came for. We’re starting at 8:00 AM Pacific each day and running solid technical content through the afternoon. You can still register here (https://aka.ms/MAIS-reg) We organized the three days around the pillars our community keeps coming back to, Build, Operate, and Optimize. Day 1 leans into Build so you leave the keynote with momentum, Day 2 bridges Build into Operate (where most of us actually spend our workdays), and Day 3 is pure Optimize, resiliency, cost, performance, and networking, before we close things out. The full 3-day agenda (all times Pacific) Online Schedule Here Day 1, Tue, May 19 · BUILD Day 2, Wed, May 20 · BUILD + OPERATE Day 3, Thu, May 21 · OPTIMIZE + Closing 8:00 KEYNOTE: Welcome & Azure Infrastructure Vision 8:00, Build and Optimize a Data Lakehouse for Unified Data Intelligence 8:00, Achieving Zonal Resiliency in Azure Infrastructure 9:00, Build a Sovereign Private Cloud with Azure Local 8:45, Designing Azure Networks That Scale: From Small Deployments to Enterprise-Grade 8:30, Architecting Resilient Azure Platforms: Durable Functions, Cosmos DB, and DR by Design 9:45, The Azure Deployment Agent: How AI Turns a Prompt into a Production-Ready Workload 9:30, From Alert to Resolved: Building a Self-Healing Azure Platform with SRE Agent 9:00, Optimizing EDA & HPC Pipelines on Azure: High-Performance Shared Storage with Azure NetApp Files 10:15, ALZ IaC Accelerator: Deploy Your Azure Platform Landing Zone with IaC 10:15, Agentic Migrations & Modernization 9:30, Elastic SAN for AVS Datastores: Best Price-Performance External Storage 11:00, Building Secure, Well-Architected Azure Workloads by Default with Azure Verified Modules and GitHub Copilot 10:45, Simplifying File Share Management and Control for Azure Files 10:00, Premium SSD v2 Disk: Best Price-Performance Block Storage for VMs and Containers 11:45, Best Practices for Infrastructure as Code CI/CD on Azure 11:30, Marketplace Image Protection: Safeguarding Workloads Through Patching and Graceful Deprecation 10:45, Optimizing File Storage for AI and Cloud-Native Workloads on Azure 12:30, Modern Ingress for AKS: Introducing Application Gateway for Containers (AGC) 12:00, Operating Hybrid at Scale: Real-World Azure Arc Patterns for Governance, Security, and Cost Control 11:30, Cut Storage Costs, Boost ROI: Optimizing Your Storage TCO on Azure Object Storage 13:15, End-to-End Security on AKS Using Azure Application Gateway for Containers with Managed Cilium 12:45, Run At-Scale On-Premises and Cloud Assessments and Migrations to Azure Storage 12:15, How to Build Resilient Networks Using Azure Networking, What’s New in Azure Software Load Balancing 14:00, Deployment Stacks: Getting Started 13:30, Modernize VDI with Azure Files and Entra Cloud-Native Identities 13:00, AKS Networking at Scale, CNI, Security, and Multi-Cluster Networking with Accelerated Performance 14:30, Accelerating Automated VM Image Pipelines with Azure Image Builder and Azure Compute Gallery 14:15, Operating Azure Backup at Scale: Day-2 Excellence for IaaS, PaaS, and Storage Workloads 13:45, Kubenet Deprecation, Futureproofing AKS IPAM and Dataplane Configurations 15:00, Troubleshooting Kubernetes Networking with an AI Diagnostic Assistant 14:15, Implement Zero-Tolerance Downtime Web Apps with Azure Front Door 14:45, Closing: Azure Infrastructure Applied Skills and Certifications What to do right now Block your calendar, May 19, 20, and 21, 8:00 AM PT start each day. Check out www.azureinfrasummit.com for more information. Register, it’s free. Pick your sessions, the online schedule has ICS files for each session. Build your personal track across Build, Operate, and Optimize. Bring your team, the agenda is deliberately wide: platform engineers, SREs, storage folks, network folks, AKS operators, IaC builders, and backup/DR owners will all find their sessions. We put a lot of work into making sure every slot earned its place, these are engineering-delivered, production-grounded, no-fluff sessions. The speakers are the people shipping the features you’re using in Azure. Can’t wait to see you online May 19–21. Until then, Cheers! Pierre RomanSegurança Corporativa no Azure VMware Solution (AVS): Como Inspecionar o Tráfego com Firewall NVA
Muitas vezes faz sentido usar uma NVA (Network Virtual Appliance) como firewall dentro do AVS, porque permite reaproveitar a solução de firewall já existente (Palo Alto, Check Point, etc..) e manter a proficiência do time de segurança, evita parte da complexidade de roteamento que pode surgir ao forçar o tráfego passar por um firewall “fora” do AVS . Além disso, administrar esse firewall dentro do AVS continua familiar para quem já opera VMware, e você ganha acesso a recursos avançados de inspeção do fabricante (como filtragem por aplicação em camada 7 e inspeção SSL/TLS), que são muito úteis para controle de tráfego outbound e políticas corporativas. Neste artigo eu demonstro e um laboratório prático de inspeção de tráfego Norte-Sul e Leste-Oeste, fazendo isolamento por ambiente (DEV/PRD) dentro do Azure VMware Solution (AVS) usando NSX-T (Tier-0/Tier-1) e um Firewall NVA (pfSense) implantado no SDDC. Também serão demonstradas as principais configurações no NSX (criação/associação de segments, gateways T0/T1 e ajustes de roteamento necessários para forçar o tráfego a passar pela NVA). Arquitetura Informações do Laboratório Segmentos de Trânsito Transit_Outside | CIDR: 192.168.30.0/24 | GW: 192.168.30.1 Transit_PRD | CIDR: 192.168.21.0/24 | GW: 192.168.21.1 Transit_DEV | CIDR: 192.168.22.0/24 | GW: 192.168.22.1 Segmentos de Workloads PRD_WEB | CIDR: 192.168.70.0/24 | GW: 192.168.70.1 PRD_DATA | CIDR: 192.168.71.0/24 | GW: 192.168.71.1 DEV_WEB | CIDR: 192.168.80.0/24 | GW: 192.168.80.1 DEV_DATA | CIDR: 192.168.81.0/24 | GW: 192.168.81.1 Interfaces da NVA (pfSense) Transit_Outside: 192.168.30.5 Transit_PRD: 192.168.21.5 Transit_DEV: 192.168.22.5 Configuração do Azure VMware Solution Na configuração Internet connectivity (egress/ingress) do Azure VMware Solution (AVS) irei utilizar a opção "Connect using Public IP down to the NSX Edge". Isso permite usar o NSX Data Center para criar regras de outbound e inbound (DNAT/SNAT) usando esses IPs públicos diretamente no Edge do AVS. Configuração de SNAT e NoSnat no NSX Regras “No SNAT” : Define que não deve haver tradução de origem quando o tráfego vai para redes privadas RFC1918. Isso preserva o IP original de origem para comunicação interna (ex.: on-prem, Azure, spoke VNets/rotas privadas), evita quebra de roteamento/retorno. Regra “SNAT”: Aplica tradução de origem para o restante do tráfego (Internet). Ou seja, quando uma VM com IP privado sai para fora, o NSX troca o IP de origem pelo IP público configurado ( 20.20.138.0/32). Criação dos Gateways TIER-1 (PRD e DEV). Importante: Estes gateway são "Isolados", portando não serão conectados ao TIER-0 T1_PRD_Isolado T1_DEV_Isolado Resultado Criação dos Segmentos de Trânsito PRD e DEV Importante: Estes Segmentos estarão conectados ao Tier-1 Gateway PRD (T1_PRD_Isolado) e DEV ( T1_DEV_Isolado) respectivamente criados na etapa anterior TRANSIT_PRD TRANSIT_DEV Criação do Segmento PRD WEB e DATA Importante: Estes Segmentos estarão conectados ao Tier-1 Gateway PRD (T1_PRD_isolado) e DEV ( T1_DEV_Isolado) respectivamente criados na etapa anterior PRD_WEB PRD_DATA DEV_WEB DEV_DATA Visão Geral dos Segmentos Configuração de Rotas Rotas no Gateway T1 Default No Gateway T1 Default que está conectado ao T0 , irei configurar rotas para todos os segmentos com Next Hop ao ip da interface Outside do meu PFsense (192.168.30.5) . obs: o nome do gateway T1 é diferente em cada AVS SDDC, no meu ambiente é "TNT13-T1" Informei o CIDR da Rede , neste caso é para o segmento TRANSIT_PRD Next Hop aqui é o ip da interface Outside do PFsense ( 192.168.30.5) , que está conectada diretamente a este GW T1. Repeti os mesmos passos para todos os outros Segmentos, sempre com next hop para 192.168.30.5. Interfaces Firewall Pfsense Neste cenário o Firewall possui apenas três interfaces. Deve ser configurada a rota default ( 0.0.0.0/0) para o gateway do Segmento Transit Outside ( 192.168.30.1) Interfaces do Pfsense Rotas no Gateways de Transito : T1_PRD_isolado Estarei criado uma rota default ( 0.0.0.0/0 ) , com next hop para a interface do Inside do PFsense (192.168.21.5 ) conectada ao Gateway T1 PRD. Devido a limitações do NSX, é necessário "quebrar" em duas: 0.0.0.0/1 e 128.0.0.1/1 Configuração da Rodas default Next Hop para ip da Interface Inside PFsense. Rotas no Gateways de Transito : T1_DEV_Isolado Estarei criado uma rota default ( 0.0.0.0/0 ) , com next hop para a interface do Inside do PFsense (192.168.22.5 ) conectada ao Gateway T1 PRD. Devido a limitações do NSX, é necessário "quebrar" em duas: 0.0.0.0/1 e 128.0.0.1/1 Configuração da Rodas default Next Hop para ip da Interface Inside PFsense. Teste de Acesso Tráfego Norte-Sul ( Saída Internet) Para comprovar que conseguimos agora ter o tráfego Norte-Sul, pelo NVA PFense , irei fazer um teste a partir da máquina no segmento PRD_WEB , com ip 192.168.70.1 É possivel observar que o ip públlico de saída é do AVS Agora vou criar uma regra no Pfsense bloqueando a porta 443 , mas deixando liberada as outras portas. Podemos comprovar que o tráfego está sendo inspersionado fazendo um teste de conexão na porta 53 e outro teste https. No Pfsense podemos ver o bloqueio Tráfego Leste-Oeste Para testar o tráfego leste oeste entre os Segmentos PRD_WEB ( VM 192.168.70.10 ) e DEV_WEB ( VM 192.168.80.10) , irei deixar ICMP liberado e bloquear a porta 3389 ( RDP) Fazendo o teste a partir da máquina 192.168.70.10 Verificando no PFsense o bloqueio da porta 3389 Resumo Neste laboratório demonstrei como integrar uma NVA ao Azure VMware Solution usando NSX-T com Tier-0/Tier-1, criando T1s isolados para DEV e PRD, segments de trânsito e a configuração de SNAT/NoSNAT no NSX para controlar o egress. Também mostrei o ajuste de rotas para garantir que o tráfego siga pelo caminho de inspeção no firewall. Validei a arquitetura com testes práticos de tráfego Norte-Sul (saída para Internet com IP público do AVS) e Leste-Oeste (controle entre DEV e PRD), comprovando a inspeção via logs e bloqueios aplicados no pfSense. Como próximos passos para produção, recomenda-se padronizar regras, logging, e revisar resiliência/HA do firewall e rotas para reduzir pontos únicos de falha. Referências Firewall integration in Azure VMware Solution | Microsoft Community Hub AVS How-to: 3rd Party Firewalls in Azure VMware SolutionProtegendo 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 LearnTech Accelerator: Mastering Azure and AI adoption
Join us to learn about the essential guidance, resources, products and tooling you need to accelerate your next Azure and AI project or enhance your existing Azure deployments. Get in-depth technical guidance from Microsoft experts to enhance the reliability, security and ongoing performance of your Azure workloads. Learn more about AMD products and solutions to accelerate cloud adoption. Now on demand! Best practices for secure and reliable Azure projects Govern, manage and secure your AI deployments How to run a successful Azure migration project Advance cloud infrastructure: Essentials with AMD on Azure Essentials to build and modernize AI applications on Azure Proactively design, deploy & monitor resilient Azure workloads Cloud platform security in an evolving threat landscapeAdvance cloud infrastructure: Essentials with AMD on Azure
When it comes to Azure, finding the right infrastructure for your workloads is essential. From performance, to flexibility, to security, to availability, and to cost, your cloud adoption choices have a major impact. Join this session to learn about the many AMD options available to you on Azure and, ultimately, how the newest general purpose AMD infrastructure can help you successfully adopt Azure. This session is part of Tech Accelerator: Mastering Azure and AI adoption. View the full agenda for more great sessions and insights.Conectando o Azure Vmware Solution (AVS) com VPN Site to Site em topologia Hub Spoke.
A conexão de VPN entre AVS e o ambiente On-premises na maioria das vezes é realizada através do Virtual WAN, conforme descrito em: https://learn.microsoft.com/en-us/azure/azure-vmware/configure-site-to-site-vpn-gateway. Contudo, caso necessário utilizar em uma topologia Hub-Spoke, existem componentes adicionais que devem ser considerados para permitir o trânsito entre o ExpressRoute do AVS e o VPN Gateway, bem como a propagação das rotas para o ambiente On-premises, assim como é feito por padrão com o Virtual WAN. Nesta topologia, o Azure Route Server deve ser integrado para habilitar esse trânsito (propagação de rotas) O objetivo deste artigo é demonstrar em um ambiente de laboratório como conectar um ambiente On-premises com o Azure VMware Solution (AVS) através de uma VPN Site-to-Site em topologia Hub-Spoke. Arquitetura do Laboratório com topologia Hub-Spoke. Componentes Azure. Vnet 10.90.0.0/16 com 3 Subnets. Gateway Subnet - 10.90.0.0/24 RouteServerSubnet - 10.90.1.0/24 VmSubnet : 10.90.2.0/24 Virtual Network Gateway - VPN Virtual Network Gateway - Express Route Azure Route Server Azure Vm Linux Ubuntu Componentes On-premises Firewall VPN PfSense - 192.168.90.0/24 , 192.168.200.0/22 , 192.168.92.0/24 Componetes Azure Vmware Solution VMware SDDC Circuito Express Route *Este laboratório presume que os componentes como o Azure Vmware Solution e ambiente On-premises com Pfsense ou qualquer outro equipamento esteja presente. 1. Deploy componentes Azure # 1. Variáveis - Altere conforme necessário RESOURCE_GROUP="rg-avs-lab" LOCATION="eastus2" VNET_NAME="vnet-avs-lab" VNET_ADDRESS_PREFIX="10.90.0.0/16" SUBNET_GATEWAY_PREFIX="10.90.0.0/24" SUBNET_ROUTE_SERVER_PREFIX="10.90.1.0/24" SUBNET_GATEWAY_NAME="GatewaySubnet" SUBNET_ROUTE_SERVER_NAME="RouteServerSubnet" EXPRESSROUTE_GW_NAME="er-avs-lab" VPN_GW_NAME="vpn-avs-lab" VPN_GW_IP1_NAME="vpn-gw-ip1" VPN_GW_IP2_NAME="vpn-gw-ip2" VPN_GW_ASN=65515 EXPRESSROUTE_IP_NAME="er-ip" LOCAL_NETWORK_GATEWAY_NAME="local-gw-avs-lab" BGP_PEER_IP="192.168.90.1" ASN_LOCAL=65503 ROUTE_SERVER_NAME="rserver-avs-lab" # Variáveis para subnet e VM SUBNET_VM_NAME="subnet-vm" SUBNET_VM_PREFIX="10.90.5.0/24" VM_NAME="vm-ubuntu" VM_ADMIN_USERNAME='azureuser' VM_ADMIN_PASSWORD='P@ssword123!' # Use um método seguro em produção VM_NIC_NAME="vm-ubuntu-nic" VM_IMAGE="Canonical:0001-com-ubuntu-server-focal:20_04-lts:latest" VM_SIZE="Standard_B2ms" # 2. Criar grupo de recursos az group create --name $RESOURCE_GROUP --location $LOCATION # 3. Criar VNet e subnets az network vnet create \ --resource-group $RESOURCE_GROUP \ --location $LOCATION \ --name $VNET_NAME \ --address-prefixes $VNET_ADDRESS_PREFIX \ --subnet-name $SUBNET_GATEWAY_NAME \ --subnet-prefix $SUBNET_GATEWAY_PREFIX az network vnet subnet create \ --resource-group $RESOURCE_GROUP \ --vnet-name $VNET_NAME \ --name $SUBNET_ROUTE_SERVER_NAME \ --address-prefix $SUBNET_ROUTE_SERVER_PREFIX # Criar subnet para a VM az network vnet subnet create \ --resource-group $RESOURCE_GROUP \ --vnet-name $VNET_NAME \ --name $SUBNET_VM_NAME \ --address-prefix $SUBNET_VM_PREFIX # 4. Criar IP público para ExpressRoute az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $EXPRESSROUTE_IP_NAME \ --sku Standard \ --allocation-method Static # 5. Criar Gateway ExpressRoute az network vnet-gateway create \ --resource-group $RESOURCE_GROUP \ --name $EXPRESSROUTE_GW_NAME \ --location $LOCATION \ --vnet $VNET_NAME \ --public-ip-addresses $EXPRESSROUTE_IP_NAME \ --gateway-type ExpressRoute \ --sku Standard # 6. Criar IPs públicos para VPN Gateway ativo-ativo az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_IP1_NAME \ --sku Standard \ --allocation-method Static az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_IP2_NAME \ --sku Standard \ --allocation-method Static # 7. Criar VPN Gateway az network vnet-gateway create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_NAME \ --location $LOCATION \ --vnet $VNET_NAME \ --public-ip-addresses $VPN_GW_IP1_NAME $VPN_GW_IP2_NAME \ --gateway-type Vpn \ --vpn-type RouteBased \ --sku VpnGw1 # Após a criação, configurar ativo-ativo e BGP az network vnet-gateway update \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_NAME \ --set activeActive=true enableBgp=true bgpSettings.asn=$VPN_GW_ASN # 8. Criar Local Network Gateway com BGP e ASN az network local-gateway create \ --resource-group $RESOURCE_GROUP \ --name $LOCAL_NETWORK_GATEWAY_NAME \ --gateway-ip-address $BGP_PEER_IP \ --local-address-prefixes "192.168.90.0/24" \ --asn $ASN_LOCAL \ --bgp-peering-address $BGP_PEER_IP \ --location $LOCATION # 9. Criar conexão VPN entre o Gateway de VPN e o Local Network Gateway az network vpn-connection create \ --resource-group $RESOURCE_GROUP \ --name vpn-s2s-connection \ --vnet-gateway1 $VPN_GW_NAME \ --local-gateway2 $LOCAL_NETWORK_GATEWAY_NAME \ --shared-key 'teste@123' \ --enable-bgp # 10. Criar NIC para a VM az network nic create \ --resource-group $RESOURCE_GROUP \ --name $VM_NIC_NAME \ --vnet-name $VNET_NAME \ --subnet $SUBNET_VM_NAME # 12. Criar VM com Ubuntu az vm create \ --resource-group $RESOURCE_GROUP \ --name $VM_NAME \ --nics $VM_NIC_NAME \ --image $VM_IMAGE \ --admin-username $VM_ADMIN_USERNAME \ --admin-password $VM_ADMIN_PASSWORD \ --size $VM_SIZE \ --location $LOCATION 2. Conectando o Express Route do AVS no VPN Gateway da Hub. No Virtual Network Gateway de ER , adicione uma conexão Defina o connection type como ExpressRoute No AVS, copie o authorization key e o ExpressRoute ID Para este cenário será utilizado o modelo de resiliência standard, o Virtual network gateway, informe um nome para conexão, insira a "authorization key" e "ExpressRoute ID" (per cirtuit URI) copiados nos passos acima e execute o deploy. Verificando que a conexão foi estabelecida com sucesso. Verificando as rotas na Vm de teste. Ao verificar as rotas do Pfsense ( onprem) , é possível observar que não temos as rotas do AVS, somente da Vnet do Azure. Para habilitar o trânsito e troca de rotas entre o Express Route do AVS e o VPN gateway precisamos inserir o Azure Route Server. 3. Deploy do Azure Route Server. #Criar Azure Route Server #Cria Public IP para o Route Server az network public-ip create --resource-group $RESOURCE_GROUP --name routeserver-pip --sku Standard --allocation-method Static # Identifica o ID da Subnet do Route Server SUBNET_ID=$(az network vnet subnet list --resource-group $RESOURCE_GROUP --vnet-name $VNET_NAME --query "[?name=='$SUBNET_ROUTE_SERVER_NAME'].id" --output tsv) # Cria o Route Server az network routeserver create \ --resource-group $RESOURCE_GROUP \ --name $ROUTE_SERVER_NAME \ --hosted-subnet $SUBNET_ID \ --location $LOCATION \ --public-ip-address routeserver-pip Após criado habilitamos a opção Branch-to-Branch Podemos verificar que agora as rotas do AVS (172.30.0.0/22), agora foram propagadas para o Pfsense. Validando acesso ao Vcenter do AVS. Referências: https://learn.microsoft.com/en-us/azure/route-server/overview https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spokeAcessar o Azure ARC com Private Endpoint e Azure Firewall Explicit Proxy - Parte 1
Benefícios de Usar o Azure ARC O Azure ARC permite gerenciar recursos de TI, independentemente de onde eles estejam hospedados, seja no Azure, em outras nuvens ou em infraestruturas locais (on-premises). Fonte: Azure Arc overview - Azure Arc | Microsoft Learn Entre os principais benefícios de usar o Azure ARC podemos citar os seguintes. Gestão Centralizada: Permite o gerenciamento de recursos multi-cloud e on-premises Consistência de Ferramentas: Com o Azure ARC, é possível usar as mesmas ferramentas e processos que você já utiliza no Azure para gerenciar recursos em qualquer infraestrutura, proporcionando uma experiência consistente. Segurança e Conformidade: A tecnologia permite aplicar políticas de segurança e conformidade de maneira uniforme em todos os ambientes, garantindo que os padrões corporativos sejam mantidos em qualquer lugar. Escalabilidade: O Azure ARC facilita a escala de operações de TI de acordo com as necessidades do negócio, sem as limitações típicas das infraestruturas locais. Automatização: A automatização de processos de gerenciamento através de scripts e ferramentas Azure Resource Manager (ARM) pode ser estendida a recursos fora do Azure, melhorando a eficiência operacional. Monitoramento e Insights: O Azure ARC integra-se com ferramentas de monitoramento do Azure, permitindo visibilidade centralizada e insights detalhados sobre o desempenho e a integridade de todos os recursos. Ao utilizar o Azure ARC, as organizações podem maximizar os investimentos existentes em infraestrutura, melhorar a governança e aprimorar a flexibilidade e a agilidade operacionais, tudo isso enquanto mantêm uma gestão centralizada e consistente. Benefício de usar Private Endpoints Utilizando o Azure ARC com private endpoints, o tráfego de rede entre os recursos gerenciados e o Azure permanece dentro da rede privada, aumentando a segurança, proteção dos dados e o desempenho. Essa configuração reduz a exposição a ameaças externas e cumpre exigências regulatórias ao assegurar que os dados sensíveis não transitem pela internet pública. Desafios no Acesso ao Azure Arc com Azure Firewall, Explicit Proxy e Private Endpoint Conectar um recurso local ao Azure por meio do Azure Arc e utilizar extensões habilitadas para Arc requer comunicação com um conjunto de serviços do Azure, cada um com seus próprios endpoints de destino. Para clientes que utilizam proxies corporativos, é necessário permitir o acesso a todos esses endpoints. Atualmente, o gateway do Arc reduz o número de url's que precisam ser permitidos por meio de um proxy corporativo, mas exige que o tráfego seja roteado para o Azure pela Internet pública. No entanto, alguns clientes precisam que todo o tráfego alcance o Azure por meio do seu circuito de ExpressRoute ou através da VPN Site a Site. Embora parte dos endpoints necessários podem ser roteados pelo Microsoft Peering ou Private Peering do ExpressRoute, nem todos os endpoints são compatíveis com essas opções. Firewall do Azure como um proxy sobre ER ou VPN site a site Os clientes que precisam que todo o tráfego alcance o Azure por meio do ExpressRoute ou VPN Site-to-Site pode hospedar um proxy de encaminhamento em sua rede virtual do Azure. O agente Arc pode então se comunicar com esse proxy de encaminhamento por meio de um IP privado, seja por meio do ExpressRoute ou VPN Site-to-Site. O Firewall do Azure com o recurso Proxy Explícito (Visualização Pública) pode ser aproveitado como esse proxy de encaminhamento. Disclaimer: O Azure Firewall com Explicit Proxy é um recurso atualmente em preview. Isso significa que ele está sujeito a alterações e pode não estar disponível em todas as regiões ou com todas as funcionalidades de produção. Para mais informações, consulte os termos de uso para preview. O diagrama abaixo representa essa arquitetura Etapas para o uso do Azure Firewall com explicit proxy Passo 1: Precisamos habilitar o uso do Azure Firewall com a feature de Explicit Proxy conforme a documentação de referência aqui Passo 2: Em seguida realizado o onboard dos servidores para o Azure ARC. Observe que o IP privado do Firewall do Azure como o proxy de encaminhamento nas configurações. No Portal do Azure Usando a CLI de comando Servidores ARC azcmagent config set proxy.url <Azure Firewall Private IP:Port> azcmagent config CLI reference - Azure Arc | Microsoft Learn Passo 3: Crie uma regra de aplicativo para permitir os endpoints necessários do Azure ARC para seu cenário de acesso através do Firewall No próximo artigo, vamos montar um laboratório passo a passo, detalhando as configurações e os requisitos necessários para utilizar o private endpoint e o explicit proxy do Azure Firewall, conforme ilustrado no diagrama abaixo Referências: Azure Arc overview - Azure Arc overview - Azure Arc | Microsoft Learn Informações gerais e preço - Azure Arc – Hybrid and Multi-Cloud Management and Solution (microsoft.com) Azure Firewall Explicit Proxy - Azure Firewall Explicit proxy (preview) | Microsoft Learn
Azure SDK for Go Fundamentals | Azure SDK Community Standup
Welcome to the Azure SDK Team channel, where we explore the latest updates and features of Azure development tools and services. In this episode, we will learn about the benefits, key features, and functionality of Azure SDK for Go. Join us as we demonstrate how to effectively use the Azure client libraries for Go, empowering you to harness the full potential of Azure services in your projects. Don't forget to like, share, and subscribe to stay updated with the latest Azure development updates and features. https://aka.ms/azsdk/releases https://aka.ms/azsdk/blog https://aka.ms/azsdk/github https://twitter.com/AzureSDK Community Links: https://www.theurlist.com/azuresdk Featuring: Hector Norzagaray @HectorOnAzure, Richard Park @ParkPlusPlus, Sandeep Sen Sandeep_K_Sen #AzureSDK #AzureDev #Microsoft
