Fundamentação Teórica: Configure Private Endpoints for Azure PaaS

1. Intuição Inicial

No módulo anterior sobre Service Endpoints, vimos que eles criam um caminho otimizado da VNet até o serviço PaaS, mas o serviço mantém seu endereço IP público. É como ter uma entrada exclusiva num banco, mas o banco ainda tem um endereço na rua principal que qualquer pessoa pode visitar.

Private Endpoints vão muito além: eles trazem o serviço PaaS para dentro da sua VNet. É como se o banco abrisse uma agência exclusiva dentro do seu condomínio, com um endereço interno que só os moradores conhecem e só eles podem visitar. O banco original continua existindo na rua principal, mas sua agência privada só é acessível de dentro.

Na prática: um Private Endpoint cria uma interface de rede (NIC) com um IP privado da sua VNet que representa um serviço PaaS específico (como uma Storage Account ou um SQL Database). Quando suas VMs se conectam ao serviço, o DNS resolve o nome do serviço para esse IP privado, e o tráfego nunca sai da sua rede privada.

2. Contexto

2.1 A evolução do acesso privado a PaaS

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

2.2 Por que Private Endpoints são superiores a Service Endpoints

Private Endpoints resolvem limitações que Service Endpoints não conseguem endereçar:

Acesso de on-premises: VMs ou servidores conectados via VPN ou ExpressRoute podem acessar serviços PaaS como se fossem recursos internos
DNS privado: O nome myaccount.blob.core.windows.net resolve para um IP privado da VNet, não para um IP público
Isolamento por instância: Cada Private Endpoint aponta para uma instância específica do serviço, não para todo o serviço Azure Storage
Eliminação do endpoint público: É possível desabilitar completamente o acesso público ao serviço PaaS

2.3 Casos de uso principais

Aplicações bancárias e de saúde com dados regulados que nunca podem trafegar por redes públicas
Ambientes on-premises conectados via ExpressRoute que precisam acessar Azure SQL ou Azure Storage
Arquiteturas onde o serviço PaaS não deve ser visível fora da VNet
Ambientes multi-tenant onde diferentes clientes têm serviços PaaS completamente isolados

3. Construção dos Conceitos

3.1 Os três componentes de um Private Endpoint

1. Private Endpoint (o recurso) Um objeto Azure que representa a conexão privada a um serviço. Contém: a NIC com IP privado, a referência ao serviço de destino e o sub-recurso de destino.

2. Network Interface (NIC) Criada automaticamente junto com o Private Endpoint. Recebe um IP privado da subnet onde é implantado. É por essa NIC que o tráfego efetivamente flui.

3. Private Link Connection A conexão lógica entre o Private Endpoint e o serviço PaaS. Pode precisar de aprovação pelo dono do serviço, dependendo da configuração.

3.2 Sub-recursos: conectando ao recurso certo dentro do serviço

Muitos serviços PaaS têm múltiplos sub-recursos. Quando você cria um Private Endpoint, precisa especificar qual sub-recurso quer expor. Exemplos:

Serviço	Sub-recursos disponíveis
Azure Storage	`blob`, `file`, `queue`, `table`, `dfs`, `web`
Azure SQL Database	`sqlServer`
Azure Key Vault	`vault`
Azure Cosmos DB	`Sql`, `MongoDB`, `Cassandra`, `Gremlin`, `Table`
Azure App Service	`sites`
Azure Container Registry	`registry`
Azure Event Hubs Namespace	`namespace`

Ponto importante: Se você precisa que uma Storage Account seja acessada tanto via Blob quanto via File por redes privadas, são necessários dois Private Endpoints, um para o sub-recurso blob e outro para file.

3.3 Private Link Service vs Private Endpoint

Há uma distinção que frequentemente confunde:

Private Endpoint: O lado do consumidor. Você cria na sua VNet para acessar um serviço de outra parte (Azure PaaS ou serviço de parceiro).

Private Link Service: O lado do provedor. Uma organização cria para expor seus próprios serviços (rodando atrás de um Load Balancer Standard) para outras VNets ou tenants via Private Endpoints.

Para o objetivo do AZ-104, o foco é em Private Endpoints conectando a serviços PaaS gerenciados pela Microsoft.

3.4 O processo de aprovação da conexão

