ECS health‑check oddity
A pointed AWS quirk: ECS health‑check grace period caps out at 2,147,483,647 seconds — roughly 69 years — an eyebrow‑raising max that engineers noticed this week. It’s a weird ceiling worth knowing when configuring long grace periods or debugging quirky defaults @pmoust note on ECS grace period.
ECS exposes the setting as HealthCheckGracePeriodSeconds in service definitions and the Amazon ECS developer guide documents that parameter in the service-definition section. (docs.aws.amazon.com) Container-level task definitions use a different field, startPeriod, and CloudFormation’s HealthCheck StartPeriod explicitly accepts values between 0 and 300 seconds. (docs.aws.amazon.com) The Terraform aws_ecs_service resource surfaces the same service-level option as health_check_grace_period_seconds in provider docs. (registry.terraform.io) That service-level ceiling aligns with the maximum value representable by a signed 32‑bit integer, a common upper bound for many programming-language int types. (en.wikipedia.org) AWS Knowledge Center’s troubleshooting guidance calls out the upper bound and warns that a very long grace period can postpone replacement of legitimately unhealthy tasks. (repost.aws) The health-check behavior differs by context: HealthCheckGracePeriodSeconds applies when a service uses load balancers (ELB/ALB/VPC Lattice) while the task definition’s startPeriod governs container command health checks. (docs.aws.amazon.com) Some AWS SDKs model the service parameter as a typical 32‑bit integer type—for example, the AWS SDK for Kotlin exposes healthCheckGracePeriodSeconds as an Int in its CreateService request model. (docs.aws.amazon.com)
