☁️ AWS 클라우드
☁️ AWS 개요
출처: 형님IT AWS 클라우드 책 (김정우 강사) — 1~22장
· 학습 목표: IAM·S3·EC2·VPC·Lambda·RDS 핵심 서비스를 이해하고 실습까지 완료한다.
AWS 서비스 카테고리
| 카테고리 | 대표 서비스 | 용도 |
|---|---|---|
| Compute | EC2, Lambda, ECS, EKS | 애플리케이션 실행 |
| Storage | S3, EBS, EFS, Glacier | 데이터 저장 |
| Network | VPC, Route 53, CloudFront, ELB | 네트워크·CDN·DNS |
| Database | RDS, DynamoDB, ElastiCache | 관계형/NoSQL/캐시 DB |
| Security | IAM, KMS, WAF, Shield | 인증·암호화·공격 방어 |
리전(Region) · AZ · Edge
- Region — 지리적 영역 (예: 서울
ap-northeast-2) - Availability Zone (AZ) — 리전 안의 독립된 데이터센터. 장애 격리용 (리전당 2~6개)
- Edge Location — CloudFront CDN 캐시 거점 (전 세계 400+개)
🔐 IAM — 계정 & 접근 관리
IAM (Identity and Access Management) = AWS 리소스에 대한 접근 제어 서비스.
4대 구성 요소
| 요소 | 설명 | 비유 |
|---|---|---|
| User | 개별 사람/앱에 부여하는 자격증명 | 직원 사원증 |
| Group | 여러 사용자에게 동일 권한 일괄 적용 | 부서 |
| Role | EC2·Lambda 등 AWS 서비스에 부여하는 권한 | 역할 배지 (교대로 착용) |
| Policy | JSON 권한 문서 (Allow/Deny) | 출입 규정 |
IAM 계정 생성 절차
- AWS 콘솔 → IAM 서비스
- 사용자 그룹 생성 →
AdministratorAccess정책 연결 - 사용자
myuser생성 → 그룹에 추가 - 액세스 키 생성 → CSV 파일 저장 (
myaccesskey.csv) - IAM 계정으로 재로그인
Policy 예시 — S3 읽기 허용
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": ["arn:aws:s3:::mybucket/*"]
}]
}
IAM 보안 모범 사례:
① 루트 계정 MFA 활성화 ·
② 최소 권한 원칙(Principle of Least Privilege) 적용 ·
③ 액세스 키 정기 교체 ·
④ 루트 계정 일상 사용 금지
📦 S3 — Simple Storage Service
- 객체 스토리지 (파일 단위 저장) · 11 9s (99.999999999%) 내구성
- Bucket — 최상위 컨테이너 (이름은 전 세계 유일)
- Object — 버킷에 저장되는 파일 (최대 5TB)
버킷 정책 — 정적 웹 호스팅 공개 읽기
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::버킷이름/*"
}]
}
S3 스토리지 클래스
| 클래스 | 용도 | 특징 |
|---|---|---|
| S3 Standard | 자주 접근하는 데이터 | 기본값, 고가용성 |
| S3 Standard-IA | 가끔 접근 (Infrequent Access) | 저장 저렴, 읽기 과금 |
| S3 Intelligent-Tiering | 접근 패턴 불규칙 | 자동 계층 이동 |
| S3 Glacier | 아카이브·장기 보관 | 분~시간 단위 복원 |
| S3 Glacier Deep Archive | 7~10년 보관 | 최저 비용·12시간 복원 |
🖥️ EC2 — Elastic Compute Cloud
AWS의 가상 서버 서비스. 인스턴스 유형 선택 → AMI → 스토리지 → 보안 그룹 → 키페어 순으로 구성한다.
인스턴스 유형 (Family)
| 패밀리 | 용도 | 예시 |
|---|---|---|
| T (범용 버스트) | 저부하 웹/개발 | t3.micro, t4g.small |
| M (범용) | 일반 애플리케이션 | m5.large, m6i.xlarge |
| C (Compute) | CPU 집약 작업 | c5.xlarge, c6g.2xlarge |
| R (Memory) | 메모리 집약·캐시·DB | r5.large, r6i.4xlarge |
| G / P (GPU) | 머신러닝·그래픽 | g4dn.xlarge, p3.2xlarge |
구매 옵션 4종
- On-Demand — 사용한 만큼 과금 (기본값, 탄력적)
- Reserved (RI) — 1~3년 약정, 최대 72% 할인
- Savings Plans — 월 사용량 약정, 유연한 할인
- Spot — 여유 용량 경매, 최대 90% 할인 (중단 가능)
🌐 VPC — Virtual Private Cloud
AWS 클라우드 내에서 논리적으로 격리된 가상 네트워크. 10.0.0.0/16 같은 CIDR 블록으로 IP 주소 범위를 정의한다.
실습 아키텍처
flowchart TB
USER([Internet 사용자]) --> IGW[Internet Gateway]
subgraph VPC["VPC 10.0.0.0/16"]
subgraph PUB["Public Subnet 10.0.1.0/24"]
BAS[Bastion / Web
Public IP] NAT[NAT Gateway] end subgraph PRI["Private Subnet 10.0.2.0/24"] APP[App Server
Private IP] DB[(RDS)] end IGW --> BAS IGW --> NAT NAT -->|Outbound Only| APP BAS -->|SSH 22| APP APP -->|3306| DB end
Public IP] NAT[NAT Gateway] end subgraph PRI["Private Subnet 10.0.2.0/24"] APP[App Server
Private IP] DB[(RDS)] end IGW --> BAS IGW --> NAT NAT -->|Outbound Only| APP BAS -->|SSH 22| APP APP -->|3306| DB end
VPC 구성 요소
- IGW (Internet Gateway) — VPC↔인터넷 양방향 통신 · 퍼블릭 서브넷 라우팅 테이블에
0.0.0.0/0 → IGW - NAT Gateway — 프라이빗 EC2의 아웃바운드만 허용 (인바운드 차단) · 퍼블릭 서브넷 배치 · 탄력적 IP 필요
- Public Subnet — 인터넷 직접 접근 가능
- Private Subnet — 인터넷 직접 접근 불가 · NAT 통해서만 아웃바운드
- 라우팅 테이블 — 서브넷 트래픽 경로 정의
통신 테스트
# 퍼블릭 EC2 → 프라이빗 EC2 SSH 접속
[root@MyWeb1 ~]# ssh root@10.0.2.101
# 프라이빗 EC2에서 NAT GW 경유 인터넷 통신
[root@MyDB1 ~]# ping -c 3 8.8.8.8
[root@MyDB1 ~]# curl -I http://www.google.com
🛡️ 보안 그룹 vs NACL
| 항목 | 보안 그룹 (Security Group) | NACL (Network ACL) |
|---|---|---|
| 적용 대상 | EC2 인스턴스(ENI) | 서브넷 전체 |
| 상태 추적 | Stateful — 응답 자동 허용 | Stateless — 인/아웃 각각 설정 |
| 규칙 처리 | 모든 규칙 평가 (OR) | 번호 순서대로 처음 매칭 적용 |
| 기본 동작 | 인바운드 전체 차단 | 인/아웃 전체 허용 (default) |
| Allow/Deny | Allow만 가능 | Allow + Deny 가능 |
흔한 출제: "보안 그룹은 Stateful, NACL은 Stateless" — 인바운드 요청을 허용하면 SG는 응답까지 자동 허용하지만, NACL은 아웃바운드 규칙에도 별도로 허용을 적어줘야 한다.
⚡ Lambda — Serverless
서버 관리 없이 코드만 작성해 실행. 이벤트 트리거 기반 · 유휴 비용 0원 · 실행 시간 최대 15분.
Lambda vs EC2
| 항목 | Lambda | EC2 |
|---|---|---|
| 서버 관리 | 불필요 (서버리스) | 직접 관리 |
| 실행 방식 | 이벤트 트리거 | 지속 실행 |
| 비용 | 실행 시간 + 요청 수 | 가동 시간 (유휴도 과금) |
| 실행 시간 제한 | 최대 15분 | 제한 없음 |
| 확장성 | 자동 수평 확장 | Auto Scaling 필요 |
기본 Python Lambda
import json
def lambda_handler(event, context):
print("Lambda 함수 실행!")
print(f"이벤트: {event}")
return {
'statusCode': 200,
'body': json.dumps('Hello from Lambda!')
}
S3 트리거 — 업로드 자동 처리
import json
import boto3
def lambda_handler(event, context):
bucket = event['Records'][0]['s3']['bucket']['name']
key = event['Records'][0]['s3']['object']['key']
s3 = boto3.client('s3')
response = s3.get_object(Bucket=bucket, Key=key)
content = response['Body'].read().decode('utf-8')
print(f"파일 내용: {content}")
return {'statusCode': 200, 'body': json.dumps(f'{key} 처리 완료')}
Serverless 활용 패턴
| 사례 | 구성 |
|---|---|
| 이미지 썸네일 생성 | S3 업로드 → Lambda → 썸네일 저장 |
| 실시간 데이터 처리 | Kinesis → Lambda → DynamoDB |
| REST API 백엔드 | API Gateway → Lambda → RDS/DynamoDB |
| 예약 작업 (Cron) | CloudWatch Events → Lambda |
| 알림 발송 | SNS/SQS → Lambda → 이메일/SMS |
🗄️ RDS — 관리형 관계형 DB
MySQL · PostgreSQL · MariaDB · Oracle · SQL Server · Aurora를 AWS가 백업·패치·복제·장애조치까지 대신 관리.
주요 기능
- Multi-AZ 배포 — 다른 AZ에 동기 Standby 복제본, 장애 시 자동 Failover
- Read Replica — 비동기 읽기 전용 복제본, 읽기 부하 분산 (최대 5개)
- 자동 백업 — 매일 스냅샷 + 5분 단위 트랜잭션 로그 (최대 35일 보관)
- DB Parameter Group — DB 엔진 설정 일괄 관리
Multi-AZ vs Read Replica
| 항목 | Multi-AZ | Read Replica |
|---|---|---|
| 목적 | 고가용성 (HA) | 읽기 성능 확장 |
| 복제 방식 | 동기 복제 | 비동기 복제 |
| 접근 가능 | Standby 접근 불가 | 읽기 가능 |
| 장애 처리 | 자동 Failover | 수동 승격 필요 |
Aurora: MySQL/PostgreSQL 호환, 스토리지 자동 확장(최대 128TB), 최대 15개 Read Replica, 3개 AZ에 6카피 복제.
⚖️ ELB — 3종 로드밸런서
Elastic Load Balancing은 트래픽을 여러 타깃(EC2/컨테이너/IP/Lambda)에 분산한다. 계층과 용도로 3종을 구분한다.
flowchart TB
USER([Client]) --> ALB["ALB (L7)
HTTP · HTTPS · gRPC"] USER --> NLB["NLB (L4)
TCP · UDP · TLS"] USER --> CLB["CLB (L4/L7 Legacy)"] ALB -->|path /api/*| TG1[Target Group A] ALB -->|path /img/*| TG2[Target Group B] NLB -->|초저지연·정적IP| TG3[Target Group C] CLB -->|단순 라운드로빈| TG4[EC2 Pool] TG1 --> EC1[EC2 · Fargate · IP] TG2 --> EC2[EC2 · Fargate · IP] TG3 --> EC3[EC2 · 고정 IP 필요 시] TG4 --> EC4[EC2 Classic]
HTTP · HTTPS · gRPC"] USER --> NLB["NLB (L4)
TCP · UDP · TLS"] USER --> CLB["CLB (L4/L7 Legacy)"] ALB -->|path /api/*| TG1[Target Group A] ALB -->|path /img/*| TG2[Target Group B] NLB -->|초저지연·정적IP| TG3[Target Group C] CLB -->|단순 라운드로빈| TG4[EC2 Pool] TG1 --> EC1[EC2 · Fargate · IP] TG2 --> EC2[EC2 · Fargate · IP] TG3 --> EC3[EC2 · 고정 IP 필요 시] TG4 --> EC4[EC2 Classic]
| 종류 | 계층 | 프로토콜 | 주요 용도 |
|---|---|---|---|
| ALB (Application) | L7 | HTTP / HTTPS / gRPC / WebSocket | Host/Path 기반 라우팅, WAF 연동, 컨테이너/Lambda 타깃 |
| NLB (Network) | L4 | TCP / UDP / TLS | 고정 IP·극저지연·초당 수백만 요청, 게임/IoT 서버 |
| GWLB (Gateway) | L3 | IP (GENEVE 터널) | 3rd-party 방화벽/IDS 체인 통과 |
헬스 체크: ALB/NLB 모두 Target Group 단위로 주기적 헬스 체크(HTTP 200, TCP 핸드셰이크). 실패한 타깃은 자동으로 라우팅 제외 → Auto Scaling과 결합해 자가 치유 구성.
📈 Auto Scaling Group (ASG)
수요에 따라 EC2 인스턴스 수를 자동으로 늘리고 줄이는 수평 확장 서비스. 4개 축으로 구성한다.
flowchart LR
CW[CloudWatch
CPU · ALB req] --> POL{{Scaling Policy}} POL -->|Scale Out| ASG[Auto Scaling Group] POL -->|Scale In| ASG ASG --> LT["Launch Template
AMI + InstanceType + UserData"] LT --> E1[EC2-1] LT --> E2[EC2-2] LT --> E3[EC2-N] subgraph ZONE[Multi-AZ 분산] E1 E2 E3 end ALB[ALB] --> E1 ALB --> E2 ALB --> E3 HC[Health Check] -.실패.-> ASG
CPU · ALB req] --> POL{{Scaling Policy}} POL -->|Scale Out| ASG[Auto Scaling Group] POL -->|Scale In| ASG ASG --> LT["Launch Template
AMI + InstanceType + UserData"] LT --> E1[EC2-1] LT --> E2[EC2-2] LT --> E3[EC2-N] subgraph ZONE[Multi-AZ 분산] E1 E2 E3 end ALB[ALB] --> E1 ALB --> E2 ALB --> E3 HC[Health Check] -.실패.-> ASG
- Launch Template — AMI, 인스턴스 타입, 키페어, SG, IAM Role, UserData 정의
- Min / Desired / Max — 유지해야 할 인스턴스 개수 범위
- Scaling Policy — Target Tracking(가장 단순) / Step / Scheduled
- Health Check — EC2 상태 + ELB 헬스 체크 통합, 비정상 인스턴스 자동 교체
Target Tracking 예시 — CPU 50% 유지
aws autoscaling put-scaling-policy \
--auto-scaling-group-name web-asg \
--policy-name cpu-50 \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{
"PredefinedMetricSpecification": {"PredefinedMetricType":"ASGAverageCPUUtilization"},
"TargetValue": 50.0
}'
Cooldown: 스케일 액션 직후 다음 액션을 미루는 대기 시간(기본 300초). 짧은 스파이크에 과반응하지 않도록 해준다.
🔌 VPC Endpoint — NAT 없이 AWS 서비스 호출
프라이빗 서브넷에서 AWS API를 호출할 때 인터넷 경유(NAT GW 비용)를 없애는 기능. 2가지 타입이 있다.
flowchart TB
subgraph GW["Gateway Endpoint (무료)"]
direction LR
EC2A[EC2 · Private Subnet] -->|Route Table
prefix list| GWE[Gateway Endpoint] GWE --> S3[(S3 · DynamoDB)] end subgraph IF["Interface Endpoint (유료 · ENI)"] direction LR EC2B[EC2 · Private Subnet] -->|Private DNS
PrivateLink| ENI[ENI in Subnet] ENI --> SVC[Kinesis · SSM · SNS
ECR · CloudWatch 등] end NOTE1[[S3 · DynamoDB 전용]] NOTE2[[그 외 대부분 AWS 서비스]] GWE -.-> NOTE1 ENI -.-> NOTE2
prefix list| GWE[Gateway Endpoint] GWE --> S3[(S3 · DynamoDB)] end subgraph IF["Interface Endpoint (유료 · ENI)"] direction LR EC2B[EC2 · Private Subnet] -->|Private DNS
PrivateLink| ENI[ENI in Subnet] ENI --> SVC[Kinesis · SSM · SNS
ECR · CloudWatch 등] end NOTE1[[S3 · DynamoDB 전용]] NOTE2[[그 외 대부분 AWS 서비스]] GWE -.-> NOTE1 ENI -.-> NOTE2
| 타입 | 지원 서비스 | 과금 | 연결 방식 |
|---|---|---|---|
| Gateway Endpoint | S3 · DynamoDB (2종) | 무료 | 라우트 테이블에 prefix list 추가 |
| Interface Endpoint | 그 외 대부분 (ECR, SQS, SNS, KMS, CloudWatch …) | 시간당 + GB | ENI(프라이빗 IP) 생성, PrivateLink 기반 |
활용 패턴: 프라이빗 Lambda가 S3에 쓰기 → Gateway Endpoint로 NAT 비용 제거 · ECS Task가 ECR에서 이미지 pull → Interface Endpoint로 폐쇄망 배포 가능.
🎯 핵심 정리 — 출제/면접 포인트
- IAM 4요소: User / Group / Role / Policy — Role은 AWS 서비스에 부여
- S3 내구성: 11 9s (99.999999999%) — 스토리지 클래스별 비용/복원 시간 트레이드오프
- VPC 라우팅: Public =
0.0.0.0/0 → IGW, Private =0.0.0.0/0 → NAT GW - SG vs NACL: SG = Stateful + Allow only + 인스턴스 · NACL = Stateless + Allow/Deny + 서브넷
- NAT Gateway: 프라이빗의 아웃바운드만 허용, 반드시 퍼블릭 서브넷에 배치
- Lambda 한계: 실행 시간 최대 15분 · 이벤트 기반 · 동시성 자동 확장
- Multi-AZ ≠ Read Replica: HA 목적 vs 읽기 확장 목적
- 비용 최적화: EC2는 RI/Savings Plans/Spot 조합 · S3는 Intelligent-Tiering · Lambda는 유휴 0원