Skip to content
Ask AI about this
Help improve this page

Redshift Serverless workgroups should prohibit public access

A publicly accessible workgroup puts your Redshift Serverless endpoint on the internet, open to connection attempts from any IP. Even with tight security groups and strong credentials, you're still exposed to brute-force attempts, credential stuffing, and any authentication vulnerabilities that surface down the road.

Analytical workloads connect through private VPC networking, VPN, or PrivateLink. There's no legitimate reason for the endpoint to be publicly routable. Network-level isolation should be a given, not something you rely on security groups alone to enforce.

Retrofit consideration

Disabling public access on an existing workgroup triggers a brief reconfiguration. Clients using the public endpoint lose connectivity immediately, so make sure private networking is in place before flipping this setting.

Implementation

Choose the approach that matches how you manage Terraform.

Use AWS provider resources directly. See docs for the resources involved: aws_redshiftserverless_workgroup.

resource "aws_redshiftserverless_workgroup" "this" {
  namespace_name     = "example-namespace"
  security_group_ids = ["sg-12345678"]
  subnet_ids         = ["subnet-12345678", "subnet-12345678", "subnet-12345678"]
  workgroup_name     = "pofix-abc123"

  publicly_accessible = false
}

What this control checks

The control evaluates aws_redshiftserverless_workgroup and passes when publicly_accessible is set to false. It fails when the argument is true. The workgroup also needs private subnet_ids for actual network isolation, but subnet placement is outside this control's evaluation scope.

Common pitfalls

  • Default is safe but explicit is better

    The publicly_accessible argument defaults to false, but don't rely on that. Provider defaults shift across versions, and static analysis tools often flag omitted values as ambiguous. Set publicly_accessible = false explicitly in your config to document intent and prevent drift.

  • VPC subnet selection still matters

    Setting publicly_accessible = false stops public IP assignment, but a workgroup in a public subnet with a route to an internet gateway doesn't actually isolate the endpoint at the network layer and will raise questions during audits. Use private subnets in subnet_ids to make the private-only posture unambiguous.

  • Confusing workgroup with namespace settings

    Audit the wrong resource and you'll miss this entirely. publiclyAccessible is a workgroup attribute, not a namespace attribute. aws_redshiftserverless_namespace doesn't have this field. If your compliance checks are scanning namespace resources, the control will never evaluate correctly.

Audit evidence

Config rule evaluations against redshiftserverless:GetWorkgroup should show all workgroups with publiclyAccessible: false. The Redshift Serverless console confirms this per workgroup in the Network and Security section, where 'Publicly accessible' should read 'Off'.

Security Hub findings for this control should show PASSED across all accounts and regions. CloudTrail records for CreateWorkgroup and UpdateWorkgroup API calls provide a change history confirming no workgroup was created or reconfigured with publiclyAccessible: true.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: redshiftserverless_workgroup_restrict_public_access

  • AWS Config Managed Rule: REDSHIFT_SERVERLESS_WORKGROUP_NO_PUBLIC_ACCESS

  • Powerpipe Control: aws_compliance.control.redshiftserverless_workgroup_restrict_public_access

  • AWS Security Hub Control: RedshiftServerless.3

Last reviewed: 2026-03-09