# Ensure Redshift clusters are not publicly accessible

- Source: https://support.icompaas.com/support/solutions/articles/a_1793292228719864-ensure-redshift-clusters-are-not-publicly-accessible
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224)
- Last updated: 2026-10-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that no Amazon Redshift cluster is reachable from the Internet. A cluster is flagged only when all three conditions apply together: its endpoint is set as publicly accessible, at least one subnet of its subnet group routes 0.0.0.0/0 to an Internet gateway, and one of its security groups allows inbound traffic on all TCP ports (0 to 65535), or all traffic, from any address (0.0.0.0/0 or ::/0). Security groups that open only specific ports, such as 5439, are not detected, and a publicly accessible cluster in private subnets is not flagged.

**Rationale**

An Internet-exposed Redshift endpoint lets any host attempt to connect to the data warehouse. Attackers can try to brute-force credentials, run unauthorized queries, extract data or change schemas, and scanning or abuse can exhaust connections and disrupt the service. Disabling public access, keeping clusters in private subnets and limiting security groups to trusted networks ensures that only approved clients can reach the cluster.

**Impact**

-   Removes direct Internet access to the cluster and its data
    
-   Reduces the risk of credential attacks, data theft and service disruption
    
-   Clients that connect over the Internet lose access and must instead connect from inside the VPC, through a VPN, AWS Direct Connect, VPC peering or a bastion host
    

**Default Value**

New provisioned Redshift clusters are created without public accessibility unless the option is explicitly turned on. Security groups have no inbound rules unless they are added.

**Pre-Requisites**

-   IAM permissions: redshift:DescribeClusters, redshift:DescribeClusterSubnetGroups, redshift:ModifyCluster, ec2:DescribeRouteTables and ec2:DescribeSecurityGroupRules
    
-   A list of the clients and applications that connect to the cluster and how they will connect privately
    

**Remediation**

**Test Plan**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon Redshift console and select **Clusters**.
    
3.  Select a cluster and open the **Properties** tab. In **Network and security settings**, check **Publicly accessible**, the subnet group and the VPC security groups.
    
4.  If the cluster is publicly accessible, open the VPC console and check whether any subnet of the subnet group uses a route table with a route whose destination is 0.0.0.0/0 and whose target is an Internet gateway (igw-...). Only such a subnet counts as public.
    
5.  If so, check the inbound rules of the cluster's security groups for any **All traffic** rule, or TCP rule with port range 0 to 65535, whose source is 0.0.0.0/0 or ::/0.
    
6.  Repeat for each cluster in each region in use.
    
7.  If all three conditions are true, follow the implementation steps.
    

**CLI:**

Show the public access setting, subnet group and security groups of each cluster:

aws redshift describe-clusters --region <REGION> --query "Clusters\[\].\[ClusterIdentifier,PubliclyAccessible,ClusterSubnetGroupName,VpcSecurityGroups\[\].VpcSecurityGroupId\]" --output json

List the subnets of the cluster's subnet group:

aws redshift describe-cluster-subnet-groups --region <REGION> --cluster-subnet-group-name <SUBNET\_GROUP\_NAME> --query "ClusterSubnetGroups\[\].Subnets\[\].SubnetIdentifier" --output table

Show the routes of a subnet (if no route table is returned, the subnet uses the VPC's main route table):

aws ec2 describe-route-tables --region <REGION> --filters Name=association.subnet-id,Values=<SUBNET\_ID> --query "RouteTables\[\].Routes\[\].\[DestinationCidrBlock,DestinationIpv6CidrBlock,GatewayId\]" --output table

List the inbound rules of a cluster security group that are open to any address:

aws ec2 describe-security-group-rules --region <REGION> --filters Name=group-id,Values=<SECURITY\_GROUP\_ID> --query "SecurityGroupRules\[?IsEgress==\\\`false\\\` && (CidrIpv4=='0.0.0.0/0' || CidrIpv6=='::/0')\].\[SecurityGroupRuleId,IpProtocol,FromPort,ToPort\]" --output table

The cluster fails if PubliclyAccessible is true, at least one of its subnets has a route with destination 0.0.0.0/0 whose target is an Internet gateway (igw-...), and a security group has an inbound rule from 0.0.0.0/0 or ::/0 with protocol -1 (all traffic) or protocol tcp with port range 0 to 65535. A publicly accessible cluster in private subnets, or whose security groups open only specific ports such as 5439 to the Internet, passes.

**Implementation Steps**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon Redshift console and select **Clusters**.
    
3.  Select the cluster and choose **Actions**, then **Modify publicly accessible setting**.
    
4.  Turn off public access and choose **Save changes**.
    
5.  Also remove or restrict any inbound security group rule that allows 0.0.0.0/0 or ::/0, so that only trusted CIDR ranges or security groups can reach the cluster port.
    
6.  Repeat for each affected cluster in each region in use.
    

**CLI:**

Turn off public access for the cluster:

aws redshift modify-cluster --region <REGION> --cluster-identifier <CLUSTER\_ID> --no-publicly-accessible

Remove an open inbound rule from a cluster security group, using the rule ID from the Test Plan:

aws ec2 revoke-security-group-ingress --region <REGION> --group-id <SECURITY\_GROUP\_ID> --security-group-rule-ids <SECURITY\_GROUP\_RULE\_ID>

**Backout Plan**

Before making changes, save the cluster's network settings and security group rules:

aws redshift describe-clusters --region <REGION> --cluster-identifier <CLUSTER\_ID> > redshift-cluster-backup.json  
aws ec2 describe-security-group-rules --region <REGION> --filters Name=group-id,Values=<SECURITY\_GROUP\_ID> > <SECURITY\_GROUP\_ID>-rules-backup.json

To roll back:

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon Redshift console, select the cluster and choose **Actions**, then **Modify publicly accessible setting**.
    
3.  Turn on public access and choose **Save changes**.
    
4.  Re-add any removed security group rules using the saved backup.
    

**CLI:**

aws redshift modify-cluster --region <REGION> --cluster-identifier <CLUSTER\_ID> --publicly-accessible

Note: rolling back exposes the cluster to the Internet again. Use it only as a temporary measure.

**Reference**

-   [https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html)
    
-   [https://docs.aws.amazon.com/redshift/latest/mgmt/rs-ra3-VPC-public-private.html](https://docs.aws.amazon.com/redshift/latest/mgmt/rs-ra3-VPC-public-private.html)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/redshift/modify-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/redshift/modify-cluster.html)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.