EC2 핵심 정리 — 인스턴스·EBS·EFS 한 번에

2026-05-01•AWS SAA-C03 스터디

AWS SAA-C03 스터디 노트 두 번째 글. EC2가 왜 가상 서버 임대 서비스인지부터 호텔 비유로 풀고, 인스턴스 타입(T·M·C·R·I·G) 패밀리를 직업별로 비교하고, 구매 옵션 7종(On-Demand·예약·Savings·스팟·전용 호스트·전용 인스턴스·용량 예약)을 호텔 객실 결제 비유로 한 번에 정리합니다. EBS gp2/gp3/io1/io2/st1/sc1 차이, EBS vs EFS vs Instance Store, 배치 그룹 3종(Cluster·Spread·Partition), ENI·Hibernate까지 — 처음 보는 사람이 옵션의 양에 질리지 않게 친절하게 풀어쓴 13편 시리즈의 두 번째.

이 글은 AWS Certified Solutions Architect Associate(SAA-C03) 스터디 노트 시리즈의 두 번째 편입니다. 1편 IAM이 "누가 무엇을 할 수 있는가"의 뼈대였다면, 2편은 그 권한 위에서 실제로 일을 하는 컴퓨팅의 본체 — EC2와 스토리지예요.

처음 EC2 단원을 펼치면 솔직히 좀 질립니다. 인스턴스 타입만 다섯 패밀리고, 구매 옵션이 일곱 개고, EBS 볼륨 타입도 여섯 종류예요. 거기에 EFS·Instance Store·배치 그룹·ENI·Hibernate까지 줄줄이 따라오면 "이거 다 외워야 해?" 싶어지죠. 그런데 한 번 흐름만 잡고 나면 의외로 쉬워요. 각 옵션이 왜 존재하는지, 어떤 문제를 풀려고 만들었는지 만 이해하면 시험 문제는 거의 다 키워드 매칭 게임으로 풀립니다.

이 글에서는 EC2를 호텔 비유로 한 번 풀고, 옵션 하나하나가 호텔에서 어떤 결제 방식·어떤 객실 종류·어떤 부대시설에 대응되는지 머릿속에 그림을 그려 갑니다. 다 외우려 하지 말고, "왜 이게 따로 있어야 했을까" 라는 시선으로 읽어 보세요.

EC2가 도대체 뭐길래 시험에 이렇게 많이 나올까요

한 줄 정의 + IaaS 분류

Amazon EC2(Elastic Compute Cloud) 를 풀어 쓰면 — "탄력적인 컴퓨팅 클라우드"입니다. 말 그대로 AWS의 데이터센터 안에 있는 가상 서버를 빌려서 쓰는 서비스예요. 회사로 치면 — 사무실 공간이 더 필요할 때 직접 건물을 짓는 대신 공유 오피스를 시간 단위로 빌리는 것이랑 비슷합니다. 필요할 때만 빌리고, 안 쓰면 반납하면 그만이에요.

클라우드 분류상으로는 IaaS(Infrastructure as a Service) 에 들어갑니다. 시험에서 "EC2의 클라우드 모델은?" 이 나오면 답은 IaaS예요. SaaS(완성된 앱), PaaS(앱 실행 환경), IaaS(인프라 자체) 중 가장 밑단을 빌려 쓰는 거라고 생각하시면 됩니다.

항상 같이 쓰는 네 친구

여기서 짚어둘 게 — EC2는 절대 혼자 쓰지 않아요. 거의 항상 다음 네 친구들과 묶입니다.

서비스	역할	비유
EC2 인스턴스	대여한 가상 머신 본체	빌린 사무실
EBS (Elastic Block Store)	네트워크로 연결되는 가상 스토리지	사무실에 들이는 캐비닛
ELB (Elastic Load Balancer)	여러 EC2에 트래픽 분산	여러 사무실에 손님 나눠 보내는 안내 데스크
ASG (Auto Scaling Group)	트래픽 따라 인스턴스 수 자동 조절	손님 늘면 사무실 더 빌려주는 매니저

ELB·ASG는 3편에서 따로 풀 거고, 이번 글은 EC2 본체 + EBS·EFS·Instance Score 같은 스토리지에 집중합니다.

User Data — 시험 함정 1순위

EC2를 만들 때 고르는 옵션이 처음에는 좀 많아 보여요 — OS(Linux/Windows/macOS), CPU 코어 수, RAM, 스토리지 종류, 네트워크 카드 속도, 보안 그룹(방화벽), 부트스트랩 스크립트(User Data)까지. 옵션마다 자세한 제약·기본값이 궁금하면 EC2 사용자 가이드 공식 문서 를 곁에 두고 보면 좋아요. 이 중에 시험에 자주 나오는 게 User Data입니다.

> User Data 한 줄 요약 — 인스턴스가 처음 부팅될 때 단 한 번만 실행되는 스크립트. 루트 권한으로 돌아가요. OS 업데이트, 웹 서버 설치, 파일 다운로드 같은 초기 설정 자동화에 씁니다.

여기서 시험 함정 하나 — 재부팅(Reboot) 시에는 User Data가 다시 실행되지 않습니다. "처음 시작 시 단 한 번"이 핵심 키워드예요. 그래서 매번 부팅할 때마다 돌려야 할 작업은 User Data가 아니라 systemd 서비스로 등록해야 합니다. 시험에 "재부팅 후에도 스크립트가 다시 실행되도록 하려면?" 같은 보기는 무조건 함정.

인스턴스 타입 — `m5.2xlarge`가 왜 그렇게 적혀 있는지

이름 세 부분 분해 — 클래스·세대·크기

EC2 인스턴스 타입을 처음 보면 — t2.micro, m5.2xlarge, c6i.large, r5.4xlarge 같이 외계어처럼 적혀 있죠. 그런데 이게 실은 세 부분으로 짜인 일관된 규칙이에요. 한 번 풀어보면 그 다음부턴 어떤 인스턴스 이름을 봐도 즉시 의미가 읽힙니다.

m5.2xlarge를 예로 들면:

