XEIZE
/Vulnerability documentation/IaC/CloudFormation/AWS/RDS-linked subnet uses a /0 CIDR

RDS-linked subnet uses a /0 CIDR

RDS subnets need valid VPC address ranges and appropriate routing. Replace invalid /0 ranges and restrict the actual connection paths for private databases.

Description

Using 0.0.0.0/0 for CidrBlock or ::/0 for Ipv6CidrBlock creates an invalid AWS subnet configuration for an RDS DB subnet group. These values cover the entire address space; choose a supported range that can be assigned to the subnet.

A subnet's address range and a route's destination serve different purposes. A subnet with a direct route to an internet gateway is public. It can still use private address space such as 10.0.0.0/24. For a private database, configure its subnet group, routing, PubliclyAccessible setting and security groups together to allow only the connections it needs.

Potential impact

  • An invalid subnet CIDR can cause resource creation or updates to fail.
  • Treating a private address range as proof of private connectivity can leave an unintended internet path in place. Public addressing combined with permissive network access can allow external clients to attempt database connections.

Remediation

  • Choose an AWS-supported subnet CIDR within the VPC's address range and avoid overlap with other subnets. Leave enough available addresses for maintenance and failover.
  • For a private database, use subnets without direct internet-gateway routes. Review every subnet and route in the DB subnet group, set PubliclyAccessible: false, and allow only required clients through security groups. Prepare the application's private connection path and test connectivity before the change.
  • Check the subnet-group requirements for the deployment location. A typical regional deployment requires subnets in two different Availability Zones, with a separate exception for Local Zones. Validate required properties, references and the impact on an existing database.

Examples

These incomplete templates compare subnet CIDRs. The first omits the mySubnet1 definition; both omit DBSubnetGroupDescription, VpcId and properties needed to create the database. The second also lacks the two-zone configuration needed for a typical regional deployment. The logical IDs differ, so check the target resources when updating an existing stack.

Before

yaml
Resources:
  Positive1:
    Type: AWS::RDS::DBInstance
    Properties:
      DBSubnetGroupName:
        Ref: myDBSubnetGroup
  myDBSubnetGroup:
    Type: "AWS::RDS::DBSubnetGroup"
    Properties:
      SubnetIds:
        - Ref: mySubnet1
        - Ref: mySubnet2
  mySubnet2:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 0.0.0.0/0

After

yaml
Resources:
  Negative1:
    Type: AWS::RDS::DBInstance
    Properties:
      DBSubnetGroupName:
        Ref: myDBSubnetGroup0
  myDBSubnetGroup0:
    Type: "AWS::RDS::DBSubnetGroup"
    Properties:
      SubnetIds:
        - Ref: mySubnet10
  mySubnet10:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.0.0/24

Explanation:

  • Before: 0.0.0.0/0 is not a valid AWS subnet CIDR. A public subnet is configured through routing, not by assigning this address range.
  • After: 10.0.0.0/24 has a supported subnet size, provided it fits the VPC range and does not overlap other subnets. Private access also requires the routes, public-access setting and security groups omitted from this example.

References

XEIZE DocumentationTechnical support