기본개념 · 5장

EC2와 컴퓨트

Amazon EC2 문항은 "EC2가 무엇인가"를 묻지 않습니다. 같은 워크로드를 두고 어떤 구매 옵션으로 사느냐, 어떤 배치로 두느냐, 메타데이터를 어떻게 잠그느냐를 묻습니다. 특히 구매 옵션 판단은 비용 최적화 도메인의 중심이고, 여기서 잘못 고르면 다른 설계가 아무리 좋아도 오답이 됩니다.

이 장은 고성능 아키텍처 설계(24%)와 비용 최적화 아키텍처 설계(20%)에 함께 걸칩니다. IMDSv2 부분은 보안 아키텍처 설계(30%)로 이어집니다.

학습 목표

인스턴스 타입 이름에서 패밀리 · 세대 · 부가 기능 · 크기를 읽어 내고, 워크로드에 맞는 패밀리를 고를 수 있습니다.
구매 옵션 다섯 가지의 약정 대상과 유연성 차이를 구분하고, 워크로드 특성으로 하나를 지목할 수 있습니다.
중단 가능한 워크로드에 스팟을, 상시 기저 부하에 Savings Plans를 배정하는 판단을 근거를 들어 설명할 수 있습니다.
AMI와 사용자 데이터로 인스턴스 기동 시간을 줄이는 방법과 그 경계를 설명할 수 있습니다.
배치 그룹 세 가지가 각각 무엇을 최적화하는지 구분하고, 성능과 장애 격리가 반대 방향임을 설명할 수 있습니다.
IMDSv2의 두 단계 요청 구조와 홉 제한이 서버 측 요청 위조를 어떻게 막는지 설명할 수 있습니다.

인스턴스 패밀리와 명명 규칙

인스턴스 타입 이름은 네 부분으로 이루어집니다 — 패밀리 · 세대 · 부가 기능 · 크기입니다. 예를 들어 c5n.xlarge는 컴퓨팅 최적화 패밀리(c)의 5세대(5)이며 네트워크가 최적화되어 있고(n) 크기는 xlarge라는 뜻입니다. 점 뒤가 크기이고, 베어메탈은 metal로 표기합니다.

SAA에서 자주 쓰이는 인스턴스 패밀리 문자와 의미
문자	의미	대표 워크로드
`M`	Most scenarios — 범용	웹 · 애플리케이션 서버, 중소형 데이터베이스
`T`	Turbo — 버스트 가능 성능	평소 부하가 낮고 가끔 튀는 개발 · 소규모 서비스
`C`	Compute — 컴퓨팅 최적화	배치 처리, 미디어 인코딩, 고성능 웹 서버
`R`	Random access memory — 메모리 최적화	인메모리 캐시, 대용량 인메모리 데이터베이스
`X` · `U`	Extra-large memory · Ultra-high memory	인메모리 데이터베이스, 대규모 분석
`I` · `D`	I/O · Dense storage — 스토리지 최적화	NoSQL, 데이터 웨어하우스, 분산 파일 시스템
`P` · `G` · `Inf` · `Trn`	GPU · AWS Inferentia · AWS Trainium — 가속 컴퓨팅	머신러닝 학습과 추론, 그래픽 워크로드
`Hpc`	High performance computing	노드 간 통신이 잦은 병렬 시뮬레이션

패밀리 문자 뒤에 붙는 부가 기능 문자도 문항의 힌트가 됩니다 — a는 AMD, g는 AWS Graviton, i는 Intel 프로세서, d는 인스턴스 스토어 볼륨, n은 네트워크 최적화, b는 블록 스토리지 최적화, e는 추가 스토리지나 메모리, z는 고클럭입니다. d가 붙은 타입은 인스턴스 스토어를 포함하므로 6장의 인스턴스 스토어 휘발성이 그대로 적용됩니다.

인스턴스 타입 목록은 계속 늘어나므로 개별 타입의 vCPU 수와 메모리 크기를 외우지 않습니다. 시험이 요구하는 것은 "메모리가 많이 필요하다 → R 계열", "컴퓨팅이 필요하다 → C 계열" 수준의 매핑입니다. 실제 설계에서는 조회해서 씁니다.

describe-instance-types.sh — 조건에 맞는 인스턴스 타입 조회 (리전은 예시입니다)

