libZSservicesZSamazonka-route53-autonamingZSamazonka-route53-autonaming
Copyright(c) 2013-2021 Brendan Hay
LicenseMozilla Public License, v. 2.0.
MaintainerBrendan Hay <brendan.g.hay+amazonka@gmail.com>
Stabilityauto-generated
Portabilitynon-portable (GHC extensions)
Safe HaskellNone

Amazonka.Route53AutoNaming.Types.HealthCheckCustomConfig

Description

 
Synopsis

Documentation

data HealthCheckCustomConfig Source #

A complex type that contains information about an optional custom health check. A custom health check, which requires that you use a third-party health checker to evaluate the health of your resources, is useful in the following circumstances:

  • You can't use a health check that's defined by HealthCheckConfig because the resource isn't available over the internet. For example, you can use a custom health check when the instance is in an Amazon VPC. (To check the health of resources in a VPC, the health checker must also be in the VPC.)
  • You want to use a third-party health checker regardless of where your resources are located.

If you specify a health check configuration, you can specify either HealthCheckCustomConfig or HealthCheckConfig but not both.

To change the status of a custom health check, submit an UpdateInstanceCustomHealthStatus request. Cloud Map doesn't monitor the status of the resource, it just keeps a record of the status specified in the most recent UpdateInstanceCustomHealthStatus request.

Here's how custom health checks work:

  1. You create a service.
  2. You register an instance.
  3. You configure a third-party health checker to monitor the resource that's associated with the new instance.

    Cloud Map doesn't check the health of the resource directly.

  4. The third-party health-checker determines that the resource is unhealthy and notifies your application.
  5. Your application submits an UpdateInstanceCustomHealthStatus request.
  6. Cloud Map waits for 30 seconds.
  7. If another UpdateInstanceCustomHealthStatus request doesn't arrive during that time to change the status back to healthy, Cloud Map stops routing traffic to the resource.

See: newHealthCheckCustomConfig smart constructor.

Constructors

HealthCheckCustomConfig' 

Fields

  • failureThreshold :: Maybe Natural

    This parameter is no longer supported and is always set to 1. Cloud Map waits for approximately 30 seconds after receiving an UpdateInstanceCustomHealthStatus request before changing the status of the service instance.

    The number of 30-second intervals that you want Cloud Map to wait after receiving an UpdateInstanceCustomHealthStatus request before it changes the health status of a service instance.

    Sending a second or subsequent UpdateInstanceCustomHealthStatus request with the same value before 30 seconds has passed doesn't accelerate the change. Cloud Map still waits 30 seconds after the first request to make the change.

Instances

Instances details
Eq HealthCheckCustomConfig Source # 
Instance details

Defined in Amazonka.Route53AutoNaming.Types.HealthCheckCustomConfig

Read HealthCheckCustomConfig Source # 
Instance details

Defined in Amazonka.Route53AutoNaming.Types.HealthCheckCustomConfig

Show HealthCheckCustomConfig Source # 
Instance details

Defined in Amazonka.Route53AutoNaming.Types.HealthCheckCustomConfig

Generic HealthCheckCustomConfig Source # 
Instance details

Defined in Amazonka.Route53AutoNaming.Types.HealthCheckCustomConfig

Associated Types

type Rep HealthCheckCustomConfig :: Type -> Type #

NFData HealthCheckCustomConfig Source # 
Instance details

Defined in Amazonka.Route53AutoNaming.Types.HealthCheckCustomConfig

Methods

rnf :: HealthCheckCustomConfig -> () #

Hashable HealthCheckCustomConfig Source # 
Instance details

Defined in Amazonka.Route53AutoNaming.Types.HealthCheckCustomConfig

ToJSON HealthCheckCustomConfig Source # 
Instance details

Defined in Amazonka.Route53AutoNaming.Types.HealthCheckCustomConfig

FromJSON HealthCheckCustomConfig Source # 
Instance details

Defined in Amazonka.Route53AutoNaming.Types.HealthCheckCustomConfig

type Rep HealthCheckCustomConfig Source # 
Instance details

Defined in Amazonka.Route53AutoNaming.Types.HealthCheckCustomConfig

type Rep HealthCheckCustomConfig = D1 ('MetaData "HealthCheckCustomConfig" "Amazonka.Route53AutoNaming.Types.HealthCheckCustomConfig" "libZSservicesZSamazonka-route53-autonamingZSamazonka-route53-autonaming" 'False) (C1 ('MetaCons "HealthCheckCustomConfig'" 'PrefixI 'True) (S1 ('MetaSel ('Just "failureThreshold") 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedStrict) (Rec0 (Maybe Natural))))

newHealthCheckCustomConfig :: HealthCheckCustomConfig Source #

Create a value of HealthCheckCustomConfig with all optional fields omitted.

Use generic-lens or optics to modify other optional fields.

The following record fields are available, with the corresponding lenses provided for backwards compatibility:

$sel:failureThreshold:HealthCheckCustomConfig', healthCheckCustomConfig_failureThreshold - This parameter is no longer supported and is always set to 1. Cloud Map waits for approximately 30 seconds after receiving an UpdateInstanceCustomHealthStatus request before changing the status of the service instance.

The number of 30-second intervals that you want Cloud Map to wait after receiving an UpdateInstanceCustomHealthStatus request before it changes the health status of a service instance.

Sending a second or subsequent UpdateInstanceCustomHealthStatus request with the same value before 30 seconds has passed doesn't accelerate the change. Cloud Map still waits 30 seconds after the first request to make the change.

healthCheckCustomConfig_failureThreshold :: Lens' HealthCheckCustomConfig (Maybe Natural) Source #

This parameter is no longer supported and is always set to 1. Cloud Map waits for approximately 30 seconds after receiving an UpdateInstanceCustomHealthStatus request before changing the status of the service instance.

The number of 30-second intervals that you want Cloud Map to wait after receiving an UpdateInstanceCustomHealthStatus request before it changes the health status of a service instance.

Sending a second or subsequent UpdateInstanceCustomHealthStatus request with the same value before 30 seconds has passed doesn't accelerate the change. Cloud Map still waits 30 seconds after the first request to make the change.