Amazon EC2 (Elastic Compute Cloud)

Amazon EC2는 AWS가 인프라를 관리하고, 사용자는 가상 서버를 온디맨드로 생성·확장·종료하며 사용한 만큼만 비용을 지불하는 IaaS 컴퓨팅 서비스이다.

1. Amazon EC2란?

Amazon EC2는 AWS에서 제공하는 온디맨드 가상 서버(Virtual Machine, VM) 서비스
애플리케이션 실행에 필요한 컴퓨팅 파워(CPU, 메모리, 네트워크) 를 즉시 제공
필요할 때 생성, 필요 없으면 중지/종료
사용한 만큼만 비용 지불 (Pay-as-you-go)

EC2 = AWS의 대표적인 IaaS (Infrastructure as a Service)

2. 클라이언트 / 서버 모델과 EC2

클라이언트: 요청(Request)을 보내는 쪽 (브라우저, 모바일 앱 등)
서버: 요청을 처리하고 응답(Response)을 반환
EC2 인스턴스는 이 서버 역할을 수행

EC2는 웹 서버, API 서버, 애플리케이션 서버, 배치 서버 등으로 사용 가능

3. 온프레미스(On-Premises) vs EC2

온프레미스의 문제점

서버 선구매 비용(CAPEX) 발생
배송, 설치, 구성까지 시간 소요
트래픽 증가 시 확장 어려움
수요 예측 실패 시 자원 낭비 or 부족

EC2 사용 시 이점

선불 비용 없음
몇 분 안에 서버 생성
필요 시 즉시 확장/축소
사용량 기반 과금(OPEX)

클라우드는 민첩성(Agility) 과 확장성(Scalability) 이 핵심 가치

4. EC2 인스턴스의 본질: 가상 머신(VM)

EC2 인스턴스 = 가상 머신
하나의 물리 서버 위에서 여러 VM이 실행됨 → 멀티테넌시(Multi-tenancy)

멀티테넌시

여러 고객의 인스턴스가 같은 물리 호스트를 공유
서로 완전히 격리(Isolation) 되어 동작

하이퍼바이저(Hypervisor)

물리 서버에서 VM을 생성·관리하는 소프트웨어
AWS가 하이퍼바이저와 물리 인프라를 모두 관리
사용자는 인프라 관리 책임 없음

EC2의 보안 격리는 하이퍼바이저 레벨에서 보장됨

5. EC2 인스턴스 구성 요소

1) AMI (Amazon Machine Image)

인스턴스의 템플릿
포함 내용:
- 운영체제(OS)
- 사전 설치된 소프트웨어
- 설정 값

EC2 생성의 시작은 AMI 선택

2) 인스턴스 유형 (Instance Type)

CPU, 메모리, 네트워크 성능 조합
예: t, m, c, r 계열 등

워크로드 특성에 맞는 인스턴스 타입 선택 중요

3) 운영체제 선택

Linux
Windows

4) 소프트웨어 자유도

웹 애플리케이션
데이터베이스
사내 업무 시스템
서드파티 엔터프라이즈 소프트웨어

EC2는 OS 위 레벨은 전부 고객 책임 (Shared Responsibility Model)

6. EC2 연결 방식

대표적인 연결 방법

Linux → SSH
Windows → RDP
AWS Systems Manager (SSM)
- 키 관리 없이 안전한 접속 가능

보안 강화 관점에서 SSM 사용이 자주 언급됨

7. EC2 스케일링

수직적 스케일링 (Vertical Scaling)

인스턴스의 사양 변경
CPU / 메모리 증가 또는 감소

수직 스케일링 = 인스턴스 크기 변경
(수평 스케일링은 Auto Scaling과 함께 출제됨)

8. 네트워킹 제어

퍼블릭 접근 / 프라이빗 접근 설정 가능
어떤 요청을 허용할지 직접 제어

EC2 네트워크 접근 제어는 보안 그룹 / NACL 과 연계

9. 비용 모델

실행 중인 인스턴스에 대해서만 과금
중지(Stopped) 또는 종료(Terminated) 시:
- 컴퓨팅 비용 발생 ❌
- (단, 스토리지는 별도 과금 가능)

EC2는 시간 단위(or 초 단위) 과금 모델

EC2 인스턴스 유형(Instance Types)

1) 인스턴스 유형이란?

EC2는 “서버 한 종류”가 아니라, 워크로드에 맞게 하드웨어 조합(CPU/메모리/스토리지/네트워크) 을 고를 수 있는 서비스
인스턴스 유형은 인스턴스 패밀리(Instance family) 로 묶이며, 각 패밀리는 특정 리소스를 “강조(최적화)”합니다.
선택 흐름:
1. 인스턴스 패밀리 선택(어떤 자원이 핵심인지)
2. 인스턴스 크기 선택(얼마나 크게 필요한지)

시험에서는 “상황 설명 → 어떤 패밀리를 선택해야 하는가”가 자주 나옵니다.

2) 인스턴스 패밀리 5가지 분류와 쓰임새

A. 범용(General Purpose)

특징: CPU / 메모리 / 네트워크 균형
추천 상황:
- 웹 서비스(일반적인 API/웹 서버)
- 코드 리포지토리
- 워크로드 특성이 아직 불확실할 때 “출발점”으로 적합

핵심 기억법: “일단 모르겠으면 범용부터”

B. 컴퓨팅 최적화(Compute Optimized)

특징: CPU 성능이 핵심(연산량이 많음)
추천 상황:
- 게임 서버
- HPC(High Performance Computing)
- 기계 학습 태스크(특히 CPU 연산 중심)
- 과학/수학 모델링 등 연산 집약적 작업

