What Network Access Skippr Needs for Redshift

June 2026

Redshift source access is mainly Redshift Data API access plus a database user that can read the tables you named.

Short Answer

Skippr needs access to the regional Redshift Data API resources referenced in the source config, plus a Redshift database user that can read the selected tables. The source docs are explicit that the connector is built around cluster_identifier or workgroup_name, database, optional db_user, and region, so the usable boundary is the AWS API path for that Redshift deployment, not a direct warehouse socket from the runner.

That changes the debugging model. If the source targets cluster my-cluster in us-east-1, the runner needs AWS credentials that can call the Redshift APIs in that region, and the database user named in the request still has to be able to read public.customers or public.orders. You can have one without the other and still end up with a source that looks configured but does not read anything useful.

Why Teams Struggle with This

Redshift source access is easy to misread because the warehouse itself feels like a database connection problem. In this connector, the first operational boundary is the AWS Data API surface, then the Redshift database permissions behind it.

• The AWS principal must be allowed to use the Redshift Data API resources you reference.
• The region has to match the real cluster or serverless workgroup location.
• The Redshift database user still needs read access to the selected tables.
• A valid AWS credential chain does not help if the wrong cluster or workgroup is named in config.

How Skippr Handles It

Skippr keeps the Redshift source boundary readable: one cluster or one workgroup, one database, one region, optional database user, optional table list. That makes it easier to coordinate with both cloud-platform and warehouse admins because the access request is already separated into API access and SQL object access.

It also avoids a common mistake in private environments. Teams sometimes open warehouse network paths that this connector does not even use, while forgetting that the runner really needs the regional Redshift API and the right AWS identity.

• Uses the Redshift Data API rather than a direct SQL port from the runner.
• Targets either a provisioned cluster or a serverless workgroup.
• Relies on the AWS default credential chain for the API-side access path.
• Keeps database read permissions explicit through the selected Redshift user and tables.

What the First Useful Version Looks Like

The first useful version is one region, one Redshift deployment, and one readable table that proves both the AWS API path and the database-user permissions.

If either half is still uncertain, keep the test small. Redshift source issues become much clearer when you validate the API layer and the SQL layer separately.