feat(deploy): API task 1 vCPU/2 GB + container health check

[iammukeshm]

Summary

Two ECS task-definition changes for the API service.

1. Size the API task to 1 vCPU / 2 GB (dev)

api_cpu = "1024", api_memory = "2048" in both dev/us-east-1 and dev/ap-south-1 tfvars (was the 256/512 default). 2 GB is Fargate''s minimum memory at 1 vCPU, so it''s a valid pairing with no wasted allocation.

2. Container-level health check (fixes ECS "Unknown" status)

The task had no container healthCheck, so the ECS console showed "...health checks are still being evaluated or there are no container health checks defined" → health status Unknown.

Added a container_health_check on the api_service module call (the module already supported it; only app_stack wasn''t passing one — no change to the protected module).

Why /dev/tcp and not curl: I inspected the real images. The noble image (what the csproj builds) ships no curl/wget, but does have bash. So the check uses bash''s built-in /dev/tcp to confirm Kestrel is accepting connections on the container port:

["CMD", "bash", "-c", "exec 3<>/dev/tcp/127.0.0.1/${var.api_container_port}"]

App-level health is already covered by the ALB target group probing /health/live; this container check is process liveness so ECS restarts a wedged task. Verified /dev/tcp works in mcr.microsoft.com/dotnet/aspnet:10.0-noble (real connect(), Connection refused on a dead port).

⚠️ Requires the noble image

The currently-deployed image at the pinned tag is chiseled (no shell, no bash) — a shell health check can''t run there. The csproj already targets ContainerFamily=noble, so roll this out with a rebuild:

./deploy.ps1 -Environment dev -Region <region> -BuildApi -AutoApprove

Applying against a chiseled image would mark the container unhealthy; the deployment circuit breaker would roll back (not a permanent crash loop, but the deploy fails).

terraform validate passes.

🤖 Generated with Claude Code