Quando um Private Endpoint é criado apontando para um serviço PaaS, a conexão pode ter diferentes estados:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Auto-aprovação: Quando o Private Endpoint e o serviço de destino estão na mesma assinatura Azure ou o criador tem permissão Microsoft.Network/privateEndpoints/privateLinkServiceConnections/write no serviço, a aprovação é automática.

Aprovação manual: Quando o serviço pertence a outro tenant ou outra assinatura sem as permissões acima, o dono do serviço deve aprovar manualmente no painel Private endpoint connections do recurso.

3.5 Private DNS Zone: a peça mais crítica do quebra-cabeça

Este é o componente mais importante e menos intuitivo dos Private Endpoints.

O problema: O nome myaccount.blob.core.windows.net resolve publicamente para um IP público. Se suas VMs usam esse nome e ele resolve para o IP público, o tráfego vai pela internet mesmo que você tenha um Private Endpoint.

A solução: Uma Private DNS Zone que sobrescreve a resolução DNS para esse nome dentro da sua VNet, fazendo-o resolver para o IP privado do Private Endpoint.

Cada serviço PaaS tem uma zona DNS privada específica:

Serviço	Sub-recurso	Zona DNS privada
Azure Storage (Blob)	blob	`privatelink.blob.core.windows.net`
Azure Storage (File)	file	`privatelink.file.core.windows.net`
Azure Storage (Queue)	queue	`privatelink.queue.core.windows.net`
Azure Storage (Table)	table	`privatelink.table.core.windows.net`
Azure Storage (ADLS Gen2)	dfs	`privatelink.dfs.core.windows.net`
Azure SQL Database	sqlServer	`privatelink.database.windows.net`
Azure Key Vault	vault	`privatelink.vaultcore.azure.net`
Azure Cosmos DB (SQL)	Sql	`privatelink.documents.azure.com`
Azure Container Registry	registry	`privatelink.azurecr.io`
Azure App Service	sites	`privatelink.azurewebsites.net`

O mecanismo funciona assim: quando você resolve myaccount.blob.core.windows.net de dentro da VNet:

A consulta DNS vai ao DNS resolvedor da VNet (168.63.129.16)
O resolvedor verifica se há uma Private DNS Zone vinculada à VNet para privatelink.blob.core.windows.net
Se sim, e se houver um registro A para myaccount.privatelink.blob.core.windows.net → retorna o IP privado do Private Endpoint
O tráfego vai para o IP privado (a NIC do Private Endpoint), nunca saindo da VNet

4. Visão Estrutural

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

5.1 Fluxo completo de configuração

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Passo mais esquecido: O passo 4, vincular a Private DNS Zone à VNet. A zona pode existir mas se não estiver vinculada à VNet, o DNS resolvedor da VNet não a usa e o nome continua resolvendo para o IP público.

5.2 O portal Azure cria a DNS Zone automaticamente

Quando você cria um Private Endpoint pelo portal e seleciona "Integrate with private DNS zone", o portal:

Cria a Private DNS Zone com o nome correto automaticamente
Cria o VNet link automaticamente
Cria o registro A apontando para o IP privado automaticamente

Isso simplifica muito o processo. Via CLI e IaC, cada passo é separado e manual.

5.3 Verificando a resolução DNS

Após configurar, verifique que o DNS está correto de dentro de uma VM na VNet:

# No Linux (dentro da VM)
nslookup myaccount.blob.core.windows.net

# Resultado esperado:
# myaccount.blob.core.windows.net → myaccount.privatelink.blob.core.windows.net → 10.0.2.5
# (O CNAME intermediário com "privatelink" é normal e esperado)

O CNAME para privatelink.blob.core.windows.net é criado automaticamente pela Microsoft no DNS público. A Private DNS Zone intercepta a resolução desse CNAME e retorna o IP privado.

5.4 Acesso de on-premises via ExpressRoute/VPN

Para que servidores on-premises acessem o serviço PaaS via Private Endpoint:

O Private Endpoint deve existir e estar aprovado
A Private DNS Zone deve estar vinculada à VNet
O DNS on-premises precisa ser configurado para encaminhar queries de privatelink.blob.core.windows.net para o DNS resolvedor da VNet (168.63.129.16)