aws ec2 describe-instance-types \
  --filters "Name=memory-info.size-in-mib,Values=32768" \
            "Name=current-generation,Values=true" \
  --query 'InstanceTypes[].[InstanceType,VCpuInfo.DefaultVCpus,MemoryInfo.SizeInMiB]' \
  --region ap-northeast-2 \
  --output table

인스턴스를 키울 것인가, 늘릴 것인가

인스턴스 타입을 더 큰 것으로 바꾸는 것이 수직 확장이고, 같은 인스턴스를 여러 대로 늘리는 것이 수평 확장입니다. EC2에서 타입 변경은 인스턴스를 중지한 상태에서만 할 수 있으므로 중단이 따라옵니다. 게다가 인스턴스가 한 대인 이상 단일 장애점은 그대로 남습니다.

그래서 탄력성 · 확장성 · 고가용성이 요구되면 답은 수평 확장이고, 그 장치가 7장의 Auto Scaling 그룹입니다. 수직 확장이 정답이 되는 경우는 수평으로 나눌 수 없는 워크로드일 때입니다.

구매 옵션 5종 — 무엇을 약정하는가 SAA 빈출

구매 옵션은 결국 무엇을 얼마나 약속하고 그 대가로 무엇을 포기하느냐의 문제입니다. 아무것도 약속하지 않으면 온디맨드이고, 금액을 약속하면 Savings Plans, 구성을 약속하면 예약 인스턴스, 중단을 감수하면 스팟, 물리 호스트를 통째로 쓰면 전용 호스트입니다.

구매 옵션 결정 트리 — 중단을 허용할 수 있는가, 사용 기간을 약정할 수 있는가, 라이선스나 규정이 물리적 격리를 요구하는가라는 세 갈래로 다섯 옵션이 갈립니다

EC2 구매 옵션 다섯 가지의 약정 대상과 성격
옵션	무엇을 약정하는가	중단 가능성	언제 고르는가
온디맨드	없음. 실행한 초 단위로 지불	없음	부하를 예측할 수 없는 초기 단계, 단기 실험, 스파이크 대응
Savings Plans	시간당 사용 금액을 1년 또는 3년 약정	없음	상시 기저 부하가 있고, 인스턴스 구성을 바꿀 여지를 남기고 싶을 때
예약 인스턴스(RI)	인스턴스 구성(타입 · 리전 등)을 1년 또는 3년 약정	없음	구성이 고정되어 있고, 특정 가용 영역의 용량 확보가 필요할 때
스팟 인스턴스	없음. 대신 AWS가 용량을 회수할 수 있음	있음 — 2분 전 통지 후 중단	중단되어도 되는 배치 · 분석 · 렌더링 · 백그라운드 처리
전용 호스트 · 전용 인스턴스	물리 서버 단위(호스트) 또는 단일 테넌트 하드웨어(인스턴스)	없음	소켓 · 코어 단위 라이선스를 가져와야 하거나 물리적 격리가 규정인 경우

구매 옵션의 상대 비용과 유연성 위치. 비용을 낮추는 방향과 유연성을 지키는 방향이 서로 반대라는 것이 이 그림의 결론입니다. 두 축 모두 등급이며 실제 금액이 아닙니다 — 요금은 리전과 시점에 따라 달라집니다

온디맨드 — 기준선

약정이 없고 실행한 만큼 지불합니다. 다른 옵션의 절감 효과는 언제나 온디맨드 요율을 기준으로 설명됩니다. 시험에서 온디맨드가 정답이 되는 경우는 기간이 짧거나 부하를 아직 모를 때입니다. "1년 약정" 같은 조건이 문제에 없는데 예약 인스턴스를 고르는 것은 과잉 설계입니다.

예약 인스턴스 — 구성을 약정한다

예약 인스턴스는 인스턴스 타입과 리전을 포함한 구성을 1년 또는 3년 약정하고 온디맨드보다 낮은 요율을 적용받습니다. 선택할 것이 세 가지 있습니다.

예약 인스턴스의 세 가지 선택 축
축	값	차이
범위(scope)	`Region` / `Availability Zone`	리전 범위는 용량을 예약하지 않지만 가용 영역과 인스턴스 크기 유연성이 있고, 가용 영역 범위는 해당 가용 영역의 용량을 예약하지만 유연성이 없다
제공 클래스	`standard` / `convertible`	표준은 절감 폭이 크고, 컨버터블은 기간 중 다른 인스턴스 구성으로 교환할 수 있다
결제 방식	`All Upfront` / `Partial Upfront` / `No Upfront`	선결제 비중이 클수록 절감 폭이 커진다

