AWS Use Case Summary
이 문서는 AWS에서 자주 혼동되는 서비스들과 시나리오를 비교 정리한 요약본입니다.
saa 문제를 풀고 작성한 오답 노트와 각 서비스별 문서를 바탕으로 작성했습니다.
아래는 관련하여 학습했던 내용들입니다.
- AWS 기본 용어
- AWS 컴퓨팅
- AWS 스토리지
- AWS 데이터베이스
- AWS 네트워킹 및 콘텐츠 전송
- AWS 보안, 자격 증명 및 규정 준수
- AWS Kinesis
- AWS Resilient Architectures 설계 (DR & HA)
1. 컴퓨팅 및 배포 (Compute & Deployment)
| 시나리오 / 키워드 | 헷갈리는 서비스 | 정답 및 선택 기준 |
|---|---|---|
| "15분 이내의 짧은 실행", "이벤트 기반", "서버리스" | AWS Batch vs Lambda | Lambda: 15분 제한 있음. 이벤트 트리거(S3 업로드 등)에 즉각 반응. |
| "대규모 배치 작업", "장시간 실행", "Docker 컨테이너" | Lambda vs AWS Batch | AWS Batch: 시간 제한 없음. 컴퓨팅 환경을 동적으로 프로비저닝하여 배치 작업 처리. |
| "타사 소프트웨어 패치 자동화", "모든 인스턴스에 명령 실행" | Lambda vs Systems Manager | Systems Manager (Patch Manager / Run Command): EC2 인스턴스 관리 및 패치 적용에 특화됨. |
| "코드만 업로드하면 인프라 자동 배포", "PaaS" | CloudFormation vs Elastic Beanstalk | Elastic Beanstalk: 개발자 친화적 PaaS. (CloudFormation은 'Infrastrucre as Code'로 템플릿 작성 필요) |
| "CPU 사용률 40% 유지", "특정 지표 유지" | Step Scaling vs Target Tracking | Target Tracking: "지표를 X로 유지한다"는 무조건 타겟 트래킹. |
| "중단 가능한 워크로드", "최저 비용" | Reserved vs Spot Instances | Spot Instances: 언제든 중단될 수 있는 배치/데이터 처리 작업에 최적(최대 90% 할인). |
| "HPC(초고속 네트워크)", "단일 AZ 내 랙 집적" | Spread vs Cluster Placement Group | Cluster PG: 인스턴스 간 물리적 거리를 최소화하여 지연 시간 단축(단일 AZ). |
| "하드웨어 장애 격리", "렉 단위 분산" | Cluster vs Spread/Partition PG | Spread/Partition PG: 하드웨어 공유를 피하고 장애 영향을 분리해야 할 때(Spread=개별, Partition=그룹). |
비용 및 운영 효율성 비교 (Cost & Operational Efficiency)
| 서비스 | 비용 모델 (Cost) | 운영 오버헤드 (Ops Overhead) | 특징 및 선택 기준 |
|---|---|---|---|
| Lambda | 최저 (요청 건수/실행 시간당 과금, 대기 비용 0) | 최소 (Serverless, 인프라 관리 X) | 15분 미만, 간헐적 실행에 최적. |
| Spot Instances | 매우 낮음 (온디맨드 대비 최대 90% 할인) | 중간 (언제든 중단 가능, 중단 처리 로직 필요) | 중단되어도 괜찮은 배치/데이터 분석 작업. |
| Reserved Instances | 낮음 (1~3년 약정 할인) | 중간 (EC2 관리 필요) | 예측 가능하고 꾸준한 상시 워크로드. |
| Elastic Beanstalk | 중간 (내부 리소스 비용 + 무료) | 낮음 (PaaS, 플랫폼 관리 자동화) | 코드만 배포하고 싶을 때 (인프라 설정 최소화). |
| EC2 On-Demand | 높음 (초 단위 과금, 약정 없음) | 높음 (OS 패치, 스케일링 직접 관리) | 유연한 개발/테스트, 단기 워크로드. |
2. 스토리지 및 데이터 마이그레이션 (Storage & Migration)
| 시나리오 / 키워드 | 헷갈리는 서비스 | 정답 및 선택 기준 |
|---|---|---|
| "Windows 파일 공유", "SMB 프로토콜", "AD 통합" | EFS vs FSx for Windows | FSx for Windows File Server: Windows & SMB는 무조건 FSx. (EFS는 리눅스 & NFS) |
| "HPC (고성능 컴퓨팅)", "Lustre", "S3 연동" | EFS vs FSx for Lustre | FSx for Lustre: HPC, 머신러닝 등 초고속 처리가 필요할 때. |
| "70TB 대용량 데이터 전송", "네트워크 대역폭 부족" | Direct Connect vs Snowball Edge | Snowball Edge: 인터넷 없이 물리적 장비로 이동. (Direct Connect는 전용선 구축에 시간/비용 소요) |
| "온프레미스 NFS/SMB를 AWS로 자동 전송", "네트워크 연결 있음" | Snowball vs DataSync | DataSync: 에이전트를 설치하여 네트워크를 통해 데이터를 자동 동기화/전송. |
| "즉시 액세스 필요", "30일 후 액세스 빈도 감소" | Glacier vs S3 Standard-IA | S3 Standard-IA: "즉시 액세스(밀리초)"가 필요하면 Glacier(분~시간 소요)는 정답이 될 수 없음. |
| "FTP/SFTP 서버 마이그레이션" | EC2 vs Transfer Family | Transfer Family: S3/EFS 위에서 FTP/SFTP 인터페이스를 제공하는 완전 관리형 서비스. |
| "법적 보존(삭제 불가)", "WORM(Write Once Read Many)" | Versioning vs Object Lock | Object Lock (Compliance Mode): 루트 사용자도 삭제 불가능. (Governance Mode는 권한 있으면 삭제 가능) |
| "글로벌 사용자 업로드 가속", "S3로 직접 전송" | CloudFront vs Transfer Acceleration | S3 Transfer Acceleration: 엣지 로케이션을 통해 S3 업로드 속도를 높임. (장거리 전송 시 유리) |
| "OS 부팅 디스크", "인스턴스 종료 시 데이터 보존 필요" | Instance Store vs EBS | EBS: 영구 블록 스토리지. (Instance Store는 휘발성, 임시 캐시용) |
비용 및 운영 효율성 비교 (Cost & Operational Efficiency)
| 서비스 | 비용 모델 (Cost) | 운영 오버헤드 (Obs Overhead) | 마이그레이션/변경 용이성 |
|---|---|---|---|
| Glacier Deep Archive | 최저 (저장 비용 최저, 검색 비용 발생) | 낮음 (S3 수명 주기 정책으로 자동 이동) | 1년에 1~2회 접근하는 장기 보관 데이터. |
| S3 Standard-IA | 낮음 (저장 비용 저렴, 검색 비용 발생) | 낮음 | 한 달에 한 번 정도 접근하지만 즉시 필요할 때. |
| DataSync | 중간 (데이터 전송량당 과금) | 최소 (에이전트 설치 후 자동 동기화) | 네트워크 연결 가능할 때 가장 빠르고 쉬운 마이그레이션. |
| Snowball Edge | 중간 (디바이스 대여료 + 전송료) | 높음 (물리적 배송/설치 필요) | 네트워크가 없거나 너무 느릴 때 대용량 이동. |
| FSx for Windows | 높음 (스토리지 + 라이선스 비용) | 중간 (완전 관리형이지만 AD 설정 등 필요) | 기존 Windows/SMB/AD 환경을 그대로 가져올 때(코드 수정 X). |
3. 네트워크 및 콘텐츠 전송 (Network & CDN)
| 시나리오 / 키워드 | 헷갈리는 서비스 | 정답 및 선택 기준 |
|---|---|---|
| "정적/동적 웹 콘텐츠 캐싱", "전 세계 지연 시간 감소" | Global Accelerator vs CloudFront | CloudFront: HTTP/HTTPS 웹 콘텐츠(이미지, HTML, API) 캐싱 및 가속에 최적. |
| "고정 IP 제공", "UDP/TCP 트래픽 가속", "게임/IoT" | CloudFront vs Global Accelerator | Global Accelerator: IP가 바뀌면 안 되거나, HTTP가 아닌 프로토콜을 가속할 때. |
| "프라이빗 서브넷에서 인터넷 접속(업데이트)" | IGW vs NAT Gateway | NAT Gateway: 프라이빗 리소스가 외부로 나갈 때(Outbound) 사용. 퍼블릭 서브넷에 배치해야 함. |
| "온프레미스-AWS 전용선 연결", "일관된 성능" | VPN vs Direct Connect | Direct Connect (DX): 인터넷을 타지 않는 전용 물리 회선. (백업으로 VPN이나 두 번째 DX 사용) |
| "S3/DynamoDB에 보안 연결 (인터넷 X)" | Interface Endpoint vs Gateway Endpoint | Gateway Endpoint: S3와 DynamoDB는 게이트웨이 엔드포인트(무료)를 사용. 나머지는 인터페이스(PrivateLink). |
| "VPC 간 1:1 연결", "대역폭 제한 없음" | Transit Gateway vs VPC Peering | VPC Peering: 두 VPC 간 단순 연결. 비용 효율적이고 대역폭 제한 없음. |
| "수백 개 VPC 연결 중앙 관리", "VPN 통합" | VPC Peering vs Transit Gateway | Transit Gateway: 복잡한 네트워크 토폴로지를 허브 앤 스포크 방식으로 간소화. |
| "특정 IP 차단", "서브넷 단위 보안" | Security Group vs NACL | NACL (Network ACL): 서브넷 단위 방화벽. 상태 비저장(Stateless). 특정 IP Deny 가능. |
비용 및 운영 효율성 비교 (Cost & Operational Efficiency)
| 서비스 | 비용 모델 (Cost) | 운영 오버헤드 (Ops Overhead) | 주요 특징 |
|---|---|---|---|
| VPC Peering | 최저 (AZ 간 데이터 전송료만 발생) | 중간 (1:1 연결, 다수 연결 시 복잡도 증가) | 비용 효율적, 단순한 두 VPC 연결. 대역폭 제한 없음. |
| Transit Gateway | 높음 (연결 시간당 비용 + 전송료) | 최소 (중앙 허브에서 모든 연결 관리) | 수백/수천 개의 VPC 및 VPN 연결을 중앙 관리. |
| VPC Endpoint (Gateway) | 무료 (S3/DynamoDB) | 최소 (라우팅 테이블 수정) | S3와 DynamoDB 접근 시 필수 (비용 0). |
| NAT Gateway | 중간 (시간당 비용 + 데이터 처리비) | 낮음 (완전 관리형) | 프라이빗 인스턴스의 인터넷 아웃바운드용. |
| CloudFront | 변동 (데이터 전송량/요청 수) | 낮음 (TTL 등 캐시 설정) | 전 세계 사용자 대상 정적 콘텐츠 가속/S3 부하 감소. |
4. 보안 및 모니터링 (Security & Monitoring)
| 시나리오 / 키워드 | 헷갈리는 서비스 | 정답 및 선택 기준 |
|---|---|---|
| "누가 API를 호출했는가?", "감사 로그" | Config vs CloudTrail | CloudTrail: API 호출 주체(Who), 시간(When), 소스IP 등을 기록. |
| "리소스 설정이 어떻게 변했는가?", "규정 준수 확인" | CloudTrail vs AWS Config | AWS Config: 리소스의 구성(Configuration) 변경 이력(History) 추적 및 규칙 위반 감시. |
| "DDoS 공격 방어", "레이어 3/4 보호" | WAF vs Shield | Shield: DDoS 방어 서비스. (Standard는 무료, Advanced는 유료/정교함) |
| "SQL Injection, XSS 차단", "웹 트래픽 필터링" | Shield vs WAF | WAF: 웹 애플리케이션 방화벽. L7(HTTP/S) 계층 공격 차단. |
| "외부 CA 인증서 만료 알림/교체" | ACM 자동 갱신 vs EventBridge 알림 | EventBridge 알림 + 수동 교체: ACM에서 발급한게 아니라 외부에서 가져온(Imported) 인증서는 자동 갱신 안 됨. |
| "DB 자격 증명 자동 교체", "RDS 연결 정보 관리" | Systems Manager vs Secrets Manager | Secrets Manager: RDS/DocumentDB 등의 비밀번호를 주기적으로 **자동 교체(Rotation)**해줌. |
| "웹/모바일 앱 사용자 가입/로그인", "JWT 토큰" | IAM User vs Cognito User Pool | Cognito User Pool: 앱 사용자를 위한 디렉터리. (IAM은 AWS 리소스 관리자용) |
| "S3 파일 암호화", "키 자동 순환(매년)" | SSE-S3 vs SSE-KMS | SSE-S3 (S3 Managed Keys): 추가 비용 없이 S3가 알아서 관리. (KMS는 키 관리 통제권이 필요할 때 사용) |
비용 및 운영 효율성 비교 (Cost & Operational Efficiency)
| 서비스 | 비용 모델 (Cost) | 운영 오버헤드 (Ops Overhead) | 특징 및 선택 기준 |
|---|---|---|---|
| Shield Standard | 무료 (모든 AWS 고객) | 없음 (자동 적용) | 일반적인 L3/L4 DDoS 방어. |
| Shield Advanced | 매우 높음 (월 $3,000 + @) | 낮음 (전담 지원팀 DRT 제공) | 엔터프라이즈급 보호, 비용 보호(DDoS로 인한 스케일링 환불). |
| WAF | 낮음 (Web ACL 규칙/요청당) | 중간 (규칙 직접 관리/업데이트) | SQL Injection, XSS 등 L7 공격 차단. |
| SSE-S3 | 무료 | 최소 (S3가 알아서 관리) | 키 관리에 신경 쓰고 싶지 않을 때 기본 암호화. |
| SSE-KMS | 저렴 (키당 월 $1 + 요청당) | 중간 (키 정책, 권한 관리 필요) | 키 사용 이력 추적(CloudTrail), 키 권한 분리 필요 시. |
| Secrets Manager | 중간 (비밀당 $0.40 + API) | 최소 (자동 교체 지원) | DB 패스워드 자동 교체/라이프사이클 관리. |
5. 데이터베이스 및 분석 (Database & Analytics)
| 시나리오 / 키워드 | 헷갈리는 서비스 | 정답 및 선택 기준 |
|---|---|---|
| "읽기 성능 향상", "수평 확장" | Multi-AZ vs Read Replica | Read Replica: 읽기 부하 분산용. (Multi-AZ는 장애 조치/고가용성 용도) |
| "실시간 데이터 수집/처리", "샤딩" | Kinesis Firehose vs Kinesis Data Streams | Kinesis Data Streams (KDS): 실시간 수집, 순서 보장, 커스텀 처리 앱 필요. |
| "데이터를 S3/Redshift로 적재", "포맷 변환" | Kinesis Data Streams vs Kinesis Firehose | Kinesis Data Firehose: 데이터를 다른 곳(Destination)으로 쉽게 전송 Delivery하기 위한 서비스. |
| "S3 데이터를 SQL로 즉시 분석", "서버리스 쿼리" | Redshift vs Athena | Athena: S3에 있는 파일에 대해 바로 표준 SQL 쿼리 실행. (Redshift는 데이터를 로딩해야 함) |
| "비정형 데이터", "스키마리스", "초고속(ms)" | RDS vs DynamoDB | DynamoDB: NoSQL 키-값 저장소. 유연한 스키마. |
| "Oracle/SQL Server 사용", "특정 버전 필수" | Aurora vs RDS | RDS: 상용 DB(Oracle, MS SQL)를 써야 하거나, 특정 마이너 버전/옵션이 필요할 때. |
| "MySQL/PostgreSQL 호환", "자동 스토리지 확장" | RDS vs Aurora | Aurora: 클라우드 네이티브. 성능이 월등히 높고(3~5배), 스토리지가 자동 확장됨. |
| "DynamoDB 읽기 성능 가속(마이크로초)", "코드 변경 X" | ElastiCache vs DAX | DAX (DynamoDB Accelerator): DynamoDB 전용 인메모리 캐시. API 호환되어 코드 변경 불필요. |
| "복잡한 조인/집계 쿼리", "페타바이트급 데이터 웨어하우스" | Athena vs Redshift | Redshift: 다차원 분석, 고성능 BI 도구 연동, 대용량 정형 데이터 분석에 최적화. |
| "Redshift에서 S3 데이터 직접 쿼리", "로딩 없이 분석" | Athena vs Redshift Spectrum | Redshift Spectrum: 이미 Redshift를 쓰고 있을 때 확장 기능으로 S3 데이터를 조인해서 분석. |
비용 및 운영 효율성 비교 (Cost & Operational Efficiency)
| 서비스 | 비용 모델 (Cost) | 운영 오버헤드 (Ops Overhead) | 애플리케이션 변경 필요 여부 |
|---|---|---|---|
| DynamoDB | 유동적 (R/W 요청량 or 스토리지) | 최소 (Serverless, 무한 확장) | 스키마 재설계 필요 (NoSQL), 높은 학습 곡선. |
| Aurora Serverless | 중간 (사용량 ACU 기반) | 낮음 (자동 시작/중지/확장) | 변경 없음 (MySQL/PostgreSQL 호환). 간헐적 워크로드. |
| RDS | 고정+@ (인스턴스 타입 + 스토리지) | 중간 (패치/백업 관리형, 확장은 수동) | 변경 없음. 상시 워크로드에 예측 가능한 비용. |
| DAX | 높음 (노드 시간당 과금) | 낮음 (완전 관리형 캐시) | 변경 없음. DynamoDB 읽기 성능 마이크로초로 가속. |
| ElastiCache | 높음 (노드 시간당 과금) | 중간 (클러스터 관리, 데이터 무효화) | 변경 필요. 코드에서 캐시 읽기/쓰기 로직 구현해야 함. |
| Athena | 저렴 (스캔한 데이터 양당 과금) | 최소 (Serverless) | 변경 없음 (표준 SQL). S3 데이터 간헐적 분석. |
| Redshift | 높음 (노드 시간당 - 비쌈) | 중간 (DW 클러스터 튜닝/관리) | 변경 있음 (데이터 로딩/스키마 설계). 대규모 상시 분석. |
기타 주요 단서
- 분리 Decoupling가 필요하다 → SQS (대기열을 통해 시스템 간 의존성 제거)
- 고가용성 High Availability을 확보해야 한다 → Multi-AZ (DB, ASG 등 여러 AZ에 분산)
- 단일 장애 지점(SPOF) 제거 → Load Balancer + Auto Scaling
- 읽기 성능 개선 (DB) → Read Replica 또는 ElastiCache/DAX (캐싱)
- 정적 콘텐츠 성능 개선 → CloudFront (CDN)
- 비용 최적화 (EC2)
- 중단 가능/배치 작업 → Spot Instances
- 꾸준한 상시 워크로드 → Savings Plans / Reserved Instances