Amazon Redshift

Connect AnomalyArmor to Amazon Redshift data warehouses

Connect AnomalyArmor to your Amazon Redshift cluster to monitor schema changes and data freshness. This guide covers both provisioned clusters and Redshift Serverless.

Supported Platforms

Platform	Notes
Redshift Provisioned	All node types (RA3, DC2, DS2)
Redshift Serverless	Workgroups with any RPU configuration

Connection Settings

Field	Description	Example
Connection Name	Friendly identifier	Production Redshift
Host	Cluster or workgroup endpoint	my-cluster.abc123.us-east-1.redshift.amazonaws.com
Port	Database port	5439
Database	Database name	dev
Username	Database user	anomalyarmor
Password	User password	See credentials section

Finding Your Connection Details

Provisioned Cluster

1. Go to AWS Console > Amazon Redshift > Clusters
2. Click on your cluster name
3. Find the Endpoint in the cluster details
4. Copy the hostname portion (everything before the port)

Redshift Serverless

1. Go to AWS Console > Amazon Redshift > Serverless dashboard
2. Click on your workgroup
3. Find the Endpoint in the workgroup details. The default database for Serverless is typically dev.

Creating a Read-Only User

Create a dedicated user with minimal permissions:

-- Create the user
CREATE USER anomalyarmor WITH PASSWORD 'your-secure-password';

-- Grant USAGE on schemas you want to monitor
GRANT USAGE ON SCHEMA public TO anomalyarmor;
GRANT USAGE ON SCHEMA analytics TO anomalyarmor;

-- Grant SELECT on all current tables
GRANT SELECT ON ALL TABLES IN SCHEMA public TO anomalyarmor;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO anomalyarmor;

-- Grant access to future tables (recommended)
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT ON TABLES TO anomalyarmor;

ALTER DEFAULT PRIVILEGES IN SCHEMA analytics
GRANT SELECT ON TABLES TO anomalyarmor;

Verifying Permissions

Test that the user can access metadata:

-- Should return tables
SELECT table_schema, table_name FROM svv_tables
WHERE table_schema NOT IN ('pg_catalog', 'information_schema')
LIMIT 5;

-- Should return columns
SELECT column_name, data_type FROM information_schema.columns
WHERE table_schema = 'public' LIMIT 5;

Network Configuration

Security Groups

Add an inbound rule to your Redshift cluster’s security group:

1. Go to AWS Console > VPC > Security Groups
2. Find the security group attached to your Redshift cluster
3. Edit inbound rules
4. Add rule:
   • Type: Custom TCP
   • Port: 5439
   • Source: AnomalyArmor IP addresses (see Settings > Security)

Public Accessibility

For AnomalyArmor to connect:

Option 1: Publicly Accessible Cluster

1. Enable “Publicly accessible” in cluster settings
2. Configure security group as shown above

Option 2: VPC Peering (Enterprise)

For private clusters, contact us for VPC peering or PrivateLink options.

Redshift clusters in private subnets with no public access require NAT Gateway or VPC peering. Contact us for Enterprise networking options.

SSL/TLS

Redshift requires SSL by default. AnomalyArmor automatically uses SSL for all Redshift connections.

Redshift Serverless Considerations

Automatic Scaling

Redshift Serverless scales compute automatically. Our discovery queries are lightweight and consume minimal RPUs.

Idle Workgroups

If your workgroup has been idle, the first query may take a few seconds while compute scales up. This is normal behavior.

Database Name

Redshift Serverless typically uses dev as the default database. Check your workgroup settings if unsure.

What We Monitor

AnomalyArmor discovers and monitors:

Object Type	Monitored	Notes
Tables	Yes	All user-created tables
Views	Yes	Regular views
Materialized Views	Yes	Treated as tables
External Tables	Yes	Redshift Spectrum tables (if permissions granted)
System Tables	No	Excluded automatically

Metadata Captured

For each table and view:

• Table name and schema
• Column names and data types
• Nullable constraints
• Default values
• Last modified timestamp (for freshness)

What We Query

AnomalyArmor runs these types of queries:

-- Tables and views (using Redshift system view)
SELECT table_schema, table_name, table_type
FROM svv_tables
WHERE table_schema NOT IN ('pg_catalog', 'information_schema');

-- Columns
SELECT column_name, data_type, is_nullable
FROM information_schema.columns
WHERE table_schema = 'your_schema';

-- Freshness (for timestamp columns)
SELECT MAX(your_timestamp_column) FROM your_table;

