Terraform: Issue creating db_cluster_instance without default VPC

[colinmutter]

Got the following error when creating instances within an aurora cluster.

• aws_rds_cluster_instance.rdsmain_instance.0: InvalidSubnet: No default subnet detected in VPC. Please contact AWS Support to recreate default Subnets. status code: 400
• aws_rds_cluster_instance.rdsmain_instance.1: InvalidSubnet: No default subnet detected in VPC. Please contact AWS Support to recreate default Subnets. status code: 400

resource "aws_rds_cluster" "rdsmain" {
  cluster_identifier = "aurora-main"
  availability_zones = ["us-east-1a","us-east-1c"]
  database_name = "foobar"

  master_username = "user"
  master_password = "pass"

  vpc_security_group_ids = [ "${aws_security_group.rds.id}" ]
  db_subnet_group_name = "${aws_db_subnet_group.rdsmain_private.name}"
}

resource "aws_rds_cluster_instance" "rdsmain_instance" {
  count = 2
  identifier = "instance-0${count.index + 1}"
  cluster_identifier = "${aws_rds_cluster.rdsmain.id}"
  instance_class = "db.r3.large"
}

resource "aws_db_subnet_group" "rdsmain_private" {
  name = "rdsmain-private"
  description = "Private subnets for RDS instance"

  # Comma sep. list of subnet ids from the VPC
  subnet_ids = [ "${split(",", module.vpc1.private_subnets)}" ]
}

resource "aws_security_group" "rds" {
  name = "rds-sg"
  description = "Allow MySQL traffic to rds"
  vpc_id = "${module.vpc1.vpc_id}"
}

resource "aws_security_group_rule" "public_to_rds" {
  type = "ingress"
  from_port = 3306
  to_port = 3306
  protocol = "tcp"
  security_group_id = "${aws_security_group.rds.id}"
  cidr_blocks = ["${split(",", var.vpc_public_subnets.1)}"]
}

The VPC in question was also created by terraform and is NOT the amazon default VPC.

As an example,

module "vpc1" {
  source = "github.com/terraform-community-modules/tf_aws_vpc"

  name = "custom-vpc"
  cidr = "10.0.0.0/16"
  private_subnets = "10.0.1.0/24,10.0.2.0/24,10.0.3.0/24"
  public_subnets  = "10.0.101.0/24,10.0.102.0/24,10.0.103.0/24"
  azs      = "us-east-1a,us-east-1b,us-east-1c"
}

[james-huston]

+1, this still appears to be an issue and makes it impossible to TF RDS in the non default VPC/subnets.

[phinze]

Hi folks, worked on reproducing this today, and I did run into a few problems getting the above config working, but I couldn't reproduce the No default subnet detected in VPC. error - which makes me wonder if the upstream API has changed its behavior slightly. Here's the tweaks I had to make to get it working though:

• The db_subnet_group_name needs to be assigned to the same thing on the rds_cluster_instance as it is on the rds_cluster
• The pass needs to be 8 characters or more.

Here's a version of the above config that works for me in us-east-1 (YMMV depending on your available AZs in your account):

provider "aws" {
  region = "us-east-1"
}

variable "azs" {
  default = "us-east-1b,us-east-1c"
}

resource "aws_vpc" "main" {
  cidr_block = "10.123.0.0/16"
}

# Creating one subnet in each AZ
resource "aws_subnet" "private" {
  vpc_id = "${aws_vpc.main.id}"
  count             = "${length(split(",", var.azs))}"
  availability_zone = "${element(split(",", var.azs), count.index)}"
  cidr_block        = "10.123.${count.index}.0/24"
}
resource "aws_rds_cluster" "rdsmain" {
  cluster_identifier     = "aurora-main"
  database_name          = "foobar"
  master_username        = "user"
  master_password        = "passpass"
  vpc_security_group_ids = [ "${aws_security_group.rds.id}" ]
  db_subnet_group_name   = "${aws_db_subnet_group.rdsmain_private.name}"
}

resource "aws_rds_cluster_instance" "rdsmain_instance" {
  count                = 2
  identifier           = "instance-0${count.index + 1}"
  cluster_identifier   = "${aws_rds_cluster.rdsmain.id}"
  instance_class       = "db.r3.large"
  db_subnet_group_name = "${aws_db_subnet_group.rdsmain_private.name}"
}

resource "aws_db_subnet_group" "rdsmain_private" {
  name        = "rdsmain-private"
  description = "Private subnets for RDS instance"
  subnet_ids  = [ "${aws_subnet.private.*.id}" ]
}

resource "aws_security_group" "rds" {
  name        = "rds-sg"
  description = "Allow MySQL traffic to rds"
  vpc_id      = "${aws_vpc.main.id}"
}

resource "aws_security_group_rule" "public_to_rds" {
  type              = "ingress"
  from_port         = 3306
  to_port           = 3306
  protocol          = "tcp"
  security_group_id = "${aws_security_group.rds.id}"
  cidr_blocks       = ["10.0.0.0/16"]
}

Let me know if this clears things up on your side!

[james-huston]

I can confirm that this does appear to be working now for me on a clean config. I don't remember exactly what account I had this issue in originally so I can't retest easily. It's possible the account is one where we deleted the default VPC and that is what triggers the issue. I will try to find time to research.

Thanks for the response!

[catsby]

Hey Friends – looks like we've cleared things up here. Please let me know if there's more for us to look into here!

[colinmutter]

Did you all try it on an account with a deleted default VPC? That was most definitely the original issue. Thanks!

[eliasdorneles]

I am having this same issue w/ Terraform v0.12.20 and aws provider 2.51.0

It's indeed an account with a deleted default VPC, I've got:

• a VPC module created with terraform-aws-modules/vpc/aws using the option create_database_subnet_group = true
• a aws_db_instance which depends_on the VPC module and points to its subnet with db_subnet_group_name = module.vpc.database_subnet_group

The RDS instance fails to create, complaining about the missing default subnet (which was deleted in this account precisely to avoid mistakenly creating resources without assigning the correct subnet).

[eliasdorneles]

Oh, sorry, I've just figure out my problem -- I had an empty value for the database_subnets of the VPC :see_no_evil:

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.