Access to non Azure DC

Question

Access to non Azure DC

Rachna R Rai1 20

I have a sandbox environment hosted in Azure, within an XYZ tenant. This uses co-pilot studio in Azure power platform. There is another tenant CCC that has connectivity to Express route via which we have existing connectivity to a non azure DC via private links. I need the sandbox in Azure XYZ tenant to go via Currys tenant over to the non azure DC using private IPs only. Currently sandbox uses public IPs. How can this work ?

Would private endpoints be needed?

Rachna R Rai1 20 Reputation points

2026-03-16T19:44:20.0066667+00:00

There are no services to be consumed in CCC.
Venkatesan S 9,055 Reputation points Microsoft External Staff Moderator

2026-03-17T18:00:53.48+00:00

Hi Rachna R Rai1,

We haven’t heard back from you regarding our last response and wanted to check if you had the opportunity to review our previous post.

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Rachna R Rai1 20 Reputation points

2026-03-17T18:19:15.68+00:00

Hi Venkatesan, I did give a thumbs up on your previous response you sent this morning.

One last question though. So for the scenario that I've given, we do not need any private endpoints setup, is that right? Just a private IP from the Azure VNET that we integrate with Co-pilot & this IP will be the source connecting to the target non-Azure DC's private IP. Is that understanding correct?
Venkatesan S 9,055 Reputation points Microsoft External Staff Moderator

2026-03-17T18:28:09.4966667+00:00

Hi Rachna R Rai1,

Updated in answer.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer accepted by question author

Venkatesan S 9,055 Microsoft External Staff Moderator

Hi Rachna R Rai1,

Thanks for reaching out in Microsoft Q&A forum,

Currently sandbox uses public IPs. How can this work ?Would private endpoints be needed?

To enable private IP-only connectivity from your XYZ tenant's Copilot Studio sandbox to the non-Azure DC via CCC's ExpressRoute, use cross-tenant VNet peering combined with Copilot's VNet integration. These routes traffic privately without public IPs or private endpoints (since no Azure PaaS services are involved in CCC).

Steps:

Follow these steps to build the private path:

VNet-Enable Copilot Studio in XYZ Deploy a dedicated VNet/subnet in XYZ for your sandbox environment. Configure the Copilot Studio/Power Platform environment for VNet isolation so outbound calls use that subnet's private IPs.
Prepare Cross-Tenant Permissions
- In CCC tenant: Invite an XYZ admin as a guest user and assign Network Contributor role on the CCC hub VNet (the one connected to ExpressRoute).
- In XYZ tenant: Invite a CCC admin as a guest user and assign Network Contributor on the XYZ VNet. This enables peering initiation across tenants.
Set Up Global VNet Peering
- From XYZ VNet: Peer to CCC's hub VNet (ExpressRoute-attached). Enable Use remote gateways.
- From CCC hub VNet: Peer back to XYZ VNet. Enable Allow gateway transit and allow forwarded traffic. Traffic from XYZ now uses CCC's ER gateway to reach on premises.
Routing Configuration
- In XYZ subnet route table: Add UDR for on-premises prefixes (e.g., 10.0.0.0/8) pointing to next hop = Remote gateway (CCC peering).
- Ensure on-premises BGP advertises routes back for return traffic.
DNS for Private Resolution
- Set XYZ VNet DNS to Azure Private DNS or on-premises DNS servers (reachable via ER).
- Create conditional forwarders so DC hostnames resolve to private IPs.

Update:

One last question though. So for the scenario that I've given, we do not need any private endpoints setup, is that right? Just a private IP from the Azure VNET that we integrate with Co-pilot & this IP will be the source connecting to the target non-Azure DC's private IP. Is that understanding correct?

Yes, correct no private endpoints needed.

Copilot Studio VNet integration gives you private source IPs from XYZ VNet > routes via peering/ExpressRoute > non-Azure DC private IP destination. Standard IP routing works fine.

Reference:

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Rachna R Rai1 20 Reputation points

2026-03-17T18:46:02.69+00:00

Thank you for the guidance.

1 additional answer

Your answer

Rachna R Rai1 20 Reputation points

2026-03-16T19:44:20.0066667+00:00

There are no services to be consumed in CCC.
Venkatesan S 9,055 Reputation points Microsoft External Staff Moderator

2026-03-17T18:00:53.48+00:00

Hi Rachna R Rai1,