Impact: Minimal. These are lightweight metadata queries that don’t scan table data.

Multiple Schemas

To monitor multiple schemas, grant permissions on each:

-- For each schema you want to monitor
GRANT USAGE ON SCHEMA raw TO anomalyarmor;
GRANT USAGE ON SCHEMA staging TO anomalyarmor;
GRANT USAGE ON SCHEMA production TO anomalyarmor;

GRANT SELECT ON ALL TABLES IN SCHEMA raw TO anomalyarmor;
GRANT SELECT ON ALL TABLES IN SCHEMA staging TO anomalyarmor;
GRANT SELECT ON ALL TABLES IN SCHEMA production TO anomalyarmor;

AnomalyArmor automatically excludes system schemas (pg_catalog, information_schema, pg_internal).

Redshift Spectrum (External Tables)

If you use Redshift Spectrum for querying S3:

-- Grant access to external schemas
GRANT USAGE ON SCHEMA spectrum_schema TO anomalyarmor;
GRANT SELECT ON ALL TABLES IN SCHEMA spectrum_schema TO anomalyarmor;

External tables appear alongside regular tables in discovery.

Troubleshooting

Connection refused

Causes:

• Security group not configured
• Cluster not publicly accessible
• Wrong endpoint

Solutions:

1. Verify AnomalyArmor IPs are in security group inbound rules
2. Check “Publicly accessible” setting in cluster configuration
3. Verify endpoint is correct (check AWS Console)
4. Test connectivity: nc -zv your-endpoint 5439

Connection timeout

Causes:

• Firewall blocking connection
• Cluster in private subnet without proper routing

Solutions:

1. Verify security group allows port 5439 from AnomalyArmor IPs
2. If private subnet, ensure NAT Gateway is configured
3. Consider enabling “Publicly accessible” for the cluster
4. Contact us for VPC peering options (Enterprise)

Authentication failed

Causes:

• Wrong password
• User doesn’t exist
• Case sensitivity issues

Solutions:

1. Verify password (copy-paste to avoid typos)
2. Confirm user exists: SELECT usename FROM pg_user;
3. Remember: Redshift usernames are case-sensitive when quoted
4. Try resetting the password:
   ALTER USER anomalyarmor PASSWORD 'new-password';
   

Database does not exist

Causes:

• Wrong database name
• Case sensitivity

Solutions:

1. List databases: SELECT datname FROM pg_database;
2. Redshift Serverless default is usually dev
3. Database names are case-sensitive

No tables found in discovery

Causes:

• User lacks SELECT permission
• Schema permissions missing
• No tables in monitored schemas

Solutions:

1. Test as the user:
   SELECT * FROM svv_tables
   WHERE table_schema = 'public' LIMIT 5;
   
2. Grant schema access:
   GRANT USAGE ON SCHEMA public TO anomalyarmor;
   GRANT SELECT ON ALL TABLES IN SCHEMA public TO anomalyarmor;
   
3. Verify tables exist in expected schemas

SSL connection error

Causes:

• SSL configuration mismatch

Solutions:

1. AnomalyArmor uses SSL by default (required for Redshift)
2. Ensure your cluster has SSL enabled (default setting)
3. Contact support if you have custom SSL requirements

Best Practices

Use a Dedicated User

Create a read-only user specifically for AnomalyArmor:

• Don’t use admin accounts
• Don’t share credentials with other tools
• Use a strong, unique password

Use Read Replicas (if available)

If you have Redshift RA3 with data sharing or multiple clusters, consider pointing AnomalyArmor at a read replica to isolate monitoring queries from production workloads.

Grant Minimal Permissions

Only grant access to schemas you want to monitor. Avoid:

-- Don't do this
GRANT ALL ON DATABASE dev TO anomalyarmor;

Schedule Discovery After ETL

If you have predictable ETL schedules, run discovery after ETL completes:

Schedule	Time
ETL	2:00 AM daily
Discovery	3:00 AM daily

Limitations

• IAM authentication: Not yet supported (username/password only)
• Cross-database queries: One connection per database
• Concurrency scaling: Queries run on main cluster, not concurrency scaling
• Stored procedures: Not monitored (tables and views only)

Coming Soon

• IAM role-based authentication
• Redshift-specific metrics (WLM queue status, disk usage)
• Cross-cluster data sharing support

Next Steps

Run Discovery

Scan your Redshift cluster

Set Up Alerts

Get notified of schema changes