[SAA Ch-02] 영역 2 복원력 있는 아키텍처 설계: 구성 요소 사이에 큐를 두고 한 곳의 장애를 견디는 설계

결론부터

1. 영역 2는 과제 두 개입니다. 2.1은 부하가 늘어도 버티도록 구성 요소를 나누고 늘리는 설계(큐, 이벤트, 서버리스, 컨테이너, Auto Scaling, 캐시), 2.2는 한 AZ나 한 리전이 멈춰도 서비스가 이어지는 설계(Multi-AZ, Route 53, DR 전략, DB 장애 조치, 복제)입니다.
2. “느슨한 결합”이 나오면 먼저 SQS를 떠올립니다. 순서와 중복 제거가 필요하면 FIFO 큐, 한 이벤트를 여러 곳에 동시에 보내야 하면 SNS 팬아웃, 규칙으로 여러 대상에 라우팅하면 EventBridge, 여러 단계를 순서와 재시도로 묶으면 Step Functions입니다.
3. 재해 복구는 백업과 복원, 파일럿 라이트, 웜 스탠바이, 다중 사이트 액티브/액티브 네 가지이고 오른쪽으로 갈수록 RPO와 RTO가 짧아지고 비용과 복잡도가 커집니다. 파일럿 라이트와 웜 스탠바이의 차이는 DR 리전이 지금 바로 요청을 처리할 수 있는지입니다. DR 백서는 이 둘을 가르는 기준을 그렇게 적습니다.
4. DB 장애 조치 시간은 서비스마다 다릅니다. RDS Multi-AZ DB 인스턴스는 보통 60~120초이고 대기 인스턴스는 읽기를 처리하지 않습니다. Aurora는 복제본이 있으면 보통 60초 안, 자주 30초 안에 복구됩니다. Aurora Global Database는 리전 간 복제 지연이 보통 1초 미만이고 2026년 10월 사용자 가이드 기준 보조 리전을 최대 10개 둡니다(2021년판 DR 백서는 5개).
5. DR 백서는 장애 조치에 데이터 플레인 작업만 쓰라고 권합니다. Route 53 상태 확인 기반 장애 조치와 ARC 라우팅 제어는 데이터 플레인이고 가중치 변경이나 Auto Scaling 확장은 컨트롤 플레인입니다. 그래서 DR 리전의 서비스 할당량을 미리 올려 두라는 문장이 안내서의 “대기 환경의 서비스 할당량” 항목과 이어집니다.

---

1. 공식 안내서의 목차

2. 과제 2.1 확장 가능하고 느슨하게 결합된 아키텍처

2-1. 수평 확장, 수직 확장, 상태 비저장

수평 확장의 전제는 상태 비저장입니다. 쇼핑몰의 장바구니를 웹 서버 메모리에 두면 다음 요청이 다른 인스턴스로 갔을 때 장바구니가 사라집니다. 세션과 장바구니를 ElastiCache나 DynamoDB 같은 외부 저장소로 옮기면 인스턴스를 자유롭게 늘리고 줄일 수 있습니다. 안내서가 마이크로서비스 설계 원칙의 예로 “상태 저장과 상태 비저장 워크로드 비교”를 든 이유가 여기 있다고 읽었습니다.

2-2. 다계층 아키텍처와 로드 밸런싱

웹 계층(ALB), 애플리케이션 계층(Auto Scaling 그룹이나 컨테이너), 데이터 계층(RDS, DynamoDB)을 나누고 각 계층을 AZ 두 개 이상에 걸칩니다. 계층마다 따로 늘릴 수 있고 한 계층의 장애가 다른 계층으로 번지는 범위가 줄어듭니다. 로드 밸런서 종류(ALB, NLB, GWLB)의 차이는 Ch-00의 4-2절 표에 정리해 두었습니다.

로드 밸런서 설정 중 시험에 자주 걸리는 세 가지를 ELB 사용자 가이드와 ALB 대상 그룹 속성 문서(2026년 10월 20일 확인)로 정리했습니다.

예제로 보면 AZ A에 대상 2개, AZ B에 8개가 있고 교차 영역이 꺼져 있으면 A의 대상은 각각 25%, B의 대상은 각각 6.25%를 받는다고 문서가 설명합니다. 켜면 10개가 10%씩 받습니다. 고정 세션은 상태를 서버에 두는 앱을 수정 없이 살리는 방법이지만 부하가 고르게 퍼지지 않으니 2-1절처럼 세션을 외부 저장소로 옮기는 것이 근본 해결입니다.

2-3. 큐: SQS

SQS 큐 유형 문서의 비교를 옮겼습니다.

높은 처리량 모드의 한도는 리전마다 다릅니다. 메시지 할당량 문서(2026년 10월 20일 확인)의 배치 없는 호출 기준은 다음과 같고 배치(10개)를 쓰면 메시지 수로 열 배입니다.

서울 리전은 이름이 따로 나오지 않아 “그 밖의 리전”인 초당 2,400건(배치로 24,000메시지)에 해당합니다. 더 필요하면 Service Quotas로 증가를 요청합니다.

메시지 최대 크기는 예전 자료에 256KB로 적힌 곳이 많습니다. 2026년 10월 문서는 1MiB이니 문항이 옛 숫자를 전제로 할 수도 있다는 점만 기억해 두었습니다.

표시 제한 시간은 소비자가 메시지를 받은 뒤 다른 소비자에게 보이지 않는 시간입니다. 처리 시간보다 짧으면 같은 메시지가 두 번 처리됩니다. “주문이 가끔 두 번 처리된다”는 시나리오에서는 표시 제한 시간을 처리 시간보다 길게 늘리거나 처리를 멱등하게 만드는 보기가 답입니다. 일정 횟수 실패한 메시지는 배달 못한 편지 큐(DLQ)로 옮겨 따로 살펴봅니다. 롱 폴링(WaitTimeSeconds)은 빈 응답을 줄여 API 호출을 아낍니다.

2-4. 발행/구독: SNS와 팬아웃