시험에서 "특정 가용 영역에 용량을 확보해야 한다"는 조건이 붙으면 리전 범위 예약 인스턴스나 Savings Plans는 답이 아닙니다. 용량 예약이 필요하면 가용 영역 범위 예약 인스턴스 또는 온디맨드 용량 예약(On-Demand Capacity Reservations)입니다.

Savings Plans — 금액을 약정한다

Savings Plans는 인스턴스 구성이 아니라 시간당 사용 금액을 1년 또는 3년 약정합니다. 약정한 금액까지는 할인 요율이 적용되고, 초과분은 온디맨드 요율로 청구됩니다. 결제 방식은 예약 인스턴스와 같이 세 가지입니다. SAA 범위에서 구분해야 할 유형은 두 가지입니다.

Savings Plans 두 유형의 적용 범위
유형	API 값	적용 범위
Compute Savings Plans	`Compute`	인스턴스 패밀리 · 크기 · 리전 · 운영체제 · 테넌시를 바꿔도 적용되고, AWS Fargate와 AWS Lambda 사용량에도 적용된다. 가장 유연하다
EC2 Instance Savings Plans	`EC2Instance`	특정 리전의 특정 인스턴스 패밀리에 한정된다. 유연성을 포기하는 대신 Compute 유형보다 절감 폭이 크다

스팟 인스턴스 — 중단을 감수한다

스팟 인스턴스는 남는 EC2 용량을 온디맨드보다 낮은 가격에 쓰는 방식입니다. AWS가 용량이 필요해지면 인스턴스를 회수하며, 이때 2분 전에 중단 통지(interruption notice)가 인스턴스 메타데이터로 전달됩니다. 더 이른 신호로 재조정 권장(rebalance recommendation)이 있어 중단 위험이 높아졌을 때 미리 워크로드를 옮길 기회를 줍니다.

스팟 인스턴스 중단 처리 타임라인 — 재조정 권장 신호와 2분 중단 통지를 받아 진행 중 작업을 마무리하고 체크포인트를 남긴 뒤 Auto Scaling이 대체 용량을 확보합니다. 상태 비저장 설계가 전제입니다

중단 시 동작은 종료 · 중지 · 최대 절전(terminate · stop · hibernate) 중에서 고를 수 있고, 요청은 일회성(one-time)과 지속(persistent)이 있습니다. 지속 요청은 중단된 뒤 용량이 생기면 자동으로 다시 제출됩니다.

스팟이 답이 되는 신호는 명확합니다 — "중단되어도 된다", "내결함성이 있다", "언제 실행되든 상관없다", "배치 작업"입니다. 반대로 상태를 로컬에 유지하는 서버, 즉시 응답해야 하는 사용자 요청 처리, 중단이 곧 데이터 손실인 워크로드에는 쓰지 않습니다.

전용 호스트와 전용 인스턴스

테넌시(Tenancy) 값은 default · dedicated · host 세 가지입니다. 전용 인스턴스(dedicated)는 단일 테넌트 하드웨어에서 실행되지만 물리 서버 자체를 우리가 지정하지는 않습니다. 전용 호스트(host)는 물리 서버를 통째로 배정받아 소켓 · 코어 · VM 단위 라이선스를 가져와 쓸 수 있고 소켓과 코어 수를 볼 수 있습니다.

따라서 시험의 갈림길은 이렇습니다 — "기존 서버 바인딩 라이선스를 가져와야 한다"면 전용 호스트, "다른 고객과 하드웨어를 공유하지 않아야 한다"는 규정만 있으면 전용 인스턴스로 충분합니다.

핵심 판단 — 스팟인가 Savings Plans인가

도메인 4에서 가장 자주 나오는 판단입니다. 기준은 단 하나, 워크로드가 중단을 견디는가입니다.

워크로드 특성에 따른 구매 옵션 배정
워크로드 특성	배정	근거
24시간 상시 실행되는 기저 부하	Savings Plans (또는 예약 인스턴스)	어차피 계속 쓸 용량이므로 약정으로 단가를 낮추는 것이 순이익이다
중단되어도 되는 배치 · 분석 · 렌더링	스팟 인스턴스	중단 비용이 낮으므로 남는 용량을 쓰는 대가를 감당할 수 있다
예측 불가능한 단기 스파이크	온디맨드	약정 기간보다 짧게 쓰면 약정이 오히려 손해다
구성이 고정되고 용량 확보까지 필요	가용 영역 범위 예약 인스턴스	Savings Plans는 용량을 예약하지 않는다
서버 바인딩 라이선스 · 물리적 격리 규정	전용 호스트 · 전용 인스턴스	비용이 아니라 라이선스와 규정이 결정 기준이다