핵심 기억법: “CPU가 병목이면 컴퓨팅 최적화”

C. 메모리 최적화(Memory Optimized)

특징: 메모리(RAM) 중심
추천 상황:
- 대규모 데이터세트 처리
- 데이터 분석(메모리에서 많이 올려 처리)
- 데이터베이스 처리(메모리 압박이 큰 경우)

핵심 기억법: “RAM이 부족하면 메모리 최적화”

D. 가속 컴퓨팅(Accelerated Computing)

특징: GPU 같은 하드웨어 가속기 사용
추천 상황:
- 부동 소수점 연산이 많은 작업
- 그래픽 처리
- 데이터 패턴 매칭
- 기계 학습(특히 GPU 사용)

정의 포인트:

하드웨어 가속기 = CPU로 소프트웨어 처리하는 것보다 효율적으로 특정 계산을 수행하는 보조 프로세서

핵심 기억법: “GPU/가속기 필요하면 가속 컴퓨팅”

E. 스토리지 최적화(Storage Optimized)

특징: 로컬 스토리지 I/O 성능이 핵심
추천 상황:
- 로컬 저장 데이터에 대해 고성능이 필요한 워크로드
- I/O 집약형 애플리케이션
- 대규모 데이터베이스 / 데이터 웨어하우징(특히 고속 I/O 요구)

핵심 기억법: “디스크 I/O가 병목이면 스토리지 최적화”

3) 인스턴스 ‘크기(Size)’ 선택 포인트

같은 패밀리 안에서도 small → large → xlarge ... 처럼 크기가 다양함
크기가 커질수록:
- CPU/메모리/스토리지/네트워크가 늘어남
- 비용도 증가

시험/실무 공통 포인트:

“성능만”이 아니라 비용 대비 적정 크기(right-sizing) 를 잡는 게 중요
과하게 큰 인스턴스는 낭비, 너무 작은 인스턴스는 병목/장애

4) 클라우드의 장점: 선택은 ‘고정’이 아니다

처음 선택이 최적이 아닐 수 있음 → 정상적인 과정
EC2는 필요하면 다른 인스턴스 유형/크기로 빠르게 전환할 수 있음
즉, “측정 → 조정”을 반복하는 방식으로 최적화 가능

5) SAA에서 자주 나오는 선택 요령

“웹 서버/일반 서비스/잘 모르겠다” → 범용
“CPU 많이 먹는다/HPC/게임 서버” → 컴퓨팅 최적화
“데이터셋이 크고 메모리에서 처리한다/DB 메모리 압박” → 메모리 최적화
“GPU/그래픽/딥러닝/부동소수점 계산” → 가속 컴퓨팅
“디스크 I/O, 로컬 스토리지 고성능, IOPS 병목” → 스토리지 최적화

AWS API와 서비스 상호 작용 방식

AWS에서 모든 리소스 작업은 API로 이루어지며, 사용자는 AWS Management Console, AWS CLI, AWS SDK 중 하나를 통해 이를 호출한다. EC2는 비관리형 서비스이므로 OS와 보안 구성은 고객 책임이다.

1. 핵심 전제: AWS의 모든 작업은 API 호출이다

EC2 인스턴스 시작 / 중지 / 설정 변경
리소스 생성 / 수정 / 삭제
모니터링 / 조회

이 모든 작업은 내부적으로 AWS API 호출로 이루어진다.
사용자는 API를 직접 또는 간접적으로 호출한다.

AWS에서 서비스와의 모든 상호 작용은 API를 통해 수행된다.

2. AWS API를 호출하는 3가지 주요 방법

AWS API는 아래 3가지 인터페이스를 통해 접근할 수 있다.

3. AWS Management Console

개념

브라우저 기반 웹 인터페이스
버튼 클릭(point-and-click) 방식
모든 작업은 내부적으로 API 호출

장점

시각적이고 직관적
AWS 학습 초기 단계에 적합
테스트 환경 구성
리소스 모니터링
청구서(Billing) 확인
비기술적 작업에 유용

단점

수동 작업 → 반복 시 비효율
사람 개입 → 실수 가능성(오타, 체크 누락)

권장 대상

AWS 입문자
시각적 UI를 선호하는 사용자
실험, 테스트, 학습 목적

콘솔도 결국 API를 호출하는 프론트엔드일 뿐이다.

4. AWS CLI (Command Line Interface)

개념

터미널에서 텍스트 명령어로 AWS API 호출
Windows / macOS / Linux 지원
스크립트와 자동화에 매우 적합

특징

콘솔보다 빠르고 일관된 작업 가능
스크립팅을 통한 자동화 가능
반복 작업, 대량 리소스 관리에 유리

예시 개념

EC2 인스턴스 생성 → run-instances
가용 영역 조회 → describe-availability-zones

(시험에서는 명령어 이름 자체보다 “CLI로 자동화 가능”하다는 개념이 중요)

CloudShell

AWS에서 제공하는 브라우저 기반 터미널
AWS CLI가 미리 설치됨
별도 로컬 설정 없이 바로 사용 가능

권장 대상

고급 사용자
운영 담당자
자동화 / 스크립트 기반 관리가 필요한 경우

자동화, 반복 작업, 운영 환경 → AWS CLI

5. AWS SDK (Software Development Kit)

개념

프로그래밍 언어에서 AWS API를 호출할 수 있게 해주는 라이브러리
Python, Java, C++, .NET 등 다양한 언어 지원

특징

애플리케이션 코드 안에서 AWS 리소스 제어 가능
AWS 서비스를 애플리케이션에 통합하는 데 사용
내부적으로 역시 API 호출

사용 예

