AWS Certified Cloud Practitioner (CLF-C02) #6 Domain 3-1 핵심 서비스: 컴퓨팅과 스토리지
#5까지 도메인 2를 마쳤습니다. 이제 시험에서 가장 출제 비중이 큰 도메인 **Cloud Technology and Services (34%)**으로 들어갑니다.
이 도메인의 출제 형태는 거의 모두 **“이 시나리오에 가장 적합한 서비스는?”**입니다. 서비스의 모든 기능을 외우기보다 각 서비스가 어떤 종류의 워크로드를 푸는지를 분류해 두는 게 효율적입니다.
이번 글은 도메인 3의 전반부, 즉 컴퓨팅과 스토리지입니다.
컴퓨팅 서비스 한눈에 #
| 서비스 | 추상화 단계 | 워크로드 |
|---|---|---|
| EC2 | 가상 머신 | 가장 일반적인 컴퓨팅. OS 선택, 자유로운 SW 설치 |
| Lightsail | EC2 + 사전 패키지 | 단순 웹사이트,소규모 앱, 정액 요금 |
| ECS / EKS | 컨테이너 오케스트레이션 | 컨테이너 기반 마이크로서비스 |
| Fargate | 서버리스 컨테이너 | ECS/EKS의 노드 관리 부담 제거 |
| Lambda | 함수 단위 서버리스 | 이벤트 기반 짧은 실행 코드 |
| Elastic Beanstalk | 앱 배포 자동화 | 코드만 올리면 인프라 자동 구성 |
| Batch | 배치 작업 | 대규모 데이터 처리 |
| Outposts | 온프레미스 AWS 하드웨어 | 데이터 주권 + AWS API 일관성 |
| Local Zones / Wavelength | 지리적 확장 | 한 자리수 ms 지연 / 5G 워크로드 |
EC2: Elastic Compute Cloud #
가상 머신을 제공하는 가장 기본 서비스입니다. 실무 트랙 #2에서 다뤘습니다.
인스턴스 패밀리 #
EC2 인스턴스는 이름에 패밀리 + 세대 + 사이즈가 들어갑니다 (m5.large, c6i.xlarge).
| 패밀리 | 용도 |
|---|---|
| T (Burstable) | 일상 트래픽이 낮고 가끔 튀는 워크로드 (개발,소규모 웹) |
| M (General Purpose) | 균형 잡힌 워크로드. 가장 일반적 |
| C (Compute Optimized) | CPU 집약적 (배치 처리,게임 서버) |
| R (Memory Optimized) | 메모리 집약적 (인메모리 DB,캐시) |
| X / Z (High Memory) | 매우 큰 메모리 (SAP HANA 같은) |
| I (Storage Optimized) | 빠른 로컬 SSD (NoSQL DB) |
| G / P (Accelerated) | GPU (ML,그래픽) |
| A (Arm-based, Graviton) | 가격 효율 + 전력 효율 |
시험에서 이 패밀리를 다 외울 필요는 없습니다. “GPU 워크로드는 G/P”, “메모리 집약은 R”, “범용은 M” 정도면 충분합니다.
EC2 인스턴스 가격 모델 (간단히) #
자세한 가격 모델은 #8에서 다룹니다. 핵심만:
| 모델 | 특성 |
|---|---|
| On-Demand | 사용한 만큼. 가장 비싸지만 가장 유연 |
| Reserved Instance | 1년,3년 약정. 최대 75% 할인 |
| Savings Plans | 시간당 약정. RI보다 유연 |
| Spot Instance | 유휴 자원 활용. 최대 90% 할인. 언제든 중단 가능 |
| Dedicated Host | 물리 서버 통째로. 라이선싱,규제 |
Lambda: 서버리스 함수 #
서버 관리 없이 코드만 실행하는 서비스입니다.
| 특성 | 값 |
|---|---|
| 실행 시간 한도 | 최대 15분 |
| 메모리 | 128 MB ~ 10 GB |
| 트리거 | S3,API Gateway,SQS,EventBridge 등 다양 |
| 가격 | 요청 수 + 실행 시간 (밀리초 단위) |
| 무료 티어 | 매월 1M 요청 + 400,000 GB-초 |
시험 출제 패턴 #
- “이미지가 S3에 업로드될 때마다 자동으로 썸네일 생성” → Lambda + S3 이벤트
- “REST API를 서버 관리 없이 운영” → Lambda + API Gateway
- “1시간 이상 걸리는 데이터 처리” → Lambda 불가(15분 한도). ECS/Batch 사용
- “사용량이 매우 불규칙하고 가끔만 실행” → Lambda (사용한 만큼만 과금)
ECS,EKS,Fargate: 컨테이너 #
| 서비스 | 의미 |
|---|---|
| ECS (Elastic Container Service) | AWS 전용 컨테이너 오케스트레이션 |
| EKS (Elastic Kubernetes Service) | 관리형 Kubernetes |
| Fargate | ECS,EKS의 서버리스 모드. 노드(EC2) 관리 부담 제거 |
ECS의 두 가지 실행 모드 #
| 모드 | 의미 |
|---|---|
| ECS on EC2 | 사용자가 EC2 노드를 직접 관리 |
| ECS on Fargate | 노드 관리 불필요. 컨테이너 단위 과금 |
시험 출제 패턴 #
- “Docker 컨테이너를 실행하면서 노드를 관리하고 싶지 않다” → Fargate
- “Kubernetes 표준을 그대로 사용하면서 관리는 AWS에 위임” → EKS
- “단순히 AWS 위에서 컨테이너만 굴리고 싶다” → ECS
- “온프레미스 Kubernetes를 사용 중인데 AWS에서도 같은 도구를 쓰고 싶다” → EKS (이식성)
Elastic Beanstalk #
PaaS 형태로 앱을 배포하는 서비스입니다. 코드를 zip으로 올리면 AWS가 EC2,ELB,Auto Scaling을 자동으로 구성합니다.
지원 플랫폼: Node.js,Python,Java,Ruby,Go,.NET,PHP,Docker 등.
시험 출제 패턴 #
- “Node.js 앱을 가장 빠르게 배포하면서 인프라 설정은 최소화” → Elastic Beanstalk
- “기존 EC2,ELB,Auto Scaling을 그대로 사용하면서 배포만 자동화” → Beanstalk보다 CodeDeploy가 더 맞음
Lightsail #
**단순한 가상 서버 + 사전 구성된 앱(WordPress,LAMP,MEAN)**을 정액제로 제공합니다.
| 항목 | 값 |
|---|---|
| 가격 | $3.50/월부터 |
| 포함 | EC2 인스턴스 + 데이터 전송량 + 정적 IP + DNS + 부하 분산 (옵션) |
| 사용 사례 | 개인 블로그, 소규모 비즈니스 웹사이트 |
EC2 vs Lightsail #
- EC2. 자유롭고 강력하지만 인프라 지식 필요. 사용량 기반 과금
- Lightsail. 단순함. 정액제. 초보자,소규모
AWS Batch #
배치 작업을 위한 관리형 서비스입니다. 수백~수만 개의 작업을 자동 스케줄링,재시도.
시험 출제 패턴 #
- “수십만 개의 영상을 일괄 인코딩” → AWS Batch
- “야간에 대량 데이터를 처리” → Batch
- “한 번에 끝나는 짧은 데이터 변환” → Lambda
Outposts,Local Zones,Wavelength #
| 서비스 | 의미 |
|---|---|
| Outposts | 사용자 데이터센터 안에 둔 AWS 하드웨어. 데이터 주권 + AWS API 일관성 |
| Local Zones | 대도시에 둔 작은 리전 확장. 한 자리수 ms 지연 |
| Wavelength | 5G 통신사 안. 모바일 5G 사용자 지연 최소화 |
시험에서는 사용 사례 매핑만:
- 데이터가 사내 데이터센터를 떠나면 안 됨 → Outposts
- 한 자리수 ms 지연이 필요한 게이밍,미디어 → Local Zones
- 5G 모바일 사용자에게 지연 최소화 → Wavelength
컴퓨팅 워크로드 매핑 정리 #
| 시나리오 | 권장 서비스 |
|---|---|
| 전통적인 웹 서버 | EC2 또는 Beanstalk |
| 이벤트 기반 짧은 코드 | Lambda |
| 1시간 이상 걸리는 처리 | EC2,ECS,Batch |
| 컨테이너 + 노드 관리 부담 제거 | Fargate |
| Kubernetes 표준 | EKS |
| 코드만 올리면 인프라 자동 | Elastic Beanstalk |
| 개인 블로그,소규모 사이트 | Lightsail |
| 대규모 배치 작업 | Batch |
| 데이터를 사내에 두면서 AWS API | Outposts |
| GPU ML 워크로드 | EC2 G/P 패밀리 |
| 라이선싱 제약으로 물리 서버 필요 | Dedicated Host |
스토리지 서비스 한눈에 #
| 서비스 | 종류 | 특성 |
|---|---|---|
| S3 | 객체 스토리지 | 가장 일반적. 무한 확장. HTTP/HTTPS |
| EBS | 블록 스토리지 | EC2의 디스크 |
| EFS | 파일 스토리지 (Linux) | 여러 EC2가 동시에 마운트 |
| FSx | 파일 스토리지 (전용) | Windows/Lustre/NetApp/OpenZFS |
| Storage Gateway | 하이브리드 | 온프레미스 ↔ AWS 스토리지 연결 |
| Snow Family | 데이터 전송 디바이스 | 페타바이트 단위 오프라인 전송 |
| Backup | 통합 백업 | 여러 서비스의 백업 정책 통합 |
S3 (Simple Storage Service) #
객체 스토리지의 표준입니다. 파일을 URL로 접근합니다.
특성 #
- 무한 확장. 객체 수와 총 용량 제한 사실상 없음
- 단일 객체 최대 5TB
- 99.999999999% (11 9s) 내구성. 자동으로 여러 시설에 복제
- 버킷 이름은 전 세계 유일
- 글로벌처럼 보이지만 데이터는 리전에 있음
S3 Storage Classes #
가장 자주 출제되는 영역으로, 데이터 접근 빈도에 따라 계층을 나눕니다.
| 클래스 | 특성 | 사용 사례 |
|---|---|---|
| S3 Standard | 즉시 접근, 다중 AZ | 자주 접근하는 데이터 |
| S3 Intelligent-Tiering | 자동 계층 이동 | 접근 패턴이 불규칙,예측 불가 |
| S3 Standard-IA (Infrequent Access) | 즉시 접근, 단 GB 비용 저렴, 검색 시 추가 비용 | 월 1회 미만 접근 |
| S3 One Zone-IA | IA + 단일 AZ. 비용 저렴, 가용성 낮음 | 재생성 가능한 백업 |
| S3 Glacier Instant Retrieval | 즉시 접근, 아카이브 가격 | 분기 1회 정도 접근 |
| S3 Glacier Flexible Retrieval | 분~시간 단위 검색 | 연 1~2회 접근 |
| S3 Glacier Deep Archive | 12시간 검색, 가장 저렴 | 법적 보관 (7년+) |
시험 출제 패턴 #
- “월 한 번 정도 접근하지만 즉시 받아야 한다” → S3 Standard-IA
- “접근 패턴을 예측할 수 없고 자동 최적화하고 싶다” → Intelligent-Tiering
- “7년 동안 법적 보관 의무, 거의 접근하지 않음, 최대 저렴” → Glacier Deep Archive
- “재생성 가능한 백업, 비용 최소화” → One Zone-IA
S3 Lifecycle Policy #
객체를 시간이 지나면 자동으로 다른 클래스로 이동시키는 규칙입니다.
객체 생성 → 30일 후 Standard-IA로 → 90일 후 Glacier로 → 1년 후 삭제S3 보안 #
| 기능 | 설명 |
|---|---|
| Block Public Access | 계정,버킷,객체 수준의 퍼블릭 차단 |
| Bucket Policy | 버킷 단위 접근 정책 (JSON) |
| ACL (Access Control List) | 객체 단위 권한 (레거시, 비권장) |
| Encryption | SSE-S3 / SSE-KMS / SSE-C / 클라이언트 측 |
| Versioning | 객체 버전 보관, 실수로 삭제,덮어쓰기 복구 |
| MFA Delete | 객체 삭제에 MFA 강제 (root만 활성화 가능) |
시험에 자주 나오는 S3 시나리오 #
- “정적 웹사이트 호스팅” → S3 (Static Website Hosting)
- “단일 객체 5GB 이상 업로드” → Multipart Upload
- “타사에 일시적으로 다운로드 권한” → Pre-signed URL
- “S3 객체를 다른 리전에 복제” → Cross-Region Replication (CRR)
- “동일 리전 내 복제” → Same-Region Replication (SRR)
EBS (Elastic Block Store) #
EC2의 디스크입니다.
| 특성 | 값 |
|---|---|
| 마운트 | EC2 인스턴스 한 대에 마운트 (Multi-Attach 옵션 있음) |
| AZ 종속 | EBS 볼륨은 한 AZ에 묶임. 다른 AZ EC2에서 사용 불가 |
| 스냅샷 | S3에 저장, 다른 리전으로 복사 가능 |
| 종류 | gp3 (SSD 범용), io2 (SSD 고성능), st1 (HDD 처리량), sc1 (HDD 저비용) |
시험 출제 패턴 #
- “EC2의 부팅 디스크” → EBS
- “다른 AZ의 EC2가 같은 디스크를 마운트” → 불가. EFS 사용
- “EBS 백업” → 스냅샷 (S3에 저장)
EFS (Elastic File System) #
여러 EC2가 동시에 마운트하는 파일 스토리지입니다. Linux 전용 (NFS).
| 특성 | 값 |
|---|---|
| 동시 마운트 | 수천 대의 EC2가 동시에 같은 파일시스템 |
| 자동 확장 | 사용한 만큼 자동 증가 |
| Multi-AZ | 한 EFS가 여러 AZ의 EC2에서 사용 가능 |
| 종류 | Standard / Infrequent Access |
시험 출제 패턴 #
- “여러 EC2가 같은 파일을 공유하면서 읽기/쓰기” → EFS
- “Windows 서버용 공유 파일” → EFS 불가. FSx for Windows
FSx #
특수 워크로드용 관리형 파일 시스템들입니다.
| 종류 | 용도 |
|---|---|
| FSx for Windows File Server | Windows 환경의 SMB |
| FSx for Lustre | HPC,ML 같은 고성능 컴퓨팅 |
| FSx for NetApp ONTAP | NetApp 호환 |
| FSx for OpenZFS | OpenZFS 워크로드 |
시험에서는 매핑만:
- Windows SMB 공유 → FSx for Windows
- HPC,ML → FSx for Lustre
Storage Gateway: 하이브리드 스토리지 #
온프레미스 ↔ AWS 스토리지를 연결하는 게이트웨이입니다.
| 종류 | 용도 |
|---|---|
| File Gateway | 온프레미스 NFS/SMB ↔ S3 |
| Volume Gateway | 블록 볼륨 백업 |
| Tape Gateway | 가상 테이프 백업 → S3,Glacier |
시험 시나리오: “온프레미스 백업 테이프 시스템을 클라우드로 옮기고 싶다” → Tape Gateway.
Snow Family: 대량 데이터 전송 #
| 디바이스 | 용량 |
|---|---|
| Snowcone | 8 TB SSD / 14 TB HDD |
| Snowball Edge | 80 TB 또는 210 TB |
| Snowmobile | 100 PB (실제 트럭) |
페타바이트급 데이터를 인터넷 회선이 아니라 물리 디바이스로 전송합니다.
시험 시나리오: “사내 데이터센터의 500TB 데이터를 AWS로 한 번에 옮기고 싶다, 인터넷 회선이 느리다” → Snowball Edge.
AWS Backup: 통합 백업 #
여러 서비스(EBS,RDS,EFS,DynamoDB,FSx 등)의 백업을 하나의 정책으로 통합 관리합니다.
스토리지 워크로드 매핑 정리 #
| 시나리오 | 권장 서비스 |
|---|---|
| 일반 객체 스토리지 (파일,이미지,로그) | S3 |
| EC2의 부팅 디스크,DB 디스크 | EBS |
| 여러 Linux EC2의 공유 파일 | EFS |
| Windows 공유 파일 (SMB) | FSx for Windows |
| HPC,ML 고성능 파일시스템 | FSx for Lustre |
| 한 달에 한 번 정도 접근 | S3 Standard-IA |
| 분기 1회 즉시 접근 | S3 Glacier Instant Retrieval |
| 거의 접근 안 함, 최대 저렴 | S3 Glacier Deep Archive |
| 온프레미스 백업을 클라우드로 | Storage Gateway (Tape) |
| 페타바이트급 데이터 전송 | Snowball Edge,Snowmobile |
| 통합 백업 관리 | AWS Backup |
자주 만나는 함정 #
1) Lambda를 모든 컴퓨팅에 답으로 #
Lambda는 15분 한도가 있습니다. 긴 작업은 ECS/Batch.
2) EBS Multi-AZ #
EBS는 기본적으로 한 AZ에 묶입니다. 다른 AZ에서 같은 디스크를 마운트할 수 없습니다. 공유는 EFS.
3) EFS와 Windows #
EFS는 Linux NFS 전용입니다. Windows는 FSx for Windows.
4) S3 Glacier가 즉시 검색 가능 #
Glacier는 종류별로 검색 시간이 다릅니다. Instant Retrieval만 즉시, 나머지는 분~시간.
5) EC2 인스턴스 패밀리를 다 외우려 하기 #
T,M,C,R,G,P 정도만 외우면 됩니다. 모든 세대,사이즈를 외울 필요 없음.
6) Lightsail을 무시 #
소규모,정액제 시나리오에서 Lightsail이 정답인 경우가 의외로 잦습니다.
정리 #
이번 글에서 잡은 것:
- 컴퓨팅. EC2(VM) / Lambda(서버리스) / ECS,EKS,Fargate(컨테이너) / Beanstalk(PaaS) / Lightsail(정액 소규모) / Batch(배치) / Outposts(하이브리드)
- 워크로드 → 서비스 매핑이 핵심
- EC2 인스턴스 패밀리. T,M,C,R,G,P 등 용도별 분류
- 스토리지. S3(객체) / EBS(블록) / EFS(Linux 파일) / FSx(특수 파일) / Storage Gateway(하이브리드) / Snow(오프라인 전송)
- S3 Storage Classes. Standard / Intelligent-Tiering / Standard-IA / One Zone-IA / Glacier 3종(Instant,Flexible,Deep Archive)
- Lifecycle Policy로 자동 계층 이동
- 함정. Lambda 15분 한도 / EBS의 AZ 제약 / EFS의 Linux 한정 / Glacier 검색 시간 / 인스턴스 패밀리 과잉 암기
다음: Domain 3-2 네트워킹과 데이터베이스 #
#7 Domain 3-2 핵심 서비스: 네트워킹과 데이터베이스에서는 VPC,Subnet,Route 53,CloudFront,ELB 4종,VPN,Direct Connect,Global Accelerator의 쓰임, 그리고 RDS,Aurora,DynamoDB,ElastiCache,Redshift의 분류와 사용 사례 매핑을 정리하겠습니다.