실무와 시험 모두에서 흔한 정답 형태는 혼합입니다. Auto Scaling 그룹의 기저 대수는 Savings Plans로 덮고, 그 위로 늘어나는 변동분은 스팟으로 채우는 구성입니다. 이때도 전제는 상태 비저장 설계입니다 — 스팟 인스턴스가 2분 뒤 사라져도 서비스가 계속되어야 하기 때문입니다.

MOST cost-effective 한정어가 붙은 컴퓨팅 문항의 판단 순서입니다.

중단을 견디는가 — 견딘다면 스팟이 거의 언제나 답입니다.
상시 부하인가 — 그렇다면 Savings Plans 또는 예약 인스턴스입니다.
구성이 고정되어 있고 용량 확보가 필요한가 — 그렇다면 가용 영역 범위 예약 인스턴스입니다.
그 밖의 단기 · 예측 불가 — 온디맨드입니다.

이 사이트는 할인율 수치를 쓰지 않습니다. 요금과 할인율은 리전과 시점에 따라 달라져서 확인된 값으로 고정할 수 없기 때문입니다. 시험도 금액 계산을 요구하지 않고 구조적으로 더 싼 안을 고르게 합니다. 비용 최적화 전반은 18장과 비용 빠른참조에서 이어집니다.

AMI와 사용자 데이터 — 무엇을 굽고 무엇을 실행할 것인가

Amazon Machine Image

AMI는 인스턴스를 시작할 때 쓰는 템플릿이며, 루트 볼륨의 스냅샷과 블록 디바이스 매핑, 시작 권한을 담습니다. EBS 기반 인스턴스에서 AMI를 만들면 연결된 EBS 볼륨의 스냅샷이 함께 생성되고, 그 AMI로 시작한 인스턴스는 같은 볼륨 구성을 그대로 갖습니다. AMI와 스냅샷의 관계는 6장에서 자세히 다룹니다.

AMI는 리전 단위 리소스입니다. 다른 리전에서 쓰려면 복사해야 하고, 복사 작업은 대상 리전에서 시작합니다. 재해 복구용으로 다른 리전에 골든 이미지를 미리 복사해 두는 구성이 여기서 나옵니다.

인스턴스 스토어 볼륨의 데이터는 AMI에 보존되지 않습니다. AMI로 시작한 새 인스턴스의 인스턴스 스토어는 비어 있습니다.

사용자 데이터 — 시작 시 실행되는 스크립트

사용자 데이터(user data)는 인스턴스를 시작할 때 전달하는 셸 스크립트 또는 cloud-init 지시문입니다. API로 넘길 때는 base64로 인코딩해야 하며, CLI와 SDK는 이 인코딩을 대신 해 주기도 합니다. 패키지 설치, 설정 파일 배치, 서비스 기동 같은 초기화를 여기서 처리합니다.

bootstrap.sh — 사용자 데이터로 전달할 초기화 스크립트 예시

#!/bin/bash
set -euo pipefail

# 애플리케이션 설정을 Parameter Store 에서 가져옵니다.
# 자격 증명은 인스턴스 프로파일(IAM 역할)로 해결하므로 키를 심지 않습니다.
APP_PORT=$(aws ssm get-parameter --name /app/web/port --query 'Parameter.Value' --output text)

systemctl enable --now web-app
echo "listen ${APP_PORT}" > /etc/web-app/listen.conf
systemctl restart web-app

사용자 데이터는 편하지만 기동 시간을 늘립니다. Auto Scaling 그룹이 새 인스턴스를 띄우는 상황에서는 이 시간이 곧 스케일아웃 지연이 됩니다. 그래서 실무 표준은 변하지 않는 부분은 AMI에 미리 굽고(golden AMI), 환경마다 달라지는 값만 사용자 데이터로 주입하는 것입니다.

배치 그룹 3종 — 성능과 장애 격리는 반대 방향

기본적으로 EC2는 인스턴스를 서로 다른 하드웨어에 흩어 놓으려 합니다. 배치 그룹은 그 배치에 개입해 더 가깝게 또는 더 멀리 두게 만드는 장치입니다. API의 배치 전략 값에는 cluster · partition · spread가 있습니다.