SNS는 발행자가 토픽에 보낸 메시지를 모든 구독자에게 밀어 넣습니다. SQS 큐를 구독자로 붙이는 팬아웃은 Ch-00에서 정리했습니다. 한 이벤트를 여러 소비자가 각자 속도로 처리해야 할 때 씁니다.

기본으로 구독자는 토픽의 모든 메시지를 받습니다. 구독에 필터 정책을 붙이면 메시지 속성이나 본문(JSON)의 조건에 맞는 메시지만 받습니다. 결제 서비스가 결제완료 이벤트를 한 토픽에 발행하고 정산 큐는 모든 메시지를, 고액 결제 검토 큐는 금액 속성이 기준 이상인 메시지만 받게 하는 식입니다.

2-5. 이벤트 기반: EventBridge

EventBridge 문서는 이벤트를 처리하는 방식을 이벤트 버스와 파이프 두 가지로 나누고 여기에 스케줄러를 따로 둡니다.

2026년 10월 문서에는 이벤트를 정한 기간 보존하고 순서 전달과 재생을 지원하는 새 Custom Event Bus와 기존 규칙 기반 버스(Custom Event Bus - Classic)가 함께 나옵니다. 문서는 새 애플리케이션이면 새 Custom Event Bus로 시작하라고 권하고 Classic도 계속 쓸 수 있다고 적습니다. 시험 문항은 규칙과 대상 중심의 기존 모델을 전제로 할 가능성이 높다고 보고 있습니다.

SNS와 EventBridge가 함께 보기에 나오면 이벤트 내용으로 세밀하게 걸러 여러 AWS 서비스나 SaaS로 보내는 쪽이 EventBridge, 대량 구독자에게 단순히 밀어 넣는 쪽이 SNS로 구분했습니다. 이 구분은 두 서비스 문서를 나란히 놓고 정리한 것이고 AWS가 이렇게 비교한 문서를 이번에 찾지는 못했습니다.

2-6. 워크플로 오케스트레이션: Step Functions

워크플로 유형은 만든 뒤 바꿀 수 없습니다. 쇼핑몰의 주문 흐름(재고 확인, 결제, 배송 요청, 실패 시 보상 처리)은 결제가 들어 있어 정확히 한 번이 필요하므로 표준 워크플로입니다. 여러 Lambda를 직접 서로 호출하게 엮는 보기보다 Step Functions로 단계와 재시도를 정의하는 보기가 운영 부담이 적은 답이 됩니다.

2-7. API 생성과 관리: API Gateway

API Gateway 문서는 HTTP API를 기능을 줄이고 가격을 낮춘 제품으로 설명하고 API 키, 클라이언트별 제한, 요청 검증, WAF, 프라이빗 엔드포인트가 필요하면 REST API를 고르라고 적습니다.

Lambda 문서에는 API Gateway의 기본 스로틀(초당 10,000)과 Lambda의 기본 동시성(1,000)이 맞지 않아 API Gateway가 받은 요청을 Lambda가 다 처리하지 못할 수 있다는 예시가 있습니다. 안내서 2.2의 “서비스 할당량과 스로틀링” 항목과 이어지는 내용입니다.

2-8. 서버리스: Lambda와 Fargate

2026년 10월 할당량 문서에는 Lambda Managed Instances라는 실행 방식이 있고 이 방식의 비동기 호출과 일부 이벤트 소스 매핑은 최대 90분까지 돈다고 적혀 있습니다. 시험 안내서보다 나중에 생긴 것이라 문항은 “Lambda 최대 15분”을 전제로 한다고 보는 편이 안전합니다.

15분을 넘는 작업, 계속 떠 있어야 하는 프로세스, 큰 로컬 상태가 필요한 작업은 Lambda 대신 Fargate나 EC2가 맞습니다. Fargate는 ECS 문서에서 서버 관리, 용량 계획, 워크로드 격리를 직접 하지 않는 서버리스 사용량 기반 컴퓨팅 엔진으로 설명됩니다.

2-9. 컨테이너: ECS, EKS, Fargate

“컨테이너로 옮기는 방법”이라는 안내서 항목은 기존 애플리케이션을 컨테이너 이미지로 만들어 ECR에 올리고 ECS 서비스로 띄우는 흐름으로 이해했습니다. ECS 문서는 서비스를 “오래 실행되는 상태 비저장 애플리케이션”, 태스크를 “작업을 하고 끝나는 애플리케이션”으로 구분합니다. EKS 문서는 쿠버네티스 컨트롤 플레인을 AWS가 관리한다고 적고 노드 관리까지 맡기는 EKS Auto Mode, 온프레미스에서 쓰는 EKS Anywhere와 Hybrid Nodes를 함께 소개합니다.

2-10. Auto Scaling

문서는 대상 추적을 강하게 권하고 용량에 반비례하는 지표(평균 CPU 사용률, 대상당 요청 수)를 고르라고 합니다. 용량을 두 배로 늘리면 지표가 절반으로 줄어드는 지표여야 비례 조정이 맞게 일어난다는 이유입니다. 정책이 여러 개 동시에 발동하면 가장 큰 용량을 주는 정책을 따릅니다.

SQS 소비자를 늘릴 때는 큐 길이 대신 인스턴스당 처리할 메시지 수(backlog per instance)를 지표로 쓰는 문서가 따로 있습니다(이번에는 목차에서 제목만 확인). 예약 조정은 정한 시각에 원하는 용량과 최소·최대를 바꾸는 예약 작업이고 한 번만 실행하거나 cron으로 반복할 수 있으며 동적 조정 정책과 함께 쓸 수 있습니다. 예측 조정은 과거 부하에서 일 단위·주 단위 패턴을 찾아 예상 부하보다 먼저 용량을 늘리고 문서는 업무 시간 주기 트래픽, 반복 배치, 초기화가 오래 걸리는 앱에 맞다고 적습니다.