m — 클래스(패밀리). 어떤 종류의 작업에 최적화됐는지. 회사로 치면 직원의 직군 같은 거예요.
5 — 세대(Generation). 숫자가 클수록 최신 세대. 같은 m이라도 m5보다 m6가 더 좋은 CPU·네트워크 카드를 씁니다.
2xlarge — 크기(Size). 클수록 CPU·메모리·네트워크가 다 비례해서 커집니다. large → xlarge → 2xlarge → 4xlarge 순으로 두 배씩 뛰어요.

패밀리 5종 + 첫 글자 암기 팁

패밀리는 다섯 가지로 갈립니다. 외울 필요는 없고, "어떤 작업이면 어떤 패밀리가 어울리겠다" 만 감이 잡히면 충분해요.

유형	특징	사용 사례	대표 패밀리
범용 (General Purpose)	CPU·메모리·네트워크의 균형	웹 서버, 코드 저장소, 개발/테스트	T, M (예: t2.micro)
컴퓨팅 최적화 (Compute Optimized)	고성능 프로세서(CPU) 위주	배치 처리, 미디어 트랜스코딩, HPC, ML, 게임 서버	C (예: C5, C6)
메모리 최적화 (Memory Optimized)	RAM 대용량 데이터 처리	인메모리 DB, ElastiCache, BI, 실시간 빅데이터	R (RAM의 R), X, Z
스토리지 최적화 (Storage Optimized)	로컬 디스크 고속 I/O	고빈도 OLTP, NoSQL, 데이터 웨어하우스	I, D, H
가속 컴퓨팅 (Accelerated Computing)	GPU/FPGA 가속	ML 추론, 그래픽 처리, 게임 렌더링	P, G, Inf

암기 팁이 있어요. 이름의 첫 글자가 힌트예요 — Compute는 C, RAM은 R, I/O는 I, GPU는 G. M은 mid(중간)·main(본체)이라고 외우면 범용이 떠오릅니다. 시험에 "인메모리 데이터베이스 운영 시 적합한 인스턴스 패밀리는?" 같은 게 나오면 R, "GPU 추론은?" 하면 P/G 하는 식으로 키워드 매칭만 하면 돼요.

> 프리티어(무료) 기본 — t2.micro (또는 리전에 따라 t3.micro). 처음 AWS 가입하면 이 인스턴스로 12개월 동안 매월 750시간을 무료로 쓸 수 있어요. 학습용이면 이걸로 충분.

다음 단원에서는 인스턴스를 빌리는 결제 방식 — 즉 구매 옵션 으로 넘어가요. 이 부분이 시험에 정말 자주 나오는데, 호텔 비유로 풀면 한 번에 정리됩니다.

구매 옵션 7종 — 호텔 객실 결제 방식이라고 생각하면 됩니다

EC2 구매 옵션이 일곱 가지나 되는 게 처음엔 좀 부담스러워요. 그런데 본질은 "얼마나 약속하고 빌릴 거냐, 그래서 얼마 할인받을 거냐" 의 변형이라 호텔 객실 결제로 비유하면 한눈에 들어옵니다.

옵션	호텔 비유
On-Demand (온디맨드)	그날그날 정가로 숙박
Reserved Instances (예약)	1~3년 장기 렌트 약정
Savings Plans	"월 X만 원어치 묵을게요" 고정 약정
Spot Instances	빈 방을 헐값에, 단 자리 비워달라 하면 즉시 나감
Dedicated Hosts	호텔 한 동(東)을 통째로 빌림
Dedicated Instances	다른 손님과 객실을 나누지 않음(층 단독 사용)
Capacity Reservations	객실 예약(투숙 안 해도 객실비는 지불)

이제 하나씩 풀어 갑니다.

온디맨드(On-Demand) — 가장 비싸지만 가장 자유로운 기본값

약정도 선불도 없이 사용한 만큼만 청구되는 가장 기본 옵션입니다. Linux와 Windows는 초당 청구로 잘게 끊어 받아요. 가장 유연하지만 단가가 가장 비쌉니다.

언제 쓰느냐 — 단기 작업, 예측 불가능한 트래픽, 중단되면 안 되는 개발/테스트 같이 약정을 걸 만큼 패턴이 안정되지 않은 워크로드. 시험에서 "예측이 어려운 단기 작업"이면 거의 항상 답이 온디맨드예요.

예약 인스턴스(Reserved Instances, RI) — 1~3년 장기 약정으로 최대 72% 할인

특정 인스턴스 타입·리전·OS를 정해서 1년 또는 3년 장기 약정을 거는 옵션입니다. 약속하는 대신 온디맨드 대비 최대 72% 할인을 받아요. 회사로 치면 사무실 1년 장기 임대 계약하면서 월세 깎는 거랑 같아요.

여기에 변형이 하나 더 있어요 — Convertible RI(컨버터블 예약 인스턴스). 약정 기간 중에 인스턴스 타입이나 OS를 바꿀 수 있는 유연성을 더한 대신 할인율은 최대 66% 로 살짝 낮아집니다. "지금은 m5인데 1년 뒤엔 r5로 바꿔야 할 수도 있어" 라는 사람한테 어울려요.

언제 쓰느냐 — 꾸준히 돌아가는 데이터베이스, 24/365 가동되는 백엔드 서버 처럼 1년 이상 죽지 않고 돌 게 확실한 워크로드. 시험 키워드는 "Steady-state(안정적인)", "장기 실행 DB", "예측 가능한".

Savings Plans — RI보다 유연한 약정

이게 처음에 RI랑 헷갈리는데, 차이가 명확해요.

RI: "특정 인스턴스 타입·리전·OS"를 약속
Savings Plans: 인스턴스를 안 정하고 "1년 또는 3년 동안 시간당 X달러어치 사용할게" 라는 금액만 약속

이 차이가 결정적입니다. Savings Plans은 인스턴스 크기·OS·테넌시를 자유롭게 바꿀 수 있어요. 약정한 금액 안에서는 m5에서 c5로 바꿔도, Linux에서 Windows로 바꿔도 할인이 그대로 적용됩니다. 약정 금액을 초과한 부분은 온디맨드 요금으로 청구되고요. 할인율은 최대 70%.

시험에 "유연성을 유지하면서 장기 할인을 받고 싶다" 가 나오면 답이 Savings Plans 또는 Convertible RI 둘 중 하나예요.

스팟 인스턴스(Spot) — 최대 90% 할인, 단 언제든 쫓겨납니다