배치 그룹 3종의 장애 도메인 비교 — 클러스터는 한 가용 영역 안에 인스턴스를 밀집시키고, 파티션은 랙 단위로 나누며, 분산은 인스턴스마다 하드웨어를 완전히 분리합니다

배치 그룹 세 가지의 배치 방식과 제약
전략	배치 방식	주요 제약	언제 고르는가
클러스터 `cluster`	단일 가용 영역 안에 인스턴스를 밀집 배치한다. 같은 고대역폭 네트워크 구간에 놓인다	여러 가용 영역에 걸칠 수 없다. 같은 타입으로 한 번에 시작하지 않으면 용량 부족 오류가 나기 쉽다	노드 간 통신이 잦은 HPC, 낮은 지연과 높은 처리량이 목표일 때
파티션 `partition`	인스턴스를 논리 파티션으로 나누고, 파티션끼리는 랙을 공유하지 않게 배치한다	가용 영역당 파티션 최대 7개. 전용 인스턴스를 쓰면 파티션 2개까지	HDFS · HBase · Cassandra처럼 복제본을 랙 단위로 흩어야 하는 대규모 분산 시스템
분산 `spread`	인스턴스를 각각 다른 하드웨어에 배치한다	랙 수준 분산은 가용 영역당 실행 인스턴스 최대 7개. 전용 인스턴스는 지원하지 않는다	소수의 중요한 인스턴스를 서로 떨어뜨려야 할 때

파티션 배치 그룹과 분산 배치 그룹은 같은 리전의 여러 가용 영역에 걸칠 수 있지만, 클러스터 배치 그룹은 단일 가용 영역을 벗어나지 못합니다. 여기서 시험이 노리는 충돌이 생깁니다 — "가용 영역 간 지연을 최소화하라"와 "다중 가용 영역으로 고가용성을 확보하라"는 동시에 만족시킬 수 없습니다. 문제문이 어느 쪽을 우선하는지 읽어야 합니다.

그 밖의 공통 제약도 함께 봅니다. 인스턴스는 한 번에 하나의 배치 그룹에만 속하고, 배치 그룹을 병합할 수 없으며, 전용 호스트에는 배치 그룹을 쓸 수 없습니다. 배치 그룹 생성 자체에는 요금이 붙지 않습니다.

create-placement-group.sh — 파티션 배치 그룹 생성과 인스턴스 시작 (리소스 ID는 예시입니다)

aws ec2 create-placement-group \
  --group-name analytics-pg \
  --strategy partition \
  --partition-count 3

aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type r6i.2xlarge \
  --count 6 \
  --placement "GroupName=analytics-pg" \
  --subnet-id subnet-0123456789abcdef0

인스턴스 메타데이터와 IMDSv2 SAA 빈출

인스턴스 메타데이터 서비스(Instance Metadata Service, IMDS)는 인스턴스 안에서 링크 로컬 주소 169.254.169.254로 호출하는 로컬 엔드포인트입니다. 인스턴스 ID, AMI ID, 사용자 데이터, 그리고 연결된 IAM 역할의 임시 자격 증명을 여기서 얻습니다. SDK가 자격 증명을 자동으로 찾는 것도 이 경로 덕분입니다.

문제는 임시 자격 증명이 여기 있다는 사실 자체입니다. 애플리케이션에 서버 측 요청 위조(Server-Side Request Forgery, SSRF) 취약점이 있으면, 공격자가 애플리케이션에 169.254.169.254로 요청을 보내게 만들어 자격 증명을 훔칠 수 있습니다. IMDSv2는 이 공격 경로를 막기 위해 설계되었습니다.

IMDSv2의 두 단계 요청 — PUT으로 세션 토큰을 받고 그 토큰을 헤더에 실은 GET만 응답을 받습니다. 홉 제한과 결합하면 서버 측 요청 위조로는 토큰 발급 단계를 통과할 수 없습니다

두 단계 요청 구조

IMDSv2는 세션 지향 방식입니다. 먼저 PUT으로 세션 토큰을 발급받고, 이후 모든 GET 요청 헤더에 그 토큰을 실어야 응답을 받습니다. 토큰의 유효 시간은 최소 1초에서 최대 6시간(21,600초)이며, 토큰 사용이 required인 인스턴스에서 토큰 없이 호출하면 401 Unauthorized가 반환됩니다. 토큰은 발급된 인스턴스에서만 유효해서 다른 인스턴스로 가져가 쓸 수 없습니다.

