# Global Endpoints

> **📝 Note**: This feature is in Preview and available only for Enterprise clusters on AWS.

Global Endpoints simplifies the application connectivity portion of disaster recovery. It provides a single, stable private endpoint for a pair of SingleStore clusters. The endpoint switches between clusters during failover and failback, so applications can continue using the same connection string when failing over to another region.

Smart DR failover and failback are initiated separately through the Portal or API; the endpoint does not start these operations automatically.

## How Global Endpoints Works

Without Global Endpoints, an application connects to the regional endpoint of a specific cluster. After a Smart DR failover, the promoted cluster becomes active and the application must be updated to use the secondary cluster's endpoint.

With Global Endpoints:

* Applications connect to one stable private hostname.
* Before failover, the endpoint routes traffic to the write cluster.
* After a failover, Global Endpoints routes the endpoint to the newly active cluster.
* After failback, SingleStore routes the endpoint back to the initial write cluster.
* The endpoint name and application connection string remain unchanged.

Global Endpoints keeps the connection string unchanged during failover, but an already-open database connection may still be interrupted. Application retry logic will ensure that connections succeed when reconnecting.

Users create the VPC endpoints. SingleStoremanages the Private Networking (PrivateLink) services, the hosted zone, and the routing decision. Because the hosted zone is managed by SingleStore and the VPC is managed by the user, users must authorize the association once during setup so the two can be linked.

