Description

• Refactor modules to group single resource modules into higher order modules
• Terraform v1.5.7 is now minimum supported version
• AWS provider v6.3 is now minimum supported version
• Replace zones and records module with new zone module that creates a Route53 zone, records, as well as association authorization, and DNSSEC signing key
• Remove delegation-sets module; users are encouraged to use the standalone resource for this functionality
• Remove resolver-rule-associations; this functionality can be implemented with the standalone resource or used within whats provided in the resolver-endpoint module
• Remove zone-cross-account-vpc-association; this functionality is split up with the association authorization resource added within the new zone module, and the association resource should be implemented on its own by users
• A new resolver-firewall-rule-group is added from the experimental proposal here
• Add support for Terragrunt wrappers which follow the norms of our other modules

Motivation and Context

• The prior zones and records modules were a single resource module over the route53 zone and record resources which on their own doesn't offer a lot of value and seemed to cause more issues than benefit. Moving resources that have a strong dependency on ordering alleviates a lot of these issues and makes the module more broadly applicable (if you create a zone, you'll inevitably want to create records. you do not have to create records; those can be added externally through the record resource itself)
• The delegation-sets module was another single resource module - this type of resource is better used on its own (bare resource) since its likely to be passed into a number of modules (zones) so that all zones have the same name servers
• The zone-cross-account-vpc-association was a peculiar module. It seems its functionality was intended to assist with associating zones with other accounts/regions. However, these sharing resources are typically better left as one-sided; where the resource creation side allows/extends the sharing of said resource, and elsewhere the accepting side receives/accepts said shared resource. This module is now facing issues due to its design requiring two different aws providers. Some of the functionality is preserved - the association authorization resource resides within the new zone module which allows the zone to be associated with a different account/region. However, performing the actual association is left to the user through the aws_route53_zone_association resource (this could be in their same statefile, in separate statefile, etc.). tl;dr - it still supports associations but without the hard assumption on how that is performed
• Resolves DNS records are recreated on hosted zone change #66
• Resolves The "for_each" value depends on resource attributes that cannot be determined until apply #92
• Resolves Zones outputs are not easily consumable, they are not primitives but objects. #93
• Resolves feat: Ability to enable DNSSEC for Route53 zone #97
• Resolves feat: Add CIDR routing policy support #98
• Resolves Updated aws_route53_zone to use vpc_id. Created variable route53_vpc_id #99
• Resolves feat: Update module to include vpc for route53 #100
• Resolves Variable Type not working when specific #103
• Resolves Set more than 1 A record for same domain #110
• Resolves feat: Complex variable types for module zones #111
• Resolves support "comment" attribute for aws_route53_record #115
• Resolves Redundant empty provider block on cross-account module. #117
• Resolves Don't destroy records when changing types between A/CNAME/NS #119
• Resolves feat: Allow skipping data source lookup #120
• Closes fix: Remove redundant empty provider blocks #121

Breaking Changes

• Yes; there are no attempts at trying to migrate resources from v5.0 and prior into this new module structure. Users are free to continue using the prior versions as is, forking at a prior version and utilizing their fork if they require changes, or removing the resources in question from Terraform state and performing imports into the new module structure

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects
• I have executed pre-commit run -a on my pull request