운영 자동화 도구의 역사는 진자 운동이다. 처음엔 모두가 SSH 스크립트를 짰고, Chef·Puppet이 그 자리를 받았으며, Docker가 mutable config 자체를 거부했고, Kubernetes가 다시 declarative config를 가져왔다. AWS도 이 진자 위를 따라 움직였다. OpsWorks for Chef Automate(2017)와 OpsWorks for Puppet Enterprise는 한때 "AWS 위에서 Chef/Puppet을 매니지드로 받는" 유일한 합법 경로였지만, 2024년 5월 26일 OpsWorks Stacks는 공식 EOL됐고, AWS는 Systems Manager로의 마이그레이션을 권장한다.
이 글에서는 왜 OpsWorks가 시간이 흐르며 SSM에 자리를 내줬는지, Launch Configuration이 Launch Template으로 대체된 이유와 두 도구의 본질적 차이가 무엇인지, 그리고 Mixed Instances Policy + Spot이라는 비용 절감 패턴이 실제로 어떻게 작동하는지 본다. AWS Proton과 Service Catalog의 위치 차이까지 정리한다. 도구 이름 암기보다 "왜 이 진자가 SSM 쪽으로 움직였는가"라는 트렌드 인식이 목표다.