AWS::Route53::HealthCheck HealthCheckConfig Disabled

[nmussy]

1. Title

AWS::Route53::HealthCheck HealthCheckConfig Disabled

2. Scope of request

The existing HealthCheck resource doesn't allow setting the Disabled property, which is settable via the API

3. Expected behavior

If true, the Disabled property should disable the health check until it is false. The property should be optional, and false by default. No particular changes to the resource life-cycle that I can see.

4. Suggest specific test cases

Check that the health check is disabled when Disabled is true

5. Helpful Links to speed up research and evaluation

API Docs Disabled field: https://docs.aws.amazon.com/Route53/latest/APIReference/API_UpdateHealthCheck.html#Route53-UpdateHealthCheck-request-Disabled
Current CloudFormation AWS::Route53::HealthCheck HealthCheckConfig docs, lacking the Disabled field: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-route53-healthcheck-healthcheckconfig.html

6. Category (required) - Will help with tagging and be easier to find by other users to +1

Use the categories as displayed in the AWS Management Console (simplified):

4. Networking & Content (VPC, Route53, API GW,...)

7. Any additional context (optional)

Found while implementing the L2 HealthCheck construct for the CDK (#4413)

[zmully]

So it's been awhile without an update, but CFN lack support for Disabled healthchecks makes my healthcheck management super janky. Working around the lack of support for Disabled doubles my Route53 healthcheck cost, so while it's not a lot of money, it's money that I really shouldn't have to spend for this baseline functionality.

Here's how (and why) I'd like to use it, and how I've had to work around it.

• A cloudformation template is used to create regional LBR/Weighted recordsets for my applications, allowing me to fail regions in and out of service by updating a stack parameter, in my case: "UsEast1Route", which drives template conditions and the creation and configuration of healthchecks.
• Because I have many services which are not publicly accessible but which still need this level of DNS management, I'm using Route53 healthchecks that point to a CloudWatch alarm for the application. This allows me to use the HealthyHostCount metric in AWS/ELB namespace to drive Route53s request routing for my internal services.
• When I fail a region out of service, what I want to do is set the HC via Cloudformation to "Disabled: true" (causing it to always be healthy) and "Inverted: true" (to invert that to "unhealthy") so that Route53 will route traffic to my other regions.
• But because Cloudformation doesn't support "Disabled", my workaround is to create this CloudWatch based Route53 healthcheck, then create another Route53 CALCULATED healthcheck, referencing the first HC. Then I set the "HealthThreshold" for the calculated HC to 1 if I want to route to the region, and to 2 if I want to fail out the region. My recordsets then reference this second calculated healthcheck.

So you might ask: why isn't Inverted support sufficient, can't you just invert your CloudWatch based Route53 HC if you want to fail the region out? Sure I could, but that would only work as long as the Cloudwatch based HC is healthy. There are times when my application stacks in a region may be healthy, but I still need to fail them out, so while Inverted would work, if those stacks in the failed out region became unhealthy for any reason, Route53 would start routing traffic back to the unhealthy stacks because of the Inverted status! Without Disabled I'm stuck creating, managing and paying for twice the number of Route53 HCs.

So please, when can we see Disabled support on the roadmap?