조정 정책 말고도 인스턴스가 들어오고 나가는 순간을 다루는 기능 두 가지가 문제에 나옵니다. EC2 Auto Scaling 사용자 가이드(2026년 10월 20일 확인) 기준입니다.

“새 인스턴스가 설정 스크립트를 끝내기 전에 ALB가 트래픽을 보내 오류” 또는 “축소 전에 로그를 S3로 옮겨야 함”은 수명 주기 후크입니다. “부팅에 10분 넘게 걸려 급증에 늦게 대응, 상시 과다 프로비저닝은 싫음”은 웜 풀입니다.

2-11. 캐싱 전략

ElastiCache 문서의 캐시 채우기 전략입니다.

게시판의 인기글 목록처럼 몇 초 낡아도 되는 데이터는 지연 로딩 + TTL, 상품 가격처럼 쓰자마자 맞아야 하는 데이터는 쓰기 통과가 맞습니다. CloudFront는 S3, ELB, API Gateway 같은 AWS 원본에서 CloudFront로 오는 전송 요금이 없다고 문서가 적습니다.

2-12. 읽기 복제본을 쓸 때

RDS 읽기 복제본은 원본 DB의 엔진 기능으로 비동기 복제되는 읽기 전용 인스턴스입니다. 문서가 드는 용도는 읽기 부하 분산, 원본이 백업이나 유지 보수로 I/O를 멈출 때의 읽기, 보고서 쿼리 분리, 다른 리전 DR(승격)입니다.

Aurora는 클러스터당 읽기 전용 Aurora 복제본을 최대 15개 두고 장애 조치 대상으로도 씁니다. Multi-AZ와 읽기 복제본의 차이는 3-7절에서 다룹니다.

2-13. 스토리지 유형: 객체, 파일, 블록

EFS 문서는 리전 파일 시스템이 여러 AZ에 데이터를 중복 저장해 하나 이상의 AZ가 멈춰도 접근할 수 있고 One Zone은 AZ 손상 시 데이터를 잃을 수 있다고 적습니다. 여러 AZ의 웹 서버가 같은 업로드 디렉터리를 공유해야 하면 EFS 리전 파일 시스템, 한 인스턴스의 DB 볼륨이면 EBS입니다.

안내서가 관리형 서비스 예시로 든 Transfer Family는 SFTP, FTPS, FTP, AS2, 브라우저 기반 전송으로 S3나 EFS에 파일을 넣고 빼는 서비스입니다. “거래처가 SFTP로 파일을 보내는 방식을 바꾸지 않고 S3로 받기”가 전형적인 시나리오입니다.

2-14. 과제 2.1에서 갈리는 조건

3. 과제 2.2 고가용성과 내결함성

3-1. 글로벌 인프라와 Multi-AZ로 충분한 경우

DR 백서의 업무 연속성 계획 절은 AWS 리전 안의 AZ가 서로 의미 있는 거리를 두고 위치가 계획되어 흔한 재해는 한 AZ에만 영향을 준다고 설명하고 그래서 리전 안 Multi-AZ 아키텍처가 위험 완화 요구의 상당 부분을 이미 충족할 수 있다고 적습니다. 같은 백서는 물리 데이터센터 하나의 손실이 재해의 정의라면 백업과 복원만으로도 될 수 있고 리전 전체 손실이나 규제 요구까지 고려하면 파일럿 라이트 이상을 검토하라고 합니다.

시험 문제에서 “AZ 하나의 장애에도 서비스 유지”는 Multi-AZ, “리전 장애에도 유지”는 다중 리전 문제로 읽습니다. 리전 문제에 Multi-AZ만 답한 보기, AZ 문제에 다중 리전 액티브/액티브를 답한 보기는 각각 요구 미달과 과잉 비용으로 걸러집니다.

3-2. 단일 장애 지점 제거

3-3. Route 53 라우팅 정책

IP 기반을 뺀 나머지는 프라이빗 호스팅 영역에서도 쓸 수 있다고 문서가 적습니다. 다중 값 응답은 로드 밸런서를 대신하지는 못하지만 상태 확인과 함께 쓰면 비정상 IP를 응답에서 뺍니다.

3-4. Route 53 상태 확인

Route 53은 사설·로컬·라우팅 불가 IP 범위의 엔드포인트는 직접 확인할 수 없습니다. VPC 안의 사설 리소스 상태로 장애 조치하려면 그 리소스의 지표에 CloudWatch 경보를 만들고 경보 기반 상태 확인을 씁니다. 실패 임계값은 Route 53 API 참조의 HealthCheckConfig 기준 1~10 범위이고 지정하지 않으면 3입니다. 요청 간격도 지정하지 않으면 30초입니다.

3-5. Global Accelerator와 CloudFront 원본 장애 조치

DR 백서는 Global Accelerator가 DNS 캐시 문제를 피하고 AWS 엣지 네트워크로 트래픽을 일찍 태워 지연을 줄인다고 설명합니다. “고정 IP가 필요한 거래처 방화벽”, “TCP/UDP 게임 서버”, “DNS TTL 때문에 장애 조치가 늦음”이 나오면 Global Accelerator, “정적 콘텐츠 캐시”면 CloudFront입니다.

3-6. 재해 복구 전략과 RPO, RTO

DR 백서의 정의입니다.

• RTO(복구 시간 목표): 서비스 중단과 복원 사이에 허용할 수 있는 최대 지연. 서비스가 쓸 수 없는 상태로 허용되는 시간입니다.
• RPO(복구 시점 목표): 마지막 데이터 복구 지점 이후 허용할 수 있는 최대 시간. 마지막 복구 지점과 중단 사이에 잃어도 되는 데이터의 양입니다.

백서가 적은 파일럿 라이트와 웜 스탠바이의 구분은 이렇습니다. 둘 다 DR 리전에 주 리전 자산의 복사본이 있지만 파일럿 라이트는 추가 조치 없이는 요청을 처리할 수 없고 웜 스탠바이는 줄어든 용량으로 즉시 트래픽을 처리합니다. 파일럿 라이트는 서버를 켜고 비핵심 인프라를 배포하고 확장해야 하고 웜 스탠바이는 확장만 하면 됩니다.

