스타트업이 AWS를 처음 도입할 때 가장 자주 만나는 풍경이 있다. 개발자 두 명, 코드는 Flask 또는 Express, "일단 띄우긴 해야 하는데 ALB는 뭐고 ASG는 뭐고 IAM Role은 또 뭐야". 이런 상황을 해결하기 위해 AWS는 2011년 1월 Elastic Beanstalk를 출시했다. "코드만 zip으로 올리면 EC2·ELB·ASG·CloudWatch까지 알아서 만들어주는 PaaS"라는 약속이었다.
DVA-C02 시험에서 Beanstalk는 ECS, Lambda, App Runner와 함께 "언제 어떤 컴퓨트를 선택할지" 시나리오의 한 축으로 꾸준히 출제된다. 특히 6가지 배포 전략의 차이, .ebextensions와 .platform의 구분, 그리고 RDS를 환경 안에 둘 때의 함정이 단골 출제 포인트다. 이번 글은 Beanstalk의 내부 구조 — 사실은 CloudFormation 위에 얹은 추상화 — 부터 시작해, 각 배포 전략이 실제로 어떻게 동작하는지를 정리한다.
Beanstalk가 등장한 2011년은 Heroku(2007 창업, 2010 Salesforce 인수)가 PaaS 시장의 표준을 만들던 시기였다. git push heroku main 한 줄로 코드가 production에 배포되는 경험은 당시로서는 혁명적이었다