콘솔 어딘가에서 "ECS 만들기"를 누른 적이 있다면, 곧바로 떠오르는 질문이 두 개 있다. "왜 EKS를 안 쓰지?", "이거 Fargate랑 무슨 차이지?" 표면적으로는 셋 다 "컨테이너를 띄우는 도구"로 보이는데, 비용 청구서를 받아보면 한 달에 수백 달러씩 차이가 난다. SAP 시험은 이 세 가지가 들어간 시나리오를 한 도메인당 평균 3~4문제씩 출제하는데, 표면적인 키워드 매칭으로는 절반도 못 맞춘다.
이 글에서는 ECS·EKS·Fargate가 왜 이런 형태로 진화했고, 컨트롤 플레인과 데이터 플레인이 어떻게 갈리며, 시나리오에 따라 어디서 분기가 나는지를 본다. App Runner와 ECS/EKS Anywhere까지 포함해서 "AWS 컨테이너 가족"의 지도를 한 장 그리는 것이 목표다. 시험 직전에 이 지도를 떠올리면 어떤 시나리오를 만나도 답이 4번 중 하나로 좁혀진다.
2013년 도커가 등장하기 전까지 서버 배포는 "특정 서버에 의존하는 작업"이었다. 한 서버 위에 ruby 2.6, python 3.7, node 12를 동시에 깔아두면 의존성 지옥이 시작됐고, "내 노트북에서는 되는데 서버에서는 안 된다"가 일상이었다. 도커가 LXC(Linux Container)와 Union FS 위에 이미지·레이어 개념을 얹어서 이 문제를 해결했지만, 한 서버에 컨테이너 30개를 띄우는 순간 새로운 문제가 생긴다