Amazon Redshift - AnomalyArmor

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
Redshift Serverless

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

Go to AWS Console > Amazon Redshift > Serverless dashboard
Click on your workgroup
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:

Go to AWS Console > VPC > Security Groups
Find the security group attached to your Redshift cluster
Edit inbound rules
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

Enable “Publicly accessible” in cluster settings
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:

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

Connection timeout

Causes:

Firewall blocking connection
Cluster in private subnet without proper routing

Solutions:

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

Authentication failed

Causes:

Wrong password
User doesn’t exist
Case sensitivity issues

Solutions:

Verify password (copy-paste to avoid typos)
Confirm user exists: SELECT usename FROM pg_user;
Remember: Redshift usernames are case-sensitive when quoted

Try resetting the password:

ALTER USER anomalyarmor PASSWORD 'new-password';

Database does not exist

Causes:

Wrong database name
Case sensitivity

Solutions:

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

No tables found in discovery

Causes:

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

Solutions:

Test as the user:

SELECT * FROM svv_tables
WHERE table_schema = 'public' LIMIT 5;

Grant schema access:

GRANT USAGE ON SCHEMA public TO anomalyarmor;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO anomalyarmor;

Verify tables exist in expected schemas

SSL connection error

Causes:

SSL configuration mismatch

Solutions:

AnomalyArmor uses SSL by default (required for Redshift)
Ensure your cluster has SSL enabled (default setting)
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

Common Questions

Does AnomalyArmor support both provisioned Redshift clusters and Redshift Serverless?

Yes. Both use the same PostgreSQL-wire-compatible connector. For Serverless, set the endpoint to the workgroup’s connection URL. For provisioned, use the cluster endpoint. SSL is required in both cases.

Can AnomalyArmor monitor Redshift Spectrum external tables?

Yes. External tables (backed by S3) are discovered and cataloged alongside local Redshift tables. Freshness works if the external table has a timestamp column queryable via a standard MAX(ts) - Spectrum resolves this against S3 metadata when partitioned appropriately.

Do I need to VACUUM or ANALYZE for AnomalyArmor to work correctly?

No for discovery or schema drift - those read the catalog directly. For row-count and statistical metrics, Redshift’s SVV_TABLE_INFO and SVV_ALL_COLUMNS views are used; these are maintained by Redshift automatically. You don’t need to add any VACUUM / ANALYZE to your maintenance.

Can I connect AnomalyArmor to Redshift in a private VPC without IP allowlisting?

Yes, via VPC peering or AWS PrivateLink (Enterprise plans). Both keep traffic off the public internet. For non-Enterprise, allowlist AnomalyArmor’s static IPs in your Redshift cluster’s security group.

Getting Started

Core Concepts

Data Sources

Detect Schema Changes

Monitor Data Health

Coverage Tiers

Get Notified

Understand Your Data

Organize & Tag

Guides

Account & Settings

Security

Help

Downloads

Documentation Index

​Supported Platforms

​Connection Settings

​Finding Your Connection Details

​Creating a Read-Only User

​Verifying Permissions

​Network Configuration

​Security Groups

​Public Accessibility

​SSL/TLS

​Redshift Serverless Considerations

​Automatic Scaling

​Idle Workgroups

​Database Name

​What We Monitor

​Metadata Captured

​What We Query

​Multiple Schemas

​Redshift Spectrum (External Tables)

​Troubleshooting

​Best Practices

​Use a Dedicated User

​Use Read Replicas (if available)

​Grant Minimal Permissions

​Schedule Discovery After ETL

​Limitations

​Coming Soon

​Common Questions

​Does AnomalyArmor support both provisioned Redshift clusters and Redshift Serverless?

​Can AnomalyArmor monitor Redshift Spectrum external tables?

​Do I need to VACUUM or ANALYZE for AnomalyArmor to work correctly?

​Can I connect AnomalyArmor to Redshift in a private VPC without IP allowlisting?

​Next Steps

Run Discovery

Set Up Alerts

Supported Platforms

Connection Settings

Finding Your Connection Details

Creating a Read-Only User

Verifying Permissions

Network Configuration

Security Groups

Public Accessibility

SSL/TLS

Redshift Serverless Considerations

Automatic Scaling

Idle Workgroups

Database Name

What We Monitor

Metadata Captured

What We Query

Multiple Schemas

Redshift Spectrum (External Tables)

Troubleshooting

Best Practices

Use a Dedicated User

Use Read Replicas (if available)

Grant Minimal Permissions

Schedule Discovery After ETL

Limitations

Coming Soon

Common Questions

Does AnomalyArmor support both provisioned Redshift clusters and Redshift Serverless?

Can AnomalyArmor monitor Redshift Spectrum external tables?

Do I need to VACUUM or ANALYZE for AnomalyArmor to work correctly?

Can I connect AnomalyArmor to Redshift in a private VPC without IP allowlisting?

Next Steps