Day 1 - EC2의 해부학: Nitro, 인스턴스 패밀리, AMI의 내부

EC2는 2006년 8월 25일 베타로 출시된 AWS의 가장 오래된 컴퓨트 서비스다. 처음엔 m1.small 한 종류, 단일 리전(us-east-1), 단순한 launch-and-pray 모델이었다. 20년이 지난 지금 EC2는 750개 이상의 인스턴스 타입, Nitro 하이퍼바이저, Graviton ARM 칩, EBS 직결 스토리지를 갖춘 거대한 컴퓨트 생태계가 됐다. 개발자가 이걸 다 외울 수는 없지만, 인스턴스 패밀리의 명명 규칙과 Nitro의 의미를 이해하면 시험 문제를 푸는 데 도움이 된다.

오늘은 EC2를 코드가 돌아가는 컨테이너로 보지 말고 "가상화된 OS를 실행하는 격리된 컴퓨트 단위"로 본다. 그 격리가 어떻게 가능한지, AMI가 정확히 무엇인지, 왜 t2와 t3가 다르게 동작하는지를 파헤친다.

EC2의 가상화 진화: Xen에서 Nitro까지

2006년 EC2가 처음 출시됐을 때 가상화 엔진은 Xen(2003년 케임브리지 대학에서 출발한 오픈소스 하이퍼바이저)이었다. Xen은 paravirtualization(게스트 OS가 자기가 가상화됐다는 걸 알고 협력)으로 시작했지만, 점차 hardware-assisted virtualization(Intel VT-x, AMD-V)으로 진화했다. 문제는 Xen이 무거웠다는 점이다. CPU·메모리·네트워크·스토리지 가상화가 모두 hypervisor 안에서 일어나서 약 30%의 오버헤드가 있었다.

AWS는 2013년부터 Nitro 시스템을 개발하기 시작해 2017년 c5에서 처음 출시했다. Nitro의 혁신은 하이퍼바이저 기능을 전용 하드웨어 카드(Nitro Cards)에 오프로드한 것이다. 네트워크 가상화는 Nitro Network Card, 스토리지 가상화는 Nitro EBS Card, 보안은 Nitro Security Chip이 처리한다. 호스트 OS의 KVM(Linux 커널 내장 하이퍼바이저)은 거의 thin layer로 남고, 게스트 인스턴스는 bare-metal에 가까운 성능을 낸다.

Nitro의 또 다른 효과는 Firecracker microVM의 탄생이다. Lambda와 Fargate가 동작하는 그 microVM은 KVM 위에서 125ms 안에 부팅 가능하고, 메모리 footprint는 5MB 미만이다. Firecracker는 Nitro 개발 과정에서 축적된 minimal hypervisor 기술이 만든 산물이며, 같은 호스트에서 수천 개 microVM을 격리 실행할 수 있게 한다. 이게 Lambda의 "함수당 격리"를 가능하게 한 핵심 인프라다. 더 자세한 내용은 Week 4에서 Lambda를 다룰 때 다시 다룬다.

Nitro Security Chip은 부팅 시점에 펌웨어 무결성을 검증하고, host kernel이 게스트 메모리에 직접 접근하지 못하게 막는다. 이게 2018년 Spectre·Meltdown 사이드채널 공격에서 AWS가 대부분의 인스턴스 타입을 빠르게 패치할 수 있었던 이유 중 하나다. KVM 기반 Nitro 인스턴스는 호스트와 게스트 간 메모리 격리가 하드웨어 수준에서 강제된다. 자세한 아키텍처는 The Security Design of the AWS Nitro System 백서에 정리돼 있다.

인스턴스 패밀리: 한 글자가 알려주는 워크로드 적합도

EC2 인스턴스 타입은 m5.xlarge처럼 패밀리 + 세대 + 크기로 명명된다. 패밀리 한 글자가 핵심.

세대 숫자(5, 6, 7)는 차세대 칩 + 더 빠른 네트워크. 접미사도 의미가 있다.

