Yes, the authorization is just for illustration only (if you were to create everything in Terraform) and that probably don't need to be imported if already handled outside Terraform. What's more important is the the zone association should be imported in the context of account B, not account A. So you might need to supply a provider argument for account B to the import block, and have a separate aws_route53_zone_association resource for the association that belong to account B.

from terraform-provider-aws.

@acwwat Great, thank you for the guidance. I'm going to mess around more with this and report back findings. I've already pulled the resources into different groups or organizational sanity purposes prior to filing this issue. Trying to correct the sins of pre-Terraform adoption, I figured it'd be good to do. This will be our first stack with multiple provider definitions going across different accounts, so need to figure that out.

from terraform-provider-aws.

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• 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.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

from terraform-provider-aws.

Additionally, running aws route53 get-hosted-zone --id ZEXAMPLEZONE shows that the VPC(s) from the other account are, in fact, associated with this zone. The ID displayed there is no different than the one used in the Terraform import statement. Output:

{
    "HostedZone": {
        "Id": "/hostedzone/ZEXAMPLEZONE",
        "Name": "foo.bar.com.",
        "CallerReference": "<guid>",
        "Config": {
            "Comment": "Internal hosts",
            "PrivateZone": true
        },
        "ResourceRecordSetCount": 118
    },
    "VPCs": [
        {
            "VPCRegion": "us-west-2",
            "VPCId": "vpc-0123456789abcdef0"
        },
        ...
    ]
}

I also tried a "naked" ID (e.g. vpc-0123456789abcdef0) and a "fully-qualified" ID (e.g. ZEXAMPLEZONE:vpc-0123456789abcdef0:us-west-2), but these don't work either, with the former giving a format error as expected.

from terraform-provider-aws.

I could be wrong, but based on the example usage provided in the aws_route53_vpc_association_authorization resource doc, it seems that the aws_route53_zone_association object is supposed to be associated with the account which owns the VPC. I created a little diagram to illustrate it - account A owns the hosted zone and account B owns the VPC to be associated with the hosted zone.

Based on this, I suspect that the import should be associated with a provider for the account that owns the VPC.

from terraform-provider-aws.

Thanks @acwwat for the references. Indeed, that's how those associations were created in the first place. However since these are import blocks, I would expect that the authorization step is not required since the association already exists. The AWS CLI nor the Console provides no details as to what the foreign VPC account ID.

from terraform-provider-aws.