백서는 같은 용량을 DR 리전에 미리 둔 정적 안정 구성을 핫 스탠바이라고 부르고 액티브/액티브와 함께 묶어 설명합니다. 핫 스탠바이는 트래픽을 한 리전에서만 받는 액티브/패시브입니다.

전략과 함께 기억할 백서의 원칙이 두 가지 있습니다.

자동 장애 조치에 대해서도 백서는 조심하라고 적습니다. 거짓 경보로 장애 조치하면 RTO와 RPO만큼의 손실을 그대로 입기 때문에 수동으로 시작하되 단계는 자동화해 버튼 하나로 만드는 방식을 많이 쓴다고 합니다.

3-7. DB 장애 조치: RDS Multi-AZ, Aurora, RDS Proxy

Multi-AZ 장애 조치가 일어나는 조건으로 문서는 OS 패치, 기본 호스트 비정상, 네트워크 단절, 고객의 인스턴스 수정, 응답 없는 기본 인스턴스, 저장 볼륨 장애, 사용자가 요청한 장애 조치(장애 조치를 포함한 재부팅)를 듭니다. 애플리케이션이 JVM이면 DNS 캐시 TTL을 60초 이하로 두라고 권합니다.

Aurora 복제본에는 0(최우선)부터 15까지 승격 우선순위를 줄 수 있습니다. 같은 우선순위면 크기가 큰 복제본을 먼저 승격합니다. 연결 문자열은 클러스터 엔드포인트를 쓰면 장애 조치 뒤에도 그대로입니다.

RDS Proxy는 DB 연결 풀을 만들어 재사용하고 장애 조치 때 애플리케이션 연결을 유지한 채 새 인스턴스로 라우팅합니다. Aurora 문서는 DNS 캐시를 우회해 Aurora Multi-AZ의 장애 조치 시간을 최대 66% 줄인다고 적습니다. 클라이언트에 IAM 인증을 강제하고 DB 자격 증명은 Secrets Manager나 IAM DB 인증으로 처리합니다. 프록시는 DB와 같은 VPC에 있어야 하고 공개 접근이 불가능합니다. RDS DB 인스턴스의 복제 구성에서는 프록시를 쓰기 인스턴스에만 연결할 수 있습니다. Aurora에서는 기본 프록시 엔드포인트가 쓰기 인스턴스로 가고 읽기 전용 프록시 엔드포인트를 만들면 클러스터의 리더 엔드포인트로 읽기를 나눌 수 있습니다.

“Lambda가 동시에 수백 개 떠서 RDS 연결이 바닥난다”는 RDS Proxy의 대표 시나리오입니다. “앱 코드를 고칠 수 없는데 장애 조치 시간을 줄이고 싶다”도 RDS Proxy가 답이 되는 경우가 많습니다. 안내서 2.2의 프록시 개념 항목이 이것입니다.

3-8. Aurora Global Database

DR 백서는 보조 리전을 “최대 5개”로 적고 있어 서비스 문서와 다릅니다. 2026년 10월 20일에 Aurora 사용자 가이드의 “Using Amazon Aurora Global Database” 페이지를 다시 열어 “up to 10 secondary DB clusters in different Regions”라는 문장을 확인했고 엔진(MySQL, PostgreSQL)을 가리지 않는 서술입니다. 백서는 2021년판이라 이전 한도로 보고 사용자 가이드의 10개를 따랐습니다. 시험 문항이 숫자 자체를 묻는다면 출제 시점에 따라 5가 정답일 수도 있어서 “리전 여러 개에 읽기 전용 사본, 1초 미만 복제”라는 성격으로 기억해 둡니다. 백서는 보조 리전을 1분 안에 읽기·쓰기로 승격할 수 있다고 적습니다.

3-9. DynamoDB 글로벌 테이블

글로벌 테이블은 여러 리전에 복제본을 두고 어느 복제본에서든 읽고 쓰는 다중 액티브 기능입니다. 한 리전에 복제본은 하나이고 모든 복제본이 같은 테이블 이름과 기본 키 스키마를 씁니다.

일관성 모드는 만든 뒤 바꿀 수 없습니다. 글로벌 테이블의 가용성 SLA는 99.999%이고 단일 리전 테이블은 99.99%입니다. MRSC는 쓰기와 강력 일관 읽기에 리전 간 통신이 필요해 MREC보다 지연이 큽니다. 빈 테이블에서만 만들 수 있고 만든 뒤에는 복제본을 더할 수 없습니다(DynamoDB 글로벌 테이블 동작 문서, 2026년 10월 21일 확인).

DR 백서는 쓰기 전략을 셋으로 나눕니다. 모든 쓰기를 한 리전으로 보내는 write global(Aurora Global Database가 맞음), 가까운 리전에 쓰는 write local(DynamoDB 글로벌 테이블이 맞음), 사용자 ID 같은 키로 쓰기 리전을 정하는 write partitioned(양방향 S3 복제 등)입니다.

3-10. S3 복제

S3 복제 문서 안에 99.99%와 99.9%가 함께 나오는 이유는 S3 FAQ가 설명합니다. 99.99%는 설계 목표이고 SLA가 약속하는 값은 리전 쌍마다 99.9%입니다. 두 숫자가 가리키는 대상이 다릅니다.

3-11. 백업으로 데이터 내구성 지키기

DR 백서가 시점 복구를 지원한다고 든 서비스는 EBS 스냅샷, DynamoDB 백업, RDS 스냅샷, Aurora 스냅샷, EFS 백업(AWS Backup 사용 시), Redshift 스냅샷, Neptune, DocumentDB, FSx입니다. AWS Backup은 이들을 중앙에서 계획하고 리전 간·계정 간 복사를 합니다. 계정 간 백업은 내부자 위협이나 계정 탈취까지 대비합니다.

