O problema não é escolher a feature “errada”. É tratar restrição de acesso, IP privado, DNS e publicação de serviços como se fossem a mesma coisa.
Em Azure, muita arquitetura “privada” só descobre que não era tão privada assim quando o DNS continua resolvendo para IP público, o acesso on-premises falha, ou o time percebe que publicou o serviço certo da forma errada.
Esse é exatamente o ponto deste artigo: Service Endpoint, Private Endpoint e Private Link não são sinônimos.
Eles se relacionam, mas resolvem problemas diferentes.
E a decisão errada quase nunca aparece na reunião de arquitetura. Ela aparece depois: no troubleshooting, na integração híbrida, na governança, ou no incidente que nasce da falsa sensação de isolamento.
Service Endpoint controla quem pode chegar ao serviço.
Private Endpoint muda como você chega ao serviço.
Private Link Service muda como você publica o seu serviço para outros.
Figura 01: Private Endpoint vs Service Endpoint vs Private Link
Guia de decisão com DNS e armadilhas
Primeiro: corte a confusão pela raiz
A forma mais simples de evitar erro nesse tema é separar os conceitos logo no início.
Service Endpoint é uma configuração aplicada na subnet.
Ele permite que determinados serviços Azure PaaS reconheçam o tráfego como vindo daquela subnet e aceitem regras de acesso baseadas nisso. O tráfego segue pela backbone da Microsoft, mas o ponto decisivo é este: mesmo com Service Endpoint, o serviço continua sendo acessado pelo endpoint público do serviço. O que muda é que o serviço passa a reconhecer o tráfego como vindo de uma subnet autorizada.. [1][4]
Private Endpoint é outra categoria de solução.
Ele cria uma interface de rede (NIC) dentro da subnet da VNet, com um IP privado que representa aquele recurso, conectada a um recurso específico que suporta Azure Private Link. Aqui, o consumo do recurso passa a acontecer por um IP privado da sua rede. [6]. Criar um Private Endpoint não desativa automaticamente o endpoint público do recurso. Isso deve ser controlado separadamente na configuração de rede do serviço.
Private Link é a plataforma.
Quando você consome um recurso privado, normalmente cria um Private Endpoint. Quando você quer publicar o seu próprio serviço para consumidores privados, entra o Private Link Service. [1][2]
Essa diferença parece sutil. Não é.
Ela muda a topologia.
Muda o DNS.
Muda o troubleshooting.
Muda a governança.
E muda a forma correta de decidir.
O que cada opção realmente resolve
Service Endpoint
Service Endpoint
Service Endpoint funciona muito bem quando o problema é:
“Quero que apenas determinadas subnets do Azure acessem esse serviço PaaS suportado.”
Ele é simples, rápido de habilitar, não exige redesenho de DNS e não tem cobrança adicional dessa camada de conectividade. [4]
Mas ele também tem um limite conceitual muito importante:
Service Endpoint não cria um IP privado do serviço dentro da sua rede.
A própria documentação da Microsoft deixa claro que, com Service Endpoint, o DNS do serviço continua resolvendo para IP público. [4]
Então a explicação correta não é “o serviço ficou privado”.
A explicação correta é:
Com Service Endpoint, o serviço continua público do ponto de vista de endereçamento.
O que muda é a forma como ele reconhece e restringe quem pode acessá-lo.
Isso faz dele uma boa escolha quando o cenário é mais simples, mais local ao Azure, e o objetivo é restringir acesso sem aumentar complexidade operacional.
Private Endpoint
Private Endpoint funciona quando o problema é outro:
“Quero acessar este recurso específico por IP privado, inclusive em cenários híbridos, com mais granularidade e menos dependência de endpoint público.”
Aqui, a mudança é arquitetural.
Você deixa de depender apenas de um endpoint público protegido por ACL de rede e passa a consumir o recurso por um IP privado da sua VNet. [6]
Esse endpoint privado pode ser acessado a partir de:
- VNet local;
- VNets emparelhadas;
- on-premises via VPN;
- on-premises via ExpressRoute. [6]
É exatamente por isso que Private Endpoint costuma ser a escolha mais consistente em ambientes enterprise, regulados e híbridos.
Private Endpoint não é apenas um recurso de segurança.
Ele é uma decisão de conectividade corporativa.
Private Link e Private Link Service
Aqui está a parte que mais costuma ser explicada de forma confusa.
Private Link é a plataforma.
Private Endpoint é o lado consumidor.
Private Link Service é o lado provedor. [1][2]
Private Link Service entra quando você quer publicar o seu próprio serviço para que outras redes o consumam de forma privada.
Nesse modelo, a Microsoft exige que o serviço esteja por trás de um Standard Load Balancer. [2][3]
Esse detalhe é fundamental porque muita gente pensa em Private Link Service como “qualquer PaaS privado no Azure”. Não é isso.
No modelo clássico, ele é mais adequado para workloads que você controla na camada de rede e balanceamento.
Quando NÃO usar cada abordagem
Além de entender quando usar cada recurso, é igualmente importante saber quando **não utilizá-los**.
Quando evitar Service Endpoint
Service Endpoint pode ser uma solução simples para restringir acesso a serviços PaaS, mas não é adequado em alguns cenários:
– quando é necessário eliminar completamente o endpoint público do serviço
– quando existe conectividade híbrida complexa com on-premises
– quando é necessário isolamento mais forte de rede
– quando políticas de segurança exigem tráfego totalmente privado
Quando evitar Private Endpoint
Private Endpoint é extremamente poderoso, mas pode adicionar complexidade desnecessária em alguns casos:
– ambientes simples totalmente dentro do Azure
– workloads temporários ou ambientes de desenvolvimento
– cenários onde a gestão de DNS privado não está bem definida
Quando evitar Private Link Service
Private Link Service é projetado principalmente para **publicação de serviços próprios** e pode ser excessivo em muitos cenários:
– quando você apenas precisa acessar um serviço PaaS da Azure
– quando não existe necessidade de expor um serviço para múltiplos consumidores
– quando não há arquitetura baseada em Load Balancer e backend pool
Onde o Private Link Service realmente entra
Quando alguém pergunta “Private Link Service serve para quê na prática?”, a melhor resposta não é abstrata. A melhor resposta é mostrar cenários reais.
1) SaaS multitenant rodando em VMs ou VM Scale Sets
Esse é um dos melhores exemplos.
Imagine uma plataforma B2B hospedada no Azure, com arquitetura multitenant, rodando em VMs ou VM Scale Sets, atrás de um Standard Load Balancer. Você quer publicar esse serviço para clientes corporativos de forma privada, sem internet pública como caminho principal.
Nesse cenário, o provedor publica o serviço por Private Link Service e cada cliente cria o seu próprio Private Endpoint do lado consumidor. [5]
Esse é um caso muito forte porque mostra Private Link Service no papel para o qual ele realmente foi desenhado.
2) Serviços privados em AKS por trás de Standard Load Balancer
AKS também pode entrar como exemplo real.
Se você tem um serviço rodando em Kubernetes e ele é exposto por Standard Load Balancer, o desenho pode usar Private Link Service como modelo de publicação privada.
Mas aqui existe uma ressalva importante: a própria Microsoft documenta limitações de suporte em AKS dependendo da forma como o backend pool do load balancer está configurado, como o caso de nodeIP. [11]
3) Proxies, appliances, brokers TCP/HTTP e NVAs
Outro cenário bem comum em ambientes enterprise é publicar serviços de infraestrutura próprios, como:
- proxies privados;
- ingress internos;
- brokers TCP;
- appliances de segurança;
- NVAs em farm atrás de load balancer.
Nesse caso, o modelo de Standard Load Balancer + backend controlado por NIC encaixa naturalmente. [2][3]
Então é só VM?
No modelo clássico e mais comum, principalmente sim:
- VMs;
- VM Scale Sets;
- alguns cenários em AKS;
- workloads próprios que fazem sentido atrás de Standard Load Balancer.
A própria criação do Private Link Service exige backend alinhado ao modelo do load balancer, o que o aproxima mais de workloads IaaS ou plataformas que se apoiam nesse desenho. [2][3][12]
E PaaS do Azure também pode usar Private Link?
Sim, mas de outro jeito.
Vários PaaS do Azure oferecem suporte nativo a Private Endpoint/Private Link como funcionalidade do próprio serviço.
Exemplos claros:
Azure App Service suporta Private Endpoint para tráfego de entrada; já a integração com VNet é usada para saída. [7][8]
Azure API Management suporta inbound private endpoint para o gateway, com exigência de DNS privado adequado. [9][10]
Ou seja:
PaaS do Azure pode usar Private Link, mas na maioria das vezes como serviço gerenciado com Private Endpoint nativo — e não como backend do seu próprio Private Link Service.
Figura 02: No Private Link Service, o provedor publica o serviço por trás de um Standard Load Balancer e cada consumidor se conecta por seu próprio Private Endpoint.
Casos de uso: quando eu escolheria cada opção
Caso 1 — aplicação no Azure acessando Storage e Key Vault, sem exigência híbrida
Se eu tenho uma aplicação hospedada inteiramente no Azure, acessando Storage e Key Vault, sem consumo forte a partir de on-premises e sem uma malha multicloud conectada, Service Endpoint ainda pode ser suficiente.
Aqui, o problema não é “preciso de IP privado do serviço”.
O problema é:
“Quero que apenas minhas subnets autorizadas acessem esse recurso PaaS.”
Nesse cenário, simplicidade operacional pesa muito a favor do Service Endpoint. [4]
Caso 2 — empresa regulada com ExpressRoute ou VPN e serviços críticos no Azure
Se o ambiente tem datacenter, ExpressRoute ou VPN, exigência de acesso privado, restrição forte de exposição e uso de SQL, Storage, Key Vault, Cosmos DB, ACR ou APIM, minha escolha tende a ser Private Endpoint. [6]
O requisito aqui já não é só “subnet autorizada”.
É:
“Quero um caminho privado e previsível até esse recurso.”
Caso 3 — organização multicloud com Azure, on-premises, AWS e GCP
Em cenários multicloud conectados, Private Endpoint normalmente se encaixa melhor do que Service Endpoint.
O motivo é simples: Service Endpoint foi pensado para estender a identidade de subnets Azure até serviços suportados. Já Private Endpoint se adapta melhor a topologias híbridas e à necessidade de padronizar conectividade privada entre domínios de rede diferentes. [5][6]
Caso 4 — publicar um serviço interno para outras subscriptions ou tenants
Se eu preciso disponibilizar um serviço meu para outras áreas, outras subscriptions ou até outros tenants, sem internet pública como caminho principal, o caminho correto é Private Link Service. [1][2]
Esse é o cenário clássico de provedor/consumidor privado.
Caso 5 — expor uma aplicação SaaS privada para clientes corporativos
Esse é provavelmente o melhor caso de uso “real de mercado” para Private Link Service.
Você tem uma solução B2B rodando em VMs ou VM Scale Sets, publica o serviço via Private Link Service e cada cliente cria seu Private Endpoint do lado dele. [5]
É um cenário elegante para explicar no Medium porque conecta Azure Networking com produto, isolamento, integração enterprise e desenho multitenant.
O ponto que mais quebra projeto: DNS
Se eu tivesse que apostar em um único ponto de falha nesses projetos, apostaria em DNS.
Em Service Endpoint, o DNS continua simples: o serviço segue resolvendo para IP público. [4]
Em Private Endpoint, o jogo muda completamente.
O Azure usa o domínio privatelink, e a resolução precisa chegar ao IP privado do endpoint. O cliente normalmente continua usando o mesmo FQDN lógico do serviço, mas o caminho de resolução precisa estar corretamente ajustado, seja com Private DNS Zone, seja com integração de DNS corporativo, seja com Azure Private Resolver em cenários maiores. [7][9]
É aqui que muita implementação “parece pronta” e falha no teste.
O Private Endpoint existe.
A conexão foi aprovada.
A subnet está certa.
Mas a aplicação continua resolvendo o nome para o IP público.
Quando isso acontece, o problema não está no peering.
Nem no firewall.
Nem na interface privada em si.
O problema está no nome.
Em Azure, conectividade privada sem desenho de DNS é projeto incompleto.
Figura 03: Em Private Endpoint, a aplicação geralmente continua usando o mesmo nome lógico do serviço; o que muda é a resolução DNS para o IP privado.
As armadilhas que realmente importam
Private Endpoint não bloqueia automaticamente o endpoint público
Esse é um dos erros mais comuns.
Criar um Private Endpoint não significa, por si só, que o endpoint público do recurso foi desabilitado. Em vários serviços, você ainda precisa tratar firewall e public network access separadamente. [6]
Service Endpoint não resolve sozinho cenário híbrido
Esse talvez seja o erro arquitetural mais caro.
Se o requisito envolve on-premises ou conectividade corporativa mais ampla, Service Endpoint normalmente não resolve o problema sozinho da forma que muitos imaginam. [4][5]
No AKS, Private Link Service tem restrições que precisam ser conhecidas
AKS pode ser um bom exemplo de uso para Private Link Service, mas com ressalvas de suporte documentadas pela Microsoft, especialmente dependendo do tipo de backend pool usado no load balancer. [11]
A topologia do backend do Private Link Service importa
Private Link Service requer Standard Load Balancer e backend aderente ao modelo suportado. Não é simplesmente “qualquer aplicação atrás de qualquer balanceador”. [2][3]
DNS privado mal desenhado gera comportamento inconsistente
Essa é a armadilha silenciosa.
Às vezes o recurso funciona na VNet local, mas não funciona em outra spoke.
Ou funciona no Azure, mas falha on-premises.
Ou funciona em um host e falha em outro.
Quando isso acontece, quase sempre vale voltar para o DNS antes de culpar a rede.
Minha regra prática de decisão
Eu usaria Service Endpoint quando:
- o cenário for predominantemente Azure-only;
- o serviço PaaS for suportado;
- o objetivo for restringir acesso por subnet;
- eu quiser a solução mais simples possível;
- eu não quiser introduzir dependência forte de DNS privado.
Eu usaria Private Endpoint quando:
- eu precisasse de IP privado;
- houvesse conectividade híbrida com on-premises;
- existisse ambiente multicloud conectado;
- eu quisesse granularidade por recurso;
- eu precisasse caminhar para redução real de exposição pública.
Eu usaria Private Link Service quando:
- eu fosse o provedor do serviço;
- eu precisasse publicar essa aplicação para outros consumidores privados;
- os consumidores estivessem em outras VNets, subscriptions ou tenants;
- o caso fosse SaaS, B2B, compartilhamento interno entre domínios de rede ou publicação privada controlada.
Figura 04: Escolha pela natureza do problema: restrição de acesso, consumo privado do recurso ou publicação privada do seu próprio serviço.
Conclusão
A pergunta certa não é:
“Qual dessas opções é a mais segura?”
A pergunta certa é:
“Eu quero restringir o acesso ao serviço, consumir o serviço por IP privado ou publicar o meu serviço para terceiros de forma privada?”
Se você responder isso corretamente, metade da decisão já está tomada.
A outra metade está no que normalmente fica para depois:
- DNS;
- topologia do backend;
- clareza entre consumidor e provedor;
- e o papel exato de cada componente.
Porque, no fim, o erro mais caro quase nunca está no nome da feature.
Ele está em usar uma tecnologia para resolver um problema diferente daquele que você realmente tem.
Service Endpoint restringe acesso.
Private Endpoint entrega conectividade privada ao recurso.
Private Link Service publica o seu serviço para consumidores privados.Quando esses três papéis ficam claros, a decisão arquitetural fica muito mais simples — e muito mais correta.
Referências
[1] What is Azure Private Link?
[2] What is Azure Private Link service?
[3] Quickstart — Create a Private Link service — Azure portal
[4] Azure Private Link frequently asked questions (FAQ)
[5] Guidance for using Azure Private Link service in a multitenant solution
[6] What is a private endpoint?
[7] Use private endpoints for Azure App Service apps
[8] Integrate your app with an Azure virtual network
[9] Set up inbound private endpoint for Azure API Management
[10] Azure API Management virtual network concepts
[11] Use a Public Standard Load Balancer in Azure Kubernetes Service (AKS)
[12] Azure Load Balancer backend pool management
[13] Azure App Service access restrictions