Esta configuração de DNS forwarding é o ponto mais complexo em ambientes híbridos. O Azure Private DNS Resolver simplifica isso ao criar endpoints de entrada e saída para resolução DNS.

6. Formas de Implementação

6.1 Portal Azure

Quando usar: Criação inicial, ambientes simples, quando se quer a criação automática da DNS Zone.

Criação: Private Link Center > Private endpoints > + Create

OU pela storage Account: Storage Account > Networking > Private endpoint connections > + Private endpoint

O formulário passa por abas:

Basics: Nome, região, resource group
Resource: Tipo de recurso, recurso alvo, sub-recurso
Virtual Network: VNet, subnet, configuração de IP
DNS: Integração com Private DNS Zone (recomendado marcar "Yes")
Tags e Review

6.2 Azure CLI

Criando o Private Endpoint:

# Obter Resource ID da Storage Account
STORAGE_ID=$(az storage account show \
  --name myaccount \
  --resource-group myRG \
  --query id --output tsv)

# Criar o Private Endpoint
az network private-endpoint create \
  --name pe-myaccount-blob \
  --resource-group myRG \
  --vnet-name myVNet \
  --subnet PrivateEndpointSubnet \
  --private-connection-resource-id $STORAGE_ID \
  --group-id blob \
  --connection-name conn-myaccount-blob \
  --location eastus

Criando a Private DNS Zone:

az network private-dns zone create \
  --resource-group myRG \
  --name "privatelink.blob.core.windows.net"

Vinculando a DNS Zone à VNet:

az network private-dns link vnet create \
  --resource-group myRG \
  --zone-name "privatelink.blob.core.windows.net" \
  --name link-to-myVNet \
  --virtual-network myVNet \
  --registration-enabled false

Criando o registro DNS automaticamente usando o DNS Zone Group:

# Obter o Resource ID do Private Endpoint
PE_ID=$(az network private-endpoint show \
  --name pe-myaccount-blob \
  --resource-group myRG \
  --query id --output tsv)

# Criar DNS Zone Group (cria o registro A automaticamente)
az network private-endpoint dns-zone-group create \
  --resource-group myRG \
  --endpoint-name pe-myaccount-blob \
  --name dns-zone-group \
  --private-dns-zone "privatelink.blob.core.windows.net" \
  --zone-name zone1

DNS Zone Group é o mecanismo que cria automaticamente o registro A na Private DNS Zone e mantém sincronizado se o IP do Private Endpoint mudar.

Desabilitando o acesso público à Storage Account:

az storage account update \
  --name myaccount \
  --resource-group myRG \
  --public-network-access Disabled

Verificando o status da conexão:

az network private-endpoint show \
  --name pe-myaccount-blob \
  --resource-group myRG \
  --query "privateLinkServiceConnections[].privateLinkServiceConnectionState"

6.3 Azure PowerShell

# Configuração completa via PowerShell

# 1. Criar Private Endpoint
$storage = Get-AzStorageAccount -ResourceGroupName "myRG" -Name "myaccount"

$privateEndpointConnection = New-AzPrivateLinkServiceConnection `
  -Name "conn-myaccount-blob" `
  -PrivateLinkServiceId $storage.Id `
  -GroupId "blob"

$subnet = Get-AzVirtualNetworkSubnetConfig `
  -VirtualNetwork (Get-AzVirtualNetwork -Name "myVNet" -ResourceGroupName "myRG") `
  -Name "PrivateEndpointSubnet"

$privateEndpoint = New-AzPrivateEndpoint `
  -ResourceGroupName "myRG" `
  -Name "pe-myaccount-blob" `
  -Location "eastus" `
  -Subnet $subnet `
  -PrivateLinkServiceConnection $privateEndpointConnection

# 2. Criar e configurar Private DNS Zone
$zone = New-AzPrivateDnsZone `
  -ResourceGroupName "myRG" `
  -Name "privatelink.blob.core.windows.net"

New-AzPrivateDnsVirtualNetworkLink `
  -ResourceGroupName "myRG" `
  -ZoneName "privatelink.blob.core.windows.net" `
  -Name "link-to-myVNet" `
  -VirtualNetworkId (Get-AzVirtualNetwork -Name "myVNet" -ResourceGroupName "myRG").Id `
  -EnableRegistration $false

# 3. Criar DNS Zone Group
New-AzPrivateEndpointIpConfiguration `
  -Name "dns-zone-group" `
  -PrivateDnsZoneId $zone.ResourceId `
  -RecordType A

