The module defaults to
create_db_subnet_group = false. In most cases you will either create a subnet group through a VPC module (like terraform-aws-modules/vpc/aws) and pass its name via db_subnet_group_name, or set create_db_subnet_group = true and provide subnet_ids.Variables
| Variable | Default | Description |
|---|---|---|
create_db_subnet_group | false | Whether to create a DB subnet group. |
db_subnet_group_name | null | Name of the subnet group to create or reference. When creating, defaults to the instance identifier. |
db_subnet_group_use_name_prefix | true | When true, appends a unique suffix to the name. Set to false to use the exact name. |
subnet_ids | [] | List of VPC subnet IDs to include. Required when create_db_subnet_group = true. |
db_subnet_group_description | null | Description for the subnet group. |
db_subnet_group_tags | {} | Additional tags to apply to the subnet group resource. |
Setup
Identify private subnets across multiple AZs
RDS instances should always be placed in private subnets — not public subnets. Ensure your VPC has at least two private subnets in different AZs. Most production deployments use three AZs for resilience.If you are using the
terraform-aws-modules/vpc/aws module, it creates a database_subnet_group output that you can reference directly:Use existing subnet group
If a subnet group already exists in AWS and is not managed by this module:Best practices
Use private subnets
Never place RDS instances in public subnets. Use dedicated database subnets that have no route to an internet gateway.
Span multiple AZs
Include subnets from at least two Availability Zones. For Multi-AZ deployments, AWS needs to place the standby replica in a different AZ.
Separate database subnets
Use dedicated database subnets rather than reusing your application’s private subnets. This allows independent routing and network ACL control.
Tag consistently
Use
db_subnet_group_tags to add environment or team tags separate from the global tags variable.