What's the difference between a subscription being in visibility versus autoApproval?

visibility.subscriptions controls which subscriptions can even discover and request a private endpoint connection to this service at all, autoApproval.subscriptions is a subset of visible subscriptions whose connection requests get automatically approved rather than landing in a pending state requiring manual review. A subscription can be visible-but-not-auto-approved (can request, needs manual approval) or, if not listed in visibility at all, can't even see or request a connection in the first place.

Does enableProxyProtocol work automatically once turned on, or does the backend need changes too?

The backend application needs to actually parse and honor the PROXY protocol header to make use of the real client IP information, simply enabling enableProxyProtocol on the Private Link service side prepends the header to the traffic, but a backend that isn't PROXY-protocol-aware will either ignore the header (seeing it as unexpected traffic, potentially causing a parsing error) or simply not extract the real client IP from it. Verify backend compatibility before enabling this in production.

Can a private endpoint connection request be revoked after it's been approved?

Yes, the Private Link service owner can change a privateEndpointConnections entry's status away from Approved (to Rejected, for instance) at any time, immediately cutting off that consumer's connectivity, this is a standing, revocable relationship, not a one-time approval that can't be undone, useful for cutting off access from a partner or team relationship that's ended.

Azure Private Link Service Builder

NetworkingAzure

Build Private Link service configs with load balancer frontend IPs, NAT IP configurations, visibility, and auto-approval settings.

Azure Private Link Configuration

Build Private Link service configs with load balancer frontend IPs, NAT IP configurations, visibility, and auto-approval settings.

Required Fields

nameresourceGrouplocationloadBalancerFrontendIpConfigurationsipConfigurationsipConfigurations[0].subnet

{
  "name": "pls-contoso-api",
  "resourceGroup": "rg-networking",
  "location": "eastus2",
  "loadBalancerFrontendIpConfigurations": [
    {
      "id": "/subscriptions/a1b2c3d4/resourceGroups/rg-networking/providers/Microsoft.Network/loadBalancers/ilb-api-prod/frontendIPConfigurations/fe-api"
    }
  ],
  "ipConfigurations": [
    {
      "name": "ipconfig-pls-primary",
      "privateIpAllocationMethod": "Dynamic",
      "subnet": {
        "name": "snet-private-link",
        "addressPrefix": "10.1.5.0/24"
      },
      "primary": true,
      "privateIpAddressVersion": "IPv4"
    }
  ],
  "visibility": {
    "subscriptions": [
      "b2c3d4e5-f6a7-8901-bcde-f23456789012",
      "c3d4e5f6-a7b8-9012-cdef-345678901234"
    ]
  },
  "autoApproval": {
    "subscriptions": [
      "b2c3d4e5-f6a7-8901-bcde-f23456789012"
    ]
  },
  "enableProxyProtocol": true,
  "fqdns": ["api.contoso.internal"],
  "privateEndpointConnections": [
    {
      "name": "pe-consumer-team-a",
      "privateLinkServiceConnectionState": {
        "status": "Approved",
        "description": "Approved by network admin"
      }
    }
  ],
  "tags": {
    "environment": "production",
    "service": "api-gateway",
    "team": "platform"
  }
}

Generated Output

Output will appear here...

About This Tool

