AWS 개념 정리

Kjjedd·2026년 1월 22일

CS

목록 보기

2/3

☁️ AWS 개념 정리 스크립트

0. AWS 글로벌 인프라 구조 (Region · AZ · Data Center)

🌍 Region (리전)

지리적으로 분리된 AWS의 물리적 위치

서울(ap-northeast-2)
도쿄(ap-northeast-1)
버지니아(us-east-1)

리전 간에는 다음과 같은 특징이 있다.

물리적으로 매우 멀리 떨어져 있음
지연 시간(Latency) 큼
장애가 서로 전파되지 않음

👉 나라/도시 단위의 개념

🏗️ Availability Zone (AZ, 가용 영역)

AZ는 리전 안에 존재하는 물리적으로 완전히 분리된 인프라 묶음이다.

각 리전은 2개 이상(보통 3개 이상)의 AZ로 구성
전원, 냉각, 네트워크 완전 분리
초고속·저지연 전용 네트워크로 서로 연결

 Region (서울) 
  ├─ AZ-a 
  ├─ AZ-b 
  └─ AZ-c

👉 AWS에서 장애 격리의 최소 단위

🏢 Data Center (데이터 센터)

데이터 센터는 실제 서버와 네트워크 장비가 들어 있는 물리적 건물이다.

AWS의 공식 설명은 다음과 같다.

“Each Availability Zone consists of one or more discrete data centers.”

하나의 AZ는 하나 이상의 데이터 센터로 구성
데이터 센터의 정확한 위치·개수는 비공개

👉 사용자는 데이터 센터를 직접 다루지 않는다.

🔗 관계 정리

 AWS Global 
  └─ Region 
  └─ Availability Zone (AZ) 
  └─ Data Center (1개 이상)

1. VPC (Virtual Private Cloud)

VPC는 AWS 안에 만드는 나만의 가상 사설 네트워크다. (Region 단위로 생성됨)

IP 대역 직접 설계 (CIDR)
완전히 격리된 네트워크
모든 AWS 네트워크의 시작점

AWS Cloud
 └─ VPC (10.0.0.0/16)

👉 현실의 사내 네트워크(LAN)와 동일한 개념

VPC 총정리

1️⃣ 기본 네트워크 구성 요소

구성요소	핵심 개념	중요 포인트
CIDR	IP 주소 범위 정의	VPC 및 Subnet의 IP 공간을 결정 (IPv4 / IPv6)
VPC	가상 사설 클라우드	IPv4 & IPv6 CIDR 블록 정의, AWS 네트워크 격리 단위
Subnet	VPC 내 AZ 단위 네트워크	Public / Private Subnet 구분
Route Table	트래픽 흐름 제어	IGW, NAT, Peering, Endpoint 등 경로 지정
Internet Gateway (IGW)	VPC ↔ 인터넷 연결	Public Subnet에서 사용, 양방향 통신 가능
Egress-only IGW	IPv6 전용 아웃바운드 인터넷	IPv6 환경에서 인터넷이 먼저 연결하지 못하도록 차단

2️⃣ 인터넷 접근 관련 구성

구성요소	설명	비고
Bastion Host	Public Subnet에서 Private EC2로 SSH 접속	보안 게이트 역할
NAT Instance	Private Subnet 인터넷 접근	현재는 거의 사용하지 않음
NAT Gateway	AWS 관리형 NAT	IPv4 전용, Private Subnet 아웃바운드 인터넷

3️⃣ 보안 및 제어 계층

구성요소	레벨	특징
Security Group	인스턴스 레벨	Stateful (인바운드 허용 시 아웃바운드 자동 허용)
NACL	Subnet 레벨	Stateless (인/아웃바운드 각각 명시 필요)
Reachability Analyzer	네트워크 디버깅	AWS 리소스 간 연결성 분석
VPC Flow Logs	네트워크 로그	ACCEPT/REJECT 트래픽 메타데이터 기록 (VPC/서브넷/ENI 단위)
Traffic Mirroring	패킷 복제	ENI 트래픽을 IDS/보안 장비로 전달

4️⃣ DNS 및 내부 통신

구성요소	설명
Private DNS + Route 53	VPC 내부 DNS 해석 가능 (enable DNS resolution / hostname 필요)

5️⃣ VPC 간 연결

구성요소	특징	제한
VPC Peering	두 VPC 직접 연결	Transitive 불가, CIDR 겹치면 불가
Transit Gateway	허브 앤 스포크 구조	Transitive Routing 지원

6️⃣ AWS 서비스에 대한 사설 접근

구성요소	설명
VPC Endpoint	인터넷 없이 AWS 서비스 접근
Gateway Endpoint	S3, DynamoDB 전용
Interface Endpoint	그 외 AWS 서비스 (ENI 기반)
AWS PrivateLink	타 VPC 서비스에 사설 연결 제공 (NLB 기반)
VPC Endpoint Services	자체 서비스를 다른 VPC에 비공개로 노출

7️⃣ 온프레미스 연결

구성요소	설명	특징
Site-to-Site VPN	IPsec 기반 VPN	VGW + Customer Gateway 필요
AWS VPN CloudHub	VGW 기반 허브앤스포크 VPN 연결	여러 VPN 연결 가능
Direct Connect (DX)	전용 물리 회선 연결	고성능, 구축 리드타임 길음
Direct Connect Gateway	여러 리전 VPC에 DX 확장	DX 연결 허브
Transit Gateway	VPN + DX + VPC 통합 허브	전이적 연결 가능

8️⃣ VPN 처리량 확장

구성	처리량
VPN → VGW	1.25 Gbps (Active/Standby)
VPN → TGW (ECMP)	2.5 Gbps 이상 확장 가능

ECMP (Equal-Cost Multi-Path) 사용 시 VPN 터널을 동시에 활용하여 대역폭 선형 확장 가능.

9️⃣ 기타

ClassicLink → EC2-Classic과 VPC 연결 (현재는 거의 사용 종료)
멀티 계정 간 TGW 공유 가능 (RAM 사용)
IPv6 환경에서는 NAT 대신 Egress-only IGW 사용

🎯 전체 구조

VPC
 ├─ Subnet (Public / Private)
 ├─ Route Table
 ├─ IGW / NAT / Egress-only IGW
 ├─ Security Group / NACL
 ├─ VPC Peering / TGW
 ├─ VPC Endpoint / PrivateLink
 ├─ Flow Logs / Traffic Mirroring
 └─ VPN / DX / DXGW

2. 서브넷 (Subnet)

서브넷은 VPC를 더 작은 네트워크 단위로 나눈 것

하나의 AZ에만 속함
리소스 배치 단위

VPC
 ├─ Subnet A (AZ-a)
 └─ Subnet B (AZ-b)

CIDR 10.0.0.0/24의 예약된 ip주소

10.0.0.0 - 네트워크 주소
10.0.0.1 - AWS가 VPC 라우터를 위해 예약해놓음
10.0.0.2 - AWS에서 제공하는 DNS에 매핑
10.0.0.3 - 나중에 사용할지도 몰라서 예약
10.0.0.255 - 네트워크 브로드캐스트 주소 .255
네트워크 브로드캐스트는 지원하지 않아 예약되어있지만 사용 불가함

3. 퍼블릭 서브넷 / 프라이빗 서브넷

🌍 퍼블릭 서브넷

Internet Gateway 연결
인터넷에서 접근 가능

🔒 프라이빗 서브넷

인터넷 직접 접근 불가
보안 영역 (DB, 내부 서버)

Internet
   │
[IGW]
   │
[Public Subnet] ── ALB, Bastion
[Private Subnet] ── EC2, RDS

👉 프라이빗 = “외부 차단” ❌ / “인터넷 차단” ⭕

4. Internet Gateway (IGW)

VPC와 인터넷을 연결하는 관문

퍼블릭 서브넷 필수
인터넷 통신의 출입구

👉 e.g., 회사 정문

5. NAT Gateway / NAT Instance

📌 NAT (Network Address Translation)

NAT = IP 주소를 변환하는 기술

💡 핵심 개념

사설 IP → 공인 IP로 변환
외부와 통신 가능하게 만들어줌
IP 주소 부족 문제 해결

📊 동작 방식

[Private EC2] (10.0.0.1)
        ↓
    [NAT 변환]
        ↓
[Public IP] (52.10.1.1)
        ↓
      인터넷

✅ 특징

IP 주소만 변환
1:1 매핑 구조
단순 주소 변환 기술

📦 예시

10.0.0.1 → 52.10.1.1

📌 PAT (Port Address Translation)

PAT = IP + PORT를 함께 변환하는 기술

💡 왜 필요할까?

여러 개의 Private 서버가 하나의 Public IP를 공유해야 하기 때문

📊 동작 방식

10.0.0.1:5000 → 52.10.1.1:30001
10.0.0.2:5000 → 52.10.1.1:30002

✅ 특징

N:1 구조
포트 번호로 구분
대부분의 NAT 환경에서 사용됨

📌 NAT Gateway (AWS 서비스)

NAT Gateway = AWS에서 제공하는 NAT 장비 (PAT 기반)

💡 한 줄 정의

프라이빗 서브넷의 EC2가 인터넷으로 나갈 수 있게 해주는 서비스 (Inbound 차단)

📊 구조

[Private EC2]
     ↓
[NAT Gateway (Public Subnet)]
     ↓
[Internet Gateway]
     ↓
   인터넷

⚙️ 동작 원리

✔ 나갈 때 (Outbound)

10.10.2.121:40000 → 3.35.100.1:55001

✔ 응답 (Response)

3.35.100.1:55001 → 10.10.2.121

❌ 외부에서 먼저 접근

인터넷 → NAT Gateway → Private EC2
→ 차단됨

📌 특징

Outbound Only (나가기 전용)
Stateful (요청한 것만 응답 허용)
퍼블릭 서브넷에 위치
Elastic IP 필요

📊 NAT vs NAT Gateway 비교

구분	NAT	NAT Gateway
개념	기술	AWS 서비스
역할	IP 변환	인터넷 출구
방식	NAT / PAT	PAT
Inbound	가능	불가능
사용 위치	네트워크 전반	AWS VPC

✅ 정리

NAT = IP 변환 기술
PAT = IP + PORT 변환 기술
NAT Gateway = AWS에서 제공하는 PAT 기반 서비스
프라이빗 EC2 → 인터넷 통신 가능
외부 → 프라이빗 EC2 접근은 차단

6. Route Table

라우팅 테이블은 트래픽의 길 안내서다.

Destination → Target
서브넷 단위로 연결

0.0.0.0/0 → IGW
10.0.0.0/16 → local

7. Security Group

Security Group은 인스턴스 단위 방화벽이다.

Stateful - Inbound만 열어줘도 Outbound 응답은 자동 통과함 (연결 상태를 기억함)
Allow 규칙만 존재 - 허용 규칙에 없으면 자동으로 차단됨 (암묵적 차단)

👉 서버 앞 개인 경호원

8. NACL (Network ACL)

서브넷 단위 방화벽

Stateless - 요청과 응답을 별개로 본다
Allow / Deny 모두 가능 - 명시적 차단

Internet
 │
[NACL]
 │
[Security Group]
 │
[EC2]

구분	Security Group	NACL
상태 기억	⭕ Stateful	❌ Stateless
응답 트래픽	자동 허용	명시적 허용 필요
규칙 작성	Allow 규칙만 존재	Allow / Deny 규칙 모두 가능
규칙 순서	순서 개념 없음	번호 순서대로 평가
적용 단위	인스턴스 단위	서브넷 단위

9. Elastic IP (EIP)

고정 퍼블릭 IP

인스턴스 재시작에도 유지
NAT, Bastion에 자주 사용

10. VPC Peering

두 VPC를 직접 연결하는 방식
다양한 리전에서 VPC를 만들어 AWS 네트워크를 통해 연결하고 싶을 때 사용한다.

👉 VPC 서브넷 상의 라우터 테이블 또한 업데이트해서 인스턴스가 서로 통신할 수 있게 함.

사설 통신
트랜짓 불가

VPC A ─── VPC B

💫 VPC Peering vs. VPN

구분	VPC Peering	Site-to-Site VPN
연결 대상	AWS VPC ↔ AWS VPC	온프레미스 ↔ AWS VPC
네트워크 경로	AWS 백본망	인터넷
암호화	기본 ❌	IPsec ⭕
지연/성능	낮음 (고성능)	인터넷 품질 의존
하이브리드 지원	❌	⭕
주요 사용 사례	AWS 내부 VPC 연결	하이브리드 클라우드 구성

🎯 요약

VPC Peering = AWS 내부 VPC 간 고속 연결
Site-to-Site VPN = 온프레미스와 AWS를 암호화 터널로 연결

11. VPN (Site-to-Site VPN)

<Site-to-Site VPN은 인터넷 위에 IPsec 기반 암호화 터널을 생성하여 온프레미스 네트워크와 AWS VPC를 연결하는 방식이다.

온프레미스 ↔ AWS VPC 연결
인터넷 기반 (Public Internet 사용)
IPsec 암호화 (IKEv1 / IKEv2)
기본적으로 2개의 터널 제공 (High Availability)

📌 동작 구조

On-Prem Router (Customer Gateway Device)
        │
   (IPsec Tunnel 1)
   (IPsec Tunnel 2)
        │
Virtual Private Gateway (VGW)
        │
       VPC

터널은 인터넷을 통해 연결된다.
AWS는 기본적으로 2개의 VPN 터널을 제공하여 장애 대비(Fault Tolerant)를 구현한다.
한 터널 장애 시 자동 Failover 가능 (BGP 사용 시 자동 경로 전환)

📌 Static Routing vs Dynamic Routing

Static Routing : CIDR 수동 입력
BGP (Dynamic Routing) : 경로 자동 전파 (권장)

특히 여러 지점을 연결하는 VPN CloudHub 구조에서는 반드시 BGP가 필요하다.

📌 Route Propagation

VPN 터널만 생성하면 끝이 아니다.

VPC Route Table에서 Route Propagation 활성화 필요
On-Prem CIDR이 자동으로 VGW 타겟으로 등록됨

Destination: 192.168.10.0/24
Target: VGW

Route Propagation을 활성화하지 않으면 통신 불가.

📌 보안 정책 고려사항

Security Group에서 ICMP 허용해야 Ping 가능
NACL은 Stateless이므로 Inbound/Outbound 모두 허용 필요
SG는 Stateful이므로 요청만 허용하면 응답은 자동 허용

📌 VPN CloudHub

하나의 VGW에 여러 VPN 연결을 붙여 Hub-and-Spoke 구조 구성 가능

Site A ─┐
Site B ─┼── VGW ── VPC
Site C ─┘

여러 온프레미스 지점 간 통신 가능
저비용 구조
반드시 BGP 필요

12. VGW + CGW (Virtual Private Gateway & Customer Gateway)

VGW와 CGW는 “VPN을 수행하기 위한 양 끝단(종단점)”이다.
둘 다 VPN 연결을 구성하는 구성요소이며, 각각 AWS 쪽과 온프레미스 쪽 게이트웨이다.

📌 CGW (Customer Gateway)

온프레미스 측 VPN 장비를 AWS에 논리적으로 등록한 객체

공인 IP 주소 필요
NAT 뒤에 있다면 NAT의 Public IP 입력 (NAT-T 필요)
IPsec 종단 장비 (방화벽/라우터 등)

📌 VGW (Virtual Private Gateway)

VPC에 Attach되는 AWS 측 VPN 종착점

VPC에 직접 Attach
암호화 기능 없음 (터널 종착점 역할)
Route Propagation 기능 제공

📌 구조 요약

On-Prem Network
        │
  [Customer Gateway]
        │
   (IPsec VPN Tunnel)
        │
[Virtual Private Gateway]
        │
         VPC

구분	VPN	CGW	VGW
개념	암호화 터널	온프레미스 VPN 장비	AWS 측 종착지
위치	인터넷 상	On-Prem	AWS VPC
Public IP 필요	-	⭕ (필수)	❌
VPC Attach	❌	❌	⭕
암호화 수행	IPsec	IPsec	종단점
Route Propagation	❌	❌	⭕

✅ 정리

VPN은 통로
CGW는 온프레미스 쪽 입구
VGW는 AWS 쪽 입구
Route Propagation 없으면 통신 불가
BGP 사용 시 자동 경로 교환 및 Failover 가능
기본 2개 터널로 Fault Tolerant 구조 제공

13. Direct Connect & Transit Gateway (DX, DXGW, TGW 정리)

1️⃣ Direct Connect (DX)

온프레미스 ↔ AWS 간 전용 프라이빗 연결
퍼블릭 인터넷 미사용
대용량 트래픽 전송에 적합

DX를 사용하려면 AWS Direct Connect Location에서 물리 회선을 개설해야 하며, VPC와 연결하려면 Virtual Private Gateway(VGW) 또는 Transit Gateway(TGW)가 필요하다.

On-Prem
   │
Direct Connect (물리 전용 회선)
   │
DX Location
   │
VGW or TGW
   │
VPC

2️⃣ Virtual Interface (VIF)

DX 연결 후 실제 트래픽을 전달하기 위해 VIF(가상 인터페이스)를 생성한다.

Private VIF → VPC 내부 프라이빗 리소스 접근
Public VIF → S3 등 AWS 퍼블릭 서비스 접근
Transit VIF → Direct Connect Gateway + Transit Gateway 연결 시 사용

VIF를 통해 콘솔과 동일한 방식으로 S3, EC2 등의 리소스에 접근 가능하다. 모든 연결은 전용 회선을 통해 비공개로 전달된다.

3️⃣ Direct Connect 사용 사례

대역폭 처리량 증가 (대규모 데이터셋 전송)
인터넷 장애 시에도 안정적인 연결 유지
하이브리드 아키텍처 구성 (온프레미스 + AWS)

퍼블릭 인터넷을 통하지 않기 때문에 장기적으로는 데이터 전송 비용 절감 효과가 있다.

4️⃣ Direct Connect Connection Types

Dedicated Connection

1Gbps ~ 10Gbps
AWS에서 물리적 전용 포트 제공
높은 비용

Hosted Connection

50Mbps ~ 10Gbps 이상
AWS 파트너를 통해 제공
유연한 용량 확장 가능

❗️리드타임이 길 수 있음 (설치까지 한 달 이상 소요 가능)
→ 일주일 내 빠른 연결이 필요한 경우 적합하지 않음

5️⃣ Direct Connect 암호화

DX 자체는 암호화 기능 없음
물리적 사설 회선으로 보안 유지
암호화 필요 시 DX + Site-to-Site VPN (IPsec)

On-Prem
   │
IPsec VPN
   │
Direct Connect
   │
AWS

보안 수준은 높아지지만 구성 복잡도가 증가한다.

6️⃣ Direct Connect Gateway (DXGW)

하나의 DX 연결로 여러 리전의 VPC를 연결하려면 Direct Connect Gateway가 필요하다.

On-Prem
   │
Direct Connect
   │
DX Gateway
   │
VPC (Region A)
   │
VPC (Region B)

DXGW는 여러 리전의 VPC와 연결을 확장해주는 허브 역할을 수행한다.

7️⃣ Direct Connect 복원력 (Resiliency)

High Resiliency

여러 DX Location 사용
하나 장애 시 다른 경로 유지

Maximum Resiliency

각 DX Location에 독립 연결 2개 구성
완전한 이중화 구조

VPN 백업 구성

DX 장애 시 Site-to-Site VPN으로 자동 전환
퍼블릭 인터넷 경유

8️⃣ Transit Gateway (TGW)

VPN과 DX로 여러 VPC를 연결하다 보면 구조가 급격히 복잡해진다.
Transit Gateway는 이러한 문제를 해결하기 위한 중앙 허브이다.

           Transit Gateway
        /        |         \
     VPC1      VPC2      VPC3
        \
        DX / VPN

허브 앤 스포크 구조
전이적 라우팅 가능 (Transitive Routing)
수천 개 VPC 확장 가능
리전 간 TGW 피어링 가능
계정 간 공유 가능 (RAM)
AWS 유일의 IP Multicast 지원

TGW에 DX Gateway를 연결하면 하나의 DX로 여러 VPC와 연결 가능하다.

9️⃣ TGW Route Table

TGW는 자체 라우팅 테이블을 가진다. 어떤 VPC가 누구와 통신할지 중앙에서 제어할 수 있다.

보안 세그먼트 분리 가능
Prod ↔ On-Prem 허용
Dev ↔ On-Prem 차단

🔟 Site-to-Site VPN 대역폭 확장 (ECMP)

ECMP (Equal-Cost Multi-Path)는 동일 비용 경로를 동시에 사용하는 라우팅 방식이다.

여러 VPN 연결을 동시에 사용
대역폭 선형 확장

VGW 연결 시

1 VPN = 1 VPC
최대 1.25Gbps
터널 2개지만 Active/Standby

TGW 연결 시

1 VPN → 여러 VPC 전이적 연결
2개 터널 동시 사용 (2.5Gbps)
VPN 추가 시 5Gbps, 7.5Gbps 확장 가능

❗️ ECMP는 Transit Gateway에서만 지원함

1️⃣1️⃣ 다중 계정 간 DX 연결

Transit Gateway에 DX Gateway를 연결하면 다중 계정 환경에서도 동일 구조 유지 가능하다.

On-Prem
   │
Direct Connect
   │
DX Gateway
   │
Transit Gateway
   │
Multi-Account VPCs

🎯 정리

Direct Connect → 전용 물리 회선 기반 안정적 연결
DX Gateway → 여러 리전 VPC 확장
Transit Gateway → 중앙 허브 및 전이적 라우팅
ECMP → VPN 대역폭 확장

대규모 엔터프라이즈 환경에서는 DX + DXGW + TGW 조합이 가장 일반적인 하이브리드 아키텍처 패턴이다.

14. CloudFront (CDN)

글로벌 CDN 서비스

CDN(Content Delivery Network)은
사용자와 원본 서버(Origin) 사이에 전 세계적으로 분산된 캐시 서버를 두는 구조다.

① Edge Server (Edge Location)

전 세계에 분산된 캐시 서버
사용자 요청의 첫 도착 지점

👉 “사용자와 가장 가까운 서버”

② Origin Server

실제 원본 데이터가 있는 서버

웹 서버
스토리지
API 서버

User (한국)
 │
[Edge Server - 서울]
 │
[Origin Server]

엣지 캐시
보안 강화

③ CloudFront의 핵심 동작 방식

CloudFront는 일반적인 DNS 요청과 유사한 흐름으로 동작한다.

요청이 Edge에 캐싱되어 있다면 → 즉시 반환
캐싱되어 있지 않다면 → Origin으로 요청
Origin 응답을 Edge에 저장 → 이후 요청은 캐시에서 제공

👉 최초 요청만 Origin까지 가고, 이후는 Edge에서 처리된다.

④ Origin (원본) 제공 방식

1) S3 Bucket

정적 파일 배포에 가장 많이 사용
CloudFront를 통해 전 세계 분산 캐싱
버킷을 Private으로 유지 가능
OAC(Origin Access Control)로 직접 접근 차단

CloudFront는 S3와 AWS 내부 사설망을 통해 통신한다.

2) Custom Origin (HTTP)

ALB
EC2
S3 Static Website Endpoint
기타 HTTP 서버

HTTP 기반이라면 대부분 원본으로 설정 가능하다.

⑤ 보안 구조

Origin을 Public으로 열 필요 없음 (S3 + OAC)
DDoS 보호 (AWS Shield 기본 포함)
HTTPS 통신 지원

👉 CloudFront는 단순 캐시가 아니라 보안 레이어 역할도 한다.

⑥ 지리적 제한 (Geo Restriction)

사용자 국가 기반으로 접근을 제어할 수 있다.

특정 국가 허용
특정 국가 차단

저작권, 지역 라이선스 제한 시 활용된다.

⑦ Price Class

모든 엣지를 사용하면 비용이 증가한다.

Price Class All → 전 세계 전체 엣지
Price Class 200 → 고비용 지역 일부 제외
Price Class 100 → 저비용 지역만 사용

👉 성능과 비용의 트레이드오프 선택

⑧ Cache Invalidation (캐시 무효화)

Origin이 업데이트되어도 캐시는 TTL 동안 유지된다.

TTL 만료 전까지는 기존 캐시 제공
강제로 캐시 삭제 가능 (Invalidation)
특정 파일 또는 전체 경로 지정 가능

👉 “즉시 최신 콘텐츠 반영”이 필요할 때 사용

⑨ CloudFront vs S3 Cross Region Replication

CloudFront

전 세계 엣지 캐시
TTL 기반 캐싱
정적 콘텐츠 글로벌 배포

S3 CRR

리전 간 복제
거의 실시간 동기화
캐시 아님, 실제 데이터 복제

👉 CloudFront는 캐시, CRR은 데이터 복제

⑩ Global Accelerator와의 차이

CloudFront

L7 (HTTP/HTTPS)
캐싱 가능
엣지에서 응답 반환

Global Accelerator

L4 (TCP/UDP)
캐싱 없음
엣지에서 백엔드로 프록시 전달
고정 Anycast IP 제공

👉 CloudFront는 콘텐츠 최적화,
👉 Global Accelerator는 네트워크 경로 최적화

15. DNS (Route 53)

Route 53은 DNS 서비스다.

도메인 → IP 변환
헬스체크

Route 53 개요

Amazon Route 53 은 고가용성과 확장성을 갖춘 완전 관리형 DNS 서비스다.

도메인 이름 → IP 주소 변환
트래픽 라우팅 제어
리소스 상태 확인(Health Check)

“권한 있는(Authoritative) DNS 서비스”라는 말은
👉 해당 도메인에 대한 DNS 응답을 최종적으로 결정한다는 의미다.

또한 Route 53은 다음 기능을 함께 제공한다.

도메인 Registrar 기능 (도메인 직접 구매 가능)
AWS 리소스 상태 기반 라우팅
100% SLA 가용성을 제공하는 유일한 AWS 서비스

숫자 53은 DNS에서 사용하는 전통적인 포트 번호(UDP/TCP 53)에서 유래했다.

Route 53 Records

특정 도메인으로 들어온 요청을 어디로 보낼지 정의하는 규칙

"이 도메인은 어디로 가야 하는가?”를 저장하는 데이터베이스 (i.e., DNS)에 저장된 한 줄의 규칙 "도메인에 대한 매핑 정보"

www.example.com → 192.168.0.10

각 레코드는 다음 요소들로 구성된다.

도메인 이름 (example.com, www.example.com)
레코드 타입 (A, AAAA, CNAME 등)
레코드 값 (IP 주소 또는 다른 도메인)
라우팅 정책
TTL (캐시 유지 시간)

📌 주요 Record Type

타입	설명
A	호스트 이름 → IPv4 주소 매핑
AAAA	호스트 이름 → IPv6 주소 매핑
CNAME	호스트 이름 → 다른 호스트 이름 매핑
NS	호스팅 존의 네임서버 지정

(고급 타입) CAA / DS / MX / NAPTR / PTR / SOA / TXT / SPF / SRV

📌 CNAME의 핵심 제약

CNAME은 호스트 이름을 다른 호스트 이름으로 매핑한다.

A 또는 AAAA 레코드로 최종 해석됨
DNS 네임스페이스의 탑 노드에는 생성 불가

즉,

❌ example.com → CNAME 불가
⭕ www.example.com → CNAME 가능

👉 루트 도메인에는 CNAME을 쓸 수 없다!

📌 Alias Record가 필요한 이유 (왜 일반 CNAME이 아닌가?)

Alias Record는 단순히 “편의 기능”이 아니라, AWS 리소스 특성과 DNS 한계를 동시에 해결하기 위해 등장한 Route 53 고유 기능이다.

기본적인 DNS 규칙에서는 루트 도메인(apex domain)에 CNAME 레코드를 사용할 수 없다. 예를 들어 example.com 자체를 다른 도메인으로 연결하는 것은 표준 DNS에서는 금지되어 있다.

하지만 실제 서비스 환경에서는 다음과 같은 요구가 매우 흔하다.

example.com → ALB로 연결
example.com → CloudFront로 연결
example.com → API Gateway 엔드포인트로 연결

이 문제를 해결하기 위해 Route 53은 Alias Record를 제공한다. Alias는 내부적으로는 A/AAAA 레코드처럼 동작하지만, 실제로는 AWS 리소스를 가리키는 논리적 포인터 역할을 한다.

📌 Alias Record의 핵심 동작 방식

Alias Record는 DNS 응답 시 다음 과정을 거친다.

클라이언트가 도메인에 대한 DNS 질의를 전송
Route 53이 Alias 대상 AWS 리소스를 확인
해당 리소스의 실제 IP 주소를 내부적으로 조회
클라이언트에게는 A / AAAA 레코드 형태로 IP를 응답

즉, 클라이언트 입장에서는 CNAME을 받은 것이 아니라
일반 A 레코드를 받은 것처럼 보이기 때문에 루트 도메인에서도 문제없이 동작한다.

📌 Alias vs CNAME 비교 정리

구분	Alias Record	CNAME Record
루트 도메인 사용	⭕ 가능	❌ 불가능
AWS 리소스 연결	⭕ 최적화됨	⚠ 가능하지만 비권장
요금	⭕ 무료	❌ 일반 DNS 쿼리 비용
IP 변경 대응	⭕ 자동	❌ 수동 관리 필요
TTL 설정	❌ Route 53이 관리	⭕ 사용자가 설정

📌 왜 EC2 퍼블릭 DNS는 Alias 대상이 될 수 없을까?

EC2 인스턴스의 퍼블릭 DNS 이름은 다음과 같은 특징을 가진다.

인스턴스 재시작 시 변경될 수 있음
AWS가 “안정적인 엔드포인트”로 보장하지 않음
단일 인스턴스 단위의 리소스

Alias Record는 IP 변경 가능성을 AWS가 직접 관리할 수 있는 리소스만 대상으로 허용한다.

따라서 EC2를 직접 Alias로 연결하는 대신,

ALB/NLB 뒤에 EC2를 배치하거나
Elastic Beanstalk 환경을 사용하거나
Auto Scaling Group + Load Balancer 구조로 감싸는 방식

이런 구조를 통해 Alias → 안정적인 AWS 엔드포인트라는 원칙을 지켜야 한다.

Hosted Zones

DNS 레코드들의 컨테이너

즉, 특정 도메인 및 서브도메인으로 들어오는 트래픽을 어떻게 라우팅할지 정의하는 공간이다.

🌐 Public Hosted Zone

인터넷에 공개된 도메인
전 세계 어디서든 DNS 조회 가능

👉 일반적인 웹 서비스용

🔒 Private Hosted Zone

특정 VPC 내부에서만 사용 가능
외부 인터넷에서는 접근 불가

예:

사내 내부 API
내부 관리용 URL

👉 회사 네트워크 내부 전용 DNS

💰 호스팅 존은 종류와 관계없이 월 $0.50 비용이 발생함

Route 53 TTL (Time To Live)

TTL은
DNS 응답을 클라이언트 또는 리졸버가 캐싱하는 시간이다.

TTL 동안에는 Route 53에 다시 묻지 않고 캐시된 IP로 직접 서버에 접근한다.

⏱ High TTL (예: 24시간)

Route 53 트래픽 감소
비용 절감
DNS 변경 반영이 느림

⚡ Low TTL (예: 60초)

변경 사항 빠르게 반영
Route 53 요청 증가 → 비용 증가

TTL은 Alias 레코드를 제외한 모든 레코드에서 필수다.

📌 Routing Policies란 ?

Route 53의 Routing Policy는 흔히 말하는 네트워크 라우팅과는 완전히 다른 개념이다.

Route 53은 트래픽을 “전송”하지 않는다.
Route 53은 오직 DNS 쿼리에 대해 “어떤 IP(엔드포인트)를 응답할지”만 결정한다.

즉, 실제 HTTP/HTTPS 트래픽의 흐름은 로드 밸런서, 네트워크, 애플리케이션 계층에서 처리되며, Route 53은 그 이전 단계에서 이름 → 엔드포인트 변환 규칙만 정의한다.