6.4 Bicep

// Private Endpoint para Storage Account (Blob)
resource privateEndpoint 'Microsoft.Network/privateEndpoints@2023-05-01' = {
  name: 'pe-myaccount-blob'
  location: location
  properties: {
    subnet: {
      id: privateEndpointSubnet.id
    }
    privateLinkServiceConnections: [
      {
        name: 'conn-myaccount-blob'
        properties: {
          privateLinkServiceId: storageAccount.id
          groupIds: ['blob']
        }
      }
    ]
  }
}

// Private DNS Zone
resource privateDnsZone 'Microsoft.Network/privateDnsZones@2020-06-01' = {
  name: 'privatelink.blob.core.windows.net'
  location: 'global'
}

// VNet Link
resource vnetLink 'Microsoft.Network/privateDnsZones/virtualNetworkLinks@2020-06-01' = {
  parent: privateDnsZone
  name: 'link-to-vnet'
  location: 'global'
  properties: {
    registrationEnabled: false
    virtualNetwork: {
      id: vnet.id
    }
  }
}

// DNS Zone Group (cria registro A automaticamente)
resource dnsZoneGroup 'Microsoft.Network/privateEndpoints/privateDnsZoneGroups@2023-05-01' = {
  parent: privateEndpoint
  name: 'dns-zone-group'
  properties: {
    privateDnsZoneConfigs: [
      {
        name: 'config-blob'
        properties: {
          privateDnsZoneId: privateDnsZone.id
        }
      }
    ]
  }
}

6.5 Aprovando conexão pendente (cross-tenant)

Quando o Private Endpoint aponta para um serviço em outro tenant ou assinatura sem as permissões adequadas:

# No lado do provedor (dono do serviço), listar conexões pendentes
az storage account show \
  --name myaccount \
  --resource-group myRG \
  --query privateEndpointConnections

# Aprovar a conexão
az network private-endpoint-connection approve \
  --resource-group myRG \
  --resource-name myaccount \
  --type Microsoft.Storage/storageAccounts \
  --name <connection-name>

7. Controle e Segurança

7.1 Permissões necessárias

Operação	Permissão mínima
Criar Private Endpoint	Network Contributor na VNet + Reader no serviço PaaS
Aprovar conexão de Private Endpoint	Contributor ou Owner no serviço PaaS
Criar Private DNS Zone	Private DNS Zone Contributor
Vincular DNS Zone à VNet	Network Contributor na VNet
Desabilitar acesso público ao PaaS	Contributor no recurso PaaS

7.2 NSG e Private Endpoints

Por padrão, NSGs não se aplicam a Private Endpoints. Tráfego para o IP privado do Private Endpoint passa pelo NSG da subnet mas as regras não são avaliadas.

Para habilitar NSG em Private Endpoints (funcionalidade mais recente):

az network vnet subnet update \
  --vnet-name myVNet \
  --name PrivateEndpointSubnet \
  --resource-group myRG \
  --private-endpoint-network-policies Enabled

Após habilitar, NSGs e UDRs aplicados à subnet afetam o tráfego para Private Endpoints, permitindo microsegmentação adicional.

7.3 Desabilitando acesso público ao serviço PaaS

Este é o passo final para segurança máxima. Após criar o Private Endpoint, o serviço PaaS ainda aceita conexões públicas por padrão. Para desabilitar:

Storage Account:

az storage account update \
  --name myaccount \
  --resource-group myRG \
  --public-network-access Disabled

Azure SQL Database:

az sql server update \
  --name mySqlServer \
  --resource-group myRG \
  --enable-public-network false

Key Vault:

az keyvault update \
  --name myKeyVault \
  --resource-group myRG \
  --public-network-access Disabled

Cuidado: Antes de desabilitar o acesso público, certifique-se de que todas as aplicações e ferramentas administrativas que acessam o serviço já estão usando o Private Endpoint. Desabilitar prematuramente causa interrupções.

8. Tomada de Decisão

8.1 Private Endpoint vs Service Endpoint: decisão definitiva