AWS Backup 개발자 가이드의 리전 간 복사 페이지(2026년 10월 20일 확인)에서 문제에 쓸 만한 동작을 모았습니다.

“규정상 백업을 운영 리전과 떨어진 곳에 자동으로 보관”은 백업 계획의 복사 규칙이 답이고 Lambda로 스냅샷을 복사하는 보기는 운영 부담이 큰 쪽입니다.

백서는 백업 복원이 컨트롤 플레인 작업이라서 재해 때 쓸 수 없을 수도 있으니 주기적으로 DR 리전에 미리 복원해 두는 방법을 권합니다. 2021년판 백서는 AWS Backup에 예약 복원이 없어 SDK로 직접 자동화한다고 적었습니다. 지금 AWS Backup에는 정한 주기마다 복원을 실행해 복원 가능 여부와 걸린 시간을 보는 복원 테스트(restore testing) 기능이 있습니다. 다만 테스트로 만든 리소스는 끝나면 지워지므로 DR 리전에 복원본을 계속 두려면 여전히 직접 자동화합니다. 백업은 복원 테스트까지 해야 백업이라는 것이 백서의 주의 사항입니다.

3-12. 앱 수정 없이 레거시 애플리케이션의 신뢰성 높이기

안내서는 “애플리케이션을 바꿀 수 없을 때 레거시 앱의 신뢰성을 높이는 AWS 서비스”를 기술 항목에 넣었습니다. 이번에 확인한 문서에서 이 조건에 맞는 것을 모았습니다.

Elastic Disaster Recovery 사용자 가이드는 RPO와 RTO 숫자를 명시하지 않고 “몇 분 안에 복구 인스턴스를 띄운다”고만 적습니다. 같은 서비스의 FAQ는 “RPOs of seconds”, “RTOs of minutes”라고 적어 흔히 보이는 “RPO 초 단위, RTO 분 단위”의 출처가 FAQ임을 확인했습니다(2026년 10월 20일). 복제 원본으로는 물리 서버, VMware vSphere, Microsoft Hyper-V, 다른 클라우드를 듭니다.

다만 2026년 10월 20일에 연 SAA-C03 범위 안 서비스 목록에는 Elastic Disaster Recovery가 없고 Migration and Transfer 범주에 AWS Application Migration Service가 있습니다. 이관(한 번 옮기기)이 목적이면 Application Migration Service, 계속 복제하다가 장애 때 띄우는 DR이 목적이면 Elastic Disaster Recovery라고 구분해 두었습니다. Application Migration Service는 2026년 10월 제품 페이지와 사용자 가이드에서 AWS Transform MGN으로 이름이 바뀌어 있고 시험 범위 목록에는 옛 이름으로 남아 있습니다. 문서는 물리·가상·클라우드 서버를 블록 수준으로 계속 복제해 AWS에서 띄우는 리호스팅 서비스로 설명합니다.

3-13. 불변 인프라와 자동화

DR 백서는 백업과 복원 전략에서도 인프라를 IaC(CloudFormation, CDK)로 배포하라고 강조합니다. IaC가 없으면 복구 리전에서 인프라를 다시 세우기 복잡해져 RTO를 넘길 수 있다는 이유입니다. 그 밖에 백서가 드는 도구는 Image Builder로 만든 골든 AMI를 두 리전에 복사하는 것, CloudFormation 의사 파라미터와 조건으로 DR 리전에는 축소 구성만 배포하는 것, StackSets로 여러 계정과 리전에 같은 스택을 배포하는 것입니다.

불변 인프라는 실행 중인 서버를 고치지 않고 새 이미지로 교체하는 방식입니다. 쇼핑몰의 배포를 새 AMI로 만든 Auto Scaling 그룹을 띄우고 ALB 대상을 옮기는 방식으로 하면 “서버마다 설정이 조금씩 다르다”는 문제가 생기지 않습니다. 이 정의는 안내서 항목 이름에서 출발한 일반적인 설명이고 이번에 AWS의 정의 문서를 따로 찾지는 않았습니다.

3-14. 서비스 할당량과 스로틀링

DR 백서는 웜 스탠바이에서 DR 리전을 프로덕션 용량으로 늘릴 때 그 리전의 서비스 할당량이 충분히 높게 설정되어 있는지 확인하라고 적습니다. 평소 DR 리전은 작게 돌기 때문에 할당량을 올려 두지 않으면 정작 장애 때 확장이 할당량에 막힙니다.

스로틀링은 서비스 사이의 한도 차이에서도 생깁니다. 2-7절의 API Gateway 초당 10,000요청과 Lambda 기본 동시성 1,000이 그 예이고 Lambda 문서는 예상 트래픽에 맞춰 동시성 한도를 미리 올리고 부하 테스트로 한도를 찾으라고 권합니다.

3-15. 가시성: X-Ray

X-Ray는 애플리케이션이 처리한 요청과 그 요청이 부른 AWS 리소스, 마이크로서비스, DB, 외부 API 호출을 추적합니다. 추적 데이터로 트레이스 맵을 만들어 병목, 지연 급증 같은 문제를 찾게 합니다. SDK는 세그먼트를 UDP로 X-Ray 데몬에 보내고 데몬이 모아서 올립니다. Lambda는 추적 데이터를 보내고 데몬을 대신 실행합니다. X-Ray 문서는 2026년 2월 25일부터 X-Ray SDK와 데몬이 유지 관리 모드에 들어가 보안 수정만 받는다고 공지하고 새 계측에는 OpenTelemetry로 옮기라고 권합니다. 트레이스를 모아 보는 X-Ray 서비스 자체는 그대로입니다.

“마이크로서비스 여러 개 중 어디서 느려지는지 모름”은 X-Ray, “지표 임계값 알림”은 CloudWatch 경보로 구분합니다. 안내서의 “비즈니스 요구에 맞는 지표 식별” 항목은 가용성을 무엇으로 잴지(오류율, 지연, 큐 적체)를 정하는 문제로 읽었습니다.

3-16. AWS 관리형 서비스 항목에 대해

