2.1.2.4. Measuring Application Health & Automating Unit Tests
2.1.2.4. Measuring Application Health & Automating Unit Tests
Application health extends beyond "is the server responding?" to "is the application actually working correctly?" The distinction matters: an EC2 instance can pass health checks while the application returns 500 errors to every user.
Health check layers:
- Infrastructure health: EC2 instance status checks (hardware/hypervisor), ELB health checks (HTTP GET to a path)
- Application health: Custom health endpoints that verify database connectivity, cache availability, and downstream service reachability
- Synthetic health: CloudWatch Synthetics canaries — Lambda-based scripts that simulate user interactions on a schedule and alert on failures
Custom health endpoint pattern:
# /health endpoint that validates all dependencies
def health_check():
checks = {
"database": check_db_connection(),
"cache": check_redis_ping(),
"api": check_downstream_api()
}
all_healthy = all(checks.values())
status = 200 if all_healthy else 503
return {"status": status, "checks": checks}
Automating unit tests in CI/CD: Configure CodeBuild to run tests and fail the build on test failures. Use the reports section in buildspec.yml to publish test results to CodeBuild's test report group — this gives you historical pass/fail trends and identifies flaky tests.
reports:
UnitTestReports:
files: ['test-results/*.xml']
file-format: JUNITXML
Exam Trap: ELB health checks and Auto Scaling health checks are independent. An instance can be "healthy" to the ALB but "unhealthy" to Auto Scaling (or vice versa) depending on configuration. If ASG health check type is set to ELB, a failing ELB health check triggers instance replacement — but the default type EC2 only checks instance status.