Critério	Service Endpoint	Private Endpoint
IP do serviço	Público (imutável)	Privado (na VNet)
Acesso de on-premises	Não	Sim
Custo	Gratuito	Custo por hora + dados
Configuração DNS	Não necessária	Obrigatória
Desabilitar endpoint público	Opcional, mas PaaS ainda acessível	Possível desabilitar completamente
Isolamento por instância	Não (por serviço)	Sim (por recurso específico)
Complexidade	Baixa	Média/Alta
Transitividade por VNet peering	Não	Sim (tráfego via rota)
Suporte regulatório (HIPAA, PCI-DSS)	Parcial	Total

8.2 Quando cada abordagem é obrigatória vs recomendada

Situação	Abordagem	Justificativa
Acesso de ExpressRoute a Storage	Private Endpoint (obrigatório)	Service Endpoint não é transitivo via ExpressRoute
VM Azure acessa SQL Database, sem on-premises	Service Endpoint ou Private Endpoint	Ambos funcionam; PE se houver requisito de compliance
Conformidade PCI-DSS ou HIPAA	Private Endpoint (obrigatório)	Dados não podem trafegar por redes públicas de forma alguma
Ambiente multi-tenant com isolamento total	Private Endpoint (obrigatório)	Service Endpoint não isola por instância
Custo mínimo em dev/test	Service Endpoint	PE tem custo adicional
Resolução DNS privada necessária	Private Endpoint (obrigatório)	Service Endpoint não altera DNS

8.3 Subnet dedicada para Private Endpoints

Situação	Usar subnet dedicada?	Motivo
Múltiplos Private Endpoints	Sim (recomendado)	Organização e gerenciamento de NSG mais claro
Um único Private Endpoint	Opcional	Pode coexistir com outras VMs se NSG for gerenciado
Ambiente com NSG em PE habilitado	Sim	Facilita criação de regras específicas

9. Boas Práticas

Sempre crie o DNS Zone Group ao criar o Private Endpoint via CLI/PowerShell/Bicep. Sem ele, o registro A na Private DNS Zone não é criado automaticamente e o DNS não funciona.
Verifique a resolução DNS de dentro de uma VM na VNet após configurar. Um nslookup que retorna IP privado é o teste de sanidade mais rápido.
Desabilite o acesso público ao serviço PaaS após validar que todas as aplicações funcionam via Private Endpoint. Mantenha habilitado durante a transição.
Use subnets dedicadas para Private Endpoints em produção, especialmente quando há muitos endpoints.
Centralize Private DNS Zones no hub em arquiteturas hub-and-spoke e vincule às VNets spoke. Não crie zonas duplicadas em cada VNet.
Configure DNS forwarding para ambientes on-premises: servidores DNS locais devem encaminhar queries de privatelink.* para o DNS resolvedor da VNet Azure.
Use o Azure Private DNS Resolver em ambientes híbridos complexos para centralizar a resolução DNS entre on-premises e Azure.
Habilite NSG em Private Endpoints em ambientes de alta segurança para controlar qual tráfego pode chegar ao endpoint.
Documente qual IP privado foi atribuído a cada Private Endpoint. IPs não mudam após criação mas é importante registrar para troubleshooting.

10. Erros Comuns

Erro	Por que acontece	Como evitar
DNS resolve IP público mesmo com PE criado	DNS Zone não vinculada à VNet ou DNS Zone Group não criado	Verificar VNet link e registro A na Private DNS Zone
Aplicação não consegue conectar mesmo com DNS correto	Acesso público desabilitado antes do PE estar aprovado	Aguardar aprovação e verificar estado da conexão
Timeout de conexão de on-premises	DNS on-premises não encaminha queries de privatelink.* para Azure	Configurar DNS forwarder para a VNet
PE em estado "Pending" indefinidamente	Criador não tem permissão de auto-aprovação no serviço	Aprovar manualmente no painel do serviço PaaS
Múltiplas DNZ Zones criadas acidentalmente	Cada deploy cria uma nova zona em vez de reutilizar	Verificar se a zona já existe antes de criar
NSG bloqueando tráfego para PE	`private-endpoint-network-policies` habilitado sem regras adequadas	Criar regras de Allow no NSG para tráfego ao IP do PE
Registro A não criado na Private DNS Zone	DNS Zone Group não foi criado	Criar o DNS Zone Group após criar o Private Endpoint
Acesso de VNet spoke não funciona	DNS Zone não vinculada à VNet spoke	Adicionar VNet link da zona para cada VNet que precisa resolver

