How to trace through who is creating hosted zones?

We have xxxxxx.yyy.com created twice(public hosted zone) and zzzz.wwww.com created twice(private hosted zone) and then different things adding records to each of those during full creation of a new datacenter. We do not have this on previous existing accounts as both just use the existing domains somehow.

I am trying to figure out how to use terraform graph to see how to change the code so that all my resources depend on the ‘same’ route53 hosted zone creation and to eliminate the duplicate creation. Is terraform graph the wrong command?

Someone else created this the output of terraform graph looks wrong to me but I am not sure. There is a subgraph “root” with 3000 lines and seems like no other subgraphs. That seems very odd to me. Is that typical?

More detail from my zones. Is this bad (seems we have 3 zone declarations for public_zone and we only have one public hosted zone ) →

93 “[root] module.ecs_backend.data.aws_route53_zone.public_zone (expand)” [label = “module.ecs_backend.data.aws_route53_zone.public_zone”, shape = “box”]

241 “[root] module.route53_private_tray_domain.module.route53_hosted_zone.aws_route53_zone.public_zone (expand)” [label = “module.route53_private_tray_domain.module.route53_hosted_zone.aws_route53_zone.public_zone”, shape = "bo

246 “[root] module.route53_public_tray_domain.module.route53_hosted_zone.aws_route53_zone.public_zone (expand)” [label = “module.route53_public_tray_domain.module.route53_hosted_zone.aws_route53_zone.public_zone”, shape = “box”

Hi @deantray,

terraform graph is primarily a learning/teaching tool and it doesn’t really scale very well for non-trivial configurations, since the graphviz automatic layout has a very hard time with graphs that contain lots of nodes or lots of edges.

With that said, the snippets from its output you’ve shared are describing three separate resources:

  • module.ecs_backend.data.aws_route53_zone.public_zone
  • module.route53_private_tray_domain.module.route53_hosted_zone.aws_route53_zone.public_zone
  • module.route53_public_tray_domain.module.route53_hosted_zone.aws_route53_zone.public_zone

The first one is a data.aws_route53_zone and so is a data resource rather than a managed resource, so I think you can ignore that one for the sake of what you’re asking here – it’s just fetching the data about some existing Route53 Zone, rather than declaring a new one.

If you intend there to be only one Route53 Zone managed by this configuration then I think those second two are the main point of concern: you seem to have you route53_private_tray_domain and route53_public_tray_domain both making separate calls to a “route53_hosted_zone” module; I’m guessing they are both calling the same module source since they both seem to have resource "aws_route53_zone" "public_zone" blocks inside.

I assume this is the same configuration we were just discussing over here:

If so, and if you intend to share the same Route53 Zone across all three of these modules ecs_backend, route53_private_tray_domain, and route53_public_tray_domain, then I would suggest moving the module "route53_hosted_zone" block up into the root module, as a sibling of the other three, and then pass its resulting zone into the other three modules.

In the other topic I discussed the idea of using an object type that’s a subset of a resource type as an input variable. You can also do a similar thing in an output value when data is flowing in the opposite direction, though of course in this case you must be the one to define how to construct the needed subset:

output "zone" {
  value = {
    name    = aws_route53_zone.public_zone.name
    zone_id = aws_route53_zone.public_zone.zone_id
    arn     = aws_route53_zone.public_zone.arn
  }
}

Terraform will also let you just return the entire resource instance object as the value if you want – value = aws_route53_zone.public_zone – but I find I typically want to be more selective in what I’m exposing because otherwise the result the caller sees can be affected by what version of the AWS provider you’re using, and that can be a surprising extra dependency.

As long as the object you return in the output value has attributes that are a superset of what the input variable expects, you can assign the output value directly to the input variable, instead of assigning the resource object itself:

module "example" {
  # ...

  route53_zone = module.route53_hosted_zone.zone
}