📌 Route 53이 지원하는 Routing Policies

Simple – 단일 응답
Weighted – 가중치 기반
Failover – 장애 조치
Latency-based – 지연 시간 기반
Geolocation – 사용자 위치 기반
Geoproximity – 리소스 근접도 기반
Multi-Value Answer – 다중 정상 응답

각 정책은 “언제, 어떤 상황에서 어떤 엔드포인트를 응답할 것인가”에 대한 전략 차이다.

✅ Simple Routing Policy

가장 기본적인 DNS 동작 방식

하나의 레코드 → 하나 또는 여러 개의 값
여러 값이 있으면 클라이언트는 랜덤으로 하나를 선택
Health Check 사용 불가

Alias 레코드를 사용하는 경우에는 반드시 하나의 AWS 리소스만 지정할 수 있다.

Simple Routing은 구조가 단순한 만큼, 장애 제어·트래픽 제어에는 적합하지 않다.

✅ Weighted Routing Policy

DNS 단계에서 트래픽 비율을 조절할 수 있는 정책

모든 레코드는 동일한 이름과 타입을 가져야 함
가중치 비율에 따라 응답 확률이 결정됨
Health Check와 함께 사용 가능

가중치가 0이면 해당 리소스로는 DNS 응답이 가지 않는다.

대표적인 사용 사례:

새 애플리케이션 버전 Canary 배포
리전 간 점진적 트래픽 이동
프로덕션 영향 최소화 테스트

⚠️ 주의할 점: 모든 레코드의 가중치가 0이면, Route 53은 이를 동일 가중치로 간주한다.

✅ Latency-based Routing Policy

사용자와 가장 빠르게 연결 가능한 AWS 리전으로 응답을 돌려준다.

여기서 말하는 “가까움”은 지리적 거리가 아니라, AWS가 측정한 실제 네트워크 지연 시간이다.

따라서 물리적으로 가까워 보여도, 네트워크 경로상 지연이 크다면 다른 리전으로 연결될 수 있다.

글로벌 서비스를 운영할 때 사용자 체감 속도 최적화에 매우 적합하다.

✅ Geolocation Routing Policy

사용자의 실제 위치(국가/대륙/미국 주)를 기준으로 다른 엔드포인트를 응답하는 정책이다.

라이선스/배포 권한 제한 처리
국가별 콘텐츠 분리
지역별 법적 요구사항 대응

예:

한국 → ap-northeast-2 ALB
미국 → us-east-1 ALB
유럽 → eu-west-1 ALB

특정 위치에 매칭되지 않는 경우를 대비해 기본(Default) 레코드를 반드시 설정해야 한다.

👉 “지역별 권한이 다를 때” 사용한다.

✅ Geoproximity Routing Policy

리소스의 지리적 위치를 기준으로 트래픽을 분배하는 정책이다.

Geolocation과 달리, 사용자 위치가 아니라 리소스 근접도 기준이다.

Bias(가중 편향값) 설정 가능
특정 리전에 더 많은 트래픽 유도 가능
Route 53 Traffic Flow 필요

예: 서울 리전에 +20 Bias → 더 넓은 영역의 트래픽을 서울로 유도

👉 특정 리전으로 의도적으로 트래픽을 끌어오고 싶을 때 사용한다.

✅ Failover Routing Policy

Primary / Secondary 구조로 장애 발생 시 자동 전환하는 정책이다.

Health Check 필수
Primary 실패 시 Secondary 응답

재해 복구(DR) 시나리오에 사용된다.

Primary (us-east-1)
    │
    ▼ 장애 발생
Secondary (us-west-2)

✅ Multi-Value Answer Routing Policy

여러 정상 엔드포인트를 동시에 반환하며, 비정상 리소스는 자동 제외한다.

Health Check 지원
간단한 DNS 레벨 로드 밸런싱 효과
ALB 없이도 기본 분산 가능

Simple Routing과 달리 비정상 엔드포인트는 응답에서 제거된다.

📌 핵심 비교 정리

정책	기준	대표 사용 사례
Simple	단일 응답	기본 DNS
Weighted	비율	Canary 배포
Latency	지연 시간	속도 최적화
Geolocation	사용자 위치	라이선스 제한
Geoproximity	리소스 근접도	트래픽 편향
Failover	장애 여부	DR 구성
Multi-Value	정상 리소스 다중 응답	간단 분산

Route 53은 트래픽을 보내는 것이 아니라 어디로 보낼지 결정하는 DNS 전략 엔진이다.

✅ Route 53 Health Check

Route 53이 레코드를 응답할지 말지 결정하는 기준

고가용성과 자동 장애 조치를 위해 사용되며, 다음 세 가지 방식이 있다.

공용 엔드포인트 직접 모니터링
계산된(Computed) 상태 확인
CloudWatch Alarm 기반 상태 확인

▶ Endpoint Health Check

HTTP / HTTPS / TCP 지원
30초(Default) / 10초(Fast)
연속 실패 3회 시 Unhealthy

상태 확인이 가능하려면 Health Checker가 해당 엔드포인트에 접근 가능해야 하며, 보안 그룹 또는 방화벽 설정이 필수다.

▶ Calculated Health Check

여러 Health Check를 하나의 논리적 결과로 결합한다.

AND / OR 조건 결합
복합 서비스 상태 판단에 유용

▶ Private Resource Health Check

VPC 내부 리소스는 직접 접근이 불가능하므로, CloudWatch Alarm을 상태 신호로 사용한다.

메트릭이 임계값을 초과하면 Alarm → Health Check 실패로 간주된다.

✅ Failover Routing (Active-Passive)

주 리소스에 장애가 발생했을 때, 자동으로 보조 리소스로 DNS 응답을 전환한다.

Primary 레코드: Health Check 필수
Secondary 레코드: 선택

Active-Active 구조가 아닌, 재해 복구(Disaster Recovery) 목적에 적합

✅ Geolocation Routing

사용자의 실제 국가 / 지역 위치를 기준으로 응답을 분기한다.

Latency 기반과 달리, 네트워크 성능이 아니라 지리적 위치 자체가 기준이다.

일치하는 위치가 없는 경우를 대비해 Default 레코드 필수

✅ Geoproximity Routing

사용자 위치와 리소스 위치 간의 “거리”를 기준으로 라우팅한다.

Bias 값을 통해 특정 리소스로 트래픽을 인위적으로 더 끌어올리거나 줄일 수 있다.

Bias ↑ → 트래픽 증가
Bias ↓ → 트래픽 감소

온프레미스 리소스의 경우 위도/경도를 직접 지정해야 한다.

⚠️ Route 53 Traffic Flow(고급 기능)가 필요함

✅ Multi-Value Answer Routing

여러 정상 엔드포인트를 동시에 응답한다.

최대 8개의 정상 레코드 반환
각 레코드는 Health Check 가능

ELB처럼 보일 수 있지만, 로드 밸런서를 대체할 수는 없다.

Simple Routing과 달리, 비정상 리소스를 자동으로 제외할 수 있다는 점이 핵심 차이

📌 Domain Registrar vs DNS Service

도메인 Registrar와 DNS 서비스는 역할이 다르다.

Registrar: 도메인 소유권 관리
DNS Service: 이름 → 엔드포인트 해석

GoDaddy에서 도메인을 구매했더라도, DNS 관리는 Route 53으로 이전할 수 있다.

이 경우 필요한 작업: Registrar에서 Nameserver(NS)를 Route 53이 제공한 NS로 변경

이 순간부터 DNS 쿼리는 Route 53이 전담하게 된다.

16. NAT (Network Address Translation)

사설 네트워크 리소스가 외부와 통신할 수 있도록 주소를 변환해주는 기술

AWS에서는 주로 프라이빗 서브넷 → 인터넷 단방향 통신을 위해 사용된다.

[Private Subnet]
      │
      ▼
   [NAT]
      │
      ▼
   Internet

외부 → 내부 접근 ❌
내부 → 외부 접근 ⭕

👉 “나가기는 되는데, 들어오지는 못하게”

📌 NAT Gateway vs NAT Instance

구분	NAT Gateway	NAT Instance
관리 주체	AWS	사용자
확장성	자동	수동
실무 사용	권장	거의 사용 ❌

👉 실무에서는 NAT Gateway가 표준

17. EBS (Elastic Block Store)

Amazon EBS는
EC2에 붙여서 사용하는 영구 블록 스토리지다.

EC2와 분리된 저장소
인스턴스 종료 후에도 데이터 유지
스냅샷 백업 가능

[EC2] ────(Network)──── [EBS]

👉 “클라우드판 외장 하드” (AZ 단위 리소스)

📌 EBS의 네트워크적 특징

로컬 디스크 ❌
네트워크를 통해 연결
I/O 성능은 네트워크 품질에 영향

👉 EBS 성능 = 네트워크 성능

📌 EBS Snapshot

EBS 볼륨의 특정 시점을 저장하는 백업 이미지

증분 백업 방식
S3 기반 내부 저장
리전 단위 리소스 (AZ 단위 X)

[EBS Volume]
   │
 Snapshot (Point-in-time)
   │
[New EBS Volume]

👉 장애 복구, 볼륨 복제, AMI 생성의 기반

중요 포인트

첫 스냅샷만 전체 백업
이후는 변경된 블록만 저장

👉 비용·시간 효율적

✅ 포인트
EBS 볼륨은 AZ 종속 리소스이며,
EBS 스냅샷은 리전 단위 리소스다.

👉 따라서, 스냅샷을 이용하면 한 AZ에서 생성된 EBS 볼륨을 다른 AZ에서 새로 만들어 사용할 수 있기 때문에,
AZ 간의 데이터 이전이 유연하게 가능하다.

📌 EBS 볼륨 타입 (Volume Types)

EBS는 성능과 비용에 따라 여러 볼륨 타입을 제공한다.

gp2 / gp3 : 범용 SSD
io1 / io2 : 프로비저닝 IOPS SSD
st1 : 처리량 최적화 HDD
sc1 : 콜드 HDD

🔹 gp2 / gp3 (범용 SSD)

OS, 개발/테스트, 일반 애플리케이션
짧은 지연시간 + 합리적 비용

IOPS 특징

gp2 → 볼륨 크기에 따라 IOPS 증가 (3 IOPS/GB)
gp3 → IOPS와 처리량을 용량과 독립적으로 설정

🔹 io1 / io2 (프로비저닝 IOPS SSD)

미션 크리티컬 워크로드
데이터베이스(DB)

IOPS 특징

IOPS를 명시적으로 지정
16,000 IOPS 초과 필요 시 사용
io2 → 더 높은 내구성과 최대 256,000 IOPS

👉 성능 안정성이 최우선일 때

🔹 st1 / sc1 (HDD 계열)

부팅 볼륨 사용 불가
대용량 데이터 저장용

st1 : 빅데이터, 로그, 데이터 웨어하우스
sc1 : 접근 빈도 낮은 아카이브

👉 IOPS보다 처리량 또는 비용이 중요할 때

📌 EBS 다중 연결 (Multi-Attach)

하나의 EBS 볼륨을 여러 EC2에 동시에 연결하는 기능

io1 / io2만 지원
같은 AZ 내에서만 가능
클러스터 파일 시스템 필요

👉 고가용성 클러스터 구성용

주의

일반 파일 시스템(ext4 등)에서는 데이터 손상 위험

📌 EBS 암호화 (Encryption)

EBS는 기본적으로 암호화 가능하다.

AWS KMS 사용
At-rest / In-transit 자동 암호화

암호화 대상:

EBS 볼륨
EBS 스냅샷
스냅샷으로 생성한 볼륨

👉 성능 저하 거의 없음

암호화된 볼륨 → 암호화 해제 ❌
비암호화 볼륨 → 스냅샷 → 암호화 가능 ⭕

[Unencrypted EBS]
   │ Snapshot
   ▼
[Encrypted Snapshot]
   │
[Encrypted EBS]

👉 암호화 전환은 스냅샷 기반

18. 인스턴스 스토어 (Instance Store)

인스턴스 스토어는 EC2 호스트에 물리적으로 붙어 있는 임시 디스크다.

인스턴스 종료 시 데이터 소멸
매우 빠른 I/O

[EC2 Host]
 └─ Instance Store (Local)

👉 “빠르지만 날아가도 되는 데이터 전용”

19. Amazon EFS (Elastic File System)

Amazon EFS는
여러 EC2 인스턴스가 동시에 접근할 수 있는 완전 관리형 파일 스토리지다.

다중 EC2 동시 접근 ⭕
파일 시스템 기반 (POSIX)
용량 자동 확장

[EC2 A] ─┐
         ├─── [EFS]
[EC2 B] ─┘

📌 EFS의 핵심 특징

EBS와 가장 큰 차이점

EBS = 하나의 EC2에 붙는 디스크
EFS = 여러 EC2가 함께 쓰는 파일 시스템

마운트 방식 사용
리눅스 파일 시스템 그대로 사용 가능
AZ 간 자동 복제

👉 고가용성 기본 제공

⚙️ EFS 성능 모델

EFS 성능은 용량이 아니라 사용량 기반으로 결정됨

저장된 데이터가 많을수록 성능 증가
읽기/쓰기 작업량에 따라 처리량 자동 확장

📈 Throughput 모드

1️⃣ Bursting Throughput (기본)

저장된 데이터 양에 비례해 처리량 증가
대부분의 일반적인 워크로드에 적합

👉 일반 웹 서비스, 공유 디렉토리

2️⃣ Provisioned Throughput

저장 용량과 무관하게 처리량 고정
항상 높은 처리량이 필요한 경우

👉 대규모 배치 작업, 분석 워크로드

📂 성능 모드

1️⃣ General Purpose (기본)

낮은 지연시간
대부분의 사용 사례

👉 웹 서버, CMS, 애플리케이션 공유 파일

2️⃣ Max I/O

높은 병렬 처리
지연시간 증가 가능

👉 수천 개 인스턴스가 동시에 접근하는 환경

🧊 스토리지 클래스

Standard : 자주 접근
Infrequent Access (IA) : 접근 빈도 낮음, 비용 절감

Lifecycle 정책을 사용하면
자동으로 Standard → IA 이동 가능

🧠 언제 EFS를 사용하는가?

여러 EC2가 같은 파일을 공유해야 한다
인스턴스 교체/확장 시 데이터 유지
NAS/NFS 구조가 필요

예시:

웹 서버 여러 대의 공용 업로드 디렉토리
컨테이너 공용 볼륨
CI/CD 아티팩트 공유

📌 옵션 선택 가이드

일반 서비스 → General Purpose + Bursting
항상 높은 처리량 → Provisioned Throughput
대규모 병렬 접근 → Max I/O
장기 보관 데이터 → IA 스토리지 클래스

📊 EBS vs Instance Store vs EFS

구분	EBS	Instance Store	EFS
스토리지 타입	블록	블록	파일
연결 방식	네트워크	로컬	네트워크
지속성	영구	임시	영구
동시 접근	❌ (1 인스턴스)	❌	⭕ (다수)
성능 특성	IOPS/처리량 설정	초고속 I/O	자동 확장 처리량
대표 용도	OS, DB	캐시, 임시 데이터	공유 파일 시스템

20. ELB (Elastic Load Balancing)

Elastic Load Balancing은
들어오는 트래픽을 여러 서버로 분산하는 서비스다.

User
 │
[Load Balancer]
 ├─ EC2
 ├─ EC2
 └─ EC2

👉 단일 서버 한계를 넘기 위한 핵심 구조

📌 ELB의 종류

종류	특징	계층
ALB	HTTP/HTTPS, 경로·호스트 기반 라우팅	L7
NLB	초고성능 TCP/UDP, 고정 IP 지원	L4
GWLB	네트워크 트래픽을 보안 장비로 전달 (방화벽, IDS/IPS)	L3 / L4
CLB	구형 로드 밸런서 (비권장)	L4 / L7

👉 웹 서비스 = ALB
👉 초고성능 네트워크 트래픽 = NLB
👉 보안 장비 트래픽 처리(L3 스위치 역할) = GWLB

🔍 GWLB를 “L3 스위치”라고 부르는 이유

Gateway Load Balancer(GWLB)는 일반적인 웹 트래픽 분산용이 아닌,

네트워크 레벨(L3/L4)에서 트래픽을 가로채서 보안 장비로 전달하는 용도다.

Client
 │
[VPC Route]
 │
[GWLB]
 │
[Firewall / IDS / IPS]
 │
Destination

패킷 내용 보지 않음 (L7 ❌)
IP 기반 트래픽 처리
보안 어플라이언스 확장·이중화

👉 그래서 개념적으로 “L3 스위치 + 로드 밸런서”에 가깝다.

ALB : 웹 요청 처리용 (HTTP/HTTPS)
NLB : 초고속 네트워크 트래픽
GWLB : 보안 장비 트래픽 분산 (L3/L4)
CLB : 과거 유산 (신규 사용 ❌)

📌 Sticky Session (Session Affinity)

Sticky Session은
같은 사용자의 요청을 항상 같은 백엔드 서버로 보내는 기능이다.

User A ──┐
         ├─ [ALB] ──→ EC2-1
User B ──┘

세션 정보가 서버 로컬에 있을 때 사용
주로 레거시 애플리케이션에서 필요

Sticky Session의 문제점 ⚠️

Auto Scaling과 충돌
특정 인스턴스로 부하 집중
인스턴스 장애 시 세션 유실

👉 ElastiCache Session Store가 권장 대안

🍪 Cookie 기반 Sticky Session

ELB의 Sticky Session은 쿠키 기반으로 동작한다.

쿠키 종류

쿠키	설명
AWSALB	AWS가 자동 생성하는 쿠키
Application Cookie	애플리케이션이 직접 정의

쿠키에 타겟 인스턴스 정보 포함
쿠키 만료 시 Sticky Session 해제

👉 “쿠키 = 서버로 가는 길 안내 표지판”

🌍 Cross-Zone Load Balancing (영역 간 LB)

Cross-Zone Load Balancing은
모든 AZ의 인스턴스에 트래픽을 균등 분산하는 기능이다.

❌ 비활성화 시

AZ-A (EC2 2대) ← 트래픽 50%
AZ-B (EC2 1대) ← 트래픽 50%

⭕ 활성화 시

모든 EC2에 균등 분산

AZ 간 인스턴스 수가 달라도 균등 분산
ALB는 기본 활성화

👉 “AZ가 아니라 인스턴스 기준 분산”이다.

🔐 SSL / TLS Termination

ELB는 SSL/TLS 암호화 종료 지점이 될 수 있다.

User (HTTPS)
   │
[ALB]  ← TLS 종료
   │
EC2 (HTTP)

인증서 관리 중앙화
백엔드 서버 부하 감소
AWS ACM과 연동

👉 “암호화는 LB에서, 서버는 가볍게 유지”

📜 SNI (Server Name Indication)

SNI

  example.com  ─┐
                ├─ [ALB] ── 인증서 A
api.example.com ┘           인증서 B

Host Header 기반 인증서 선택
여러 도메인을 하나의 ALB에서 처리

👉 “한 IP / 한 LB / 여러 HTTPS 사이트”

🔄 Connection Draining (Deregistration Delay)

Connection Draining은
인스턴스를 제거할 때 기존 연결을 정상 종료하도록 기다리는 기능이다.

인스턴스가 Draining 상태가 되면, ELB는 등록 취소 중인 인스턴스로 새로운 요청을 보내지 않고 현재 연결되어 있는 작업을 완료하면 종료된다.

[ALB]
 │
EC2 (제외 예정)
 │
기존 요청 처리 완료 후 제거

새 요청은 더 이상 전달 ❌
기존 요청은 완료까지 유지 ⭕
무중단 배포 핵심 기능

👉 “지금 처리 중인 요청은 끝내고 가라”

📌 ELB 상태 확인 (Health Check)

ELB는 백엔드 인스턴스의 상태를 지속적으로 검사한다.

HTTP / HTTPS / TCP 지원
비정상 인스턴스는 자동 제외

👉 “살아 있는 서버만 트래픽 받는다”

21. Auto Scaling

Auto Scaling은 트래픽에 따라 서버, 컨테이너, DB 용량 등 리소스의 양을 자동으로 조절하는 기능을 의미한다

User
 │
[ALB]
 │
[Auto Scaling Group]
 ├─ EC2
 ├─ EC2
 └─ EC2

Scale Out / Scale In
ELB와 거의 항상 함께 사용

📌 Auto Scaling Group (ASG)

오토 스케일링을 실제로 수행하는 관리 단위(그룹)

EC2 생성 / 종료를 직접 수행
항상 일정 개수의 인스턴스 유지
로드 밸런서(Target Group)와 연동

[ASG]
 ├─ Desired Capacity
 ├─ Min Size
 └─ Max Size

📌 ASG의 기본 동작 과정 (EC2)

Auto Scaling은 다음과 같은 흐름으로 동작한다.

1. 트래픽 증가
2. CloudWatch 지표 상승
3. Scaling Policy 트리거
4. ASG가 EC2 생성
5. ELB(Target Group)에 자동 등록

반대로 트래픽이 줄어들면:

1. 지표 감소
2. Scale In 조건 충족
3. ASG가 EC2 제거
4. Connection Draining 대기
5. 인스턴스 종료

👉 “지표 기반 자동 증감”

📌 CloudWatch와 Auto Scaling

CloudWatch는
Auto Scaling의 판단 근거를 제공하는 모니터링 서비스다.

CPU 사용률
네트워크 트래픽
ALB Request Count

CloudWatch는 지표(Metric)를 수집하고, 이를 기준으로 Alarm을 발생시킨다.

CloudWatch Metric
   │
CloudWatch Alarm
   │
Scaling Policy
   │
ASG 동작

👉 “CloudWatch = 눈, ASG = 손”

📌 Scaling Policy (조정 정책)

Scaling Policy는
언제, 얼마나 EC2를 늘리거나 줄일지 정의한다.

Target Tracking (기본·권장)
Step Scaling
Scheduled Scaling
Predictive Scaling

🔹 Target Tracking Scaling - 대상 추정 조정

특정 지표를 목표값(Target)으로 유지하도록 자동 조절한다.

CPU 평균 50% 유지

AWS가 증감 폭 자동 계산
가장 안정적

🔹 Step Scaling - 단계 조정

지표 구간에 따라 단계적으로 인스턴스를 증감한다.

CPU ≥ 60% → +1
CPU ≥ 80% → +3

정밀 제어 가능
설계 난이도 높음

👉 “부하 패턴이 명확할 때 사용”

🔹 Scheduled Scaling

정해진 시간에 인스턴스 수를 조절한다.

매일 09:00 → 10대
매일 22:00 → 3대

👉 “트래픽 패턴이 시간 기반일 때”

🔹 Predictive Scaling

과거 데이터를 분석해 미래 트래픽을 예측하고 미리 Scale Out을 수행한다.

CloudWatch ML 기반
Scale-out 지연 최소화

👉 대규모 서비스용

📌 ASG와 ELB의 관계

ASG와 ELB는 다음과 같이 역할이 분리된다.

ELB → 헬스 체크, 트래픽 분산
ASG → EC2 생성/종료

ELB가 비정상 인스턴스를 감지하면:

ELB (Unhealthy)
   ↓
ASG
   ↓
EC2 교체

👉 “ELB는 판단, ASG는 실행”

22. Elastic IP (EIP)

EIP는 고정 퍼블릭 IP다.

인스턴스 재시작에도 유지
NAT, Bastion Host에 자주 사용

👉 “바뀌지 않는 인터넷 주소”

23. Bastion Host

Bastion Host는 프라이빗 서브넷에 접근하기 위한 중간 서버다.

Internet
 │
[Bastion (Public)]
 │
[Private EC2]

SSH 접근 통제
보안 진입점

👉 “출입 통제용 정문”

24. IAM (Identity and Access Management)

IAM은 AWS 리소스에 대해
누가(Who), 무엇을(What), 어떻게(How) 접근할 수 있는지를 정의하는 서비스다.

인증(Authentication)
권한 부여(Authorization)

👉 AWS 보안의 출발점

네트워크가 “어디까지 들어올 수 있느냐”를 다룬다면,
IAM은 “들어온 뒤 무엇을 할 수 있느냐”를 다룬다.

25. IAM 구성 요소

IAM은 여러 개념이 결합된 권한 설계 시스템이다.

👤 IAM User

AWS에 로그인할 수 있는 실제 주체다.

사람 또는 고정된 계정
장기 자격증명 보유

👉 “사람 계정”

👥 IAM Group

여러 IAM User를 논리적으로 묶는 단위

권한 관리용
User만 포함 가능

👉 “부서”

📜 IAM Policy

무엇을 허용하거나 거부할지 정의한 규칙 문서

JSON 형식
Action / Resource / Effect

IAM Policy 기본 구성

IAM 정책은 크게 Version과 Statement로 구성된다.

Version : 정책 문법 버전 (항상 2012-10-17)
Statement : 실제 권한 규칙 (1개 이상 필수)
id : 정책의 식별자 (선택)

Statement 구성 요소

Sid : 규칙 식별자 (선택)
Effect : Allow / Deny을 지정
Principle : 어떤 사용자가 리소스에 접근 가능한지 지정
Action : Allow/Deny 할 AWS API작업 정의
Resource : 작업이 적용되는 리소스
Condition : 조건 (선택)

Principal이란?

Principal은
“이 리소스를 사용할 수 있는 대상”을 명시적으로 지정할 때 사용한다.

즉,

어떤 AWS 계정
어떤 IAM User / Role
어떤 AWS 서비스

가 이 리소스에 접근 가능한지를 지정한다.

Principal을 언제 쓰고, 언제 안 쓰나?

❌ 사용자 기반 정책 (User / Group / Role에 붙는 정책)

이 경우 Principal을 쓰지 않는다.

정책이 이미 특정 User / Role에 붙어 있고
“정책을 가진 주체”가 곧 적용 대상이기 때문

👉 Principal을 안 쓰면
“이 정책을 가진 사람만” 권한을 가진다.

⭕ 리소스 기반 정책 (S3, SQS, SNS 등)

이 경우 Principal이 필수

정책이 리소스에 붙어 있고
누가 이 리소스를 사용할 수 있는지 직접 지정해야 하기 때문

👉 Principal을 쓰면
“이 리소스를 사용할 수 있는 대상”을 명시한다.

🎭 IAM Role

Role은 누군가가 잠시 맡아서 사용하는 권한 묶음이다.

로그인 불가
임시 자격증명 사용

👉 “빌려 쓰는 권한”

User vs Role 차이

User → 사람
Role → 행위 / 상황

EC2, Lambda 같은 AWS 서비스는
User가 아니라 Role을 통해 권한을 가진다.

👉 장기 키 노출을 막기 위한 설계

26. EC2 (Elastic Compute Cloud)

EC2는 AWS에서 제공하는 가상 서버다.

CPU, 메모리, 네트워크 포함
필요할 때 생성, 필요 없으면 종료

[User]
 │
[EC2 Instance]

👉 “클라우드에서 빌려 쓰는 컴퓨터”

📌 EC2 인스턴스 라이프사이클

EC2 인스턴스는 단순히 “켜고 끄는 서버”가 아니라
상태(State)를 가진 리소스다.

Pending : 생성 중
Running : 실행 중
Stopping / Stopped : 중지
Terminated : 종료 (복구 불가)

💤 EC2 Hibernate (절전 모드)

Hibernate는 EC2 인스턴스를 종료하지 않고
메모리(RAM) 상태까지 디스크에 저장한 뒤 중지하는 기능이다.

Running
   ↓
Hibernate
   ↓
Stopped (RAM 상태 보존)
   ↓
Resume → 이전 상태 그대로 복원

Hibernate의 핵심 특징

RAM 내용 → 루트 EBS에 저장
재부팅 후 이전 프로세스 그대로 복원
빠른 재개(Resume)

제약 사항 ⚠️

EBS 기반 인스턴스만 가능
루트 볼륨 암호화 필수
지원 인스턴스 타입 제한
최대 절전 기간 제한

👉 “OS 부팅 없이 그대로 이어서 쓰고 싶을 때”

🧠 Stop vs Hibernate vs Terminate

구분	Stop	Hibernate	Terminate
RAM 보존	❌	⭕	❌
재시작 속도	느림	빠름	불가
데이터 유지	EBS만	EBS + RAM	❌

🧩 EC2 인스턴스 타입

EC2는 워크로드에 따라 인스턴스 패밀리로 구분된다.

타입	용도
T 계열	버스트형, 저비용 (웹 서버)
C 계열	CPU 집약 (연산)
M 계열	범용
R 계열	메모리 집약 (DB, 캐시)

💾 EC2 스토리지 구성

EBS : 네트워크 기반 영구 스토리지
Instance Store : 로컬 임시 스토리지

[EC2]
 ├─ Root EBS (OS)
 └─ Data EBS / Instance Store

👉 중요한 데이터 = EBS
👉 날아가도 되는 데이터 = Instance Store

🌐 EC2 네트워크 구성

VPC 안에 생성
서브넷에 속함
ENI(가상 NIC) 보유

VPC
 └─ Subnet
     └─ EC2
         └─ ENI
             ├─ Private IP
             └─ Security Group

👉 퍼블릭 서브넷 ≠ 퍼블릭 IP 필수
👉 프라이빗 서브넷 ≠ 인터넷 접근 불가 (NAT로 가능)

🔐 EC2 보안 구조

1️⃣ Security Group

상태 기반(Stateful)
Allow 규칙만 존재
인스턴스 단위 적용

2️⃣ IAM Role for EC2

EC2에 권한 부여
Access Key 하드코딩 ❌

👉 EC2는 User가 아니라 Role을 사용

📈 EC2 + Auto Scaling

EC2는 단독으로 쓰기보다
Auto Scaling Group(ASG)과 함께 사용된다.

트래픽 증가 → EC2 자동 증가
트래픽 감소 → EC2 자동 감소

User
 │
[ALB]
 │
[ASG]
 ├─ EC2
 ├─ EC2
 └─ EC2

👉 EC2 = 컴퓨터
👉 ASG = 수 자동 관리

27. AMI (Amazon Machine Image)

AMI는 EC2를 생성할 때 사용하는 서버 템플릿이다.
=> EBS 스냅샷을 가리키는 메타데이터 + 참조 정보

AMI는 EBS 스냅샷을 기반으로 만들어지며,
EBS 스냅샷이 리전 단위 리소스이기 때문에 AMI 또한 리전 종속적이다. (리전 단위로 존재하는 리소스)
따라서, 다른 리전에서 사용하려면 복사해서 새로운 AMI를 만들어야 한다.

OS 포함
필요 시 소프트웨어까지 포함

👉 “서버 설계도”

28. Instance Type

인스턴스 타입은 EC2의 성능 스펙을 의미한다.

CPU
메모리
네트워크 성능

예)

t 계열 → 범용
c 계열 → 연산 집중
m 계열 → 밸런스

👉 “컴퓨터 사양 선택”

29. Key Pair

Key Pair는 EC2에 접속하기 위한 SSH 인증 수단이다.

Public Key → 서버 저장
Private Key → 사용자 보관

👉 비밀번호 로그인 ❌
👉 키 기반 로그인 ⭕

30. ENI (Elastic Network Interface)

ENI는 EC2에 붙는 가상 네트워크 카드다. (특정 AZ에 종속 됨)

IP 주소
보안 그룹
네트워크 트래픽

[EC2]
 └─ ENI ── Network

👉 EC2의 네트워크 정체성

31. 컨테이너(Container)

컨테이너는 애플리케이션과 실행 환경을 하나로 묶은 실행 단위다.

EC2가 “가상 컴퓨터”라면,
컨테이너는 그 위에서 돌아가는 가벼운 실행 프로세스다.

OS 전체 ❌
애플리케이션 + 라이브러리만 포함 ⭕
빠른 실행, 높은 밀도

[EC2]
 └─ Container 1
 └─ Container 2

👉 서버를 더 잘 쪼개 쓰는 방법

32. Docker

Docker는 컨테이너를 만들고 실행하기 위한 도구다.