Python 코드에서 EC2 인스턴스 목록 조회
애플리케이션 실행 중 S3 업로드
백엔드 로직에서 DynamoDB 접근

권장 대상

개발자
AWS 리소스를 코드 레벨에서 제어해야 하는 경우

“애플리케이션에서 AWS를 사용한다” → SDK

6. 3가지 방식 비교 요약

Console
- 시각적
- 학습/테스트/수동 관리
CLI
- 명령줄
- 자동화 / 스크립트 / 운영
SDK
- 코드
- 애플리케이션 통합

👉 하지만 셋 다 결국 같은 AWS API를 호출한다.

7. 자동화의 중요성

수동 프로비저닝:
- 느림
- 오류 발생 가능성 큼
자동화:
- 예측 가능
- 반복 가능
- 안정적인 배포

“성공적이고 예측 가능한 클라우드 배포”의 핵심 = 자동화

8. 공동 책임 모델 (Shared Responsibility Model)

기본 원칙

AWS 책임: 클라우드의 보안
- 물리적 데이터 센터
- 하드웨어
- 인프라
고객 책임: 클라우드 내부의 보안
- 애플리케이션
- 데이터
- IAM 권한
- OS 관리
- 네트워크 설정

9. EC2와 공동 책임

EC2는 비관리형(Unmanaged) 서비스에 해당

고객 책임:

게스트 OS 관리
OS 패치 및 업데이트
보안 그룹(방화벽) 설정
애플리케이션 보안
사용자 계정 및 접근 제어

EC2 = 고객 책임 범위가 넓다 (관리형 서비스는 나중에 비교 출제됨)

AWS EC2 인스턴스 생성과 AMI

AWS에서 EC2 인스턴스는 AWS Management Console을 통해 단계별로 생성할 수 있으며, 이 과정에서 AMI, 인스턴스 유형, 키 페어, 네트워크, 스토리지, User Data 등이 핵심 구성 요소로 사용된다.
AMI는 EC2 인스턴스의 기본 환경을 정의하는 템플릿으로, 반복 가능하고 일관된 인프라 배포의 핵심이다.

1. 핵심 전제: EC2 인스턴스 생성은 구성 요소 선택의 조합이다

EC2 인스턴스는 “한 번에 생성”되는 것이 아니라
- AMI
- 인스턴스 유형
- 키 페어
- 네트워크 설정
- 스토리지
- 시작 시 실행할 스크립트(User Data)
  를 조합하여 생성된다.
콘솔에서의 모든 클릭은 내부적으로 AWS API 호출이다.

2. EC2 인스턴스 생성의 시작: Launch Instance

EC2 콘솔에서 Launch instance 선택
새 EC2 인스턴스 생성 프로세스의 진입점
이후 단계별 설정을 통해 인스턴스의 성격이 결정됨

3. 인스턴스 이름(Name)

인스턴스를 식별하기 위한 논리적 이름
기능적 영향은 없으나,
- 운영
- 모니터링
- 관리 측면에서 매우 중요

4. AMI (Amazon Machine Image) 선택

개념

EC2 인스턴스를 시작하기 위한 가상 머신 템플릿
운영 체제 및 기본 소프트웨어 포함

데모에서 사용한 AMI

Amazon Linux AMI
범용 웹 서버에 적합한 기본 AMI

AMI의 역할

인스턴스의 “출발 상태”를 결정
같은 AMI → 같은 환경의 인스턴스를 반복 생성 가능

5. 인스턴스 유형(Instance Type)

개념

인스턴스의 CPU / 메모리 성능 정의

데모에서 사용한 유형

t2.micro
- vCPU 1개
- 메모리 1GB
- 프리 티어 대상

핵심 포인트

인스턴스 유형은 성능과 비용에 직접적인 영향
처음에는 작은 타입으로 시작 후 변경 가능

6. 키 페어(Key Pair)

개념

EC2 인스턴스에 접속(로그인) 하기 위한 인증 수단
퍼블릭 키 + 프라이빗 키의 쌍

책임 주체

퍼블릭 키: EC2 인스턴스에 저장
프라이빗 키: 사용자 보관 (분실 시 복구 불가)

시험 포인트

EC2 접근 제어는 키 페어 + 보안 그룹 조합

7. 네트워크 설정(Network Settings)

데모 설정

Allow HTTP traffic from the internet 선택

의미

인터넷에서 HTTP(80 포트) 접근 허용
웹 서버로 동작 가능

핵심 개념

이 설정은 내부적으로 보안 그룹(Security Group) 규칙을 구성

8. 스토리지 설정(Storage)

데모 설정

gp3 EBS 볼륨
8GB 용량

개념

EBS(Elastic Block Store)는 EC2에 연결되는 블록 스토리지
인스턴스의 루트 디스크 역할

9. User Data를 통한 초기 설정

문제 상황

기본 Amazon Linux AMI에는 웹 서버가 자동으로 실행되지 않음

해결 방법

Advanced Details → User Data
시작 시 실행할 스크립트 삽입

역할

인스턴스 최초 부팅 시:
- Nginx 설치
- 웹 서버 자동 시작
- 등 자동화

시험 포인트

User Data는 초기 자동 설정(bootstrap) 용도
인스턴스 시작 시 1회 실행

10. 인스턴스 실행 및 검증

Launch Instance 실행
인스턴스 상태: running
퍼블릭 IP 주소 확인
브라우저에서 퍼블릭 IP 접속
웹 서버 정상 동작 확인

11. AMI 심화 개념

AMI의 구성 요소

운영 체제(OS)
스토리지 설정
CPU 아키텍처
시작 권한
사전 설치된 소프트웨어

12. AMI를 사용하는 3가지 방법

