Terraform-provider-aws: aws_lambda_function data source outputs qualified ARN for arn attribute

[tdmalone]

Terraform Version

Terraform v0.11.7
+ provider.aws v1.16.0

Affected Resource(s)

Please list the resources as a list, for example:

• aws_lambda_function data source

Terraform Configuration Files

data "aws_lambda_function" "sns_to_slack" {
  function_name = "snsToSlack"
}

resource "aws_sns_topic" "lambda_dead_letter_queue" {
  name         = "lambda-dead-letter-queue"
  display_name = "Lambda Dead Letter Queue (Managed by Terraform)"
}

resource "aws_sns_topic_subscription" "lambda_dead_letter_queue_to_slack" {
  topic_arn = "${aws_sns_topic.lambda_dead_letter_queue.arn}"
  protocol  = "lambda"
  endpoint  = "${data.aws_lambda_function.sns_to_slack.arn}"
}

resource "aws_lambda_permission" "lambda_dead_letter_queue_to_slack" {
  statement_id  = "AllowExecutionFromSNS"
  action        = "lambda:InvokeFunction"
  function_name = "${data.aws_lambda_function.sns_to_slack.function_name}"
  principal     = "sns.amazonaws.com"
  source_arn    = "${aws_sns_topic.lambda_dead_letter_queue.arn}"
}

Expected Behavior

I'm not sure if this is an issue with the data source itself or with its documentation, but I expected to get a non-qualified ARN from the arn attribute, especially because there's also a qualified_arn attribute available.

Actual Behavior

Using ${data.aws_lambda_function.sns_to_slack.arn} resulted in the ARN being qualified by $LATEST:

 arn:aws:lambda:ap-southeast-2:XXXXXXXXX:function:snsToSlack:$LATEST

Importantly in this case, using this ARN, the topic subscription was not firing.

I resolved it by using the following in my aws_sns_topic_subscription_resource, after which the Lambda function successfully received incoming SNS events:

endpoint = "${replace(data.aws_lambda_function.sns_to_slack.arn,":$LATEST","")}"

Important Factoids

• An S3 bucket notification I set up through the AWS console, and then imported into Terraform, also used the Lambda ARN without the qualification, so the requirement to use an unqualified ARN doesn't appear to be unique to SNS (I was unable to test in this case if the event still worked when providing the qualified ARN).
• I'm not sure if this is a bug or a documentation issue. It's possible this is the desired behaviour, and perhaps it might be worth adding the tip to use replace() to the docs. Either way, I would expect it to be _fairly_ self explanatory to get an ARN from the data source that can be successfully passed as an input into other resources.

[tkalus]

Additional observations with a possible work-around by setting the qualifier to empty.

Continuing with the above example:

data "aws_lambda_function" "sns_to_slack" {
  function_name = "snsToSlack"
  qualifier = ""
}

${data.aws_lambda_function.sns_to_slack.arn} seems to return what @tdmalone is expecting.
E.G. arn:aws:lambda:us-east-1:123456789012:function:snsToSlack

But ${data.aws_lambda_function.sns_to_slack.qualified_arn} weirdly returns something like this:
arn:aws:lambda:us-east-1:123456789012:function:snsToSlack:$LATEST

[tdmalone]

@tkalus Thanks for that - your second find does make sense, because no qualifier with Lambda implies you want $LATEST. Your first find - that's a decent workaround, and if it's not possible to fix this (because of backwards compatibility), then perhaps that could be added to the docs?

[jangolano]

Can the documentation be updated to denote this?

Thanks

[MichaelDeCorte]

It would be very helpful if the aws_lambda_function resource and data attributes were the same. So arn would be non-qualified for both, and qualified_arn was qualified.

[kyeotic]

This is still an issue

[bflad]

Hi folks 👋 Sorry for this unexpected behavior! You'll be happy to know this has been fixed in version 2.0.0 of the Terraform AWS Provider, releasing in the next week or two. The comment associated with this pull request has details about the changes to the aws_lambda_function data source: https://github.com/terraform-providers/terraform-provider-aws/pull/7663 🎉

[hashibot[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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!