saa 핵심 요약(1)
✅ Domain 1: 복원력 있는 아키텍처 설계를 위한 AWS 서비스 비교 및 설계 전략 요약
🔷 핵심 개념 먼저 정리
| 개념 | 설명 |
| 고가용성 (High Availability) | 시스템이 장애가 발생해도 지속적으로 운영될 수 있는 능력. 여러 AZ 사용, 자동 복구, 다중 인스턴스 구성 등. |
| 장애 복구 (Fault Tolerance) | 일부 구성 요소에 장애가 나더라도 시스템 전체가 중단 없이 동작하는 능력. |
| RTO (Recovery Time Objective) | 복구까지 걸리는 시간 |
| RPO (Recovery Point Objective) | 데이터 손실 허용 범위 (백업 시점 기준) |
📘 자주 등장하는 AWS 서비스 및 개념
① Multi-AZ Deployment (다중 가용 영역 배포)
- EC2, RDS, ELB 등 대부분의 리소스는 여러 Availability Zone(AZ)에 걸쳐 배포 가능
- 장애 발생 시 다른 AZ로 자동 전환해 서비스 연속성 보장
- 특히 RDS의 Multi-AZ 옵션은 **자동 장애 조치(Failover)**를 지원
② Elastic Load Balancer (ELB) + Auto Scaling
- 다수의 AZ에 EC2 인스턴스를 배포한 후,
- ELB로 트래픽을 분산하고,
- Auto Scaling으로 수요 변화나 장애에 따라 인스턴스를 자동 조정
📌 조합 예시:
EC2 + ALB + Auto Scaling + 2개 AZ = 고가용성 + 장애 복구 기본 패턴
③ Amazon Route 53 - 장애 조치 라우팅(Failover Routing)
- 하나의 리소스에 장애가 발생하면 대체 리소스로 DNS를 자동 전환
- 헬스 체크 기능 포함
📌 예시:
메인 서버가 장애 발생 시 Route 53이 헬스 체크를 감지하고, 자동으로 백업 서버로 트래픽 전환
④ Amazon S3
- S3는 자체적으로 99.999999999% (11 9's)의 내구성과 고가용성을 제공
- 자동 복제 및 지역 간 복제(CRR) 기능으로 **재해 복구(Disaster Recovery)**에 적합
⑤ Amazon RDS – Multi-AZ & Read Replica
- Multi-AZ: 자동 장애 조치 제공. 쓰기 인스턴스 장애 시 대기 인스턴스로 자동 전환
- Read Replica: 읽기 성능 확장 및 장애 시 수동 전환 가능
⑥ Amazon DynamoDB – 글로벌 테이블 (Global Tables)
- 여러 리전에 걸쳐 다중 마스터 DB 운영 가능
- 리전 하나가 장애 나도 다른 리전에서 계속 사용 가능
⑦ AWS Backup + Amazon S3/Glacier
- 중요한 데이터를 주기적으로 백업해 RPO 최소화
- Glacier는 장기 보관 및 비용 절감 목적
⑧ Elastic IP
- EC2 인스턴스가 중단되더라도 동일한 IP 주소를 유지하며 다른 인스턴스로 빠르게 전환 가능
🔹 1. Multi-AZ vs Multi-Region
| 항목 | Multi-AZ | Multi-Region |
| 목적 | 가용성(HA) 확보 | 재해 복구(DR) 중심 |
| 거리 | 동일 리전에 있는 AZ 간 구성 | 서로 다른 리전 간 구성 |
| 사용 예 | RDS, EC2 Auto Scaling | Route 53, S3 Cross-Region Replication |
| 권장 설계 | 일반적인 장애 대비에 적합 | 대규모 장애나 법적 요구 대비 |
활용 맥락
- RDS: Multi-AZ로 장애 시 자동 failover
- EC2: Auto Scaling Group을 AZ 두 개 이상에 구성
- S3: Cross-Region Replication으로 재해 대비 백업
🔹 2. Auto Scaling vs Load Balancer
| 항목 | Auto Scaling | Elastic Load Balancing (ELB) |
| 기능 | 인스턴스 수 조절 (수평 확장) | 트래픽을 여러 인스턴스로 분산 |
| 작동 방식 | 정책 기반으로 EC2 수 증감 | 요청을 가용 인스턴스로 라우팅 |
| 구성 요소 | Launch Template, ASG, Scaling Policy | ALB, NLB, CLB |
| 활용 | 수요 증가 시 자동 확장 | 고가용성/장애 복원력 확보 |
추천 설계
- ELB + Auto Scaling 조합 필수
- 예: ALB 앞단에 두고 뒤에서 EC2 ASG가 트래픽 대응
🔹 3. Route 53을 통한 복원력 설계
기능 요약
- DNS 서비스 + 트래픽 라우팅 기능
- 헬스 체크 + Failover 설정 가능
- 지리적 위치, 지연 시간 기반 분산 지원
활용 예시
- Failover Routing: 기본 리소스 장애 시 백업 리소스로 전환
- Latency Routing: 사용자와 가장 가까운 리전에 요청 전달
- Geo Routing: 지역 기반 정책 설정 (법률/속도 고려)
🔹 4. Disaster Recovery 전략과 관련 서비스
| 전략 | 복구 시간 | 비용 | 주요 서비스 |
| 백업 및 복원 | 길다 | 낮음 | S3, Glacier, Backup |
| Pilot Light | 중간 | 중간 | AMI, CloudFormation, minimal EC2 |
| Warm Standby | 짧음 | 높음 | RDS Multi-AZ, 소규모 인스턴스 상시 가동 |
| Active-Active | 거의 즉시 | 매우 높음 | Multi-Region + Route 53 + ELB |
추천 전략
- 업무 중요도, SLA 요구사항, 비용 여건에 따라 선택
- Mission-critical: Warm Standby 이상
- 일반 서비스: Pilot Light 혹은 백업/복원
🔹 5. 기타 복원력 서비스 요약
| 서비스 | 개념 | 활용 맥락 |
| Amazon S3 | 고내구성 객체 스토리지 | 백업 및 복구 데이터 저장 |
| Amazon CloudWatch | 모니터링 | ASG 및 복구 자동화 트리거 |
| AWS Config / CloudTrail | 구성 변경 및 감사 | 보안 및 복구 상태 점검 |
| Amazon SNS/SQS | 비동기 메시징 | 장애 격리, 유연한 복구 설계 가능 |
✅ 사례 1: 장애 대비 아키텍처 구성
문제
한 글로벌 기업이 웹 애플리케이션을 AWS 상에 배포하려 한다. 트래픽은 전 세계에서 발생하고, 장애 발생 시에도 서비스를 계속 제공할 수 있어야 한다. 어떤 설계가 가장 적절한가?
선택지 예시
A. 단일 리전에 EC2 Auto Scaling 구성
B. S3 정적 웹사이트 호스팅만 활용
C. 두 개 리전에 배포하고 Route 53으로 Failover 구성
D. 모든 트래픽을 하나의 리전에 집중
정답: ✅ C
해설
- 글로벌 트래픽 + 고가용성이 핵심 → Multi-Region 필요
- Route 53의 Failover Routing을 통해 장애 시 다른 리전으로 자동 전환 가능
- 고비용이지만 고복원력 제공
추천 설계
- 두 리전에 EC2 Auto Scaling + ALB 구성
- Route 53: 헬스체크 설정으로 자동 전환
- S3 Cross-Region Replication으로 정적 자산도 동기화
✅ 사례 2: 비용 고려 + 최소 복원력
문제
개발 중인 내부 시스템에 대한 장애 복원력을 최소한으로 보장하고 싶다. 비용도 중요하다. 어떤 전략이 적절한가?
선택지 예시
A. Active-Active 전략
B. Warm Standby 구성
C. Pilot Light 전략
D. 백업 및 복원 전략
정답: ✅ D
해설
- “비용 중요” → 가장 저렴한 DR 전략은 백업/복원
- S3/Glacier 등에 주기적으로 백업하고, 복구 시 수작업 복원
추천 설계
- AWS Backup으로 자동 백업
- Amazon S3 버전관리 및 Glacier 저장
- 복구 시 CloudFormation으로 인프라 재생성
✅ 사례 3: Auto Scaling 그룹 설계
문제
EC2 인스턴스로 구성된 웹 애플리케이션이 트래픽 급증에 자동으로 대응해야 한다. 어느 구성이 적절한가?
선택지 예시
A. 단일 EC2 인스턴스 + 수동 확장
B. ELB 없이 Auto Scaling만 구성
C. Auto Scaling Group + Launch Template + ALB
D. CloudFront 캐시만 구성
정답: ✅ C
해설
- 트래픽 증가 → Auto Scaling 필수
- 트래픽 분산 → ALB 필요
- Launch Template은 인스턴스 구성 자동화
추천 설계
- 두 개 이상의 AZ에 Auto Scaling Group 구성
- Launch Template 활용해 AMI 및 스펙 관리
- ALB를 앞단에 배치해 트래픽 분산
✅ 사례 4: 복구 자동화 설계
문제
백엔드 DB 장애 발생 시, 자동으로 대체 인스턴스로 전환하고 서비스 중단을 최소화하고자 한다. 가장 적절한 AWS 기능은?
선택지 예시
A. RDS Read Replica
B. RDS Multi-AZ 배포
C. DynamoDB 글로벌 테이블
D. CloudFront 캐시
정답: ✅ B
해설
- RDS Multi-AZ는 동일 리전 내에 대기 인스턴스 구성
- 장애 시 자동으로 Failover
추천 설계
- RDS 생성 시 Multi-AZ 옵션 활성화
- CloudWatch로 장애 알림
- Route 53과 연계 시 DB 연결 재지정 가능