사용자 지정 AMI
- 직접 구성한 환경을 AMI로 생성
AWS 제공 AMI
- 일반적인 OS 및 소프트웨어 포함
AWS Marketplace AMI
- 서드 파티 공급업체가 제공
- 특정 사용 사례에 최적화된 소프트웨어 포함

13. AMI의 반복성과 자동화

동일한 AMI → 동일한 환경
개발 / 테스트 / 프로덕션 환경 일관성 유지
자동화 및 대규모 확장에 유리
오류 감소 및 운영 단순화

EC2 인스턴스는 AMI를 기반으로 다양한 설정을 조합해 생성되며, AMI는 일관되고 반복 가능한 인프라 배포의 핵심 요소이다.

Amazon EC2 요금 옵션

Amazon EC2는 다양한 워크로드 패턴에 대응하기 위해 여러 요금 옵션을 제공한다.
각 옵션은 비용, 유연성, 예측 가능성, 제어 수준의 균형이 다르며, 사용 사례에 맞게 선택하는 것이 핵심이다.

1. 핵심 전제: EC2 비용은 사용 패턴에 따라 최적화할 수 있다

EC2는 단일 요금 모델이 아니다.
워크로드의 특성에 따라:
- 즉시성
- 예측 가능성
- 중단 허용 여부
- 규정/라이선스 요구 사항
  을 기준으로 요금 옵션을 선택한다.
잘못된 요금 옵션 선택은 불필요한 비용 증가로 이어진다.

2. 온디맨드 인스턴스(On-Demand)

개념

실행한 인스턴스 시간(또는 초)만큼만 비용 지불
장기 약정 없음
선불 결제 없음

특징

가장 유연한 요금 옵션
즉시 시작 가능
사용량 변동이 큰 워크로드에 적합

사용 사례

초기 서비스
테스트 및 개발 환경
사용량을 아직 예측할 수 없는 경우

비용 관점

다른 옵션 대비 단가가 가장 높음
하지만 리스크가 가장 낮음

3. 절감형 플랜(Savings Plans)

개념

1년 또는 3년 동안 시간당 일정 사용량을 약정
약정 대가로 할인 제공

할인율

최대 72% 절감

주요 특징

인스턴스 패밀리, 크기, OS, 리전과 무관
적용 대상:
- Amazon EC2
- AWS Fargate
- AWS Lambda
- Amazon SageMaker AI

결제 옵션

전체 선결제
부분 선결제
선결제 없음

사용 사례

장기간 안정적인 사용량이 있는 경우
특정 인스턴스에 종속되지 않고 유연성을 유지하고 싶은 경우

4. 예약 인스턴스(Reserved Instances, RI)

개념

특정 인스턴스 패밀리와 리전에 대해
1년 또는 3년 약정

할인율

온디맨드 대비 최대 75% 절감

결제 옵션

전체 선결제
부분 선결제
선결제 없음

적합한 워크로드

사용량이 예측 가능한
꾸준히 실행되는 안정 상태(steady-state) 워크로드

5. 예약 인스턴스의 유연성

크기 유연성

동일 인스턴스 패밀리 내에서
크기가 달라도 자동으로 할인 적용

AZ 유연성

동일 리전 내 여러 가용 영역(AZ)에 할인 적용
내결함성 및 분산 아키텍처에 유리

핵심 포인트

“완전히 고정된 서버”가 아니라
패밀리 단위의 할인 권한으로 이해해야 함

6. 스팟 인스턴스(Spot Instances)

개념

AWS의 예비 EC2 용량을 저렴하게 사용
AWS가 필요 시 인스턴스를 회수 가능

할인율

온디맨드 대비 최대 90% 절감

제약 사항

언제든지 중단 가능
중단 전 2분 경고 제공

사용 사례

중단되어도 괜찮은 워크로드
- 배치 처리
- 데이터 분석
- 테스트 작업
- 대규모 병렬 연산

핵심 판단 기준

“이 워크로드는 중단되어도 괜찮은가?”

7. 전용 호스트(Dedicated Hosts)

개념

고객이 물리적 서버 전체를 독점 사용
다른 고객과 절대 공유하지 않음

특징

인스턴스 배치 및 리소스 할당 완전 제어
라이선스 단위(소켓, 코어) 관리 가능

사용 사례

Windows / SQL Server 라이선스 기반 워크로드
엄격한 보안 및 규정 준수 요구 사항

8. 전용 인스턴스(Dedicated Instances)

개념

물리적으로 다른 계정과 격리된 인스턴스
하지만 물리 서버 제어권은 없음

전용 호스트와의 차이

전용 호스트: 서버 자체를 독점 + 완전 제어
전용 인스턴스: 격리만 제공, 서버 제어 불가

사용 사례

격리는 필요하지만
물리 서버 단위 제어는 필요 없는 경우

9. 용량 예약(Capacity Reservations)

개념

특정 가용 영역(AZ)에 EC2 용량을 미리 확보
사용 여부와 관계없이 예약된 용량은 유지

요금

온디맨드 요금 기준
실제 실행한 인스턴스에 대해서만 비용 발생

사용 사례

비즈니스 크리티컬 워크로드
반드시 특정 시점에 용량이 필요할 경우

10. 요금 옵션 선택 감각

시작 단계 / 예측 불가 → 온디맨드
장기적이고 안정적 사용 → 절감형 플랜 또는 RI
중단 허용 / 대규모 연산 → 스팟 인스턴스
라이선스·규정·보안 → 전용 호스트
격리만 필요 → 전용 인스턴스
AZ 단위 용량 보장 필요 → 용량 예약