이미지(Image) 기반
어디서나 동일하게 실행

컨테이너는 보통 이렇게 만들어진다.

Source Code
 → Docker Image
 → Container

👉 “내 PC에서 되던 게 서버에서도 그대로 된다”

33. Amazon ECS (Elastic Container Service)

Amazon ECS는 AWS가 제공하는 AWS 네이티브 컨테이너 오케스트레이션 서비스다.
Docker 컨테이너를 대규모로 배포하고, 확장하고, 관리하기 위한 플랫폼이다.

✅ AWS 서비스와 깊게 통합됨
✅ 설정 단순
✅ Kubernetes보다 러닝커브 낮음

User
  │
  ▼
[ECS Service]
  │
  ▼
[EC2  or  Fargate]
  │
  ▼
[Docker Containers]

👉 ECS는 “컨테이너를 실행하고 유지하는 관리자” 역할을 한다.

📦 ECS 핵심 구성요소

1️⃣ Task Definition

컨테이너 실행 설계도다.

Docker Image
CPU / Memory
Port Mapping
Environment Variables
IAM Task Role

👉 컨테이너 청사진

2️⃣ Cluster

컨테이너가 실행될 인프라 집합이다.

EC2 기반 클러스터
Fargate 기반 클러스터

👉 컨테이너가 올라갈 공간

3️⃣ Service

Task를 원하는 개수만큼 항상 유지한다.

자동 재시작
Auto Scaling 연동
Load Balancer 통합

👉 무중단 운영의 핵심

ECS 실행 방법: EC2 Launch Type vs Fargate Launch Type

(1) EC2 Launch Type

EC2 인스턴스를 직접 프로비저닝해야 하며, EC2 위에서 컨테이너가 실행됨.

ECS Cluster
 ├─ EC2 Instance
 │     ├─ ECS Agent
 │     └─ Containers

✔ 인프라 직접 관리
✔ Spot / Reserved 사용 가능
❌ 패치 및 관리 필요

ECS Agent는 EC2 안에서 실행되며 ECS와 통신하는 중개자다.

(2) Fargate Launch Type

EC2를 만들지 않고 AWS가 서버를 대신 관리함. 완전 서버리스!

User
  │
  ▼
[ECS Service]
  │
  ▼
[Fargate]
  │
  ▼
[Containers]

✔ EC2 없음
✔ Task 수만 늘리면 확장
❌ 인프라 제어 불가

📌 핵심 차이
EC2 = 서버 관리 + 컨테이너 실행
Fargate = 컨테이너만 신경 쓰면 됨

Amazon ECR (Elastic Container Registry)

컨테이너 이미지를 저장하는 AWS 전용 레지스트리

Dockerfile
   │
   ▼
docker build
   │
   ▼
docker push → [ECR]
   │
   ▼
ECS pulls image → 실행

Private / Public 지원
IAM 기반 접근 제어
ECS/EKS와 완전 통합

👉 컨테이너 이미지 저장소

IAM Roles for ECS (중요 ⭐)

ECS에는 권한이 두 계층으로 나뉜다.

🧱 EC2 Instance Profile (EC2 Launch Type 전용)

ECS Agent가 사용
ECR 이미지 Pull
CloudWatch Logs 전송
ECS API 호출

👉 인프라 권한

🧩 ECS Task Role

컨테이너 내부 애플리케이션이 사용
S3 접근
DynamoDB 접근
SNS / SQS 호출

👉 애플리케이션 권한

EC2 Role  → 인프라 권한
Task Role → 앱 권한

⚠️ 최소 권한 원칙 적용해야 함

Load Balancer 통합

Users
  │
  ▼
Application Load Balancer
  │
  ▼
ECS Service
  │
  ▼
Tasks

Target Group 자동 등록
Health Check
Path 기반 라우팅

👉 대부분의 웹 서비스 기본 구조

데이터 지속성 – Amazon EFS

컨테이너는 기본적으로 Stateless다.

영구 저장이 필요하면 EFS를 사용한다.

ECS Tasks
   │ mount
   ▼
Amazon EFS

Multi-AZ 지원
EC2 / Fargate 모두 가능
동시에 여러 Task 공유 가능

👉 서버리스 + 공유 파일 시스템 가능

ECS Auto Scaling

📈 Task Level Scaling

CPU 사용률
Memory 사용률
ALB 요청 수

CloudWatch Metric
     │
     ▼
Application Auto Scaling
     │
     ▼
Task Count 증가/감소

📈 EC2 Launch Type 인스턴스 확장

Task 증가
   │
   ▼
EC2 부족
   │
   ▼
Auto Scaling Group 확장

Capacity Provider 사용 권장

EventBridge로 ECS Task 실행

📌 이벤트 기반 실행

S3 업로드
   │
   ▼
EventBridge
   │
   ▼
ECS Task 실행
   │
   ▼
DynamoDB 저장

📌 스케줄 기반 실행

매 1시간
   │
   ▼
EventBridge Rule
   │
   ▼
ECS Task 실행

👉 서버리스 배치 처리 패턴

🔥 전체 아키텍처 정리

Docker → ECR
         │
         ▼
       ECS
   (EC2 or Fargate)
         │
         ▼
        ALB
         │
         ▼
        EFS (선택)
         │
         ▼
   Auto Scaling
         │
         ▼
   EventBridge 트리거

📌 핵심 요약

개념	설명
ECS	컨테이너 오케스트레이션
Fargate	서버리스 컨테이너 실행
ECR	컨테이너 이미지 저장소
Task Role	애플리케이션 권한
Instance Role	인프라 권한
ALB	트래픽 분산
EFS	공유 스토리지
EventBridge	이벤트 기반 실행

ECS는 로드밸런싱, 스케일링, 이벤트 트리거, 영구 저장소까지 연결되는 완전한 애플리케이션 실행 플랫폼이다.

34. AWS Fargate

Fargate는 서버를 관리하지 않고 컨테이너를 실행할 수 있는 AWS의 서버리스 컴퓨팅 엔진이다.
ECS, EKS에서 사용 가능

컨테이너 관리자 = ECS
실행 엔진 = EC2 or Fargate

EC2 관리 ❌
컨테이너만 정의 ⭕

ECS
 │
[Fargate]
 │
[Container]

👉 “서버 신경 쓰기 싫을 때”

35. AWS Lambda

AWS Lambda는 서버를 전혀 관리하지 않고 코드를 실행하는 서버리스 컴퓨팅 서비스다.

Fargate가 “컨테이너 실행만 신경 쓰는 방식”이라면,
Lambda는 컨테이너조차 신경 쓰지 않는 방식이다.

서버 관리 ❌
컨테이너 관리 ❌
코드만 작성 ⭕

Event
 │
[Lambda]
 │
Code 실행

👉 “코드만 올리면 나머지는 AWS가 전부 처리”

⚙️ 함수(Function)

Lambda는 함수 단위로 실행된다.

특정 이벤트에 의해 실행
짧은 실행 시간

👉 “요청이 들어올 때만 잠깐 실행”

⏱️ 실행 방식

Lambda는 항상 켜져 있지 않다.

요청 없음 → 실행 없음
요청 발생 → 즉시 실행

👉 유휴 비용 없음

Lambda 트리거(Event Source)

Lambda는 이벤트 기반으로 동작한다.

API Gateway (HTTP 요청)
S3 (파일 업로드)
SQS / SNS
EventBridge

[S3 Upload]
   │
[Lambda]
   │
[처리 로직]

👉 “무언가 발생하면 실행”

Lambda와 실행 환경

Lambda는 내부적으로 컨테이너 환경에서 실행된다.

하지만 사용자는:

EC2 ❌
컨테이너 ❌
네트워크 구성 ❌

을 전혀 신경 쓰지 않는다.

👉 완전한 추상화

Lambda vs Fargate

구분	Lambda	Fargate
실행 단위	함수	컨테이너
서버 관리	❌	❌
컨테이너 관리	❌	⭕
실행 시간	짧음 (이벤트 기반)	상대적으로 김

👉 단순 이벤트 처리 = Lambda
👉 지속 실행 서비스 = Fargate

36. Kubernetes (쿠버네티스)

Kubernetes는
컨테이너를 자동으로 배치·확장·복구·관리하는 오케스트레이션 시스템이다.

컨테이너가 “실행 단위”라면,
쿠버네티스는 컨테이너를 운영하는 운영체제에 가깝다.

👉 “컨테이너가 많아졌을 때 생기는 모든 문제를 해결하기 위해 등장”

왜 Kubernetes가 필요할까?

컨테이너만으로는 이런 문제가 생긴다.

컨테이너가 죽으면 누가 다시 띄우지?
트래픽이 늘면 몇 개 더 띄워야 하지?
어느 서버에 배치해야 하지?

이걸 사람이 직접 하면 불가능하다.
그래서 쿠버네티스가 자동으로 결정한다.

👉 “사람 대신 판단하는 컨테이너 관리자”

Kubernetes 기본 구조

[Kubernetes Cluster]
 ├─ Control Plane (두뇌)
 └─ Worker Node (일꾼)

클러스터는 크게 두 영역으로 나뉜다.

🧠 Control Plane

클러스터 전체를 제어하는 영역이다.

어디에 컨테이너를 배치할지 결정
상태를 지속적으로 감시

👉 “관리자”

🧱 Worker Node

실제로 컨테이너가 실행되는 서버다.

EC2 또는 물리 서버
여러 개의 컨테이너 실행

👉 “실행 공간”

37. Pod (쿠버네티스의 최소 단위)

Pod는 쿠버네티스에서
배포와 실행의 최소 단위다.

하나 이상의 컨테이너 포함 가능
같은 네트워크(IP) 공유

[Pod]
 ├─ Container A
 └─ Container B

👉 쿠버네티스는 컨테이너가 아니라 Pod를 관리한다.

38. Deployment

Deployment는
Pod를 어떻게, 몇 개, 어떤 상태로 유지할지 정의한다.

원하는 개수 유지
자동 재시작
무중단 배포

👉 “서비스 운영 설명서”

39. Service (쿠버네티스 네트워크)

Pod는 IP가 자주 바뀐다.
그래서 직접 접근하면 안 된다.

Service는
Pod들을 하나의 논리적 서비스로 묶는 네트워크 객체다.

Client
 │
[Service]
 │
[Pod A] [Pod B] [Pod C]

👉 로드 밸런싱 + 고정 접근 지점

Kubernetes 네트워크 개념

쿠버네티스의 기본 가정은 이렇다.

모든 Pod는 서로 통신 가능
NAT 없이 직접 통신

AWS에서는 이걸
ENI + VPC CNI로 구현한다.

👉 Pod도 결국 VPC 네트워크 위에 올라간다.

Kubernetes vs ECS

구분	Kubernetes	ECS
표준	오픈소스	AWS 전용
자유도	높음	낮음
운영 난이도	높음	낮음

👉 복잡하지만 강력 = Kubernetes
👉 단순하고 빠름 = ECS

40. Amazon EKS (Elastic Kubernetes Service)

EKS는 AWS에서 제공하는 관리형 Kubernetes 서비스다.
쿠버네티스 컨트롤 플레인을 AWS가 대신 운영해준다.

✅ Kubernetes 표준 API 사용
✅ 멀티 클라우드 / 온프레미스 확장 가능
✅ 높은 자유도
❗ 러닝 커브 존재

User
  │
  ▼
[EKS Control Plane]
  │
  ▼
[Worker Nodes]
  │
  ▼
[Pods]

👉 “쿠버네티스를 그대로 쓰고 싶을 때” 사용하는 서비스

🧠 EKS의 핵심 구조

1️⃣ Control Plane (AWS가 관리)

API Server
Scheduler
etcd (상태 저장)

AWS가 Multi-AZ로 자동 구성하며 고가용성을 보장한다.

2️⃣ Worker Nodes (사용자가 관리)

EC2 기반 노드
Fargate 기반 노드

실제 Pod가 실행되는 서버다.

3️⃣ Pod

쿠버네티스의 최소 배포 단위 (컨테이너를 포함하는 실행 단위)

🔐 EKS 보안 – Kubernetes Secret 암호화

EKS에서 Kubernetes Secret은 etcd에 저장된다. 기본적으로 EBS 디스크 암호화는 적용되지만, Secret 데이터 자체는 기본적으로 평문 상태로 저장된다.

이를 해결하기 위해 EKS는 AWS KMS 기반 Envelope Encryption을 지원한다.

Kubernetes Secret
        │
        ▼
EKS API Server
        │
        ▼
AWS KMS (Data Key 생성)
        │
        ▼
Encrypted Secret → etcd 저장

KMS 키로 Data Key를 암호화
Secret은 암호화된 상태로 etcd에 저장
복호화는 API Server에서 자동 수행

📌 클러스터 생성 시 --encryption-config 옵션으로 KMS 키를 지정한다.
📌 별도의 Lambda나 사용자 암호화 로직 구현이 필요 없다.
📌 최소 운영 오버헤드로 Secret 보안을 강화할 수 있다.

EKS Node Type

🧩 Managed Node Group

AWS가 EC2 노드 생성 및 관리
Auto Scaling Group 자동 구성
온디맨드 / Spot 인스턴스 지원

👉 일반적으로 가장 많이 사용

🛠 Self-Managed Node

사용자가 직접 ASG 구성
커스텀 AMI 사용 가능
고급 튜닝 가능

👉 세밀한 제어가 필요할 때

⚡ Fargate for EKS

노드 관리 필요 없음
Pod 단위 서버리스 실행

👉 완전 서버리스 Kubernetes

EKS 네트워크 구조

Internet
   │
   ▼
ALB / NLB
   │
   ▼
EKS Service
   │
   ▼
Pods

VPC 내부에 배치
Public / Private Subnet 구성
ELB Controller 필요

Kubernetes Service → AWS Load Balancer로 연결된다.

EKS 데이터 스토리지

Pod는 기본적으로 Stateless다.
👉 데이터가 필요하면 Volume을 사용

지원 스토리지

EBS (블록 스토리지)
EFS (공유 파일 시스템)
FSx (Lustre / NetApp)

Pod
 │
 ▼
Persistent Volume
 │
 ▼
EBS / EFS

📌 EBS는 단일 AZ
📌 EFS는 Multi-AZ 공유 가능

EKS 확장 (Auto Scaling)

1️⃣ Pod 오토스케일링

HPA (Horizontal Pod Autoscaler)
CPU / Memory 기준

2️⃣ Node 오토스케일링

Cluster Autoscaler
노드 부족 시 EC2 자동 추가

Pod 증가
  │
  ▼
Node 부족
  │
  ▼
Auto Scaling Group 확장

EKS Use Case

멀티 클라우드 전략
온프레미스 Kubernetes 확장
Helm / Istio / ArgoCD 사용
복잡한 마이크로서비스 아키텍처

👉 Kubernetes 생태계를 그대로 활용하고 싶을 때

AWS App Runner

컨테이너 기반 웹 애플리케이션을 가장 단순하게 배포하는 서비스

Container Image / Source Code
        │
        ▼
Configure (vCPU / RAM / Auto Scaling)
        │
        ▼
Deploy
        │
        ▼
Public URL 제공

인프라 관리 불필요
HTTPS 자동
간단한 Web / API 서비스에 적합

👉 “가장 간단한 컨테이너 배포”

✅ ECS vs EKS 차이

구분	ECS	EKS
표준	AWS 전용	Kubernetes 표준
난이도	낮음	높음
이식성	낮음	높음
운영 복잡도	간단	복잡
생태계	AWS 중심	Helm / CNCF 전체

빠른 시작 → ECS
표준·멀티클라우드 → EKS

🔥 전체 컨테이너 서비스 비교

서비스	용도
ECS	AWS 최적화 컨테이너
EKS	Kubernetes 표준
Fargate	서버리스 컨테이너
ECR	이미지 저장소
App Runner	초간단 배포

41. Amazon RDS (Relational Database Service)

Amazon RDS는 AWS에서 제공하는 관리형 관계형 데이터베이스 서비스다.

DB 설치, 패치, 백업 자동 관리
고가용성(Multi-AZ) 지원
Read Replica를 통한 읽기 확장

Application
   │
[RDS Endpoint]
   │
[RDS DB Instance]

📌 RDS에서 지원하는 엔진

엔진	설명
MySQL	가장 범용적인 오픈소스 RDB
PostgreSQL	고급 SQL, 확장성 강점
MariaDB	MySQL 호환 오픈소스
Oracle	엔터프라이즈 DB
SQL Server	Microsoft RDB

RDS Multi-AZ

Multi-AZ는 RDS의 고가용성(HA) 기능

AZ-A (Primary)
   │  (Sync Replication)
AZ-B (Standby)

동기 복제(Synchronous)
장애 발생 시 자동 Failover
Endpoint 변경 없음

👉 SQL 연결 문자열 변경 ❌
👉 고가용성 ⭕

Multi-AZ vs Read Replica

구분	Multi-AZ	Read Replica
목적	가용성	읽기 성능 확장
복제 방식	동기	비동기
Endpoint	하나	별도 Endpoint
자동 Failover	⭕	❌

RDS Read Replica

Read Replica는 읽기 트래픽을 분산하기 위한 기능이다.

비동기 복제
SELECT 전용
수동으로 엔드포인트 사용

Writer DB
   │ (Async)
Read Replica

👉 성능 확장 ⭕
👉 고가용성 ❌

AWS RDS 백업

RDS는 두 가지 백업 메커니즘을 제공한다.

🕒 자동 백업 (Automated Backup)

Point-In-Time Recovery 지원
보존 기간 1~35일
활성화 시 스토리지 비용 발생

📸 수동 스냅샷 (Manual Snapshot)

영구 보관
사용자가 삭제 전까지 유지
리전 간 복사 가능

PITR = 자동 백업

42. Amazon Aurora

AWS가 직접 설계한 고성능 클라우드 네이티브 RDB

MySQL / PostgreSQL 호환
RDS 대비 최대 5배 성능
스토리지 자동 확장

👉 “RDS의 상위 호환, 완전 다른 구조”

Aurora DB Cluster 구조

        Writer
          │
  ┌───────┴────────┐
Reader          Reader
          │
    Shared Storage
   (6 copies, 3 AZ)

Writer Endpoint (쓰기)
Reader Endpoint (읽기 분산)
스토리지와 컴퓨트 분리

Global Aurora

Global Aurora는 전 세계 리전에 걸친 읽기 확장을 제공한다.

Primary Region 1개
Secondary Region 다수
Cross-Region Replication (지연 매우 낮음)

👉 글로벌 서비스 + DR(재해복구)

Aurora Cloning

스토리지를 복사하지 않고 DB를 즉시 복제하는 기능

Copy-on-Write 방식
스냅샷보다 훨씬 빠름
테스트 / 개발 환경에 최적

👉 백업 ❌
👉 실험 / 테스트 ⭕

RDS & Aurora Security

🔐 At-Rest Encryption

AWS KMS 사용
생성 시만 설정 가능
기존 DB 암호화 → 스냅샷 복원 필요

🔒 In-Flight Encryption

TLS 기본 지원
클라이언트 인증서 사용

👮 IAM Authentication

DB 비밀번호 대신 IAM Role
단기 자격증명

🧱 Security Group

네트워크 접근 제어
DB는 퍼블릭 노출 ❌

43. Amazon RDS Proxy

RDS Proxy는 DB 앞단에서 연결을 관리하는 프록시

DB 커넥션 풀링
Failover 시간 단축
Lambda / Auto Scaling 환경 필수

Lambda / EC2
      │
 [RDS Proxy]
      │
[RDS / Aurora]

44. Amazon ElastiCache

Amazon ElastiCache는
자주 조회되는 데이터를 메모리에 저장하여 응답 지연을 최소화하는
완전 관리형 인메모리 데이터 저장소다.

Redis / Memcached 엔진 지원
ms 단위 초저지연 응답
RDS / Aurora 부하 감소
애플리케이션 성능 및 확장성 향상

Application
   │  (Read / Write)
[ElastiCache]   ← In-Memory
   │
[RDS / Aurora]  ← Persistent Storage

👉 “DB 앞단에 두는 초고속 메모리 계층”

📌 ElastiCache를 사용하는 이유

읽기 집약적(Read-heavy) 트래픽 처리
DB 커넥션 수 감소
응답 속도 개선 (수십 ms → 수 ms)
애플리케이션을 Stateless 구조로 설계 가능

RDS가 “관리형 관계형 DB”라면,
ElastiCache는 관리형 Redis / Memcached다.

📦 ElastiCache 엔진

🔴 Redis

다양한 데이터 구조 지원 (String, List, Set, Sorted Set, Hash)
읽기 복제본(Read Replica) 지원
Multi-AZ + 자동 Failover
영속성 옵션 (AOF / RDB)
백업 & 복구 가능

👉 “실서비스 표준, 기능 중심”

🔵 Memcached

단순 Key-Value 구조
멀티 노드 샤딩 기반 확장
멀티스레드 구조 (초고속)
영속성 ❌
고가용성 ❌

👉 “단순 캐시 + 최고 성능”

Redis vs Memcached

구분	Redis	Memcached
데이터 구조	풍부 (List, Set, ZSet 등)	단순 Key-Value
영속성	⭕ (선택)	❌
고가용성	⭕ (Multi-AZ + Failover)	❌
백업/복구	⭕	❌
사용 목적	세션, 리더보드, 실시간 데이터	단순 조회 캐시

🧠 ElastiCache 주요 사용 패턴

1️⃣ Cache-Aside (Lazy Loading)

애플리케이션이 직접 캐시를 관리하는 가장 일반적인 패턴

1. Cache 조회
2. Cache Hit → 바로 반환
3. Cache Miss → DB 조회
4. DB 결과를 Cache에 저장

구현 단순
Cache Miss 시 지연 발생
TTL / 무효화 전략 필수

👉 “없으면 DB 가서 채운다”

2️⃣ Write-Through

DB에 쓰기 전에 항상 Cache에도 동시에 기록

항상 최신 데이터 유지
쓰기 지연 증가

👉 “Cache = DB 미러”

3️⃣ Write-Behind (Write-Back)

먼저 Cache에 쓰고, 비동기로 DB에 반영

쓰기 성능 매우 우수
Cache 장애 시 데이터 유실 위험

👉 “속도 최우선, 리스크 감수”

4️⃣ Session Store

사용자 로그인 정보, 세션 상태를 애플리케이션 서버가 아닌 ElastiCache에 저장

User
 │
[ALB]
 │
[App Server A] ─┐
[App Server B] ─┼─→ [ElastiCache (Session)]
[App Server C] ─┘

Sticky Session 불필요
서버 무상태(Stateless) 구현
Auto Scaling에 최적

👉 “어디로 가도 로그인 유지”

🔐 ElastiCache 보안

1️⃣ 네트워크 보안

VPC 내부 전용
Security Group으로 접근 제어

2️⃣ Redis AUTH

Redis 접근 시 토큰/비밀번호 요구
보안 그룹 위에 추가 보안 계층

3️⃣ 암호화

전송 중 암호화 (TLS)
저장 시 암호화 (Redis 지원)

4️⃣ IAM

ElastiCache에 대한 IAM 정책은 AWS API 제어용
Redis 데이터 접근 자체는 IAM으로 제어 ❌

👉 “IAM은 관리용, 데이터 접근은 Redis 인증”

🎮 Redis 대표 Use Case

게임 리더보드 (Sorted Set)

점수 기반 자동 정렬
실시간 순위 계산
중복 없는 랭킹 관리

👉 Sorted Set 하나로 실시간 랭킹 구현

📌 ElastiCache 사용 시 주의점

캐시는 항상 데이터 유실 가능성 존재
TTL, 무효화 전략 필수
애플리케이션 코드 변경 필요

👉 “캐시는 DB를 대체하지 않는다”

45. Amazon S3 (Simple Storage Service)

Amazon S3는 AWS의 핵심 구성 요소 중 하나로, 사실상 무한히 확장 가능한 객체 스토리지 서비스다.

S3는 단순한 파일 저장소를 넘어, 웹 서비스, 데이터 분석, 백업, 재해 복구 등 수많은 AWS 서비스와 애플리케이션의 기반 인프라로 사용된다.

중요한 점은 S3가 단순한 “디스크”가 아니라 고가용성 · 고내구성 · 글로벌 접근이 가능한 객체 스토리지라는 점이다.

🎯 S3 주요 사용 사례 (Use Cases)

백업 및 장기 스토리지
재해 복구 (Disaster Recovery)
아카이브 저장소 (저비용 장기 보관)
하이브리드 클라우드 스토리지
이미지·동영상 등 미디어 파일 호스팅
대규모 데이터 분석 (Data Lake)
소프트웨어 및 패키지 배포
정적 웹사이트 호스팅

🪣 S3 Buckets

S3는 데이터를 Bucket(버킷)이라는 단위에 저장한다. 버킷은 S3의 최상위 컨테이너 역할을 한다.

모든 객체는 반드시 하나의 버킷에 속함
버킷 이름은 전 세계적으로 유일해야 함
버킷은 특정 리전(Region)에 생성됨

S3는 전역 서비스처럼 보이지만, 버킷은 리전 단위로 물리적으로 존재한다.

📄 Objects (객체)

S3에서 실제로 저장되는 파일을 객체(Object)라고 한다.

🔑 Object Key

객체는 Key로 식별된다. 이 Key는 “파일 경로”처럼 보이지만, 실제로는 하나의 문자열이다.

s3://my-bucket/my_file.txt
s3://my-bucket/my_folder1/another_folder/my_file.txt

S3에는 실제 디렉토리 개념이 없다. 슬래시(/)는 단지 키의 일부일 뿐이다.

Prefix: my_folder1/another_folder/
Object Name: my_file.txt

📦 Object 구성 요소

객체 본문 (실제 데이터)
메타데이터 (Key-Value)
태그 (최대 10개, 보안·라이프사이클에 활용)
버전 ID (버전 관리 활성화 시)

📏 객체 크기 제한

최대 크기: 5TB
5GB 이상 파일은 Multipart Upload 필수 (100MB 이상이면 권장됨)

🔐 S3 보안 모델

S3 접근 제어는 크게 두 가지 방식으로 이루어진다.

1️⃣ User-Based (IAM Policy)

IAM 정책을 통해 “이 사용자가 어떤 S3 API를 호출할 수 있는지”를 제어한다.

2️⃣ Resource-Based (S3 정책)

S3 Bucket Policy (가장 일반적)
Object ACL (세밀하지만 비권장)
Bucket ACL (비활성화 가능)

실무에서는 Bucket Policy 하나로 대부분 해결함

📌 접근 허용 조건

IAM 정책이 허용하거나

리소스 정책이 허용하고

명시적인 Deny가 없어야 함

🔒 Encryption (암호화)

S3는 객체를 암호화된 상태로 저장할 수 있다.

서버 측 암호화 (SSE-S3, SSE-KMS)

업로드 시 암호화 강제 가능 (Bucket Policy)

🚫 Block Public Access

기업 데이터 유출을 방지하기 위해 AWS가 제공하는 추가 보안 계층

버킷 정책이 Public이어도 접근 차단

계정 단위 또는 버킷 단위 설정 가능

👉 “절대 공개되면 안 되는 버킷”에는 항상 활성화한다.

🔐 S3 사전 서명 URL (Pre-Signed URL)🔐

S3 사전 서명 URL은
IAM 자격 증명이 없는 사용자에게도 제한된 시간 동안 특정 S3 객체에 접근할 수 있도록 허용하는 임시 URL이다.

쉽게 말하면
“권한이 없는 사용자에게 잠깐만 접근권을 빌려주는 링크”다.

📌 왜 필요한가?

S3 버킷을 퍼블릭으로 열면 보안 위험이 크다.
하지만 특정 파일을 외부 사용자에게 잠깐 제공해야 하는 경우가 있다.

예:

이미지 업로드 URL 발급

다운로드 링크 제공

모바일 앱에서 직접 S3 업로드

이때 사용하는 것이 Pre-Signed URL이다.

🌐 Static Website Hosting

S3는 정적 웹사이트를 직접 호스팅할 수 있다.

HTML / CSS / JS 호스팅 가능

리전별 엔드포인트 URL 제공

Public Read 정책 필요

🕓 Bucket Versioning

버킷 단위로 객체의 버전 관리를 활성화할 수 있다.

같은 키로 업로드 시 새 버전 생성

실수로 삭제된 파일 복구 가능

이전 상태로 롤백 가능

⚠️ 버전 관리를 중단해도 기존 버전은 삭제되지 않는다.

🔁 S3 Replication (CRR & SRR)

CRR: Cross-Region Replication

SRR: Same-Region Replication

📌 복제 조건

소스/대상 버킷 모두 버전 관리 활성화

비동기 복제

계정 간 복제 가능

📌 주의사항

복제 활성화 이후 객체만 복제

기존 객체는 배치 복제 필요

체이닝 복제 불가

🗄️ S3 Storage Classes

S3 Standard

S3 Standard-IA

S3 One Zone-IA

S3 Glacier Instant Retrieval

S3 Glacier Flexible Retrieval

S3 Glacier Deep Archive

S3 Intelligent-Tiering

📦 1. S3 Standard 계열 (일반 목적 스토리지)

🔹 S3 Standard

가장 기본적인 스토리지 클래스. 높은 내구성(99.999999999%)과 높은 가용성을 제공하며, 자주 액세스되는 데이터를 위한 기본 선택지다.

선택 상황

웹사이트 콘텐츠

모바일/게임 애플리케이션 데이터

빅데이터 분석용 원본 데이터

실시간 접근이 필요한 데이터

🔹 S3 Standard-IA (Infrequent Access)

자주 사용되지는 않지만 필요 시 즉시 접근해야 하는 데이터에 적합하다. 스토리지 비용은 Standard보다 저렴하지만 데이터 접근 시 비용이 발생함.

선택 상황

백업 파일

장기 보관 데이터

재해 복구(Disaster Recovery) 데이터

🔹 S3 One Zone-IA

Standard-IA와 유사하지만 단일 AZ(가용 영역)에만 저장된다. 비용은 더 저렴하지만 AZ 장애 발생 시 데이터 손실 위험이 존재한다.

선택 상황

복구 가능한 2차 백업

쉽게 재생성 가능한 데이터

비용 최적화가 최우선인 경우

🧊 2. S3 Glacier 계열 (아카이브 스토리지)

🔹 S3 Glacier Instant Retrieval

아카이브 목적이지만 즉시 조회가 필요한 데이터에 적합하다. Standard-IA보다 저렴하면서 밀리초 단위 접근이 가능하다.

선택 상황

의료 영상 데이터

금융 기록

장기 보관이지만 즉시 조회가 필요한 데이터

🔹 S3 Glacier Flexible Retrieval (기존 Glacier)

몇 분에서 몇 시간 내 복원이 가능하다. 스토리지 비용이 매우 저렴하며 장기 보관 목적에 적합하다.

선택 상황

규정 준수 목적의 데이터 보관

드물게 접근하는 백업 데이터

복원 시간이 크게 중요하지 않은 경우

🔹 S3 Glacier Deep Archive

가장 저렴한 스토리지 옵션이다. 복원에 12시간 이상이 소요될 수 있다.

선택 상황

5~10년 이상 장기 보관 데이터

법적 보존 의무 데이터

거의 접근하지 않는 데이터

🤖 3. S3 Intelligent-Tiering

접근 패턴을 예측하기 어려운 데이터를 위한 자동 최적화 스토리지다. 액세스 패턴에 따라 자동으로 비용이 가장 낮은 티어로 이동한다. 운영 관리 부담을 줄이면서 비용을 최적화할 수 있다.

선택 상황

사용 빈도를 예측하기 어려운 데이터

운영 관리 부담을 줄이고 싶은 경우

자동 비용 최적화가 필요한 환경

📌 선택 기준 요약

사용 패턴 추천 스토리지

자주 접근 S3 Standard

가끔 접근, 즉시 필요 Standard-IA

비용 우선, 단일 AZ 가능 One Zone-IA

아카이브 + 즉시 접근 Glacier Instant Retrieval