스팟이 시험에 정말 자주 나오는데, 개념을 한 줄로 풀면 — AWS의 남는 컴퓨팅 용량을 경매식으로 헐값에 빌려쓰는 것입니다. 최대 90% 할인이라 진짜 매력적인데, 함정이 하나 있어요.

> AWS는 자기 가격이 사용자가 설정한 최대 가격을 넘으면, 그 인스턴스를 언제든 회수합니다. 회수 전에 2분의 유예 시간만 줘요. 그 안에 작업을 정리하고 종료해야 합니다.

쉽게 말해 — 호텔 비유로 비유한다면 "비어있는 객실 헐값에 들어왔지만, 정가 손님이 오면 즉시 방을 비워줘야 하는 상황"이에요. 그래서 중간에 끊겨도 괜찮은 작업 에만 써야 합니다.

언제 쓰느냐 — 배치 처리, 데이터 분석, 머신러닝 학습, 영상 트랜스코딩, CI/CD 처럼 끊겨도 다시 돌리면 되는 작업. 시험 키워드는 "장애 내성(Fault-tolerant)", "유연한 일정", "배치", "분석".

스팟 요청에는 두 종류가 있어요.

유형	특징
One-time(일회성)	인스턴스 시작 후 요청 소멸. 회수돼도 그걸로 끝
Persistent(영구적)	회수돼도 조건 충족 시 자동으로 새 스팟 인스턴스 시작

여기서 시험 단골 함정 — Persistent 스팟을 종료시킬 때 순서가 중요해요. 반드시 "스팟 요청을 먼저 Cancel → 그다음 인스턴스 Terminate" 순서로 해야 합니다. 인스턴스만 종료하면 Persistent 요청이 살아 있어서 자동으로 새 인스턴스가 또 뜹니다. 시험에 자주 나와요.

스팟을 여러 개 한 번에 다루는 게 Spot Fleet(스팟 플릿) 인데, 할당 전략이 네 가지 있습니다.

전략	설명	어울리는 작업
Lowest Price	가장 저렴한 풀에서 시작	비용 최우선, 짧은 작업
Diversified	모든 풀에 분산	가용성 최우선, 긴 작업
Capacity Optimized	여유 용량 가장 많은 풀	중단 최소화
Price Capacity Optimized	용량 많고 가격 저렴한 풀	AWS 권장 디폴트

가장 무난한 답은 거의 항상 Price Capacity Optimized입니다. AWS 자체가 "특별한 사정 없으면 이걸 써라" 라고 권장해요.

전용 호스트(Dedicated Hosts) — 물리 서버 한 대 통째로

물리적 서버 자체를 예약해서 그 위에서만 인스턴스를 띄우는 옵션입니다. 같은 물리 서버에 다른 고객 인스턴스가 절대 안 올라와요. 게다가 소켓 수, 코어 수 같은 하드웨어 레벨 정보가 보입니다.

이게 왜 필요하냐면 — 소켓·코어 단위로 라이선스가 묶인 소프트웨어(예: 일부 오라클 라이선스, 일부 Windows Server 라이선스)를 자기 라이선스로 가져와 쓸 때(BYOL, Bring Your Own License) 필수예요. 또 금융권처럼 규정 준수(Compliance) 가 매우 엄격해서 "물리적 격리 증명이 필요한" 경우에도 씁니다.

시험 키워드 — BYOL, 소켓/코어 라이선스, 강력한 컴플라이언스 → Dedicated Hosts. 가장 비싼 옵션이에요.

전용 인스턴스(Dedicated Instances) — 다른 고객과는 안 섞이지만 내 계정 안끼리는 섞임

Dedicated Hosts와 헷갈리기 쉬운 게 이건데, 차이가 명확해요.

Dedicated Hosts: 물리 서버 자체를 빌림 + 하드웨어 정보 보임 + 같은 호스트에 어떤 인스턴스가 올라갈지 제어 가능
Dedicated Instances: 다른 AWS 고객과는 하드웨어를 안 나눠 씀. 단, 내 계정 안의 다른 인스턴스와는 같은 하드웨어를 쓸 수 있음. 하드웨어 제어권 없음

쉽게 말해 — Dedicated Hosts는 호텔 한 동을 통째로 빌리는 거고, Dedicated Instances는 "한 층은 우리 회사 사람들끼리만 써요" 정도예요.

용량 예약(Capacity Reservations) — 객실 예약, 투숙은 별도

이게 처음에 좀 헷갈리는 옵션인데, 한 줄로 풀면 — 특정 가용 영역(AZ)에 인스턴스 용량을 미리 잡아두는 것입니다. 인스턴스를 실제로 켜든 안 켜든 온디맨드 요금이 그대로 청구돼요. 할인은 없습니다.

언제 쓰냐 — 재해 복구나 블랙프라이데이 같은 단기 트래픽 폭주 처럼, 그 시점에 반드시 그 AZ에 용량이 있어야 하는 상황. AWS도 가끔 특정 리전 특정 AZ가 인스턴스 부족(Insufficient Capacity)을 겪을 때가 있는데, 미리 예약해 두면 그날 보장돼요.

일곱 옵션 한 표로 정리

구매 옵션	약정	할인율	중단 가능성	키워드
On-Demand	없음	0%	없음	단기, 예측 불가, 개발/테스트
Reserved (Standard)	1년/3년	최대 72%	없음	Steady-state, DB, 장기
Reserved (Convertible)	1년/3년	최대 66%	없음	유연한 타입 변경
Savings Plans	1년/3년	최대 70%	없음	유연성 + 할인
Spot	없음	최대 90%	있음	배치, 분석, 장애 내성
Dedicated Hosts	없음/1년/3년	-	없음	BYOL, 컴플라이언스
Dedicated Instances	없음	-	없음	다른 고객과 격리
Capacity Reservations	없음	0%	없음	특정 AZ에 용량 보장

시험에서 구매 옵션 문제가 나오면 — 약정 가능 여부, 중단 허용 여부, 라이선스/컴플라이언스 요구 세 축으로 보기를 거르면 거의 다 풀립니다.

AMI — 미리 만들어둔 EC2 템플릿

