Secure connections

VPC isolation

AuraDB Virtual Dedicated Cloud AuraDS Enterprise

AuraDB Virtual Dedicated Cloud and AuraDS Enterprise run in a dedicated cloud Account (AWS), Subscription (Azure) or Project (GCP) to achieve complete isolation for your deployment.

Additional VPC boundaries enable you to operate within an isolated section of the service, where your processing, networking, and storage are further protected.

The Aura Console runs in a separate VPC, separate from the rest of Aura.

Network access

An Aura instance can be publicly available, completely private, or both. To configure this, you need to be authorized to access the part of the infrastructure that runs and handles these instances as well as the networking used to establish secure connections between the database and the application’s VPC. This includes the ability to connect over the cloud provider’s private link and private endpoint.

If your Aura instances are public, traffic to them is allowed to traverse the public internet and they are accessible with the correct username and password.

For your instance to be completely private, turn public traffic off, use the cloud provider’s network, and create a private endpoint inside your VPC, which gives you a private connection to Aura. The only way to connect to your database is from inside your network (your VPC in your AWS/Azure/GCP account) using an internal IP address you choose and DNS records you create.

To select network access settings go to Aura Console > Security > Network Access.

Private endpoints

Private endpoints are network interfaces inside your own VPC, which can only be accessed within your private network. The cloud provider connects them over their network to Neo4j Aura. By design they are not exposed to the public internet, ensuring that critical services are accessible only through private, secure networks.

A single private link connection applies to all instances in a region. So if you’ve set one up for us-east-1 then those network connections will apply to all instances in that region. You can set up a second private link connection to applications that are hosted in a second region (for example us-west-1) but still housed inside the same Aura project.

AWS private endpoints

AuraDB Virtual Dedicated Cloud AuraDS Enterprise

AuraDB Virtual Dedicated Cloud and AuraDS Enterprise support private endpoints on AWS using AWS PrivateLink.

Once activated, you can create an endpoint in your VPC that connects to Aura.

For a step-by-step guide, see the How to Configure Neo4j Aura With AWS PrivateLink blog article.

Figure 1. VPC connectivity with AWS PrivateLink

All applications running Neo4j workloads inside the VPC are routed directly to your isolated environment in Aura without traversing the public internet. You can then disable public traffic, ensuring all traffic to the instance remains private to your VPC.

PrivateLink applies to all instances in the region.
When activated, a Private Connection label, shield icon, and dedicated Private URI will appear on any instance tile using PrivateLink in the Aura Console.
If you disable public traffic, you must use a dedicated VPN to connect to your instance via Browser or Bloom.
Connections using private endpoints are one-way. Aura VPCs can’t initiate connections back to your VPCs.
In AWS region us-east-1, we do not support the Availability Zone with ID use1-az3 for private endpoints.

Browser and Bloom access over private endpoints

To connect to your instance via Browser or Bloom, you must use a dedicated VPN. This is because when you disable public access to your instance, this applies to all connections, including those from your computer when using Browser or Bloom.

Without private endpoints, you access Browser and Bloom over the internet:

Figure 2. Architecture overview before enabling private endpoints

When you have enabled private endpoints and disabled public internet access, you can no longer connect Browser or Bloom to your instances over the internet:

Figure 3. Architecture overview with private endpoints enabled and public traffic disabled

To continue accessing Browser and Bloom, you can configure a VPN (Virtual Private Network) in your VPC and connect to Browser and Bloom over the VPN.

To access Bloom and Browser over a VPN, you must ensure that:

The VPN server uses the VPC’s DNS servers.
You use the Private URI shown on the instance tile and in the instance details. It will be different from the Connection URI you used before.

Figure 4. Accessing Browser and Bloom over a VPN

Enabling private endpoints

To enable private endpoints using AWS PrivateLink:

Select Network Access from the sidebar menu of the Console.
Select New network access configuration and follow the setup instructions.

You will need an AWS account with permissions to create, modify, describe and delete endpoints. Please see the AWS Documentation for more information.

GCP private endpoints

AuraDB Virtual Dedicated Cloud AuraDS Enterprise

AuraDB Virtual Dedicated Cloud and AuraDS Enterprise support private endpoints on GCP using GCP Private Service Connect.

Once activated, you can create an endpoint in your VPC that connects to Aura.

Figure 5. VPC connectivity with GCP Private Service Connect

Private Service Connect applies to all instances in the region.
When activated, a Private Connection label, shield icon, and dedicated Private URI will appear on any instance tile using Private Service Connect in the Aura Console.
If you disable public traffic, you must use a dedicated VPN to connect to your instance via Browser or Bloom.
Connections using private endpoints are one-way. Aura VPCs can’t initiate connections back to your VPCs.

Browser and Bloom access over private endpoints

Without private endpoints, you access Browser and Bloom over the internet:

Figure 6. Architecture overview before enabling private endpoints

When you have enabled private endpoints and disabled public internet access, you can no longer connect Browser or Bloom to your instances over the internet:

Figure 7. Architecture overview with private endpoints enabled and public traffic disabled

To continue accessing Browser and Bloom, you can configure a GCP Cloud VPN (Virtual Private Network) in your VPC and connect to Browser and Bloom over the VPN.