imdsv2.sh — 토큰 발급 후 메타데이터 조회 (인스턴스 안에서 실행합니다)

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id

# 연결된 IAM 역할 이름 확인
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

여기에 홉 제한(HttpPutResponseHopLimit)이 더해집니다. PUT 응답의 기본 홉 제한은 1이고 1에서 64 사이로 조정합니다. 홉 제한이 1이면 응답이 인스턴스를 벗어나지 못하므로 역방향 프록시나 컨테이너 네트워크를 한 번 더 거치는 요청은 토큰을 받을 수 없습니다. 컨테이너에서 메타데이터를 써야 한다면 이 값을 올려야 하지만, 올리는 만큼 노출 범위도 넓어진다는 것을 함께 알아야 합니다. 또한 PUT 요청에 X-Forwarded-For 헤더가 있으면 거부됩니다 — 프록시를 경유한 요청을 걸러 내기 위한 장치입니다.

2024년 이후의 기본값 정책

예전에는 인스턴스가 IMDSv1과 IMDSv2를 둘 다 받아들이는 것이 일반적이었고, IMDSv2 강제는 인스턴스마다 따로 켜야 했습니다. 2024년 3월부터는 계정과 리전 수준에서 신규 인스턴스 시작의 기본값을 지정할 수 있습니다. ModifyInstanceMetadataDefaults로 HttpTokens를 required로 정해 두면 그 이후 시작되는 인스턴스는 별도 지정이 없는 한 IMDSv2 전용으로 뜹니다. 또한 AMI에 ImdsSupport가 v2.0으로 표시된 경우와 최근에 출시된 인스턴스 타입은 IMDSv2를 전제로 동작합니다.

따라서 "IMDSv1이 기본이다"라고 서술하는 자료는 현행이 아닙니다. 설계 질문에서는 계정 수준 기본값을 required로 두고, IMDSv1이 필요한 오래된 소프트웨어만 예외로 관리하는 것이 표준 답입니다.

인스턴스 메타데이터 옵션의 값과 기본값
옵션	값	기본값
`HttpTokens`	`optional`(IMDSv1도 허용) / `required`(IMDSv2 전용)	AMI의 `ImdsSupport`와 계정 수준 기본값의 조합으로 결정된다
`HttpEndpoint`	`enabled` / `disabled`	`enabled`
`HttpPutResponseHopLimit`	1 – 64	1
`HttpProtocolIpv6`	`enabled` / `disabled`	`disabled`
`InstanceMetadataTags`	`enabled` / `disabled`	`disabled`

enforce-imdsv2.sh — 계정 수준 기본값 설정과 기존 인스턴스 적용 (리소스 ID와 리전은 예시입니다)

# 이 리전에서 앞으로 시작되는 인스턴스의 기본값을 IMDSv2 전용으로 지정합니다.
aws ec2 modify-instance-metadata-defaults \
  --http-tokens required \
  --http-put-response-hop-limit 1 \
  --region ap-northeast-2

# 이미 실행 중인 인스턴스에 개별 적용합니다.
aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-endpoint enabled

메타데이터 관련 문항의 정답 패턴은 두 가지로 수렴합니다.

"EC2에서 AWS API를 호출해야 한다" → 액세스 키가 아니라 IAM 역할입니다. 액세스 키를 인스턴스에 심는 선택지는 거의 항상 오답입니다 (2장 IAM과 자격 증명).
"메타데이터를 통한 자격 증명 탈취를 막아야 한다" → IMDSv2를 required로 강제하고 홉 제한을 최소로 둡니다.

메타데이터 엔드포인트를 아예 끄는 것(HttpEndpoint=disabled)도 가능하지만, 그러면 인스턴스 프로파일로 자격 증명을 받을 수 없게 되므로 IAM 역할을 쓰는 워크로드에는 답이 되지 않습니다.

인스턴스 수명주기와 상태별 과금

인스턴스 상태와 인스턴스 사용 요금 과금 여부
상태	의미	인스턴스 사용 요금
`pending`	시작 준비 중. 시작 직후 또는 중지 상태에서 다시 시작할 때 거친다	과금 안 됨
`running`	실행 중이며 사용 가능	과금됨
`stopping`	중지 준비 중	과금 안 됨 (최대 절전으로 중지할 때는 이 구간도 과금됨)
`stopped`	종료되지 않았고 언제든 다시 시작할 수 있다	과금 안 됨
`shutting-down`	종료 준비 중	과금 안 됨
`terminated`	영구 삭제되어 다시 시작할 수 없다	과금 안 됨 (예약 인스턴스 약정은 기간까지 계속 청구됨)

