Beanstalk이 "환경까지 묶어준다"는 PaaS 철학으로 출발했다면, CodeDeploy는 정반대 결정에서 시작한다. 인프라는 네가 알아서 만들어라. 나는 코드만 안전하게 올리겠다. 2014년 11월 출시된 이 서비스는 Amazon 내부에서 수년간 쓰던 Apollo deployment system(매년 5천만 회 배포)에서 잘라낸 외부 버전이다. EC2가 기존에 있든, 온프레미스든, Lambda든, ECS Task든 — "이미 돌고 있는 컴퓨트 위에 새 코드를 어떻게 안전하게 얹을 것인가"라는 한 가지 문제만 푼다.
이 글에서는 In-place와 Blue-Green이라는 두 배포 모델의 trade-off를 EC2·Lambda·ECS 각각에서 어떻게 해석하는지, AppSpec.yml의 13개 lifecycle hook이 왜 그 순서로 정해졌는지, 그리고 자동 롤백이 어떤 신호를 보고 동작하는지를 본다. 시험을 위한 hook 이름 암기가 아니라 "왜 BeforeInstall과 AfterInstall이 따로 있어야 하는가" 같은 설계 의도를 따라가는 게 목표다.
2014년의 AWS는 이미 Beanstalk(2011), OpsWorks(2013), CloudFormation(2011)을 갖고 있었다. 세 도구 모두 "코드 배포"를 일부 다루지만, 어느 것도 다음 세 가지 시나리오를 깔끔하게 풀지 못했다.
첫째, 온프레미스 서버에 배포