RDS-linked subnet uses a /0 CIDR

Use valid address ranges for RDS subnets and review routing together with public-access settings.

Description

Subnets in an RDS subnet group need valid address blocks within the VPC range. Setting a subnet's cidr to 0.0.0.0/0 or its ipv6_cidr to ::/0 is not a valid AWS subnet configuration.

In AWS, a public subnet has a direct route to an internet gateway. A subnet using a private CIDR can still be public when it has such a route. Distinguish a /0 route destination from the address range assigned to the subnet itself when reviewing the configuration.

Potential impact

  • An invalid /0 subnet configuration causes deployment to fail.
  • Relying on a private address range alone to assess isolation can leave real internet access paths unnoticed.
  • When routing, public-access settings, and security groups permit external connections together, RDS can receive unwanted connection attempts.

Remediation

  • Assign valid, non-overlapping subnet CIDRs within the VPC address range. Changing a CIDR alone does not make a subnet private.
  • For an internal database, choose subnets without direct routes to an internet gateway and check the actual members of the subnet group.
  • Review publicly_accessible, security groups, and application connection paths together. Check the subnet group's Availability Zone requirements for your RDS configuration.

Examples

These excerpts compare subnet address settings and are not deployment configurations. The first example's /0 is not a valid subnet CIDR. Both omit the second subnet declaration and routing configuration. Review the legacy module names, resource identifiers, and RDS settings for your environment as well.

Before

yaml
- name: create minimal aurora instance
  community.aws.rds_instance:
    engine: aurora
    db_instance_identifier: ansible-test-aurora-db-instance
    instance_type: db.t2.small
    password: "{{ password }}"
    username: "{{ username }}"
    cluster_id: ansible-test-cluster
    db_subnet_group_name: my_subnet_group

- name: Add or change a subnet group
  community.aws.rds_subnet_group:
    state: present
    name: my_subnet_group
    description: My Fancy Ex Parrot Subnet Group
    subnets:
      - "{{ subnet1.subnet.id }}"
      - "{{ subnet2.subnet.id }}"

- name: Create subnet for database servers
  amazon.aws.ec2_vpc_subnet:
    state: present
    vpc_id: vpc-123456
    cidr: 0.0.0.0/0
  register: subnet1

After

yaml
- name: create minimal aurora instance
  community.aws.rds_instance:
    engine: aurora
    db_instance_identifier: ansible-test-aurora-db-instance
    instance_type: db.t2.small
    password: "{{ password }}"
    username: "{{ username }}"
    cluster_id: ansible-test-cluster
    db_subnet_group_name: my_private_subnet_group

- name: add private subnet group
  community.aws.rds_subnet_group:
    state: present
    name: my_private_subnet_group
    description: private database subnets
    subnets:
      - "{{ subnet_private_a.subnet.id }}"
      - "{{ subnet_private_b.subnet.id }}"

- name: create private subnet
  amazon.aws.ec2_vpc_subnet:
    state: present
    vpc_id: vpc-123456
    cidr: 10.0.1.16/28
  register: subnet_private_a

Explanation:

  • Before: 0.0.0.0/0 cannot be used as a subnet address range. A public subnet also needs a valid CIDR and appropriate routing.
  • After: The subnet address range is changed to 10.0.1.16/28. Check that this range is within the VPC and does not overlap other subnets. A name containing private or a private CIDR does not block internet routes.

References