<aside>
CloudWave · W05 · 2/5 · 예상 읽기 7분
</aside>
둘째 날에는 서비스 이름보다 “무엇을 책임지는가”가 중요했다. EC2는 코드를 실행하는 컴퓨팅 자원이고, 저장소는 실행 환경과 다른 수명 주기를 가진다. 여기에 사용자의 요청을 가까운 위치에서 전달하는 계층까지 더해지면 네 가지 서비스의 경계가 선명해진다.
EC2는 가상 서버로서 운영체제와 애플리케이션을 실행한다. 로드 밸런서와 오토 스케일링 그룹을 연결하면 대상의 상태를 확인하고 필요할 때 인스턴스 수를 조정하는 흐름을 만들 수 있다. 그러나 자동 확장이 곧 애플리케이션의 무상태성이나 데이터 보호를 보장하지는 않는다.
EBS는 EC2에 연결하는 네트워크 기반 블록 저장소다. 운영체제가 디스크처럼 다루며 볼륨의 수명과 가용 영역 범위를 고려해야 한다. 스냅샷은 특정 시점의 볼륨 데이터를 보존하는 복사본으로 활용할 수 있지만, 백업의 복구 목표와 보존 정책은 별도로 정해야 한다.
S3는 객체를 버킷과 키의 구조로 저장하고 API를 통해 접근한다. 서버에 디스크를 붙이는 모델이 아니며, 객체의 접근 정책과 수명 주기, 암호화, 버전 관리가 중요한 설계 요소다. EBS와 S3를 같은 “파일 저장소”라고 부르면 복구 방식과 접근 패턴을 잘못 선택하게 된다.
CloudFront는 원본에서 콘텐츠를 가져와 엣지에서 캐시하고 사용자에게 전달하는 서비스다. 원본은 S3나 애플리케이션 서버가 될 수 있지만 CloudFront 자체가 원본 저장소는 아니다. 캐시 정책, 만료, 원본 접근 제한을 함께 설계해야 한다.
가상 서비스 example-app이 정적 자산을 제공한다고 해 보자. 객체는 demo-bucket에 저장하고, 애플리케이션 응답은 EC2에서 만든다. CloudFront는 요청 특성에 맞춰 원본으로 전달하거나 캐시된 응답을 반환한다. 이 구조에서 저장, 실행, 전달을 분리하면 장애 원인도 더 좁게 볼 수 있다.
Dev에서 이미지와 설정을 검증하고 QA와 Staging에서 운영에 가까운 부하와 권한을 확인한 뒤 Production으로 넘긴다. 인스턴스 교체가 데이터 손실로 이어지지 않도록 상태 데이터를 별도 저장소로 분리하고, 캐시 무효화와 배포 순서도 정해야 한다. 실습에서 볼륨을 늘리는 작업과 운영의 온라인 확장·백업 검토는 같은 수준의 결정이 아니다.
EBS는 객체 저장소가 아니고 S3는 EC2의 부팅 디스크가 아니다. CloudFront도 데이터를 영구 보관하는 곳이 아니다. 오토 스케일링은 서버 수 조정이지 데이터베이스 확장이나 모든 장애의 자동 해결을 뜻하지 않는다.
실행, 저장, 전달을 분리해서 보면 AWS 서비스의 이름보다 책임 범위가 먼저 보인다.