Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
These sections contain information about private connectivity options from Immuta to various data platforms and APIs.
AWS PrivateLink provides private connectivity from the Immuta SaaS platform to Redshift clusters hosted on AWS. It ensures that all traffic to the configured endpoints only traverses private networks.
This feature is supported in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
You have an Immuta SaaS tenant.
You have set up an for your Redshift Cluster endpoints.
When creating the service, make sure that the Require Acceptance option is checked (this does not allow anyone to connect, all connections will be blocked until the Immuta service principal is added).
Open a support ticket with with the following information:
AWS region
AWS subnet availability zones IDs (e.g. use1-az3; these are not the account-specific identifiers like us-east-1a or eu-west-2c)
VPC endpoint service ID (e.g., vpce-0a02f54c1d339e98a)
Ports used
Authorize the service principal provided by your representative so that Immuta can complete the VPC endpoint configuration.
Immuta SaaS supports two different kinds of private networking:
Data connection private networking: Enables private connectivity from the Immuta SaaS network and a user's data platforms or private APIs over either AWS PrivateLink or Azure Private Link. This is useful for organizations with security and compliance policies that require that their data platforms and APIs are not routable over the public internet (even with a firewall in place).
Immuta SaaS private networking (public preview): Enables private connectivity from a user's network to an Immuta SaaS tenant. It will require Immuta SaaS users to connect over a private endpoint. This is useful for organizations with security and compliance policies that require that the SaaS applications they use are not publicly accessible.
A simple way to understand the difference between these two features: Data connection private networking is outbound from Immuta to an organization's data sources, where the organization creates the private service endpoint for Immuta SaaS to connect to. Immuta SaaS private networking is inbound to Immuta from an organization's network, where Immuta creates the private service endpoint for users to connect to.
Having one type of private networking enabled does not mean that the other is configured automatically. The two features perform different operations and use different networking interfaces that are configured independently.
Although AWS PrivateLink and Azure Private Link differ in their implementation details, they are fundamentally similar offerings. Organizations can expose private services on AWS or Azure networks that Immuta SaaS can establish a connection to. How this is done can vary significantly by both data platform and hosting cloud provider, which is why this documentation has been broken down into specific instructions for each combination in the support matrix below.
Over time, the breadth and depth of private networking support will continue to grow. If there are specific data platforms and/or cloud providers that you require, which are either not listed or not yet supported, please contact your Immuta representative.
Immuta SaaS's global network is divided into large geographic regions called . All Immuta SaaS tenants are deployed into an AWS region inside their chosen segment.
Occasionally, it may be required to connect to data sources outside of a specific region. To meet those needs, Immuta SaaS supports both cross-region and cross-global-segment connectivity.
This involves connecting to data sources in a different region within a given global segment.
Examples
a tenant in us-east-1 needs to connect to a Snowflake account in AWS'sus-east-2 region.
a tenant in us-west-2 needs to connect to an Azure Databricks workspace in the westus2 region.
This involves connecting to data sources in a region outside of the tenant's global segment.
Examples
a tenant in the EU Global Segment needs to connect to a Snowflake account in us-east-2.
a tenant in the AP Global Segment needs to connect to a Starburst instance hosted in Azure's eastus2 region.
Currently, Immuta SaaS Private Networking only supports the Governance app. Support for private networking to the Marketplace app is coming soon.
The fundamental mechanism that underlies Immuta SaaS private networking is an Immuta SaaS private endpoint service (e.g. an ) which organizations can establish a connection to via a private endpoint (e.g. an ).
Once the endpoint-service connection is established, organizations then configure DNS resolution in their network to resolve their governance private FQDN (e.g.<tenant>.privatelink.immutacloud.com) to their private endpoint. Organizations can continue to access their Immuta SaaS tenants using their standard governance FQDN (e.g. <tenant>.hosted.immutacloud.com), which will now automatically resolve to their private FQDN.
As with data connection private networking the specifics of configuring Immuta SaaS private networking can vary by the cloud provider the source network is hosted on. Please consult the support matrix below for specific instructions.
This section contains information about private connectivity options for Databricks integrations.
The Immuta SaaS platform supports private connectivity to and the . This allows organizations to meet security and compliance controls by ensuring that traffic to data sources from Immuta SaaS only traverses private networks, never the public internet.
Support for AWS PrivateLink is available in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
Support for Azure Private Link is available in all Databricks-supported Azure regions.
Amazon RDS/Aurora PostgreSQL
N/A
Amazon S3
Generally available
N/A
AWS Lake Formation
Private preview
N/A
Amazon API gateway
N/A
Azure Synapse Analytics
N/A
Not yet supported
Snowflake
Databricks
Starburst (Trino)
Amazon Redshift
N/A
AWS PrivateLink
Azure Private Link
Not yet supported
This section contains information about private connectivity options for Snowflake integrations.
The Immuta SaaS platform supports private connectivity to Snowflake accounts hosted in both AWS and Azure. This allows organizations to meet security and compliance controls by ensuring that traffic to data sources from Immuta SaaS only traverses private networks, never the public internet.
Support for AWS PrivateLink is available in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
Support for Azure Private Link is available in .
AWS PrivateLink provides private connectivity from the Immuta SaaS platform to Starburst (Trino) Clusters hosted on AWS. It ensures that all traffic to the configured endpoints only traverses private networks.
This feature is supported in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta account manager if you have questions about availability.
provides private connectivity from the Immuta SaaS platform, hosted on AWS, to Azure Databricks accounts. It ensures that all traffic to the configured endpoints only traverses private networks over the Immuta Private Cloud Exchange.
This front-end Private Link connection allows users to connect to the Databricks web application, REST API, and Databricks Connect API over an Azure Private Endpoint. For details about Azure Private Link for Databricks and the network flow in a typical implementation, explore the .
Support for Azure Private Link is available in .
Ensure that your accounts meet the following requirements:
This section contains information about private connectivity options for Immuta SaaS applications.
Immuta SaaS applications support private connectivity from customer networks. This allows organizations to meet security and compliance controls by ensuring that no users can access these endpoints outside of their internal networks.
This section contains information about private connectivity options for Starburst (Trino) integrations.
The Immuta SaaS platform supports private connectivity to Starburst (Trino) clusters hosted in both AWS and Azure. This allows organizations to meet security and compliance controls by ensuring that traffic to data sources from Immuta SaaS only traverses private networks, never the public internet.
Support for AWS PrivateLink is available in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
Support for AWS PrivateLink is available in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
Support for Azure Private Link is available in all Azure regions.
Your Starburst (Trino) Cluster is hosted on AWS.
You have set up an AWS PrivateLink Service for your Starburst Cluster endpoints.
When creating the service, make sure that the Require Acceptance option is checked (this does not allow anyone to connect; all connections will be blocked until the Immuta Service Principal is added).
Only TCP connections over IPv4 are supported.
Your Starburst (Trino) cluster endpoints are secured with TLS certificates for encryption in-transit.
The presented certificate must have the Fully-Qualified Domain Name (FQDN) of your cluster hostname as a Subject Alternative Name (SAN). This can either be a wildcard (e.g. *.example.com) or specific to the host (e.g. starburst.example.com)
The presented certificate must be issued from a publicly-trusted certificate authority (CA). Private CAs and/or internal top-level domains (TLDs) are not supported.
Open a support ticket with Immuta Support with the following information:
AWS region
AWS subnet availability zones IDs (e.g. use1-az3; these are not the account-specific identifiers like us-east-1a or eu-west-2c)
VPC endpoint service ID (e.g., com.amazonaws.vpce.us-east-1.vpce-svc-0471015b106ad1d47)
DNS hostname
This is the hostname of the cluster that will be used to ingest data sources. It must match the Common Name (CN) or a Subject Alternative Name (SAN) on your cluster's TLS certificate.
Ports used
provided by your representative so that Immuta can complete the VPC endpoint configuration.
.
.
You have an Immuta SaaS tenant.
Your Azure Databricks workspace must be on the Premium or Enterprise pricing tier.
Azure Private Link for Databricks has been configured and enabled.
You have your Databricks account ID from the account console.
Contact your Immuta representative, and provide the following information for each Azure Databricks Workspace you wish to connect to:
Azure region
Azure Databricks hostname
Azure Databricks resource ID or alias
Your representative will inform you when the two Azure Private Link connections have been made available. Accept them in your .
Configure Databricks depending on your integration type:
using your standard cloud.databricks.com workspace URL as the Host.
Configure the using your standard azuredatabricks.net URL. And using the privatelink-account-url from the JSON object in step one as the Server when registering data sources.
Your Snowflake account is hosted on Azure.
Your Snowflake account is on the Business Critical Edition.
You have ACCOUNTADMIN role on your Snowflake account to configure the Private Link connection.
Snowflake requires that an Azure temporary access token be used when configuring the Azure Private Link connection. Due to the constraint imposed by the 1-hour token expiration, your Immuta representative will ask for a time window in which you can accept the connection in your Snowflake account. During this window, the token will be generated by Immuta and provided to you when you're ready to run the following SQL query.
In your Snowflake environment, run the following SQL query, which will return a JSON object with the connection information you will need to include in your support ticket:
Copy the returned JSON object into a support ticket with Immuta Support to request for the feature to be enabled on your Immuta SaaS tenant.
Your Immuta representative will work with you to schedule a time in which to accept the connection in your Snowflake account. They will provide you with a SQL query to run using the ACCOUNTADMIN role. The SQL query will be in this format:
The query should return the following response: Private link access authorized.
using the privatelink-account-url from the JSON object in step one as the Host.
Azure Private Link provides private connectivity from the Immuta SaaS platform, hosted on AWS, to Starburst (Trino) clusters on Azure. It ensures that all traffic to the configured endpoints only traverses private networks over the Immuta Private Cloud Exchange.
Support for Azure Private Link is available in all Azure regions.
You have an Immuta SaaS tenant.
Your Starburst (Trino) cluster is hosted on Azure.
You have set up an for your Starburst cluster.
The Private Link Service's should be set to Restricted by Subscription.
Open a support ticket with with the following information:
Azure region
Azure Private Link service resource ID or alias
DNS hostname
AWS PrivateLink provides private connectivity from the Immuta SaaS platform to PostgreSQL database engines hosted on Amazon Aurora and Amazon RDS. It ensures that all traffic to the configured endpoints only traverses private networks.
This feature is supported in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
You have an Immuta SaaS tenant.
You have set up an for your Amazon Aurora/Amazon RDS endpoints.
When creating the service, make sure that the Require Acceptance option is checked (this does not allow anyone to connect, all connections will be blocked until the Immuta service principal is added).
Like all data connection private networking integrations that Immuta offers for AWS, the Amazon Aurora/Amazon RDS PrivateLink integration relies on a Network Load Balancer (NLB) that targets a private IP address - in this case, the private IP address of the Aurora/RDS instance. In a Multi-AZ configuration, the primary instance's private IP address changes during a failover event.
The NLB will not automatically detect this new IP address. Consequently, after an RDS failover, Immuta will be unable to connect to the database until the NLB's target group is updated with the new primary instance's private IP address.
To avoid the need for manual updates to your NLB configuration, you must implement an automated solution. A common approach is to use an AWS Lambda function that listens for RDS failover events and automatically updates the NLB target group with the new IP address. For a detailed guide on this automation, refer to the AWS blog post: .
Open a support ticket with with the following information:
AWS region
AWS subnet availability zones IDs (e.g. use1-az3; these are not the account-specific identifiers like us-east-1a or eu-west-2c)
select SYSTEM$GET_PRIVATELINK_CONFIG()SELECT SYSTEM$AUTHORIZE_PRIVATELINK (
'/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Network/privateEndpoints/abc12345.east-us-2.azure.snowflakecomputing.com-eus2',
'<ACCESS_TOKEN>'
);Your Immuta representative will provide you with the Immuta subscription ID that needs to be authorized to consume the service.
Once the Immuta Azure subscription is authorized, inform your representative so that Immuta can complete Private Link endpoint configuration.
Your representative will inform you when the two Azure Private Link connections have been made available. Accept them in the Private Link Center of your Azure Portal.
VPC endpoint service ID (e.g., vpce-0a02f54c1d339e98a)
Ports used
Authorize the service principal provided by your representative so that Immuta can complete the VPC endpoint configuration.
AWS PrivateLink provides private connectivity from the Immuta SaaS platform to API gateway endpoints hosted on AWS. It ensures that all traffic to the configured endpoints only traverses private networks.
This feature is supported in all regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
You have an Immuta SaaS tenant.
You have an .
Your private API must exist in .
to allow for access from the Immuta VPC endpoint in the applicable AWS region. The Immuta VPC endpoint IDs are listed in the table below.
Here is an example resource policy:
Once you have made changes to your resource policy, you must for the updates to take effect.
You should now be able to connect to your private API from your Immuta SaaS tenant using your API endpoint, i.e. <api-gateway-id>.execute-api.<region>.amazonaws.com/<stage>/<endpoint>.
If you get an error similar to the following:
Check to make sure that the following is true:
You have authorized the correct VPC endpoint for the region you are targeting in your resource policy.
Your resource policy allows for execute-api:Invoke privileges on the endpoint you are making requests to from Immuta.
You have deployed your API after making changes to your resource policy.
AWS PrivateLink provides private connectivity from the Immuta SaaS platform to Snowflake accounts hosted on AWS. It ensures that all traffic to the configured endpoints only traverses private networks.
This feature is supported in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
You have an Immuta SaaS tenant.
Your Snowflake account is hosted on AWS.
Your Snowflake account is on the .
You have ACCOUNTADMIN role on your Snowflake account to configure the Private Link connection.
You have enabled .
allow you to limit access to your Snowflake service endpoints. can be used with those network policies to define the specific IP CIDR blocks or AWS VPC endpoints that are allowed. Immuta supports both, but we highly recommend that you configure your network rules to reference our VPC endpoints and not our CIDR block.
With a network rule type of AWSVPCEID, you can use the following table of Immuta's VPC endpoints by AWS region to configure access from Immuta SaaS to your Snowflake service:
With a network rule type of IPV4, you must configure an IP address block of 10.0.0.0/8.
This size of block is required because traffic could come from anywhere in Immuta's network. Immuta has globally distributed compute and does not assign static IP addresses to any workloads. This is why you should use VPC endpoint network rules instead.
In your Snowflake environment, run the following SQL query, which will return a JSON object with the connection information you will need to include in your support ticket:
Copy the returned JSON object into a support ticket with to request for the feature to be enabled on your Immuta SaaS tenant.
using the privatelink-account-url from the JSON object in step one as the Host.
provides private connectivity from the Immuta SaaS platform to Databricks accounts hosted on AWS. It ensures that all traffic to the configured endpoints only traverses private networks.
This front-end PrivateLink connection allows users to connect to the Databricks web application, REST API, and Databricks Connect API over a VPC interface endpoint. For details about AWS PrivateLink in Databricks and the network flow in a typical implementation, explore the .
This feature is supported in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
eu-west-1
Europe (Ireland)
vpce-079feae086b944dad
eu-west-2
Europe (London)
vpce-091d282f539081cf5
us-east-1
US East (Virginia)
vpce-0421446f7bf694e56
us-east-2
US East (Ohio)
vpce-071ef6403fa277210
us-west-2
US West (Oregon)
vpce-01f8edfbf6da1095d
ap-northeast-1
Asia Pacific (Tokyo)
vpce-09b3a20743b64ecc9
ap-south-1
Asia Pacific (Mumbai)
vpce-00620d5f59239fa03
ap-southeast-1
Asia Pacific (Singapore)
vpce-0b470f0df2b0e03f3
ap-southeast-2
Asia Pacific (Sydney)
vpce-0afc6a24f0959847c
ca-central-1
Canada (Central)
vpce-07dfc91c761a8f2f9
eu-central-1
Europe (Frankfurt)
vpce-04bc9a3cd6020a865
eu-central-1
Europe (Frankfurt)
vpce-07f633ac50bc430c2
eu-north-1
Europe (Stockholm)
vpce-05c586fedca0a4112
eu-west-1
Europe (Ireland)
vpce-0ac01be5c06a919b0
eu-west-2
Europe (London)
vpce-0dd3c340c3dd64a5b
us-east-1
US East (Virginia)
vpce-03b3bf4334aa34d88
us-east-2
US East (Ohio)
vpce-04fdafe0ed07caace
us-west-2
US West (Oregon)
vpce-06624165eaa569250
ap-northeast-1
Asia Pacific (Tokyo)
vpce-0c738d241aa0bfde7
ap-northeast-2
Asia Pacific (Seoul)
vpce-00daddfa7477666eb
ap-south-1
Asia Pacific (Mumbai)
vpce-08a6d075ddd92df58
ap-southeast-1
Asia Pacific (Singapore)
vpce-030933ffc228d94ac
ap-southeast-2
Asia Pacific (Sydney)
vpce-0803dc2285d0d695f
ca-central-1
Canada (Central)
vpce-0ebff3192617126c9
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": [
"execute-api:/*"
]
},
{
"Effect": "Deny",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": [
"execute-api:/*"
],
"Condition" : {
"StringNotEquals": {
"aws:SourceVpce": [
"vpce-1a2b3c4d5e6f7g8h9", # customer internal VPC Endpoint
"vpce-0421446f7bf694e56" # Immuta VPC Endpoint added to list
]
}
}
}
]
{"Message":"User: anonymous is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:us-east-1:****************/foo/GET/bar with an explicit deny"}select SYSTEM$GET_PRIVATELINK_CONFIG()Ensure that your accounts meet the following requirements:
Your Databricks account is on the E2 version of the platform.
Your Databricks account is on the Enterprise pricing tier.
You have your Databricks account ID from the account console.
You have an Immuta SaaS tenant.
has been enabled.
Ensure that your workspace meets the following requirements:
Your workspace must be in an AWS region that supports the E2 version of the platform.
Your Databricks workspace must use a customer-managed VPC to add any PrivateLink connection.
Your workspaces must be configured with private_access_settings objects.
You cannot configure a connection to your workspace over the public internet if PrivateLink is enabled.
If you have PrivateLink configured on your workspace, Databricks will update the DNS records for that workspace URL to resolve to <region>.privatelink.cloud.databricks.com. Immuta SaaS uses these publicly-resolvable records to direct traffic to a PrivateLink endpoint on our network.
This means that if you have PrivateLink enabled on your workspace, you must follow these instructions to configure your integration. Even if your workspace is also publicly-routable, Databricks's DNS resolution forces the traffic over PrivateLink.
The two supported configurations are
A workspace with no PrivateLink configuration, which resolves to public IP addresses.
A workspace with PrivateLink configuration, which allows access from the Immuta SaaS regional endpoint (listed below).
Contact your Databricks representative to enable AWS PrivateLink on your account.
Register the Immuta VPC endpoint for the applicable AWS region with your Databricks workspaces. The Immuta VPC endpoint IDs are listed in the table below.
ap-northeast-1
Asia Pacific (Tokyo)
vpce-08cadda15f0f70462
ap-northeast-2
Asia Pacific (Seoul)
vpce-0e45ce26a7f8d00af
ap-south-1
Asia Pacific (Mumbai)
vpce-0efef886a4fbd9532
ap-southeast-1
Asia Pacific (Singapore)
vpce-07e9890053f5084b2
ap-southeast-2
Asia Pacific (Sydney)
vpce-0d363d9ea82658bec
ca-central-1
Canada (Central)
vpce-01933bcf30ac4ed19
Identify your private access level (either ACCOUNT or ENDPOINT) and configure your Databricks workspace accordingly.
If the private_access_level on your private_access_settings object is set to ACCOUNT, no additional configuration is required.
If the private_access_level on your private_access_settings object is set to ENDPOINT, using the table above, you will need to add it to the allowed_vpc_endpoint_ids list inside your private_access_settings object in Databricks. For example,
Configure Databricks depending on your integration type:
Configure the Databricks Unity Catalog integration using your standard cloud.databricks.com workspace URL as the Host.
Configure the Databricks Spark integration using your standard cloud.databricks.com URL. And register your tables as Immuta data sources using the cloud.databricks.com as the Server when registering data sources.
Immuta SaaS hosts AWS PrivateLink services that organizations can configure Amazon VPC endpoint connections to, which ensures that all traffic to Immuta SaaS only traverses private networks.
This feature is supported in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
"private_access_settings_name": "immuta-access",
"region": "us-east-1",
"public_access_enabled": false,
"private_access_level": "ENDPOINT",
"allowed_vpc_endpoint_ids": [
"vpce-0fe5b17a0707d6fa5"
]eu-central-1
Europe (Frankfurt)
vpce-0048e36edfb27d0aa
eu-west-1
Europe (Ireland)
vpce-0783d9412b046df1f
eu-west-2
Europe (London)
vpce-0f546cc413bf70baa
us-east-1
US East (Virginia)
vpce-0c6e8f337e0753aa9
us-east-2
US East (Ohio)
vpce-00ba42c4e2be20721
us-west-2
US West (Oregon)
vpce-029306c6a510f7b79
You have an Immuta SaaS tenant.
You have an Amazon VPC in one of the supported regions listed in the global segment tables below.
Clients (users or services) can access the Amazon VPC network where the AWS PrivateLink endpoint will be created.
You will need to create an AWS PrivateLink endpoint to connect directly to your tenant over the Immuta SaaS network. Please refer to the AWS PrivateLink documentation for instructions on creating an endpoint.
Immuta has a set of PrivateLink services that you can connect to in different global segments. When creating your endpoint, please choose the service in the same region as your tenant. If you do not know what region your tenant is in, please contact your Immuta representative.
us-east-1
US East (Virginia)
com.amazonaws.vpce.us-east-1.vpce-svc-0c33df1aaf78a8955
use1-az2
use1-az4
use1-az6
us-west-2
US West (Oregon)
com.amazonaws.vpce.us-west-2.vpce-svc-0e35fa96fd264e0a6
usw2-az1
usw2-az2
usw2-az3
eu-central-1
Europe (Frankfurt)
com.amazonaws.vpce.eu-central-1.vpce-svc-027e6fd0c1cf62c68
euc1-az1
euc1-az2
euc1-az3
eu-west-1
Europe (Ireland)
com.amazonaws.vpce.eu-west-1.vpce-svc-0bd003f6352dc5e58
euw1-az1
euw1-az2
euw1-az3
eu-west-2
Europe (London)
com.amazonaws.vpce.eu-west-2.vpce-svc-0cb6dcde93257e082
euw2-az1
euw2-az2
euw2-az3
ap-northeast-1
Asia Pacific (Tokyo)
com.amazonaws.vpce.ap-northeast-1.vpce-svc-056d170f71688f5f9
apne1-az1
apne1-az2
apne1-az4
ap-southeast-2
Asia Pacific (Sydney)
com.amazonaws.vpce.ap-southeast-2.vpce-svc-0f1fad760b7efc4d7
apse2-az1
apse2-az2
apse2-az3
VPC endpoints must be associated with at least one security group upon creation. Please ensure that traffic from your clients to port 443 is allowed.
In order to direct traffic to your PrivateLink endpoint for your tenant hostname, you will need to set up DNS resolution in your network for the privatelink.immutacloud.com domain. For instructions on how to do this, please refer to your internal DNS provider's documentation.
Once you have resolution for the domain configured, you will need to create a CNAME DNS record that resolves <tenant name>.privatelink.immutacloud.com to your newly-created VPC endpoint's DNS name.
For example, if your tenant's hostname is example.hosted.immutacloud.com and your VPC endpoint DNS name is vpce-0d363d9ea82658bec-e4wo04x9.vpce-svc-0d12345ddd89101112.us-east-1.vpce.amazonaws.com, you should create a CNAME record that resolves example.privatelink.immutacloud.com to your VPC endpoint DNS name.
The end result should be that, inside your network, DNS resolution for your tenant hostname will direct traffic to your VPC Endpoint.
Once you have configured DNS, you will need to contact your Immuta representative with the following information in order to have your VPC endpoint connection request accepted and PrivateLink enabled for your tenant:
Tenant name
AWS region
VPC endpoint ID
After the request is completed, please continue to use your standard hostname (e.g. example.hosted.immutacloud.com) to access your tenant. An Immuta-managed CNAME record will direct that traffic to your PrivateLink hostname (e.g. example.privatelink.immutacloud.com).
When Immuta completes this request, your tenant will no longer be publicly accessible. Traffic bound for your tenant hostname (e.g. example.hosted.immutacloud.com) will be directed to your PrivateLink hostname (e.g. example.privatelink.immutacloud.com).
Any services or data platforms that make requests to the Governance app API will need to route their traffic over your VPC endpoint as well. The integrations that require this connectivity are:
If your Identity Provider only supports public SCIM endpoints, please see .
In order to prevent these integrations from becoming degraded, please ensure that they can send traffic to your PrivateLink endpoint.
Identity providers that support SCIM often require that the endpoints that they interact with are publicly accessible. In order to accommodate this traffic, Immuta can configure a separate, SCIM-only public traffic ingress for your tenant.
If needed, request a public SCIM ingress when you contact your Immuta representative to have Immuta SaaS private networking enabled.
If you have multiple Immuta SaaS tenants that you need to enable Immuta SaaS private networking for, you only need to configure one endpoint per global segment. For example, if all your tenants are in the EU global segment, you only need to create a VPC endpoint in one of the EU regions from the table above.
While having at least one is required, it is possible to configure multiple endpoints, either for redundancy or to support traffic to your tenants from distinct, isolated networks. If you do create multiple VPC endpoints, please provide all the VPC endpoint IDs from your connection requests to your Immuta representative.
You will still need to create a privatelink.immutacloud.com CNAME record for each tenant. Please ensure that, if you've created separate VPC endpoints per tenant, the CNAME record references the correct VPC endpoint DNS name.
You have an Immuta SaaS tenant.
You have an Amazon VPC in one of the supported regions listed in the global segment tables above.
Clients (users or services) can access the Amazon VPC network where the AWS PrivateLink endpoint will be created.
You have successfully configured Immuta SaaS PrivateLink for the Governance app.
PrivateLink for the Marketplace app is only supported if all your tenants reside in a single global segment. Having tenants in multiple global segments is very uncommon, so you are unlikely to be affected by this limitation.
Immuta SaaS Private Networking for the Marketplace app will use the same VPC endpoint as the one created for the Governance app, so the only required additional configuration is DNS-related.
In order to direct traffic to your PrivateLink endpoint for Marketplace, you will need to set up DNS resolution in your network for the following domains:
app.immutacloud.com
marketplace-fe.immutacloud.com
For instructions on how to do this, refer to your internal DNS provider's documentation.
Once you have resolution for the domain configured, you will need to create a CNAME DNS record that resolves those domains to your PrivateLink VPC endpoint's DNS name (the same endpoints used for the Governance PrivateLink).
For example, if your VPC endpoint DNS name is vpce-0d363d9ea82658bec-e4wo04x9.vpce-svc-0d12345ddd89101112.us-east-1.vpce.amazonaws.com, you should create CNAME records that resolve app.immutacloud.com and marketplace-fe.immutacloud.com to your VPC endpoint DNS name.
The end result should be that, inside your network, DNS resolution to app.immutacloud.com and marketplace-fe.immutacloud.com will direct traffic to your VPC endpoint, and Marketplace should be accessible along with your tenant.
