RTO & RPO 정의
RTO (Recovery Time Objective)
서비스 중단과 서비스 복구 사이의 최대 허용 지연시간
즉, 서비스 다운타임으로 허용 가능한 시간
RPO (Recovery Point Objective)
마지막 데이터 복구 시점 이후 최대 허용 시간
즉, 허용 가능한 데이터 손실 범위
재해 발생
│◄──── RPO ────►│◄──────── RTO ────────►│
│ │ │
마지막 백업 재해 발생 시점 서비스 복구
(이 이후 데이터 완료 시점
손실 허용)
RPO = 얼마나 오래된 데이터까지 잃어도 되는가 (데이터 손실 허용량)
RTO = 재해 후 얼마 만에 복구해야 하는가 (복구 속도 목표)
Plain Text
복사
RTO — 시간(다운타임) 관점
RPO — 데이터 관점
숫자가 낮을수록 비용이 높아진다.
DR 전략 — 시험 단골
전략 1 — Backup & Restore
RTO: 수 시간 / RPO: 수 시간
가장 단순하고 저렴한 방식
Primary Region Recovery Region
[프로덕션 환경] [없음]
│
│ 스냅샷/백업 → S3 Cross-Region 복제
▼
[S3 버킷 (백업 저장)]
재해 발생 시:
① CloudFormation으로 인프라 재생성
② S3에서 데이터 복원
③ Route 53 DNS 전환
→ RTO: 수 시간 / RPO: 수 시간 (백업 주기에 따라)
Plain Text
복사
•
비용: 가장 저렴 (S3 스토리지 비용만 발생)
•
사용 사례: 규정 준수용 백업, 비중요 워크로드
전략 2 — Pilot Light
RTO: 수십 분 / RPO: 수 분
복구 리전에 핵심 워크로드 인프라 사본을 프로비저닝한다. 데이터를 복구 리전으로 복제하고 백업을 생성한다. 데이터베이스 등 데이터 복제와 백업을 지원하는 리소스는 항상 실행 중이지만, 애플리케이션 서버 등의 나머지 요소는 필요할 때 생성할 수 있도록 배포되지 않은 상태로 유지한다.
Primary Region Recovery Region
[Full 프로덕션 환경] [핵심 DB만 실행 중 🔵]
│ EC2: 미배포 (AMI만 복사)
│ DB 복제 LB: 미배포
▼ App: 미배포
[RDS Primary] ──────────► [RDS Replica 🔵 항상 ON]
재해 발생 시:
① EC2 인스턴스 AMI로 배포 (Turn On)
② Auto Scaling 스케일 아웃
③ Route 53 DNS 전환
→ RTO: 수십 분 / RPO: 수 분
Plain Text
복사
DB(데이터)는 항상 복제 중, Compute는 꺼진 상태
전략 3 — Warm Standby
RTO: 수 분 / RPO: 수 초
Pilot Light와 Warm Standby의 공통점으로는 둘 다 복구 리전에 Primary 리전 자산의 사본 환경이 있다는 것이다. 하지만 차이점은 Pilot Light는 추가 작업 없이는 요청을 처리할 수 없지만, Warm Standby는 즉시 트래픽을 처리할 수 있다는 것이다(축소된 용량에서). Pilot Light는 서버를 켜고 추가 인프라를 배포한 후 스케일 업이 필요하지만, Warm Standby는 스케일 업만 하면된다(모든 것이 이미 배포되어 실행 중).
Primary Region Recovery Region
[Full 프로덕션 환경] [축소 버전 전체 실행 중 🟡]
EC2: 최소 1대 실행 중
│ DB 복제 LB: 실행 중
▼ App: 실행 중 (소규모)
[RDS Primary] ──────────► [RDS Replica 🟡]
재해 발생 시:
① Auto Scaling으로 스케일 아웃 (Scale Up만 하면 됨)
② Route 53 DNS 전환
→ RTO: 수 분 / RPO: 수 초
Plain Text
복사
Pilot Light vs Warm Standby 결정적 차이:
Pilot Light → 서버 켜기 + 배포 + 스케일 아웃 필요
Warm Standby → 스케일 아웃만 필요 (이미 배포되어 실행 중)
전략 4 — Multi-Site Active/Active
RTO: 잠재적 0 / RPO: 거의 0
Multi-Region Active/Active는 워크로드가 여러 AWS 리전에 배포되어 모든 리전에서 트래픽을 처리한다. 이 전략은 리전 간 데이터 동기화가 필요하다.
Primary Region Recovery Region
[Full 프로덕션 환경 🟢] [Full 프로덕션 환경 🟢]
│ │
│◄──── 양방향 데이터 복제 ────► │
│ │
└────────┬───────────────────┘
│
Route 53 / Global Accelerator
(두 리전 모두 트래픽 수신)
재해 발생 시:
① 장애 리전 트래픽 자동 차단
② 남은 리전이 전체 트래픽 처리
→ RTO: 거의 0 / RPO: 거의 0
Plain Text
복사
•
비용: 가장 비쌈 (2배 인프라 운영)
•
주의: 양방향 DB 동기화 시 Write 충돌 처리 복잡
Summary
비용 낮음 ◄────────────────────────────────► 비용 높음
RTO/RPO 높음 ◄──────────────────────────────► RTO/RPO 낮음
Backup & Pilot Warm Multi-Site
Restore Light Standby Active/Active
│ │ │ │
수 시간 수십 분 수 분 거의 0
Plain Text
복사
전략 | RTO | RPO | 컴퓨트 상태 | DB 상태 | 비용 |
Backup & Restore | 수 시간 | 수 시간 | 없음 | 백업만 | |
Pilot Light | 수십 분 | 수 분 | 꺼짐(AMI 대기) | 항상 복제 중 | |
Warm Standby | 수 분 | 수 초 | 축소 실행 중 | 항상 복제 중 | |
Multi-Site A/A | ~0 | ~0 | 풀 실행 중 | 양방향 복제 | |
RTO < 1시간 → Warm Standby 이상
RTO < 15분 또는 RPO ~ 0 → Multi-Site Active/Active
비용 효율적이면서 핵심 DB만 보호 → Pilot Light
비중요 시스템, 비용 최소화 → Backup & Restore
AWS DR 핵심 서비스
AWS Elastic Disaster Recovery (DRS)
Elastic Disaster Recovery는 온프레미스 또는 다른 클라우드의 워크로드를 AWS로 DR 복구하는데 사용할 수 있다. EC2 기반 애플리케이션과 데이터베이스에 대한 AWS 호스팅 워크로드 DR에도 사용 가능하다. Pilot Light 전략을 사용해 스테이징 VPC에 데이터 사본과 꺼진 리소스를 유지한다. Failover 이벤트 발생 시 스테이징 리소스가 복구 VPC에 전체 용량 배포를 자동으로 생성한다.
온프레미스 / 타 클라우드 AWS (DR Region)
[프로덕션 서버] [Staging VPC]
│ ├── Replication Server
│ 지속적 블록 레벨 복제 ├── Replicated EBS Volumes
└──────────────────────────► └── (EC2 꺼진 상태)
Failover 트리거 시:
→ 자동으로 EC2 인스턴스 생성 (Recovery VPC)
→ RTO: 수 분 / RPO: 수 초
Plain Text
복사
MGN vs DRS 혼동 주의
AWS MGN (Application Migration Service) → 마이그레이션 (한 번 이동)
AWS DRS (Elastic Disaster Recovery) → 재해복구 (지속적 보호)
Aurora Global Database
•
RPO: 1초 미만 (비동기 복제, 일반적으로 < 1초 지연)
•
RTO: 1분 미만 (Secondary를 Primary로 승격)
•
최대 5개 Secondary 리전 지원
•
일기 전용 Secondary → Failover 시 Primary로 승격
Route 53 Failover 라우팅
Route 53 Health Check
│ Primary 엔드포인트 모니터링
│
├── Primary 정상 → Primary로 트래픽
└── Primary 비정상 → Secondary(DR)로 자동 전환
설정:
① Primary 레코드: Health Check 연결
② Secondary 레코드: Failover 타입
→ DNS TTL 낮게 설정 (60초 이하) → 빠른 전환
Plain Text
복사
AWS Backup
•
중앙 집중식 백업 정책: 여러 AWS 서비스(EC2, RDS, EFS, DynamoDB 등) 백업 통합 관리
•
Backup Plan: 일정, 보존 기간, 백업 규칙 정의
•
Cross-Account Backup: Organizations와 통합해 다른 계정으로 백업 복사
•
Cross-Region Backup: 다른 리전으로 백업 자동 복사
•
Vault Lock (WORM): 백업 불변성 보장, 삭제 방지
여러 서비스 백업을 한 곳에서 정책으로 관리 → AWS Backup
RDS 개별 스냅샷 vs AWS 정책 비교 문제 자주 출제
비용 최적화
구매 옵션
옵션 | 할인율 | 약정 | 중단 위험 | 적합한 워크로드 |
On-Demand | 없음 | 없음 | 없음 | 예측 불가, 단기 |
Reserved Instances | 최대 75% | 1년/3년, 특정 인스턴스 | 없음 | 안정적, 예측 가능 |
Savings Plans | 최대 72% | 1년/3년, $/시간 약정 | 없음 | 유연한 장기 약정 |
Spot Instances | 최대 90% | 없음 | 있음 | 중단 허용 워크로드 |
Savings Plans (시험 단골)
AWS는 Reserved Instances보다 Savings Plans를 권장한다. Savings Plans는 AWS 컴퓨팅 비용 절감을 위한 가장 쉽고 유연한 방법으로, On-Demand 대비 최대 72% 할인을 제공한다.
Reserved Instances는 특정 인스턴스 구성에 약정하지만, Savings Plans는 시간당 달러 단위의 일정 사용량에 약정하면 된다.
Savings Plans 유형 | 적용 범위 | 유연성 | 할인율 |
Compute SP | EC2 + Fargate + Lambda | 최고 (인스턴스 패밀리, OS, 리전 자유) | 최대 66% |
EC2 Instance SP | 특정 인스턴스 패밀리 + 리전 | 중간 (사이즈/OS 자유) | 최대 72% |
SageMaker SP | SageMaker 전용 | SageMaker만 | 최대 64% |
Reserved Instances
Standard RI는 가장 큰 할인을 제공하지만 수정만 가능하고 교환을 불가하다. Convertible RI는 Standard보다 낮은 할인율을 제공하지만 다른 인스턴스 속성을 가진 Convertible RI로 교환이 가능하다.
•
Standard RI → 최대 할인, 인스턴스 패밀리/리전 변경 불가, 마켓플레이스 판매 가능
•
Convertible RI → 낮은 할인, 다른 Convertible RI로 교환 가능 (유연성 ↑)
Spot Instance 핵심 패턴
•
최대 90% 절감, 단 AWS가 용량 필요 시 2분 전 통보 후 중단
•
적합한 워크로드: 배치 처리, 빅데이터, CI/CD, 머신러닝 학습, 렌더링
•
Spot Fleet: 여러 인스턴스 풀에서 Spot + On-Demand 혼합 운용
•
Capacity Rebalancing: 중단 위험 감지 시 미리 새 Spot 확보
가장 저렴 + 중단 허용 → Spot
장기 안정 워크로드, 유연성 필요 → Compute Savings Plans
장기 안정 워크로드, 최대 할인 → Standard RI
인스턴스 변경 가능성 있음 → Convertible RI
비용 최적화 도구 — 시험 단골
도구별 역할 명확히 구분
도구 | 역할 | 핵심 기능 |
Cost Explorer | 과거/현재 비용 분석 | 서비스별·태그별 비용 시각화, RI/SP 구매 추천 |
AWS Budgets | 예산 알림 설정 | 임계값 초과 시 SNS/이메일 알림, 자동 액션 |
Compute Optimizer | 리소스 적정 규모 추천 | EC2/Lambda/EBS/ECS 과소/과잉 사용 탐지 |
Trusted Advisor | 전반적 모범 사례 점검 | 비용·보안·성능·내결함성·서비스 한도 5개 영역 |
Cost & Usage Report | 가장 상세한 청구 데이터 | 시간별 리소스 단위 전체 데이터, S3 저장 후 Athena 분석 |
S3 Storage Lens | S3 사용량 최적화 | 버킷별 스토리지 사용 패턴, 비용 절감 기회 탐지 |
태깅 전략 — 비용 배분의 핵심
태그 예시:
Environment: Production / Staging / Dev
Team: Backend / Frontend / Data
CostCenter: CC-001 / CC-002
Project: ProjectA / ProjectB
→ Cost Explorer에서 태그별 필터링
→ 팀/프로젝트별 정확한 비용 배분 가능
활성화 방법:
Billing → Cost allocation tags → 태그 활성화 (24시간 후 반영)
Plain Text
복사
EC2 인스턴스가 과도하게 프로비저닝됐는지 확인 → Compute Optimizer
부서별 비용 배분 리포트 → Cost Allocation Tags + Cost Explorer
예산 초과 시 EC2 자동 중지 → AWS Budgets Action
가장 세분화된 청구 데이터 분석 → Cost & Usage Report + Athena
Summary
개념 | 한 줄 요약 |
RPO | 데이터 손실 허용 범위 (마지막 백업 이후) |
RTO | 복구 시간 목표 (중단 후 복구까지) |
Backup & Restore | 가장 저렴. RTO/RPO 수 시간. 스냅샷+IaC |
Pilot Light | DB만 항상 복제. 컴퓨트는 꺼짐. RTO 수십 분 |
Warm Standby | 전체 축소 실행. 스케일 업만 필요. RTO 수 분 |
Multi-Site A/A | 양방향 복제. RTO/RPO ≈ 0. 가장 비쌈 |
DRS | 블록 레벨 복제. Pilot Light 방식. 온프레미스→AWS |
Aurora Global DB | RPO < 1초, RTO < 1분. 최대 5개 Secondary |
Compute SP | 가장 유연한 Savings Plans (EC2+Fargate+Lambda) |
Standard RI | 최대 할인, 교환 불가. 마켓플레이스 판매 가능 |
Convertible RI | 낮은 할인, 다른 Convertible RI로 교환 가능 |
Spot | 최대 90% 절감, 2분 전 통보 후 중단 가능 |
Compute Optimizer | EC2/Lambda/EBS 적정 규모 추천 |
Budgets Action | 예산 초과 시 EC2 자동 중지 등 자동 액션 |