표는 인스턴스 사용 요금만 다룹니다. 중지된 인스턴스라도 연결된 EBS 볼륨과 Elastic IP 요금은 계속 발생합니다. "인스턴스를 껐는데 왜 요금이 나오는가"의 답이 여기 있습니다.

중지와 시작이 바꾸는 것들

인스턴스가 다른 호스트로 옮겨질 수 있습니다. 그래서 인스턴스 스토어 볼륨의 데이터는 사라집니다 (6장).
프라이빗 IPv4 주소와 IPv6 주소는 유지됩니다. 프라이빗 주소에 연결된 Elastic IP도 그대로 남습니다.
중지 상태에서만 인스턴스 타입 같은 일부 속성을 변경할 수 있습니다.
재부팅은 새 과금 주기를 시작하지 않습니다. 재부팅 동안 인스턴스는 계속 running 상태이고, 인스턴스 스토어 데이터도 남습니다.
최대 절전(hibernate)은 메모리 내용을 EBS 루트 볼륨에 저장했다가 다시 불러옵니다. 그래서 루트 볼륨이 EBS인 인스턴스에서만 가능합니다.

운영체제 안에서 종료 명령을 실행했을 때의 동작은 InstanceInitiatedShutdownBehavior가 정하며 기본값은 stop입니다. 이 값을 terminate로 두면 인스턴스 안에서의 실수 한 번이 인스턴스 삭제로 이어집니다.

흔한 오해

시험 포인트 정리

5장 핵심 암기 항목과 함정
항목	사실	함정
인스턴스 타입 이름	패밀리 · 세대 · 부가 기능 · 크기 순. `d`는 인스턴스 스토어, `g`는 Graviton	개별 타입의 사양을 외우려다 시간을 씀
Savings Plans의 약정 대상	시간당 사용 금액을 1년 또는 3년	인스턴스 타입을 약정하는 것으로 오해
예약 인스턴스의 약정 대상	인스턴스 구성(타입 · 리전 등)을 1년 또는 3년	구성 변경 가능성이 있는데 표준 RI를 고름
RI 범위	리전 범위는 용량 예약 없음 + 가용 영역·크기 유연성, 가용 영역 범위는 용량 예약 있음 + 유연성 없음	용량 확보 요구에 리전 범위 RI나 Savings Plans를 고름
Compute와 EC2 Instance Savings Plans	Compute는 패밀리·리전·Fargate·Lambda까지 적용, EC2 Instance는 리전 안 특정 패밀리 한정	서버리스까지 덮어야 하는데 EC2 Instance 유형을 고름
스팟 중단 통지	회수 2분 전 통지. 그전에 재조정 권장 신호가 올 수 있다	중단을 감지할 방법이 없다고 판단
스팟의 적용 조건	중단을 견디는 내결함성 · 상태 비저장 워크로드	상태를 로컬에 두는 서버에 스팟을 배정
전용 호스트와 전용 인스턴스	테넌시 `host`는 서버 바인딩 라이선스 용도, `dedicated`는 단일 테넌트 하드웨어	라이선스 요구에 전용 인스턴스를 고름
AMI의 범위	리전 단위 리소스. 복사는 대상 리전에서 시작한다	다른 리전에서 AMI ID를 그대로 쓰려고 함
사용자 데이터	base64로 전달되며 메타데이터로 조회할 수 있다	비밀번호나 액세스 키를 사용자 데이터에 넣음
클러스터 배치 그룹	단일 가용 영역을 벗어날 수 없다	다중 가용 영역 고가용성 요구에 클러스터를 고름
파티션 배치 그룹	가용 영역당 파티션 최대 7개, 파티션끼리 랙을 공유하지 않는다	분산 배치 그룹과 목적을 혼동
분산 배치 그룹	랙 수준에서 가용 영역당 실행 인스턴스 최대 7개	대규모 클러스터를 분산 배치 그룹에 넣으려 함
IMDS 주소	`169.254.169.254` 링크 로컬 주소	보안 그룹으로 이 주소를 막을 수 있다고 생각
IMDSv2 요청 구조	`PUT`으로 토큰 발급 후 헤더에 토큰을 실은 `GET`. 토큰 유효 시간 최대 6시간	IMDSv2를 단순한 옵션 변경으로만 이해
홉 제한	기본 1, 범위 1–64. 낮을수록 프록시 경유 탈취가 어렵다	컨테이너에서 안 된다고 무작정 값을 크게 올림
IMDSv2 기본값 정책	계정·리전 수준에서 신규 시작 기본값을 `required`로 지정할 수 있다 (2024-03)	"IMDSv1이 기본"이라는 옛 서술을 그대로 적용
중지 시 남는 비용	인스턴스 사용 요금은 멈추지만 EBS 볼륨 요금은 계속	"껐으니 요금 0"으로 판단
중지 시 잃는 것	인스턴스 스토어 데이터. 재부팅은 잃지 않는다	중지와 재부팅을 같은 것으로 취급
확장 방향	타입 변경(수직)은 중지가 필요하고 상한이 있다. 탄력성은 수평 확장	"더 큰 인스턴스로 교체" 선택지를 고름