EC2 인스턴스를 새로 띄울 때 OS만 깔린 빈 깡통에서 시작하면 매번 같은 셋업을 반복해야 해요. 그래서 등장하는 게 AMI(Amazon Machine Image) 입니다. 이름 그대로 "머신 이미지" — OS·소프트웨어·설정이 전부 패키징된 인스턴스 시작용 템플릿이에요. 회사로 치면 — 신입사원 PC 셋업 표준 이미지를 한 번 만들어두고 새 직원 올 때마다 그걸로 클론 뜨는 것과 같습니다.

AMI를 쓰는 가장 큰 이유는 부팅 시간 단축입니다. User Data로 일일이 깔면 부팅이 5~10분 걸리지만, 미리 다 깔린 AMI로 띄우면 1분 안에 떠요.

AMI는 세 종류로 갈려요.

종류	설명
Public AMI	AWS가 공식 제공 (Amazon Linux 2, Ubuntu 등)
Custom AMI(사용자 지정)	사용자가 직접 만든 이미지 — 일명 Golden AMI
AWS Marketplace AMI	외부 벤더가 최적화해서 판매하는 이미지

여기서 시험에 자주 나오는 함정 — AMI는 리전(Region)에 종속됩니다. 서울에서 만든 AMI는 도쿄 리전에서 안 보여요. 다른 리전에서 쓰려면 AMI 복사(Copy) 를 해야 합니다. 단, 같은 리전 안의 다른 AZ에서는 그대로 쓸 수 있어요.

AMI를 만드는 표준 흐름은 네 단계입니다.

EC2 인스턴스 시작해서 필요한 소프트웨어 설치·설정 완료
인스턴스 중지(Stop) — 데이터 무결성을 보장하기 위해 권장
AMI 구축(Create Image) — 백그라운드에서 EBS 스냅샷이 자동 생성됨
그 AMI로 새 인스턴스 시작

> Golden AMI 패턴 — 회사에서 자주 쓰는 표준 패턴. 소프트웨어가 미리 다 설치된 커스텀 AMI를 만들어두면, Auto Scaling이 새 인스턴스를 띄울 때 부팅이 훨씬 빨라요. 트래픽 폭증 시 빠르게 대응하려면 거의 필수입니다.

자주 패치된 최신 AMI를 자동으로 굴리고 싶다면 EC2 Image Builder를 쓰면 됩니다. 빌드 파이프라인을 자동화해서 주기적으로 패치된 AMI를 새로 만들어 줘요. Image Builder 자체는 무료고, 빌드 중 띄워지는 EC2/스토리지 비용만 청구됩니다.

보안 그룹 — EC2 외부에 붙는 가상 방화벽

EC2 인스턴스에 트래픽이 들어오기 전, 방화벽 역할을 하는 게 보안 그룹(Security Group) 입니다. 회사로 치면 — 사옥 입구의 보안 게이트랑 비슷해요. 들어오는 사람·나가는 사람을 일일이 검문합니다.

핵심 특징을 한 번에 짚으면:

허용(Allow) 규칙만 존재합니다. 거부(Deny) 규칙은 못 걸어요. 명시적으로 허용한 트래픽만 통과하고, 나머지는 자동으로 차단됩니다.
인바운드 기본값은 모두 차단, 아웃바운드 기본값은 모두 허용(0.0.0.0/0).
N:M 관계 — 한 인스턴스에 여러 보안 그룹을 동시에 붙일 수 있고, 한 보안 그룹을 여러 인스턴스에 재사용할 수도 있어요.
리전·VPC 종속 — 다른 리전이나 VPC에서는 새로 만들어야 합니다.
다른 보안 그룹을 소스로 참조 가능 — IP 대역 대신 "이 보안 그룹에 속한 인스턴스는 통과" 식으로 규칙을 짤 수 있어요. IP 변경 신경 안 써도 돼서 편합니다.
EC2 인스턴스 외부에서 작동 — 차단된 트래픽은 인스턴스 안의 OS가 인식조차 못 합니다.

여기서 자주 나오는 시험 함정 — 트러블슈팅 오류 메시지 구분.

오류 메시지	원인
타임아웃(Timeout)	보안 그룹 문제 — 방화벽이 패킷을 막아서 응답이 안 옴
연결 거부(Connection Refused)	애플리케이션 문제 — 서버까지 패킷은 갔는데 그 포트에서 도는 프로그램이 없거나 죽음

이 둘 구분이 시험에 자주 나옵니다. 타임아웃 = 방화벽, 거부 = 앱 — 한 줄로 외워두세요.

자주 외워야 할 포트 번호도 정리합니다.

포트	프로토콜	용도
22	SSH / SFTP	Linux 원격 접속 / 보안 파일 전송
21	FTP	일반 파일 전송
80	HTTP	평문 웹 트래픽
443	HTTPS	암호화 웹 트래픽
3389	RDP	Windows 원격 데스크톱

마지막으로 시험에 잘 나오는 함정 두 개:

기본(Default) 보안 그룹은 삭제 못 합니다.
사용 중인 보안 그룹은 삭제 못 합니다 — 인스턴스를 완전히 종료한 뒤에야 삭제 가능.

Key Pairs와 EC2 접속 — 그리고 IAM 역할은 왜 따로 있나

EC2에 접속하려면 키 페어(Key Pair) 가 필요합니다. SSH 인증을 비밀번호 대신 공개키-개인키 방식으로 하기 위한 자격 증명이에요.

형식	사용 환경
`.pem`	Mac, Linux, Windows 10 이상
`.ppk`	구버전 Windows(7, 8)에서 PuTTY 사용 시

기본 사용자 이름은 OS마다 달라요 — Amazon Linux 2는 ec2-user, Ubuntu는 ubuntu. 그리고 .pem 파일은 반드시 권한을 chmod 0400 으로 잠가야 합니다. 안 그러면 SSH가 "권한이 너무 열려 있어 위험" 이라며 거부해요.

접속 방법은 세 가지가 있습니다.

방법	특징
SSH(터미널)	Mac/Linux/Win10+에서 기본 `ssh` 명령
PuTTY	Windows 환경에서 `.ppk` 키 파일 사용
EC2 Instance Connect	브라우저 기반 SSH, 임시 키 자동 발급, 키 파일 관리 불필요 (포트 22 필요)