To access Bloom and Browser over a VPN, you must ensure that:

You have set up GCP Response Policy Zone, or an equivalent DNS service, inside of the VPC.
You use the Private URI shown on the instance tile and in the instance details. It will be different from the Connection URI you used before.

Figure 8. Accessing Browser and Bloom over a VPN

Enabling private endpoints

To enable private endpoints using GCP Private Service Connect:

Select Network Access from the sidebar menu of the Console.
Select New network access configuration and follow the setup instructions.

Please see the GCP Documentation for required roles and permissions.

Azure private endpoints

AuraDB Virtual Dedicated Cloud AuraDS Enterprise

AuraDB Virtual Dedicated Cloud and AuraDS Enterprise support private endpoints on Azure using Azure Private Link.

Once activated, you can create an endpoint in your Virtual Network (VNet) that connects to Aura.

Figure 9. VNet connectivity with Azure Private Link

All applications running Neo4j workloads inside the VNet are routed directly to your isolated environment in Aura without traversing the public internet. You can then disable public traffic, ensuring all traffic to the instance remains private to your VNet.

Private Link applies to all instances in the region.
When activated, a Private Connection label, shield icon, and dedicated Private URI will appear on any instance tile using Private Link in the Aura Console.
If you disable public traffic, you must use a dedicated VPN to connect to your instance via Browser or Bloom.
Connections using private endpoints are one-way. Aura VNets can’t initiate connections back to your VNets.

Browser and Bloom access over private endpoints

Without private endpoints, you access Browser and Bloom over the internet:

Figure 10. Architecture overview before enabling private endpoints

When you have enabled private endpoints and disabled public internet access, you can no longer connect Browser or Bloom to your instances over the internet:

Figure 11. Architecture overview with private endpoints enabled and public traffic disabled

To continue accessing Browser and Bloom, you can configure a VPN (Virtual Private Network) in your VNet and connect to Browser and Bloom over the VPN.

To access Bloom and Browser over a VPN, you must ensure that:

You have setup Azure Private DNS, or an equivalent DNS service, inside of the VNet.
You use the Private URI shown on the instance tile and in the instance details. It will be different from the Connection URI you used before.

Figure 12. Accessing Browser and Bloom over a VPN

Enabling private endpoints

To enable private endpoints using Azure Private Link:

Select Network Access from the sidebar menu of the Console.
Select New network access configuration and follow the setup instructions.

Please see the Azure Documentation for required roles and permissions.

Private links

This private link section is cloud-agnostic and therefore applicable to all clouds. A private link provides secure network connectivity between your application and AuraDB without exposing traffic to the public internet.

The term “private link” refers to:

Private Service Connect = Google Cloud platform
PrivateLink = AWS
Private Link = Azure

The following steps explain the process of establishing a private link connection to securely connect your application to an AuraDB Virtual Dedicated Cloud environment.

The dbid: abcd1234 and orch-id: 0000 are used in this example. These are different in your AuraDB Virtual Dedicated Cloud environment.

The application initializes a driver connection to neo4j+s://abcd1234.production-orch-0000.neo4j.io.
The network layer then queries the DNS server to resolve the fully qualified domain name (FQDN) (in this case, abcd1234.production-orch-0000.neo4j.io) to its corresponding IP address.
The Cloud Virtual Network private DNS is queried, and it resolves the FQDN to 10.10.10.10, based on the wildcard DNS A record created: *.production-orch-0000.neo4j.io → 10.10.10.10
The application’s connection is directed to 10.10.10.10, which is the private link endpoint. From there, the private link endpoint forwards the network connection to the private ingress through the private link.
The private ingress extracts the dbid from the FQDN and directs the connection to the appropriate Aura instance (dbid: abcd1234).
The Aura instance responds by sending the Neo4j cluster routing table back to the application, which contains information about the instances and their roles.
Based on the type of transaction (read or write) the driver selects an appropriate instance to execute a read or write transaction. The code has the ability to direct the transaction to the appropriate instances this way.
Similar to before, the Cloud Virtual Network private DNS is queried and resolves the FQDN to 10.10.10.10. The application’s connection is sent to the private link endpoint (10.10.10.10), which forwards the network connection to the private ingress through the private link. The private ingress then directs the connection to the Aura instance with dbid: abcd1234.
Finally, the write transaction is received and executed within the Aura instance with dbid: abcd1234.

Table 1. Available instances and their roles
abcd1234.production-orch-0000.neo4j.io	role: write
abcd1234.production-orch-0000.neo4j.io	role: read
abcd1234.production-orch-0000.neo4j.io	role: read

Supported TLS cipher suites

For additional security, client communications are carried via TLS v1.2 and TLS v1.3.

AuraDB has a restricted list of cipher suites accepted during the TLS handshake, and does not accept all of the available cipher suites. The following list conforms to safety recommendations from IANA, the OpenSSL, and GnuTLS library.

TLS v1.3:

TLS_CHACHA20_POLY1305_SHA256 (RFC8446)
TLS_AES_128_GCM_SHA256 (RFC8446)
TLS_AES_256_GCM_SHA384 (RFC8446)

TLS v1.2:

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (RFC5288)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (RFC5289)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC5289)
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (RFC7905)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (RFC5288)