Amazon EC2는 온디맨드, 절감형 플랜, 예약 인스턴스, 스팟 인스턴스, 전용 호스트 등 다양한 요금 옵션을 제공하며, 워크로드의 예측 가능성·중단 허용 여부·제어 요구 수준에 따라 최적의 선택이 달라진다.

AWS 확장성·탄력성과 EC2 Auto Scaling

AWS는 확장성(Scalability)과 탄력성(Elasticity)을 통해 수요 변화에 따라 컴퓨팅 용량을 효율적으로 조정할 수 있도록 지원한다.
이를 통해 고객 만족도와 비용 효율성을 동시에 달성하며, Amazon EC2 Auto Scaling이 이 개념의 핵심 구현 수단이다.

1. 핵심 전제: 수요는 항상 변한다

웹 사이트가 느리거나 타임아웃되는 주요 원인:
- 처리 가능한 용량보다 많은 요청 유입
전통적 온프레미스 환경:
- 피크 트래픽 기준으로 과도한 용량 사전 구매
- 대부분의 시간에는 리소스 낭비 발생
AWS의 접근 방식:
- 필요한 순간에만 용량을 늘리고
- 필요 없으면 즉시 줄인다

2. 확장성과 탄력성의 차이

확장성(Scalability)

시스템이 더 큰 부하를 처리할 수 있도록 성장할 수 있는 능력
장기적인 용량 계획 관점
더 많은 사용자나 워크로드를 수용하는 데 초점

탄력성(Elasticity)

실시간 수요 변화에 따라 리소스를 자동으로 조정
수요 증가 시 확장, 감소 시 축소
비용 효율성과 최적 리소스 사용에 초점

핵심 구분

확장성: “커질 수 있는가”
탄력성: “지금 당장 늘리고 줄일 수 있는가”

3. 스케일링의 두 가지 방식

스케일 업(Scale Up, 수직적 스케일링)

기존 인스턴스의 성능을 증가
CPU, 메모리 등 사양을 키움
단일 인스턴스 성능 향상

제약:

하드웨어 한계 존재
항상 필요한 방식은 아님

스케일 아웃(Scale Out, 수평적 스케일링)

인스턴스 수를 늘려 병렬 처리
여러 인스턴스가 작업을 분담

특징:

고가용성에 유리
AWS에서 권장되는 확장 방식

4. 고가용성과 중복 구성

한 가용 영역에 실패가 발생할 경우 다른 가용 영역의 인스턴스가 트래픽을 처리할 수 있도록 하여 고가용성을 제공하기 위해 여러 가용 영역에 배포

단일 인스턴스 장애 → 서비스 중단
해결 방식:
- 동일한 인스턴스를 여러 개 배포
- 여러 가용 영역(AZ)에 분산 배치
결과:
- 단일 장애 지점(SPOF) 제거
- 한 AZ 장애 시 다른 AZ가 서비스 유지

5. 워크로드별 독립적 스케일링의 중요성

프론트엔드(요청 수신)와 백엔드(처리)는 부하 특성이 다름
모든 계층을 동일하게 확장하면:
- 불필요한 오버프로비저닝 발생
각 구성 요소를 독립적으로 스케일링해야 비용과 성능을 최적화할 수 있음

6. Amazon EC2 Auto Scaling 개념

애플리케이션 수요에 따라 EC2 인스턴스 수를 자동 조정
수요 증가 시 인스턴스 추가
수요 감소 시 인스턴스 종료
사용 중인 인스턴스에 대해서만 비용 발생

7. Auto Scaling의 두 가지 접근 방식

동적 스케일링(Dynamic Scaling)

실시간 지표 기반
현재 수요 변화에 즉각 반응

예측 스케일링(Predictive Scaling)

과거 데이터를 기반으로 미래 수요 예측
트래픽 증가 전에 선제적으로 인스턴스 준비

8. Auto Scaling 그룹(Auto Scaling Group, ASG)

개념

스케일 인/아웃 대상이 되는 EC2 인스턴스 집합
애플리케이션 단위로 관리

9. Auto Scaling 그룹의 3가지 핵심 설정

최소 용량(Minimum Capacity)

항상 유지해야 하는 최소 인스턴스 수
가용성 보장 목적
그룹 생성 직후 시작되는 인스턴스 수

원하는 용량(Desired Capacity)

현재 워크로드를 처리하기 위한 이상적인 인스턴스 수
명시하지 않으면 기본값은 최소 용량

최대 용량(Maximum Capacity)

확장 가능한 인스턴스 수의 상한선
과도한 확장 및 비용 폭증 방지

10. CloudWatch와 Auto Scaling의 연계

Auto Scaling은 단독으로 동작하지 않음
Amazon CloudWatch가:
- CPU 사용률
- 지연 시간
- 기타 애플리케이션 지표 수집
이 지표를 기반으로 스케일링 여부 결정

11. 비용 관점에서의 Auto Scaling

사용한 인스턴스에 대해서만 비용 지불
트래픽이 적을 때는 자동 축소
고객 경험 유지 + 비용 최적화 동시 달성

AWS는 확장성과 탄력성을 통해 수요 변화에 따라 컴퓨팅 용량을 조정하며, Amazon EC2 Auto Scaling은 CloudWatch 지표를 기반으로 인스턴스 수를 자동 조절해 가용성과 비용 효율성을 동시에 제공한다.

Elastic Load Balancing(ELB)

Elastic Load Balancing(ELB)은 들어오는 애플리케이션 트래픽을 여러 EC2 인스턴스에 자동으로 분산하여 성능과 가용성을 향상시키는 AWS의 관리형 로드 밸런싱 서비스이다.
ELB는 Amazon EC2 Auto Scaling과 함께 작동하여 확장성과 고가용성을 동시에 달성한다.

