terraform-provider-aws
terraform-provider-aws copied to clipboard
aws_sns_topic Invalid parameter: TopicArn
This issue was originally opened by @smailli as hashicorp/terraform#16148. It was migrated here as a result of the provider split. The original body of the issue is below.
Hi guys!
I have a problem !!!!
When I use aws_sns_topic + aws_sns_topic_policy + aws_sns_topic_subscription and remove the configuration file, terraform returns Invalid parameter: TopicArn error.
Terraform Version
$ terraform version
Terraform v0.10.6
Prerequisite
Create two SQS named SQS_NAME0 and SQS_NAME1
Terraform Configuration Files
modules/aws/test/main.tf:
resource "aws_sns_topic" "default_topic" {
name = "TOPIC_NAME"
}
resource "aws_sns_topic_policy" "default_policy" {
depends_on = ["aws_sns_topic.default_topic"]
arn = "${aws_sns_topic.default_topic.arn}"
policy = <<POLICY
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__default_statement_ID",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"SNS:GetTopicAttributes",
"SNS:SetTopicAttributes",
"SNS:AddPermission",
"SNS:RemovePermission",
"SNS:DeleteTopic",
"SNS:Subscribe",
"SNS:ListSubscriptionsByTopic",
"SNS:Publish",
"SNS:Receive"
],
"Resource": "${aws_sns_topic.default_topic.arn}",
"Condition": {
"StringEquals": {
"AWS:SourceOwner": "000000000000"
}
}
}
]
}
POLICY
}
resource "aws_sns_topic_subscription" "default_topic_subscription" {
count = "2"
depends_on = ["aws_sns_topic.default_topic"]
topic_arn = "${aws_sns_topic.default_topic.arn}"
protocol = "sqs"
endpoint = "arn:aws:sqs:us-west-2:000000000000:SQS_NAME${count.index}"
}
Environment
In environment directory create a module file
environment/test.tf:
module "sns-test" {
source = "../../modules/aws/test"
}
Reproduce
$ terraform apply -target=module.sns-test
$ rm test.tf
$ terraform apply -target=module.sns-test
aws_sns_topic.default_topic: Refreshing state... (ID: arn:aws:sns:us-west-2:000000000000:TOPIC_NAME)
Error refreshing state: 1 error(s) occurred:
* module.sns-test.aws_sns_topic.default_topic: aws_sns_topic.default_topic: InvalidParameter: Invalid parameter: TopicArn
status code: 400, request id: xxxxxxxx-yyyy-zzzz-xxxx-zzzzzzzzzzzz
When I run terraform destroy -target=module.sns-test this execution return OK.
But, if I remove the config file, returns Invalid parameter: TopicArn
May be related to a misconfigured region https://github.com/boto/boto3/issues/646
FYI terraform state rm helped me to get rid of some orphaned non existing resource and this Invalid parameter: TopicArn error.
This is still an issue and I am seeing it when trying to deploy across regions+ across profiles.
Sample Code:
variable region {}
variable profile {}
provider "aws" {
region = "${var.region}"
shared_credentials_file = "/Users/tf_user/.aws/creds"
profile = "${var.profile}"
}
resource "aws_sns_topic" "default_topic" {
name = "topic-name"
}
Steps I took:
Set region = us-east-1 profile = dev Run Terraform Apply The topic is deployed successfully to east
Set region = us-west-1
profile = dev
Run Terraform Apply
aws_sns_topic.default_topic: InvalidParameter: Invalid parameter: TopicArn
A similar error appears and the topic doesn't get created
Next going to the Prod region:
Set region = us-east-1
profile = prod
aws_sns_topic.default_topic: InvalidParameter: Invalid parameter: TopicArn
Topic doesn't get created
Set region = us-west-1
profile = prod
aws_sns_topic.default_topic: InvalidParameter: Invalid parameter: TopicArn
Topic doesn't get created
Whatever the first region/profile you deploy in is what terraform sets as the default for ALL sns topic creation and it doesn't matter if you change the region/profile in your provider it only will create things in the first region/profile combination provided. I would expect to be able to deploy with the same topic name in both east/west and dev/prod AWS environments as that is how terraform works for most other resources. Even if I switched topicname to be "test_topic_east" and "test_topic_west" it didn't make a difference. It seems terraform is ignoring all of this (provider region/profile and any subsequent topic names) and just reading directly from the terraform state of the first topic that was set up. Could someone from the team look into this issue as it is still present in 2019 and it was opened in 2017.
We are also now experiencing this in our setup.
For me I update region in lambda function and its worked. AWS.config.update({region: 'us-west-2'});
As @Hashfyre mentioned above, this may be related to misconfigured region - that happened to be the case for me as well.
Ensure that the region you're using for the AWS provider is the region that the SNS topic in question resides in. The error message is misleading - the SNS topic ARN may be valid, but it may just be in a different region.
This is still a problem for me, and it is not related to a mis-configured region.
Please see this gist
It involves an SNS topic I create, identified in the output as "aws_sns_topic.jambonz-sns-topic".
I perform the following steps:
terraform apply- successfully creates SNS topic and other infrastructureterraform show- shows that the SNS topic was successfully createdterraform state list- shows that the SNS topic is in stateterraform destroy- fails withInvalid parameter: TopicArn
Any idea what the problem is?
@Adiii717 how and where do you execute the lambda function?
any workarounds? need to deploy sns topic to multiple regions
I managed to do this by putting each regional SNS in different modules, and passing the ARN of each SNS to the lambda in eu-central-1.
backend.tf
terraform {
required_version = ">= 0.12.20"
backend s3 {
region = "eu-central-1"
}
}
module "sns-eu-central-1" {
source = "./modules/sns-only"
providers = {
aws = aws.eu-central-1
}
account_id = var.account_id
}
module "sns-us-east-1" {
source = "./modules/sns-only"
providers = {
aws = aws.us-east-1
}
account_id = var.account_id
}
module "sns-us-west-2" {
source = "./modules/sns-only"
providers = {
aws = aws.us-west-2
}
account_id = var.account_id
}
module "sns-ap-northeast-1" {
source = "./modules/sns-only"
providers = {
aws = aws.ap-northeast-1
}
account_id = var.account_id
}
module "eu-central-1" {
source = "./modules/lambda-that-publishes-to-all-sns"
providers = {
aws = aws.eu-central-1
}
account_id = var.account_id
regional_sns_arn_eu_central_1 = module.sns-eu-central-1.regional_sns_arn
regional_sns_arn_us_east_1 = module.sns-us-east-1.regional_sns_arn
regional_sns_arn_us_west_2 = module.sns-us-west-2.regional_sns_arn
regional_sns_arn_ap_northeast_1 = module.sns-ap-northeast-1.regional_sns_arn
}
providers.tf
provider aws {
alias = "eu-central-1"
region = "eu-central-1"
allowed_account_ids = [var.account_id]
}
provider aws {
alias = "us-east-1"
region = "us-east-1"
allowed_account_ids = [var.account_id]
}
provider aws {
alias = "us-west-2"
region = "us-west-2"
allowed_account_ids = [var.account_id]
}
provider aws {
alias = "ap-northeast-1"
region = "ap-northeast-1"
allowed_account_ids = [var.account_id]
}
configured region u need assign
100% will work @hashibot
still having same issues while trying to modify sns topic in us-east-2, it is modifying in us-east-1 instead ....
Still having this issue when I have preconfigured SNS in region1, creating new sqs in region/account and connecting same with different region/account is throwing error.
I had this problem, the only solution I found was to remove manually from the aws console the given sns and also to remove it from my terraform state.
Is this still an issue in v1.2.4?
I am hitting (what appears to be) this same error, using Terraform 1.5.7.
Interestingly, if I go into the AWS web console and attempt to manually set up an SES Bounce notification to go to the SNS Topic I created through Terraform, it similarly rejects the Topic ARN. (The error message below is slightly redacted:)
An invalid or out-of-range value was supplied for the input parameter. SNS topic arn:aws:sns:us-east-1:123456789012:subdomain-domain-tld-ses-bounces is invalid.
At least for some of us, this might not be an issue with Terraform as much as it is an issue with AWS having some ARN or naming constraints that are not obvious (such as allowing an SNS topic to have a longer name than SES will accept an ARN for, though that's just a guess).