안내서 2.2의 지식 항목에는 “AWS Managed Services (AMS) with appropriate use cases (for example, Amazon Comprehend, Amazon Polly)“가 있습니다. AMS라는 이름의 별도 운영 대행 서비스가 있지만 예시는 관리형 AI 서비스입니다. 저는 이 항목을 “직접 모델과 서버를 운영하지 않고 목적별 관리형 서비스로 해결하는 선택”으로 읽었습니다. Comprehend는 문서에서 엔터티, 핵심 구문, 언어, 감정을 뽑는 자연어 처리 서비스이고 토픽 모델링, 이벤트 감지, 프롬프트 안전 분류 기능은 신규 고객에게 더 이상 제공되지 않습니다. Polly는 텍스트를 음성으로 바꾸는 서비스이고 생성형, 장문형, 뉴럴, 표준 음성을 고를 수 있습니다.

3-17. 과제 2.2에서 갈리는 조건

4. 확인 문제

직접 만든 시나리오입니다. 실제 시험 문항이나 문제집에서 가져온 것은 없습니다.

문제 1. 쇼핑몰의 주문 API가 결제 서비스를 동기로 호출합니다. 할인 행사 때 결제 서비스가 느려지면 주문 API까지 타임아웃이 납니다. 주문은 접수만 빠르게 하고 결제는 몇 분 늦어도 됩니다. 같은 주문이 두 번 결제되면 안 됩니다. 가장 알맞은 설계는 무엇입니까?

A. 결제 서비스 인스턴스를 더 큰 유형으로 바꾼다
B. 주문 API가 SQS FIFO 큐에 결제 요청을 넣고 결제 서비스가 큐를 소비한다. 중복 제거 ID로 주문 번호를 쓴다
C. 주문 API가 SNS 토픽에 발행하고 결제 서비스가 HTTP로 구독한다
D. 결제 서비스 앞에 ALB를 두고 Auto Scaling을 붙인다

정답과 이유

B입니다. 큐가 두 서비스 사이를 끊어 결제가 느려도 주문 접수는 계속되고 FIFO 큐의 중복 제거로 같은 주문 번호가 두 번 들어오는 것을 막습니다. A는 수직 확장이라 결합은 그대로입니다. C는 SNS가 밀어 넣는 방식이라 결제 서비스가 느릴 때 재시도와 적체 관리가 큐보다 약합니다. D는 결제 서비스 확장에는 도움이 되지만 동기 결합과 중복 문제는 남습니다. 표준 큐를 고르면 최소 한 번 전달이라 결제 쪽을 반드시 멱등하게 만들어야 합니다.

문제 2. 게시판에 글이 올라오면 검색 색인 갱신, 알림 발송, 통계 집계 세 작업이 각각 일어나야 합니다. 세 작업은 처리 속도가 다르고 하나가 멈춰도 나머지는 계속되어야 합니다. 어떤 구성이 맞습니까?

A. 글 저장 Lambda가 세 작업을 순서대로 호출한다
B. SNS 토픽에 발행하고 작업마다 SQS 큐를 구독시켜 각자 소비한다
C. SQS 표준 큐 하나에 넣고 세 작업이 같은 큐를 소비한다
D. Step Functions 익스프레스 워크플로로 세 작업을 직렬로 묶는다

정답과 이유

B입니다. SNS와 SQS 팬아웃은 한 메시지를 큐마다 복사하므로 작업이 각자 속도로 처리하고 하나가 멈춰도 그 큐에만 쌓입니다. C는 한 메시지를 한 소비자만 가져가므로 세 작업이 메시지를 나눠 갖게 됩니다. A와 D는 직렬이라 한 작업의 실패가 나머지에 영향을 줍니다. 이벤트 내용에 따라 대상을 다르게 고르는 조건이 붙으면 EventBridge 규칙도 후보입니다.

문제 3. 결제 서비스의 RDS for MySQL이 Multi-AZ DB 인스턴스로 구성되어 있습니다. 월말 정산 보고서 쿼리 때문에 기본 인스턴스 CPU가 높아집니다. 개발자는 대기 인스턴스로 보고서 쿼리를 보내자고 제안합니다. 맞는 판단은 무엇입니까?

A. 대기 인스턴스 엔드포인트로 보고서 쿼리를 보낸다
B. 대기 인스턴스는 읽기를 처리하지 않으니 읽기 복제본을 만들어 보고서 쿼리를 보낸다
C. Multi-AZ를 끄고 그 비용으로 인스턴스를 키운다
D. 보고서 쿼리를 ElastiCache에 넣는다

정답과 이유

B입니다. RDS 문서는 Multi-AZ DB 인스턴스의 대기 복제본이 읽기 트래픽을 처리할 수 없고 읽기에는 읽기 복제본이나 Multi-AZ DB 클러스터를 쓰라고 적습니다. 보고서 분리는 문서가 든 읽기 복제본 용도 중 하나입니다. A는 불가능합니다. C는 가용성을 잃습니다. D는 매번 다른 집계 쿼리라 캐시 효과가 적습니다. 읽기 복제본은 비동기라 보고서가 몇 초 늦은 데이터를 볼 수 있다는 점을 받아들일 수 있어야 합니다.

문제 4. 쇼핑몰은 서울 리전에서 운영합니다. 경영진은 리전 장애 시 RTO 4시간, RPO 1시간을 요구하고 DR 비용은 가장 적게 쓰기를 원합니다. 어떤 전략이 맞습니까?

A. 다중 사이트 액티브/액티브
B. 웜 스탠바이
C. 백업과 복원. 1시간보다 짧은 주기의 백업을 DR 리전으로 복사하고 인프라는 IaC로 둔다
D. Multi-AZ 구성만 유지한다

정답과 이유

