🔥 EC2란 무엇인가: 가상 머신의 추상 계층
강의 목차
신입 시절 EC2 콘솔에서 'Launch instance' 버튼을 눌렀다. Ubuntu LTS 한 줄을 고르고, t3.micro 한 줄을 고르고, 키 페어를 만들고, Launch를 다시 눌렀다. 5분 뒤 SSH가 들어갔다. 그 5분 동안 AWS 데이터센터에서 정확히 무엇이 만들어졌는지를 그땐 한 줄도 설명할 수 없었다.
그 5분 동안 AWS가 어떤 순서로 어떤 계층을 올리는지부터 짚는다. 처음 EC2를 배울 때 가장 자주 듣는 말은 "EC2는 가상 서버다"인데, 이 표현은 물리 서버부터 애플리케이션까지 이어지는 다섯 계층을 한 단어로 압축한다. 그 다섯 계층을 순서대로 놓고 보면 같은 구조가 인스턴스 타입, OS 패치 책임, 시간 단위 과금이라는 질문을 함께 설명한다.
'Launch'를 누른 5분의 해부, 다섯 계층의 추상
AWS 데이터센터 한 곳에는 수만 대의 물리 서버가 랙에 꽂혀 있다. 각 서버에는 Intel Xeon, AMD EPYC, 또는 AWS Graviton ARM 칩이 들어간다. AWS는 그 한 대의 물리 서버 위에서 여러 사용자의 EC2 인스턴스를 함께 돌린다. AWS는 그 분할을 AWS Nitro System이라는 경량 하이퍼바이저로 처리한다.
Nitro는 AWS가 2017년 C5 인스턴스 세대부터 적용한 가상화 기반이다. 이전 Xen 기반 세대와 다른 점은 가상화 오버헤드를 전용 하드웨어로 넘겼다는 데 있다. Nitro는 네트워크, 스토리지, 보안 처리를 Nitro Card로 보내고 호스트 CPU 사이클은 대부분 인스턴스 계산에 남겨 둔다. 그래서 같은 물리 한 대에서도 베어메탈에 가까운 성능이 나온다. 이건 단순한 기술 자랑이 아니라 다음 사실의 출발점이다. 한 m6i.metal 한 대(128 vCPU·512 GiB)가 가진 물리 자원 위에서 m6i.large(2 vCPU·8 GiB) 분량의 작은 인스턴스가 수십 개씩 동시에 돌 수 있는 건 Nitro가 그 분할을 거의 무료로 처리하기 때문이다.
AWS는 이 분할 위에 EC2 인스턴스라는 실행 단위를 배치한다. 인스턴스는 vCPU 수, RAM 용량, 네트워크 대역폭으로 묶은 자원 단위다. 그 다음에는 내가 고른 게스트 OS가 올라가고 Ubuntu, Amazon Linux, Windows Server를 모두 선택할 수 있다. 그 OS 위에서 내 앱이 돈다.
다섯 계층을 위에서 아래로 적으면 이렇게 된다.
물리 서버 (Intel/AMD/Graviton)
└─ Nitro 하이퍼바이저
└─ EC2 인스턴스 (vCPU·RAM·NIC 슬라이스)
└─ 게스트 OS (Ubuntu / Amazon Linux / Windows ...)
└─ 내 앱물리 서버 (Intel/AMD/Graviton)
└─ Nitro 하이퍼바이저
└─ EC2 인스턴스 (vCPU·RAM·NIC 슬라이스)
└─ 게스트 OS (Ubuntu / Amazon Linux / Windows ...)
└─ 내 앱*.metal 인스턴스(예: m6i.metal)는 하이퍼바이저를 거치지 않고 게스트 OS가 물리 하드웨어를 직접 쓰는 예외다. AWS는 VMware Cloud on AWS처럼 자체 하이퍼바이저가 필요한 워크로드를 위해 이 유형을 제공한다. 대부분의 일반 워크로드는 이 유형을 선택할 이유가 없다.
다섯 계층 위의 공유 책임 모델
다섯 계층을 나눠 놓고 나면 다음 질문이 바로 붙는다. 그중에서 내가 직접 관리하는 범위는 어디서 시작할까. 공유 책임 모델은 그 경계를 한 줄로 정한다.
AWS는 클라우드 자체의 보안을 맡고, 사용자는 클라우드 안에서 돌아가는 자산의 보안을 맡는다. EC2에서는 하이퍼바이저 아래를 AWS가 관리하고 게스트 OS부터는 사용자가 관리한다. 데이터센터 보안, 물리 서버, 전원, 네트워크 백본, Nitro 하이퍼바이저는 AWS 책임이고 게스트 OS, 미들웨어, 애플리케이션, 데이터, 네트워크 설정, 자격 증명은 사용자 책임이다.
이 한 줄의 무게는 구체 사건에서 가장 먼저 드러난다. Linux 커널에 OpenSSL CVE 한 건이 떴다고 해 보자. AWS는 내가 띄운 EC2 인스턴스 안의 OpenSSL을 대신 패치해 주지 않는다. 내가 SSH로 들어가서 apt upgrade를 직접 돌리거나, 패치된 AMI를 새로 굽고 인스턴스를 교체해야 한다. 같은 사건이 RDS 위에서 일어났다면 결과가 다르다. RDS는 같은 Shared Responsibility Model 가족이지만 경계가 OS보다 위에 있어서, AWS가 점검 창 안에서 패치를 직접 적용한다. 두 서비스가 같은 모델을 공유한다는 말이 책임의 위치까지 같다는 뜻은 아니라는 대목이다.
AWS가 이 경계를 나눠 두는 이유는 분명하다. 한쪽이 모든 책임을 떠안으면 컴플라이언스 문서와 운영 통제 기준의 경계가 모호하다. 감사자는 PCI-DSS, HIPAA, ISO 27001 같은 표준에서 책임 주체와 통제 범위를 뚜렷하게 구분한 문서를 요구한다. 또 하나는 사용자가 운영 방식을 직접 정할 수 있어야 한다는 점이다. 인스턴스 안의 OS, 앱, 자격 증명은 사용자가 통제해야 하고, AWS가 그 권한까지 가져가면 EC2는 Lambda나 App Runner 같은 다른 서비스 쪽으로 성격이 바뀐다.
'관리형'이라는 단어가 감추는 비용
공유 책임 모델은 보통 보안 문서나 컴플라이언스 문서에서 먼저 등장한다. 하지만 운영을 시작하면 이 모델의 무게가 가장 먼저 드러나는 곳은 따로 있다. EC2는 관리형 서비스가 아니므로 사용자가 매일 처리할 운영 작업이 그대로 남는다.
회사 사이드 프로젝트 하나를 t3.micro 한 대로 1년 운영했다. 그 1년 동안 나는 Ubuntu 22.04 LTS를 24.04 LTS로 올렸고, 노출된 SSH 키를 두 번 교체했고, /var/log/journal이 디스크를 잠식하자 journalctl --vacuum-size=200M을 cron에 등록했다. 또 EBS 스냅샷 자동 백업을 Data Lifecycle Manager로 매일 새벽 3시에 실행했고, CloudWatch agent를 설치해 메모리와 디스크 사용률 메트릭을 직접 보냈다.
이 다섯 가지 작업은 EC2가 운영 책임을 사용자에게 남겨 두기 때문에 생긴다. 같은 워크로드를 AWS Lambda로 옮기면 OS 패치, SSH 관리, 디스크 청소, 메트릭 에이전트 설치 같은 일은 처음부터 사용자 업무에 들어오지 않는다. Lambda는 실행 환경 아래의 OS를 감추기 때문에 그 영역은 AWS가 관리한다. 함수 코드 자체는 ZIP이나 컨테이너로 버전 관리하므로 EBS 스냅샷이라는 개념도 등장하지 않는다. 같은 식으로 AWS Fargate도 OS 패치, SSH, 디스크 청소를 사용자에게 남기지 않는다.
이 차이가 EC2 다음 세대(Lambda·Fargate·App Runner) 서비스가 등장한 이유다. 어느 날 AWS가 "이 비용을 자동화해 줄게요, 대신 자유도는 일부 가져갈게요"라고 제안한 결과물이 그 서비스들이다. 그래서 EC2를 켤지 Lambda를 쓸지를 정할 때 가장 중요한 한 줄은 "내가 OS 위 다섯 가지 작업을 직접 하고 싶은가, 자동화에 양보하고 싶은가"가 된다.
EC2가 혼자 살지 못하는 이유, 다섯 이웃
EC2 인스턴스 한 대는 절대로 단독으로 동작하지 못한다. 'Launch instance' 버튼이 끝까지 켜지려면 다섯 이웃이 같이 있어야 한다. 이 다섯을 알지 못하면 EC2 콘솔에서 빨간 에러 메시지를 읽고도 무엇이 빠졌는지 모르는 상태가 된다.
첫째 이웃은 VPC와 Subnet이다. 모든 EC2 인스턴스는 한 VPC의 한 Subnet 안에서 IP를 받는다. ENI라는 가상 NIC가 그 Subnet에서 IP를 할당받아야 인스턴스가 네트워크에 닿는다. 둘째는 IAM Role이다. 인스턴스 안에서 다른 AWS API(S3·DynamoDB·Secrets Manager 등)를 부르려면 Instance Profile에 IAM Role을 매달아야 하고, 인스턴스는 IMDS를 통해 그 자격증명을 받는다. 셋째는 Security Group이다. 인스턴스 레벨 방화벽이고, 어떤 포트로 누가 들어올 수 있는지를 정한다. 넷째는 EBS Volume이다. 루트 디스크 한 장이 기본으로 붙고, 추가 디스크를 더 매달 수도 있다. 다섯째는 CloudWatch다. 인스턴스 메트릭(CPU·네트워크·디스크 I/O)이 자동으로 들어온다.
다섯 이웃 가운데 하나만 빠져도 인스턴스 운영이 바로 멈춘다. VPC가 없으면 ENI를 붙일 수 없고, ENI가 없으면 인스턴스는 네트워크에 닿지 못한다. IAM Role이 없으면 인스턴스 안에서 aws s3 ls 같은 호출을 할 수 없고, 액세스 키를 환경 변수에 직접 넣는 방식은 자격 증명 관리 원칙과 어긋난다. Security Group 없이는 SSH·HTTP 어떤 포트도 열리지 않는다. EBS 루트 없이는 OS가 부팅하지 않는다. CloudWatch 없이는 콘솔에서 "이 인스턴스가 살아 있는가"를 그래프로 확인할 수 없다.
이 다섯 이웃 때문에 EC2는 단독 컴포넌트가 아니라 여러 AWS 서비스와 함께 움직이는 컴퓨터가 된다. 그래서 EC2를 한 줄로 부를 때는 "AWS Nitro 위에서 다섯 이웃과 함께 동작하는 가상 컴퓨터"라고 적는 편이 더 정확하다.
EC2를 이해하는 출발선
EC2를 이해하려면 다섯 계층, 책임 경계, 다섯 이웃을 먼저 붙잡아야 한다. 이 셋을 같이 놓고 읽으면 EC2는 더 이상 막연한 가상 서버가 아니다. 사용자는 OS 위를 직접 맡고 AWS는 그 아래를 책임지는 구조다.
이 구조를 잡고 나면 인스턴스 타입이 왜 그렇게 많은지 바로 묻게 된다. 이어서 AMI를 누가 만들고 무엇을 담는지도 확인해야 한다. 디스크 연결 방식, 가격 모델 차이, 오토 스케일링 방식도 같은 축에서 따라온다.
EC2 인스턴스를 만들기 전에 먼저 콘솔 좌측 상단의 Region을 확인한다. Region 선택이 다섯 이웃과 책임 경계가 놓일 범위를 먼저 고른다. Region을 고르면 그 안에서 VPC, Subnet, 가용 영역, EBS 가격 범위까지 함께 따라온다.
참고 자료
- Amazon EC2 User Guide: EC2 핵심 개념 공식 문서
- AWS Nitro System: Nitro 하이퍼바이저 구조와 도입 배경
- AWS Shared Responsibility Model: 클라우드와 내 책임 경계의 정식 정의
- EC2 Instance Types: 인스턴스 타입 목록
- Amazon EBS: EC2의 기본 블록 스토리지
YouTube 영상
