스토리지 선택 실수는 조용히 큰 대가를 치른다. EC2 인스턴스 스토어에 저장한 데이터가 인스턴스 종료와 함께 사라지거나, EBS gp2를 쓰다가 IOPS 한계에 부딪혀 데이터베이스가 멈추거나, EFS 대신 FSx for Windows를 써야 했는데 Linux 마운트를 고집하다 AD 인증이 안 되는 상황이 그 예다. 이런 선택 오류는 대부분 "어떻게 동작하는지"를 몰라서 생긴다.
이 글에서는 EBS의 볼륨 타입별 내부 설계 원리(IOPS 계산, gp3 vs gp2 차이), Instance Store의 물리적 구조와 데이터 손실 시나리오, EFS의 분산 파일 시스템 구조, FSx 4종의 각각의 존재 이유를 다룬다. 스토리지 시스템 이론부터 실제 사고 사례까지 연결해서 읽으면 시험 시나리오가 읽히는 구조가 된다.
EC2 초기에는 모든 스토리지가 인스턴스 스토어였다. 물리 서버에 붙은 로컬 디스크를 그대로 썼고, 인스턴스를 종료하면 데이터도 사라졌다. 개발자들은 중요한 데이터를 S3에 수동으로 백업해야 했다.
2008년 AWS는 EBS(Elastic Block Store)를 출시했다. 핵심 아이디어는 블록 스토리지를 네트워크로 분리한다는 것이었다. 인스턴스와 스토리지가 논리적으로 분리되면 인스턴스가 종료되어도 데이터가 살아있고, 한 인스턴스에서 분리해 다른 인스턴스에 재연결할 수 있다