![](https://cdn.sanity.io/images/h3bp8c98/production/e0de5a69137f390749e0d2b0ab5d7538cd9b2e9d-1212x1280.png)

## Sample Scenarios

| Scenario                       | What it covers                                                                                                                           |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Planned DR drill or switchover | Rehearse or perform a controlled regional switch without touching application configuration, which makes drills cheap to run and repeat. |
| Unplanned regional failover    | Recover from a region failure without tracking down every application owner to repoint connection strings mid-incident.                  |
| Failback                       | Return to the original primary once it recovers, using the same endpoint and the same process as failover.                               |

## Recovery Options

Global Endpoints support two common recovery scenarios:

## Scenario 1: When Only the Database Failsover

In this scenario, the application remains available in the original region but the database must fail over.

If a problem occurs that impacts only the SingleStore cluster or database while the application and its region remain healthy, failing over only the database lets the application keep running, avoiding an unnecessary application failover. This reduces recovery work because the application continues using the same connection string.

The typical action steps are:

1. The application continues running in Region A.

2. You initiate Smart DR failover.

3. The secondary cluster in Region B becomes active.

4. The Global Endpoint routes new connections to Region B.

5. The application continues using the same connection string over a private cross-region path.

However in such cases, requests may experience additional latency since the application and database are in different regions.

## Scenario 2: When the Application and Database Both Failover

In this scenario, a broader disruption requires both the application and database to move.

If a broader regional disruption affects both the application and SingleStore cluster, you can fail over both to the secondary region. This restores the application and database into the same region, allowing your application to resume local communication without the added latency of cross-region access. The Global Endpoint lets the application continue using the same connection string during recovery.

The typical action steps are:

1. The application moves to Region B.

2. You initiate Smart DR failover.

3. The secondary cluster in Region B becomes active.

4. The application uses the same Global Endpoint as before the failover.

5. The endpoint routes traffic to the active cluster in Region B.

This preserves regional locality when the application and database are deployed in both regions. Configure Global Endpoint connectivity for each VPC where the application may run.

## Prerequisites

Before configuring a Global Endpoint, confirm that:

* Smart DR is configured on the cluster being failed over between regions.
* The databases that you want to protect are being replicated.
* Replication is active and the secondary cluster is available as the failover destination.
* The cluster uses AWS PrivateLink.
* An AWS VPC is available for each application environment that will connect to the active cluster.
* The user has permission to create AWS VPC endpoints in the application VPCs.

Run the AWS CLI command provided by SingleStore to associate the application VPC with the SingleStore managed Private Hosted Zone (PHZ). Once validated, applications in that VPC can use a stable Global Endpoint that connects privately to the active SingleStore cluster.

## Configure a Global Endpoint

Complete the following steps for each application VPC that may run during recovery.

**Step 1: Configure Smart DR**

Create the primary cluster and configure Smart DR replication to a secondary region. Select the databases to protect and verify that replication is active.

**Step 2: Pre-provision the Secondary Cluster**

Pre-provision the secondary cluster before you need it for recovery. This allows you to configure private connectivity in advance. After private connectivity is configured, you can suspend the secondary cluster if you want to reduce ongoing compute costs.

**Step 3: Configure PrivateLink for both Clusters**

In the Portal:

1. Open **Access and Security** for the primary cluster.

2. Create an inbound PrivateLink connection.

3. Enable cross-region access for the secondary region.

4. Repeat the configuration for the secondary cluster, enabling access from the primary region.

**Step 4: Create AWS VPC Endpoints**

In each application VPC, create two AWS VPC endpoints:

* One endpoint for the primary SingleStore cluster.
* One endpoint for the secondary SingleStore cluster.

Note the DNS names of both VPC endpoints.

**Step 5: Add the PrivateLink Configuration to Smart DR**

In the Portal, open **PrivateLinks for Smart DR** and provide:

* The application VPC ID.
* The AWS region for the application VPC.
* The DNS name of the primary VPC endpoint.
* The DNS name of the secondary VPC endpoint.

Repeat this step for every VPC where the application may run.

**Step 6: Authorize and Validate Private DNS**

SingleStore creates the private DNS configuration and provides an AWS CLI command to associate it with your VPC.

1. Run the provided command from the AWS account that owns the VPC.

2. Return to the Portal.

3. Validate the association.

4. Confirm that the Global Endpoint resolves from the application VPC.

**Step 7: Update the Application Connection String**

Update the application to use the Global Endpoint instead of the regional endpoint for either cluster. This is the only endpoint change required in the application configuration.

Use the same connection string during:

* Normal operation.
* Smart DR failover.
* Smart DR failback.

## Failover and Failback Behavior

Global Endpoints follow the active cluster, but you remain responsible for initiating Smart DR operations.

## During Failover

1. Initiate Smart DR failover through the Portal or API.

2. Smart DR promotes the secondary cluster.

3. SingleStore updates the Global Endpoint routing.

4. Applications reconnect through the same hostname after the secondary cluster is ready.

## During Failback

1. Confirm that the original primary cluster is healthy.

2. Initiate Smart DR failback through the Portal or API.

3. Smart DR returns the active role to the original primary cluster.

4. SingleStore routes the Global Endpoint back to that cluster.

5. Applications continue using the same connection string.

## Design Applications for Reconnects

A Global Endpoint removes the need to change connection strings. It does not preserve connections that were established with the previous active cluster.

When failover begins, existing connections may be interrupted. Applications may temporarily receive connection errors, timeouts, or unavailable responses while the secondary cluster is promoted and endpoint routing changes take effect.

Configure standard retry and reconnect behavior in the application or database client:

* Check for failed or stale connections.
* Close and recreate connections when required.
* Retry requests according to your application's safety and idempotency requirements.
* Use bounded backoff rather than retrying continuously.
* Allow enough time for the secondary cluster and endpoint routing to become ready.
* Log reconnect attempts and failures so that recovery can be monitored.

Test this behavior during a planned DR exercise. Test both the remote cross-region and local-access patterns when both are part of your recovery plan.

## Troubleshooting Checklist

If an application cannot connect through the Global Endpoint, verify the following:

* The application is running in a VPC configured under **Private Links for Smart DR**.
* Both primary and secondary AWS VPC endpoints were created in that VPC.
* The submitted VPC endpoint DNS names are correct.
* The private DNS association command was run from the AWS account that owns the VPC.
* Private DNS association was successfully validated in the Portal.
* Smart DR has completed the failover or failback and the target cluster is ready.
* The application has retried or recreated connections that were open before failover.
* Cross-region latency is acceptable when using the remote cross-region pattern.

***

Modified at: October 23, 2026

Source: [/cloud/manage-data/global-endpoints/](https://docs.singlestore.com/cloud/manage-data/global-endpoints/)

(An index of the documentation is available at /llms.txt)