확인 문제

이 장의 핵심을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

이어서 볼 곳

공식 문서 출처

이 장의 설정값 · 기본값 · 동작은 모두 아래 문서에서 확인했습니다.

Amazon EC2 사용 설명서 — 인스턴스 타입 — 명명 규칙(패밀리 · 세대 · 부가 기능 · 크기), 패밀리 문자와 부가 기능 문자의 의미
Amazon EC2 사용 설명서 — 인스턴스 구매 옵션 — 온디맨드 · Savings Plans · 예약 인스턴스 · 스팟 · 전용 호스트 · 전용 인스턴스 · 용량 예약의 구분과 1년 또는 3년 약정
Amazon EC2 사용 설명서 — 리전 및 영역 예약 인스턴스(범위) — 리전 범위는 용량을 예약하지 않고 가용 영역·크기 유연성이 있으며, 가용 영역 범위는 용량을 예약한다는 비교표
Amazon EC2 API 레퍼런스 — DescribeReservedInstancesOfferings — 예약 인스턴스가 온디맨드보다 낮은 사용 요율을 적용받는다는 서술, 범위·제공 클래스·결제 방식의 값
AWS Savings Plans 사용 설명서 — Compute와 EC2 Instance 유형의 구분, 결제 방식 세 가지
Amazon EC2 사용 설명서 — 스팟 인스턴스 — 2분 전 중단 통지, 재조정 권장, 일회성과 지속 요청, 중단 시 동작 세 가지
Amazon EC2 사용 설명서 — 전용 호스트 — 물리 호스트 배정과 서버 바인딩 라이선스 사용
Amazon EC2 사용 설명서 — Amazon Machine Image — AMI의 구성 요소와 리전 단위 성격
Amazon EC2 API 레퍼런스 — CopyImage — 복사 작업을 대상 리전에서 시작해야 한다는 서술
Amazon EC2 사용 설명서 — 시작 시 명령 실행(사용자 데이터) — 셸 스크립트와 cloud-init 지시문, base64 전달
Amazon EC2 사용 설명서 — 배치 그룹 — 세 가지 전략의 정의, 클러스터가 단일 가용 영역을 벗어날 수 없다는 점, 파티션 최대 7개와 분산 최대 7개 제한, 전용 호스트 사용 불가
Amazon EC2 API 레퍼런스 — CreatePlacementGroup — 배치 전략 값과 파티션 수 지정
Amazon EC2 사용 설명서 — IMDSv2 사용 — 세션 토큰 발급과 사용, 토큰 유효 시간 최대 6시간, 토큰 없는 요청의 401 응답, 홉 제한 기본값 1
Amazon EC2 API 레퍼런스 — ModifyInstanceMetadataDefaults — 계정과 리전 수준에서 인스턴스 메타데이터 기본값을 지정하는 방법
Amazon EC2 API 레퍼런스 — ModifyInstanceMetadataOptions — HttpTokens · HttpEndpoint · HttpPutResponseHopLimit · InstanceMetadataTags의 값과 기본값
Amazon EC2 사용 설명서 — 인스턴스 수명주기 — 상태별 과금 여부, 중지·시작 시 호스트 이동과 인스턴스 스토어 데이터 손실, 재부팅이 새 과금 주기를 시작하지 않는다는 점
Amazon EC2 API 레퍼런스 — RunInstances — 사용자 데이터의 base64 요구, InstanceInitiatedShutdownBehavior 기본값 stop