클라우드 인프라가 수백 개의 리소스로 커지면, "지금 우리 환경이 안전한 상태인가?"라는 질문에 사람이 직접 답하는 게 불가능해진다. 어제까지 모든 S3 버킷이 퍼블릭 액세스 차단(BPA)이었는데, 누군가 오늘 한 버킷을 공개로 바꿨다면? 어제까지 모든 EBS 볼륨이 암호화됐는데, 새로 만든 볼륨 하나가 평문이라면? 이런 "원하는 상태(desired state)에서 벗어나는 표류(drift)"는 시간이 지날수록 누적되고, 그 한 틈이 보안 사고의 입구가 된다. 핵심 문제는 두 가지다 — 첫째, 표류를 어떻게 지속적으로 감지할 것인가. 둘째, 표류를 발견했을 때 어떻게 자동으로 교정할 것인가.
AWS는 이 두 문제를 두 서비스로 나눠 푼다. AWS Config(2014)는 "리소스의 구성을 계속 기록하고, 원하는 상태(Rule)와 비교해 위반을 감지"하는 거버넌스 도구다. **Systems Manager(SSM)**는 "인스턴스와 리소스를 중앙에서 실제로 조작·교정"하는 운영 도구다. Config가 "무엇이 잘못됐는지"를 알려주면 SSM이 "그것을 고친다." 이 글은 두 서비스의 기능을 나열하는 대신, "desired state 모델이 왜 인프라 관리의 핵심 패러다임인지", "Session Manager가 어떻게 SSH 키와 베스천 호스트를 없앴는지", "Config + SSM 자동 교정이 어떤 제어 루프를 만드는지"를 따라가며 SAA 운영 도메인의 본질을 짚는다.