1) Pense em camadas: assinatura → grupo de recursos → componentes

No Azure, a arquitetura começa com a forma como você organiza o “onde” e o “como” cada coisa vive.
O objetivo não é só cumprir padrões: é reduzir custo operacional, aumentar governança e diminuir
o risco de mudanças.

2) Desenhe a rede como produto: sub-redes, rotas e fronteiras

Redes não são apenas “subnets e NSG”. Uma arquitetura Azure robusta define claramente:
fronteiras de segurança, caminhos de tráfego, padrões de segmentação e como você trata DNS e
conectividade com on-premises.

• Segmente por função: por exemplo, private endpoints, workloads de aplicação e
  serviços compartilhados (bastion/jumpbox, observabilidade, etc.).
• Defina um plano de endereçamento: reserve espaço para crescimento e evite “subnetting”
  improvisado; isso reduz retrabalho em migrations e expansão.
• Tráfego e egress: garanta que egress controlado (ex.: por NAT/Firewall) seja uma
  decisão explícita, não um efeito colateral.
• DNS e resolução: quando você usa Private Link e endpoints privados, o DNS vira parte
  da arquitetura (split-horizon, zonas privadas e configuração de resolução).

3) Identidade e acesso: o padrão que evita incidentes

A arquitetura de segurança do Azure tende a falhar quando o acesso é concedido pelo “atalho”.
O que funciona no longo prazo é usar identidade e permissões com clareza: onde aplicar, o que permitir
e como restringir.

• RBAC por escopo: prefira permissões no nível mais baixo que ainda atende ao caso de uso
  (resource group, ou recurso específico quando fizer sentido).
• Separação de funções: admin de plataforma (infra), admin de aplicativo (deploy/config),
  e operadores (observabilidade/runbook) sem misturar tudo.
• Princípios de menor privilégio: evite permissões amplas e permanentes para tarefas
  pontuais.
• Proteção de credenciais: trate segredos e chaves fora do código; centralize e opere com rotação.
• Auditoria desde o início: logs e trilhas precisam estar prontos antes do tráfego real.
  Isso diminui o tempo de investigação quando algo dá errado.

4) Observabilidade, custo e resiliência: feche o ciclo de operação

Uma arquitetura madura não termina na entrega. Ela prepara o time para operar: detectar falhas,
entender gargalos, responder rápido e controlar custos com visibilidade.

• Trilhas de operação: centralize logs de plataforma e de aplicação, mantendo correlação
  entre eventos (ex.: requisição → dependências → falha).
• Métricas com intenção: defina SLOs/SLAs (latência, taxa de erro, disponibilidade) e conecte
  alertas a sinais úteis — não só a “CPU alta”.
• Ambiente de falha: planeje como você valida fallback e degradação controlada.
  Resiliência é testar caminhos alternativos.
• Controle de custo por camada: custos geralmente vêm de rede, armazenamento, computação e
  execução de operações. Faça diagnósticos por categoria para ajustar sem achismo.

Exemplo prático: mapeando rotas e DNS com endpoint privado

Quando você usa Private Endpoint, a resolução de nomes passa a ser determinante.
A regra é: garantir que o DNS do cliente aponte para o IP privado, e que as rotas/segurança permitam o fluxo.

# 1) Valide se o FQDN resolve para o IP privado a partir da rede correta
#    (executar em uma VM dentro da VNet, ou via ferramenta equivalente no ambiente alvo)
nslookup SEU_SERVICO.SEUDOMINIO.com

# 2) Confirme conectividade TCP/HTTPS para o IP privado
#    Ajuste a porta conforme o serviço (ex.: 443)
#    Exemplo com PowerShell (Windows):
Test-NetConnection -ComputerName SEU_SERVICO.SEUDOMINIO.com -Port 443

# 3) Se o DNS estiver incorreto, revise:
#    - private DNS zone linking (VNet links)
#    - registros (A/CNAME) e policies de resolução
#    - se há split-brain de DNS (zonas diferentes por rede)
#
# Observação: o "funcionou" é quando:
#   (a) nslookup retorna IP privado esperado
#   (b) handshake na porta permitida ocorre sem bloqueio

Dica: trate esse tipo de validação como parte do checklist de rollout. Se o DNS não está correto, a falha
costuma ser intermitente e difícil de diagnosticar.