운영팀이 한 번쯤 겪는 사건이 있다. 새벽에 보안팀이 "log4shell 패치를 모든 EC2에 즉시 적용하라"는 요청을 보낸다. SSM Patch Manager로 돌리려고 보니 일부 인스턴스는 Patch Manager Agent가 없고, 일부는 패치 후 부팅 안 되는 의존성이 있고, 일부는 패치 도중 워크로드가 멈춘다. 운영자는 "다음에는 새 AMI를 만들어 ASG에 통째로 갈아끼우자"고 다짐한다. 그게 Golden AMI 패턴이고, 그 다짐을 자동화한 게 EC2 Image Builder다.
이 글에서는 Image Builder가 왜 단순한 Packer 대체품이 아니라 "AWS 네이티브 immutable infrastructure 파이프라인"으로 설계됐는지, Recipe·Component·Pipeline이라는 세 레이어가 어떤 책임 분리를 따르는지, 그리고 Golden AMI를 운영 ASG에 흘려보내는 정석 패턴(SSM Parameter Store + Launch Template {{resolve:ssm:...}})이 어떻게 동작하는지 본다. 시험 표 암기가 아니라 "왜 Image Builder가 EC2 콘솔이 아닌 별도 서비스로 분리됐는가"라는 설계 의도를 따라가는 게 목표다.
전통적 서버 운영은 mutable infrastructure다