[AWS-SAA03 공부법] 알아야 할 서비스

 

 

1. EC2

2. RDS

3. S3

4. EMR

5. Lambda

6. DynamoDB

7. SQS/SNS

8. ElastiCache

9. Kinesis

---

1. EC2 (Elastic Compute Cloud)

EC2는 AWS의 가상 서버 서비스로, 클라우드에서 컴퓨터 한 대를 빌리는 거라 생각하면 쉽다.

인스턴스 타입

t 계열  → 범용, 버스트 가능, 저렴           예) t3.micro
m 계열  → 범용, 안정적인 성능               예) m5.large
c 계열  → 컴퓨팅 최적화 (CPU 집약 작업)     예) c5.xlarge
r 계열  → 메모리 최적화 (DB, 캐시)          예) r5.2xlarge
p/g 계열→ GPU 최적화 (ML, 딥러닝)           예) p3.2xlarge

CPU 집약적인 배치 처리 → c 계열
인메모리 DB, 대용량 캐시 → r 계열

구매 옵션

On-Demand    → 쓴 만큼 지불. 기본값.
Reserved     → 1년 or 3년 약정. 최대 72% 할인.
Spot         → 남는 용량 경매. 최대 90% 할인. 언제든 중단 가능.
Savings Plan → 사용량 기준 약정. Reserved보다 유연함.

중단돼도 괜찮은 배치 작업 → Spot 인스턴스
24/7 운영되는 프로덕션 서버 → Reserved 인스턴스

스토리지

• EBS : EC2에 붙이는 블록 스토리지. 영구 저장. 기본적으로 하나의 EC2에만 연결.
• Instance Store : EC2 내장 임시 스토리지. 인스턴스 종료 시 데이터 삭제.
• EFS : 여러 EC2가 동시에 마운트 가능한 공유 스토리지.

여러 EC2가 같은 파일을 공유해야 한다 → EFS
재시작해도 데이터가 남아야 한다 → EBS

---

2. RDS (Relational Database Service)

RDS는 관계형 DB를 관리형으로 제공하는 서비스다.

패치, 백업, 복제를 AWS가 자동으로 처리해준다.

Multi-AZ vs Read Replica

Multi-AZ
 ├ Primary DB (AZ-a)   ← 실제 읽기/쓰기
 └ Standby DB (AZ-b)   ← 장애 시 자동 전환 대기 (평소엔 트래픽 없음)

Read Replica
 ├ Primary DB          ← 쓰기
 ├ Read Replica 1      ← 읽기 전용
 └ Read Replica 2      ← 읽기 전용

DB 장애 시 자동 복구 → Multi-AZ
읽기 트래픽이 너무 많다 → Read Replica

Aurora

• AWS가 만든 클라우드 네이티브 DB 엔진. MySQL/PostgreSQL 호환.
• 일반 RDS보다 최대 5배(MySQL 기준) 빠르다.
• 스토리지 자동 확장 (최대 128TB).
• 6개 AZ에 걸쳐 6벌 복제를 자동 유지.

고성능 + 고가용성 관계형 DB → Aurora가 거의 정답

---

3. S3 (Simple Storage Service)

S3는 객체 스토리지 서비스다. 용량 제한이 없고 내구성이 99.999999999%다.

스토리지 클래스

Standard          → 자주 접근. 기본값.
Standard-IA       → 가끔 접근. 조회 시 비용 발생.
One Zone-IA       → Standard-IA와 비슷. 단일 AZ. 더 저렴.
Glacier Instant   → 드문 접근. 밀리초 단위 복원.
Glacier Flexible  → 드문 접근. 복원에 수 분~수 시간.
Glacier Deep Archive → 거의 안 씀. 최저 비용. 복원에 최대 12시간.
Intelligent-Tiering  → 접근 패턴 자동 분석해서 클래스 이동.

Lifecycle Policy

생성 후 30일  → Standard-IA로 이동
생성 후 90일  → Glacier로 이동
생성 후 365일 → 삭제

