어제 본 Run Command는 강력하지만 한 가지 약점이 있다. 일회성이라는 점이다. nginx를 재시작하는 명령을 던지면 그 순간엔 다 재시작되지만, 30분 뒤 새 인스턴스가 ASG로 뜨면 그 인스턴스는 아무도 손대지 않은 맨몸 상태다. CloudWatch Agent를 fleet 전체에 깔아도, 다음 주에 누군가 한 대에서 그걸 지워버리면 그 한 대는 조용히 표준에서 벗어난다. fleet은 살아 움직이는 생물이라 한 번 명령을 친다고 그 상태가 유지되지 않는다.
State Manager는 이 문제를 "원하는 상태(desired state)"라는 추상화로 푼다. 명령을 "한 번 실행"하는 게 아니라 "이 상태가 항상 참이어야 한다"고 선언하고, SSM이 주기적으로 실제 상태를 그 선언에 맞춘다. 오늘은 이 desired state 모델이 Kubernetes·Puppet·Chef와 어떻게 같은 뿌리를 갖는지, Inventory로 fleet의 소프트웨어 지형을 수집해 S3로 흘려 Athena로 SQL 질의하는 데이터 레이크 패턴, 그리고 이 모든 결과가 Compliance로 모여 Security Hub까지 흘러가는 거버넌스 파이프라인을 본다. DOP 시험에서 "새 인스턴스에 자동으로 X 설치", "100만 대 인벤토리를 SQL로 분석", "fleet 컴플라이언스 통합 가시화"는 단골 시나리오다.