아카이브 + 몇 분~시간 허용 Glacier Flexible Retrieval

거의 접근 없음 Glacier Deep Archive

패턴 예측 불가 Intelligent-Tiering

46. AWS Storage Architecture

AWS 스토리지 서비스는 단순히 “저장소 종류가 많은 것”이 아니라, 워크로드 특성 · 접근 방식 · 온프레미스 연계 여부에 따라 선택하는 구조적 설계 문제다.

따라서 시험이나 실무에서 가장 중요한 것은 “이 상황에서는 어떤 스토리지를 선택해야 하는가?”를 판단하는 능력이다.

🧭 스토리지 선택의 3가지 기준

데이터 접근 방식 (객체 / 파일 / 블록)

온프레미스 연동 필요 여부

성능 요구사항 (IOPS / Throughput / Latency)

1️⃣ Snow Family – 네트워크 한계를 극복하는 물리적 전송

“네트워크가 병목이 될 때 사용하는 오프라인 데이터 전송 전략”

📌 개념

온라인 전송이 1주 이상 걸리면 고려

대역폭 공유, 불안정 연결 문제 해결

데이터 전송 비용 절감

🚚 서비스 구분

Snowcone – 소형, 엣지 컴퓨팅 가능

Snowball Edge – 대용량 + 컴퓨팅 가능

Snowmobile – 엑사바이트 단위 마이그레이션

Snow는 직접 Glacier로 업로드하지 않고
→ S3 → Lifecycle 정책 → Glacier 구조를 사용한다.

2️⃣ Amazon FSx – 관리형 파일 시스템의 집합

“특정 파일 시스템을 AWS가 대신 운영해주는 서비스”

RDS가 데이터베이스 엔진을 관리해주는 것과 동일한 개념이다.

📂 FSx 서비스 비교

서비스 주 사용 환경 프로토콜 핵심 특징
FSx for Windows Windows 환경 SMB AD 통합, NTFS, ACL
FSx for Lustre HPC, ML POSIX 초고성능, 병렬 처리
FSx for NetApp ONTAP 하이브리드 환경 NFS/SMB/iSCSI 스냅샷, 중복 제거, 복제
FSx for OpenZFS ZFS 워크로드 NFS ZFS 기능 완전 지원

🔥 FSx for Lustre의 차이

Scratch → 임시, 복제 없음, 비용 절감

Persistent → 동일 AZ 복제, 장애 대응

즉, ML 학습처럼 “다시 계산 가능”한 데이터는 Scratch
재생산이 어려운 데이터는 Persistent.

3️⃣ Hybrid Storage – 온프레미스와 AWS 연결

기업은 모든 데이터를 한 번에 AWS로 옮기지 않는다. 따라서 브릿지 역할이 필요하다.

🔗 Storage Gateway

Storage Gateway는 온프레미스에 설치된다. AWS 내부 서비스가 아님

Gateway 종류 프로토콜 백엔드 용도
S3 File Gateway NFS/SMB S3 파일 공유
FSx File Gateway SMB FSx Windows Windows 네이티브 파일 공유
Volume Gateway iSCSI S3 + Snapshot 블록 스토리지 백업
Tape Gateway iSCSI VTL S3 + Glacier 테이프 대체

⚡ Volume Gateway 모드 차이

Cached Mode → 대부분 데이터는 S3, 로컬은 캐시

Stored Mode → 전체 데이터는 온프레미스, S3는 백업

재해 복구 중심이면 Cached, 온프레미스 주 저장이면 Stored.

4️⃣ Transfer Family – 레거시 프로토콜 대응

많은 기업은 여전히 FTP 기반 시스템을 사용한다.

FTP

FTPS

SFTP

이 서비스는 S3나 EFS를 FTP 인터페이스로 제공한다.

중요한 점: 파일 전송 인터페이스를 제공하는 것이지 저장소가 아니다.

5️⃣ AWS DataSync – 고속 데이터 동기화

파일 권한과 메타데이터까지 보존하는 엔터프라이즈 동기화 서비스

📌 특징

10Gbps 전송 가능

NFS / SMB 권한 유지

스케줄 기반 실행

온프레미스 ↔ AWS

AWS ↔ AWS

온프레미스 ↔ S3 / EFS / FSx 전송 가능

자동 데이터 검증 수행

전송 중 및 전송 후 무결성 확인

암호화 전송

증분 복사 지원

병렬 전송 최적화

지속적 실시간 복제가 아닌,
“스케줄 기반 동기화”

6️⃣ 스토리지 선택 전략

서비스 스토리지 유형 접근 방식 / 프로토콜 주요 사용 상황 핵심 특징
Amazon S3 객체(Object) HTTP / REST API 백업, 데이터 레이크, 정적 웹 호스팅 무한 확장, 11 9's 내구성, 대부분 AWS 서비스와 연동
S3 Glacier 객체 아카이브 REST API 장기 보관, 규제 준수 데이터 저비용, 복구 지연 존재
Amazon EBS 블록(Block) EC2 직접 연결 DB, 트랜잭션 시스템 단일 AZ, 고성능 IOPS, io1/io2 다중 연결 지원
Instance Store 물리적 블록 EC2 로컬 디스크 임시 캐시, 고성능 처리 초고속 IOPS, 인스턴스 종료 시 데이터 삭제
Amazon EFS 파일(File) NFS (POSIX) Linux 다중 인스턴스 공유 Multi-AZ, 자동 확장, 서버리스
FSx for Windows 파일(File) SMB Windows 파일 서버, AD 환경 NTFS, ACL, AD 통합
FSx for Lustre 파일(File) POSIX HPC, ML, 대규모 병렬 연산 초고속 처리, S3와 통합 가능
FSx for NetApp ONTAP 파일 + 블록 NFS / SMB / iSCSI 하이브리드 NAS 마이그레이션 스냅샷, 복제, 중복 제거, 압축 지원
FSx for OpenZFS 파일(File) NFS ZFS 기반 워크로드 ZFS 기능 완전 지원, 고성능
S3 File Gateway 하이브리드 파일 NFS / SMB 온프레미스 파일 → S3 연결 로컬 캐시, IAM 연동
FSx File Gateway 하이브리드 파일 SMB 온프레미스 ↔ FSx Windows 로컬 캐시, AD 통합
Volume Gateway 하이브리드 블록 iSCSI 온프레미스 볼륨 백업 S3에 스냅샷 저장, Cached/Stored 모드
Tape Gateway 하이브리드 아카이브 iSCSI VTL 테이프 백업 대체 S3 + Glacier 기반 가상 테이프
AWS Transfer Family 전송 인터페이스 FTP / FTPS / SFTP 레거시 파일 전송 유지 S3/EFS를 FTP처럼 사용
AWS DataSync 동기화 서비스 NFS / SMB / API 대용량 정기 동기화 10Gbps 전송, 메타데이터 유지
Snow Family 오프라인 전송 물리 장치 초대용량 초기 마이그레이션 네트워크 병목 제거

7️⃣ AWS Storage Gateway – 유형별 비교

Gateway 유형 연결 대상 (AWS) 프로토콜 온프레미스 저장 방식 주요 목적 대표 사용 상황
S3 File Gateway Amazon S3 NFS / SMB 자주 쓰는 데이터 로컬 캐시 파일 기반 → 객체 스토리지 연결 온프레미스 파일 서버를 S3에 연결
FSx File Gateway FSx for Windows SMB 로컬 캐시 Windows 파일 서버 하이브리드 구성 AD 환경, Windows 공유 드라이브 확장
Volume Gateway (Cached) Amazon S3 (EBS 스냅샷 형태) iSCSI 핫 데이터만 캐시 저지연 블록 스토리지 온프레미스 앱 + 클라우드 백업
Volume Gateway (Stored) Amazon S3 (백업용) iSCSI 전체 데이터 온프레미스 유지 정기 백업 온프레미스 볼륨 전체 백업
Tape Gateway S3 + Glacier iSCSI (VTL) 테이프 캐시 물리 테이프 대체 기존 백업 시스템 유지 + 클라우드 아카이브

📌 핵심 구조 차이

구분 File Gateway Volume Gateway Tape Gateway
스토리지 유형 파일 블록 가상 테이프
주 사용 목적 파일 공유 확장 백업 / DR 레거시 테이프 대체
백엔드 저장소 S3 S3 (EBS Snapshot) S3 → Glacier
레거시 시스템 유지 가능 가능 가장 적합

🧠 선택 전략

• 파일 공유를 그대로 S3에 연결 → S3 File Gateway
• 블록 스토리지 백업 필요 → Volume Gateway
• 테이프 백업 시스템 유지하면서 클라우드 전환 → Tape Gateway
• Windows 파일 서버 하이브리드 → FSx File Gateway

📊 Amazon S3 Storage Lens

Amazon S3 Storage Lens는
S3 스토리지 사용 현황과 활동 패턴을 조직 단위까지 분석·가시화해주는 분석 서비스다.

“S3를 얼마나 쓰고 있는지, 어디에서 비용이 발생하는지, 비효율은 없는지”를 보여주는 관리형 분석 도구다.

🎯 왜 필요한가?

대규모 S3 환경에서는:

버킷 수백~수천 개

계정 다수

리전 분산

스토리지 클래스 다양

이런 상황에서
비용 최적화 / 보안 위험 탐지 / 비활성 객체 파악이 어렵다.

Storage Lens는 이를 중앙에서 분석해준다.

47. Amazon SQS (Simple Queue Service)

Amazon SQS는 완전 관리형 메시지 큐 서비스다.

목적: 애플리케이션 간 결합도(Decoupling)를 낮추는 것

Producer와 Consumer 사이에 큐를 두어 서로 직접 통신하지 않도록 만듦

🔄 기본 구조

Producer → SQS Queue → Consumer

Producer는 메시지를 큐에 넣는다.

Consumer는 Polling 방식으로 메시지를 가져온다.

처리 완료 후 DeleteMessage API 호출 필수.

트래픽 완충 장치(Buffer) 역할을 한다.

🎯 Standard Queue 특징

무제한 처리량

at-least-once delivery (중복 가능)

Best-effort ordering (순서 보장 없음)

메시지 최대 256KB

보존 기간 최대 14일

중복 가능성이 있으므로 idempotent 설계가 필요하다.

📌 FIFO Queue 특징

정확한 순서 보장

Exactly-once processing (중복 제거)

처리량 제한 존재

Message Group ID 기반 병렬 처리

순서가 중요한 금융 트랜잭션, 주문 처리 등에 사용된다.

👀 Polling과 Long Polling

Consumer는 큐에 메시지가 있는지 직접 요청한다. 이를 Polling이라 한다.

Short Polling: 즉시 응답

Long Polling: 최대 20초 대기

Long Polling은 API 호출 수 감소 + 비용 절감 목적

⏳ Visibility Timeout

Consumer가 메시지를 가져가면 일정 시간 동안 다른 소비자에게 보이지 않는다.

기본 30초

DeleteMessage 호출하지 않으면 재전송

ChangeMessageVisibility로 조정 가능

너무 짧으면 중복 처리, 너무 길면 장애 복구 지연.

📈 SQS + Auto Scaling Group

CloudWatch Metric: ApproximateNumberOfMessages

큐 길이 증가 → 스케일 아웃

큐 길이 감소 → 스케일 인

대규모 이벤트, 주문 폭증 상황에서 매우 자주 사용됨

🔐 보안

HTTPS 전송 암호화

SSE-KMS 서버 측 암호화

IAM 정책 기반 접근 제어

SQS Access Policy로 교차 계정 허용

🎯 언제 사용할까?

애플리케이션 티어 분리

DB 트래픽 완충

비동기 작업 처리

백엔드 워커 확장 구조

Decouple -> SQS

48. Amazon SNS (Simple Notification Service)

Pub/Sub 기반 메시징 서비스

하나의 메시지를 여러 구독자에게 동시에 전달한다.

📢 기본 구조

Producer → SNS Topic → 여러 Subscriber

Producer는 Topic에 Publish

Subscriber는 자동으로 메시지 수신 (Push)

SQS와 가장 큰 차이: SNS는 Push 방식.

🎯 주요 목적

Fan-Out 아키텍처

이벤트 브로드캐스트

알림 시스템

📌 특징

최대 1,250만 구독자

메시지 보관 없음

필터 정책(JSON) 지원

여러 AWS 서비스와 통합

메시지는 저장되지 않기 때문에 지속성이 필요하면 SQS와 결합한다.

🔁 SNS + SQS Fan-Out 패턴

SNS Topic → 여러 SQS Queue 구독

데이터 손실 방지

재시도 가능

독립적 확장 가능

실무에서 매우 자주 등장하는 패턴.

📌 SNS FIFO Topic

순서 보장

중복 제거

SQS FIFO만 구독 가능

.fifo 이름 필수

정렬 + Fan-out이 동시에 필요할 때 사용

🔎 Message Filtering

구독자는 JSON 필터 정책을 사용해 특정 메시지만 받을 수 있다.

하나의 Topic으로 여러 비즈니스 로직 분기 가능.

🔐 보안

HTTPS 암호화

KMS 암호화

IAM 정책

SNS Access Policy로 교차 계정 허용

🎯 언제 사용할까?

하나의 이벤트를 여러 서비스에 전달

마이크로서비스 간 이벤트 통합

알림 시스템 구축

Broadcast / Fan-out 키워드 -> SNS다.

49. Amazon Kinesis (Data Streams & Data Firehose)

Amazon Kinesis는 대규모 실시간 데이터 스트리밍 플랫폼이다.

로그, IoT 데이터, 클릭 스트림, 금융 트랜잭션처럼 초당 수천~수백만 건의 데이터를 지속적으로 처리해야 할 때 사용된다.

SQS가 “작업 큐”라면, Kinesis는 “데이터 스트림 파이프라인”이다.

📊 Kinesis Data Streams

실시간 데이터 스트림을 수집하고, 여러 Consumer가 반복적으로 읽을 수 있게 한다.

🔹 구조

Producer → Kinesis Stream → Consumer

Stream은 여러 개의 Shard로 구성

Partition Key를 해싱하여 샤드 결정

같은 Partition Key는 같은 샤드로 들어감

📌 샤드(Shard)의 의미

쓰기: 1MB/sec 또는 1000 records/sec

읽기: 2MB/sec

샤드 수 = 처리량

확장이 필요하면 샤드를 늘린다.

📌 특징

보존 기간: 1~365일

데이터 재처리 가능

데이터 삭제 불가 (Immutable)

여러 Consumer가 동일 데이터 읽기 가능

이 점이 SQS와 가장 큰 차이다.
Kinesis는 데이터를 재생(replay)할 수 있다.

📈 Capacity Modes

1️⃣ Provisioned Mode

샤드 수 직접 설정

시간당 샤드 비용 발생

2️⃣ On-Demand Mode

자동 확장

트래픽 예측 불필요

🚰 Kinesis Data Firehose

완전 서버리스 데이터 전송 서비스

S3

Redshift

OpenSearch

HTTP Endpoint

Streams와 달리:

샤드 관리 없음

자동 확장

배치 기반 전송

Firehose는 “실시간에 가까운 배치 전송 서비스”

📊 Kinesis vs SQS FIFO 정렬 차이

항목 Kinesis SQS FIFO

정렬 기준 Partition Key Message Group ID

병렬성 샤드 수 Group 수

재처리 가능 불가

대규모 스트리밍 분석 → Kinesis 작업 순서 보장 → SQS FIFO

🎯 언제 사용할까?

실시간 빅데이터 분석

로그 파이프라인 구축

IoT 데이터 수집

ETL 처리

“실시간 분석” -> Kinesis

50. Amazon MQ (Managed Message Broker)

Amazon MQ는 관리형 메시지 브로커 서비스다.

SQS/SNS와 달리, 브로커 서버 기반 구조다.

📌 지원 기술

ActiveMQ (JMS 기반)

RabbitMQ (AMQP 기반)

MQTT, AMQP, STOMP, OpenWire 등 개방형 프로토콜을 지원한다.

🎯 왜 사용하는가?

기존 JMS 애플리케이션 이전

레거시 메시징 시스템 유지

프로토콜 변경 없이 클라우드 마이그레이션

신규 설계에서는 잘 사용하지 않는다. 레거시 호환 목적이 핵심이다.

📌 구조

Producer → MQ Broker → Consumer

브로커가 중앙에서 관리

연결 유지 필요

상태 기반 아키텍처

📈 고가용성

Multi-AZ 배포 가능

EFS 기반 스토리지 사용 가능

자동 장애 복구

하지만:

SQS/SNS보다 확장성 낮음

완전 서버리스 아님

📊 SQS vs MQ 차이

항목 SQS Amazon MQ

아키텍처 서버리스 브로커 서버

확장성 무제한 제한적

프로토콜 AWS API JMS, AMQP 등

주 용도 신규 클라우드 설계 레거시 이전

🎯 언제 사용할까?

은행, 보험사 등 기존 JMS 기반 시스템

AMQP 기반 마이크로서비스 이전

온프레미스 메시지 브로커를 그대로 유지해야 할 때

JMS / AMQP / MQTT 키워드 -> MQ

51. Serverless

📌 Serverless란?

Serverless는 “서버가 없다”는 뜻이 아니다.
서버를 직접 관리할 필요가 없다는 의미다.

서버 프로비저닝 불필요

운영/패치/확장 자동화

코드만 배포하면 실행

초기에는 FaaS(Function as a Service)를 의미했지만,
현재는 완전 관리형 서비스 전반을 포함하는 개념이다.

AWS in Serverless 🚀

AWS에서는 인프라를 직접 프로비저닝하지 않는 서비스들을 서버리스로 분류한다.

AWS Lambda

DynamoDB

API Gateway

S3

Cognito

SNS / SQS

Kinesis Data Firehose

Aurora Serverless

Step Functions

Fargate

📌 대표적인 서버리스 아키텍처

Users │ ├── Static Content → S3 │ ├── Log-in → Cognito │ └── REST API → API Gateway │ ▼ Lambda │ ▼ DynamoDB

완전 관리형 서비스들만으로 웹 애플리케이션 구성이 가능하다.

52. AWS Lambda 🔥

📌 개념

서버 관리 불필요

온디맨드 실행

자동 스케일링

짧은 실행 시간 기반

📌 EC2 vs Lambda

항목 EC2 Lambda

운영 방식 가상 서버 가상 함수

실행 방식 항상 실행 요청 시 실행

확장 서버 추가 필요 자동

과금 시간 단위 실행 시간 단위

📌 장점

실행 시간 기반 과금

CloudWatch와 통합

다양한 언어 지원

최대 10GB 메모리 설정 가능

📌 실행 한도

최대 실행 시간 900초

메모리 128MB ~ 10GB

/tmp 512MB ~ 10GB

동시 실행 기본 1000

📌 배포 한도

ZIP 50MB (압축)

컨테이너 이미지 지원

Lambda 주요 통합 🔗

API Gateway → REST API 처리

DynamoDB → 스트림 트리거

S3 → 파일 업로드 트리거

SNS / SQS → 메시지 처리

CloudWatch Events / EventBridge → 스케줄 실행

CloudFront → Lambda@Edge

📌 예시 1 : 서버리스 썸네일 생성

S3 (이미지 업로드) │ ▼ Lambda │ ├── 썸네일 저장 → S3 └── 메타데이터 → DynamoDB

📌 예시 2 : Serverless CRON

EventBridge (매 1시간) │ ▼ Lambda

Lambda in VPC 🌐

📌 기본 구조

Public Lambda ──► DynamoDB (가능) Public Lambda ──X► Private RDS (불가능)

기본 Lambda는 AWS 내부 네트워크에서 실행된다.
Private Subnet의 RDS 접근 불가하다.

📌 해결 방법

Lambda를 VPC 내부에 배치

서브넷 지정

보안 그룹 설정

📌 내부 구조

Lambda Function │ ▼ ENI (Elastic Network Interface) │ ▼ Private Subnet │ ▼ RDS

Lambda는 ENI를 생성해 VPC 내부 리소스에 접근한다.

Lambda + RDS Proxy 🗄️

📌 문제

Lambda는 스케일링 시 DB 연결이 폭증한다.

📌 해결

RDS Proxy 사용

Lambda x 1000 │ ▼ RDS Proxy (Connection Pool) │ ▼ RDS DB

📌 장점

Connection Pool 관리

장애 복구 시간 단축

IAM 인증 지원

Lambda@Edge & CloudFront Functions 🌍

📌 Edge에서 코드 실행

CloudFront는 4단계에서 요청 수정 가능하다.

Client │ Viewer Request │ CloudFront │ Origin Request │ Origin │ Origin Response │ Viewer Response

📌 CloudFront Functions

JavaScript 전용

실행 시간 < 1ms

Viewer 단계만 수정

초고속, 초경량

📌 Lambda@Edge

Node.js / Python

Origin 요청/응답 수정 가능

최대 5~10초 실행

외부 서비스 호출 가능

📊 비교

항목 CloudFront Functions Lambda@Edge

런타임 JavaScript Node.js / Python

실행 시간 < 1ms 최대 5~10초

트리거 Viewer 단계 Viewer + Origin

네트워크 접근 불가 가능

📌 사용 사례

URL 리다이렉션

JWT 검증

SEO 최적화

A/B 테스트

이미지 실시간 변환

🎯 전체 서버리스 정리

Client │ CloudFront │ API Gateway │ Lambda │ DynamoDB

서버 없이도 글로벌 확장 가능한 아키텍처 구현 가능하다.

핵심은 “서버를 관리하지 않는다”는 점

53. Amazon DynamoDB 🚀

DynamoDB는 완전 관리형(NoSQL) 분산 데이터베이스다.

다중 AZ 자동 복제

초당 수백만 요청 처리

한 자릿수 밀리초 지연시간

IAM 기반 보안 통합

서버 프로비저닝 불필요

자동 스케일링 지원

Standard / IA 스토리지 클래스

관계형이 아니지만 트랜잭션을 지원함.

DynamoDB 기본 구조 📦

DynamoDB는 데이터베이스를 생성하지 않고,
테이블 단위로 동작한다.

📌 테이블 구성

Primary Key (필수)

Partition Key

Sort Key (선택)

Attributes (Nullable)

Table ├── Item (Row) │ ├── PK │ ├── SK (optional) │ └── Attributes

📌 특징

아이템 무한 추가

스키마 자유

컬럼 사전 정의 불필요

아이템 최대 400KB

📌 데이터 타입

Scalar: String, Number, Binary, Boolean, Null

Document: List, Map

Set: String Set, Number Set, Binary Set

빠른 스키마 전개가 필요한 경우 적합

Read / Write Capacity Modes ⚙️

① 프로비저닝 모드

RCU / WCU 사전 지정

예측 가능한 워크로드에 적합

오토스케일링 가능

비용 절감 효과적

② 온디맨드 모드

용량 계획 불필요

자동 확장

예측 불가능한 트래픽에 적합

항목 Provisioned On-Demand

용량 설정 사전 지정 자동

비용 저렴 상대적으로 높음

적합한 환경 예측 가능 급격한 트래픽

DynamoDB 고급 기능 🚀

📌 DAX (DynamoDB Accelerator)

인메모리 캐시

마이크로초 지연시간

기존 API와 호환

TTL 기본 5분

📌 DAX vs ElastiCache

항목 DAX ElastiCache

용도 DynamoDB 캐시 범용 캐시

쿼리 캐시 가능 직접 구현

집계 결과 비추천 적합

DynamoDB Streams 🔄

테이블 변경사항(생성/수정/삭제)을 스트림으로 생성한다.

보존 기간 24시간

Lambda 트리거 가능

실시간 이벤트 처리

DynamoDB │ ▼ Streams │ ▼ Lambda

📌 Kinesis Data Streams 통합

최대 1년 보존

다양한 소비자 지원

대규모 분석 처리 적합

DynamoDB Global Tables 🌍

여러 리전에 자동 복제되는 다중 활성 테이블이다.

양방향 복제

모든 리전에서 읽기/쓰기 가능

Streams 활성화 필요

Region A ↔ Region B ↔ Region C

TTL & 백업 🛡

📌 TTL

시간 경과 시 자동 삭제

세션 관리에 자주 사용

📌 백업

PITR (35일)

온디맨드 백업

복구 시 새 테이블 생성

S3 통합 📂

Export

PITR 활성화 필요

성능 영향 없음

JSON / ION 포맷

Import

CSV / JSON / ION 지원

쓰기 용량 소비 없음

54. API Gateway 🌐

Lambda와 통합하면 완전 서버리스 REST API 구현 가능하다.

📌 기능

API 버저닝

인증/인가

쓰로틀링

응답 캐싱

Swagger / OpenAPI 지원

📌 통합 방식

Lambda

HTTP Backend

AWS Service (예: SQS)

Endpoint Types 📡

Edge-Optimized → 글로벌

Regional → 특정 리전

Private → VPC 내부

API Gateway Security 🔐

IAM 인증

Cognito 통합

Custom Authorizer

ACM 기반 HTTPS

55. AWS Step Functions 🔁

서버리스 워크플로 오케스트레이션 서비스

Lambda 시퀀싱

병렬 실행

조건 분기

에러 핸들링

타임아웃 설정

Lambda A │ ▼ Choice ├── Lambda B └── Lambda C

주문 처리, 데이터 파이프라인, 복잡한 비즈니스 로직에 적합하다.

🔁 Map State 실행 모드

1️⃣ Inline Mode (기본)

기본 Map 실행 방식

최대 40개 병렬 실행

단일 실행 컨텍스트 내에서 처리

소규모 병렬 작업에 적합

👉 반복 개수가 적고 단순 병렬 처리가 필요할 때 사용한다.

2️⃣ Distributed Mode (대규모 처리)

각 반복이 별도 Child Execution으로 실행

최대 10,000개 병렬 실행 가능

S3 대용량 데이터 처리 가능

대규모 ETL 및 데이터 처리에 적합

👉 수천 개 이상의 대규모 병렬 처리가 필요할 때 사용한다.

📌 소규모 반복 → Inline
📌 대규모 데이터 처리 → Distributed

56. Amazon Cognito 🔐

Amazon Cognito는 완전 관리형 사용자 인증 및 권한 부여 서비스다.

회원가입 / 로그인 처리

JWT 토큰 발급

MFA 지원

소셜 로그인 연동

IAM과 통합

서버 구축 불필요

웹 및 모바일 애플리케이션에서 서버리스 인증 시스템을 구축할 때 사용된다.

Cognito 구성 요소 🧩

📌 User Pool (인증)

사용자 디렉터리 역할을 하며 인증(Authentication)을 담당한다.

회원가입 / 로그인

비밀번호 정책 관리

이메일 / 휴대폰 인증

MFA 설정

JWT 토큰 발급

로그인 성공 시 3가지 토큰을 발급한다.

ID Token → 사용자 정보 포함

Access Token → API 접근 권한

Refresh Token → 토큰 재발급

📌 Identity Pool (인가)

인가(Authorization)를 담당하며 AWS 리소스 접근 권한을 부여한다.

임시 IAM Role 발급

S3 접근

DynamoDB 접근

AWS API 호출

User Pool = 인증
Identity Pool = AWS 리소스 접근 권한

Cognito + API Gateway 구조 🌐

Client ↓ Cognito 로그인 ↓ JWT 발급 ↓ API Gateway (Cognito Authorizer) ↓ Lambda 실행

API Gateway에서 JWT를 검증하여 완전 서버리스 인증 구조를 구성한다.

소셜 로그인 및 보안 🔐

📌 소셜 로그인 지원

Google

Facebook

Apple

SAML

OIDC

📌 SAML (기업 SSO 연동)

SAML(Security Assertion Markup Language)은 기업 환경에서 사용하는 표준 인증 프로토콜이다.

Cognito는 외부 SAML Identity Provider(IdP)와 연동하여 기업 계정 기반 SSO를 지원한다.

User ↓ Cognito (Service Provider 역할) ↓ SAML Identity Provider (Okta / Azure AD 등) ↓ SAML Assertion 반환 ↓ Cognito JWT 발급

사내 AD 계정으로 로그인 가능

IAM 사용자 생성 불필요

기업 SSO 통합 가능

클라우드 + 온프레미스 연계 인증 지원

👉 기업 환경에서 “사내 계정으로 AWS 서비스 로그인” 요구 시 SAML을 사용한다.

📌 보안 기능

MFA 지원

비밀번호 정책 설정

계정 잠금 정책

JWT 서명 기반 검증

IAM 통합

핵심 포인트 📝

User Pool은 인증

Identity Pool은 IAM Role 부여

JWT 기반 인증

SAML / OIDC 외부 IdP 연동 가능

API Gateway Authorizer와 통합

완전 관리형 서비스

Amazon Cognito는 서버를 직접 구축하지 않고도 안전한 사용자 인증과 AWS 리소스 접근 제어를 구현할 수 있는 완전 관리형 서비스다.

57. Amazon DocumentDB (for MongoDB) 📄

Amazon DocumentDB는 MongoDB와 호환되는 완전 관리형 NoSQL 문서 데이터베이스

MongoDB API 호환

JSON 문서 저장

완전 관리형

3 AZ에 걸쳐 자동 복제

대규모 읽기 확장 가능

📌 JSON 형태의 문서 데이터를 저장한다.

{ "user_id": 101, "name": "Kim", "orders": [ {"item": "Laptop", "price": 1200}, {"item": "Mouse", "price": 30} ] }

관계형 JOIN 대신 문서 안에 중첩 데이터로 저장

📌 언제 사용하는가?

기존 MongoDB 앱을 AWS로 이전할 때

JSON 기반 애플리케이션

카탈로그 서비스

콘텐츠 관리 시스템

📌 DynamoDB vs DocumentDB

항목 DynamoDB DocumentDB

API AWS 전용 MongoDB 호환

구조 Key-Value Document

쿼리 유연성 제한적 강력

사용 사례 초고속 트랜잭션 복잡한 JSON 데이터

58. Amazon Neptune 🔗

완전 관리형 그래프 데이터베이스

그래프 구조 저장

3 AZ 복제

최대 15개 Read Replica

수십억 관계 저장 가능

밀리초 단위 응답

📌 그래프 데이터란?

User A → 친구 → User B User B → 팔로우 → User C User A → 좋아요 → 게시글 123

관계가 중심이 되는 데이터

📌 사용 사례

소셜 네트워크

추천 엔진

사기 탐지

지식 그래프 (위키피디아)

📌 언제 Neptune을 선택하는가?

데이터보다 “관계”가 더 중요한 경우.

59. Amazon Keyspaces (for Apache Cassandra) 🧱

완전 관리형 Apache Cassandra 호환 NoSQL DB

Cassandra Query Language(CQL) 지원

3 AZ 복제

10ms 미만 지연

온디맨드 / 프로비저닝 모드

PITR 35일

📌 사용 사례

IoT 장치 데이터

시계열 이벤트

대규모 분산 로그

📌 DynamoDB vs Keyspaces

항목 DynamoDB Keyspaces

API AWS 전용 Cassandra CQL

마이그레이션 불가 Cassandra 이전 가능

서버리스 완전 서버리스 관리형 Cassandra

60. Amazon QLDB (Quantum Ledger Database) 📜

변하지 않는 원장 데이터베이스
*Ledger: 금융 트랜잭션을 기록하는 장부

모든 변경 이력 저장

삭제/수정 불가

암호학적 검증

3 AZ 복제

SQL 지원

📌 내부 개념

Transaction ↓ Journal ↓ Hash Chain

데이터 변경이 위변조되지 않았음을 증명 가능하다.

📌 사용 사례

금융 트랜잭션 기록

보험 계약 이력

차량 소유권 추적

61. Amazon Timestream ⏱

완전 관리형 서버리스 시계열 데이터베이스

시간 기반 데이터 최적화

자동 확장

메모리 + 장기 스토리지 계층

SQL 지원

실시간 분석 가능

📌 시계열 데이터 예시

Timestamp Temperature 2024-01-01 10:00 22.1 2024-01-01 10:01 22.3

📌 사용 사례

IoT 센서 데이터

서버 모니터링

실시간 운영 분석

