aws_cloudwatch_metric_alarm "arn:aws:automate:${var.region}:ec2:recover does not match regexp

[ghost]

This issue was originally opened by @klassm as hashicorp/terraform#19307. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Hi there,
updating to the latest version of terraform 0.11.10 produced a new issue with our configuration. We are using an aws_cloudwatch_metric_alarm to trigger alarm actions for recover and reboot.

resource "aws_cloudwatch_metric_alarm" "auto_recovery_alarm" {
  count = "${length(var.availability_zones)}"

  alarm_name = "${var.env}-auto-recovery-${count.index}"
  comparison_operator = "LessThanThreshold"
  evaluation_periods = "1"
  metric_name = "ProxyHealth"
  namespace = "MyService"
  period = "60"
  statistic = "Minimum"
  threshold = "1"

  dimensions = {
    InstanceId = "${aws_instance.proxy.*.id[count.index]}"
    ProxyIp = "${aws_instance.proxy.*.private_ip[count.index]}"
  }

  alarm_actions = [
    "arn:aws:automate:${var.region}:ec2:recover",
    "arn:aws:automate:${var.region}:ec2:reboot"
  ]
}

This worked out just fine - however, in the latest version of terraform planning an execution plan breaks with

Error: module.service.module.proxy.aws_cloudwatch_metric_alarm.auto_recovery_alarm[0]: "alarm_actions.1" does not match EC2 automation ARN ("^arn:[\\w-]+:automate:[\\w-]+:ec2:(recover|stop|terminate)$"): "arn:aws:automate:eu-central-1:ec2:reboot"

Looking at the AWS API documentation, "arn:aws:automate:eu-central-1:ec2:reboot" still seems to be a valid value: https://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html

Is there any reason why this does not work any more?

Thanks,
Matthias

[zleavell]

Im definitely having the same error with terraform. I was actually able to use this about 2 days ago, but today I cannot use it:

 resource "aws_cloudwatch_metric_alarm" "ec2-autorecover-application-amer" {
     alarm_name          = "${var.application-group}-${var.application}-amer-autorecover-ec2-application"
     namespace           = "AWS/EC2"
     evaluation_periods  = "2"
     period              = "300"
     alarm_description   = "This metric auto recovers the EC2 instance after failed status checks"
     alarm_actions       = ["arn:aws:automate:${var.region}:ec2:recover"]
     statistic           = "Minimum"
     comparison_operator = "GreaterThanThreshold"
     threshold           = "1"
     metric_name         = "StatusCheckFailed_System"
     insufficient_data_actions = []
 
     dimensions {
     InstanceId = "${data.aws_instances.zoom-instance-amer.ids[count.index]}"

Reboot action seems to be gone now?

Error:

module.app.aws_cloudwatch_metric_alarm.autoreboot-application-high-cpu-amer: "alarm_actions.0" does not match EC2 automation ARN ("^arn:[\\w-]+:automate:[\\w-]+:ec2:(recover|stop|terminate)$"): "arn:aws:automate:us-west-2:ec2:reboot"

[bflad]

Hi folks 👋 Sorry for the trouble here. This has been an unfolding issue for the last few releases. 😅

• In version 1.41.0 of the AWS provider (specifically resource/aws_cloudwatch_metric_alarm: Validate alarm actions #6151), we started validating during plan-time that alarm_actions were in fact "normal" ARNs (e.g. arn:PARTITION:SERVICE:REGION:ACCOUNT:RESOURCE) which was a validation that did not exist previously. Since these EC2 automation ARNs differ by including ec2 in the account ID field (normally a 12 digit number) this caused the initial regression.
• In version 1.42.0 of the AWS provider (specifically resource/aws_cloudwatch_metric_alarm: Allow EC2 Automate ARNs with alarm_actions #6206) we started allowing EC2 automation ARNs including recover, stop, and terminate.
• This issue here now surfaces that while reboot is documented under OKActions, it was not documented under AlarmActions, which was a mistake on my part for not including it in the original fix.

I have submitted #6405 to allow reboot as well. I'll make sure this gets included in version 1.43.1, which will likely get released later tonight.

[klassm]

Perfect thanks! ;-) Am Fr., 9. Nov. 2018, 00:32 hat Brian Flad <notifications@github.com> geschrieben:

…

Hi folks 👋 Sorry for the trouble here. This has been an unfolding issue for the last few releases. 😅 - In version 1.41.0 of the AWS provider (specifically #6151 <#6151>), we started validating during plan-time that alarm_actions were in fact "normal" ARNs (e.g. arn:PARTITION:SERVICE:REGION:ACCOUNT:RESOURCE) which was a validation that did not previously. Since these EC2 automation ARNs differ by including ec2 in the account ID field (normally a 12 digit number) this caused the initial regression. - In version 1.42.0 of the AWS provider (specifically #6206 <#6206>) we started allowing EC2 automation ARNs including recover, stop, and terminate. - This issue here now surfaces that while reboot is documented under OKActions, it was not documented under AlarmActions, which was a mistake on my part for not including it in the original fix. I have submitted #6405 <#6405> to allow reboot as well. I'll make sure this gets included in version 1.43.1, which will likely get released later tonight. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6386 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAedILg-SDOud0SdDb3Slz-3rrRqPrIAks5utL8WgaJpZM4YSPkX> .

[zleavell]

Hi folks 👋 Sorry for the trouble here. This has been an unfolding issue for the last few releases. 😅

• In version 1.41.0 of the AWS provider (specifically resource/aws_cloudwatch_metric_alarm: Validate alarm actions #6151), we started validating during plan-time that alarm_actions were in fact "normal" ARNs (e.g. arn:PARTITION:SERVICE:REGION:ACCOUNT:RESOURCE) which was a validation that did not exist previously. Since these EC2 automation ARNs differ by including ec2 in the account ID field (normally a 12 digit number) this caused the initial regression.
• In version 1.42.0 of the AWS provider (specifically resource/aws_cloudwatch_metric_alarm: Allow EC2 Automate ARNs with alarm_actions #6206) we started allowing EC2 automation ARNs including recover, stop, and terminate.
• This issue here now surfaces that while reboot is documented under OKActions, it was not documented under AlarmActions, which was a mistake on my part for not including it in the original fix.

I have submitted #6405 to allow reboot as well. I'll make sure this gets included in version 1.43.1, which will likely get released later tonight.

Hey there Blfad - will you let us know when this gets deployed?

[bflad]

The fix for this has been merged and will be released in version 1.43.1 of the provider shortly (next hour or so, sorry for the slight delay). 👍

[bflad]

This has been released in version 1.43.1 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

[zleavell]

Fixed, thanks!

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