오래된 로그를 자동 아카이빙 → Lifecycle Policy + Glacier
특정 기간만 유효한 임시 접근 URL → Pre-signed URL
S3를 외부에 직접 노출하지 않고 CloudFront로만 접근 → OAC 설정

---

4. Lambda

Lambda는 서버 없이 코드만 실행하는 서버리스 컴퓨팅 서비스다.

서버를 직접 관리할 필요가 없고, 코드가 실행된 시간만큼만 비용을 낸다.

이벤트 발생
    ↓
 Lambda 함수 실행 (코드 실행)
    ↓
 결과 반환 또는 다른 서비스로 전달

Lambda를 트리거하는 이벤트

• S3에 파일 업로드 시
• API Gateway로 HTTP 요청이 들어올 때
• DynamoDB 데이터 변경 시
• CloudWatch 이벤트/일정
• SQS 메시지 수신 시

EC2 vs Lambda

EC2
 ├ 항상 켜져 있음
 ├ 고정 비용 발생
 ├ 서버 관리 필요
 └ 장시간 실행 가능 (제한 없음)

Lambda
 ├ 요청이 있을 때만 실행
 ├ 실행 시간만큼만 비용
 ├ 서버 관리 불필요
 └ 최대 실행 시간 15분

트래픽이 불규칙하고 짧게 실행되는 작업 → Lambda
24/7 돌아야 하는 서버, 15분 이상 실행 → EC2

---

5. DynamoDB

DynamoDB는 AWS의 관리형 NoSQL 데이터베이스다.

키-값(Key-Value) 또는 문서(Document) 형태로 데이터를 저장한다.

DynamoDB
 └ Table
     └ Item (행 하나)
         ├ Partition Key  (필수, 기본 키)
         ├ Sort Key       (선택, 복합 키 구성)
         └ Attributes     (나머지 데이터, 스키마 자유)

RDS vs DynamoDB

RDS
 ├ 관계형 (테이블 간 JOIN 가능)
 ├ 고정 스키마
 ├ 수직 확장 중심
 └ 복잡한 쿼리에 적합

DynamoDB
 ├ NoSQL (JOIN 없음)
 ├ 유연한 스키마
 ├ 자동 수평 확장
 └ 단순 조회, 대규모 트래픽에 적합

테이블 간 JOIN이 필요하다 → RDS
초당 수백만 건의 단순 읽기/쓰기 → DynamoDB
스키마가 자주 바뀐다 → DynamoDB

DynamoDB Streams

테이블의 데이터 변경 이벤트를 실시간으로 캡처하는 기능이다.

Lambda와 연결하면 데이터가 변경될 때 자동으로 함수를 실행시킬 수 있다.

---

6. SQS / SNS

SQS와 SNS는 서비스 간 메시지를 주고받는 방식이다.

서비스 간 직접 연결 대신 메시지를 통해 연결하면 느슨한 결합(디커플링)이 된다.

SQS (Simple Queue Service)

메시지를 큐에 넣어두고, 소비자가 꺼내 처리하는 방식이다.

생산자 (Producer)
    ↓ 메시지 전송
   SQS 큐
    ↓ 메시지 꺼내기
소비자 (Consumer, EC2 / Lambda)

• 메시지는 최대 14일 보관된다.
• 소비자가 처리하기 전까지 메시지가 큐에 남아있다.
• 소비자가 여러 개면 메시지를 나눠서 처리한다 (경쟁 소비).

SNS (Simple Notification Service)

하나의 메시지를 여러 구독자에게 동시에 전달하는 방식이다.

게시자 (Publisher)
    ↓
  SNS Topic
    ├ → SQS 큐
    ├ → Lambda
    ├ → 이메일
    └ → HTTP 엔드포인트

SQS vs SNS

SQS → 1:1. 메시지를 큐에 쌓아두고 하나씩 처리.
SNS → 1:N. 하나의 메시지를 여러 곳에 동시 전달.

주문이 들어오면 결제/배송/알림 서비스 모두에 동시 전달 → SNS
처리 속도가 느린 작업을 큐에 넣고 순서대로 처리 → SQS
"SNS + SQS 팬아웃" : SNS로 뿌리고 각 SQS에서 독립적으로 처리하는 패턴도 자주 나옴