여기서 시험 단골 포인트 — EC2 안의 애플리케이션이 다른 AWS 서비스(예: S3)에 접근해야 한다면? 정답은 IAM 역할(Role) + Instance Profile 이지, 액세스 키를 코드에 박아두는 것이 절대 아닙니다. 1편에서도 강조했던 부분인데, 여기서 한 번 더 짚고 갑니다.

> 여기서 시험 함정 하나 — IAM 역할의 정책을 변경하면 인스턴스를 재시작하지 않아도 즉시 반영됩니다. 새 정책 적용 위해 EC2 재시작이 필요하다는 보기는 무조건 오답.

퍼블릭 IP·프라이빗 IP·Elastic IP — 셋의 차이

EC2 인스턴스가 가지는 IP는 두 종류가 기본이에요 — 퍼블릭 IP와 프라이빗 IP.

구분	Public IP	Private IP
접근성	인터넷 어디서든 접근 가능	VPC 안에서만 접근 가능
고유성	전체 인터넷에서 고유	해당 VPC 안에서만 고유
Stop/Start 시	변경됨(새 IP 할당)	유지됨

여기서 시험에 자주 나오는 함정 — 인스턴스를 Stop했다가 Start하면 퍼블릭 IP가 바뀝니다. 단, Reboot은 IP가 그대로 유지돼요. Stop/Start와 Reboot은 다릅니다.

매번 IP가 바뀌면 서비스 운영이 곤란하죠. 그래서 등장하는 게 Elastic IP(EIP) 입니다.

> Elastic IP — 삭제 전까지 내가 영구 소유하는 고정 퍼블릭 IPv4 주소. 한 인스턴스에 붙였다가 떼서 다른 인스턴스로 옮길 수 있어서, 장애 발생 시 재연결(Remapping)으로 IP를 살리며 페일오버 가능.

특징을 정리하면 — 계정당 기본 5개까지(요청 시 증가 가능), 사용 여부와 무관하게 시간당 요금 발생(붙은 인스턴스가 없으면 더 비쌈), 안 쓸 거면 릴리스(Release) 하는 게 원칙.

근데 AWS 모범 사례는 좀 의외예요. "가급적 Elastic IP를 쓰지 마라" 입니다. 대신 Route 53(DNS) 또는 Load Balancer 를 쓰라고 권장해요. 시험에서 "고가용성 환경에서 IP 노출 없이 트래픽 라우팅" 같은 게 나오면 답은 거의 항상 ELB 또는 Route 53입니다.

Placement Groups — 인스턴스를 어떻게 물리적으로 배치할 것인가

여기서 좀 새로운 개념이 나옵니다. Placement Group(배치 그룹) 은 EC2 인스턴스를 데이터센터 안의 물리적 하드웨어에 어떻게 배치할지 결정하는 기능이에요. 회사로 치면 — 직원들 자리를 한 회의실에 몰아서 앉힐지, 다른 층에 흩어 둘지 정하는 거랑 비슷합니다.

세 가지 모드가 있고, 각자 푸는 문제가 달라요.

유형	특징	제한	사용 사례
Cluster (클러스터)	단일 AZ 안에서 인스턴스를 물리적으로 가깝게 모아 배치. 10Gbps 대역폭, 최저 지연	AZ 장애 시 전체가 같이 죽음	HPC, 빅데이터, 노드 간 통신이 빈번한 작업
Spread (스프레드)	인스턴스들을 서로 다른 물리 하드웨어(랙)에 분산. 동시 장애 위험 최소화	AZ당 최대 7개 인스턴스	중요(Critical) 앱, 엄격한 격리 필요
Partition (파티션)	논리적 파티션으로 나눠 각 파티션이 다른 랙 차지	AZ당 최대 7개 파티션, 수백 개 인스턴스 가능	Hadoop, Cassandra, Kafka 같은 대규모 분산 시스템

이 셋이 처음에는 다 비슷해 보이는데, 푸는 문제가 정반대예요.

Cluster는 "모아서 빠르게" — 노드끼리 통신이 잦으니까 물리적으로 가까울수록 좋다
Spread는 "흩어서 안전하게" — 한 랙이 죽어도 나머지는 살아남아야 한다
Partition은 "그룹으로 나눠 큰 분산 시스템 운용" — Cassandra 클러스터가 100노드인데, 같은 랙끼리 묶어두면 한 랙 사고에 그 그룹만 영향

시험 키워드 매칭으로 정리하면 — 짧은 지연시간 → Cluster, 엄격한 격리/AZ당 7개 제한 → Spread, Kafka·Cassandra·Hadoop·수백 개 노드 → Partition. 이 셋만 외워도 거의 다 풀립니다.

ENI — 가상 네트워크 카드

ENI(Elastic Network Interface) 는 EC2의 가상 네트워크 카드예요. 회사로 치면 — 사무실에 꽂는 LAN 카드 같은 건데, AWS에선 이걸 떼서 다른 PC에 옮길 수 있다는 게 결정적인 차이입니다.

ENI 한 장이 가지는 속성:

1개의 기본 프라이빗 IPv4 주소
1개 이상의 보조 프라이빗 IPv4 주소
프라이빗 IPv4마다 1개의 Elastic IP 또는 Public IPv4
1개 이상의 보안 그룹
고유한 MAC 주소

이게 왜 중요하냐면 — ENI를 떼서 다른 인스턴스에 붙이면 프라이빗 IP와 MAC 주소가 그대로 따라갑니다. 이걸 페일오버에 쓰는 게 시험 단골이에요. 한 인스턴스가 죽으면 ENI를 떼서 다른 인스턴스에 붙이면 — 외부에서 보면 IP·MAC 그대로니까 트래픽이 끊김 없이 넘어갑니다.

다만 함정 하나 — ENI는 특정 AZ에 묶여 있어요. 다른 AZ의 인스턴스에는 붙일 수 없습니다.

수명 주기도 알아두면 좋아요.

기본 ENI(인스턴스 만들 때 자동으로 생기는 것): 인스턴스 종료 시 함께 삭제
수동으로 만든 보조 ENI: 인스턴스 종료 후에도 유지(Available 상태)

> 시험 키워드 — "프라이빗 IP를 유지하면서 페일오버", "MAC 주소 고정" → ENI 이동(Attach/Detach).