m6g.large는 "범용(m) 6세대 Graviton(g) ARM 칩에 large 크기". 시험에서 비용 최적화 시나리오는 Graviton(g)이 답이 되기 쉽다(같은 성능에 약 20% 저렴).

Graviton의 가격 우위가 가능한 이유는 AWS가 칩을 직접 설계하기 때문이다. 2018년 Graviton1(A1 인스턴스, Arm Cortex-A72 코어 16개)을 시작으로, 2020년 Graviton2(Arm Neoverse-N1 64코어)는 c6g·m6g·r6g, 2021년 발표된 Graviton3는 c7g·m7g·r7g에 들어갔다. 2023년 발표된 Graviton4는 칩당 코어가 96개로 늘었고, 2024년 r8g를 시작으로 c8g·m8g에 들어갔다. Intel/AMD 칩을 사 오는 대신 직접 설계해 마진을 절약하고, 그 일부를 고객에 돌려준다. ARM 인스트럭션 세트는 RISC라 같은 와트당 성능이 x86보다 높은 경향이 있다.

t 시리즈의 비밀: CPU credit 메커니즘

t 시리즈(burstable)는 다른 패밀리와 완전히 다른 과금 모델을 쓴다. baseline CPU 사용률 이하로 쓰면 CPU credit을 쌓고, baseline을 초과하면 credit을 소비한다.

t2와 t3의 가장 큰 차이는 credit 소진 시 동작이다. t2는 standard 모드만 있어서 credit이 떨어지면 baseline CPU로 제한된다(스로틀링). t3는 기본이 unlimited 모드로, credit이 떨어져도 추가 비용을 내고 burst를 유지한다. CloudWatch에서 CPUSurplusCreditBalance 지표가 0보다 크면 추가 과금이 일어나고 있다는 뜻. 비용 예측이 중요한 워크로드에선 t3를 standard 모드로 명시적 전환하거나 m 시리즈를 쓰는 게 안전하다.

⚠️ 함정: t3.medium을 "프로덕션 API 서버"로 쓰는 건 시험에서 오답 보기로 쓰이기 쉽다. 트래픽이 baseline 30%를 자주 넘으면 credit이 빠르게 소진되고, unlimited 비용이 m5보다 비싸지는 경계점이 있다. AWS Compute Optimizer가 이를 분석해 패밀리 변경을 추천한다.

AMI: 디스크 이미지 + 메타데이터

AMI(Amazon Machine Image)는 EC2를 시작할 때 사용하는 디스크 이미지다. 정확히는 EBS 스냅샷(또는 instance-store 매니페스트) + 부팅 메타데이터(커널, ramdisk, 블록 디바이스 매핑) 의 묶음이다.

AMI 구성:
├─ Root EBS Snapshot     (OS + 사전 설치 SW)
├─ Additional EBS Snapshots (선택적 추가 볼륨)
├─ Block Device Mapping  (디스크 → /dev/xvda 등 매핑)
├─ Kernel/RamDisk ID     (PV-AMI인 경우)
└─ Launch Permissions    (어느 계정이 이 AMI로 시작 가능한가)

AMI 종류는 3가지다.

AMI는 리전 단위로 존재한다. us-east-1에서 만든 AMI를 ap-northeast-2에서 쓰려면 CopyImage API로 복사해야 한다. 복사 시 ID가 바뀌고, EBS 스냅샷도 같이 복사된다(별도 비용).

실무에서는 신뢰할 수 있는 AMI ID를 SSM Parameter Store(/aws/service/ami-amazon-linux-latest/...)에서 가져오는 패턴이 표준이다.

EC2 시작 시퀀스: User Data와 IAM Role

EC2 인스턴스를 시작하면 다음 순서로 부팅된다.

1. Nitro hypervisor가 인스턴스 할당, EBS 볼륨 attach
2. ENI(Elastic Network Interface) attach
3. AMI에서 부팅 (BIOS/UEFI → bootloader → kernel)
4. cloud-init이 IMDS에서 메타데이터 조회
   - hostname, security groups, IAM role 등