1. 핵심 전제: 스케일링만으로는 트래픽 문제를 해결할 수 없다

EC2 Auto Scaling으로 인스턴스 수는 조절 가능
하지만 문제:
- 사용자는 특정 인스턴스로만 트래픽을 보냄
- 일부 인스턴스는 과부하, 일부는 유휴 상태
해결 과제:
- 들어오는 요청을 균등하고 지능적으로 분산해야 함

2. 로드 밸런싱의 기본 개념

로드 밸런서:
- 클라이언트 요청을 수신
- 여러 백엔드 리소스(EC2 등)로 분산 전달
목적:
- 단일 인스턴스 과부하 방지
- 전체 리소스 활용도 최적화
- 응답 시간 및 안정성 개선

3. 자체 로드 밸런서 vs Elastic Load Balancing

자체 로드 밸런서 사용 시

직접 관리 필요:
- 패치
- 업그레이드
- 장애 조치
- 유지 보수

Elastic Load Balancing 사용 시

한 번 설정하면:
- AWS가 관리 전담
- 자동 확장/축소
- 장애 처리 자동화

4. Elastic Load Balancing(ELB) 개념

AWS 관리형 로드 밸런서 서비스
내부 트래픽 및 외부 트래픽 모두 처리 가능
트래픽 수요에 따라 자동으로 확장 및 축소
시간당 비용 추가 없이 탄력적으로 동작

5. ELB가 해결하는 아키텍처 문제

문제 상황

프론트엔드 인스턴스가
- 모든 백엔드 인스턴스를 직접 인지
백엔드 인스턴스 추가 시:
- 모든 프론트엔드 구성 변경 필요
인스턴스 수 증가 시 관리 복잡도 급증

ELB 도입 후

프론트엔드는 단일 엔드포인트(URL) 만 사용
ELB가:
- 백엔드 인스턴스 상태 관리
- 가장 적절한 인스턴스로 트래픽 전달
티어 간 결합도 감소 (Decoupling)

6. ELB와 Auto Scaling의 관계

ELB와 Auto Scaling은 별도 서비스
하지만 함께 동작하도록 설계됨

동작 흐름

클라이언트 요청 → ELB
ELB → 사용 가능한 EC2 인스턴스로 분산
Auto Scaling:
- 수요 증가 시 인스턴스 추가
- 수요 감소 시 인스턴스 제거
ELB는 변경 사항을 자동 반영

7. ELB의 주요 이점

효율적인 트래픽 분산

모든 EC2 인스턴스에 균등 분산
특정 인스턴스 과부하 방지

오토 스케일링 지원

인스턴스 추가/제거 시 트래픽 자동 재조정
서비스 중단 없이 확장 가능

간소화된 관리

프론트엔드와 백엔드 분리
수동 동기화 불필요
유지 관리 및 장애 조치 자동 처리

8. ELB의 라우팅 방식 개념

ELB는 트래픽 분산을 위해 여러 라우팅 전략을 활용한다.

라운드 로빈

모든 서버에 순차적으로 균등 분산

최소 연결

활성 연결 수가 가장 적은 서버로 전달

최소 응답 시간

응답 속도가 가장 빠른 서버로 전달
지연 시간 최소화 목적

9. 확장성과 고가용성 관점에서의 ELB

단일 접점(Single Entry Point) 제공
인스턴스 장애 시:
- 비정상 인스턴스로 트래픽 전달 차단
- 정상 인스턴스로 자동 우회
Auto Scaling과 결합 시:
- 수요 변화에 자동 대응
- 안정적인 사용자 경험 유지

10. 대표적인 사용 시나리오

트래픽 변동이 큰 웹 애플리케이션
다수의 사용자가 동시에 접속하는 포털
시간대별 수요 편차가 큰 서비스

ELB는 들어오는 요청을 현재 부하가 낮은 인스턴스로 전달하여, 전체 시스템이 균형 있게 동작하도록 한다.

Elastic Load Balancing은 애플리케이션 트래픽을 여러 EC2 인스턴스에 자동 분산하는 관리형 서비스로, Amazon EC2 Auto Scaling과 함께 사용되어 확장성과 고가용성을 동시에 제공한다.

ELB와 Auto Scaling은 함께 작동하여 가변적인 수요의 수준을 효율적으로 관리합니다. ELB는 들어오는 트래픽을 여러 EC2 인스턴스에 균일하게 분산하는 역할을 합니다. 이렇게 하면 어떠한 인스턴스에도 과부하가 발생하지 않습니다. 또한 ELB는 Auto Scaling 그룹으로 유입되는 트래픽의 단일 진입점 역할을 하여, 요청을 적절한 리소스로 전달합니다.

한편 Auto Scaling은 수요에 따라 EC2 인스턴스 수를 자동으로 조정합니다. 최적의 성능 및 리소스 사용을 위해 필요에 따라 인스턴스를 추가하거나 제거합니다. ELB와 Auto Scaling을 함께 사용하면 애플리케이션의 신뢰성과 비용 효율성을 유지하는 데 도움이 됩니다.

메시징 및 대기열 처리(SQS, SNS, EventBridge)

메시징과 대기열 처리는 애플리케이션 구성 요소 간 통신을 분리하여 병목과 연쇄 장애를 방지하고, 트래픽 변동에도 안정적으로 동작하는 아키텍처를 구현하게 해준다.
AWS에서는 Amazon SQS, Amazon SNS, Amazon EventBridge가 메시지·이벤트 기반 통신을 담당하는 핵심 서비스이다.

1. 핵심 전제: 직접 통신은 시스템을 취약하게 만든다