Hibernate — 메모리 상태를 그대로 EBS에 저장하고 자기

Hibernate(최대 절전 모드) 가 처음에 좀 신기한 기능인데, 한 줄로 풀면 — 인스턴스를 중지할 때 RAM 안 데이터를 통째로 EBS에 저장해두고, 다시 켜면 RAM을 그 상태 그대로 복구하는 모드예요.

이게 왜 유용하냐면 — 일반 Stop은 RAM이 다 날아가요. 그래서 다시 시작할 때 OS 부팅, 캐시 로드, 애플리케이션 초기화를 처음부터 다시 해야 합니다. Hibernate는 그 단계를 통째로 건너뛰니까 부팅이 매우 빠르고, OS 입장에서는 재부팅된 적이 없는 것처럼 인식돼요(uptime 명령이 초기화되지 않음).

그런데 조건이 좀 까다롭습니다.

조건	내용
루트 볼륨 타입	반드시 EBS (인스턴스 스토어 불가)
루트 볼륨 암호화	반드시 암호화(Encrypted)
루트 볼륨 크기	RAM 데이터 다 담을 만큼 여유 공간 충분
RAM 크기	150GB 미만
베어 메탈 인스턴스	지원 안 함
최대 동면 기간	60일 이하
활성화 시점	인스턴스 최초 생성 시에만 가능

특히 마지막이 시험 함정이에요 — Hibernate는 나중에 활성화할 수 없습니다. 인스턴스를 만들 때 반드시 같이 켜둬야 해요. "이미 도는 인스턴스에 Hibernate를 켜려면…" 같은 보기는 무조건 오답.

Stop·Terminate·Hibernate 차이를 표로 정리하면 깔끔합니다.

동작	메모리(RAM)	루트 EBS	인스턴스 스토어	재시작
Stop (중지)	삭제됨	유지됨	삭제됨	가능
Terminate (종료)	삭제됨	기본 삭제(설정 변경 가능)	삭제됨	불가(인스턴스 자체 삭제)
Hibernate (동면)	EBS에 저장	유지됨	삭제됨	가능(이전 상태 복구)

여기서 한 가지 더 — Reboot은 셋 다 어디에도 없어요. 재부팅은 그냥 OS 재시작이라 데이터·IP가 다 그대로 유지됩니다.

다음 단원에서는 EC2의 짝꿍 — EBS 스토리지 로 넘어갑니다. 여기서부터 시험 출제 빈도가 또 한 번 확 올라가요.

EBS 볼륨 타입 — 6가지 중에 어떤 걸 골라야 하나

한 줄 정의 + AZ 바인딩

EBS(Elastic Block Store) 는 EC2에 붙이는 가상 디스크예요. 회사로 치면 — 사무실(EC2)에 들이는 외장 캐비닛 같은 거. 데이터를 영구 보존하려면 거의 항상 EBS에 저장합니다. 깊게 파고들 때는 EBS 사용자 가이드 를 옆에 두고 보면 편해요.

EBS는 특정 AZ에 바인딩돼요. 서울 AZ-a에서 만든 EBS는 같은 서울 AZ-c의 인스턴스에 못 붙습니다. 다른 AZ로 옮기려면 스냅샷을 먼저 떠서, 다른 AZ에서 그 스냅샷으로 새 볼륨을 만들어야 해요.

6종 비교 — SSD 4 + HDD 2

볼륨 타입은 여섯 가지예요. 처음 보면 많아 보이는데, SSD 4종 + HDD 2종 으로 갈리고, 각자 푸는 문제가 다릅니다.

볼륨 타입	종류	용도	최대 IOPS	처리량	부팅 가능	특징
gp3	범용 SSD	시스템 부팅, 가상 데스크톱, 개발/테스트	16,000	1,000 MB/s	O	IOPS와 처리량을 독립적으로 설정 가능
gp2	범용 SSD	시스템 부팅, 가상 데스크톱	16,000	-	O	볼륨 크기와 IOPS가 연동 (1GB = 3 IOPS)
io1	프로비저닝 IOPS SSD	미션 크리티컬 DB	64,000 (Nitro)	-	O	Multi-Attach 지원
io2 Block Express	프로비저닝 IOPS SSD	최고 성능 DB	256,000	-	O	밀리초 미만 지연, 최대 64TB, Multi-Attach 지원
st1	처리량 최적화 HDD	빅데이터, 데이터 웨어하우스, 로그 처리	500	500 MB/s	X	자주 액세스하는 대용량 데이터
sc1	콜드 HDD	아카이브, 저빈도 액세스 데이터	250	250 MB/s	X	가장 저렴한 EBS 볼륨

시험 단골 규칙 — 부팅·gp2/gp3·고IOPS

여기서 시험에 자주 나오는 핵심 규칙들을 짚어둡니다.

부팅 볼륨에는 SSD 타입만 가능 — gp2, gp3, io1, io2. HDD(st1, sc1)는 부팅 볼륨이 못 됩니다. 시험에 자주 나와요.
gp2 vs gp3 차이가 시험 단골 — gp2는 볼륨 크기에 IOPS가 묶여 있어요(1GB당 3 IOPS, 그래서 IOPS를 더 받으려면 용량을 키워야 함). gp3는 IOPS와 처리량을 독립적으로 설정 가능. "용량 그대로 두고 IOPS만 올리고 싶다" 면 답은 gp3.
32,000 IOPS 이상 필요? → io1 또는 io2 + Nitro 인스턴스 조합.
빅데이터/로그 처리 (고처리량 + 저비용) → st1.
장기 보관 + 가장 저렴 → sc1.

처음 보면 헷갈리지만, 워크로드 키워드 → 볼륨 타입 매칭만 익혀두면 시험 보기에서 답이 거의 보입니다.

EBS 스냅샷 — 백업, 그리고 변형 4가지

EBS의 백업 수단이 스냅샷(Snapshot) 입니다. 특정 시점의 볼륨 상태를 통째로 떠두는 거예요. 스냅샷이 있으면 다른 AZ나 다른 리전으로 볼륨을 옮길 수도 있고, 실수로 삭제했을 때 복구할 수도 있습니다.

스냅샷에는 변형이 네 가지 있어요.

