Connect through AWS PrivateLink

Connect provisioned Amazon Redshift or Redshift Serverless to DinMo through a managed, cross-account AWS PrivateLink route.

AWS PrivateLink lets DinMo reach a private Amazon Redshift deployment without a public Redshift endpoint, SSH bastion, or SSM-managed instance.

This is an assisted setup. Your AWS team authorizes one exact DinMo account and VPC; DinMo creates, validates, and operates the private connection.

Start the request in DinMo. We first review it and provide the account and VPC to authorize. Your team then grants access in AWS and confirms the action in DinMo. We verify the grant and finish the connection. The product shows who needs to act at each step; you can leave the page and resume later.

Data path and ownership

DinMo managed service
        │ AWS PrivateLink
        ▼
Your private Redshift cluster or Serverless workgroup

The Redshift-managed endpoint lives in DinMo's AWS account and VPC. It does not make your warehouse public and does not require inbound access from the internet.

Component or action	Owner
Redshift cluster or Serverless workgroup	Your AWS team
Scoped cross-account authorization	Your AWS team
DinMo-managed AWS PrivateLink endpoint and service infrastructure	DinMo
Database user and SQL grants	Your Redshift team
Endpoint DNS name and port registration	DinMo, server-side only

PrivateLink and SSM are alternatives. Selecting PrivateLink does not require your team to operate an EC2 or SSM tunnel host, or to provide AWS credentials to DinMo at runtime.

Supported Redshift deployments

DinMo supports both Redshift-managed endpoint models:

• Provisioned Amazon Redshift clusters.

• Amazon Redshift Serverless workgroups.

The Redshift resource and DinMo endpoint must be in the same AWS region. The guided setup confirms region availability before asking your team to authorize access.

Prerequisites

Required for every setup

Have the following ready before starting in DinMo:

• Standard Redshift host, without a protocol or port.

• Customer AWS account ID for a provisioned cluster. For Serverless, DinMo reads it from the standard host.

• An AWS operator who can apply the scoped authorization.

• A Redshift administrator who can prepare the DinMo database identity, schemas, and grants.

DinMo detects the deployment type, AWS region, and cluster or workgroup from the standard host. PrivateLink currently supports Redshift port 5439. The app records the setup directly in the current workspace; do not send these values or database credentials by email.

Provisioned cluster

The cluster must:

• Use an RA3 or another node type currently supported by Redshift-managed VPC endpoints.

• Have cluster relocation or Multi-AZ enabled.

• Be available in the recorded AWS region.

• Allow your AWS operator to call redshift:AuthorizeEndpointAccess.

Review the current AWS requirements in Redshift-managed VPC endpoints.

Redshift Serverless

The workgroup must:

• Be in the AVAILABLE state.

• Belong to the recorded customer AWS account and region.

• Allow your AWS operator to manage Granted accounts for the workgroup.

Review the current AWS cross-account flow in Connecting to Amazon Redshift Serverless.

Guided setup statuses

The PrivateLink step in DinMo is the source of truth for progress.

Status	Meaning	Action owner	Can continue?
Request received	The non-secret Redshift details are saved and DinMo is preparing the authorization scope.	DinMo	No
Customer action required	DinMo recorded the setup and is waiting for the AWS authorization.	Your AWS team	No
DinMo verification pending	Your team confirmed the AWS action; DinMo still verifies the effective grant.	DinMo	No
DinMo is provisioning	DinMo verified the authorization and is creating and validating the endpoint.	DinMo	No
Private network ready	The endpoint is available, validated, and registered server-side.	You: continue to database authentication	Yes
Revoked	The authorization or endpoint is no longer approved for use.	DinMo and your AWS team	No

The page refreshes automatically while work is in progress. You can close it at any time. The pending setup remains visible under Sources, where Continue setup returns to the current step.

The progress panel identifies the owner of each action. This example shows the completed network setup.

Step 1: Create the setup request in DinMo

1. Add an Amazon Redshift source.

2. Select AWS PrivateLink as the connection method.

3. Enter a source name used inside DinMo. It does not need to match the AWS resource name.

4. Paste the standard Redshift host. DinMo displays the deployment type, region, and cluster or workgroup it detects. For a provisioned cluster, also enter the AWS account ID.

5. Check the detected values, then click Start PrivateLink setup.

DinMo receives the request in the app. The source appears immediately under Sources with its current status, even if you leave the setup page. You can choose Return to Sources or Exit without losing the request, then select Continue setup later. No database name, username, password, or PrivateLink endpoint is requested at this stage.

Step 2: Review the authorization scope

DinMo reviews the request and publishes the exact DinMo AWS account and VPC to authorize. When the status changes to Customer action required, open the pending source and confirm the cluster or workgroup, customer account, region, DinMo account, and DinMo VPC displayed in the app.

Stop and contact DinMo if any value is unexpected. Do not authorize a broader account, VPC, region, or Redshift resource.

Step 3: Authorize the exact DinMo account and VPC

DinMo displays the exact action and scope for the deployment type. Use the values shown in the app for your setup.

Provisioned cluster authorization

Run the following shape of command in the Redshift owner account:

