Unable to Create Cloudwatch Metric/Alarm in Route53 Healthcheck

[hashibot]

This issue was originally opened by @vikas027 as hashicorp/terraform#13895. It was migrated here as part of the provider split. The original body of the issue is below.

---

Terraform Version

0.9.1 and 0.9.3

Affected Resource(s)

Please list the resources as a list, for example:

• aws_route53_health_check
• aws_cloudwatch_metric_alarm

Terraform Configuration Files

resource "aws_route53_health_check" "health_check" {
  fqdn                  = "${var.name}-${var.environment_short}.${var.domain_name}"
  port                  = "${var.https_port}"
  type                  = "HTTPS"
  resource_path         = "/login"
  failure_threshold     = "3"
  request_interval      = "30"
  cloudwatch_alarm_name = "${var.name}-${var.environment_short}.${var.domain_name}"
  cloudwatch_alarm_region = "ap-southeast-2"
}

resource "aws_cloudwatch_metric_alarm" "alarm" {
  depends_on          = ["aws_route53_health_check.health_check"]
  alarm_name          = "${var.name}-${var.environment_short}.${var.domain_name}"
  comparison_operator = "LessThanOrEqualToThreshold"
  evaluation_periods  = "2"
  metric_name         = "AppHealthCheck"
  namespace           = "AWS/Route53"
  period              = "60"
  statistic           = "Minimum"
  threshold           = "0"
  alarm_description   = "This metric monitors application"

  dimensions = {
    HealthCheckId = "${aws_route53_health_check.health_check.id}"
  }
}

Expected Behavior

Alarm should have been created and visible in Route53 Healthcheck

Actual Behavior

• Health check was created fine
• Alarm got created but is in INSUFFICIENT DATA state and was not linked to Route53 Healthcheck
  

Steps to Reproduce

run terraform apply after copying the above .tf file

References

• PR-8319
• aws_ssm_association - Issue passing parameters #7830

[chrismdp]

We are also experiencing this. We are working in the eu-west-1 region: it looks like manually created alarms are being placed in the us-east-1 region, whereas the terraformed alarms are going in the eu-west-1 region with all our other infrastructure.

Is it possible that terraform needs to place all alarms in us-east-1 regardless of the set region?

[Techbrunch]

@chrismdp I'm running into the same issue, I think this will only work if you are working in the us-east-1 region since "Amazon Route 53 metrics are not available if you select any other region as the current region".

Source: Monitoring Health Check Status and Getting Notifications.

Is there any way to override the region for a specific resource ?

Also I think the documentation of the aws_route53_health_checkshould have an example that mimic what you would get when creating an healthcheck with an alarm in the console. The current example doesn't make sense to me.

EDIT:

Here is my workaround, I created a module that will use a custom provider with the region hardcoded.

variable "environment" {}
variable "domain_name" {}
variable "resource_path" {}

provider "aws" {
  alias  = "use1"
  region = "us-east-1"
}

resource "aws_route53_health_check" "health_check" {
  fqdn              = "${var.domain_name}"
  port              = 443
  type              = "HTTPS"
  resource_path     = "${var.resource_path}"
  measure_latency   = true
  request_interval  = 30
  failure_threshold = 3

  tags = {
    Name        = "${var.environment}"
    Origin      = "terraform"
    Environment = "${var.environment}"
  }
}

resource "aws_cloudwatch_metric_alarm" "metric_alarm" {
  provider                  = "aws.use1"
  alarm_name                = "${var.environment}-alarm-health-check"
  comparison_operator       = "LessThanThreshold"
  evaluation_periods        = "1"
  metric_name               = "HealthCheckStatus"
  namespace                 = "AWS/Route53"
  period                    = "60"
  statistic                 = "Minimum"
  threshold                 = "1"
  alarm_description         = "Send an alarm if ${var.environment} is down"
  insufficient_data_actions = []

  dimensions {
    HealthCheckId = "${aws_route53_health_check.health_check.id}"
  }
}

[Ray-B]

We ran into this today, and reading through the AWS docs, this is indeed a limitation of Route53 and it's related health-check alarms.

Others have alluded to it, but just to mentioned it explicitly: If you create a route53 health-check alarm "by hand" from the AWS console, you'll see they are always created in us-east-1.

AWS Thread: https://forums.aws.amazon.com/thread.jspa?threadID=209680

That being said, @Techbrunch 's workaround is suitable.

We should:

• Update the documentation to reflect this limitation
• Decide on a behavior for aws_cloudwatch_metric alarms that have a HealthCheckId dimension specified...Maybe default to us-east-1? Haven't looked at the code so I'm speculating. maybe not feasible.

We need some sort of sensible default though.

The alternative is an obnoxious "gotcha" lying around in the documentation so people to come across. At the same time, minimizing the amount of re-work later if AWS decides to re-architect route53 healthcheck alarms to work in more or all regions by still allowing the default to be changed might be ok.

[russmac]

Terraform v0.11.7
+ provider.aws v1.29.0
+ provider.template v1.0.0

When using the above workaround at either the top level instantiation of the module or in the module itself the API returns:

* aws_cloudwatch_metric_alarm.front-end-check-alarm: Creating metric alarm failed: ValidationError: Invalid region us-west-2 specified. Only us-east-1 is supported.
	status code: 400, request id: a22e1255-955f-REDACTED

I had to set another default provider block overriding the region within the module and remove any non us-east-1 or global resources to another module.

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

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