11. Operação e Manutenção

11.1 Verificando o estado de todas as conexões de Private Endpoint

# Listar todos os Private Endpoints e seus estados
az network private-endpoint list \
  --resource-group myRG \
  --query "[].{Name:name, Status:privateLinkServiceConnections[0].privateLinkServiceConnectionState.status, ProvisioningState:provisioningState}" \
  --output table

11.2 Verificando o registro DNS criado

az network private-dns record-set a list \
  --resource-group myRG \
  --zone-name "privatelink.blob.core.windows.net" \
  --output table

11.3 Monitorando Private Endpoints com Azure Monitor

az monitor diagnostic-settings create \
  --name "pe-diagnostics" \
  --resource <private-endpoint-id> \
  --metrics '[{"category": "AllMetrics", "enabled": true}]' \
  --workspace <log-analytics-workspace-id>

Métricas relevantes incluem bytes enviados/recebidos pelo Private Endpoint.

11.4 Limites importantes

Recurso	Limite
Private Endpoints por subscription	64.000
Private Endpoints por VNet	Sem limite documentado
Private DNS Zones por subscription	1.000
VNet links por Private DNS Zone	1.000
Registros A por Private DNS Zone	25.000
Custo	~$7,30/mês por endpoint + $0,01 por GB processado (aproximado, varia por região)

12. Integração e Automação

12.1 Azure Policy para exigir Private Endpoints

# Policy: Storage Accounts devem usar Private Endpoints
az policy assignment create \
  --name "storage-require-private-endpoint" \
  --policy "6edd7eda-6dd8-40f7-810d-67160c639cd9" \
  --scope "/subscriptions/<sub-id>"