구성 요소 A가 구성 요소 B에 직접 요청을 보내는 구조에서는
- B의 지연이나 장애가 A로 즉시 전파된다.
- 트래픽 증가 시 병목이 빠르게 발생한다.
이 구조에서는
- 처리 속도 불균형
- 장애 격리 실패
- 확장성 저하
  문제가 발생한다.

2. 긴밀하게 결합된 아키텍처(Tightly Coupled)

개념

애플리케이션 구성 요소가 서로 직접 통신하며
즉각적인 응답을 전제로 동작하는 구조

문제점

한 구성 요소의 실패가 전체 시스템 장애로 확산될 수 있다.
트래픽 급증 시 특정 구성 요소가 병목 지점이 된다.
변경이나 확장이 어렵다.

3. 느슨하게 결합된 아키텍처(Loosely Coupled)

개념

구성 요소 사이에 중간 계층(큐 또는 이벤트 버스) 을 두어 직접 의존성을 제거한 구조

효과

생산자와 소비자의 처리 속도를 분리
장애가 발생해도 다른 구성 요소는 정상 동작
확장성과 복원력 향상

4. 메시지·이벤트 기반 통신의 핵심 역할

요청을 즉시 처리하지 못해도 중간에 안전하게 보관
트래픽 급증을 버퍼링하여 시스템 붕괴 방지
각 구성 요소를 독립적으로 확장 가능
비동기 처리 기반 아키텍처 구현

5. AWS 메시징 및 이벤트 통신 서비스 3종

AWS는 느슨하게 결합된 아키텍처를 구현하기 위해 서로 다른 목적의 3가지 서비스를 제공한다.

5-1. Amazon SQS (Simple Queue Service)

개념

메시지를 대기열에 저장하고
소비자가 준비되었을 때 하나씩 처리하는 큐 기반 서비스

특징

메시지 손실 방지
소비자 가용성과 무관하게 메시지 보관
자동 확장 및 높은 신뢰성

처리 흐름

Producer가 메시지를 대기열에 전송
Consumer가 메시지를 수신하여 처리
처리 완료 후 메시지를 삭제

사용 사례

비동기 작업 처리
백엔드 작업 큐
트래픽 급증 시 요청을 안전하게 적재해야 하는 경우

5-2. Amazon SNS (Simple Notification Service)

개념

게시-구독(Pub/Sub) 모델 기반 즉시 알림 서비스
게시자가 주제(Topic)에 메시지를 발행하면 구독자에게 전달

특징

메시지를 대기시키지 않음
여러 구독자에게 동시에 전달(팬아웃)
즉각적인 반응이 필요한 알림에 적합

구독 대상 예

이메일
SMS
모바일 푸시
Lambda 함수
웹 서버

사용 사례

이벤트 알림
사용자 통지
관심사 기반 메시지 배포

5-3. Amazon EventBridge

개념

이벤트 기반 아키텍처(Event-Driven Architecture) 를 위한 서버리스 이벤트 버스
다양한 소스에서 발생한 이벤트를 규칙에 따라 라우팅

특징

이벤트 수신, 필터링, 변환, 전달을 중앙에서 관리
AWS 서비스, 사용자 지정 애플리케이션, 서드파티 SaaS 이벤트 처리 가능
소비자 장애 시 이벤트를 보존 후 재처리

사용 사례

주문 생성, 결제 완료 같은 비즈니스 이벤트 처리
여러 마이크로서비스에 동일 이벤트 전달
서비스 간 느슨한 연결 유지

6. 서비스 간 역할 구분(시험 포인트)

SQS:
메시지를 보관하고 나중에 처리하는 작업 큐
SNS:
메시지를 즉시 여러 대상에게 배포
EventBridge:
이벤트를 규칙 기반으로 라우팅하는 중앙 이벤트 허브

7. 모놀리스 vs 마이크로서비스 관점

모놀리스

구성 요소가 긴밀하게 결합
한 장애가 전체 장애로 확산 가능

마이크로서비스

구성 요소가 느슨하게 결합
메시지/이벤트 기반 통신 활용
장애 격리 및 독립적 확장 가능

8. 확장 가능하고 신뢰할 수 있는 클라우드 통신

SQS → 비동기 처리와 백로그 관리
SNS → 즉시 알림 및 팬아웃
EventBridge → 이벤트 중심 시스템 연결

이 조합을 통해

높은 트래픽 처리
장애 복원력
유연한 서비스 확장이 가능해진다.

9. 시험 대비 선택 감각

“메시지를 잃으면 안 되고, 나중에 처리해도 됨” → SQS
“여러 대상에게 즉시 알림 필요” → SNS
“이벤트를 기준으로 여러 서비스 연결” → EventBridge
“긴밀 결합을 제거하고 장애를 격리하고 싶다” → 메시지/이벤트 기반 설계

AWS의 메시징 및 이벤트 처리에서 SQS는 큐 기반 비동기 처리, SNS는 게시-구독 기반 즉시 알림, EventBridge는 이벤트 중심 아키텍처를 담당하며, 이들은 느슨하게 결합된 확장 가능하고 복원력 있는 시스템을 구현하는 핵심 도구이다.