기능	설명	비용	복구 시간	키워드
Standard	기본 스냅샷 스토리지	보통	즉시	일반 백업
Archive	장기 보관용 저렴한 계층	최대 75% 절감	24~72시간	장기 보관, 즉시 복구 불필요
Recycle Bin(휴지통)	우발적 삭제 방지 및 복구	-	보존 기간 내 즉시	실수 삭제 방지, 1일~1년 보존
FSR (Fast Snapshot Restore)	초기 지연 없이 즉시 최대 성능	매우 비쌈	즉시	즉각적인 최대 성능

FSR이 좀 특이한데, 일반 스냅샷에서 새 볼륨을 만들면 처음에는 데이터가 백그라운드로 천천히 채워져요(Lazy Loading). 그래서 만든 직후에 IOPS를 풀로 못 씁니다. FSR을 켜두면 그 지연이 사라져서 만들자마자 최대 성능이 나와요. 다만 비용이 매우 비싸서 정말 필요할 때만 씁니다.

스냅샷의 활용:

AZ 간 볼륨 이동: 스냅샷 → 다른 AZ에서 새 볼륨 생성
리전 간 복사: 스냅샷 복사로 다른 리전으로 이동(DR 목적)
암호화 적용: 비암호화 볼륨도 스냅샷 → 암호화 복사 → 새 볼륨으로 우회 가능

비암호화 볼륨을 암호화로 바꾸는 표준 절차

이게 시험 단골이에요. 절차가 정해져 있습니다.

비암호화 EBS 볼륨의 스냅샷 생성
그 스냅샷을 복사(Copy)하면서 암호화 활성화 + KMS 키 선택
암호화된 스냅샷으로 새 EBS 볼륨 생성
새 암호화된 볼륨을 인스턴스에 연결(Attach)

EBS 암호화는 AWS KMS 위에서 AES-256 으로 동작하고, 볼륨·전송 중·스냅샷·스냅샷에서 만든 모든 새 볼륨까지 자동 암호화돼요. 성능 영향도 거의 없으니 — 모든 환경에서 켜두는 게 모범 사례입니다.

EBS Multi-Attach — 한 볼륨을 여러 인스턴스에서 동시에

Multi-Attach는 단일 EBS 볼륨을 같은 AZ 안의 여러 EC2 인스턴스에 동시에 붙이는 기능입니다. 모두가 동시에 읽기/쓰기 권한을 가져요.

조건이 좀 까다롭습니다.

지원 볼륨: io1, io2 만 (gp2/gp3는 안 됨)
최대 연결 수: 16개
파일 시스템: 클러스터 인식 파일 시스템이 필수예요. ext4·XFS 같은 일반 파일 시스템은 동시 쓰기가 안전하지 않으니 사용 불가.

언제 쓰냐 — Linux 클러스터링 애플리케이션, Teradata 같은 분산 DB 같이 여러 노드가 같은 디스크를 공유해야 하는 특수한 경우. 일반 웹 서비스에는 거의 안 씁니다.

EBS vs EFS vs Instance Store — 셋의 차이가 시험 단골

지금까지 EBS는 봤고, 이제 EFS와 Instance Store 가 등장합니다. 셋이 비슷해 보여도 푸는 문제가 다 달라요. 표로 한 번에 정리합니다.

구분	Amazon EBS	Amazon EFS	EC2 Instance Store
유형	블록 스토리지(네트워크)	파일 스토리지(네트워크)	블록 스토리지(물리 직결)
연결	기본 1:1(io1/io2 Multi-Attach)	1:N (다수 인스턴스 동시)	단일 인스턴스 물리 종속
AZ	단일 AZ 고정	다중 AZ 지원	단일 인스턴스 고정
OS	Windows·Linux 모두	Linux 전용(POSIX)	Windows·Linux 모두
데이터 영속성	영구 보관(스냅샷 가능)	영구 보관	휘발성(중지/종료 시 삭제)
성능	볼륨 타입에 따라 다름	보통	최고(수백만 IOPS)
비용	중간	비쌈(사용량 기반)	인스턴스 비용에 포함
사용 사례	DB, 범용 스토리지	공유 파일 시스템, 웹 서버	캐시, 버퍼, 임시 데이터

이 셋의 차이를 한 줄로 풀면 — EBS = 캐비닛(한 사무실 전용), EFS = 공용 자료실(여러 사무실이 같이 씀), Instance Store = 책상에 붙어 있는 서랍(자리 떠나면 사라짐).

특히 Instance Store가 휘발성이라는 점이 시험에 정말 자주 나와요. 인스턴스를 Stop·Terminate하거나 하드웨어 장애가 나면 데이터가 다 날아갑니다. 단, Reboot 시에는 데이터가 유지돼요(이게 시험 함정).

그래서 Instance Store는 임시 데이터 — 캐시·버퍼·스크래치 데이터 에만 써야 합니다. 데이터베이스처럼 영속성이 필요한 데이터는 절대 Instance Store에 두면 안 돼요. 데이터 백업·복제는 전적으로 사용자 책임입니다.

EFS 좀 더 — 성능 모드, 처리량 모드, 스토리지 클래스

EFS가 좀 더 깊게 들어갈 부분이 있어서 따로 풀어 갑니다.

EFS(Elastic File System) 는 AWS의 관리형 NFS(Network File System) 예요. 여러 EC2 인스턴스가 동시에 마운트해서 공유하는 파일 시스템. 다중 AZ를 지원해서 가용성도 좋습니다. 단, Linux 전용이에요(Windows에서 공유 파일 시스템이 필요하면 Amazon FSx 사용).

성능 모드 — General Purpose vs Max I/O

모드	특징	사용 사례
General Purpose(기본값)	낮은 지연 시간, 대부분 워크로드 적합	웹 서버, CMS, WordPress, 홈 디렉터리
Max I/O	지연 시간 증가하나 처리량/병렬 처리 극대화	빅데이터 분석, 미디어 처리, 대규모 병렬 앱

대부분은 General Purpose가 답이에요. Max I/O는 정말 수백~수천 노드가 동시에 IO 때리는 특수 환경에서만 씁니다.

처리량 모드 — Bursting vs Provisioned vs Elastic