Policy custom para negar criação de Storage Accounts com acesso público habilitado:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Storage/storageAccounts"
      },
      {
        "field": "Microsoft.Storage/storageAccounts/publicNetworkAccess",
        "notEquals": "Disabled"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

12.2 Azure Private DNS Resolver para ambientes híbridos

# Criar DNS Resolver
az dns-resolver create \
  --name myDnsResolver \
  --resource-group myRG \
  --location eastus \
  --id-virtual-network <vnet-id>

# Criar inbound endpoint (DNS on-premises aponta para esse IP)
az dns-resolver inbound-endpoint create \
  --dns-resolver-name myDnsResolver \
  --resource-group myRG \
  --name inbound-ep \
  --ip-configurations "[{\"privateIpAllocationMethod\":\"Dynamic\",\"id\":\"<subnet-id>\"}]"

# Criar outbound endpoint e forwarding ruleset
az dns-resolver outbound-endpoint create \
  --dns-resolver-name myDnsResolver \
  --resource-group myRG \
  --name outbound-ep \
  --id <subnet-id>

O Private DNS Resolver é a solução recomendada pela Microsoft para resolução DNS híbrida, substituindo o tradicional "custom DNS server" com forwarders manuais.

13. Resumo Final

Conceitos essenciais:

Um Private Endpoint cria uma NIC com IP privado na sua VNet que representa um serviço PaaS específico. O tráfego para o serviço nunca sai da rede privada.
A configuração exige três componentes: o Private Endpoint, a Private DNS Zone (com VNet link) e o DNS Zone Group (que cria o registro A automaticamente).
Cada sub-recurso de um serviço PaaS (blob, file, queue no Storage; sqlServer no SQL) requer um Private Endpoint separado.

A cadeia de DNS é a peça central:

myaccount.blob.core.windows.net → CNAME → myaccount.privatelink.blob.core.windows.net → Registro A na Private DNS Zone → IP privado do Private Endpoint (ex: 10.0.2.5)

Diferenças críticas com Service Endpoints:

Service Endpoint: tráfego usa backbone MS mas PaaS tem IP público. Não funciona de on-premises.
Private Endpoint: PaaS recebe IP privado na VNet. Funciona de on-premises via VPN/ExpressRoute. Tem custo adicional. Requer configuração DNS.

O que precisa ser lembrado:

Sem a Private DNS Zone vinculada à VNet, o DNS resolve o IP público mesmo com o Private Endpoint ativo.
O DNS Zone Group é o mecanismo que cria e sincroniza o registro A automaticamente.
A conexão pode precisar de aprovação manual quando o serviço PaaS está em outro tenant ou assinatura sem as permissões adequadas.
Desabilitar o acesso público ao PaaS é o passo final para segurança completa, mas deve ser feito após validar que tudo funciona pelo endpoint privado.
Para ambientes on-premises, a resolução DNS requer configuração de forwarders apontando para o DNS Azure (168.63.129.16) ou uso do Azure Private DNS Resolver.
Por padrão, NSGs não se aplicam a Private Endpoints; é necessário habilitar private-endpoint-network-policies na subnet para ativá-los.

1. Intuição Inicial​

2. Contexto​

2.1 A evolução do acesso privado a PaaS​

2.2 Por que Private Endpoints são superiores a Service Endpoints​

2.3 Casos de uso principais​

3. Construção dos Conceitos​

3.1 Os três componentes de um Private Endpoint​

3.2 Sub-recursos: conectando ao recurso certo dentro do serviço​

3.3 Private Link Service vs Private Endpoint​

3.4 O processo de aprovação da conexão​

3.5 Private DNS Zone: a peça mais crítica do quebra-cabeça​

4. Visão Estrutural​

5. Funcionamento na Prática​

5.1 Fluxo completo de configuração​

5.2 O portal Azure cria a DNS Zone automaticamente​

5.3 Verificando a resolução DNS​

5.4 Acesso de on-premises via ExpressRoute/VPN​

6. Formas de Implementação​

6.1 Portal Azure​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 Bicep​

6.5 Aprovando conexão pendente (cross-tenant)​

7. Controle e Segurança​

7.1 Permissões necessárias​

7.2 NSG e Private Endpoints​

7.3 Desabilitando acesso público ao serviço PaaS​

8. Tomada de Decisão​

8.1 Private Endpoint vs Service Endpoint: decisão definitiva​

8.2 Quando cada abordagem é obrigatória vs recomendada​

8.3 Subnet dedicada para Private Endpoints​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

11.1 Verificando o estado de todas as conexões de Private Endpoint​

11.2 Verificando o registro DNS criado​

11.3 Monitorando Private Endpoints com Azure Monitor​

11.4 Limites importantes​

12. Integração e Automação​

12.1 Azure Policy para exigir Private Endpoints​

12.2 Azure Private DNS Resolver para ambientes híbridos​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

2.1 A evolução do acesso privado a PaaS

2.2 Por que Private Endpoints são superiores a Service Endpoints

2.3 Casos de uso principais

3. Construção dos Conceitos

3.1 Os três componentes de um Private Endpoint

3.2 Sub-recursos: conectando ao recurso certo dentro do serviço

3.3 Private Link Service vs Private Endpoint

3.4 O processo de aprovação da conexão

3.5 Private DNS Zone: a peça mais crítica do quebra-cabeça

4. Visão Estrutural

5. Funcionamento na Prática

5.1 Fluxo completo de configuração

5.2 O portal Azure cria a DNS Zone automaticamente

5.3 Verificando a resolução DNS

5.4 Acesso de on-premises via ExpressRoute/VPN

6. Formas de Implementação

6.1 Portal Azure

6.2 Azure CLI

6.3 Azure PowerShell

6.4 Bicep

6.5 Aprovando conexão pendente (cross-tenant)

7. Controle e Segurança

7.1 Permissões necessárias

7.2 NSG e Private Endpoints

7.3 Desabilitando acesso público ao serviço PaaS

8. Tomada de Decisão

8.1 Private Endpoint vs Service Endpoint: decisão definitiva

8.2 Quando cada abordagem é obrigatória vs recomendada

8.3 Subnet dedicada para Private Endpoints

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

11.1 Verificando o estado de todas as conexões de Private Endpoint

11.2 Verificando o registro DNS criado

11.3 Monitorando Private Endpoints com Azure Monitor

11.4 Limites importantes

12. Integração e Automação

12.1 Azure Policy para exigir Private Endpoints

12.2 Azure Private DNS Resolver para ambientes híbridos

13. Resumo Final