We haven’t heard back from you regarding our last response and wanted to check if you had the opportunity to review our previous post.

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Rachna R Rai1 20 Reputation points

2026-03-17T18:19:15.68+00:00

Hi Venkatesan, I did give a thumbs up on your previous response you sent this morning.

One last question though. So for the scenario that I've given, we do not need any private endpoints setup, is that right? Just a private IP from the Azure VNET that we integrate with Co-pilot & this IP will be the source connecting to the target non-Azure DC's private IP. Is that understanding correct?
Venkatesan S 9,055 Reputation points Microsoft External Staff Moderator

2026-03-17T18:28:09.4966667+00:00

Hi Rachna R Rai1,

Updated in answer.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Rachna R Rai1 20 Reputation points

2026-03-17T18:46:02.69+00:00

Thank you for the guidance.

Answer 1

Yes, private endpoints (via Azure Private Link) are the right pattern, but they must be combined with cross-tenant networking and DNS so that traffic from the XYZ sandbox reaches the non-Azure DC only over private IP paths.

At a high level, the design is:

The non-Azure DC is already reachable privately from tenant CCC via ExpressRoute.
Tenant CCC exposes the needed services (for example, an app, database, or API that fronts the DC) via Private Link/private endpoints into a virtual network in tenant CCC.
Tenant XYZ (the sandbox tenant) connects to those services in tenant CCC using cross-tenant Private Link and DNS, so that all traffic from the sandbox to the DC flows:
- Sandbox VNet (tenant XYZ) -→ Private endpoint in tenant XYZ -→ Private Link to service/VNet in tenant CCC -→ ExpressRoute to non-Azure DC

No public IPs are required on the data path.

Concrete building blocks and how they fit together:

Use Private Link and private endpoints for private ingress
- A private endpoint is a NIC in a VNet that gets an IP from that VNet and provides private ingress to a PaaS or custom service.
- The client (sandbox) talks to a DNS name that resolves to the private endpoint IP; traffic stays on the Microsoft backbone and does not use public IPs.
- This is the same pattern described for securely exposing an App Service or Function across tenants, but the target in tenant CCC can be whatever service is already connected to the non-Azure DC.
Cross-tenant Private Link pattern
- In the provider tenant (CCC):
  - Host the service that has connectivity to the non-Azure DC (for example, an API, web app, or other endpoint that uses the DC over ExpressRoute).
  - Secure that service with a private endpoint in a VNet that is already on the ExpressRoute path.
  - Configure DNS for that private endpoint (typically using a private DNS zone such as privatelink.<service-domain> and linking it to the provider VNet).
- In the consumer tenant (XYZ sandbox):
  - Create a private endpoint that targets the provider’s service in tenant CCC (cross-tenant Private Link).
  - Place this private endpoint in the sandbox VNet.
  - Configure DNS so that the sandbox resolves the service FQDN to the private endpoint IP in the sandbox VNet.
DNS requirements so only private IPs are used
- The client in the sandbox must resolve the service name to the private endpoint IP, not to any public IP.
- Typical approach in the consumer (XYZ) tenant:
  - Create the appropriate private DNS zone (for example, privatelink.azurewebsites.net if the provider is an App Service) and link it to the sandbox VNet.
  - Associate the private endpoint with that private DNS zone so an A record is created for the service FQDN.
- With this in place, the sandbox VM or app resolves the name to a private IP and sends traffic over the private endpoint/Private Link path.
Why private endpoints are needed in this scenario
- The requirement is “private IPs only” from the sandbox to a resource that ultimately lives behind ExpressRoute in another tenant.
- Private endpoints provide:
  - A private IP in the sandbox VNet for the remote service.
  - A private link path that does not traverse the public internet.
  - A way to do cross-tenant connectivity without VNet peering or site-to-site VPN between tenants.
- This matches the documented pattern for cross-tenant secure access to PaaS services using private endpoints.
Connection and lifecycle management
- The provider tenant (CCC) must approve the private endpoint connection from the consumer (XYZ) before it becomes active.
- Either side can later delete the connection; it cannot be paused. If deleted, a new private endpoint must be created to restore connectivity.

In summary: configure the non-Azure DC–connected services in tenant CCC as Private Link–enabled endpoints, then consume them from the XYZ sandbox via cross-tenant private endpoints and private DNS. This ensures all traffic from the sandbox to the DC uses private IPs only, with no public IP exposure.

References:

Share via

Access to non Azure DC

1 additional answer

Your answer