# Wait for AWS Services After Wake

## Analysis

`make wake CLOUD=aws` changes an existing EC2 instance from `stopped` to
`running`, but the original bootstrap waiter is keyed only by instance ID. It
therefore does not rerun, and the subsequent smoke test can reach MySQL before
the systemd-managed containers are ready. The existing `BootstrapStatus=ready`
tag persists across stop/start, so rerunning the tag waiter would not prove live
service readiness.

| Area | Change | Success criterion |
|---|---|---|
| Terraform lifecycle | Add a waiter keyed by `desired_state` and instance ID after the EC2 state resource | A stopped-to-running apply replaces and executes the waiter |
| Runtime readiness | Query the live systemd unit through SSM | Apply completes only when `date-integration.service` is active |
| Regression coverage | Assert the waiter trigger for running and stopped plans | `terraform test` passes for the AWS root |

## Execution Steps

1. Add an AWS service-readiness script that waits for EC2 and SSM availability,
   then waits for `date-integration.service` to become active.
2. Add a post-state-change `terraform_data` resource whose replacement trigger
   includes `desired_state` and whose execution depends on the EC2 state change.
3. Add plan assertions for both running and stopped modes.
4. Run `terraform fmt -check`, shell syntax checks, `terraform validate`, and
   `terraform test` for the AWS module.

## Risks

- The deployer needs SSM `SendCommand` and command-status read permissions. The
  environment already relies on SSM rather than SSH, and the configured AWS
  deployment role provides these test-environment permissions.
- A failed systemd service now fails Terraform apply before smoke, with the SSM
  command result available for diagnosis.