5. cloud-init이 user-data 실행 (#!/bin/bash 또는 cloud-config YAML)
6. SSH/RDP 서비스 시작

User data는 인스턴스 시작 시 한 번만(기본) 실행되는 부트스트랩 스크립트다. 흔한 패턴은 SSM Agent 설치, 애플리케이션 코드 다운로드, 시크릿 주입.

#!/bin/bash
yum update -y
yum install -y httpd
echo "<h1>Hello from $(hostname)</h1>" > /var/www/html/index.html
systemctl enable --now httpd

🔍 더 깊이: user-data는 IMDS의 http://169.254.169.254/latest/user-data에서 읽을 수 있다. 그래서 user-data에 비밀번호나 API key를 박으면 인스턴스 내부 모든 프로세스가 그것을 읽을 수 있다. IMDSv2 강제, SSM Parameter Store/Secrets Manager 사용, IAM Role 활용이 표준 패턴이다. 시험에 "user-data에 DB 비밀번호를 박았다"는 시나리오가 나오면 오답이고, "Secrets Manager에서 부팅 시 가져오기"가 답이다.

Placement Group: 인스턴스를 어디에 둘지

인스턴스가 같은 AZ 안에서 어떻게 분산되는지를 제어하는 옵션이다.

Cluster placement는 인스턴스 간 10 Gbps full-bisection bandwidth를 제공해 MPI(Message Passing Interface) 같은 워크로드에서 latency를 최소화한다. 단점은 하드웨어 장애 시 모든 인스턴스가 같이 죽을 수 있다는 것.

Partition placement는 Cassandra·HBase 같은 분산 시스템의 rack awareness와 동일한 발상이다. 각 파티션은 서로 다른 랙·전원·네트워크 스위치에 매핑된다. 데이터 복제본을 다른 파티션에 두면 한 파티션이 죽어도 데이터가 살아남는다. AWS는 AZ당 최대 7개 파티션을 지원하므로, 7개 복제본까지 자연스럽게 격리할 수 있다.

가격 모델 4가지

Spot은 "아무 때나 죽어도 되는" 워크로드만. CI 빌드, 배치 분석, fault-tolerant 작업. 시험에 "stateless and can be interrupted"가 보이면 Spot 답.

Spot 가격은 AWS 내부 수요에 따라 동적으로 결정된다. 예전엔 명시적 입찰(maximum bid price)이 필요했지만, 2018년 이후 단순화돼 max price를 명시 안 하면 On-Demand 가격을 상한선으로 자동 적용한다. Spot 회수는 항상 2분 사전 통보(spot interruption notice via IMDS의 latest/meta-data/spot/instance-action)와 함께 오므로, 워크로드가 이 신호를 듣고 graceful shutdown 하도록 만든다. Spot Fleet과 EC2 Fleet은 여러 인스턴스 타입·AZ를 혼합해 회수율을 분산시킨다.

CLI로 EC2 시작

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --key-name MyKeyPair \
  --security-group-ids sg-0123456 \
  --subnet-id subnet-0abc123 \
  --iam-instance-profile Name=MyInstanceProfile \
  --user-data file://bootstrap.sh \
  --metadata-options "HttpTokens=required" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=web-1}]'

HttpTokens=required로 IMDSv2 강제, IAM 인스턴스 프로파일로 자격증명 자동 주입, 태그로 식별. 이 옵션들을 기억하면 실무의 기본적인 EC2 시작 시나리오를 다룰 수 있다.

정리

EC2의 핵심은 Nitro 하이퍼바이저 + 인스턴스 패밀리의 워크로드 적합도 + AMI 라이프사이클이다. 패밀리 한 글자(t/m/c/r/x/i/d/p/g)로 적합한 워크로드를 식별하고, Graviton(g 접미사)으로 비용을 줄이고, t 시리즈의 credit 모델을 이해하면 시험의 EC2 관련 문제를 푸는 기본기가 된다.

다음 글에서는 EC2의 네트워크 통제 — 보안 그룹, 키 페어, user-data 보안 — 를 본다.