RDS cross-region read replica placed in wrong VPC (MySQL 5.6)

[nTraum]

I'm currently trying to set up a cross-region read replica for a MySQL 5.6 RDS cluster via terraform v0.8.6.

As stated in the AWS docs, this can be done by specifying the ARN of the source database:

resource "aws_db_instance" "mysql" {
  engine                  = "mysql"
  identifier              = "${var.name}-${var.uid}"
  allocated_storage       = "${var.allocated_storage}"

  engine_version          = "${var.engine_version}"
  instance_class          = "${var.instance_class}"
  username                = "${var.username}"
  password                = "${var.password}"
  storage_type            = "${var.storage_type}"
  availability_zone       = "${var.availability_zone}"
  replicate_source_db     = "arn:aws:rds:eu-west-1:123456789:db:my-fancy-database"
  maintenance_window      = "${var.maintenance_window}"
  multi_az                = "${var.multi_az}"
  publicly_accessible     = "${var.publicly_accessible}"
  backup_retention_period = "${var.backup_retention_period}"

  vpc_security_group_ids  = ["${aws_security_group.mysql.id}"]

  db_subnet_group_name    = "${aws_db_subnet_group.mysql.name}"
  parameter_group_name    = "${aws_db_parameter_group.mysql.name}"
}

Running terraform plan shows the desired output (correct security groups etc).
Terraform does create the read replica successfully when applying, but always places it in the default VPC (instead of the one specified).

Interestingly enough, this only happens when the replicate_source_db parameter is set. Without, the resource gets placed in the correct VPC (incl. correct security groups).

A consecutive terraform plan afterwards shows a recreation of that read replica to assign the correct db_subnet_group_name to it (default ones are chosen instead).

I'm fairly (TM) certain this is a bug in terraform. If I create the read replica via AWS' web console, it works.

What would be the most useful information for you / us to debug this? Providing a minimum 'failing' example would be quite some work as this is read replica is part of a reasonably sized stack. Would running it with TF_DEBUG produce useful output? If so, at which level?

[catsby]

Hey @nTraum thanks for writing in – I don't think I need any more information, I can see the issue(s) in the code now that you point this out. I'll see about getting a patch in...

[catsby]

Fwiw, the patch for this should be as simple as adding db_subnet_group_name to the request built and sent in this block:

• https://github.com/hashicorp/terraform/blob/master/builtin/providers/aws/resource_aws_db_instance.go#L268-L294

It's not well documented on the AWS API Documentation on the web (that I found), but the SDK explains it like so:

    // Specifies a DB subnet group for the DB instance. The new DB instance will
    // be created in the VPC associated with the DB subnet group. If no DB subnet
    // group is specified, then the new DB instance is not created in a VPC.
    //
    // Constraints:
    //
    //  Can only be specified if the source DB instance identifier specifies a
    // DB instance in another region. The specified DB subnet group must be in the
    // same region in which the operation is running.  All Read Replicas in one
    // region that are created from the same source DB instance must either: Specify
    // DB subnet groups from the same VPC. All these Read Replicas will be created
    // in the same VPC.Not specify a DB subnet group. All these Read Replicas will
    // be created outside of any VPC.

[nTraum]

Thanks for the quick reply and the detailed explanation @catsby, appreciate it!

[listenrightmeow]

I can confirm that adding db_subnet_group_name results in the same issue as well.

[ghost]

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.