Redshift Audit Logging Disabled: Why It Matters and How to Fix It

Amazon Redshift sits at the center of a lot of analytics stacks, and the data it holds is usually some of the most sensitive in an organization: customer records, financial transactions, behavioral data, and more. When audit logging is off, every connection and query against that data leaves no trace. The Lensix redshift_nologging check looks for exactly this gap and flags any cluster where audit logging has not been enabled.

---

What this check detects

The check inspects each Redshift cluster in your account and reports whether audit logging is enabled. Redshift audit logging captures three categories of information:

• Connection log — authentication attempts, connections, and disconnections, including the source IP, username, and SSL details.
• User log — changes to database user definitions, such as creating, dropping, or altering users.
• User activity log — every query and command run against the cluster (this one requires the enable_user_activity_logging parameter to be set as well).

When logging is disabled, none of this is recorded. The cluster will happily serve queries, but you have no durable record of who did what, from where, and when.

---

Why it matters

The risk here is not theoretical. Audit logs are the primary evidence you have when investigating a data breach, an insider misuse incident, or even an accidental mass deletion. Without them, you are guessing.

Incident response goes blind

Imagine credentials for a Redshift user leak through a committed config file or a compromised laptop. With audit logging on, you can see exactly which queries that user ran, when the connection started, and what data was touched. Without it, your incident response team can confirm the credentials existed but cannot tell you whether the attacker pulled one row or ten million.

Insider threats stay invisible

Not every threat comes from outside. An analyst with legitimate access who exfiltrates customer data leaves no record if logging is off. Connection and user activity logs are often the only way to spot abnormal query patterns, like a sudden full-table export at 3 a.m.

Compliance failures

Frameworks including PCI DSS, HIPAA, SOC 2, and ISO 27001 all expect audit trails for systems handling sensitive data. An auditor asking "show me who accessed this table last quarter" is a conversation you do not want to have with logging disabled.

---

How to fix it

You can enable logging on an existing cluster without downtime. Pick a destination first: CloudWatch Logs (recommended for most teams) or an S3 bucket.

Option 1: Enable logging to CloudWatch (CLI)

aws redshift enable-logging \
  --cluster-identifier my-redshift-cluster \
  --log-destination-type cloudwatch \
  --log-exports connectionlog useractivitylog userlog

Option 2: Enable logging to S3 (CLI)

The target bucket needs a policy that allows Redshift's log delivery service to write to it. Create the bucket and attach the policy first:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RedshiftLogDelivery",
      "Effect": "Allow",
      "Principal": {
        "Service": "redshift.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-redshift-audit-logs/*"
    },
    {
      "Sid": "RedshiftGetBucketAcl",
      "Effect": "Allow",
      "Principal": {
        "Service": "redshift.amazonaws.com"
      },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::my-redshift-audit-logs"
    }
  ]
}

Then enable logging:

aws redshift enable-logging \
  --cluster-identifier my-redshift-cluster \
  --bucket-name my-redshift-audit-logs \
  --s3-key-prefix audit/

Don't forget user activity logging

The connection and user logs work out of the box, but the user activity log (the one that records actual queries) depends on a parameter group setting. If your cluster uses the default parameter group, you will need a custom one because the default cannot be modified.

# Create a custom parameter group
aws redshift create-cluster-parameter-group \
  --parameter-group-name audit-enabled-pg \
  --parameter-group-family redshift-1.0 \
  --description "Parameter group with user activity logging"

# Turn on user activity logging
aws redshift modify-cluster-parameter-group \
  --parameter-group-name audit-enabled-pg \
  --parameters ParameterName=enable_user_activity_logging,ParameterValue=true

# Apply it to the cluster
aws redshift modify-cluster \
  --cluster-identifier my-redshift-cluster \
  --cluster-parameter-group-name audit-enabled-pg

Console steps

1. Open the Amazon Redshift console and select your cluster.
2. Go to the Properties tab and find the Database configurations or Audit logging section.
3. Click Edit audit logging, toggle it on, and choose CloudWatch or an S3 bucket as the destination.
4. Select the log types you want exported (connection, user, user activity).
5. Save changes. For user activity logs, edit the cluster's parameter group and set enable_user_activity_logging to true, then reboot.

---

Fixing it in infrastructure as code

If you manage Redshift with Terraform, enabling logging is a single nested block on the cluster resource, so you can enforce it for every cluster going forward.

resource "aws_redshift_cluster" "analytics" {
  cluster_identifier = "analytics"
  database_name      = "warehouse"
  node_type          = "ra3.xlplus"
  number_of_nodes    = 2
  master_username    = "admin"

  cluster_parameter_group_name = aws_redshift_parameter_group.audit.name

  logging {
    enable               = true
    log_destination_type = "cloudwatch"
    log_exports          = ["connectionlog", "userlog", "useractivitylog"]
  }
}

resource "aws_redshift_parameter_group" "audit" {
  name   = "audit-enabled-pg"
  family = "redshift-1.0"

  parameter {
    name  = "enable_user_activity_logging"
    value = "true"
  }
}

For CloudFormation, set the LoggingProperties on the AWS::Redshift::Cluster resource and reference a parameter group with the activity logging parameter enabled.

---

How to prevent it from happening again

Remediating one cluster is fine, but the goal is to make a cluster without logging impossible to ship. A few layers work well together.

Policy as code in CI/CD

Catch the misconfiguration before it reaches AWS. With a tool like Checkov or OPA scanning your Terraform plans, you can block any merge that defines a Redshift cluster without a logging block.

# Run Checkov against your Terraform directory in CI
checkov -d ./infra --check CKV_AWS_71

Continuous detection with Lensix

Drift happens. Someone spins up a cluster by hand, or restores a snapshot into a new cluster that does not inherit the logging config. Lensix runs the redshift_nologging check continuously across your accounts so a non-logging cluster surfaces within minutes rather than at audit time.

Service Control Policies and AWS Config

An AWS Config managed rule, redshift-audit-logging-enabled, can flag and even auto-remediate clusters through an SSM automation document. Pair it with an organization-wide deployment so every account is covered.

---

Best practices

• Enable all three log types. Connection logs alone are useful, but the user activity log is what answers "what did they actually run."
• Set retention deliberately. For S3, use a lifecycle policy to transition logs to cheaper storage and to match your compliance retention window. For CloudWatch, set a retention period rather than leaving logs forever.
• Lock down the log destination. Audit logs are sensitive. Encrypt the S3 bucket, block public access, and restrict who can read the log group or bucket.
• Centralize logs. Ship Redshift logs into the same SIEM or log lake as the rest of your security telemetry so analysts can correlate Redshift activity with network and IAM events.
• Monitor, don't just store. Logs no one reads add little value. Build alerts for failed authentication spikes, off-hours access, and large data exports.
• Apply it to snapshots and restores. A restored cluster is a brand new cluster. Make logging part of your restore runbook so recovered environments are not running dark.

Audit logging is one of those controls that costs almost nothing to enable and is invaluable the day you need it. Turn it on everywhere, enforce it in your pipeline, and let continuous monitoring keep it that way.