Add hostname property for aws_transfer_server

[dbuzolin-nfl]

Is there way to add hostname property to transfer service, and/or also integrate it with Route53? Current implementation creates service with empty hostname: "-"

[bflad]

Hi @dbuzolin-nfl 👋 Can you verify creating Route53 records is correct? #6639 (comment)

There is not currently anything in the AWS Transfer API to set this: https://docs.aws.amazon.com/transfer/latest/userguide/API_CreateServer.html

If so, maybe we should add an example aws_route53_record configuration to the aws_transfer_server documentation.

[dbuzolin-nfl]

Creation of the SFTP service from AWS console allows entering DNS name for service and then it creates CNAME entry in route53 for you. Two tags show up in sftp service, ex:

aws:transfer:route53HostedZoneId | /hostedzone/ABCDEFGHIGFK
aws:transfer:customHostname | mysftphost.myco.com

Can we use this route (tags) - since they are "aws.*" ?

[ntman4real]

I see when I create the service manually, via console, it adds this tag which reflects the hostname:"aws:transfer:customHostname"

But when i try to apply this via TF, it successfully appears that it applied it, but it doesn't show up, and then when I run the plan again it shows that it is needed and isn't there.

[dbuzolin-nfl]

Yeah, probably because "aws.*" tags are considered "system" tags and can't be applied externally? Just a guess...

[gazoakley]

That's how the AWS console is doing it (see the XHR requests made from the browser):

{
    "headers": {
        "X-Amz-User-Agent": "aws-sdk-js/2.41.0 promise",
        "Content-Type": "application/x-amz-json-1.1",
        "X-Amz-Target": "TransferService.TagResource"
    },
    "path": "/",
    "method": "POST",
    "region": "eu-central-1",
    "params": {},
    "contentString": "{\"Arn\":\"arn:aws:transfer:eu-central-1:123456789012:server/s-12345678901234567\",\"Tags\":[{\"Key\":\"aws:transfer:customHostname\",\"Value\":\"sftp.example.com\"}]}",
    "operation": "tagResource"
}

I think it's appropriate here to allow creating aws.* tags if that's how the console achieves what it does.

[ntman4real]

any update?

[nickvollmar]

Workaround: if the AWSCLI is installed on the machine where you're running Terraform, you can use local-exec to create the hostname. I ended up doing this:

resource "aws_transfer_server" "this" { ... }
resource "aws_route53_record" "custom_hostname" { ... }

resource "null_resource" "associate_custom_hostname" {
  provisioner "local-exec" {
    command = <<EOF
aws transfer tag-resource \
  --arn '${aws_transfer_server.this.arn}' \
  --tags \
    'Key=aws:transfer:customHostname,Value=${aws_route53_record.custom_hostname.name}' \
    'Key=aws:transfer:route53HostedZoneId,Value=/hostedzone/${aws_route53_record.custom_hostname.zone_id}'
EOF
  }
  depends_on = ["aws_transfer_server.this", "aws_route53_record.custom_hostname"]
}

[nexxai]

Has anyone had any success using @nickvollmar 's method, but with a non-Route53-hosted customHostname?

I did the following:

resource "aws_transfer_server" "company-sftp-server" {
  identity_provider_type = "SERVICE_MANAGED"
  logging_role = "${aws_iam_role.company-sftp-role-client.arn}"
  endpoint_type = "PUBLIC"
  tags = "${aws_s3_bucket.company-sftp-s3-bucket.tags}"
}

resource "null_resource" "company-sftp-server-custom-hostname" {
  provisioner "local-exec" {
    command = <<EOF
aws transfer tag-resource \
  --arn '${aws_transfer_server.company-sftp-server.arn}' \
  --tags 'Key=aws:transfer:customHostname,Value=sftp.company.com'
EOF
  }
  depends_on = ["aws_transfer_server.company-sftp-server"]
}

but no matter what I do, it keeps throwing "Invalid ARN", including when I try the CLI directly:

Error: Error running command 'aws transfer tag-resource \
  --arn 'arn:aws:transfer:ca-central-1:############:server/s-#################' \
  --tags 'Key=aws:transfer:customHostname,Value=sftp.company.com'
': exit status 255. Output: 
An error occurred (InvalidRequestException) when calling the TagResource operation: Invalid ARN

I've tried literally copying and pasting the ARN from the contentString, from within the POST request in my browser's DevTools network panel, but I still get the same problem. I've also had 2 other people confirm that my request matches character-for-character, including re-typing the entire thing in the unlikely event that a homograph was unintentionally being copied. Finally, I've tried destroying and re-building the resource several times, just in case it was some weird issue with a specific instance, but no dice.

I'm pulling my hair out here, but I don't know what else to try. Anyone have any ideas?

EDIT: For anyone finding this later, the solution was something very simple but not documented anywhere: you must specifically define the region that the SFTP server lives in, using the "--region" argument.

For example:

aws transfer tag-resource \
  --arn 'arn:aws:transfer:ca-central-1:############:server/s-#################' \
  --tags 'Key=aws:transfer:customHostname,Value=sftp.company.com' \
  --region ca-central-1

[tracypholmes]

Hi, @dbuzolin-nfl! Thank you for using Terraform and for opening up this question. Issues on GitHub are intended to be related to bugs or feature requests with the provider codebase. I looks like you've gotten some great feedback and solutions i this thread. Please use https://discuss.hashicorp.com/c/terraform-providers for additional feedback, community discussions, and questions around Terraform.

If you believe that your issue was miscategorized as a question or closed in error, please create a new issue using one of the following provided templates: bug report or feature request. Please make sure to provide us with the appropriate information so we can best determine how to assist with the given issue.

[atrepca]

@nickvollmar's workaround only partly solves this - the local-exec adds the aws: tags, but that doesn't trigger the route 53 CNAME creation further. AWS support confirmed that this is not supported, and an internal request was put in with the SFTP team for it.

[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!