Azure Reference Network ArchitecturePDF version

Additional VNet scenarios

Learn more about the additional VNet scenarios that show how private endpoints can be configured between your workload environment and Cloudera Control Plane.

Scenario 1: Private endpoint in your egress VNet with no HTTP proxy
This scenario has the private endpoints in your egress VNet, allowing the private endpoints to be shared by multiple VNets in your network. In this setup, private endpoints receive IPs from egress VNet.
  • DNS overrides where DNS is a per-VNet view:
    • DNS override zones and records can be deployed in each workload environment VNet, or a single set of DNS override zones and records are deployed and the zones are associated with each workload environment VNet.
  • DNS overrides where DNS is a regional or global view:
    • The DNS override will have a regional or global impact to resolution of the Cloudera hostnames, clients in the region/globally will receive these private endpoints.
Scenario 2: Private endpoint in your egress VNet, HTTP proxy
Similar to scenario 1, except you have egress traffic flowing through an HTTP proxy in the egress VNet. In this setup, Private endpoints receive IPs from egress VNet.
  • DNS overrides:
    • Transparent proxy or egress firewall policy configurations may require the original destination IP to match the DNS resolution. If this is the case, the override zones/records/VNet associations can be deployed as described in scenario 1.
Scenario 3: Private endpoint in your workload environment VNet, HTTP proxy
Private endpoints deployed in your workload environment network. In this setup, private endpoints receive IPs from egress VNet.
  • DNS overrides where DNS is a regional or global view:
    • The overrides will impact resolution for clients elsewhere in the region and globally.
    • Traffic to these hostnames from outside this VNet will attempt to use these Private Endpoints, which may not be a desired configuration
  • HTTP forward proxy or non-transparent proxy
    • Workload environment will be configured to use an HTTP proxy profile.
    • The no_proxy configuration of the profile must include the hostnames of the APIs reachable through private endpoint. HTTP requests for destinations in the no_proxy list will not be forwarded to the proxy, local DNS and therefore the private endpoints will be used for that traffic