EC2를 처음 배우면 패밀리 이름과 구매 옵션 표를 외우려 든다. 하지만 솔루션 아키텍트에게 정작 중요한 건 "왜 이런 종류가 생겼는지"다. CPU-바운드 워크로드와 메모리-바운드 워크로드가 왜 다른 하드웨어 구성을 요구하는지, Spot이 90% 할인을 줄 수 있는 경제적 구조는 무엇인지를 이해하면, 이름을 외우지 않아도 시나리오를 보는 순간 답이 떠오른다.
이 글에서는 EC2 인스턴스 설계의 물리적·역사적 배경부터 구매 옵션의 수학, Nitro 하이퍼바이저 내부, Graviton ARM의 등장, Placement Group이 분산 시스템 이론과 어떻게 맞닿아 있는지까지를 다룬다.
2006년 S3 출시 이후 몇 달 뒤 EC2 베타가 열렸을 때, 인스턴스 타입은 단 하나였다. m1.small이라 불렸던 이 인스턴스는 1 vCPU, 1.7GB RAM, 160GB 로컬 스토리지를 제공했고, 모든 워크로드가 이 하나의 틀에 맞춰야 했다. 그러나 고객들이 다양한 워크로드를 올리기 시작하면서 문제가 드러났다. 비디오 인코딩을 돌리는 고객은 RAM이 남아돌았고, 인메모리 데이터베이스를 돌리는 고객은 CPU가 놀고 있었다. 낭비다.
AWS는 2009년부터 워크로드별 최적화 패밀리를 분리하기 시작했다. 이 결정의 기저에는 컴퓨터 아키텍처의 오래된 병목 이론, Amdahl의 법칙이 있다