Conceptual scenario
Different clouds. One private working environment.
Keep compute where it makes sense for your business. Plan approved private connections between supported cloud hosts and office resources, across the providers you already use.
Explore Networks ↗A worked planning example, not a customer case study or a released installation procedure.
A hybrid environment
A build worker in one cloud. A service in another.
An engineering team runs a build worker with one hosting provider and a private test service with another. Its release files remain on an office server. Developers work from several locations. The team needs specific private paths between these resources, without publishing the test service or moving everything to one provider.
Private path
A working environment across providers
- Cloud A worker
- Approved private path
- Cloud B service
- People
- Enrolled devices across working locations
- Office
- Separately approved gateway route
- Boundary
- Application credentials stay with the service
One logical network does not automatically connect every VPC or subnet.
The workload dependency
Connect the worker to the service it needs.
The Cloud A worker is supported enrolled compute with an approved service identity. Its intended destination and access group define the relationship to the Cloud B test service.
- At the source
- Check the worker’s enrollment, approved scope and outbound restrictions with its engineering owner.
- At the destination
- Retain the test service’s application credentials, provider security groups and host firewall controls.
- Across providers
- Measure the real workload’s latency and throughput. Provider egress charges still apply.
A separate office dependency
Release files stay on site.
A supported office gateway can add a separately approved path to the file server. Agree the destination range and verify the return route with the site owner.
Separate working identities
Developers have their own grants.
Engineers join through individually enrolled computers. Their resource grants are separate from the worker’s service access.
Conceptual planning example · No automatic cloud integration or direct peer-to-peer topology is implied.
Resource plan
Connect the workload, then assess the wider network.
Start with supported enrolled hosts. Keep an owner on every resource and agree the intended access before adding a route.
- Build worker
- Engineering
Engineering owns the supported compute host and its enrollment. It needs the test service, not general access to every cloud resource.
- Test service
- Application owner
The application owner retains authentication, service credentials and host firewall controls. Private reachability does not replace those controls.
- Office files
- Site owner
The site owner operates the file server and any supported gateway. A private route is approved for the intended destination range.
- Working devices
- Individual engineers
Engineers join through individually enrolled computers. Their resource grants are separate from the worker’s service access.
A joined virtual machine does not join its entire VPC.
If a whole subnet must be reachable, assess a gateway, destination ranges, overlapping addresses and return routing separately. A supported enrolled host and an approved subnet route are different deployment decisions.
Review deployment options before extending this host-to-service plan to a wider network.
Across providers
Keep the placement. Make the connections deliberate.
The private network model sits over the existing internet connections. It does not provide a dedicated cloud interconnect or imply a cloud-provider partnership.
- Provider and host controls
- Provider security groups, host firewalls and outbound restrictions still apply. Check the intended service listener and application authentication alongside the network grant.
- Addresses and return routes
- Resolve overlapping address ranges before approving gateway routes. Verify destination scope and the return path; enrolling one VM does not establish routes to neighbouring cloud resources.
- Private resource names
- Private workspace DNS can help supported clients find internal resources. Confirm which service owns each name and which clients resolve it. Name resolution does not grant application access.
- Transfer costs and workload fit
- Provider egress charges still apply. Select service locations with application latency and data-transfer needs in mind, and measure the actual worker-to-service workload.
The application operating plan
A private path carries the connection. The workload still needs its own recovery plan.
A private path can support application calls, administrative access or a controlled migration workflow. It does not provide data replication, database consistency, backup scheduling or disaster recovery. Those remain application and operating decisions.
Before expanding
Three results worth recording.
Evaluate the real service, the resource beside it and the end of access. Keep the observed result with the policy and provider configuration used for the test.
Approved application path
The worker reaches the intended test service, and the service’s own authentication is exercised. Record latency and throughput for this workload rather than assuming them from the network model.
Denied neighbouring resource
A resource outside the approved scope remains inaccessible. Review both policy and provider/local firewall behaviour.
Removal and recovery
Withdraw a grant or approved route, verify the observed result and retain a separate administrative recovery path. Restore only the intended scope.
Confirm the supported deployment.
Automated site-to-site orchestration, full-mesh routing, high availability and worldwide backbone coverage are not established by this example. Supported endpoint, gateway and market combinations must be verified for the deployment. Review current availability and the cloud infrastructure plan for the wider operating context.
Continue with the private connection model or work through the separate office dependency.