---

7. ElastiCache

ElastiCache는 인메모리 캐시를 관리형으로 제공하는 서비스다.

자주 조회되는 데이터를 메모리에 올려두고 DB 대신 캐시에서 바로 응답한다.

기존 구조
사용자 → 애플리케이션 → RDS (매번 DB 조회)

캐시 적용 후
사용자 → 애플리케이션 → ElastiCache (캐시 히트 시 바로 응답)
                              ↓ 캐시 미스 시
                            RDS

지원 엔진

• Redis : 데이터 영속성 지원. 복제/클러스터링 가능. 더 많은 자료구조 지원. 세션 저장소로도 활용.
• Memcached : 순수 캐시 목적. 멀티스레드. 더 단순한 구조.

세션 데이터, 리더보드, 실시간 데이터 → Redis
단순한 캐싱만 필요하다 → Memcached
"RDS 부하를 줄여야 한다" → ElastiCache가 거의 정답

---

8. EMR (Elastic MapReduce)

EMR은 대용량 데이터를 분산 처리하기 위한 관리형 클러스터 서비스다.

Hadoop, Spark, Hive 같은 빅데이터 프레임워크를 AWS에서 쉽게 실행할 수 있다.

데이터 소스 (S3, DynamoDB, ...)
        ↓
   EMR 클러스터
    ├ Master Node  → 작업 조율
    ├ Core Node    → 데이터 저장 + 처리 (On-Demand 권장)
    └ Task Node    → 처리만 담당 (Spot 인스턴스 활용 가능)
        ↓
   결과 저장 (S3, Redshift, ...)

Task Node는 데이터를 저장하지 않기 때문에 중단돼도 데이터 손실이 없다.
→ Task Node에 Spot 인스턴스를 써서 비용 절감

---

9. Kinesis

Kinesis는 실시간 스트리밍 데이터를 수집하고 처리하는 서비스다.

로그, 클릭스트림, IoT 센서 데이터처럼 계속 흘러들어오는 데이터를 처리할 때 쓴다.

Kinesis 구성 요소

Kinesis Data Streams    → 실시간 데이터 스트림 수집/처리
Kinesis Data Firehose   → 스트림 데이터를 S3/Redshift 등에 자동 적재
Kinesis Data Analytics  → SQL로 스트리밍 데이터 실시간 분석

EMR vs Kinesis

EMR      → 배치 처리. 쌓인 대용량 데이터를 한꺼번에 분석.
Kinesis  → 실시간 처리. 데이터가 들어오는 즉시 처리.

"실시간으로 클릭 로그를 분석해야 한다" → Kinesis
"하루치 로그를 새벽에 한꺼번에 분석한다" → EMR
"스트리밍 데이터를 S3에 자동으로 저장하고 싶다" → Kinesis Firehose

---

마무리

📌 핵심 정리

• EC2 : 가상 서버. 인스턴스 타입 / 구매 옵션 / 스토리지 구분
• RDS : 관리형 관계형 DB. Multi-AZ(고가용성) vs Read Replica(성능)
• S3 : 객체 스토리지. 스토리지 클래스 + Lifecycle Policy
• Lambda : 서버리스. 짧고 이벤트 기반 작업. 최대 15분.
• DynamoDB : NoSQL. 대규모 단순 읽기/쓰기. 유연한 스키마.
• SQS / SNS : 디커플링. SQS는 1:1 큐, SNS는 1:N 발행.
• ElastiCache : 인메모리 캐시. RDS 부하 감소. Redis vs Memcached.
• EMR : 빅데이터 배치 처리. Spark/Hadoop. Task Node에 Spot 활용.
• Kinesis : 실시간 스트리밍. Streams/Firehose/Analytics 구분.

SAA 시험은 서비스를 외우는 게 아니라
"이 상황에서 왜 이 서비스인가"를 이해하는 게 핵심이다.
기본 지식 편이랑 같이 보면서 전체 구조를 잡고 나서 문제를 풀어보자.