C입니다. RTO 4시간과 RPO 1시간은 비교적 여유 있는 목표이고 백업과 복원이 네 전략 중 비용이 가장 낮습니다. RPO를 맞추려면 백업 주기가 1시간보다 짧아야 하고 RTO를 맞추려면 DR 백서가 강조하는 대로 IaC로 인프라를 빠르게 다시 세울 수 있어야 합니다. A와 B는 요구를 넘는 비용입니다. D는 리전 장애에 대비하지 못합니다. 실제로 4시간 안에 복원되는지는 복원 테스트로 확인해야 합니다.

문제 5. 결제 서비스의 DR 리전에는 데이터가 Aurora Global Database 보조 클러스터로 복제되고 있고 애플리케이션 서버는 AMI와 템플릿만 준비되어 있으며 실행 중인 인스턴스는 없습니다. 이 구성은 어떤 전략이고 장애 시 무엇을 해야 합니까?

A. 웜 스탠바이. 트래픽만 돌리면 된다
B. 파일럿 라이트. 보조 클러스터를 승격하고 앱 서버를 시작해 확장한 뒤 트래픽을 돌린다
C. 백업과 복원. 스냅샷에서 DB를 복원한다
D. 액티브/액티브. 할 일이 없다

정답과 이유

B입니다. 데이터는 계속 복제되어 켜져 있고 앱 서버는 꺼져 있으니 백서의 파일럿 라이트 정의와 같습니다. 백서는 파일럿 라이트가 추가 조치 없이는 요청을 처리할 수 없다고 적습니다. A는 앱 서버가 작게라도 돌고 있어야 합니다. C는 데이터가 연속 복제되고 있어 맞지 않습니다. DR 리전에서 앱 서버를 프로덕션 규모로 늘릴 수 있도록 서비스 할당량을 미리 올려 두는 것도 준비에 들어갑니다.

문제 6. 게시판 서비스가 두 리전에서 ALB로 운영됩니다. 주 리전이 비정상이면 DNS가 자동으로 보조 리전을 가리켜야 합니다. 주 리전의 정상 여부는 사설 서브넷의 DB 연결 오류율로 판단하려 합니다. 어떤 구성이 맞습니까?

A. Route 53 가중치 라우팅으로 50:50 분산
B. 사설 DB 엔드포인트를 대상으로 하는 Route 53 엔드포인트 상태 확인
C. DB 연결 오류율에 CloudWatch 경보를 만들고 그 경보를 보는 Route 53 상태 확인을 주 레코드에 연결한 장애 조치 라우팅
D. 지연 시간 기반 라우팅

정답과 이유

C입니다. Route 53은 사설 IP 범위의 엔드포인트를 직접 확인할 수 없으므로 사설 리소스의 상태는 CloudWatch 경보 기반 상태 확인으로 반영합니다. 장애 조치 라우팅이 액티브/패시브 구성에 맞습니다. A는 두 리전에 트래픽을 나누는 설정입니다. B는 사설 IP라 불가능합니다. D는 지연 기준이고 정상 여부 판단 조건이 없습니다. 경보는 상태 확인과 같은 계정에 있어야 하고 지표 수학 경보는 지원되지 않는다는 제약이 있습니다.

문제 7. 쇼핑몰의 상품 조회 API는 Lambda와 RDS for PostgreSQL로 되어 있습니다. 행사 때 Lambda 동시 실행이 수백 개로 늘면서 DB 연결 수 한도에 걸려 오류가 납니다. 코드 변경은 최소로 하고 싶습니다. 가장 알맞은 방법은 무엇입니까?

A. DB 인스턴스 유형을 키운다
B. RDS Proxy를 두고 Lambda가 프록시 엔드포인트에 연결하게 한다
C. Lambda 예약 동시성을 1로 낮춘다
D. 읽기 복제본을 15개 만든다

정답과 이유

B입니다. RDS Proxy는 연결 풀을 만들어 재사용하고 즉시 처리할 수 없는 연결은 큐에 넣거나 제한해 DB를 과부하에서 보호합니다. 대부분의 애플리케이션은 연결 엔드포인트만 바꾸면 됩니다. A는 연결 한도를 조금 늘릴 뿐 급증을 흡수하지 못합니다. C는 처리량을 버립니다. D는 읽기 전용 연결을 나눌 수는 있지만 복제본마다 연결 수 문제가 반복되고 RDS Proxy는 복제 구성에서 쓰기 인스턴스에만 붙는다는 제약도 함께 봐야 합니다.

문제 8. 결제 기록을 담은 S3 버킷을 다른 리전에 복제하려 합니다. 이미 있는 객체 수천만 개도 복제해야 하고 새 객체는 규정상 15분 안에 대상 리전에 있어야 합니다. 맞는 구성은 무엇입니까? (두 개 고르기)

A. 원본과 대상 버킷에 버전 관리를 켜고 CRR에 S3 RTC를 켠다
B. 기존 객체는 S3 Batch Replication으로 복제한다
C. 기존 객체는 CRR 규칙을 만들면 자동으로 복제된다
D. 버전 관리 없이 CRR만 켠다
E. RTC가 기존 객체에도 15분 SLA를 적용한다

정답과 이유

A와 B입니다. CRR은 원본과 대상 모두 버전 관리가 필요하고 RTC는 새 객체의 99.99%를 15분 안에 복제하도록 설계됐으며 99.9%까지를 SLA로 보장합니다. 실시간 복제는 설정 이전 객체를 복제하지 않으므로 기존 객체는 Batch Replication을 씁니다. C와 D는 문서와 반대입니다. E는 문서가 RTC는 Batch Replication에 적용되지 않는다고 명시합니다.

5. 범위와 한계

