route53_vpc_association_authorization + aws_route53_zone_association makes Terraform attempt to delete associations on subsequent runs

[fideloper]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform AWS Provider Version

Terraform v0.12.29
+ provider.aws v3.3.0
+ provider.template v2.1.2

Affected Resource(s)

• aws_route53_zone
• aws_route53_vpc_association_authorization
• aws_route53_zone_association

Terraform Configuration Files

You should be able to reproduce this using the specific example from the docs on aws_route53_vpc_association_authorization here.

Here is my lightly-changed version of it (difference perhaps is the use of a data provider?

# Alternative Provider
provider "aws" {
  alias = "alternative"
}

data "aws_vpc" "alt_vpc" {
  provider = aws.alternative

  filter {
    name   = "tag:Environment"
    values = ["staging"]
  }

  filter {
    name   = "tag:Project"
    values = ["my-project"]
  }

  filter {
    name   = "tag:Peering"
    values = ["yes"]
  }
}

resource "aws_route53_zone" "systems_private" {
  name = var.systems_domain_name

  vpc {
    vpc_id = var.vpc_id
  }

  tags = {
    Name        = "${var.infra_name} ${var.infra_env} Private Systems Zone"
    Environment = var.infra_env
    Project     = var.infra_name
    Role        = "systems-private-zone"
    VPC         = var.vpc_id
    ManagedBy   = "terraform"
  }
}

resource "aws_route53_vpc_association_authorization" "vpc_association" {
  vpc_id  = data.aws_vpc.alt_vpc.id
  zone_id = aws_route53_zone.systems_private.id
}

resource "aws_route53_zone_association" "vpc_zone_association" {
  provider = aws.alternative

  vpc_id  = aws_route53_vpc_association_authorization.vpc_association.vpc_id
  zone_id = aws_route53_vpc_association_authorization.vpc_association.zone_id
}

This works great on the first run. On subsequent runs, Terraform attempts to delete all but the first in-line associated VPC.

Expected Behavior

This works on the first run. On subsequent runs, I expect the zone associations to remain in place.

We need to mix the use of in-line VPC associations with the use of the separate aws_route53_zone_association using this method, otherwise I believe we'd get a circular dependency issue.

Actual Behavior

On subsequent runs, I see two things that seem odd:

First:

The main issue: Terraform believes it needs to delete all but one associated VPC association. The one VPC association it keeps is the one added as an in-line block within the aws_route53_zone resource (which requires at least one to be a private zone):

  # module.dns.aws_route53_zone.systems_private will be updated in-place
  ~ resource "aws_route53_zone" "systems_private" {
        comment       = "Managed by Terraform"
        force_destroy = false
        id            = "<redacted>"
        name          = "redacted.systems"
        name_servers  = [
            "ns-0.awsdns-00.com.",
            "ns-1024.awsdns-00.org.",
            "ns-1536.awsdns-00.co.uk.",
            "ns-512.awsdns-00.net.",
        ]

        zone_id       = "<redacted>"

    # It wants to delete any VPC other than the original/first in-line VPC added
    # This is the alternative account VPC association
      - vpc {
          - vpc_id     = "vpc-<alt_vpc-id-redacted>" -> null
          - vpc_region = "us-east-2" -> null
        }
        vpc {
            vpc_id     = "vpc-<redacted>"
            vpc_region = "us-east-2"
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.

I originally had 3 VPC's associated, in which case it wanted to delete 2 of them and keep only the one added as an in-line block

Second

All VPC associations added via aws_route53_zone_association appears as an in-line VPC association within the plan, rather than a separate resource, which feels like a clue towards what might be a bug here.

Steps to Reproduce

You should be able to reproduce this using the specific example from the docs on aws_route53_vpc_association_authorization here.

1. Setup the appropriate HCL
2. terraform apply to create the resources
3. terraform plan or terraform apply again to see it attempting to delete the VPC associations added as a aws_route53_zone_association resource

The documentation (route53_zone) says we cannot mix in-line blocks with aws_route53_zone_association, BUT we also HAVE to have one in-line block for it to be a private hosted zone, so how could we ever use the aws_route53_zone_association resource?

Let me know if I can provide additional information!

[bflad]

Hi @fideloper 👋 Thank you for reporting this and sorry you ran into trouble there. Indeed the documentation is missing an important piece, which we note in the aws_route53_zone_association resource example, but not the aws_route53_vpc_association_authorization resource documentation:

resource "aws_route53_zone" "example" {
  # ... other configuration ...

  lifecycle {
    ignore_changes = [vpc]
  }
}

Route 53 requires an initial VPC to ensure its a private zone but Terraform detect any aws_route53_zone_association resources on the same Hosted Zone as drift in the aws_route53_zone resource. Configurations need to explicitly use ignore_changes in this case. The aws_route53_vpc_association_authorization example should also include that ignore_changes configuration for the aws_route53_zone resource.

If you or anyone is interested in fixing the documentation, the source for it lives in this repository in the website/docs/r/route53_vpc_association_authorization.html.markdown file. 👍

[fideloper]

Thanks! That works. I added a quick PR to the docs here.

[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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!