Copy page

Managed Dedicated

Managed Dedicated: Azure Private Networking

Zuplo Managed Dedicated can run on Azure and connect privately to backends that aren't exposed to the public internet. This includes Azure Container Apps, Azure App Service, AKS, and internal services that are only reachable inside your Azure network.

This page focuses on customer-facing requirements and the common Azure patterns used to connect Zuplo to private backends.

When to use this

Azure private networking is a good fit when you need to:

• Keep your backend off the public internet while still using Zuplo as the public API entry point
• Connect Zuplo to Azure Container Apps or App Service using private access
• Reach services that are only available inside your Azure Virtual Network (VNet)
• Meet internal security or compliance requirements around network isolation

Azure connectivity options

Azure uses VNet peering, not VPC peering.

The two most common patterns are:

1. Private Endpoint

This is usually the preferred option when your backend supports Azure Private Link.

Typical use cases:

• Azure Container Apps
• Azure App Service
• Azure SQL
• Azure Storage
• Azure Key Vault

Why teams choose this pattern:

• Access is scoped to a specific service instead of an entire network
• It is easier to review from a security perspective
• It avoids broader Layer 3 connectivity between VNets when you only need private access to a specific service
• Your wider VNet does not need to be exposed to Zuplo

2. VNet peering

This is the right option when your backend is only reachable on private IP addresses inside your VNet, or when Zuplo needs access to multiple internal services.

Typical use cases:

• Internal load balancers
• Private AKS services
• Self-managed applications reachable only inside a VNet
• Hub-and-spoke Azure network designs

Why teams choose this pattern:

• Zuplo can reach internal services that are not exposed through Private Link
• It works well for broader private connectivity needs
• It fits existing enterprise Azure network topologies

Azure Container Apps

Yes, Zuplo can connect to Azure Container Apps that are restricted to private networking.

The pattern depends on how your environment is configured:

• If your Container Apps environment uses Private Endpoint, Zuplo connects through Private Link and private DNS
• If your Container Apps environment is internal and your app is reachable only on private IPs inside your VNet, Zuplo connects through VNet peering

Important details for Container Apps:

• The private endpoint is created on the managed environment, not on an individual container app
• If you use an internal Container Apps environment, DNS must resolve the environment's private address correctly
• If you use app ingress set to Internal, that traffic is limited to the same Container Apps environment. For private access from outside that environment, use VNet-reachable ingress with the correct DNS setup

This lets you keep Azure Container Apps private while still presenting a public API through Zuplo.

What is required from your side

The exact setup depends on your Azure design, but most projects need:

• The Azure region or regions where Zuplo should run
• The target service details, such as the VNet, resource ID, or Private Endpoint-enabled service
• A DNS plan for private name resolution
• Network approval for peering or Private Endpoint connections
• Non-overlapping CIDR ranges if VNet peering is used

If your team manages Azure through Terraform, Zuplo can work within that model. The ownership split depends on your environment and security model.

DNS requirements

Private connectivity on Azure depends on DNS as much as it depends on routing.

For private connectivity to work, Zuplo needs to resolve your backend to the correct private address. That usually means one of the following:

• Linking the relevant Azure Private DNS zone to every VNet that needs to resolve the private service
• Forwarding DNS through your existing Azure DNS architecture
• Using your shared DNS resolver strategy

Common examples include:

• privatelink.azurewebsites.net for Azure App Service private endpoints
• privatelink.{region}.azurecontainerapps.io for Azure Container Apps private endpoints
• The Container Apps environment's own private DNS zone when you use an internal environment

Without the correct DNS configuration, the network path can exist while traffic still resolves to the public endpoint.

Planning considerations

Before implementation, align on:

• Whether Private Endpoint or VNet peering is the better fit
• Which environments need private connectivity, such as production only or both production and non-production
• CIDR planning for any peered VNets
• Which team owns the Azure networking changes
• Whether the connection should be provisioned through Terraform

Recommendation

In most Azure environments:

• Use Private Endpoint when the backend supports it, especially for Azure PaaS services where you only need private access to a specific service
• Use VNet peering when the backend is only reachable on private IPs inside your VNet or when Zuplo needs broader private connectivity into your Azure network

In practice, Private Endpoint is usually the cleaner fit for Azure Container Apps and App Service. VNet peering is usually the better fit for internal load balancers, private AKS services, or broader VNet-to-VNet connectivity.

If you are evaluating Zuplo for a private Azure workload, those are the two patterns to expect.

Next steps

• Review the general Managed Dedicated networking overview
• Review Managed Dedicated architecture
• Schedule time with Zuplo to review your Azure network design