언제 어떤 DB를 선택할까? 🎯

DB 유형 주요 특징 대표 사용처
RDS 관계형 관리형 SQL DB 전통적 웹앱
Aurora 관계형 고성능 클라우드 최적화 대규모 트래픽 서비스
DynamoDB NoSQL 초고속 Key-Value 모바일, 게임
DocumentDB 문서형 MongoDB 호환 JSON 중심 앱
Neptune 그래프 관계 중심 데이터 추천, 소셜 네트워크
Keyspaces NoSQL (Cassandra) 분산 대규모 처리 IoT, 로그
QLDB 원장 DB 불변 이력 저장 금융, 감사
Timestream 시계열 시간 기반 데이터 분석 IoT, 모니터링

전체 DB 선택 기준 요약 🧠

JOIN 필요 → RDS / Aurora

초고속 Key-Value → DynamoDB

JSON 문서 구조 → DocumentDB

관계 중심 그래프 → Neptune

Cassandra 앱 이전 → Keyspaces

위변조 방지 이력 관리 → QLDB

시간 기반 데이터 → Timestream

62. Amazon Athena 🔍

S3에 저장된 데이터를 직접 SQL로 분석할 수 있는 서버리스 쿼리 서비스

서버리스 (프로비저닝 불필요)
Presto 기반 SQL 엔진

S3 데이터를 직접 분석

TB당 스캔 데이터 기준 과금

QuickSight와 통합 가능

📌 사용 예시

CloudTrail 로그 분석

VPC Flow Logs 분석

로드 밸런서 로그 분석

임시 BI 쿼리

SELECT * FROM cloudtrail_logs WHERE eventName = 'CreateUser';

📌 성능 향상 전략

Columnar 포맷 사용 (Parquet, ORC)

데이터 압축

Partitioning (예: year/month/day)

작은 파일 대신 큰 파일 사용

📌 Federated Query

Lambda 기반 커넥터를 사용해 S3 외의 데이터(RDS, DynamoDB 등)도 쿼리 가능하다.

63. Amazon Redshift 🏢

PostgreSQL 기반의 완전 관리형 데이터 웨어하우스

OLAP 전용

Columnar 스토리지

병렬 쿼리 엔진

PB 단위 확장 가능

📌 OLTP vs OLAP

OLTP OLAP

트랜잭션 처리 대규모 분석

RDS/Aurora Redshift

📌 Redshift 구조

Leader Node → 쿼리 계획

Compute Node → 병렬 처리

📌 Spectrum

S3 데이터를 Redshift로 로드하지 않고 직접 분석.

📌 Snapshot & DR

Single AZ

S3에 증분 스냅샷 저장

Cross-region 복사 가능

64. Amazon OpenSearch 🔎

대규모 로그, 텍스트 데이터를 빠르게 검색하고 분석하기 위한 관리형 검색 엔진 서비스

Full-text 검색

로그 분석

SQL 미지원 (자체 쿼리 DSL)

Dashboard 제공

📌 사용 사례

애플리케이션 검색 기능

로그 모니터링

실시간 분석

65. Amazon EMR 🧠

Hadoop/Spark 기반 빅데이터 처리 플랫폼

Apache Spark

Hadoop

Flink

Presto

📌 노드 유형

Master Node → 클러스터 관리 (예약 인스턴스)

Core Node → 데이터 저장 + 처리 (예약 인스턴스)

Task Node → 처리 전용 (스팟 인스턴스 권장)

66. Amazon QuickSight 📊

서버리스 BI 서비스.
데이터를 시각화하고 대시보드를 만들 수 있다.
👉 직접 데이터를 저장하지 않고 데이터 소스와 연결하여 분석 결과를 보여줌

SPICE 인메모리 엔진

대화형 대시보드

Row/Column Level Security

67. AWS Glue 🔄

완전 관리형 ETL 서비스.
(추출과 변환, 로드 서비스를 관리하는 서버리스 서비스)

Extract / Transform / Load

Glue Data Catalog

Glue Studio

Streaming ETL

📌 ETL vs ELT

ETL ELT

변환 후 적재 적재 후 변환

Glue Redshift

📌 Glue Job Bookmark

이전 처리 데이터를 재처리하지 않도록 방지.

68. AWS Lake Formation 🏞

데이터 레이크 구축을 자동화하는 서비스.

중앙 S3 저장소

Row/Column 수준 권한

보안 정책 중앙 관리

보안 정책을 한 곳에서 설정할 수 있다는 것이 가장 큰 장점이다.
📌 Data Lake란?

모든 원천 데이터를 S3에 "중앙 저장"하는 구조.

69. Kinesis Data Analytics ⚡

스트리밍 데이터를 "실시간으로 분석"하는 완전 관리형 서비스
서버를 직접 관리하지 않아도 되며 자동 확장된다.

📌 두 가지 유형

유형 설명

SQL 애플리케이션용 SQL 기반 실시간 분석

Apache Flink용 코드 기반 고급 스트리밍 처리

🔹 SQL 애플리케이션용 Kinesis Data Analytics

데이터 소스: Kinesis Data Streams / Firehose

S3 참조 데이터로 데이터 보강 가능

완전 서버리스

오토 스케일링

사용한 만큼 과금

📌 출력 대상

Kinesis Data Streams (다른 스트림으로 전달)

Kinesis Data Firehose (S3 적재)

📌 사용 예시

실시간 지표 계산

시계열 분석

실시간 대시보드

이상 탐지

🔹 Apache Flink용 Kinesis Data Analytics

고급 스트리밍 처리용 엔진이다.

Java / Scala / SQL 지원

병렬 처리

체크포인트 & 스냅샷

Exactly-once 처리 가능

자동 프로비저닝

오토스케일링

📌 데이터 소스

Kinesis Data Streams

Amazon MSK

⚠ Firehose는 직접 읽지 못한다.

📌 언제 사용할까?

복잡한 Window 처리

세션 분석

Complex Event Processing

Kafka 기반 분석

70. Amazon MSK (Managed Streaming for Apache Kafka) 🛰

완전 관리형 Kafka 클러스터 서비스.
Kafka는 Kinesis의 대안 개념이다.

브로커 자동 생성

Zookeeper 관리

다중 AZ 배포

자동 복구

EBS 스토리지 기반

📌 Kafka 구조

Producer ↓ Topic ├── Partition 0 ├── Partition 1 └── Partition 2 ↓ Consumer Group

📌 특징

메시지 보존 기간 1년 이상 가능

파티션 추가만 가능 (감소 불가)

대규모 확장 가능

🔹 MSK Serverless

용량 관리 불필요

자동 확장

자동 리소스 프로비저닝

✅ Kinesis Data Streams vs Amazon MSK

항목 Kinesis MSK

메시지 크기 1MB 고정 기본 1MB (확장 가능)

구조 Shard Partition

확장 Split / Merge 가능 추가만 가능

보관 기간 기본 7일 1년 이상 가능

생태계 AWS 중심 Kafka 오픈소스

📌 선택 기준

AWS 네이티브 + 간편함 → Kinesis

Kafka 생태계 + 하이브리드 환경 → MSK

71. Big Data Ingestion Pipeline 🏗

📌 요구사항

실시간 데이터 수집

데이터 변환

SQL 분석

S3 저장

데이터 웨어하우스 적재

대시보드 생성

📌 전체 구조

IoT Devices ↓ IoT Core ↓ Kinesis Data Streams ↓ Kinesis Firehose ↓ S3 (Ingestion Bucket) ↓ SQS (optional) ↓ Lambda ↓ Athena ↓ S3 (Reporting Bucket) ↓ QuickSight / Redshift

🔹 IoT Core

IoT 장치 관리

MQTT 기반 통신

Kinesis와 통합

🔹 Firehose

1분 단위 버퍼링

S3 자동 적재

Lambda 변환 지원

🔹 S3 (Data Lake)

Raw 데이터 중앙 저장

무제한 확장

11 9’s 내구성

🔹 SQS + Lambda

비동기 처리

재시도

DLQ 구성 가능

🔹 Athena

서버리스 SQL

결과를 S3에 저장

Presto 기반

🔹 Redshift Serverless

대규모 OLAP 분석

컬럼 기반 저장

고속 조인 처리

🔹 QuickSight

SPICE 인메모리 엔진

대화형 대시보드

Row / Column Level Security

72. 아키텍처 핵심 개념 정리 🧠

계층 서비스

수집 IoT Core / Kinesis / MSK

스트리밍 처리 Kinesis Analytics / Flink

저장 S3 (Data Lake)

SQL 분석 Athena

웨어하우스 Redshift

BI QuickSight

📌 최종 정리

Data Lake = S3 중심 저장

Stream Processing = Kinesis / MSK / Flink

Serverless SQL = Athena

Warehouse 분석 = Redshift

BI 시각화 = QuickSight

73. AWS AI / Machine Learning Services Overview 🤖

📌 AI 서비스 분류 체계

분야 서비스

Computer Vision Rekognition / Textract

Speech Transcribe / Polly

Language (NLP) Comprehend / Comprehend Medical / Translate

Conversational AI Lex / Connect

Search Kendra

Prediction Forecast

Recommendation Personalize

Custom ML SageMaker

AWS ML 서비스는 “완전 관리형 AI API”와 “직접 모델 구축 플랫폼(SageMaker)”로 구분된다.

74. Computer Vision 계열 👁

🔹 Amazon Rekognition

이미지 및 비디오 분석 자동화

객체, 사람, 텍스트, 장면 탐지

얼굴 탐지 및 분석 (성별, 연령, 감정 등)

얼굴 검색 및 얼굴 확인 (Face Recognition)

유명인 인식

스포츠 분석

부적절한 콘텐츠 자동 탐지 (폭력, 성적, 인종차별 등)

신뢰도 임계값(Confidence Threshold) 설정 가능

임계값 낮을수록 더 많은 콘텐츠 플래그 지정

플래그된 이미지 → A2I(Amazon Augmented AI)로 인적 검토 가능

규제 준수 및 안전한 사용자 경험 보장

🔹 Amazon Textract

문서 OCR 서비스

PDF, 이미지, 스캔본, 손글씨 분석 가능

텍스트 + 구조 데이터 추출 (표, 폼)

송장, 보험청구서, 세금양식, 신분증 등 자동 처리

Rekognition은 “이미지 이해”, Textract는 “문서 이해”에 특화됨.

75. Speech 계열

🔹 Amazon Transcribe

음성 → 텍스트 (ASR 기반)

자동 언어 감지

자막 및 폐쇄 자막 생성

Speaker Identification (화자 구분)

Redaction 기능으로 PII 자동 제거

실시간 스트리밍 지원

🔹 Amazon Polly

텍스트 → 음성 변환 (Transcribe의 반대)

Neural TTS 지원

Lexicon으로 사용자 정의 발음 생성

SSML 지원 (속도, 강조, pause 조절)

76. Language & NLP 계열 🧠

🔹 Amazon Comprehend

NLP 기반 텍스트 분석

감정 분석 (Positive / Negative)

개체 인식 (사람, 장소, 브랜드 등)

주제 모델링

문서 분류

고객 상호작용 분석

“텍스트의 의미 이해”가 핵심.

🔹 Amazon Comprehend Medical

의료 특화 NLP

의사 소견서, 검사 결과 분석

DetectPHI API → 보호된 건강 정보 탐지

Transcribe와 결합 가능 (음성 의료 기록 분석)

🔹 Amazon Translate

신경망 기반 자동 번역

대량 텍스트 번역 가능

글로벌 콘텐츠 현지화 지원

77. Conversational AI

🔹 Amazon Lex

Alexa 기반 기술 사용

ASR + NLU 지원

챗봇 및 음성봇 구축

의도(Intent) 기반 대화 처리

🔹 Amazon Connect

클라우드 기반 가상 콜센터

Lex, Transcribe, Comprehend와 통합

CRM 연동 가능

초기 비용 없음

Lex + Connect = 스마트 AI 콜센터 구축 가능

78. Prediction & Recommendation 📊

🔹 Amazon Forecast

시계열 기반 수요 예측

AutoML 기반 모델 선택

P10 / P50 / P90 확률 예측

프로모션, 날씨 등 외부 변수 반영 가능

🔹 Amazon Personalize

실시간 개인화 추천

사용자 행동 기반 학습

Amazon.com 추천 기술과 동일한 구조

랭킹, 유사 아이템 추천 지원

79. Intelligent Search

🔹 Amazon Kendra

ML 기반 지능형 문서 검색

PDF, HTML, PPT 등 다양한 문서 지원

자연어 검색

사용자 피드백 기반 증분 학습

검색 결과 조정 가능

80. Custom Machine Learning

🔹 Amazon SageMaker

ML 모델 구축/학습/배포 통합 플랫폼

데이터 준비 → 학습 → 튜닝 → 배포까지 전 과정 지원

Notebook, AutoML, Endpoint 배포 지원

완전 관리형 인프라

나머지 AI 서비스는 “미리 학습된 모델 제공”,
SageMaker는 “직접 모델을 만드는 플랫폼”.

📌 비교 요약

서비스 핵심 기능

Rekognition 이미지/비디오 분석

Textract 문서 OCR

Transcribe 음성 → 텍스트

Polly 텍스트 → 음성

Translate 번역

Lex 챗봇

Connect 클라우드 콜센터

Comprehend 텍스트 의미 분석

Forecast 시계열 예측

Kendra 문서 검색

Personalize 추천 시스템

SageMaker 직접 ML 구축

AWS AI 서비스는 대부분 서버리스 완전 관리형이며, 복잡한 ML 구현 없이 API 호출만으로 사용 가능하다.

📊 81. AWS CloudWatch

🔥 AWS 모니터링이란?

모니터링 = 서비스가 정상적으로 계속 동작하도록 상태를 관찰하는 것

성능 확인 (CPU, 네트워크)

로그 분석

이상 감지 및 알림

보안 및 감사

AWS 리소스의 "수치 데이터(지표)"를 수집하는 기능

✔ 주요 개념

Metric → CPU, NetworkIn, Disk

Namespace → 서비스별 그룹 (EC2, S3 등)

Dimension → 필터 (InstanceId, Environment)

Timestamp → 시간 기준 데이터

✔ 특징

서비스별 자동 제공

사용자 정의 지표 생성 가능 (예: 메모리)

대시보드 구성 가능

🚀 CloudWatch Metric Streams

CloudWatch 데이터를 외부로 "실시간 스트리밍"

Kinesis Firehose로 전송

Datadog, Splunk 등 외부 연동 가능

지연 시간 매우 짧음

📜 CloudWatch Logs

✔ 구조

Log Group → 애플리케이션 단위 Log Stream → 인스턴스/파일 단위

✔ 특징

로그 보관 기간 설정 가능

S3, Lambda, Elasticsearch로 전송 가능

📡 로그 수집 소스

SDK / API

Unified Agent

Lambda

ECS / EKS

VPC Flow Logs

API Gateway

CloudTrail

Route53 DNS 로그

🔍 Logs Insights & Metric Filter

로그를 "데이터처럼 분석"

"ERROR" 로그 필터링

IP 추적

로그 → 메트릭 변환

알람 트리거 가능

🔁 Logs Subscriptions

실시간 로그 전송

S3 Export보다 빠름

Kinesis / Lambda 연결

🖥 EC2 로그 수집 핵심

EC2는 기본적으로 로그를 CloudWatch로 보내지 않는다

Agent 설치 필요

IAM Role 필요

⚙️ Logs Agent vs Unified Agent

항목 Logs Agent Unified Agent

로그 수집 O O

메트릭 수집 X O

상태 구형 최신

📊 Unified Agent 수집 데이터

CPU (user, system, idle 등)

Disk (read/write)

RAM (used/free)

Network (패킷, 연결 수)

Process 상태

Swap 공간

🚨 CloudWatch Alarms

조건을 만족하면 자동으로 알림 발생

✔ 상태

OK

ALARM

INSUFFICIENT_DATA

✔ 활용

Auto Scaling

EC2 재시작

SNS 알림

🔄 EC2 Instance Recovery

하드웨어 문제 감지

자동 복구

IP 유지

⚡ EventBridge

이벤트 기반 자동화 시스템

Event → Event Bus → Rule → Target

✔ 사용 예

S3 업로드 → Lambda 실행

EC2 종료 → 알림

🧠 Event Bus 종류

Default → AWS 이벤트

Custom → 사용자 이벤트

Partner → 외부 서비스

🧾 82. CloudTrail

"누가 무엇을 했는지" 기록

모든 API 호출 기록

90일 보관

S3로 장기 저장

✔ 이벤트 종류

Management Event

Data Event

🧠 CloudTrail Insights

비정상 행동 탐지

API 호출 급증 감지

🔐 83. AWS Config

"리소스 설정이 규칙을 지키는지 검사"

보안 그룹 공개 여부

S3 공개 여부

시간별 변경 추적

⚠️ Config 특징

변경 기록

규정 준수 확인

자동 수정 가능 (SSM)

🔁 Config + EventBridge

Config → 위반 감지 → EventBridge → SNS / Lambda

📊 서비스 비교

서비스 역할

CloudWatch 성능 모니터링

CloudTrail API 로그

Config 구성 및 규정

[CloudWatch] → 성능 [CloudTrail] → 감사 [Config] → 규정 [EventBridge] → 자동화

🔥 정리

CloudWatch = 상태 확인
CloudTrail = 행동 기록
Config = 규정 검사
EventBridge = 자동 실행

📌 84. AWS 보안 아키텍처

🔷 AWS Organizations — 멀티 계정 아키텍처의 시작

✔ 정의
여러 AWS 계정을 하나의 조직으로 묶어 중앙에서 관리하는 글로벌 서비스

✔ 계정 구조

Management Account (관리 계정) ├── OU (Dev) │ ├── Account A │ └── Account B └── OU (Prod) ├── Account C └── Account D

Management Account: 조직의 루트 관리자 (SCP 적용 X)

Member Account: 조직에 속한 계정 (1개 조직만 가능)

OU: 계정 그룹 (환경/프로젝트/부서 기준)

✔ 비용 최적화

통합 결제 (Consolidated Billing)

예약 인스턴스 / Savings Plan 공유

사용량 기반 할인 공유

💡 핵심
어떤 계정에서 남는 할인 → 다른 계정이 사용 가능

✔ 장점

계정 단위 격리 → VPC보다 강력한 보안

중앙 로그 수집 (CloudTrail, CloudWatch Logs)

태그 기반 비용 관리

계정 간 역할 자동 구성

🔷 SCP (Service Control Policy) — 조직 레벨 보안

<✔ 정의
계정이 가질 수 있는 최대 권한을 제한하는 정책

✔ 특징

OU / 계정 단위 적용

모든 사용자/역할에 적용

관리 계정에는 적용 안됨

✔ 핵심 룰

Explicit Deny > Allow

✔ 실제 예시

OU에서 Redshift Deny → 계정에서 Allow 있어도 사용 불가

관리 계정 → Deny 적용 안됨 (예: Athena 가능)

🔹 Blocklist vs Allowlist

방식 설명

Blocklist 전체 허용 후 일부 Deny

Allowlist 일부만 허용 (나머지 전부 차단)

👉 보안적으로는 Allowlist 방식이 더 안전

🔷 IAM Conditions — 조건 기반 보안

권한 + 조건 = 고급 보안 정책

✔ 주요 조건

aws:SourceIp → 특정 IP만 허용

aws:RequestedRegion → 특정 리전 제한

ec2:ResourceTag → 리소스 태그 기반

aws:PrincipalTag → 사용자 속성 기반

aws:MultiFactorAuthPresent → MFA 강제

✔ 예시

"MFA 없으면 EC2 종료 금지"

🔷 IAM for S3 — 버킷 vs 객체 구분

구분 Action ARN

버킷 s3:ListBucket arn:aws:s3:::bucket

