APRENDER. PRATICAR. EVOLUIR.Um private endpoint não resolve todas as dependências
Um endpoint aprovado é um elemento da arquitetura, não uma prova de funcionamento do cliente. Inventaria consumidores, nomes usados, resolvers, subrecursos, portas e credenciais. Para Blob em Azure público, a aplicação mantém o nome normal da conta. A arquitetura DNS encaminha a resolução até ao IP privado; não se deve substituir o hostname por uma IP e retirar validação TLS para compensar uma falha DNS. Uma operação representativa precisa de transporte, identidade, permissões e resultado esperado. A restrição do endpoint público é uma decisão adicional, a executar com dependências identificadas e critérios de retorno.
Seguir o resolver do cliente
No modelo on-premises com Private Resolver, a zona de encaminhamento recomendada para Blob é blob.core.windows.net. A zona privada contém o registo correspondente em privatelink.blob.core.windows.net. Regista o caminho usado pelo cliente, o resolver que responde e os resultados observados; o ensaio no hub pode seguir outro percurso. Num desenho simples com Azure-provided DNS e VNets em peering, associa a mesma zona privada às VNets clientes necessárias. Peering não cria essa associação. Em arquiteturas com custom DNS, aplica o desenho de encaminhamento adequado, em vez de presumir que adicionar uma ligação de zona altera automaticamente o servidor DNS usado.
Separar registo, subrecurso e autorização
Blob e File usam subrecursos e zonas diferentes. Um endpoint para Blob não cria por si acesso privado a File. Verifica o serviço usado por cada funcionalidade antes de copiar configurações. No fixture autoritativo sem fallback, conta-a tem um registo e conta-b não; obter NXDOMAIN para b é um problema de resolução nesse âmbito, não prova de bloqueio TCP. Outro exercício tem DNS e TLS corretos, mas o serviço devolve AuthorizationPermissionMismatch para a identidade esperada. A investigação passa então por operação, credencial, âmbito e permissões de dados. O código específico e os logs ajudam a não tratar todos os HTTP 403 como a mesma causa.
Aceitar uma migração com provas positivas e negativas
Para cada cliente previsto, confirma resposta DNS, destino, TLS com o nome normal, identidade e operação representativa. Não uses um único ensaio do hub para aprovar um batch on-premises que ainda resolve publicamente. Se o requisito é exclusivamente privado, acrescenta um teste externo controlado que confirme a restrição pública sem expor dados. Os testes respondem a perguntas distintas: sucesso privado e negação pública. Define o que fazer se a janela terminar antes da validação; adiar, reverter ou aceitar exceção temporária exige responsável e registo. O prazo da mudança não transforma uma dependência por testar numa dependência pronta.
Recolha de tráfego com ciclo de vida atual
Na consulta de 02-10-2026, a documentação indica que novos NSG flow logs já não podem ser criados e que a retirada está prevista para 30-09-2027. Para um projeto novo, avalia VNet flow logs, compatibilidade dos recursos, destino e retenção. A migração deve considerar sobreposição de recolha, que pode duplicar registos e custos. Registos de fluxo descrevem tráfego e decisões de rede; não comprovam confirmação de transações nem validade dos dados. Mantém identificadores e tempos que permitam correlação com a aplicação. Não apagues registos históricos só porque o recurso de recolha vai ser retirado; conserva-os conforme as regras de retenção aplicáveis.
Exercício de entrega a RUN
Prepara uma demonstração para a equipa que vai receber incidentes: gerar um fluxo autorizado, observar chegada de dados, consultar com permissões adequadas e correlacionar com um job de teste. Regista âmbito, atraso observado, retenção, responsáveis e instruções de diagnóstico. Se a recolha existe mas não há dados ou acesso de consulta, identifica a lacuna em vez de dar Owner como solução universal. Se TCP passa e o job falha por validação, mantém a pendência funcional aberta. Um handover condicionado deve indicar cobertura temporária, prazos e responsabilidades, sem confundir aceitação administrativa com autonomia operacional comprovada.
Resumo e próximos exercícios
O percurso privado tem de ser observado a partir dos clientes que vão usá-lo. Nome resolvido, destino alcançado, TLS, autorização e resultado são critérios separados. A observabilidade só está pronta quando RUN consegue encontrar e interpretar os dados necessários. Os exemplos e modelos locais são originais e sintéticos: não criam recursos, não consultam subscrições, não executam resolvers e não enviam pacotes. Usa-os para preparar hipóteses e critérios; depois confirma o comportamento num laboratório autorizado com recursos e dados de teste. Liga esta aula à anterior, a storage, identidade, gestão de mudanças e recuperação.
APPLICATION NAME fundsdata.blob.core.windows.net
PUBLIC FORWARDING ZONE blob.core.windows.net
PRIVATE ZONE privatelink.blob.core.windows.net
HUB CLIENT private answer observed
ON-PREMISES CLIENT public answer observed
CUTOVER ACCEPTANCE pending representative on-premises validationO hub obtém IP privado e o batch on-premises obtém IP público. Regista os dois resolvers e valida o cliente do batch antes de desativar o acesso público. O sucesso do hub tem um âmbito limitado.
Armadilhas comuns
Assumir DNS partilhado por peering; usar o IP em vez do nome suportado; confundir endpoint Blob e File; encerrar com TCP positivo e job falhado.
Tópicos relacionados: Diagnóstico de produção · Mudanças e recuperação · Evidência operacional
Aprova o corte e o handover com evidência dos clientes reais e com resultados interpretados por camada.
Referência: Private endpoint DNS integration · AZ-104; skills measured 2026-04-17