AWS 기반 컴퓨팅(opens in a new tab)	이 리소스는 AWS에서 제공하는 다양한 클라우드 컴퓨팅 서비스의 개요를 제공합니다.
AWS 컴퓨팅 블로그(opens in a new tab)	이 블로그에서는 Amazon EC2, AWS Lambda, Amazon ECS 등과 같은 AWS 컴퓨팅 서비스를 사용하기 위한 업데이트, 자습서, 모범 사례를 제공합니다.
AWS 컴퓨팅 서비스(opens in a new tab)	이 참조 자료는 AWS 클라우드에서 사용할 수 있는 컴퓨팅 서비스를 심층적으로 소개합니다.
실습 자습서: 컴퓨팅(opens in a new tab)	이 리소스는 사용자가 AWS 컴퓨팅 서비스를 직접 사용해 볼 수 있도록 제작된 실용적인 단계별 자습서를 제공합니다. 이는 초보자 및 클라우드 컴퓨팅을 처음 접하는 사용자에게 적합합니다.
Amazon EC2(opens in a new tab)	Amazon EC2는 유연한 컴퓨팅 용량을 갖춘 클라우드에서 가상 서버를 실행합니다.
Amazon EC2 인스턴스 유형(opens in a new tab)	이 가이드는 사양, 기능, 사용 사례를 비롯하여 다양한 유형의 EC2 인스턴스에 대한 자세한 정보를 제공합니다. 이를 참조하여 컴퓨팅, 메모리, 스토리지 요구 사항 등 워크로드 요구 사항에 따라 적합한 인스턴스 유형을 선택할 수 있습니다.
Amazon EC2 요금(opens in a new tab)	이 가이드에서는 온디맨드, 예약 인스턴스, 스팟 인스턴스를 비롯하여 EC2 인스턴스의 다양한 요금 모델에 대해 설명하므로, 사용량을 기준으로 가장 적합한 옵션을 선택할 수 있습니다.
Amazon EC2 Auto Scaling(opens in a new tab)	Amazon EC2 Auto Scaling은 수요에 따라 인스턴스 수를 자동으로 조정하여 가용성 및 비용 효율성을 높입니다.
Elastic Load Balancing(opens in a new tab)	Elastic Load Balancing은 들어오는 애플리케이션 트래픽을 여러 EC2 인스턴스에 자동으로 분산하여 높은 가용성 및 내결함성을 제공합니다.
Amazon Simple Notification Service(opens in a new tab)	Amazon SNS는 SMS, 이메일 또는 모바일 푸시 알림을 통해 사용자 또는 기타 애플리케이션에 알림을 전송하는 메시징 서비스입니다.
Amazon Simple Queue Service(opens in a new tab)	Amazon SQS는 메시지 대기열 처리, 메시지 저장, 처리를 통해 애플리케이션 구성 요소를 분리합니다.

저작자표시 비영리 동일조건 (새창열림)

'Deployment > Cloud Computing' 카테고리의 다른 글

AWS Cloud Practitioner Essentials (Global) (0)	2026.03.13
AWS Cloud Practitioner Essentials (Exploring) Lambda (0)	2026.02.12
AWS Cloud Practitioner Essentials (Introduction) (0)	2026.02.02
Azure 사용 방법 (0)	2025.10.14
클라우드 컴퓨팅 기술 (1)	2025.10.14

AWS Cloud Practitioner Essentials (Compute) EC2

Amazon EC2 (Elastic Compute Cloud)

1. Amazon EC2란?

2. 클라이언트 / 서버 모델과 EC2

3. 온프레미스(On-Premises) vs EC2

온프레미스의 문제점

EC2 사용 시 이점

4. EC2 인스턴스의 본질: 가상 머신(VM)

멀티테넌시

하이퍼바이저(Hypervisor)

5. EC2 인스턴스 구성 요소

1) AMI (Amazon Machine Image)

2) 인스턴스 유형 (Instance Type)

3) 운영체제 선택

4) 소프트웨어 자유도

6. EC2 연결 방식

대표적인 연결 방법

7. EC2 스케일링

수직적 스케일링 (Vertical Scaling)

8. 네트워킹 제어

9. 비용 모델

EC2 인스턴스 유형(Instance Types)

1) 인스턴스 유형이란?

2) 인스턴스 패밀리 5가지 분류와 쓰임새

A. 범용(General Purpose)

B. 컴퓨팅 최적화(Compute Optimized)

C. 메모리 최적화(Memory Optimized)

D. 가속 컴퓨팅(Accelerated Computing)

E. 스토리지 최적화(Storage Optimized)

3) 인스턴스 ‘크기(Size)’ 선택 포인트

4) 클라우드의 장점: 선택은 ‘고정’이 아니다

5) SAA에서 자주 나오는 선택 요령

AWS API와 서비스 상호 작용 방식

1. 핵심 전제: AWS의 모든 작업은 API 호출이다

2. AWS API를 호출하는 3가지 주요 방법

3. AWS Management Console

개념

장점

단점

권장 대상

4. AWS CLI (Command Line Interface)

개념

특징

예시 개념

CloudShell

권장 대상

5. AWS SDK (Software Development Kit)

개념

특징

사용 예

권장 대상

6. 3가지 방식 비교 요약

7. 자동화의 중요성

8. 공동 책임 모델 (Shared Responsibility Model)

기본 원칙

9. EC2와 공동 책임

AWS EC2 인스턴스 생성과 AMI

1. 핵심 전제: EC2 인스턴스 생성은 구성 요소 선택의 조합이다

2. EC2 인스턴스 생성의 시작: Launch Instance

3. 인스턴스 이름(Name)

4. AMI (Amazon Machine Image) 선택

개념

데모에서 사용한 AMI

AMI의 역할

5. 인스턴스 유형(Instance Type)

개념

데모에서 사용한 유형

핵심 포인트

6. 키 페어(Key Pair)

개념

책임 주체

시험 포인트

7. 네트워크 설정(Network Settings)

데모 설정

의미

핵심 개념

8. 스토리지 설정(Storage)

데모 설정

개념

9. User Data를 통한 초기 설정