모드	특징	사용 사례
Bursting(기본값)	스토리지 크기에 비례한 처리량	일반 워크로드
Provisioned	크기와 무관하게 처리량 직접 설정	처리량을 미리 아는 경우
Elastic(AWS 권장)	워크로드 따라 자동 확장/축소	예측 불가능한 워크로드

시험에 "예측 불가능한 워크로드 + 자동 확장" 키워드가 나오면 답은 Elastic입니다.

스토리지 클래스 + 수명 주기 관리

클래스	설명	비용
EFS Standard	자주 액세스, 다중 AZ	높음
EFS-IA(Infrequent Access)	자주 안 쓰는 파일	저렴(읽기 시 검색 비용)
EFS Archive	1년에 몇 번만 접근	가장 저렴
EFS One Zone	단일 AZ만 저장	Standard보다 저렴
EFS One Zone-IA	단일 AZ + IA 계층	가장 저렴한 EFS

수명 주기 정책을 켜두면 — 예를 들어 30일간 접근 안 한 파일은 자동으로 IA → Archive 계층으로 이동시켜서 최대 90% 비용 절감이 가능합니다. 시험에서 "EFS 비용 절감"이 나오면 답이 거의 항상 수명 주기 + IA/Archive 활용.

EFS 보안 관련해서도 시험 포인트 있어요.

보안 그룹으로 접근 제어
NFS 프로토콜, 포트 2049 허용 필수
KMS로 미사용 데이터 암호화 가능

> 시험 키워드 — Linux 공유 파일 시스템 + 다중 AZ + 동시 마운트 = EFS. Windows 공유 파일 시스템 = FSx(EFS 아님).

AMI vs 스냅샷 — 마지막에 한 번 더 정리

이 둘이 시험에서 헷갈리기 쉬운 페어라서 마지막에 표로 박아 둡니다.

구분	AMI	EBS 스냅샷
정의	EC2 인스턴스 전체 템플릿(OS + 소프트웨어 + 설정)	EBS 볼륨의 특정 시점 백업
포함	OS, 앱, EBS 스냅샷까지 포함	볼륨 데이터만
용도	새 EC2 인스턴스 시작	볼륨 복원, AZ/리전 간 이동
리전 종속	리전 종속(타 리전 사용 시 복사 필요)	리전에 저장(복사로 이동 가능)
생성	AMI 만들면 EBS 스냅샷이 자동 생성됨	EBS 볼륨에서 직접 생성

핵심은 — AMI는 인스턴스 통째 템플릿, 스냅샷은 볼륨 한 장 백업. 헷갈릴 때마다 이 한 줄만 떠올리시면 돼요.

시험 직전 한 번 더 — 자주 헷갈리는 함정 모음

여기까지가 EC2와 스토리지 영역의 핵심입니다. 시험 직전에 한 번 더 펼칠 압축 노트를 마지막에 박아 둡니다.

EC2 기본기 — 시작·종료·네트워크·IAM

EC2는 IaaS
User Data = 처음 시작 시 단 한 번만 실행, 루트 권한
Stop/Start = 퍼블릭 IP 변경, 프라이빗 IP 유지 / Reboot = IP 모두 유지
루트 EBS의 Delete on Termination 기본값 = True / 추가 EBS는 False
보안 그룹은 외부 가상 방화벽, 허용 규칙만 존재(거부 규칙 없음)
타임아웃 = 보안 그룹 / 연결 거부 = 애플리케이션
기본 보안 그룹·사용 중 보안 그룹 = 삭제 불가
EC2가 다른 AWS 서비스 접근 = IAM 역할(Instance Profile) 사용, 액세스 키 하드코딩 X
IAM 역할 정책 변경 = 인스턴스 재시작 없이 즉시 반영
배치 그룹: Cluster = 모아서 빠르게 / Spread = 흩어서 안전(AZ당 7개) / Partition = 그룹 분산(Hadoop·Kafka·Cassandra)
ENI = AZ 종속, 떼서 다른 인스턴스에 붙이면 프라이빗 IP·MAC 유지된 채 페일오버
Hibernate 조건: EBS + 암호화 + 충분한 공간 + RAM 150GB 미만, 활성화는 인스턴스 최초 생성 시에만, 최대 60일

구매 옵션·라이선스

구매 옵션: 스팟 = 최대 90% / Savings = 최대 70% / RI Standard = 최대 72% / Convertible = 최대 66%
Persistent 스팟 종료 순서 = Cancel → Terminate (꼭 이 순서)
BYOL/소켓·코어 라이선스 = Dedicated Hosts / 특정 AZ 용량 보장 = Capacity Reservations

스토리지 — AMI·EBS·EFS·Instance Store

AMI는 리전 종속, 다른 리전 쓰려면 복사 필요
EBS는 AZ 바인딩, 다른 AZ로 옮기려면 스냅샷 → 새 볼륨
gp2 = 크기와 IOPS 연동 / gp3 = IOPS·처리량 독립 설정 가능
io1/io2 = 32,000+ IOPS, Multi-Attach 지원
HDD(st1, sc1) = 부팅 볼륨 불가
비암호화 → 암호화: 스냅샷 → 암호화 복사 → 새 볼륨
Multi-Attach = io1/io2만, 같은 AZ, 최대 16개, 클러스터 인식 파일 시스템 필수
EFS = Linux 전용, 다중 AZ, NFS 포트 2049, 처리량 Elastic 모드 = AWS 권장
EFS 수명 주기(IA/Archive) = 비용 최대 90% 절감
Instance Store = 휘발성, Reboot 시에는 유지 / Stop·Terminate·하드웨어 장애 시 삭제
AMI = 인스턴스 전체 템플릿 / 스냅샷 = 볼륨 한 장 백업

마무리 한 줄

여기까지가 SAA-C03 두 번째 단원 EC2와 스토리지의 전부입니다. 1편 IAM이 "권한의 뼈대"였다면, 2편은 "그 위에서 실제로 일하는 컴퓨팅 본체"였어요. 옵션이 너무 많아서 처음엔 머리가 아픈데, 워크로드 → 키워드 → 옵션 매칭 흐름만 잡으면 시험 문제는 거의 다 풀립니다. 표를 직접 손으로 한 번 더 옮겨 그려 보면 머리에 빠르게 박혀요.

시리즈 다른 편

같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.