클라우드의 가장 비싼 실수는 장애가 아니라 방치다. 누군가 3년 전 "넉넉하게" m5.4xlarge를 띄웠고, 그 위에서 도는 서비스는 사실 m5.large면 충분한데, 아무도 다시 들여다보지 않는다. CPU 평균 사용률이 4%인 인스턴스가 24시간 365일 풀 가격으로 청구된다. 온프레미스 시절엔 이런 낭비가 잘 안 보였다 — 서버는 이미 사뒀으니 매몰 비용이었다. 그런데 클라우드는 매시간 과금하므로 과다 프로비저닝이 곧바로 청구서에 박힌다. Right Sizing(적정 사이징)은 이 간극, 즉 "프로비저닝한 용량"과 "실제 쓰는 용량" 사이의 거리를 좁히는 작업이다.
문제는 이 거리를 사람이 눈으로 재기 어렵다는 점이다. CPU만 보면 메모리를 놓치고, 평균만 보면 피크를 놓치고, 한 인스턴스만 보면 200대를 놓친다. AWS Compute Optimizer는 이 판단을 ML에 맡긴다 — 14일치 메트릭을 학습해 "이 인스턴스는 m5.large로 줄여도 됩니다, 월 $X 아낍니다"를 자동으로 뽑아준다. 이 글은 그 권장이 어디서 나오는지, 왜 메모리 메트릭이 없으면 권장이 틀어지는지, 그리고 EC2 인스턴스 패밀리라는 알파벳 코드가 실제로 어떤 하드웨어를 가리키는지 그 내부를 파고든다.
과다 프로비저닝은 클라우드가 만든 문제가 아니라 클라우드가 드러낸 문제다