Build an Azure Private Link service exposing an internal load balancer's frontend to other VNets/subscriptions privately, with visibility.subscriptions controlling which subscriptions can even see and request a connection, and the separate autoApproval.subscriptions list controlling which of those get auto-approved rather than landing as a pending request needing manual review. A subscription not listed anywhere in visibility can't discover or request a private endpoint connection to this service at all (assuming visibility isn't left fully open), while a subscription in visibility but not in autoApproval can request a connection but it sits pending until someone with sufficient permission on the Private Link service explicitly approves it, two genuinely different levels of access control that are easy to conflate.

When to Use This Tool

•Listing specific subscription IDs under visibility.subscriptions rather than leaving the service open to any subscription, so only pre-approved consumer subscriptions can even discover and request a private endpoint connection.
•Adding a subset of those visible subscriptions to autoApproval.subscriptions for trusted internal consumers (other teams within the same organization), while leaving external partner subscriptions in visibility-only so their connection requests require manual review before approval.
•Enabling enableProxyProtocol so the backend service behind the load balancer can see the original client's source IP address, since Private Link's NAT-based connectivity would otherwise obscure it, PROXY protocol support needs to be implemented on the backend to actually consume this information.
•Reviewing privateEndpointConnections periodically to confirm every Approved connection is still an intentional, currently-valid consumer relationship, since an old approved connection to a since-decommissioned consumer represents lingering, unnecessary private network access.

Pro Tips

TIP

Don't conflate visibility and autoApproval, a subscription needing manual-approval access still needs to be listed in visibility first, forgetting this means the subscription can't even request a connection, not just that it needs approval.

TIP

PROXY protocol only provides value if the backend actually parses it, verify backend compatibility (many common load balancers and web servers support it, but not universally) before enabling it and assuming client IP visibility is restored.

TIP

Periodically audit privateEndpointConnections for Approved entries that no longer correspond to an active, intended consumer relationship, a forgotten approved connection to a decommissioned partner integration is a standing private network access path nobody's actively reviewing.

How It Works Under the Hood

The builder validates that name, resourceGroup, location, loadBalancerFrontendIpConfigurations, ipConfigurations, and the first IP configuration's subnet all resolve before accepting the JSON as a valid Private Link service definition, the fields Azure needs to know which internal load balancer frontend to expose and through which subnet's NAT IP configuration; it can't verify the referenced load balancer frontend IP configuration actually exists or that listed visibility/autoApproval subscription IDs are valid, real subscriptions.

Frequently Asked Questions

What's the difference between a subscription being in visibility versus autoApproval?: visibility.subscriptions controls which subscriptions can even discover and request a private endpoint connection to this service at all, autoApproval.subscriptions is a subset of visible subscriptions whose connection requests get automatically approved rather than landing in a pending state requiring manual review. A subscription can be visible-but-not-auto-approved (can request, needs manual approval) or, if not listed in visibility at all, can't even see or request a connection in the first place.
Does enableProxyProtocol work automatically once turned on, or does the backend need changes too?: The backend application needs to actually parse and honor the PROXY protocol header to make use of the real client IP information, simply enabling enableProxyProtocol on the Private Link service side prepends the header to the traffic, but a backend that isn't PROXY-protocol-aware will either ignore the header (seeing it as unexpected traffic, potentially causing a parsing error) or simply not extract the real client IP from it. Verify backend compatibility before enabling this in production.
Can a private endpoint connection request be revoked after it's been approved?: Yes, the Private Link service owner can change a privateEndpointConnections entry's status away from Approved (to Rejected, for instance) at any time, immediately cutting off that consumer's connectivity, this is a standing, revocable relationship, not a one-time approval that can't be undone, useful for cutting off access from a partner or team relationship that's ended.

Related Learning Guides

Virtual Network Architecture28 min read
Azure Networking Deep Dive30 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.

Azure Private Link Service Builder

NetworkingAzure

Build Private Link service configs with load balancer frontend IPs, NAT IP configurations, visibility, and auto-approval settings.

Azure Private Link Configuration

Build Private Link service configs with load balancer frontend IPs, NAT IP configurations, visibility, and auto-approval settings.

Required Fields

nameresourceGrouplocationloadBalancerFrontendIpConfigurationsipConfigurationsipConfigurations[0].subnet

Generated Output

Output will appear here...

About This Tool

When to Use This Tool

•Listing specific subscription IDs under visibility.subscriptions rather than leaving the service open to any subscription, so only pre-approved consumer subscriptions can even discover and request a private endpoint connection.
•Adding a subset of those visible subscriptions to autoApproval.subscriptions for trusted internal consumers (other teams within the same organization), while leaving external partner subscriptions in visibility-only so their connection requests require manual review before approval.
•Enabling enableProxyProtocol so the backend service behind the load balancer can see the original client's source IP address, since Private Link's NAT-based connectivity would otherwise obscure it, PROXY protocol support needs to be implemented on the backend to actually consume this information.
•Reviewing privateEndpointConnections periodically to confirm every Approved connection is still an intentional, currently-valid consumer relationship, since an old approved connection to a since-decommissioned consumer represents lingering, unnecessary private network access.

Pro Tips

TIP

How It Works Under the Hood

Frequently Asked Questions

What's the difference between a subscription being in visibility versus autoApproval?: visibility.subscriptions controls which subscriptions can even discover and request a private endpoint connection to this service at all, autoApproval.subscriptions is a subset of visible subscriptions whose connection requests get automatically approved rather than landing in a pending state requiring manual review. A subscription can be visible-but-not-auto-approved (can request, needs manual approval) or, if not listed in visibility at all, can't even see or request a connection in the first place.
Does enableProxyProtocol work automatically once turned on, or does the backend need changes too?: The backend application needs to actually parse and honor the PROXY protocol header to make use of the real client IP information, simply enabling enableProxyProtocol on the Private Link service side prepends the header to the traffic, but a backend that isn't PROXY-protocol-aware will either ignore the header (seeing it as unexpected traffic, potentially causing a parsing error) or simply not extract the real client IP from it. Verify backend compatibility before enabling this in production.
Can a private endpoint connection request be revoked after it's been approved?: Yes, the Private Link service owner can change a privateEndpointConnections entry's status away from Approved (to Rejected, for instance) at any time, immediately cutting off that consumer's connectivity, this is a standing, revocable relationship, not a one-time approval that can't be undone, useful for cutting off access from a partner or team relationship that's ended.

Related Learning Guides

Virtual Network Architecture28 min read
Azure Networking Deep Dive30 min read

Was this tool helpful?