Azure
Diagramas de infraestrutura Azure utilizando os pacotes de ícones HashiCorp Flight e Carbon para redes VNet, computação e serviços gerenciados.
VNet com App Gateway
Seção intitulada “VNet com App Gateway”VNet Azure com sub-redes de gateway, aplicação e dados. O Application Gateway distribui o tráfego para VM Scale Sets.
architecture-beta group vnet(carbon:virtual-private-cloud)[Azure VNet] group gwsub(carbon:ibm-cloud-subnets)[Gateway Subnet] in vnet group appsub(carbon:ibm-cloud-subnets)[App Subnet] in vnet group datasub(carbon:ibm-cloud-subnets)[Data Subnet] in vnet service appgw(carbon:gateway-security)[App Gateway] in gwsub service vm1(hashicorp-flight:azure-vms-color)[VM Scale Set] in appsub service vm2(hashicorp-flight:azure-vms-color)[VM Scale Set] in appsub service sqldb(carbon:data-base)[Azure SQL] in datasub appgw:R --> L:vm1 appgw:B --> T:vm2 vm1:R --> L:sqldb vm2:R --> L:sqldb
AKS com F5 XC Multi-Cloud Connect
Seção intitulada “AKS com F5 XC Multi-Cloud Connect”Azure Kubernetes Service gerenciado pelo F5 Distributed Cloud para conectividade e segurança de aplicações em múltiplas nuvens.
architecture-beta group xc(lucide:cloud)[F5 XC] group aks(hashicorp-flight:azure-aks-color)[AKS Cluster] service mcn(f5xc:multi-cloud-network-connect)[Network Connect] in xc service waap(f5xc:web-app-and-api-protection)[WAAP] in xc service ingress(carbon:gateway)[Ingress] in aks service app(hashicorp-flight:docker-color)[App Pods] in aks service cache(carbon:datastore)[Redis Cache] in aks service blob(hashicorp-flight:azure-blob-storage-color)[Blob Storage] mcn:R --> L:waap waap:R --> L:ingress ingress:R --> L:app app:B --> T:cache app:R --> L:blob
Topologia de Rede Hub-Spoke
Seção intitulada “Topologia de Rede Hub-Spoke”Arquitetura Hub-Spoke Azure com segurança centralizada e serviços compartilhados conectando múltiplas VNets spoke.
flowchart TD
hub@{ icon: 'carbon:virtual-private-cloud', label: 'Hub VNet' }
fw@{ icon: 'carbon:firewall', label: 'Azure Firewall' }
vpn@{ icon: 'carbon:gateway-vpn', label: 'VPN Gateway' }
spoke1@{ icon: 'carbon:ibm-cloud-subnets', label: 'Spoke 1 - Web' }
spoke2@{ icon: 'carbon:ibm-cloud-subnets', label: 'Spoke 2 - App' }
spoke3@{ icon: 'carbon:ibm-cloud-subnets', label: 'Spoke 3 - Dados' }
onprem@{ icon: 'lucide:server', label: 'DC On-Premises' }
onprem --> vpn
vpn --> hub
hub --> fw
fw --> spoke1
fw --> spoke2
fw --> spoke3Alta Disponibilidade de NVA com Load Balancer — Tráfego Internet
Seção intitulada “Alta Disponibilidade de NVA com Load Balancer — Tráfego Internet”O tráfego de entrada da internet atinge um load balancer público, que distribui para instâncias de NVA no hub. O NVA encaminha o tráfego inspecionado para as cargas de trabalho nos spokes. O tráfego de retorno dos spokes é roteado por um load balancer interno de volta ao NVA para saída. As etapas numeradas mostram o caminho de entrada (1-3) e o caminho de retorno (4-6).
flowchart TD
subgraph internet[Internet]
cloud@{ icon: 'lucide:globe', label: 'Internet' }
end
subgraph hub[Hub VNet 10.0.0.0/24]
subgraph gwsub[Gateway Subnet 10.0.0.0/27]
gw@{ icon: 'azure:virtual-network-gateways', label: 'VPN/ER GW' }
end
subgraph nvasub[NVA Subnet 10.0.0.32/27]
intlb@{ icon: 'azure:load-balancers', label: 'Internal LB 10.0.0.36' }
nva@{ icon: 'azure:firewalls', label: 'NVA' }
end
publb@{ icon: 'azure:load-balancers', label: 'Public LB' }
end
subgraph spoke1[Spoke1 10.1.1.0/24]
app1@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
end
subgraph spoke2[Spoke2 10.1.2.0/24]
app2@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
end
onprem@{ icon: 'lucide:building', label: 'On-Premises 192.168.0.0/16' }
cloud -->|1| publb
publb -->|2| nva
nva -->|3| app2
app2 -->|4| intlb
intlb -->|5| nva
nva -->|6| cloud
onprem --> gw
gw --> intlbAlta Disponibilidade de NVA com Load Balancer — Tráfego On-Premises
Seção intitulada “Alta Disponibilidade de NVA com Load Balancer — Tráfego On-Premises”O tráfego on-premises entra por um gateway VPN ou ExpressRoute e é direcionado a um load balancer interno que gerencia múltiplas instâncias de NVA. O NVA inspeciona e encaminha o tráfego para as cargas de trabalho nos spokes. O tráfego de retorno percorre o mesmo load balancer interno para garantir a simetria do fluxo, evitando problemas de roteamento assimétrico.
flowchart TD
subgraph hub[Hub VNet 10.0.0.0/24]
subgraph gwsub[Gateway Subnet 10.0.0.0/27]
gw@{ icon: 'azure:virtual-network-gateways', label: 'VPN/ER GW' }
end
subgraph nvasub[NVA Subnet 10.0.0.32/27]
intlb@{ icon: 'azure:load-balancers', label: 'Internal LB 10.0.0.36' }
nva1@{ icon: 'azure:firewalls', label: 'NVA' }
nva2@{ icon: 'azure:firewalls', label: 'NVA' }
end
end
subgraph spoke1[Spoke1 10.1.1.0/24]
app1@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
end
subgraph spoke2[Spoke2 10.1.2.0/24]
app2@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
end
onprem@{ icon: 'lucide:building', label: 'On-Premises 192.168.0.0/16' }
onprem -->|1| gw
gw -->|2| intlb
intlb -->|3| nva1
nva1 -->|4| app2
app2 -->|5| intlb
intlb -->|6| nva2
nva2 -->|7| gw
gw -->|8| onpremAlta Disponibilidade de NVA com PIP/UDR — Ativo/Standby
Seção intitulada “Alta Disponibilidade de NVA com PIP/UDR — Ativo/Standby”Par de NVA ativo/standby onde a instância ativa (NVA1) detém o endereço IP público. Em caso de falha, o NVA2 em standby aciona a API do Azure para reatribuir o IP público e atualizar as rotas definidas pelo usuário para apontarem para si mesmo. Essa abordagem dispensa load balancers, mas requer orquestração de failover no nível da API.
flowchart TD
subgraph internet[Internet]
cloud@{ icon: 'lucide:globe', label: 'Internet' }
end
subgraph hub[Hub VNet 10.0.0.0/24]
pip@{ icon: 'azure:public-ip-addresses', label: 'IP Público' }
subgraph gwsub[Gateway Subnet 10.0.0.0/27]
gw@{ icon: 'azure:virtual-network-gateways', label: 'VPN/ER GW' }
end
subgraph nvasub[NVA Subnet 10.0.0.32/27]
nva1@{ icon: 'azure:firewalls', label: 'NVA1 Ativo 10.0.0.37' }
nva2@{ icon: 'azure:firewalls', label: 'NVA2 Standby 10.0.0.38' }
end
end
subgraph spoke1[Spoke1 10.1.1.0/24]
app1@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
end
subgraph spoke2[Spoke2 10.1.2.0/24]
app2@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
end
onprem@{ icon: 'lucide:building', label: 'On-Premises 192.168.0.0/16' }
cloud -->|1| pip
pip -->|2| nva1
nva1 -->|3| app2
app2 -->|4| nva1
nva1 -->|5| cloud
onprem --> gwAlta Disponibilidade de NVA com Azure Route Server
Seção intitulada “Alta Disponibilidade de NVA com Azure Route Server”Alta disponibilidade baseada em BGP utilizando o Azure Route Server. O Route Server estabelece adjacências eBGP com ambas as instâncias de NVA e programa dinamicamente as rotas efetivas dos spokes. O ECMP distribui a carga entre os NVAs sem necessidade de rotas definidas pelo usuário. O Route Server injeta entradas de next-hop para ambos os IPs de NVA em todas as VNets emparelhadas.
flowchart TD
subgraph internet[Internet]
cloud@{ icon: 'lucide:globe', label: 'Internet' }
end
subgraph hub[Hub VNet 10.0.0.0/24]
publb@{ icon: 'azure:load-balancers', label: 'Public LB' }
subgraph gwsub[Gateway Subnet 10.0.0.0/27]
gw@{ icon: 'azure:virtual-network-gateways', label: 'VPN/ER GW' }
end
subgraph nvasub[NVA Subnet 10.0.0.32/27]
nva1@{ icon: 'azure:firewalls', label: 'NVA1 10.0.0.37' }
nva2@{ icon: 'azure:firewalls', label: 'NVA2 10.0.0.38' }
end
subgraph rssub[Route Server Subnet 10.0.0.64/27]
rs@{ icon: 'azure:virtual-router', label: 'Route Server' }
end
end
subgraph spoke1[Spoke1 10.1.1.0/24]
app1@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
end
subgraph spoke2[Spoke2 10.1.2.0/24]
app2@{ icon: 'azure:virtual-machine', label: 'Servidor de Aplicação' }
end
cloud -->|1| publb
publb -->|2| nva1
nva1 -->|3| app2
app2 -->|4| nva1
nva1 -->|5| cloud
rs <-.->|eBGP| nva1
rs <-.->|eBGP| nva2
gw --> rsAlta Disponibilidade de NVA com Gateway Load Balancer
Seção intitulada “Alta Disponibilidade de NVA com Gateway Load Balancer”Inserção transparente de NVA utilizando o Azure Gateway Load Balancer. O tráfego destinado à aplicação é transparentemente desviado do load balancer padrão público para o Gateway LB em uma VNet de NVA separada. Os NVAs inspecionam o tráfego e o devolvem ao Gateway LB, que o encaminha de volta à aplicação. Não são necessários peering de VNet nem UDRs entre as VNets de NVA e de aplicação.
flowchart TD
subgraph internet[Internet]
cloud@{ icon: 'lucide:globe', label: 'Internet' }
end
subgraph nvavnet[NVA VNet]
gwlb@{ icon: 'azure:load-balancers', label: 'Gateway LB' }
nva1@{ icon: 'azure:firewalls', label: 'NVA' }
nva2@{ icon: 'azure:firewalls', label: 'NVA' }
end
subgraph appvnet[App VNet]
publb@{ icon: 'azure:load-balancers', label: 'Public Std LB' }
web@{ icon: 'azure:virtual-machine', label: 'Servidor Web' }
end
cloud -->|1| publb
publb -->|2| gwlb
gwlb -->|3| nva1
nva1 -->|4| gwlb
gwlb -->|5| publb
publb -->|6| web
gwlb --> nva2