• 2026년 10월 19일에 열어 본 AWS 공식 문서, SAA-C03 시험 안내서, DR 백서(Disaster Recovery of Workloads on AWS)로 정리했습니다. 한도와 요금은 바뀌므로 응시 전에 다시 확인합니다.
• 실습은 아직 하지 않았습니다. SQS 표시 제한 시간과 DLQ 동작, Route 53 장애 조치 전환 시간, RDS 장애 조치 시간은 문서 수치를 옮긴 것이고 직접 잰 값이 아닙니다. Ch-00의 3단계에서 SQS와 SNS 팬아웃부터 만들어 볼 계획입니다.
• 2026년 10월 21일 보강: DynamoDB MRSC의 리전 수와 지연 특성, Auto Scaling 예약·예측 조정, Application Migration Service(AWS Transform MGN), DAX, EKS, Comprehend, Polly를 각 문서로 확인해 본문에 넣었습니다. S3 RTC 99.99%와 99.9%의 차이, AWS Backup 복원 테스트, X-Ray SDK·데몬 유지 관리 모드, Aurora에서 RDS Proxy 읽기 전용 엔드포인트도 고쳤습니다.
• 2026년 10월 20일 보강: 읽기 복제본 15개는 RDS 할당량 문서의 “Read replicas per primary” 기본값 15로, Route 53 실패 임계값 기본값 3은 API 참조로, Elastic Disaster Recovery의 RPO 초·RTO 분은 FAQ로, 서울 리전의 SQS FIFO 높은 처리량 한도(그 밖의 리전 2,400)는 메시지 할당량 문서로 확인했습니다. ELB 교차 영역·고정 세션·등록 취소 지연, Auto Scaling 수명 주기 후크·웜 풀, AWS Backup 리전 간 복사를 새로 넣었습니다.
• 문서끼리 숫자가 다른 곳은 Aurora Global Database 보조 리전 수(사용자 가이드 10개, 2021년판 DR 백서 5개)입니다. 본문에 어느 쪽을 따랐는지 적었습니다.
• SQS 메시지 최대 크기(1MiB), Lambda 비동기 페이로드 1MB와 Managed Instances 90분, EventBridge의 새 Custom Event Bus, ECS Managed Instances, 리전 NAT 게이트웨이는 시험 안내서 이후 바뀌거나 생긴 것으로 보이며 문항 반영 여부는 알 수 없습니다. Elastic Disaster Recovery는 2026년 10월 범위 안 서비스 목록에 없습니다.
• “시험에서 갈리는 조건” 표와 SNS·EventBridge 구분은 문서 설명을 시나리오 단어와 짝지은 제 정리입니다. 확인 문제는 직접 만든 것입니다.

참고 자료

시험 안내서와 백서

• AWS, AWS Certified Solutions Architect - Associate (SAA-C03)
• AWS, Content Domain 2: Design Resilient Architectures
• AWS Whitepaper, Disaster Recovery of Workloads on AWS: Business Continuity Plan (BCP), Disaster recovery options in the cloud

결합 끊기와 확장

• Amazon SQS Developer Guide: Amazon SQS queue types, Amazon SQS message quotas
• Amazon SNS Developer Guide, Amazon SNS message filtering
• Amazon EventBridge User Guide, What Is Amazon EventBridge?
• AWS Step Functions Developer Guide, Choosing workflow type in Step Functions
• Amazon API Gateway Developer Guide: Choose between REST APIs and HTTP APIs, Amazon API Gateway quotas, Quotas for configuring and running a REST API in API Gateway
• AWS Lambda Developer Guide, Lambda quotas
• Amazon ECS Developer Guide, What is Amazon Elastic Container Service?
• Amazon EC2 Auto Scaling User Guide, Dynamic scaling for Amazon EC2 Auto Scaling
• Amazon ElastiCache, Caching strategies for Memcached
• Amazon CloudFront Developer Guide, What is Amazon CloudFront?
• Amazon RDS User Guide: Working with DB instance read replicas, Differences between read replicas for DB engines
• AWS What’s New, Amazon RDS for MySQL, MariaDB and PostgreSQL now support up to 15 read replicas for 3X read capacity, 2022
• What is Amazon Elastic File System?, Amazon EBS volumes, What is AWS Transfer Family?

가용성과 복구

• Amazon Route 53 Developer Guide: Choosing a routing policy, Types of Amazon Route 53 health checks, Values that you specify when you create or update health checks
• AWS Global Accelerator Developer Guide, What is AWS Global Accelerator?
• Amazon RDS User Guide: Multi-AZ DB instance deployments for Amazon RDS, Failing over a Multi-AZ DB instance for Amazon RDS, Amazon RDS Proxy
• Amazon Aurora User Guide: High availability for Amazon Aurora, Using Amazon Aurora Global Database
• Amazon DynamoDB Developer Guide: Global tables - multi-active, multi-Region replication, Global tables core concepts
• Amazon S3 User Guide, Replicating objects within and across Regions
• AWS Backup Developer Guide, What is AWS Backup?
• AWS Elastic Disaster Recovery User Guide, What is Elastic Disaster Recovery?
• AWS X-Ray Developer Guide, What is AWS X-Ray?

2026년 10월 20일 보강 때 연 문서

• Elastic Load Balancing User Guide, How Elastic Load Balancing works
• User Guide for Application Load Balancers, Edit target group attributes for your Application Load Balancer
• Amazon EC2 Auto Scaling User Guide: Amazon EC2 Auto Scaling lifecycle hooks, Decrease latency for applications with long boot times using warm pools
• Amazon Route 53 API Reference, HealthCheckConfig
• AWS, AWS Elastic Disaster Recovery FAQs
• AWS Backup Developer Guide, Creating backup copies across AWS Regions
• Amazon RDS User Guide, Quotas and constraints for Amazon RDS

2026년 10월 21일 보강 때 연 문서

• AWS, Amazon S3 FAQs, S3 Replication Time Control SLA
• AWS Backup Developer Guide, Restore testing
• AWS X-Ray Developer Guide, X-Ray SDK and daemon support timeline
• AWS Transform MGN, Amazon RDS Proxy for Aurora, Multi-AZ DB cluster deployments
• Amazon DynamoDB Developer Guide, How global tables work, In-memory acceleration with DAX
• EC2 Auto Scaling: Scheduled scaling, Predictive scaling
• What is Amazon EKS?, What is Amazon Comprehend?, Amazon Comprehend availability change, What is Amazon Polly?
• AWS, In-Scope AWS Services (SAA-C03)