객체 Get/Put/Delete arn:aws:s3:::bucket/*

👉 시험 단골 함정 포인트

🔷 Resource Policy + aws:PrincipalOrgID

조직 내부 계정만 리소스 접근 허용

"Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-xxxx" } }

👉 조직 외 접근 완전 차단

🔷 IAM Role vs Resource-based Policy

구분 특징

IAM Role 권한을 “바꿔서 사용”

Resource Policy 권한을 “추가 허용”

✔ 핵심 차이

Role → 기존 권한 포기 Resource Policy → 기존 권한 유지

✔ 지원 서비스

S3

SNS

SQS

Lambda

🔷 EventBridge Security

EventBridge → 타겟 실행하려면 권한 필요

Resource Policy → Lambda, SQS

IAM Role → EC2, Kinesis

🔷 Permission Boundaries

IAM 권한의 "최대 범위 제한"

✔ 공식

Effective Permission = IAM Policy ∩ Permission Boundary ∩ SCP

✔ 특징

User / Role만 가능

Group 적용 불가

✔ 사용 이유

개발자가 관리자 권한 상승 방지

권한 위임 시 안전장치

🔷 IAM Policy Evaluation Logic

1. Explicit Deny → 무조건 거부 2. Allow → 허용 3. 둘 다 없으면 → 거부

✔ 문제 예시

CreateQueue → ❌

DeleteQueue → ❌

DescribeInstances → ❌

🔷 AWS Cognito — 외부 사용자 인증

IAM = 내부 사용자
Cognito = 외부 사용자

✔ 구성

User Pool → 로그인 시스템

Identity Pool → AWS 접근 권한

✔ 흐름

로그인 → 토큰 → 임시 AWS 자격증명

✔ 특징

소셜 로그인 지원

Row-level 접근 제어 가능

🔷 IAM Identity Center (SSO)

한 번 로그인 → 모든 AWS 계정 + SaaS 접근

✔ 구성

Users / Groups

Permission Sets

Organizations 연동

✔ ABAC

속성 기반 접근 제어 (Tag 기반)

🔷 AWS Directory Service (AD)

✔ 개념

사용자/컴퓨터/그룹 DB

중앙 인증 시스템

✔ 종류

Managed AD → AWS 내부 AD

AD Connector → 온프레미스 연결

Simple AD → 경량 AD

🔷 AWS Control Tower

멀티 계정 환경 자동 구축 + 보안 관리

계정 자동 생성

정책 자동 적용

보안 모니터링

🔷 Guardrails (보안 핵심)

종류 기술

Preventive SCP

Detective AWS Config

✔ 흐름

Config → 위반 감지 → SNS 알림 → Lambda 자동 수정

🚀 아키텍처 정리

[ 사용자 ] ↓ AD / Cognito ↓ IAM Identity Center (SSO) ↓ AWS Organizations ↓ IAM + SCP + Boundary ↓ Control Tower + Guardrails

🔥 핵심
AWS 보안 설계는
👉 "누가 (Identity)"
👉 "어디서 (Account)"
👉 "무엇을 (Permission)"
👉 "어떻게 제한할지 (SCP/Boundary)"
를 동시에 설계하는 것

❗️ 85. AWS 보안 및 암호화

암호화의 3가지 축 (Encryption Domains)

1) 전송 중 암호화 (Encryption in Transit)

TLS/SSL 기반 HTTPS 통신

패킷 레벨 암호화

MITM(Man-in-the-Middle) 공격 방지

AWS 서비스는 대부분 HTTPS Endpoint 기본 제공

2) 저장 시 암호화 (Encryption at Rest)

서버가 데이터를 받은 후 암호화

EBS, S3, RDS 디스크에 암호화된 형태 저장

데이터 키(Data Key) 기반 암호화

키는 KMS에 의해 보호

3) 클라이언트 측 암호화 (Client-side Encryption)

서버가 절대 복호화 불가

암호화/복호화는 클라이언트 책임

Envelope Encryption 사용 가능

✅ TLS vs SSL

SSL은 구버전 프로토콜 (보안 취약)

TLS는 SSL의 후속 표준

HTTPS는 TLS 기반

ACM이 TLS 인증서 발급

포인트: Edge-Optimized API Gateway → ACM 인증서는 반드시 us-east-1에서 생성

86. 서버 사이드 암호화 구조 (SSE)

클라이언트가 데이터 업로드

AWS 서비스가 Data Key 생성

Data Key로 데이터 암호화

Data Key는 KMS CMK로 암호화

암호화된 데이터 + 암호화된 Data Key 저장

종류

SSE-S3

SSE-KMS

SSE-C (고객 키 제공)

87. AWS KMS (Key Management Service)

AWS 암호화 핵심 서비스

IAM과 완전 통합

CloudTrail로 모든 키 사용 API 감사 가능 (중요)

EBS, S3, RDS, Lambda, SSM, Secrets Manager 통합

보안 원칙

암호를 코드에 저장 금지

환경 변수 평문 저장 금지

항상 KMS 사용

👉 KMS 키 유형

① Symmetric (AES-256)

단일 키

AWS 서비스 기본 통합

KMS API 통해서만 사용 가능

② Asymmetric (RSA/ECC)

Public / Private Key 구조

Public Key 다운로드 가능

Private Key 직접 접근 불가

외부 시스템 암호화에 사용

✅ KMS Key 관리 유형

AWS Managed Key

aws/rds 등

무료

AWS가 관리

Customer Managed Key (CMK)

$1/월

API 호출 비용 발생

Key Import 가능

교차 계정 접근 가능

Multi-Region Key

Primary + Replica 구조

Key ID 동일

재암호화 없이 교차 리전 복호화 가능

Global DynamoDB, Aurora Global DB 사용

💫 Key Rotation

AWS Managed → 자동 1년 교체

CMK → 수동 활성화 필요

Import Key → 수동 교체만 가능

Alias 사용 권장

📝 Snapshot 암호화 복사

리전 간 복사

KMS는 리전 범위

Key A → Key B 자동 재암호화

계정 간 복사

KMS Key Policy 수정 필요

Launch Permission 수정

대상 계정에서 새 CMK로 재암호화

🛠️ S3 암호화 복제

SSE-S3 기본 복제 가능

SSE-KMS 복제하려면 옵션 활성화 필요

Target Key 지정 필수

KMS Key Policy 수정 필요

SSE-C 복제 불가

88. SSM Parameter Store
📌 애플리케이션 구성 값과 비밀(암호, API 키 등)을 안전하게 저장하고 중앙에서 관리하는 키-값 기반의 서버리스 구성 저장소

구성값 + 암호 저장

KMS 암호화 가능

버전 관리

Hierarchy 지원

IAM 제어

EventBridge 알림

Advanced Tier

TTL 정책

만료 알림

변경 없음 알림

89. AWS Secrets Manager
👉 데이터베이스 자격 증명, API 키 등 민감한 비밀 정보를 안전하게 저장하고 자동 교체(Rotation)까지 관리하는 비밀 전용 관리 서비스

암호 전용 서비스

자동 Rotation 지원

Lambda로 자동 갱신

Multi-Region 복제

RDS/Aurora 통합

90. AWS Certificate Manager (ACM)
👉 AWS 리소스에 사용되는 TLS/SSL 인증서를 발급, 배포, 관리 및 자동 갱신하는 완전 관리형 인증서 서비스

TLS 인증서 발급

퍼블릭 인증서 무료

자동 갱신

ALB, CloudFront, API Gateway 통합

EC2 직접 사용 불가

91. API Gateway Endpoint Types

Edge-Optimized → CloudFront 기반

Regional → 동일 리전 최적화

Private → VPC 내부 접근

92. AWS WAF (Web Application Firewall)
👉 HTTP/HTTPS 기반 웹 애플리케이션을 Layer 7(애플리케이션 계층) 공격으로부터 보호하는 웹 방화벽 서비스

Layer 7 보호

SQL Injection, XSS 방어

IP Set (10,000개 가능)

Geo Match

Rate-based Rule

CloudFront는 글로벌

📌 적용 위치

WAF는 다음 리소스 앞단에 연결된다:

CloudFront

Application Load Balancer (ALB)

API Gateway

AppSync

93. AWS Shield
✅ AWS 인프라를 DDoS 공격(3/4 계층 및 일부 7계층)으로부터 보호하는 관리형 서비스
Standard

무료

3/4계층 보호

Advanced

$3000/월

DDoS 대응팀(DRP)

자동 WAF Rule 생성

DDoS 비용 보호

94. AWS Firewall Manager
👉 AWS Organizations 환경에서 여러 계정의 보안 정책(WAF, Shield, Network Firewall 등)을 중앙에서 관리하는 보안 정책 관리 서비스

Organization 전체 보안 정책 중앙 관리

WAF / Shield / Network Firewall 관리

새 리소스 자동 적용

95. GuardDuty
✅ AWS 계정과 워크로드에서 발생하는 로그 데이터를 분석하여 위협과 비정상 활동을 탐지하는 지능형 위협 탐지 서비스

ML 기반 위협 탐지

CloudTrail 분석

VPC Flow Log 분석

DNS 로그 분석

EKS 감사 로그 분석

암호화폐 탐지

96. Amazon Inspector
✅ EC2, 컨테이너 이미지(ECR), Lambda 함수의 취약점을 자동으로 평가하는 취약점 분석 서비스

EC2 취약점 분석

ECR 이미지 스캔

Lambda 코드 분석

Security Hub 통합

EventBridge 통합

97. Amazon Macie
✅ Amazon S3에 저장된 데이터를 분석하여 민감한 정보(PII 등)를 탐지하고 보호하는 데이터 보안 서비스

S3 데이터 PII 탐지

Machine Learning 기반

EventBridge 통합

🔐 AWS 보안 & 암호화 전체 정리

📌 암호화 구조 한눈에 보기

구분 목적 대표 서비스 핵심 포인트
전송 중 암호화 네트워크 도청 방지 HTTPS (TLS), ACM MITM 방지 / Edge는 us-east-1 인증서
저장 시 암호화 디스크 데이터 보호 S3, EBS, RDS + KMS Data Key + Envelope Encryption
클라이언트 암호화 AWS도 복호화 불가 KMS SDK 고객 책임 / 최고 보안 수준

📌 KMS 핵심 구조

💡 Envelope Encryption 흐름

1) KMS가 Data Key 생성
2) Data Key로 데이터 암호화
3) Data Key는 CMK로 다시 암호화
4) 암호화된 데이터 + 암호화된 Data Key 저장

🔑 KMS 키 유형 정리

구분 특징 사용 예
Symmetric (AES-256) 단일 키 / AWS 기본 S3, EBS, RDS
Asymmetric (RSA/ECC) Public/Private 구조 외부 시스템 암호화
Multi-Region Primary + Replica Global DB

🔐 키 관리 유형

AWS Managed Key → 무료 / 자동 회전

Customer Managed Key → $1/월 / 교차 계정 가능

Imported Key → 자동 회전 불가

📌 비밀 관리 서비스 비교

항목 SSM Parameter Store Secrets Manager ACM
용도 구성값 + 암호 비밀 전용 TLS 인증서
자동 Rotation ❌ ✅ (Lambda) ✅ (자동 갱신)
비용 저렴 비쌈 무료(공개 인증서)
Multi-Region ❌ ✅ CloudFront 글로벌

📌 웹 보안 계층 정리

서비스 보호 계층 역할
AWS WAF Layer 7 SQLi, XSS 방어
AWS Shield Layer 3/4 DDoS 보호
Firewall Manager 관리 계층 Org 전체 정책 중앙 관리

💡 기억 공식

WAF = 웹 공격 차단
Shield = DDoS 방어
Firewall Manager = 조직 통합 관리

📌 위협 탐지 서비스 비교

서비스 무엇을 분석? 목적
GuardDuty CloudTrail, VPC Flow, DNS 위협 탐지
Inspector EC2, ECR, Lambda 취약점 분석
Macie S3 데이터 PII 탐지

🧠 기억 구조

GuardDuty = 공격 탐지
Inspector = 취약점 점검
Macie = 민감 데이터 탐지

📌 핵심 포인트

Edge API Gateway 인증서는 반드시 us-east-1

KMS는 리전 단위

SSE-C는 복제 불가

Shield Standard는 무료

Secrets Manager는 자동 Rotation 지원

Alias 사용하면 Key 교체 시 코드 수정 불필요

98. AWS Network Firewall

VPC 전체를 보호하는 관리형 Layer 3 ~ Layer 7 방화벽 서비스
기존 Security Group이나 NACL이 개별 인스턴스 또는 서브넷 수준의 제어를 담당했다면, Network Firewall은 VPC 경계에서 모든 트래픽을 중앙 집중적으로 검사한다.

1️⃣ 왜 필요한가?

VPC가 커지고, Transit Gateway, Direct Connect, Site-to-Site VPN, VPC Peering 등으로 네트워크가 확장되면 트래픽 흐름이 복잡해진다.

인터넷 ↔ VPC 트래픽

VPC ↔ VPC 트래픽

VPC ↔ On-Prem (DX / VPN)

Outbound 인터넷 통제

이 모든 경로를 하나의 중앙 방화벽 정책으로 통제하기 위해 AWS Network Firewall을 사용한다.

2️⃣ 보호 범위

Internet Inbound / Outbound 트래픽

VPC 간 트래픽 (Transit Gateway 경유 포함)

Direct Connect 트래픽

Site-to-Site VPN 트래픽

즉, VPC 내부뿐 아니라 하이브리드 연결까지 모두 검사 가능하다.

3️⃣ 동작 구조

AWS Network Firewall은 내부적으로 Gateway Load Balancer(GWLB) 기반으로 동작한다.

Internet │ Internet Gateway │ Network Firewall (GWLB 기반 검사) │ Private Subnet / Application

트래픽은 GWLB를 통해 방화벽 엔진으로 전달되고, 검사 후 원래 경로로 반환된다. 완전 관리형이므로 사용자가 인프라를 직접 운영할 필요가 없다.
4️⃣ 보안 계층 (Layer 3 ~ 7)

Layer 3 (IP 기반 필터링)

CIDR 기반 차단

수천~수만 개 IP 블랙리스트 관리 가능

Layer 4 (포트 / 프로토콜)

특정 포트 차단

특정 프로토콜 차단 (예: SMB, FTP 등)

Layer 7 (애플리케이션 계층)

도메인 기반 필터링

정규 표현식(Regex) 패턴 매칭

특정 도메인만 허용 (예: *.mycorp.com)

5️⃣ 트래픽 처리 방식

규칙에 따라 트래픽을 다음과 같이 처리한다:

Allow – 통과

Drop – 차단

Alert – 로그만 남김

단순 차단뿐 아니라 모니터링 전용 모드 운영도 가능하다.

6️⃣ 침입 방지 기능 (IPS)

Active flow inspection을 통해 네트워크 위협을 탐지하고 차단한다.

Deep Packet Inspection (DPI)

시그니처 기반 위협 탐지

랜섬웨어 확산 차단 (예: SMB Outbound 차단)

온프레미스 IDS/IPS 장비와 동일한 수준의 보호 기능을 제공한다.

7️⃣ 로그 및 모니터링

규칙 매칭 로그는 다음으로 전송 가능하다:

Amazon S3

CloudWatch Logs

Kinesis Data Firehose

SIEM 시스템과 연동하여 중앙 보안 관제 체계 구성 가능.

8️⃣ 중앙 정책 관리

AWS Firewall Manager와 통합하면 다중 계정 / 다중 VPC 환경에서 조직 전체에 동일 정책을 적용할 수 있다.

멀티 계정 환경 지원

엔터프라이즈 보안 표준 강제 적용

9️⃣ 기존 보안 계층과 비교

구분 Security Group NACL Network Firewall

레벨 인스턴스 서브넷 VPC 경계

Stateful Yes No Yes

L7 검사 No No Yes

중앙 정책 관리 제한적 제한적 가능

🔟 언제 사용할까?

Outbound 트래픽을 강하게 통제해야 할 때

Direct Connect / VPN 트래픽 검사 필요 시

규제 준수 환경 (금융, 의료)

Zero Trust 아키텍처 구현

🎯 정리

AWS Network Firewall은 VPC 경계에서 L3~L7 트래픽을 검사하고, 중앙 정책 관리와 침입 방지 기능을 제공하는 관리형 네트워크 방화벽이다.

Security Group과 NACL은 내부 보안 계층, Network Firewall은 VPC 전체를 보호하는 상위 계층 방어선이다.

99. Disaster Recovery (재해 복구)

Disaster Recovery는 재해가 발생했을 때 서비스를 복구하고 비즈니스를 지속할 수 있도록 준비하는 전략이다.

시험에서도 매우 자주 나오는 핵심 주제

Solutions Architect 관점에서 반드시 이해해야 하는 영역

백업, 복제, 자동화, 멀티 리전 설계가 함께 연결됨

정상 운영 │ ├─ 장애 예방 ├─ 데이터 보호 ├─ 장애 감지 └─ 복구 및 전환

👉 핵심은 “장애를 막는 것”만이 아니라 장애가 나도 서비스가 다시 살아나게 만드는 것

Disaster Recovery 총정리

1️⃣ 재해 복구의 기본 개념

개념 설명 핵심 포인트
재해(Disaster) 사업 지속성이나 재정에 큰 악영향을 주는 장애 이벤트 리전 장애, 데이터 손상, 네트워크 분리, 랜섬웨어 등 포함
재해 복구(DR) 장애 발생 시 서비스를 복원하는 절차와 전략 백업, 복제, 페일오버, 자동화가 모두 포함됨
온프레미스 → 온프레미스 전통적인 DR 방식 비용이 크고 관리 복잡도도 높음
온프레미스 → 클라우드 하이브리드 DR 기존 환경을 유지하면서 AWS를 DR 사이트로 활용
클라우드 리전 A → 리전 B 멀티 리전 DR 클라우드 네이티브 DR의 대표 패턴

2️⃣ DR에서 가장 중요한 질문

장애가 났을 때 얼마나 빨리 복구해야 하는가?

복구 시 얼마만큼의 데이터 손실을 감수할 수 있는가?

평상시에 어느 정도 비용을 지불할 수 있는가?

자동 복구가 필요한가, 수동 복구도 가능한가?

3️⃣ DR 전략 선택 기준

기준 의미 영향
RPO 얼마나 최신 데이터까지 복구해야 하는가 백업 주기, 복제 방식 결정
RTO 얼마나 빨리 서비스를 복구해야 하는가 예비 인프라 규모와 자동화 수준 결정
비용 평상시 유지 비용 허용 범위 Backup / Pilot Light / Warm Standby / Hot Site 선택
복잡도 운영팀이 감당할 수 있는 설계 수준 멀티 리전, Active-Active 설계 여부에 영향

100. RPO와 RTO

RPO와 RTO는 재해 복구 전략을 설계할 때 가장 먼저 결정해야 하는 기준이다.

RPO = 데이터 손실 허용 범위

RTO = 서비스 중단 허용 시간

둘 다 짧을수록 비용과 복잡도가 올라감

데이터 손실 관점 -> RPO 서비스 중단 관점 -> RTO

👉 DR 설계는 결국 “얼마나 잃어도 되는가”와 “얼마나 빨리 살아나야 하는가”를 정하는 일

RPO / RTO 총정리

1️⃣ RPO (Recovery Point Objective)

RPO는 재해 발생 시점 기준으로 얼마 전 시점까지의 데이터는 반드시 복구되어야 하는지를 의미한다.

백업 주기가 1시간이면 최악의 경우 1시간치 데이터 손실 가능

복제 주기가 짧을수록 RPO는 낮아짐

동기 복제는 낮은 RPO에 유리하지만 비용과 복잡도가 큼

2️⃣ RTO (Recovery Time Objective)

RTO는 재해 발생 후 얼마 안에 서비스를 다시 정상화해야 하는지를 의미한다.

복구 절차가 수동이면 RTO가 길어짐

예비 인프라가 이미 준비돼 있으면 RTO가 짧아짐

멀티 사이트는 RTO를 크게 줄일 수 있지만 비용이 매우 큼

3️⃣ 비교 정리

항목 RPO RTO
관점 데이터 손실 서비스 다운타임
질문 얼마나 최근 데이터까지 복구해야 하는가? 얼마나 빨리 서비스가 살아나야 하는가?
줄이는 방법 복제 주기 단축, 지속 복제 자동화, 예비 인프라 상시 운영

101. Disaster Recovery Strategies

재해 복구 전략은 보통 비용과 복구 속도의 트레이드오프로 나뉜다.

Backup and Restore

Pilot Light

Warm Standby

Multi Site / Hot Site

저비용 / 느린 복구 Backup and Restore ↓ Pilot Light ↓ Warm Standby ↓ Multi Site / Hot Site 고비용 / 빠른 복구

👉 DR 전략은 기술 선택이 아니라 비즈니스 요구사항에 맞춘 비용-복구 속도 균형

DR 전략 총정리

1️⃣ 전략 비교

전략 평상시 비용 RPO/RTO 핵심 특징
Backup and Restore 낮음 높음 / 높음 백업만 보관, 장애 시 재구성
Pilot Light 중간 이하 중간 / 중간 핵심 시스템만 상시 운영
Warm Standby 중간 이상 낮음 / 낮음 전체 시스템 축소판 운영
Multi Site / Hot Site 높음 매우 낮음 / 매우 낮음 거의 즉시 전환 가능한 운영 환경 유지

2️⃣ Active-Passive vs Active-Active

구조 설명 예시
Active-Passive 평소에는 한쪽만 서비스하고 장애 시 다른 쪽으로 전환 Pilot Light, Warm Standby
Active-Active 여러 사이트가 동시에 트래픽을 처리 Multi Site / Hot Site

102. Backup and Restore

Backup and Restore는 백업만 보관해 두고 재해가 발생하면 그때 인프라와 데이터를 다시 복구하는 전략이다.

가장 비용이 낮음

복구 시간은 가장 오래 걸림

소규모 시스템 또는 복구 시간이 길어도 되는 워크로드에 적합

정기 백업 │ 재해 발생 │ 새 인프라 생성 │ 백업 복원

👉 “평소엔 거의 안 들고, 장애 시 다시 만든다”

Backup and Restore 총정리

1️⃣ 핵심 특징

EBS 스냅샷, RDS 백업, S3 백업, AMI 등을 저장해 둔다.

재해 발생 후 인프라를 새로 만들고 데이터를 복원한다.

백업 자체는 저렴하지만 복구 절차가 길다.

2️⃣ 장단점

장점 단점
평상시 비용이 매우 낮음 복구 시간이 길다
구조가 단순함 자동화가 부족하면 운영 실수가 생길 수 있음
비핵심 시스템에 적합 최신 데이터 보장이 약함

3️⃣ 주의사항

백업이 있다고 끝이 아니라 실제 복원 테스트를 해야 한다.

인프라를 재생성해야 하므로 CloudFormation 같은 IaC가 중요하다.

Snowball은 대용량 이전에는 좋지만, 빠른 RPO에는 적합하지 않을 수 있다.

103. Pilot Light

Pilot Light는 핵심 데이터와 최소한의 코어 시스템만 클라우드에서 계속 유지하다가, 장애 시 전체 시스템으로 빠르게 확장하는 전략이다.

Backup and Restore보다 빠름

Warm Standby보다 저렴함

핵심 데이터 계층은 지속적으로 유지하는 것이 중요

평상시 ├─ 핵심 DB / 복제 └─ 최소 코어 서비스 재해 발생 └─ 애플리케이션 계층 확장

👉 “불씨만 살려 두었다가, 필요할 때 크게 키우는 전략”

Pilot Light 총정리

1️⃣ 구조

중요 데이터는 AWS 쪽으로 지속 복제

코어 서비스만 최소 구성으로 유지

장애 시 애플리케이션 서버, 로드밸런서 등을 빠르게 확장

2️⃣ 적합한 경우

모든 시스템을 상시 운영하기엔 비용이 부담될 때

데이터 손실은 줄여야 하지만, 수분~수십 분 수준 복구는 허용될 때

핵심 시스템만 먼저 복구해도 되는 구조일 때

3️⃣ 주의사항

DB, 스토리지, DNS 전환 절차가 자동화되어야 한다.

장애 시 실제로 어떤 순서로 확장할지 Runbook이 필요하다.

크리티컬 코어 시스템에 특히 적합하다.

104. Warm Standby

Warm Standby는 전체 시스템을 축소판 형태로 계속 실행해 두었다가 재해가 발생하면 프로덕션 규모로 빠르게 확장하는 전략이다.

Pilot Light보다 더 빠른 복구 가능

대부분의 계층이 이미 살아 있음

비용은 Pilot Light보다 높음

평상시 ├─ 작은 규모의 전체 시스템 운영 └─ 데이터 복제 지속 재해 발생 └─ Auto Scaling으로 생산 규모까지 확대

👉 “작게 계속 돌리다가, 장애 시 크게 늘리는 전략”

Warm Standby 총정리

1️⃣ 핵심 구성

구성요소 설명 포인트
애플리케이션 서버 축소된 규모로 상시 실행 완전 정지는 아님
데이터 계층 지속 복제 또는 스탠바이 유지 낮은 RPO 확보에 중요
ELB / Route 53 전환용 엔드포인트 준비 페일오버 속도에 직접 영향
Auto Scaling 장애 시 생산 규모로 빠르게 확장 RTO 감소 핵심

2️⃣ 장단점

장점 단점
RTO가 비교적 짧다 평상시 비용이 지속 발생
실제 복구 절차가 단순해진다 운영/동기화 관리가 필요함
대부분의 구성요소가 이미 살아 있음 멀티 리전 설계가 복잡해질 수 있음

105. Multi Site / Hot Site Approach

Multi Site / Hot Site는 여러 사이트가 거의 생산 환경 수준으로 동시에 준비되어 있어, 장애 시 즉시 또는 매우 빠르게 전환할 수 있는 전략이다.

가장 짧은 RTO/RPO 가능

가장 높은 비용

진짜 엔터프라이즈급 핵심 서비스에서 자주 고려됨

Site A (Active) │ 동시 운영 / 복제 │ Site B (Active 또는 즉시 승격 가능)

👉 “비싸지만 가장 빨리 살아나는 전략”

Multi Site / Hot Site 총정리

1️⃣ 핵심 특징

AWS와 온프레미스, 혹은 리전과 리전이 모두 생산 수준에 가까운 상태를 유지한다.

Route 53 또는 글로벌 트래픽 제어 계층이 빠른 전환을 담당한다.

Active-Active 또는 거의 그에 가까운 구조가 많다.

2️⃣ 적합한 경우

다운타임 허용 범위가 매우 짧을 때

금융, 결제, 대형 SaaS 등 핵심 서비스일 때

지역 단위 장애에도 비즈니스 지속이 필수일 때

3️⃣ 주의사항

데이터 일관성과 쓰기 충돌 문제를 고려해야 한다.

운영 절차가 가장 복잡하다.

비용뿐 아니라 테스트와 관측 체계도 함께 성숙해야 한다.

106. All AWS Multi Region

All AWS Multi Region은 온프레미스 대신 AWS 여러 리전을 활용해 재해 복구와 고가용성을 설계하는 방식이다.

클라우드 네이티브 DR의 대표 형태

멀티 리전 아키텍처와 연결됨

Aurora Global Database 같은 서비스가 큰 역할을 함

AWS Region A │ 복제 AWS Region B

👉 “클라우드 안에서 클라우드로 복구하는 구조”

All AWS Multi Region 총정리

1️⃣ 장점

온프레미스 DR 사이트보다 빠르게 구축 가능

AWS 서비스 간 통합이 쉬움

자동화, 모니터링, IaC와 결합이 용이함

2️⃣ 자주 쓰는 서비스

서비스 역할
Route 53 DNS 기반 트래픽 전환
Aurora Global Database 리전 간 DB 복제
S3 CRR 리전 간 객체 복제
CloudFormation 재생성 자동화
AWS Backup 리전 간 백업 복사

107. Disaster Recovery Tips

재해 복구는 백업 서비스 하나만 있다고 완성되지 않는다. 백업, 고가용성, 복제, 자동화, 테스트가 함께 가야 한다.

백업만 있으면 복구가 느릴 수 있음

복제만 있으면 악성 데이터도 같이 복제될 수 있음

자동화가 없으면 실제 장애 시 사람이 병목이 됨

백업 + 복제 + 전환 + 자동화 + 테스트 = 실제 DR

👉 DR은 “기능”이 아니라 운영 체계 전체

DR Tips 총정리

1️⃣ 백업 관점

EBS Snapshot, RDS 자동 백업/수동 스냅샷

S3 Lifecycle, S3 Glacier, Cross-Region Replication

온프레미스 데이터는 Snowball, Storage Gateway, DataSync로 이전 가능

2️⃣ 고가용성 관점

Route 53 Failover 정책

RDS Multi-AZ, ElastiCache Multi-AZ, EFS, S3

Site-to-Site VPN, Direct Connect 이중화

3️⃣ 복제 관점

RDS Read Replica / Cross-Region Replica

Aurora Global Database

온프레미스 -> AWS DB 지속 복제

4️⃣ 자동화 관점

CloudFormation으로 인프라 재생성

CloudWatch + Lambda로 자동 복구

Elastic Beanstalk, Systems Manager Automation 활용

5️⃣ 카오스 엔지니어링 관점

복구 전략은 문서만 있으면 안 되고 실제로 시험해야 한다.

장애를 의도적으로 발생시켜 대응 능력을 확인해야 한다.

넷플릭스의 Simian Army는 이런 사고방식의 대표 사례다.

108. DMS (Database Migration Service)

DMS는 데이터베이스를 AWS로 또는 AWS 간에 마이그레이션하고, 변경 데이터를 지속 복제할 수 있게 해주는 서비스다.

소스 DB를 계속 사용하면서 이전 가능

CDC(변경 데이터 캡처) 지원

동종 / 이기종 마이그레이션 모두 자주 사용됨

Source DB │ Full Load + CDC ▼ DMS Replication Instance ▼ Target DB

👉 “서비스 중단을 최소화하면서 DB를 옮기고 싶을 때 가장 먼저 떠올리는 서비스”

DMS 총정리

1️⃣ 핵심 기능

기능 설명 포인트
Full Load 기존 데이터를 한 번에 적재 초기 이전 단계
CDC 변경 데이터 지속 복제 다운타임 최소화 핵심
동종 마이그레이션 예: Oracle -> Oracle 비교적 단순
이기종 마이그레이션 예: SQL Server -> Aurora 보통 SCT 필요

2️⃣ 핵심 포인트

DMS는 데이터를 옮기는 역할이다.

스키마를 바꿔주는 역할은 기본적으로 SCT가 담당한다.

DMS는 복제 인스턴스를 사용해 마이그레이션 작업을 수행한다.

109. DMS Sources and Targets

DMS는 다양한 소스와 타깃을 지원하며, 데이터베이스뿐 아니라 분석/스트리밍 계층으로도 연결할 수 있다.

온프레미스 DB -> AWS

AWS DB -> AWS

AWS -> 온프레미스

DMS Sources / Targets 총정리

1️⃣ Source 예시

온프레미스 데이터베이스

EC2 상 데이터베이스

RDS

S3

2️⃣ Target 예시

RDS

Aurora

S3

Redshift

DynamoDB

Kinesis Data Streams

3️⃣ 의미

즉, DMS는 단순히 “DB -> DB” 도구가 아니라 DB -> 분석/스트리밍/스토리지 계층으로 이어지는 데이터 이동 도구로도 볼 수 있다.

110. Schema Conversion Tool (SCT)

SCT는 소스 DB와 타깃 DB의 엔진이 다를 때 스키마를 변환해 주는 도구다.

이기종 마이그레이션에서 중요

DMS가 자동으로 대신 해주는 것은 아님

데이터 이전과 스키마 변환은 분리해서 생각해야 함

SCT -> 스키마 변환 DMS -> 데이터 이동 및 지속 복제

👉 “구조는 SCT, 데이터는 DMS”

SCT 총정리

1️⃣ 언제 필요한가

상황 SCT 필요 여부
PostgreSQL -> PostgreSQL 보통 불필요
MySQL -> Aurora MySQL 대체로 불필요 또는 최소
SQL Server -> Aurora PostgreSQL 필요 가능성 높음
Oracle -> PostgreSQL 매우 중요

2️⃣ 주의사항

엔진과 플랫폼을 구분해야 한다.

예를 들어 PostgreSQL은 엔진이고, RDS는 플랫폼이다.

동일 엔진이면 DMS만으로 충분한 경우가 많다.

111. DMS Continuous Replication

지속 복제는 초기 이전 후에도 소스 데이터의 변경 사항을 계속 타깃으로 반영하는 방식이다.

초기 Full Load 후 CDC로 전환

다운타임 최소화에 매우 중요

컷오버 직전까지 데이터 차이를 줄일 수 있음

SCT -> 스키마 준비 │ Full Load │ CDC │ Cutover

👉 “한 번 옮기고 끝”이 아니라 실시간에 가깝게 따라오게 만드는 과정

112. Aurora MySQL로 마이그레이션

Aurora MySQL로 이전할 때는 다운타임 허용 범위와 데이터 규모에 따라 방법을 선택해야 한다.

스냅샷 기반 이전

Aurora Read Replica 기반 점진 이전

DMS 기반 지속 복제

백업/Import 방식

Aurora MySQL 마이그레이션 총정리

1️⃣ RDS MySQL → Aurora MySQL

방법 설명 특징
Snapshot Restore RDS 스냅샷을 이용해 Aurora 생성 단순하지만 다운타임 발생 가능
Aurora Replica Aurora Read Replica 생성 후 승격 지연이 0에 가까워지면 컷오버 가능
DMS 지속 복제 후 컷오버 운영 지속성이 좋음

2️⃣ 외부 MySQL → Aurora MySQL

Percona XtraBackup -> S3 -> Import

mysqldump 기반 이전

DMS 기반 지속 복제

3️⃣ 선택 기준

다운타임 허용 가능하면 Snapshot 방식이 단순하다.

다운타임을 줄이려면 Replica 또는 DMS 방식이 유리하다.

데이터 규모가 크고 서비스가 살아 있어야 하면 지속 복제가 핵심이다.

113. AWS를 통한 온프레미스 전략

AWS는 단순히 “클라우드로 새로 만드는 곳”이 아니라, 온프레미스 환경을 점진적으로 이전하고 확장하는 전략적 플랫폼으로 활용할 수 있다.

서버 이전

DB 이전

VM 이미지 이전

DR 사이트 구축

온프레미스 ├─ 서버 ├─ VM ├─ DB └─ 파일 데이터 │ ▼ AWS

👉 핵심은 “한 번에 완전 전환”보다 단계적 이전과 하이브리드 운영

온프레미스 전략 총정리

1️⃣ 관련 서비스

서비스 역할 사용 예시
VM Import/Export VM 이미지 이동 레거시 VM 이전
DMS DB 마이그레이션 온프레미스 DB -> RDS
Application Discovery Service 사전 조사 종속성 파악
MGN 서버 리호스팅 Lift-and-shift
Storage Gateway / DataSync 데이터 이동 파일/볼륨 이전

114. AWS Backup

AWS Backup은 여러 AWS 서비스의 백업을 중앙에서 일관되게 관리하는 완전 관리형 백업 서비스다.

서비스별로 따로 백업 정책을 만들 필요를 줄여줌

예약 백업, 온디맨드 백업, 리전 간/계정 간 복사 지원

교본 관점에서 반드시 알아야 하는 중앙 백업 관리 서비스

AWS Backup ├─ Backup Plan ├─ Backup Vault ├─ Schedule ├─ Retention └─ Cross-Region / Cross-Account Copy

👉 “백업 기능을 리소스별로 흩어 놓지 않고 중앙에서 묶어 관리하는 서비스”

AWS Backup 총정리

1️⃣ 지원 대상 예시

서비스 지원 여부
EC2 / EBS 지원
S3 지원
RDS / Aurora / DynamoDB 지원
DocumentDB / Neptune 지원
EFS / FSx 지원
Storage Gateway 지원

2️⃣ 핵심 기능

Backup Plan 생성

백업 주기, 윈도우, 보관 기간 정의

태그 기반 백업 정책 적용

리전 간 백업 복사

계정 간 백업 복사

PITR 지원 리소스 관리

3️⃣ 왜 중요한가

백업 정책을 표준화할 수 있다.

DR 전략과 바로 연결된다.

대규모 조직에서 운영 일관성을 높일 수 있다.

115. AWS Backup Vault Lock

Backup Vault Lock은 백업 데이터를 WORM(Write Once Read Many) 방식으로 보호해 삭제나 변경을 매우 어렵게 만드는 기능이다.

랜섬웨어 대응 관점에서 중요

악의적 삭제 방어

루트 사용자도 제한될 수 있음

Backup Vault └─ Vault Lock └─ 삭제 / 보존기간 변경 제한

👉 “백업이 있어도 지워지면 소용없기 때문에, 백업 자체를 잠그는 것”

Vault Lock 총정리

1️⃣ 핵심 효과

백업 삭제 방지

보존 정책 임의 변경 방지

추가 보호 계층 제공

2️⃣ 왜 필요한가

공격자는 운영 데이터를 못 지우면 백업을 노릴 수 있다.

백업 무결성이 DR의 마지막 보루가 되는 경우가 많다.

116. AWS Application Discovery Service

AWS Application Discovery Service는 온프레미스 서버의 사용량, 구성, 종속성, 네트워크 연결을 조사해 마이그레이션 계획을 세우도록 돕는 서비스다.

무엇을 먼저 옮길지 파악 가능

서버 간 의존 관계를 이해하는 데 중요

AWS Migration Hub와 함께 보면 더 유용함

온프레미스 서버 스캔 │ 구성 / 성능 / 종속성 수집 │ Migration Hub에서 분석

👉 “옮기기 전에 먼저 구조를 이해하게 해주는 서비스”

Application Discovery 총정리

1️⃣ Agentless Discovery

가상 머신 정보, CPU, 메모리, 디스크 사용량 같은 성능 데이터 수집

빠른 인벤토리 파악에 적합

2️⃣ Agent-based Discovery

프로세스, 네트워크 연결, 더 세밀한 종속성 정보 수집

정교한 마이그레이션 계획 수립에 유리

3️⃣ 핵심 포인트

실제로 이전해 주는 서비스는 아니다.

무엇을 어떻게 옮길지 판단하는 입력 데이터를 제공한다.

117. AWS Application Migration Service (MGN)

MGN은 온프레미스나 다른 클라우드의 서버를 AWS로 리호스팅(Lift-and-Shift)하는 데 특화된 서비스다.

서버 단위 이전에 강함

지속 복제 기반

다운타임을 줄이기 쉬움

Source Server │ 복제 에이전트 │ 스테이징 영역 │ Cutover │ AWS Production

👉 “서버 자체를 AWS로 옮기고 싶을 때 가장 직접적인 도구”

MGN 총정리

1️⃣ 작동 방식

복제 에이전트가 디스크 데이터를 지속 복제한다.

AWS 쪽 스테이징 영역에 저비용 리소스로 데이터를 보관한다.

컷오버 시 실제 프로덕션 인스턴스로 전환한다.

2️⃣ 장점

광범위한 OS/플랫폼 지원

운영 중 시스템 이전에 유리

자동화 비중이 높아 인력 부담을 줄일 수 있다.

3️⃣ DMS와 비교

서비스 대상 주 용도
DMS 데이터베이스 DB 데이터 복제/마이그레이션
MGN 서버 전체 서버 리호스팅

118. 대규모 데이터를 AWS로 전송

대규모 데이터 이전은 단순 속도 비교가 아니라 데이터 양, 전송 기간, 지속성, 비용, 일회성 여부를 함께 보고 결정해야 한다.

작은 데이터셋이면 굳이 DX가 필요 없을 수 있음

대용량 일회성 전송에는 Snowball이 유리할 수 있음

지속 복제는 VPN, DX, DataSync, DMS와 함께 고려해야 함

작은 데이터 -> 인터넷 / VPN 지속 연결 -> VPN / DX / DataSync / DMS 대용량 일회성 -> Snowball

👉 “데이터셋과 시간 제약에 따라 답이 달라진다”

대규모 데이터 전송 총정리

1️⃣ 방식 비교

방식 장점 주의사항
공용 인터넷 / VPN 빠르게 시작 가능 대용량 전송엔 느릴 수 있음
Direct Connect 예측 가능한 전용 회선 구축 리드타임 존재
Snowball 대용량 일회성 이전에 강함 지속 복제용은 아님
DataSync 대량 데이터 동기화 자동화 네트워크 연결 필요
DMS DB 지속 복제 범용 파일 전송용은 아님

2️⃣ 예시 판단

200TB 같은 대형 데이터셋은 Snowball이 매우 현실적일 수 있다.

남은 변경분만 DMS/DataSync로 마무리하는 하이브리드 전략도 자주 쓰인다.

지속적 전송이라면 DX 또는 VPN 위에 적절한 데이터 이동 서비스를 올리는 방식이 좋다.

119. VMware Cloud on AWS

VMware Cloud on AWS는 온프레미스 VMware 환경을 AWS 위로 확장해, 익숙한 VMware 운영 모델을 유지하면서 클라우드 이점을 얻는 서비스다.

vSphere 기반 운영 조직에 매우 중요

기존 VMware 워크로드를 비교적 자연스럽게 AWS로 확장 가능

DR, 마이그레이션, 하이브리드 클라우드 전략과 잘 연결됨

온프레미스 VMware │ ├─ 확장 ▼ VMware Cloud on AWS │ └─ AWS 서비스 연동

👉 “운영 방식은 VMware, 인프라 확장은 AWS”

VMware Cloud on AWS 총정리

1️⃣ 왜 필요한가

기존 VMware 운영팀이 완전히 다른 운영 모델로 급격히 전환하지 않아도 된다.

데이터센터 확장, DR, 마이그레이션을 더 빠르게 수행할 수 있다.

AWS 서비스와 연결해 백업, 보안, 분석, 스토리지 확장을 활용할 수 있다.

2️⃣ 사용 사례

사용 사례 설명
데이터센터 확장 추가 서버 자원을 AWS에서 확보
워크로드 마이그레이션 VMware 기반 애플리케이션을 자연스럽게 이전
재해 복구 클라우드에 빠른 복구 사이트 확보
하이브리드 운영 온프레미스와 클라우드를 함께 사용

3️⃣ 주의사항

VMware 운영 모델을 유지할 수 있는 장점이 있지만, 클라우드 네이티브 전환과는 별개다.

즉시 현대화보다 점진적 이전 전략에 더 잘 맞는다.

🎯 전체 구조

Disaster Recovery / Migration ├─ RPO / RTO ├─ Backup and Restore ├─ Pilot Light ├─ Warm Standby ├─ Multi Site / Hot Site ├─ Multi Region ├─ DMS / SCT / CDC ├─ Aurora Migration ├─ AWS Backup / Vault Lock ├─ Application Discovery / MGN ├─ Large Data Transfer └─ VMware Cloud on AWS

120. AWS 이벤트 처리 방법

AWS 이벤트 처리는 어떤 사건이 발생했을 때 해당 사건을 감지하고, 다른 서비스가 자동으로 반응하도록 연결하는 방식이다.

서비스 간 결합도를 낮출 수 있음

비동기 처리와 확장성에 매우 유리함

Lambda, SQS, SNS, EventBridge, S3 Event가 핵심 조합

이벤트 발생 │ ├─ 큐(SQS) ├─ 토픽(SNS) ├─ 이벤트 버스(EventBridge) └─ 함수 실행(Lambda)

👉 핵심은 “요청이 오면 즉시 처리”가 아니라 이벤트를 안전하게 전달하고, 필요할 때 확장 가능하게 처리하는 것

AWS 이벤트 처리 총정리

1️⃣ 이벤트 기반 아키텍처가 중요한 이유

서비스 간 직접 연결을 줄여 장애 전파를 막을 수 있다.

트래픽이 순간적으로 몰려도 큐와 비동기 처리로 흡수할 수 있다.

이벤트를 여러 소비자에게 동시에 전달하는 구조를 만들 수 있다.

2️⃣ 대표 구성요소

구성요소 역할 핵심 포인트
Lambda 이벤트 발생 시 코드 실행 짧고 빠른 처리에 적합
SQS 메시지를 보관하고 소비자가 나중에 처리 버퍼링, 재시도, 백프레셔 흡수
SNS 이벤트를 여러 구독자에게 동시에 전달 Fan-out 구조의 핵심
EventBridge AWS/SaaS/사용자 정의 이벤트 라우팅 정교한 필터링과 다중 타깃 연결
S3 Event S3 객체 이벤트 발생 업로드, 삭제, 복원 등에 반응

121. Lambda + SQS / SNS

Lambda는 SQS나 SNS와 결합할 때 가장 자주 쓰이는 이벤트 소비자다. 하지만 SQS와 연결할 때와 SNS와 연결할 때의 처리 방식은 다르다.

Lambda + SQS = 큐를 폴링하면서 안정적으로 처리

Lambda + SNS = 비동기 푸시 방식으로 즉시 전달

재시도와 DLQ 처리 방식도 서로 다름

SQS -> Lambda (polling) SNS -> Lambda (push)

👉 둘 다 “이벤트 -> 함수 실행”처럼 보이지만 전달 방식과 실패 처리 전략이 다르다

Lambda + SQS / SNS 총정리

1️⃣ Lambda + SQS

SQS는 큐에 메시지를 저장하고, Lambda 서비스가 큐를 폴링해서 메시지를 읽어 처리한다.

메시지는 큐에 안전하게 저장된다.

Lambda가 배치 단위로 읽어 간다.

문제가 발생하면 재시도가 가능하다.

반복 실패 시 DLQ로 보내 후속 분석이 가능하다.

항목 설명
전달 방식 Lambda 서비스가 SQS를 폴링
장점 메시지 보관, 재시도, 트래픽 버퍼링 가능
실패 처리 다시 큐에 남아 재시도되거나 DLQ로 이동
적합한 경우 비동기 처리, 작업 지연 허용, 백프레셔 흡수 필요 시

2️⃣ Lambda + SQS FIFO

FIFO 큐는 메시지 순서를 보장해야 할 때 사용한다.

같은 메시지 그룹 내 순서가 보장된다.

앞 메시지가 실패하면 뒤 메시지 처리가 막힐 수 있다.

순서 보장이 중요한 대신 처리 유연성은 낮아진다.

따라서 FIFO는 “무조건 더 좋은 큐”가 아니라 순서가 정말 중요한 경우에만 선택해야 하는 큐다.

3️⃣ Lambda + SNS

SNS는 메시지를 비동기적으로 Lambda에 직접 전달한다.

SNS가 Lambda를 푸시 방식으로 호출한다.

처리 실패 시 내부적으로 재시도를 수행한다.

필요하면 DLQ나 별도 SQS 큐와 결합할 수 있다.

항목 Lambda + SQS Lambda + SNS
전달 방식 큐 폴링 비동기 푸시
메시지 저장 큐에 보관 SNS 자체는 큐처럼 장기 보관 개념이 아님
적합한 경우 안정적 비동기 처리 빠른 알림성 이벤트 전달

4️⃣ Fan-out Pattern

Fan-out Pattern은 하나의 이벤트를 여러 소비자에게 동시에 전달하는 구조다.

Producer │ SNS Topic ├─ SQS A ├─ SQS B └─ Lambda C

앱이 여러 SQS에 직접 넣는 방식보다 안정적이다.

한 곳에서 실패하더라도 다른 소비자에게 미치는 영향을 줄일 수 있다.

새로운 구독자를 붙이기 쉬워 확장성이 높다.

직접 SDK로 여러 큐에 각각 전송하면, 중간 실패 시 일부 큐만 메시지를 받는 문제가 생길 수 있다. 따라서 SNS를 중앙 분배 계층으로 두고 SQS를 구독자로 붙이는 구조가 더 안정적이다.

122. S3 Event 알림과 EventBridge

S3 Event Notification은 객체 생성, 삭제, 복원 같은 이벤트가 발생했을 때 다른 서비스에 알림을 보내는 기능이다. 여기에 EventBridge를 결합하면 훨씬 더 정교한 이벤트 처리 구조를 만들 수 있다.

S3 자체 이벤트 알림은 간단하고 빠름

EventBridge는 더 많은 타깃과 고급 필터링을 제공

단순 자동화와 복잡한 이벤트 라우팅을 구분해서 설계해야 함

S3 Event ├─ Lambda / SNS / SQS └─ EventBridge -> 다양한 서비스

👉 “S3가 직접 알려줄 수도 있고, EventBridge를 통해 더 넓게 퍼뜨릴 수도 있다”

S3 Event / EventBridge 총정리

1️⃣ S3 Event Notification

항목 설명 포인트
지원 이벤트 객체 생성, 삭제, 복원, 복제본 생성 등 버킷 이벤트에 반응 가능
필터 이름 기반 필터(prefix/suffix) 특정 파일 패턴만 처리 가능
대표 대상 Lambda, SNS, SQS 썸네일 생성 같은 자동화에 적합
특징 간단하고 직관적 전달까지 수초~수분 걸릴 수 있음

2️⃣ S3 Event with EventBridge

S3 이벤트를 EventBridge로 보내면 더 정교한 규칙과 더 많은 타깃을 활용할 수 있다.

객체 이름뿐 아니라 크기 같은 조건도 활용 가능

여러 대상 서비스로 동시에 전달 가능

아카이빙, 리플레이 같은 EventBridge 기능 사용 가능

3️⃣ S3 직접 알림 vs EventBridge

방식 장점 적합한 경우
S3 Event Notification 구성이 단순하고 빠름 기본 자동화, 단일 후처리
S3 + EventBridge 필터링/확장성/타깃 다양성 우수 복잡한 이벤트 라우팅, 다중 대상 처리

123. EventBridge와 API Call 이벤트

EventBridge는 애플리케이션 이벤트뿐 아니라 AWS API 호출 이벤트에도 반응할 수 있다. 이때 중요한 연결 고리가 CloudTrail이다.

모든 API 호출은 CloudTrail에 기록될 수 있음

CloudTrail 이벤트를 EventBridge가 규칙 기반으로 소비 가능

운영 자동화와 보안 자동화에서 매우 중요

API Call │ CloudTrail │ EventBridge Rule │ Lambda / SNS / SSM / 기타 서비스

👉 “누가 무엇을 했는지 기록하고, 그 기록에 자동으로 반응하는 구조”

EventBridge API Call 총정리

1️⃣ 왜 중요한가

보안 그룹 변경 시 경고

IAM 정책 수정 시 감사 알림

루트 계정 사용 감지

특정 리소스 생성/삭제 시 자동 대응

2️⃣ 핵심 포인트

CloudTrail은 기록, EventBridge는 반응이다.

즉 “감사”와 “자동화”가 연결되는 구조다.

운영/보안 자동화의 대표 패턴으로 자주 출제된다.

124. API Gateway - Kinesis Data Streams 통합

API Gateway와 Kinesis Data Streams를 연결하면 HTTP 요청을 받아 실시간 스트리밍 파이프라인으로 넣는 구조를 만들 수 있다.

대량 이벤트 수집 API에 적합

동기 요청을 비동기 스트림 처리로 전환할 수 있음

로그, 클릭스트림, IoT 이벤트 수집에 자주 연결됨

Client Request │ API Gateway │ Kinesis Data Streams │ Consumer / Analytics / Storage

👉 “API로 받은 이벤트를 바로 스트림으로 흘려보내는 구조”

API Gateway - Kinesis 총정리

1️⃣ 왜 사용하는가

모바일/웹/디바이스에서 들어오는 요청을 표준 API로 받을 수 있다.

백엔드가 바로 처리하지 않고 스트림에 적재해 후속 처리를 분리할 수 있다.

실시간 분석과 비동기 소비자 확장이 쉬워진다.

2️⃣ 적합한 경우

클릭 로그 수집

실시간 이벤트 수집

고속 데이터 인입 파이프라인

125. AWS의 캐싱 전략

캐싱 전략은 같은 데이터를 더 빠르고 더 저렴하게 반복 제공하기 위해 어느 계층에 캐시를 둘 것인지 설계하는 것이다.

캐시는 특정 서비스 하나의 기능이 아님

CloudFront, API Gateway, Redis, DAX, 애플리케이션 내부 등 여러 계층에서 가능

앞단에 가까울수록 빠르지만 유연성은 달라질 수 있음

사용자 가까운 쪽 CloudFront ↓ API Gateway Cache ↓ Redis / DAX ↓ DB / 원본 저장소

👉 “캐시는 어디에 둘지에 따라 속도, 비용, 운영 복잡도가 달라진다”

AWS 캐싱 전략 총정리

1️⃣ 주요 캐시 계층

계층 설명 특징
CloudFront 전 세계 엣지 캐시 정적/일부 동적 콘텐츠 가속
API Gateway Cache API 응답 캐시 리전 서비스, API 응답 최적화
ElastiCache Redis/Memcached 애플리케이션 인메모리 캐시 유연성 높음, 앱 로직과 함께 설계 필요
DAX DynamoDB 전용 캐시 DynamoDB 읽기 성능 최적화
애플리케이션 내부 캐시 EC2/Lambda 내부 캐싱 구현 자유도 높음

2️⃣ 핵심 포인트

S3 자체에는 “애플리케이션 캐시” 같은 개념이 있는 것은 아니다.

CloudFront는 글로벌 캐시, API Gateway 캐시는 리전 캐시라는 차이를 이해해야 한다.

뒤쪽 계층으로 갈수록 더 일반적인 캐시는 가능하지만 비용과 지연이 늘 수 있다.

3️⃣ 설계 시 고민할 것

무엇을 캐싱할지

얼마나 오래 캐싱할지

언제 무효화할지

캐시 일관성 문제를 어떻게 다룰지

126. AWS에서 IP 주소 차단

AWS에서 IP 차단은 한 곳에서만 처리하는 것이 아니라 어느 계층에서 막을 것인지를 먼저 결정해야 한다.

NACL, 보안 그룹, WAF, CloudFront Geo Restriction, OS 방화벽 등 선택지가 다름

L3/L4 차단과 L7 차단을 구분해야 함

글로벌 서비스에서는 단순 보안 그룹만으로 해결되지 않는 경우가 많음

네트워크 계층 -> NACL 인스턴스 허용 -> Security Group 애플리케이션 계층 -> WAF 국가 단위 차단 -> Geo Restriction

👉 “IP 차단은 어디서 보느냐에 따라 답이 달라진다”

IP 차단 총정리

1️⃣ 구성요소별 역할

구성요소 가능한 일 제한
NACL IP 차단 규칙 생성 가능 서브넷 레벨, Stateless
ALB Security Group 허용 규칙 기반 접근 제어 차단 규칙은 직접 없음
NLB 구성에 따라 SG 사용 제약 고려 L4 중심 설계
EC2 Security Group 허용 규칙만 설정 가능 명시적 차단 불가
OS 방화벽 인스턴스 내부 차단 가능 운영 부담, CPU 비용
WAF IP, 패턴, 요청 수 기반 차단 가능 추가 비용 발생
CloudFront Geo Restriction 국가 단위 차단 세부 애플리케이션 패턴 제어는 제한

2️⃣ 실무 포인트

글로벌 앱에서는 모든 클라이언트 IP를 미리 아는 것이 현실적으로 어렵다.

따라서 단순 SG보다 WAF나 Geo Restriction이 더 현실적인 경우가 많다.

CloudFront 앞단 구조에서는 원본이 보는 IP와 실제 클라이언트 IP 처리 방식을 이해해야 한다.

3️⃣ 기억해야 할 핵심

NACL = 차단 가능

Security Group = 허용만 가능

WAF = L7 요청 단위 차단

CloudFront + 글로벌 서비스 = WAF / Geo Restriction이 자주 정답

127. AWS의 고성능 컴퓨팅 (HPC)

HPC(High Performance Computing)는 대규모 연산을 매우 빠르게 처리하기 위해 고성능 컴퓨팅, 네트워킹, 스토리지를 조합하는 방식이다.

기상 예측, 머신러닝, 자율주행, 과학 계산에 자주 사용

많은 리소스를 즉시 확보할 수 있다는 점에서 클라우드와 잘 맞음

HPC는 단일 서비스가 아니라 여러 서비스의 조합

Compute + Network + Storage + Orchestration = HPC

👉 “HPC는 서비스 하나를 고르는 문제가 아니라 성능 중심 아키텍처를 조합하는 문제”

HPC 총정리

1️⃣ AWS에서 HPC가 유리한 이유

필요한 순간에 대량의 컴퓨팅 자원을 빠르게 확보할 수 있다.

사용한 만큼 지불하므로 대규모 일시성 작업에 유리하다.

고성능 네트워크와 파일 시스템, 배치 서비스가 함께 제공된다.

2️⃣ 대표 사용 사례

기상 시뮬레이션

유전체 분석

머신러닝/딥러닝 학습

자율주행 시뮬레이션

128. HPC를 위한 데이터 전송과 스토리지

HPC는 계산만 빠르면 되는 것이 아니라, 대용량 데이터를 얼마나 빨리 옮기고 읽고 쓰느냐도 매우 중요하다.

입력 데이터가 크면 전송 전략이 성능에 직접 영향

스토리지 종류에 따라 처리 방식이 달라짐

네트워크 스토리지와 로컬 스토리지를 구분해야 함

HPC 데이터/스토리지 총정리

1️⃣ 데이터 전송 방식

서비스 설명 적합한 경우
Direct Connect 전용 물리 회선으로 대용량 데이터 전송 지속적이고 안정적인 대량 전송
Snowball / Snowmobile 물리 장비 기반 대용량 전송 일회성 대규모 데이터 이동
DataSync 온프레미스와 AWS 간 고속 동기화 NFS, SMB, S3, EFS, FSx 연계

2️⃣ 스토리지 구성

분류 서비스 특징
Instance-attached EBS 영구 블록 스토리지
Instance-attached Instance Store 매우 높은 IOPS, 데이터 영속성 약함
Network Storage S3 대규모 객체 저장
Network Storage EFS 공유 파일 시스템
HPC 전용 FSx for Lustre 고성능 병렬 파일 시스템, S3와 연계 가능

129. HPC를 위한 Compute & Networking

HPC에서는 어떤 인스턴스를 쓰느냐뿐 아니라, 인스턴스 간 통신 속도와 지연 시간이 매우 중요하다.

CPU/GPU/메모리 최적화 인스턴스 사용

클러스터 배치 그룹으로 네트워크 성능 향상

ENA, EFA 같은 고성능 네트워킹 기능이 핵심

EC2 Instance ├─ CPU / GPU / Memory 최적화 ├─ Placement Group ├─ ENA └─ EFA

👉 “HPC에서는 서버 성능만큼 서버 사이 통신 성능이 중요하다”

HPC Compute / Networking 총정리

1️⃣ 대표 요소

구성요소 설명 포인트
EC2 CPU/GPU/메모리 최적화 인스턴스 선택 워크로드 성격에 맞는 타입 중요
Spot Instance 저비용 대규모 연산 자원 중단 허용 가능한 작업에 적합
Cluster Placement Group 최고 수준 네트워크 근접성 확보 노드 간 통신 집중 작업에 유리

2️⃣ ENA / EFA / ENI 차이

항목 의미 핵심 포인트
ENI Elastic Network Interface 기본 네트워크 인터페이스 개념
ENA Elastic Network Adapter 높은 대역폭과 높은 PPS 제공
EFA Elastic Fabric Adapter HPC용 초고성능 네트워크 인터페이스

3️⃣ Enhanced Networking

SR-IOV 기반

낮은 지연 시간, 높은 처리량 제공

ENA는 고성능 네트워크의 기본 축

4️⃣ EFA가 중요한 이유

Linux 기반 HPC 워크로드에서 특히 중요

MPI(Message Passing Interface) 기반 분산 계산에 적합

노드 간 통신이 밀집된 환경에서 성능 차이가 큼

130. HPC의 Automation and Orchestration

대규모 연산은 자원만 많다고 끝나지 않는다. 작업을 어떻게 예약하고, 클러스터를 어떻게 자동 구성하느냐가 생산성을 결정한다.

AWS Batch는 대규모 작업 실행 자동화

AWS ParallelCluster는 HPC 클러스터 구성 자동화

수동으로 EC2를 일일이 띄우는 것보다 훨씬 효율적

Automation / Orchestration 총정리

1️⃣ AWS Batch

AWS Batch는 대규모 배치 작업을 큐에 넣으면, 필요한 EC2/Spot 자원을 자동으로 준비해 실행해 주는 서비스다.

작업 예약이 쉬움

컴퓨팅 자원 프로비저닝 자동화

대규모 배치/HPC 작업에 적합

2️⃣ AWS ParallelCluster

AWS ParallelCluster는 오픈소스 기반 HPC 클러스터 배포 도구다.

텍스트 설정 파일로 클러스터를 정의

VPC, 서브넷, 인스턴스 타입, 노드 구성을 자동화

EFA 활성화 같은 고성능 옵션도 포함 가능

3️⃣ 왜 중요한가

HPC는 리소스가 많고 구조가 복잡해 수동 구성이 비효율적이다.

자동화 도구를 써야 클러스터 재현성과 운영 속도가 올라간다.

131. EC2 인스턴스 고가용성

EC2 인스턴스는 기본적으로 하나의 AZ에서 실행되기 때문에, 별도 구성을 하지 않으면 고가용성이 자동으로 보장되지 않는다.

단일 인스턴스는 단일 장애 지점이 될 수 있음

Multi-AZ 분산, ELB, ASG, 모니터링 자동화가 핵심

단순히 서버를 띄우는 것과 고가용성을 갖춘 것은 다름

EC2 한 대 └─ 장애 시 중단 EC2 여러 대 + ELB + ASG └─ 장애 시 자동 우회 / 교체

👉 “EC2는 기본적으로 고가용하지 않다. 사용자가 고가용 구조를 만들어야 한다.”

EC2 고가용성 총정리

1️⃣ 핵심 구성요소

구성요소 역할 포인트
다중 AZ 배치 장애 도메인 분산 한 AZ 장애가 전체 장애로 이어지지 않게 함
ELB 정상 인스턴스로 트래픽 분산 헬스 체크 기반 우회
ASG 비정상 인스턴스 자동 교체 자동 복구의 핵심
CloudWatch Events / Alarm 이상 징후 감지 자동 복구나 알림 트리거
Elastic IP 고정 퍼블릭 IP 유지 특정 구조에서는 Role과 자동 전환 설계 필요

2️⃣ ASG를 활용한 고가용성

ASG는 비정상 인스턴스를 자동 교체한다.

ELB와 연결하면 정상 인스턴스에게만 트래픽을 보낼 수 있다.

여러 AZ에 분산 배치하면 훨씬 안정적이다.

3️⃣ 기억해야 할 핵심

단일 EC2 = 고가용성 아님

고가용성 = ELB + ASG + Multi-AZ + 모니터링

인스턴스 자체보다 “구조”가 가용성을 만든다

🎯 전체 구조

AWS Event / Caching / HPC / HA ├─ Lambda + SQS / FIFO / SNS ├─ Fan-out Pattern ├─ S3 Event Notification ├─ EventBridge + CloudTrail ├─ API Gateway -> Kinesis ├─ CloudFront / API Gateway / Redis / DAX 캐시 ├─ NACL / SG / WAF / Geo Restriction ├─ HPC Data Transfer / Storage ├─ ENA / EFA / Placement Group ├─ AWS Batch / ParallelCluster └─ EC2 HA with ELB / ASG / CloudWatch

132. CloudFormation (대규모 인프라 배포 및 관리)

CloudFormation은 AWS 인프라를 선언적으로 정의하고, 그 정의대로 리소스를 자동 생성·수정·삭제하는 Infrastructure as Code 서비스다.

“이렇게 만들고 싶다”를 템플릿으로 선언하면 AWS가 실제 리소스를 구성한다

보안 그룹, EC2, S3, 로드 밸런서 같은 여러 리소스를 한 번에 배포 가능

대규모 인프라를 반복 가능하고 일관되게 운영할 때 핵심이 되는 서비스

Template │ CloudFormation Stack │ AWS Resources ├─ Security Group ├─ EC2 Instance ├─ S3 Bucket └─ Load Balancer

👉 핵심은 “수동으로 하나씩 만드는 것”이 아니라 원하는 인프라 상태를 코드로 선언하고 재현하는 것

CloudFormation 총정리

1️⃣ 왜 중요한가

인프라를 코드로 관리하면 실수와 편차를 줄일 수 있다.

운영, 개발, 테스트 환경을 같은 템플릿으로 반복 생성할 수 있다.

변경 사항을 코드 리뷰로 검토할 수 있어 운영 안정성이 올라간다.

2️⃣ Infrastructure as Code 관점

항목 설명 핵심 포인트
선언적 방식 원하는 최종 상태를 적는다 순서를 일일이 코딩하지 않아도 됨
재현성 같은 템플릿으로 같은 인프라 반복 생성 환경 간 차이 감소
버전 관리 코드 저장소에서 변경 이력 추적 코드 리뷰와 감사에 유리
자동화 배포와 변경을 자동화 가능 대규모 운영에 필수

3️⃣ CloudFormation의 장점

관점 장점 설명
Cost 비용 구조 파악이 쉬움 스택 단위로 리소스를 묶어 관리하고 태그 전략과 함께 쓰기 좋다
Productivity 빠른 생성/파괴/재배포 가능 실험 환경을 쉽게 만들고 지울 수 있다
Consistency 같은 설계를 여러 환경에 반복 적용 리전, 계정, 환경이 달라도 템플릿 기준으로 일관성 유지
Extensibility 커스텀 리소스 확장 가능 기본 지원이 없는 기능도 확장 가능

4️⃣ Stack과 Template

CloudFormation에서 Template는 설계도이고, Stack은 그 설계도로 실제 만들어진 AWS 리소스 묶음이다.

Template = “무엇을 만들지”를 정의한 코드

Stack = Template이 실제로 배포된 결과

Stack Update = 기존 인프라를 코드 변경에 맞춰 수정

5️⃣ Stack Designer와 시각화

CloudFormation은 스택 내부 리소스 간 관계를 시각적으로 파악하는 데도 유용하다.

구성요소 간 관계를 다이어그램처럼 볼 수 있다.

WordPress 같은 참조 아키텍처 스택을 이해하는 데 도움 된다.

특히 여러 환경, 여러 리전, 여러 계정에서 반복 배포할 때 강력하다.

6️⃣ 실습 예시

아래처럼 템플릿의 Resources 섹션에 EC2 인스턴스를 선언하면, 그 정의를 바탕으로 실제 리소스를 생성할 수 있다.

Resources: MyInstance: Type: AWS::EC2::Instance Properties: AvailabilityZone: us-east-1a ImageId: ami-a4c7edb2 InstanceType: t2.micro

7️⃣ 교본 관점 핵심 포인트

CloudFormation은 “대규모 인프라 배포” 문제를 해결한다.

운영 자동화, DR, 반복 배포, 멀티 계정 전략과 자연스럽게 연결된다.

수동 콘솔 작업보다 코드형 인프라가 장기적으로 훨씬 안정적이다.

133. Amazon SES와 Pinpoint

SES와 Pinpoint는 모두 메시지 전달과 커뮤니케이션에 관련된 서비스지만, 역할과 추상화 수준이 다르다.

SES는 이메일 송수신 중심의 메시징 서비스

Pinpoint는 이메일, SMS, 푸시, 음성, 인앱 메시지를 포함한 마케팅/고객 커뮤니케이션 플랫폼

즉 “이메일 엔진”과 “캠페인/고객 커뮤니케이션 플랫폼”의 차이로 이해하면 쉽다

SES -> 이메일 전송/수신 Pinpoint -> 다채널 커뮤니케이션 / 세분화 / 캠페인

👉 SES는 “보내는 기술”, Pinpoint는 누구에게 어떤 메시지를 어떤 채널로 보낼지까지 포함한 운영 도구

SES / Pinpoint 총정리

1️⃣ Amazon SES (Simple Email Service)

SES는 전 세계로 이메일을 안전하고 대규모로 송수신할 수 있는 완전 관리형 이메일 서비스다.

API 또는 SMTP 방식으로 메일 발송 가능

아웃바운드뿐 아니라 인바운드 이메일도 지원

DKIM, SPF, 피드백, 열람 추적, 반송 처리 같은 이메일 운영 기능 제공

기능 설명
발송 방식 SES API, SMTP
지원 범위 아웃바운드 / 인바운드 이메일
보안 DKIM, SPF 등 이메일 신뢰성 관련 기능 제공
통계 열람, 반송, 피드백 추적 가능

2️⃣ Amazon Pinpoint

Pinpoint는 고객에게 이메일, SMS, 푸시 알림, 음성, 인앱 메시지를 전달할 수 있는 확장형 양방향 커뮤니케이션 서비스다.

메시지 세분화와 개인화가 가능하다.

세그먼트 기반 메시징이 가능하다.

캠페인 운영, 전달 일정, 반응 추적에 강하다.

3️⃣ SES / SNS / Pinpoint 차이

서비스 핵심 역할 적합한 경우
SES 이메일 발송/수신 트랜잭션 메일, 시스템 알림 메일
SNS Pub/Sub 기반 메시지 전달 서비스 간 알림, 이벤트 팬아웃
Pinpoint 다채널 마케팅/고객 커뮤니케이션 캠페인, 개인화, 세그먼트 메시징

4️⃣ 기억해야 할 핵심

SES는 이메일 전문 서비스다.

Pinpoint는 고객 커뮤니케이션 플랫폼에 가깝다.

즉 같은 메시징이라도 운영 수준과 목적이 다르다.

134. AWS Systems Manager와 운영 자동화

AWS Systems Manager(SSM)는 EC2와 온프레미스 서버를 중앙에서 운영, 패치, 접속, 자동화할 수 있게 해주는 운영 관리 서비스 모음이다.

SSH 없이 인스턴스 접속 가능

명령 실행, 패치 관리, 유지보수 일정, 자동화 Runbook 제공

운영 자동화와 보안 강화를 함께 가져갈 수 있음

Systems Manager ├─ Session Manager ├─ Run Command ├─ Patch Manager ├─ Maintenance Windows └─ Automation

👉 SSM은 단일 기능이 아니라 “서버 운영을 중앙에서 관리하는 제어판”에 가깝다

Systems Manager 총정리

1️⃣ Session Manager

Session Manager는 SSH 키나 Bastion Host 없이 EC2 및 온프레미스 서버에 보안 셸 세션을 여는 기능이다.

포트 22를 열 필요가 없다.

SSH 키를 직접 관리하지 않아도 된다.

세션 로그를 S3 또는 CloudWatch Logs로 저장할 수 있다.

Linux, macOS, Windows 환경을 지원한다.

항목 Session Manager 전통적 SSH/Bastion
접속 방식 에이전트 기반 세션 네트워크 포트와 키 기반
포트 22 불필요 보통 필요
로그 기록 중앙 저장 가능 별도 구성 필요

2️⃣ Run Command

Run Command는 여러 인스턴스에 스크립트나 명령을 원격으로 실행하는 기능이다.

SSH 없이 명령 실행 가능

리소스 그룹 단위로 여러 서버에 동시에 배포 가능

결과를 S3 또는 CloudWatch Logs로 저장 가능

상태를 SNS, IAM, CloudTrail, EventBridge와 연계 가능

3️⃣ Patch Manager

Patch Manager는 운영체제와 애플리케이션 패치를 자동화하는 기능이다.

EC2와 온프레미스 환경 모두 지원

Linux, macOS, Windows 지원

패치 일정과 규정 준수 확인에 유용하다

4️⃣ Maintenance Windows

Maintenance Windows는 패치, 재부팅, 드라이버 업데이트, 소프트웨어 설치 같은 작업이 수행될 시간 창을 정의하는 기능이다.

언제 작업할지

얼마 동안 작업할지

어떤 작업을 실행할지

즉, 운영 작업을 “아무 때나”가 아니라 정해진 유지보수 창 안에서 통제된 방식으로 실행하게 만들어 준다.

5️⃣ Automation

Automation은 운영 Runbook을 코드처럼 실행해 반복 작업을 자동화하는 기능이다.

인스턴스 재시작

AMI 생성

EBS 스냅샷 생성

AWS 리소스에 대한 표준 운영 절차 자동화

이 기능은 EventBridge, AWS Config, 콘솔, SDK, CLI 등과 연계해 트리거할 수 있다.

6️⃣ 교본 관점 핵심 포인트

Session Manager = 안전한 접속

Run Command = 명령 실행

Patch Manager = 패치 운영

Maintenance Windows = 작업 시간 통제

Automation = 반복 운영 절차 자동화

135. AWS Cost Explorer

Cost Explorer는 AWS 비용과 사용량을 시간, 서비스, 태그, 리소스 기준으로 시각화하고 분석할 수 있는 비용 관리 도구다.

비용이 어디서 발생하는지 빠르게 파악 가능

예측과 절감 전략 수립에 도움 됨

대규모 계정 운영에서 필수적인 FinOps 도구 중 하나

Usage Data │ Cost Explorer ├─ 시각화 ├─ 분석 ├─ 예측 └─ 절감 전략

👉 “얼마를 썼는가”를 넘어서 왜 썼고 앞으로 얼마나 쓸 것인가까지 보는 도구

Cost Explorer 총정리

1️⃣ 주요 기능

기능 설명
비용 시각화 시간 흐름에 따른 비용/사용량 확인
사용자 정의 보고서 태그, 서비스, 계정 기준 분석
예측 과거 데이터를 바탕으로 미래 비용 추정
절감형 플랜 분석 Savings Plans/RI 최적화에 도움

2️⃣ 왜 중요한가

비용 최적화는 아키텍처 설계와 운영의 중요한 축이다.

대규모 인프라에서는 태그 전략과 함께 써야 의미가 커진다.

사용량 기반 서비스일수록 시계열 분석이 중요하다.

136. Amazon Elastic Transcoder

Elastic Transcoder는 S3에 저장된 미디어 파일을 다양한 디바이스가 재생 가능한 형식으로 자동 변환하는 관리형 서비스다.

비디오/오디오 포맷 변환에 적합

파일 수가 많아질수록 확장성이 중요해지는 영역에 유리

직접 EC2에 트랜스코딩 파이프라인을 구성하지 않아도 됨

Input Bucket │ Transcoding Pipeline │ Output Bucket │ PC / Mobile / Tablet / 기타 디바이스

👉 “원본 미디어를 다양한 소비 환경에 맞게 자동 변환하는 서비스”

Elastic Transcoder 총정리

1️⃣ 장점

완전 관리형 서비스

사용량 기반 과금

대량 파일 처리에도 유연하게 확장 가능

2️⃣ 적합한 경우

동영상 서비스

멀티 디바이스 대응이 필요한 미디어 플랫폼

직접 미디어 처리 인프라를 운영하고 싶지 않을 때

137. AWS Batch

AWS Batch는 대규모 배치 작업을 큐에 넣으면, 필요한 컴퓨팅 자원을 자동으로 준비하고 작업을 실행·종료해 주는 관리형 배치 처리 서비스다.

수십만 개 수준의 배치 작업도 효율적으로 처리 가능

EC2 또는 Spot 인스턴스를 자동 조정

작업 정의 기반으로 컨테이너화된 배치를 실행할 수 있음

Job Queue │ AWS Batch │ EC2 / Spot / Container Runtime │ Batch Job 실행 후 종료

👉 “배치 작업에만 집중하면 나머지 자원 준비와 확장은 AWS가 맡는 구조”

AWS Batch 총정리

1️⃣ 핵심 특징

작업에는 시작과 끝이 있다.

필요한 시점에만 컴퓨팅 자원을 띄운다.

작업량에 따라 EC2/Spot 규모를 자동 조절한다.

컨테이너 이미지 기반 작업 정의를 사용할 수 있다.

2️⃣ Batch vs Lambda

항목 AWS Batch Lambda
실행 시간 장시간 작업 가능 최대 15분 제한
런타임 자유도 컨테이너 기반으로 매우 유연 지원 런타임 및 함수 모델 중심
스토리지 EC2/EBS 등 활용 가능 디스크 공간 제한적
적합한 작업 대규모 배치, 장시간 처리 짧은 이벤트 처리

3️⃣ 기억해야 할 핵심

Batch는 관리형이지만 내부적으로는 컴퓨팅 자원을 활용한다.

즉 “서버리스 함수”라기보다 “관리형 배치 오케스트레이션”에 가깝다.

138. Amazon AppFlow

Amazon AppFlow는 SaaS 애플리케이션과 AWS 서비스 간 데이터를 연결하고 이동시키는 완전 관리형 통합 서비스다.

Salesforce, SAP, Slack, ServiceNow 같은 SaaS와 AWS를 연결

일정 기반, 이벤트 기반, 주문형 통합 가능

필터링, 검증, 기본 변환 같은 데이터 처리 지원

SaaS Source │ AppFlow │ S3 / Redshift / 기타 대상

👉 “애플리케이션 간 데이터 이동을 직접 코드로 짜지 않게 해주는 서비스”

AppFlow 총정리

1️⃣ 대표 Source / Destination

구분 예시
Source Salesforce, SAP, Zendesk, Slack, ServiceNow
Destination S3, Redshift, Snowflake, Salesforce 등

2️⃣ 핵심 기능

스케줄 기반 통합

이벤트 기반 통합

주문형 데이터 이동

필터링과 유효성 검사

PrivateLink를 통한 비공개 전송 가능

3️⃣ 왜 중요한가

SaaS 데이터를 분석용 S3/Redshift로 옮기는 데 매우 유용하다.

직접 API 연동 코드를 모두 짜지 않아도 된다.

데이터 통합과 분석 파이프라인 구축 속도를 높여 준다.

🎯 전체 구조

CloudFormation / Ops / Integration ├─ CloudFormation │ ├─ Template │ ├─ Stack │ └─ IaC ├─ SES / Pinpoint │ ├─ Email │ └─ Multi-channel Communication ├─ Systems Manager │ ├─ Session Manager │ ├─ Run Command │ ├─ Patch Manager │ ├─ Maintenance Windows │ └─ Automation ├─ Cost Explorer ├─ Elastic Transcoder ├─ AWS Batch └─ AppFlow

139. AWS Well-Architected

AWS Well-Architected는 좋은 클라우드 아키텍처를 설계하고 운영하기 위한 원칙과 점검 기준을 제공하는 프레임워크다.

단순히 서비스를 나열하는 것이 아니라 “좋은 아키텍처란 무엇인가”를 판단하는 기준을 제공

아키텍처를 모범 사례에 맞게 점검하고 개선하는 데 사용

Solutions Architect, 운영팀, 플랫폼팀 모두에게 매우 중요한 사고 틀

아키텍처 설계 │ Well-Architected 기준 적용 │ 문제 발견 / 개선 │ 더 안정적이고 효율적인 시스템

👉 핵심은 “AWS 서비스를 많이 아는 것”이 아니라 그 서비스를 어떤 원칙으로 조합할지 아는 것

AWS Well-Architected 총정리

1️⃣ 왜 중요한가

아키텍처 품질을 감에 의존하지 않고 기준으로 점검할 수 있다.

비용, 보안, 안정성, 성능 같은 요소를 균형 있게 볼 수 있다.

새로운 시스템 설계뿐 아니라 기존 시스템 개선에도 활용된다.

2️⃣ Well-Architected가 강조하는 사고방식

원칙 설명 핵심 포인트
용량을 추측하지 말 것 필요 용량을 미리 크게 잡기보다 Auto Scaling 활용 과소/과대 프로비저닝 위험 감소
프로덕션 규모 테스트 작은 실험만으로는 실제 병목을 알기 어려움 실제 운영 조건에서 검증 필요
자동화 반복 작업과 운영 절차를 코드/도구로 자동화 운영 실수 감소, 실험 속도 증가
진화하는 아키텍처 요구 사항 변화에 맞춰 구조도 계속 바뀌어야 함 한 번 만든 설계가 영원한 정답은 아님
데이터 기반 운영 감이 아니라 메트릭, 로그, 실제 사용 패턴으로 판단 CloudWatch, 분석 지표와 연결됨
GameDay 장애 상황을 시뮬레이션하며 실제 대응력 점검 복구 전략은 문서보다 실전 연습이 중요

3️⃣ CloudFormation과 연결되는 이유

Well-Architected는 자동화를 매우 중요하게 본다. 그래서 CloudFormation 같은 IaC가 있으면 여러 환경에서 실험, 재배포, 복구 연습을 훨씬 쉽게 수행할 수 있다.

같은 템플릿으로 여러 환경 배포 가능

실험 후 파괴/재생성 용이

재해 복구 시 재현 가능한 아키텍처 확보

140. Well-Architected Framework 6 Pillars

Well-Architected Framework의 핵심은 6개의 Pillar(축)로 아키텍처를 점검하는 것이다.

운영 우수성

보안

안정성

성능 효율성

비용 최적화

지속 가능성

Well-Architected ├─ Operational Excellence ├─ Security ├─ Reliability ├─ Performance Efficiency ├─ Cost Optimization └─ Sustainability

👉 좋은 아키텍처는 한 축만 잘한다고 완성되지 않고 여섯 축의 균형으로 완성된다

6 Pillars 총정리

1️⃣ Pillar별 의미

Pillar 의미 대표 질문
운영 우수성 운영을 얼마나 안정적이고 반복 가능하게 수행하는가 관측성, 자동화, 운영 절차가 준비됐는가?
보안 권한, 데이터, 네트워크, 감사가 적절히 설계됐는가 최소 권한, 암호화, 탐지가 적용됐는가?
안정성 장애가 나도 얼마나 잘 버티고 복구하는가 Multi-AZ, 자동 복구, 백업이 준비됐는가?
성능 효율성 적절한 기술과 리소스를 효율적으로 선택했는가 워크로드에 맞는 인스턴스/서비스를 썼는가?
비용 최적화 필요한 성능을 유지하면서 불필요한 비용을 줄였는가 미사용 자원, 과대 프로비저닝이 없는가?
지속 가능성 에너지와 자원 사용을 효율적으로 했는가 불필요한 리소스를 줄이고 효율적 구조를 썼는가?

2️⃣ 시험/실무 관점 핵심

보안과 안정성은 언제나 중요하지만, 비용 최적화와 성능 효율성도 함께 봐야 한다.

운영 우수성은 자동화, 관측성, 운영 프로세스 성숙도와 강하게 연결된다.

지속 가능성은 최신 시험/실무 모두에서 점점 중요해지고 있다.

141. Well-Architected Tool

Well-Architected Tool은 실제 워크로드를 선택하고, 질문에 답하면서 6가지 Pillar 기준으로 점검하고 개선 조언을 받는 도구다.

프레임워크를 실제 점검 절차로 바꿔 주는 도구

아키텍처 리뷰를 체계적으로 수행할 수 있게 도와줌

단순 문서가 아니라 실제 개선 액션으로 연결하기 좋음

Workload 선택 │ 질문 응답 │ 6 Pillars 기준 점검 │ 개선 권고 도출

👉 프레임워크가 “이론”이라면 Tool은 그 이론을 실제 리뷰 절차로 바꾸는 실행 장치

Well-Architected Tool 총정리

1️⃣ 어떻게 쓰는가

워크로드를 하나 선택한다.

각 Pillar에 대해 질문에 답한다.

위험이 높은 항목과 개선 포인트를 확인한다.

개선 작업을 아키텍처 리팩토링과 연결한다.

2️⃣ 왜 유용한가

막연한 “좋은 설계”를 구체적인 질문으로 바꿔 준다.

팀 간 공통 언어를 만들어 준다.

주기적인 아키텍처 점검 문화를 만드는 데 도움 된다.

3️⃣ 잘 활용하는 방법

처음 설계 시 1회만 쓰는 게 아니라, 시스템이 커질 때마다 반복 점검한다.

신규 프로젝트뿐 아니라 기존 운영 시스템에도 적용한다.

GameDay, 비용 점검, DR 점검과 함께 활용하면 효과가 커진다.

142. Trusted Advisor

Trusted Advisor는 AWS 계정 전체를 분석해 비용, 성능, 보안, 내결함성, 서비스 할당량 관점의 권장사항을 제공하는 계정 수준 점검 서비스다.

Well-Architected가 워크로드 중심이라면, Trusted Advisor는 계정/리소스 상태 점검 성격이 강함

운영 중인 리소스를 빠르게 스캔해 개선 포인트를 찾는 데 유리

특히 비용 절감, 보안 누락, 리소스 낭비 탐지에 자주 쓰임

AWS Account │ Trusted Advisor 분석 ├─ 비용 ├─ 성능 ├─ 보안 ├─ 내결함성 └─ 서비스 할당량

👉 Trusted Advisor는 “아키텍처 철학”보다 현재 계정 상태를 실용적으로 진단하는 도구에 가깝다

Trusted Advisor 총정리

1️⃣ 5가지 검사 범주

범주 무엇을 보는가 대표 예시
비용 최적화 낭비되고 있는 리소스 비용 활용도 낮은 EC2, 미사용 EBS, 비효율 리소스
성능 리소스 성능 병목 가능성 활용률 높은 EC2, CloudFront 활동량, EBS 성능 최적화
보안 보안 모범 사례 누락 여부 루트 MFA, 액세스 키 노출, S3 퍼블릭 권한, 과도한 SSH 오픈
내결함성 장애 복구/고가용성 준비 수준 ASG / RDS / ELB Multi-AZ 여부, 스냅샷 상태
서비스 할당량 리소스 한도 도달 가능성 서비스 제한 근접 여부

2️⃣ 지원 수준과 한계

모든 고객에게 기본 검사(Core checks)는 제공된다.

더 많은 기능과 전체 검사를 활용하려면 비즈니스/엔터프라이즈 수준 지원 플랜이 필요하다.

지원 플랜이 없으면 Programmatic Access가 제한될 수 있다.

3️⃣ 대표 검사 예시

범주 예시
비용 최적화 활용도 낮은 EC2, 사용되지 않는 로드 밸런서, 낮은 활용도의 EBS, Savings Plans/RI 추천
성능 활용률이 매우 높은 EC2, CloudFront 활동량, EBS 성능 관련 권장사항, DNS Alias 권장
보안 루트 MFA 확인, IAM 키 교체, 노출된 액세스 키, S3 퍼블릭 액세스, SSH 오픈 포트
내결함성 EBS 스냅샷 상태, AZ 균형, ASG/RDS/ELB Multi-AZ 여부
서비스 할당량 한도 도달 전 리소스 제한 증가 필요 여부

4️⃣ Well-Architected와의 차이

도구 중심 성격
Well-Architected Framework / Tool 워크로드 아키텍처 설계 원칙과 구조적 리뷰
Trusted Advisor AWS 계정과 리소스 상태 실용적 점검과 권장사항

5️⃣ 교본 관점 핵심 포인트

Well-Architected는 “어떻게 설계해야 하는가”를 묻는다.

Trusted Advisor는 “지금 계정에서 무엇이 잘못되었는가”를 보여준다.

둘은 경쟁 관계가 아니라, 설계 원칙과 운영 점검이라는 서로 다른 축이다.

🎯 전체 구조

AWS Well-Architected ├─ Framework │ ├─ 모범 사례 │ ├─ 아키텍처 진화 │ ├─ 자동화 │ └─ GameDay / 데이터 기반 운영 ├─ 6 Pillars │ ├─ 운영 우수성 │ ├─ 보안 │ ├─ 안정성 │ ├─ 성능 효율성 │ ├─ 비용 최적화 │ └─ 지속 가능성 ├─ Well-Architected Tool │ └─ 워크로드 질문 기반 점검 └─ Trusted Advisor ├─ 비용 ├─ 성능 ├─ 보안 ├─ 내결함성 └─ 서비스 할당량

📚 AWS 데이터베이스 정리

1️⃣ 관계형 데이터베이스 (SQL)

🔹 Amazon RDS

전통적인 관계형 데이터베이스

MySQL, PostgreSQL, Oracle, SQL Server 지원

ACID 트랜잭션

ERP, 금융 시스템, 일반 웹 서비스

🔹 Amazon Aurora

AWS가 만든 클라우드 최적화 SQL DB

MySQL / PostgreSQL 호환

고성능, 자동 확장

SaaS, 대규모 웹 서비스

✔ RDS vs Aurora
일반 서비스 → RDS
고성능 + 확장성 필요 → Aurora

2️⃣ NoSQL

🔹 Amazon DynamoDB

완전 서버리스 Key-Value DB

자동 확장

밀리초 응답

모바일, 게임, IoT

🔹 Amazon DocumentDB

MongoDB 호환 문서형 DB

JSON 기반

유연한 스키마

콘텐츠 관리, 카탈로그

3️⃣ 인메모리 (Cache)

🔹 Amazon ElastiCache (Redis / Memcached)

초고속 캐시

DB 부하 감소

세션 관리, 랭킹 시스템

🔹 Amazon MemoryDB

Redis 기반 + 영속성

캐시 + 데이터 저장 역할

4️⃣ 분석 / 데이터 웨어하우스

🔹 Amazon Redshift

대규모 데이터 분석

OLAP 최적화

BI, 경영 분석

🔹 Amazon Athena

S3 데이터에 SQL 분석

서버리스

로그 분석

5️⃣ 특수 목적 DB

🔹 Amazon Neptune

그래프 DB

추천 시스템, 관계 분석

🔹 Amazon Timestream

시계열 DB

IoT, 센서 데이터

🔹 Amazon QLDB

원장(Ledger) DB

변경 불가 감사 로그

🔥 한 눈에 비교

서비스 유형 대표 사용처

RDS 관계형 ERP, 금융

Aurora 고성능 관계형 SaaS

DynamoDB Key-Value 모바일, IoT

DocumentDB 문서형 콘텐츠

ElastiCache 캐시 세션, 랭킹

Redshift 분석 BI

Neptune 그래프 추천

Timestream 시계열 IoT

QLDB 원장 감사 로그

📌 시험용 암기 공식

SQL → RDS / Aurora
Key-Value → DynamoDB
Cache → Redis
분석 → Redshift
그래프 → Neptune
시계열 → Timestream
감사 로그 → QLDB

🎯 정리

👉 트랜잭션이면 관계형
👉 확장성과 속도면 DynamoDB
👉 분석이면 Redshift
👉 실시간 캐시면 Redis

사용 패턴	추천 스토리지
자주 접근	S3 Standard
가끔 접근, 즉시 필요	Standard-IA
비용 우선, 단일 AZ 가능	One Zone-IA
아카이브 + 즉시 접근	Glacier Instant Retrieval
아카이브 + 몇 분~시간 허용	Glacier Flexible Retrieval
거의 접근 없음	Glacier Deep Archive
패턴 예측 불가	Intelligent-Tiering

서비스	주 사용 환경	프로토콜	핵심 특징
FSx for Windows	Windows 환경	SMB	AD 통합, NTFS, ACL
FSx for Lustre	HPC, ML	POSIX	초고성능, 병렬 처리
FSx for NetApp ONTAP	하이브리드 환경	NFS/SMB/iSCSI	스냅샷, 중복 제거, 복제
FSx for OpenZFS	ZFS 워크로드	NFS	ZFS 기능 완전 지원

Gateway 종류	프로토콜	백엔드	용도
S3 File Gateway	NFS/SMB	S3	파일 공유
FSx File Gateway	SMB	FSx Windows	Windows 네이티브 파일 공유
Volume Gateway	iSCSI	S3 + Snapshot	블록 스토리지 백업
Tape Gateway	iSCSI VTL	S3 + Glacier	테이프 대체

서비스	스토리지 유형	접근 방식 / 프로토콜	주요 사용 상황	핵심 특징
Amazon S3	객체(Object)	HTTP / REST API	백업, 데이터 레이크, 정적 웹 호스팅	무한 확장, 11 9's 내구성, 대부분 AWS 서비스와 연동
S3 Glacier	객체 아카이브	REST API	장기 보관, 규제 준수 데이터	저비용, 복구 지연 존재
Amazon EBS	블록(Block)	EC2 직접 연결	DB, 트랜잭션 시스템	단일 AZ, 고성능 IOPS, io1/io2 다중 연결 지원
Instance Store	물리적 블록	EC2 로컬 디스크	임시 캐시, 고성능 처리	초고속 IOPS, 인스턴스 종료 시 데이터 삭제
Amazon EFS	파일(File)	NFS (POSIX)	Linux 다중 인스턴스 공유	Multi-AZ, 자동 확장, 서버리스
FSx for Windows	파일(File)	SMB	Windows 파일 서버, AD 환경	NTFS, ACL, AD 통합
FSx for Lustre	파일(File)	POSIX	HPC, ML, 대규모 병렬 연산	초고속 처리, S3와 통합 가능
FSx for NetApp ONTAP	파일 + 블록	NFS / SMB / iSCSI	하이브리드 NAS 마이그레이션	스냅샷, 복제, 중복 제거, 압축 지원
FSx for OpenZFS	파일(File)	NFS	ZFS 기반 워크로드	ZFS 기능 완전 지원, 고성능
S3 File Gateway	하이브리드 파일	NFS / SMB	온프레미스 파일 → S3 연결	로컬 캐시, IAM 연동
FSx File Gateway	하이브리드 파일	SMB	온프레미스 ↔ FSx Windows	로컬 캐시, AD 통합
Volume Gateway	하이브리드 블록	iSCSI	온프레미스 볼륨 백업	S3에 스냅샷 저장, Cached/Stored 모드
Tape Gateway	하이브리드 아카이브	iSCSI VTL	테이프 백업 대체	S3 + Glacier 기반 가상 테이프
AWS Transfer Family	전송 인터페이스	FTP / FTPS / SFTP	레거시 파일 전송 유지	S3/EFS를 FTP처럼 사용
AWS DataSync	동기화 서비스	NFS / SMB / API	대용량 정기 동기화	10Gbps 전송, 메타데이터 유지
Snow Family	오프라인 전송	물리 장치	초대용량 초기 마이그레이션	네트워크 병목 제거

Gateway 유형	연결 대상 (AWS)	프로토콜	온프레미스 저장 방식	주요 목적	대표 사용 상황
S3 File Gateway	Amazon S3	NFS / SMB	자주 쓰는 데이터 로컬 캐시	파일 기반 → 객체 스토리지 연결	온프레미스 파일 서버를 S3에 연결
FSx File Gateway	FSx for Windows	SMB	로컬 캐시	Windows 파일 서버 하이브리드 구성	AD 환경, Windows 공유 드라이브 확장
Volume Gateway (Cached)	Amazon S3 (EBS 스냅샷 형태)	iSCSI	핫 데이터만 캐시	저지연 블록 스토리지	온프레미스 앱 + 클라우드 백업
Volume Gateway (Stored)	Amazon S3 (백업용)	iSCSI	전체 데이터 온프레미스 유지	정기 백업	온프레미스 볼륨 전체 백업
Tape Gateway	S3 + Glacier	iSCSI (VTL)	테이프 캐시	물리 테이프 대체	기존 백업 시스템 유지 + 클라우드 아카이브

구분	File Gateway	Volume Gateway	Tape Gateway
스토리지 유형	파일	블록	가상 테이프
주 사용 목적	파일 공유 확장	백업 / DR	레거시 테이프 대체
백엔드 저장소	S3	S3 (EBS Snapshot)	S3 → Glacier
레거시 시스템 유지	가능	가능	가장 적합

항목	Kinesis	SQS FIFO
정렬 기준	Partition Key	Message Group ID
병렬성	샤드 수	Group 수
재처리	가능	불가

항목	SQS	Amazon MQ
아키텍처	서버리스	브로커 서버
확장성	무제한	제한적
프로토콜	AWS API	JMS, AMQP 등
주 용도	신규 클라우드 설계	레거시 이전

항목	EC2	Lambda
운영 방식	가상 서버	가상 함수
실행 방식	항상 실행	요청 시 실행
확장	서버 추가 필요	자동
과금	시간 단위	실행 시간 단위

항목	CloudFront Functions	Lambda@Edge
런타임	JavaScript	Node.js / Python
실행 시간	< 1ms	최대 5~10초
트리거	Viewer 단계	Viewer + Origin
네트워크 접근	불가	가능

항목	Provisioned	On-Demand
용량 설정	사전 지정	자동
비용	저렴	상대적으로 높음
적합한 환경	예측 가능	급격한 트래픽

항목	DAX	ElastiCache
용도	DynamoDB 캐시	범용 캐시
쿼리 캐시	가능	직접 구현
집계 결과	비추천	적합

항목	DynamoDB	DocumentDB
API	AWS 전용	MongoDB 호환
구조	Key-Value	Document
쿼리 유연성	제한적	강력
사용 사례	초고속 트랜잭션	복잡한 JSON 데이터

항목	DynamoDB	Keyspaces
API	AWS 전용	Cassandra CQL
마이그레이션	불가	Cassandra 이전 가능
서버리스	완전 서버리스	관리형 Cassandra

DB	유형	주요 특징	대표 사용처
RDS	관계형	관리형 SQL DB	전통적 웹앱
Aurora	관계형	고성능 클라우드 최적화	대규모 트래픽 서비스
DynamoDB	NoSQL	초고속 Key-Value	모바일, 게임
DocumentDB	문서형	MongoDB 호환	JSON 중심 앱
Neptune	그래프	관계 중심 데이터	추천, 소셜 네트워크
Keyspaces	NoSQL (Cassandra)	분산 대규모 처리	IoT, 로그
QLDB	원장 DB	불변 이력 저장	금융, 감사
Timestream	시계열	시간 기반 데이터 분석	IoT, 모니터링

OLTP	OLAP
트랜잭션 처리	대규모 분석
RDS/Aurora	Redshift

ETL	ELT
변환 후 적재	적재 후 변환
Glue	Redshift

유형	설명
SQL 애플리케이션용	SQL 기반 실시간 분석
Apache Flink용	코드 기반 고급 스트리밍 처리

항목	Kinesis	MSK
메시지 크기	1MB 고정	기본 1MB (확장 가능)
구조	Shard	Partition
확장	Split / Merge 가능	추가만 가능
보관 기간	기본 7일	1년 이상 가능
생태계	AWS 중심	Kafka 오픈소스

계층	서비스
수집	IoT Core / Kinesis / MSK
스트리밍 처리	Kinesis Analytics / Flink
저장	S3 (Data Lake)
SQL 분석	Athena
웨어하우스	Redshift
BI	QuickSight

분야	서비스
Computer Vision	Rekognition / Textract
Speech	Transcribe / Polly
Language (NLP)	Comprehend / Comprehend Medical / Translate
Conversational AI	Lex / Connect
Search	Kendra
Prediction	Forecast
Recommendation	Personalize
Custom ML	SageMaker

Kjjedd

Gongbuhaja

이전 포스트

Network

다음 포스트

서비스	핵심 기능
Rekognition	이미지/비디오 분석
Textract	문서 OCR
Transcribe	음성 → 텍스트
Polly	텍스트 → 음성
Translate	번역
Lex	챗봇
Connect	클라우드 콜센터
Comprehend	텍스트 의미 분석
Forecast	시계열 예측
Kendra	문서 검색
Personalize	추천 시스템
SageMaker	직접 ML 구축

서비스	역할
CloudWatch	성능 모니터링
CloudTrail	API 로그
Config	구성 및 규정

방식	설명
Blocklist	전체 허용 후 일부 Deny
Allowlist	일부만 허용 (나머지 전부 차단)

구분	Action	ARN
버킷	s3:ListBucket	arn:aws:s3:::bucket
객체	Get/Put/Delete	arn:aws:s3:::bucket/*

구분	특징
IAM Role	권한을 “바꿔서 사용”
Resource Policy	권한을 “추가 허용”

구분	목적	대표 서비스	핵심 포인트
전송 중 암호화	네트워크 도청 방지	HTTPS (TLS), ACM	MITM 방지 / Edge는 us-east-1 인증서
저장 시 암호화	디스크 데이터 보호	S3, EBS, RDS + KMS	Data Key + Envelope Encryption
클라이언트 암호화	AWS도 복호화 불가	KMS SDK	고객 책임 / 최고 보안 수준

구분	특징	사용 예
Symmetric (AES-256)	단일 키 / AWS 기본	S3, EBS, RDS
Asymmetric (RSA/ECC)	Public/Private 구조	외부 시스템 암호화
Multi-Region	Primary + Replica	Global DB

항목	SSM Parameter Store	Secrets Manager	ACM
용도	구성값 + 암호	비밀 전용	TLS 인증서
자동 Rotation	❌	✅ (Lambda)	✅ (자동 갱신)
비용	저렴	비쌈	무료(공개 인증서)
Multi-Region	❌	✅	CloudFront 글로벌

서비스	보호 계층	역할
AWS WAF	Layer 7	SQLi, XSS 방어
AWS Shield	Layer 3/4	DDoS 보호
Firewall Manager	관리 계층	Org 전체 정책 중앙 관리

서비스	무엇을 분석?	목적
GuardDuty	CloudTrail, VPC Flow, DNS	위협 탐지
Inspector	EC2, ECR, Lambda	취약점 분석
Macie	S3 데이터	PII 탐지

구분	Security Group	NACL	Network Firewall
레벨	인스턴스	서브넷	VPC 경계
Stateful	Yes	No	Yes
L7 검사	No	No	Yes
중앙 정책 관리	제한적	제한적	가능

개념	설명	핵심 포인트
재해(Disaster)	사업 지속성이나 재정에 큰 악영향을 주는 장애 이벤트	리전 장애, 데이터 손상, 네트워크 분리, 랜섬웨어 등 포함
재해 복구(DR)	장애 발생 시 서비스를 복원하는 절차와 전략	백업, 복제, 페일오버, 자동화가 모두 포함됨
온프레미스 → 온프레미스	전통적인 DR 방식	비용이 크고 관리 복잡도도 높음
온프레미스 → 클라우드	하이브리드 DR	기존 환경을 유지하면서 AWS를 DR 사이트로 활용
클라우드 리전 A → 리전 B	멀티 리전 DR	클라우드 네이티브 DR의 대표 패턴

기준	의미	영향
RPO	얼마나 최신 데이터까지 복구해야 하는가	백업 주기, 복제 방식 결정
RTO	얼마나 빨리 서비스를 복구해야 하는가	예비 인프라 규모와 자동화 수준 결정
비용	평상시 유지 비용 허용 범위	Backup / Pilot Light / Warm Standby / Hot Site 선택
복잡도	운영팀이 감당할 수 있는 설계 수준	멀티 리전, Active-Active 설계 여부에 영향

항목	RPO	RTO
관점	데이터 손실	서비스 다운타임
질문	얼마나 최근 데이터까지 복구해야 하는가?	얼마나 빨리 서비스가 살아나야 하는가?
줄이는 방법	복제 주기 단축, 지속 복제	자동화, 예비 인프라 상시 운영

전략	평상시 비용	RPO/RTO	핵심 특징
Backup and Restore	낮음	높음 / 높음	백업만 보관, 장애 시 재구성
Pilot Light	중간 이하	중간 / 중간	핵심 시스템만 상시 운영
Warm Standby	중간 이상	낮음 / 낮음	전체 시스템 축소판 운영
Multi Site / Hot Site	높음	매우 낮음 / 매우 낮음	거의 즉시 전환 가능한 운영 환경 유지

구조	설명	예시
Active-Passive	평소에는 한쪽만 서비스하고 장애 시 다른 쪽으로 전환	Pilot Light, Warm Standby
Active-Active	여러 사이트가 동시에 트래픽을 처리	Multi Site / Hot Site

장점	단점
평상시 비용이 매우 낮음	복구 시간이 길다
구조가 단순함	자동화가 부족하면 운영 실수가 생길 수 있음
비핵심 시스템에 적합	최신 데이터 보장이 약함

구성요소	설명	포인트
애플리케이션 서버	축소된 규모로 상시 실행	완전 정지는 아님
데이터 계층	지속 복제 또는 스탠바이 유지	낮은 RPO 확보에 중요
ELB / Route 53	전환용 엔드포인트 준비	페일오버 속도에 직접 영향
Auto Scaling	장애 시 생산 규모로 빠르게 확장	RTO 감소 핵심

장점	단점
RTO가 비교적 짧다	평상시 비용이 지속 발생
실제 복구 절차가 단순해진다	운영/동기화 관리가 필요함
대부분의 구성요소가 이미 살아 있음	멀티 리전 설계가 복잡해질 수 있음

서비스	역할
Route 53	DNS 기반 트래픽 전환
Aurora Global Database	리전 간 DB 복제
S3 CRR	리전 간 객체 복제
CloudFormation	재생성 자동화
AWS Backup	리전 간 백업 복사

기능	설명	포인트
Full Load	기존 데이터를 한 번에 적재	초기 이전 단계
CDC	변경 데이터 지속 복제	다운타임 최소화 핵심
동종 마이그레이션	예: Oracle -> Oracle	비교적 단순
이기종 마이그레이션	예: SQL Server -> Aurora	보통 SCT 필요

상황	SCT 필요 여부
PostgreSQL -> PostgreSQL	보통 불필요
MySQL -> Aurora MySQL	대체로 불필요 또는 최소
SQL Server -> Aurora PostgreSQL	필요 가능성 높음
Oracle -> PostgreSQL	매우 중요

방법	설명	특징
Snapshot Restore	RDS 스냅샷을 이용해 Aurora 생성	단순하지만 다운타임 발생 가능
Aurora Replica	Aurora Read Replica 생성 후 승격	지연이 0에 가까워지면 컷오버 가능
DMS	지속 복제 후 컷오버	운영 지속성이 좋음

서비스	역할	사용 예시
VM Import/Export	VM 이미지 이동	레거시 VM 이전
DMS	DB 마이그레이션	온프레미스 DB -> RDS
Application Discovery Service	사전 조사	종속성 파악
MGN	서버 리호스팅	Lift-and-shift
Storage Gateway / DataSync	데이터 이동	파일/볼륨 이전

서비스	지원 여부
EC2 / EBS	지원
S3	지원
RDS / Aurora / DynamoDB	지원
DocumentDB / Neptune	지원
EFS / FSx	지원
Storage Gateway	지원

서비스	대상	주 용도
DMS	데이터베이스	DB 데이터 복제/마이그레이션
MGN	서버 전체	서버 리호스팅

방식	장점	주의사항
공용 인터넷 / VPN	빠르게 시작 가능	대용량 전송엔 느릴 수 있음
Direct Connect	예측 가능한 전용 회선	구축 리드타임 존재
Snowball	대용량 일회성 이전에 강함	지속 복제용은 아님
DataSync	대량 데이터 동기화 자동화	네트워크 연결 필요
DMS	DB 지속 복제	범용 파일 전송용은 아님

사용 사례	설명
데이터센터 확장	추가 서버 자원을 AWS에서 확보
워크로드 마이그레이션	VMware 기반 애플리케이션을 자연스럽게 이전
재해 복구	클라우드에 빠른 복구 사이트 확보
하이브리드 운영	온프레미스와 클라우드를 함께 사용

구성요소	역할	핵심 포인트
Lambda	이벤트 발생 시 코드 실행	짧고 빠른 처리에 적합
SQS	메시지를 보관하고 소비자가 나중에 처리	버퍼링, 재시도, 백프레셔 흡수
SNS	이벤트를 여러 구독자에게 동시에 전달	Fan-out 구조의 핵심
EventBridge	AWS/SaaS/사용자 정의 이벤트 라우팅	정교한 필터링과 다중 타깃 연결
S3 Event	S3 객체 이벤트 발생	업로드, 삭제, 복원 등에 반응

항목	설명
전달 방식	Lambda 서비스가 SQS를 폴링
장점	메시지 보관, 재시도, 트래픽 버퍼링 가능
실패 처리	다시 큐에 남아 재시도되거나 DLQ로 이동
적합한 경우	비동기 처리, 작업 지연 허용, 백프레셔 흡수 필요 시