home
SAA-C03

[Compute] EC2 컨셉 노트

EC2 시험 빈출 컨셉 노트

Amazon EC2 for SAA-C03

One-Line Summary

Amazon EC2는 물리 서버를 사지 않고 필요한 만큼 원격 가상 서버를 빌려 쓰는 서비스다. 시험에서는 대부분 요금 모델 선택과 Auto Scaling 정책 선택을 묻는다.

Why It Exists

물리 서버를 사서 데이터센터에 두면 초기 투자(CapEx)가 크고, 미리 용량을 넉넉히 사둬야 하며, 부하가 줄어도 그대로 비용이 나간다.

EC2는 이 문제를 해결한다.

물리 서버 구매
  -> 큰 초기 투자, 고정 용량, 늘리고 줄이기 어려움

EC2
  -> 몇 분 만에 서버 생성/종료
  -> 쓴 만큼 과금(OpEx)
  -> 부하에 따라 대수 자동 조절

시험 감각:

"원격으로 서버를 빌려서 애플리케이션을 실행한다" = EC2.

Abbreviations

약어풀네임의미
EC2Elastic Compute Cloud원격으로 빌려 쓰는 가상 서버
ASGAuto Scaling GroupEC2 대수를 자동으로 조절하는 그룹
AMIAmazon Machine ImageEC2를 생성할 때 쓰는 서버 이미지(OS+설정)
RIReserved Instance1~3년 약정 요금 모델
SPSavings Plans시간당 사용액 약정 요금 모델
BYOLBring Your Own License보유한 라이선스를 가져와서 사용
CapExCapital Expenditure자본 지출(초기 투자)
OpExOperational Expenditure운영 지출(사용한 만큼 지불)

EC2 Auto Scaling

Auto Scaling은 EC2 자체 기능이 아니라 별도 개념인 Auto Scaling Group (ASG) 이다. ASG가 "몇 대를 유지할지" 정하고, 그 판단 규칙이 Scaling Policy다.

Auto Scaling Group
  -> min / desired / max 대수 설정
  -> Scaling Policy에 따라 자동 확장/축소
  -> 비정상 인스턴스는 교체(self-healing)
항목의미
목적부하에 맞춰 대수 자동 조절, 가용성 유지
min/desired/max최소/희망/최대 인스턴스 수
self-healing비정상 인스턴스 종료 후 새로 생성
시험 키워드scale in/out, maintain availability, match demand

Scaling Policies

정책동작시험 감각
Target Tracking특정 지표를 목표값으로 유지 (예: 평균 CPU 50%)가장 쉽고 AWS 권장. "지표를 이 값으로 유지"
Step Scaling임계값을 얼마나 초과했는지 단계별로 다르게 조정세밀한 제어 필요 시
Simple Scaling임계값 넘으면 정해진 수만큼 조정 (쿨다운 대기)구형, 단순
Scheduled Scaling예측 가능한 시간대에 미리 조정"매일 오전 9시 트래픽 급증"
Predictive ScalingML로 미래 부하 예측 후 미리 확장주기적 패턴 있는 워크로드

Target Tracking Policy

Target Tracking Policy는 지정한 지표를 목표값으로 유지하도록 ASG가 자동으로 대수를 조절하는 정책이다.

목표: 평균 CPU 사용률 50% 유지

CPU가 50%보다 높아짐 -> 인스턴스 추가(scale out)
CPU가 50%보다 낮아짐 -> 인스턴스 제거(scale in)

시험 감각:

에어컨 온도조절기(thermostat)처럼 "이 지표를 이 값으로 계속 맞춰줘"라고 하면 Target Tracking. "가장 간단하게 자동 확장"도 이거다.

EC2 Purchasing Options

모델약정할인대표 워크로드
On-Demand없음없음(가장 비쌈)단기, 예측 불가, 개발/테스트
Reserved Instance1년/3년최대 ~72%24/7 상시 안정 워크로드
Savings Plans1년/3년 (시간당 $ 약정)RI급, 더 유연상시인데 인스턴스 타입이 바뀔 수 있음
Spot없음(여유 용량)최대 90%중단 감내 가능한 배치/CI/빅데이터
Dedicated Host--규정상 물리 서버 격리, 서버 단위 라이선스(BYOL)

On-Demand

항목의미
약정없음
과금초/시간당, 쓴 만큼
적합단기, 예측 불가, 개발/테스트, 처음 도입
단점단가가 가장 비쌈

Reserved Instance / Savings Plans

항목의미
약정1년 또는 3년
할인최대 약 72% (On-Demand 대비)
적합24시간 상시 돌아가는 안정적 워크로드
Savings Plans 차이인스턴스 종류가 아니라 "시간당 사용액"을 약정 → 더 유연

시험 감각:

"steady state", "24/7", "1~3년 예측 가능" 워크로드 = RI 또는 Savings Plans.

Spot Instance

Spot은 AWS의 남는 여유 용량을 크게 할인해 빌려주는 대신, 용량이 필요해지면 2분 통보 후 회수할 수 있는 모델이다.

Spot 인스턴스
  -> 최대 90% 저렴
  -> 언제든 2분 통보 후 중단 가능
  -> 그래서 "죽어도 되는" 작업에만 사용
적합부적합
배치 처리, 빅데이터미션 크리티컬 상시 서버
CI/CD 빌드중단되면 안 되는 상태 저장 앱
stateless / 재시도 가능 워크로드실시간 결제 등

시험 감각:

"can be interrupted", "fault-tolerant", "flexible start/end time", "최저 비용" = Spot.

Dedicated Host / Dedicated Instance

항목의미
목적물리 서버를 전용으로 격리
대표 이유규정 준수, 서버 단위 소프트웨어 라이선스(BYOL)
시험 키워드compliance, physical isolation, per-socket/per-core license

Common Wrong Directions

오답 방향왜 부족한가
상시 워크로드를 계속 On-Demand로 결제24/7이면 RI/Savings Plans가 훨씬 저렴
미션 크리티컬 상시 서버를 Spot으로 구성Spot은 회수될 수 있어 중단 감내 워크로드용
Auto Scaling을 EC2 인스턴스 하나의 기능으로 이해Auto Scaling은 ASG(그룹) 개념
"가장 간단한 자동 확장"에 Step/Simple 선택가장 간단·권장은 Target Tracking
예측 가능한 시간대 급증에 Target Tracking만 고려시간 기반이면 Scheduled Scaling이 더 직접적

Exam Triggers

문제에서 이런 표현이 나오면떠올릴 것
"can be interrupted", "fault-tolerant", "lowest cost"Spot
"steady state", "24/7", "1-3 year commitment"Reserved Instance / Savings Plans
"short-term", "unpredictable", "spiky"On-Demand
"physical server isolation", "compliance", "BYOL"Dedicated Host
"automatically scale based on demand"EC2 Auto Scaling
"maintain average CPU at 50%", 가장 간단한 확장Target Tracking Policy
"traffic spikes every day at 9 AM"Scheduled Scaling

Memory Sentence

EC2는 서버 대여, Auto Scaling(ASG)은 대수 자동 조절, 요금은 상시=RI/Savings·중단가능=Spot·단기=On-Demand·격리=Dedicated Host, 확장 정책은 "지표 유지=Target Tracking, 시간 기반=Scheduled".

References

댓글

아직 댓글이 없습니다.