Enable End-to-End Private Consumption of SaaS and Public Services from AWS, GCP, and Azure

Many large Infrastructure as a Service (IaaS) providers offer solutions such as storage, databases, and other service APIs that can be accessed from the internet. Relying on these public services for your application increases the threat of data exfiltration and expands the attack surface of your application. 

You can reinforce your security by isolating access to these services from the internet and making them accessible only via a private network. To facilitate the consumption of their services privately, IaaS providers have started offering features such as Private Endpoints, Private Links, and Private Services Connect. These features provide secure, private connections for customers to access their cloud services and ensure that traffic is kept within a private network. 

CloudConnexa makes access to these newly-private Platform as a Service (PaaS) services easier by routing to these private endpoints by domain name; it also enhances security by adding another layer of access control to these services. CloudConnexa can be used to extend these private services to on-prem data centers, between different IaaS environments, or directly to users.

CloudConnexa makes access to these newly-private PaaS services easier by routing to these private endpoints by domain name; it also enhances security by adding another layer of access control to these services.

Public PaaS Offerings

Infrastructure as a Service (IaaS) providers like Azure, Google Cloud Platform (GCP), and Amazon Web Services (AWS) offer many services that fall within the Platform as a Service (PaaS) category (for example, Azure Storage and SQL Database). While these services can be directly accessed from the internet, the IaaS providers also provide features to bring these PaaS services into your virtual private cloud network for added security and control.

Private Access Within Virtual Private Cloud Networks

Different IaaS providers use different terminology and setup methods, but a common framework is used by these IaaS providers to make their services privately accessible from within your Virtual Private Cloud (VPC). The framework, at a high level, consists of:

  1. A private endpoint.
  2. The private service feature.
  3. DNS setup.
  4. Approvals.
  5. Access Controls.

1) Private Endpoint

A private endpoint is a network interface that uses a private IP address from your VPC. This network interface connects that VPC privately and securely to services. Private endpoints allow the resources in your VPC to connect to PaaS services, third-party SaaS services, and services in your other VPCs as if those services were hosted directly in that VPC. Traffic between your VPC and the services accessed via the private endpoint traverses the IaaS provider’s network, eliminating exposure from the public Internet.

2) The Private Service Feature

The services made accessible via the private endpoint vary. Not everything offered by the IaaS provider is accessible privately via the endpoint. The private service feature performs Network Address Translation (NAT) and forwards the data traffic received at the private endpoint to the target service. The target service could be one of the PaaS services offered by the IaaS provider, a service developed by you in another VPC, or a service offered by a third-party Marketplace partner. This feature can also be used to publish and share your service with other customers of the IaaS provider. The target services, terminology, and functionality of the private service feature differ based on the IaaS provider. A quick summarization follows:


AWS calls its private endpoint a ‘VPC Endpoint,’ and the technology that enables customers to privately connect their VPC to services is referred to as ‘AWS PrivateLink.’ The AWS services that are made accessible by PrivateLink are listed here.

AWS PrivateLink not only provides private access to AWS services but can also be used to access services hosted by AWS Marketplace partner service providers. Customers can also make their applications available to other AWS customers using PrivateLink.


Azure calls its feature ‘Azure Private Link.’ The services available are the destination target of a specified private endpoint. Similar to AWS, Azure Private Link can also be used to deliver a customer-developed service to other Azure customers.


GCP has a feature that allows private consumption of services across VPC networks that belong to different groups, teams, projects, or organizations. This is called ‘Private Service Connect.’ The private endpoint is called ‘Private Service Connect endpoint.’ It also allows one to publish and consume services. Private Service Connect can be used to access Google APIs and services, managed-services in another VPC network, and provide others access to services hosted in a VPC.

3) DNS

Now that a private endpoint has been created and the private service has been used to map it to a target service, the private endpoint needs to be used for communication. It is common to create a DNS record that maps a private name (e.g., cloudkms.example.com for target service asia-east1-cloudkms.googleapis.com) to the private IP address of the private endpoint used for the target service. The DNS record can be created using Amazon Route 53 hosted zone; Cloud DNS can be used for GCP. For Azure, existing Microsoft Azure services might already have a DNS configuration for a public endpoint. This configuration must be overridden to connect using your private endpoint.

Once DNS is configured, your applications can start using the private service by calling the API endpoint using the private API name (e.g., cloudkms.example.com) instead of the public API name (e.g., cloudkms.googleapis.com)

4) Approvals

As noted in the description of the various private service features, the services consumed can also belong to other third-party service providers or your own service in another account. The method to receive or grant access to such services typically works on an approval model where the service consumer can request a connection to the service provider to consume the service. The service provider can then decide whether to allow the consumer to connect. See, Azure reference, AWS reference, GCP reference.

5) Access Controls

In the IaaS platforms, you can use firewalls, ACLs, security groups, and other access control means to provide only authorized access to the services brought into the VPC using private endpoints. In AWS, when you create an interface endpoint or a gateway endpoint, you can attach an endpoint policy. The endpoint policy controls who/what can use the VPC endpoint to access the endpoint service.

Private endpoints provide a privately accessible IP address for the Azure service but do not necessarily restrict public network access. Azure App Service and Azure Functions become inaccessible publicly when they are associated with a private endpoint. All other Azure services require additional access controls, however.

Extending Reach and Simplifying Security Using CloudConnexa

CloudConnexa can extend the reach of those PaaS services that are now available for private access through your VPC to on-prem private networks and applications servers, resources in a different IaaS VPC, or end users.

How CloudConnexa Makes It Simple

