aws_transfer_server custom hostname via alternate mechanism

[brettcave]

https://github.com/hashicorp/terraform-provider-aws/issues/6956

AWS Transfer Server Custom Hostname is configured by adding 2 tags to the Server:

• aws:transfer:customHostname - e.g. "mytransferserver.mydomain.com"
• aws:transfer:route53ZoneId - in the format "/hostedzone/<ZoneId>"

These tags can be applied by using the regular tags attribute on the server, but are also accessible via Transfer-specific APIs:

• ListTagsForResources reads tags - https://docs.aws.amazon.com/transfer/latest/userguide/API_ListTagsForResource.html
• TagResource adds a tag - https://docs.aws.amazon.com/transfer/latest/userguide/API_TagResource.html
• UntagResource removes a tag - https://docs.aws.amazon.com/transfer/latest/userguide/API_UntagResource.html

Using the regular tagging mechanism doesn't work due to the aws: namespace, is an aws_transfer_server_custom_hostname resource feasible?

Potential usage:

resource "aws_transfer_server_custom_hostname" "this" {
   transfer_server_arn = aws_transfer_server.this.arn
   custom_hostname = "my-custom-hostname.some.domain"
   zone_id = 'AAAAAAAA'
}

This could easily compare the results of ListTagsForResources for determining state, and invoke TagResource to add tags. I've tested the api, there's no zone ID or hostname validation, this would need to be handled by Route53 records for R53 zones, but it's a lot better than needing to fall back to direct API calls or CLI runs to get this configuration in.

I've confirmed the approach works with boto3:

>>> t = boto3.client('transfer')
>>> servers = t.list_servers() # i have 1 that i am testing with
>>> t.tag_resource(Arn=servers['Servers'][0]['Arn'], Tags=[{'Key':'aws:transfer:route53HostedZoneId','Value':'/hostedzone/MyHostedZoneId'}, {'Key':'aws:transfer:customHostname':'foo.bar'])

Then go to console, and the custom domain is configured. When using a valid zone id and unreserved record name, there is no interaction to route53 (this is a console-only thing).

[brettcave]

The issue at opening is referenced, but locked - this is a duplicate, but with a workable approach.

[yermulnik]

I've just hit this issue =( Has there been any update on this yet?

[edli2]

+1, looking for the custom hostname solution

[kieryn]

Just setting up a terraform/AWS transfer PoC and a simple solution directly in templates would be really nice.

[davidferguson-cr]

Proper solution to this would be really nice, but in the meantime I used this workaround based on the comments on the original issue #6956, which I nearly missed so worth mentioning again here. Simply add a local-exec provisioner to set the tags via the CLI (assuming you have this configured locally):

resource "null_resource" "aws_transfer_server_custom_hostname" {
  provisioner "local-exec" {
    command = <<EOF
aws transfer tag-resource \
  --region ${var.aws_region} \
  --arn '${aws_transfer_server.this.arn}' \
  --tags \
    Key=aws:transfer:route53HostedZoneId,Value=/hostedzone/${var.route53_zone_id} \
    Key=aws:transfer:customHostname,Value=${var.custom_hostname}
EOF
  }

  triggers = {
    hosted_zone = var.route53_zone_id
    hostname    = var.custom_hostname
  }

  depends_on = [
    aws_transfer_server.this
  ]
}

Of course use your own vars/data sources/hardcoded values in place of my vars as appropriate.

[amit0904]

Any updates on this issue ? Is there any fix/feature scheduled ?

[z-mani]

Hello, any updates on this issue? Thanks

[chandanpjain]

We have hit this issue as well, is there a fix scheduled?

[vyanhursky]

+1

[kyle-francis]

Would like to know as well, thanks!

[dpreble-cisco]

+1

Don't mind setting up the route53 record ourselves outside the module, but the inability to set the tags without using the CLI is a blocker.

[jufemaiz]

Oh dear :sadpanda: just hit this one.

[jufemaiz]

https://github.com/hashicorp/terraform-provider-aws/blob/main/internal/service/transfer/server.go#L316-L318

So this is where the problem lies.

Options to resolve:

1. custom resource – best option as allows for lifecycle management.
2. adding back in an allowed list of two "aws" tags – more challenging managing lifecycle?

[christianblunden]

I have also hit this issue 👍

[jufemaiz]

Nice work @ewbankkit !

[yermulnik]

Yay 🥳 Will give it a try once it gets released in v4.35.0: https://github.com/hashicorp/terraform-provider-aws/blob/main/CHANGELOG.md#4350-unreleased

[Greyvend]

So, what will be the correct way to set the custom hostname once the new version is out?

[jufemaiz]

So, what will be the correct way to set the custom hostname once the new version is out?

As per the transfer server – setting the tags (it's such a hack by AWS I really don't know how it got through their review processes).

Ref: https://docs.aws.amazon.com/transfer/latest/userguide/requirements-dns.html#tag-custom-hostname-cdk

So given this, you'll create two aws_transfer_tag resources:

resource "aws_transfer_server" "with_custom_domain" {
  # config here
}

resource "aws_transfer_tag" "with_custom_domain_route53_zone_id" {
  resource_arn = aws_transfer_server.with_custom_domain.arn
  key          = "aws:transfer:route53HostedZoneId"
  value        = "/hostedzone/ABCDE1111222233334444"
}

resource "aws_transfer_tag" "with_custom_domain_name" {
  resource_arn = aws_transfer_server.with_custom_domain.arn
  key          = "aws:transfer:customHostname"
  value        = "abc.example.com"
}

[github-actions[bot]]

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.