aws redshift authorize-endpoint-access \
  --cluster-identifier "$CLUSTER_IDENTIFIER" \
  --account "$DINMO_AWS_ACCOUNT_ID" \
  --vpc-ids "$DINMO_VPC_ID" \
  --region "$AWS_REGION"

The command grants access only to the named cluster, DinMo account, DinMo VPC, and region. Do not omit --vpc-ids or replace it with an all-VPC grant.

AWS documents the parameters in AuthorizeEndpointAccess.

Serverless workgroup authorization

Use the Redshift Serverless console so the workgroup's other permissions remain unchanged:

1. In the Redshift owner account, open Amazon Redshift Serverless in the AWS region shown by DinMo.

2. Select the exact workgroup shown by DinMo.

3. Open Data access. Under Granted accounts, choose Grant access.

4. Enter the exact DinMo AWS account ID shown in the app.

5. Choose Specific VPCs and add the exact DinMo VPC ID shown in the app. Do not grant access to all VPCs.

6. Review the account and VPC, then save the grant.

If your AWS access is managed as code, merge the DinMo grant into the workgroup's existing resource policy and retain every existing statement. Do not submit a replacement policy containing only the DinMo statement: an AWS put-resource-policy update replaces the complete policy document.

AWS documents the same console flow in Granting access to a VPC.

Return to the PrivateLink step in DinMo and click I authorized access in AWS. This records your confirmation in the setup; it does not mark the connection as approved or ready. DinMo separately verifies the effective AWS grant.

Step 4: Wait for DinMo validation

After your AWS team applies the authorization:

1. DinMo verifies the account, VPC, region, and Redshift resource.

2. DinMo creates the Redshift-managed endpoint in its AWS VPC.

3. DinMo validates the endpoint state, DNS resolution, and private connectivity.

4. DinMo securely registers the connection for your workspace.

5. The app changes the setup status to Private network ready.

No customer action is required while the status is DinMo is provisioning.

The managed endpoint hostname and port never appear in the browser or source payload. Only DinMo's server-side services can resolve the workspace-scoped setup to the endpoint.

Step 5: Configure Redshift credentials and permissions

When the status is Private network ready, click Continue.

Prepare the DinMo database identity and schemas, then enter the database and authentication details. DinMo restores the standard Redshift host recorded in step 1. Follow Prepare the database identity and DinMo schemas.

For provisioned IAM, DinMo requests the dedicated database username and generates a policy for redshift:GetClusterCredentials. For Serverless IAM, DinMo generates a policy for redshift-serverless:GetCredentials on the exact workgroup and maps the AWS role to the IAMR:<role name> Redshift identity; no separate username is requested.

If the workgroup consumes a datashare, use its local writable database for the DinMo connection and expose the shared schemas there. See Use a datashare through a Serverless consumer.

Do not enter the PrivateLink endpoint hostname. DinMo attaches the approved private route automatically.

Step 6: Save and test

For password authentication, click Save & test. For IAM, click Continue first, then follow the generated AWS role commands and confirm the role ARN before testing. See Save and test for the full sequence.

The connection test validates:

• The same private connection used by scheduled jobs.

• TLS to the expected Redshift-managed endpoint.

• Database authentication.

• Read access to selected source schemas.

• Full access to the DinMo technical schemas.

The source is ready only when the connection test succeeds.

Security properties

• Redshift does not need a public IP address.

• The customer authorization is scoped to one DinMo AWS account and VPC.

• The setup record is workspace-scoped and contains no database credentials.

• Endpoint hostname and port remain server-side.

• The browser receives status and customer-safe setup values only.

• DinMo controls the service-side connection and enforces the approved destination.

• PrivateLink cannot be combined accidentally with SSH or SSM settings for the same source.

Rotation and offboarding

Contact DinMo before changing the Redshift resource, region, customer AWS account, or authorized DinMo VPC. Those values define the connection's ownership boundary and require a reviewed replacement setup.

For endpoint rotation, DinMo validates and registers the replacement before retiring the old endpoint.

For offboarding:

1. Pause jobs that use the source.

2. DinMo revokes the setup record and removes the registered endpoint.

3. Your AWS team revokes the endpoint authorization or removes only the DinMo entry from the Serverless Granted accounts list.

4. DinMo deletes the endpoint after confirming that no jobs use it.

Troubleshooting by status

Status or symptom	Recommended action
Pending setup is not visible	Confirm that you are in the workspace where the request was created, then reopen Workspace Settings > Sources.
Request received for an extended period	Check that the AWS account, region, resource name, and standard host are correct, then contact DinMo.
Customer action required	Apply the exact action shown in DinMo, then click I authorized access in AWS.
DinMo verification pending or provisioning for an extended period	Do not broaden the grant. Contact DinMo with the source name and current status.
Revoked	Stop using the setup and contact DinMo for review or replacement.
Private network ready, but Save & test fails	Check Redshift credentials or IAM role, database name, effective database identity, grants, and technical schema permissions. Run grants in the same database selected in DinMo.
Region or VPC mismatch	Stop the setup. DinMo must issue or review a connection record with the correct ownership values.

Support

Share the workspace, source name, and current status with your DinMo account team or [e-mail]. Never send database passwords or private endpoint details by email.