CloudConnexa allows you to set up DNS such that your private DNS servers can be used. Therefore, if you used AWS, GCP or Azure to set up private DNS zones for naming your private endpoint, you can just set CloudConnexa DNS to use those DNS Servers. CloudConnexa allows you to quickly set up a DNS record using the Administration portal. If all access to the private service is going to be via CloudConnexa, you can just configure the DNS record right in CloudConnexa.

CloudConnexa makes routing to private services and APIs simple by not basing the routing decisions on IP addresses. Instead, CloudConnexa routes to the correct connected network based on application domain names. You just connect your cloud private networks by deploying lightweight VM(s) running Connector software and then configure Applications using the domain names assigned to the private endpoints. Routing remains accurate even if the private IP address of a private endpoint is the same as that of another in a different network.

CloudConnexa makes routing to private services and APIs simple by not basing the routing decisions on IP addresses. Instead, CloudConnexa routes to the correct connected network based on application domain names.

Access Controls can be applied to individual servers (Hosts), connected networks (even IP address subnets within those networks), and User Groups. This allows you to simply authorize the Hosts, sites (or subnets within a site network), or Users that get access to the Applications that are offered via the private endpoints.

For maximum security, you can configure a Host, Network or a User Group such that the only access it has is to the services offered by the private endpoints. Attempts to access any other service, even public services from the internet, will be denied.

Using CloudConnexa to Access AWS/GCP/Azure Services and APIs Privately From Other Networks

For example, let’s say that multiple servers running on your on-prem network need access to AWS Lambda functions. You have created an interface VPC endpoint, in your AWS VPC, to invoke your Lambda function without crossing the public internet. As shown in the illustration, you can use CloudConnexa to provide private access to those Lambda functions by installing Connectors on your private network and the AWS VPC. Both networks will connect to an CloudConnexa Region (one of 30+ worldwide Regions) that is in close geographic proximity. Any traffic destined to the domain name of the interface VPN endpoint will be routed to the AWS VPC, achieving completely private communications from the on-prem network to the needed Lambda function running on AWS.

Quick Steps to Use CloudConnexa

  1. Add a Network and deploy Connector(s) in the VPC where the private endpoint is configured.
    • Add Applications with the domain names of the private endpoints in the above Network. Note that the IP address subnet of the VPC is not needed for routing. In keeping with ZTNA principles, the needed applications are exposed, not the entire VPC network.
    • If the DNS servers or private zones within the VPC need to be used, add a Route only to the IP addresses of the DNS servers.
  2. Configure DNS servers to use the private hosted zone configured in IaaS provider, or add DNS record for the private endpoints IP addresses in CloudConnexa.
  3. Add other on-premise or cloud private networks as Networks, and deploy Connectors to give them access.
    • As these networks will be originating the API calls, add the IP subnets from which the requests will originate to the Route. You can also add IP Services (with 'Use as Source' toggled ON) if you want to limit access from a specific subnet to one or more Applications on the VPC.
  4. Configure Access Groups to limit access to the configured Applications.

On carrying out the above setup, you will notice that only the Lambda functions are accessed through CloudConnexa. Traffic to the internet does not use CloudConnexa.

Figure 1. Private access to PaaS services from on-prem network

Using CloudConnexa to Access AWS/GCP/Azure Services and APIs Privately From Application Servers

We looked at how to provide access to the PaaS Applications from a network in the previous section. But what if you want to limit your risk exposure and directly provide access to only those application servers that need it without connecting the entire network to CloudConnexa? You can achieve this by installing the Connector on the application server that needs private access to PaaS applications. The application server (Host) creates an unattended connection to CloudConnexa. You can also configure the ‘Internet Access’ setting of the Host to ‘Restricted Internet’ in order to block all direct internet access from the application server. All the internet traffic from the application server is channeled through CloudConnexa, and only authorized and configured Applications and IP Services are made accessible.

Want to limit your risk exposure and directly provide access to only those application servers that need it without connecting the entire network to CloudConnexa? Install the Connector on the application server that needs private access to PaaS applications.

Quick Steps to Use CloudConnexa

The steps to add the VPC Network, configure Applications, and DNS servers remain the same as in the prior section. Instead of adding other on-premise or cloud private networks, the application server is added as a Host. The Host can then be used in configuring Access Groups.

Figure 2. Private access to PaaS services from an application server

Using CloudConnexa to Access SaaS and AWS/GCP/Azure Services Privately From User Devices

Some IaaS providers have enabled private access to SaaS products sold via their Marketplaces using the same private service feature as the one used with their own services. For example, AWS PrivateLink can be used to access SaaS products. Now, in order to extend private access to these SaaS services or even PaaS services to your workforce, you can use CloudConnexa. Users install the client application on their mobile and desktop devices, authenticate, and select the CloudConnexa Region closest to them. CloudConnexa provides SSO using SAML and LDAP. User Groups can be created to map the user’s role or department received from SAML and LDAP. These User Groups can, in turn, be used in Access Groups to authorize users' access to specific private services and SaaS applications.

Figure 3. Private access to PaaS services for end users

Get Started

OpenVPN® is the market-proven leader in secure virtualized networking. Our cloud-based platform enables organizations to maintain secure communication between their distributed workforce, IoT/IIoT devices, and the online services they rely on daily. Built on the market-proven OpenVPN protocol, the solution combines advanced network security, encrypted remote access, and content filtering into a virtualized secure network that provides the best of VPN and ZTNA security.

With over 60 million downloads of our core open-source software and over 20,000 commercial customers, OpenVPN is recognized as a global leader in secure networking.

Ready to take your business to the next level with CloudConnexa? Create an account today to get the network connectivity and security your business needs.

Share this story: