AWS SAA-C03 시험의 70%는 시나리오 기반 아키텍처 문제예요. 글로벌 인프라부터 단일 EC2가 고가용성 웹앱으로 진화하는 8단계, 3계층 쇼핑몰의 세션 관리, EFS 공유 스토리지, Elastic Beanstalk, 단일 EC2 HA 3패턴, 이벤트 드리븐(SQS/SNS/EventBridge·Fan-out), 캐싱 4계층, 네트워크 보안, HPC(EFA·FSx Lustre)까지 — 회사 사옥 진화 비유로 흐름 있게 풀어쓴 13편.
이 글은 AWS SAA-C03 스터디 노트 시리즈 13편입니다. 시리즈 거의 끝자락이고, 시험에서 가장 결정적인 단원이기도 해요. 13편의 키워드 한 줄로 묶으면 — Multi-AZ입니다. 시나리오 문제 거의 절반이 "Multi-AZ로 어떻게 묶어야 하나"를 묻거든요. 1편부터 12편까지 본 EC2·S3·VPC·RDS 같은 개별 서비스는 각자 단원에서는 분명했는데, 시험 문제는 항상 그것들을 Multi-AZ 단위로 두세 개씩 묶어서 던지거든요. "Multi-AZ 웹 앱에서 세션을 어디 둘까" 같은 문제는 EC2도 알아야 하고, ELB도 알아야 하고, ElastiCache·DynamoDB·세션 쿠키 개념도 알아야 풀립니다.
그래서 이 단원이 마지막 점수의 분기점이에요. SAA의 약 70%가 여러 서비스를 Multi-AZ로 결합한 시나리오 기반 아키텍처 문제라서, 12편까지 쌓아 둔 개별 지식을 솔루션 단위로 다시 묶는 작업을 안 하면 시험장에서 헤맵니다.
이번 글은 노트 한 권을 큰 흐름으로 풀어 갑니다. 회사 비유를 자주 쓸 거예요 — 단일 EC2 한 대로 시작한 회사가 본사·지사 Multi-AZ 멀티사이트로 성장하는 과정처럼 풀면 머릿속에 잘 들어옵니다. 한 단원 한 단원이 결국 "이런 키워드가 보이면 이런 Multi-AZ 조합이 답"이라는 매칭 자료가 돼요. AWS 공식 Well-Architected 신뢰성 기둥 문서도 결국 같은 결론입니다 — 가용성은 Multi-AZ에서 시작합니다.
먼저 한 번 더 — AWS 글로벌 인프라
시험 직전에도 한 번 더 짚어야 할 가장 기초 — 리전·AZ·엣지 로케이션 셋입니다. 1편에서도 다뤘지만 시험 직전 머릿속이 흐릿해질 때 다시 펼쳐 볼 수 있게 한 번 더 박아 둡니다.
| 구성 요소 | 설명 |
|---|---|
| 리전(Region) | 데이터 센터 클러스터, 대부분의 서비스가 리전 종속 |
| 가용 영역(AZ) | 리전 내 격리된 데이터 센터 묶음 (3~6개), 독립 전원·네트워킹 |
| 엣지 로케이션 | 전 세계 400+ 지점, 최종 사용자에게 최저 지연으로 콘텐츠 전달 |
회사 비유로 풀면 — 리전은 한 도시 안에 여러 사옥이 모인 캠퍼스, AZ는 그 캠퍼스 안에 떨어져 있는 별개 건물들, 엣지 로케이션은 손님 가까이 둔 임시 매장이에요. 한 건물(AZ)에 정전이 나도 다른 건물은 멀쩡합니다 — 이게 바로 결함 내성(Fault Tolerance) 설계.
리전을 고를 때 따져야 하는 4요인을 우선순위로 외워 두면 좋아요 — Compliance(법률) → Latency(지연) → Availability(서비스 제공) → Pricing(요금). GDPR 같은 규정이 가장 우선이고 가격이 가장 마지막입니다. 가격이 1순위로 등장하는 보기는 거의 함정이에요.
글로벌 vs 리전 서비스 — 콘솔에서 'Global' 표시가 붙는 건 딱 4개입니다. IAM·Route 53·CloudFront·WAF. 나머지는 거의 다 리전 종속이에요. 1편 IAM 단원에서 외운 그대로입니다.
AWS와 상호작용하는 통로는 셋 — Console(웹 UI), CLI(터미널), SDK(앱 코드 안에서). 시험에서 어느 통로로 자동화할지 묻는 문제는 보통 "스크립트로 자동화"가 보이면 CLI, "앱 코드 안"이면 SDK입니다.
클래식 패턴 1 — 시간 표시 웹 서비스 예시 (단일 EC2가 Multi-AZ로 성장하는 8단계)
처음 사옥 1개에서 본사·지사 멀티사이트로 성장하는 과정과 똑같습니다. 단일 EC2 한 대가 어떻게 고가용성·확장성 있는 시스템으로 진화하는지 보여 주는 정석 시나리오예요. SAA의 거의 모든 웹앱 문제의 베이스가 되니 한 번 흐름으로 잡고 갑니다.
| 단계 | 구성 | 해결한 문제 / 새 문제 |
|---|---|---|
| 1. 단일 EC2 (T2 micro) | 퍼블릭 IP + Elastic IP | 재시작 시 IP 변경 방지용 EIP 필요 |
| 2. 수직 확장 (Scale-up) | T2 → M5 large | 인스턴스 중지 → 변경 → 다운타임 발생 |
| 3. 수평 확장 (수동) | M5 여러 대 + EIP 각각 | EIP는 리전당 계정별 기본 5개 제한, 사용자가 여러 IP 인지해야 |
| 4. Route 53 도입 | A 레코드로 여러 EC2 IP 반환 | TTL 1시간 캐싱 → EC2 장애 시 1시간 접속 불가 |
| 5. ELB 도입 | ALB + Health Check + Alias 레코드 | EC2 프라이빗 전환, SG 참조로 보안 강화 |
| 6. ASG 도입 | ELB + Auto Scaling Group | 수동 추가/제거 불필요 |
| 7. Multi-AZ | ELB + ASG를 여러 AZ에 배포 | 단일 AZ 장애에도 생존 → 고가용성 확보 |
| 8. 비용 최적화 | 기본 용량(2대)은 RI, 변동은 On-Demand/Spot | 비용 대폭 절감 |
회사 비유로 한 번 풀면 — 1단계는 동네에 자그마한 사옥 하나, 2단계는 그 사옥을 더 큰 건물로 이사 가는 것(이사 동안 영업 중단), 3단계는 같은 동네에 사옥 여러 개를 두는 것(손님이 어느 사옥으로 갈지 헷갈림), 4단계는 안내 데스크(Route 53)를 두지만 안내가 1시간씩 묵은 정보, 5단계는 회전문(ELB)으로 자동 분배, 6단계는 직원 수가 자동으로 늘었다 줄었다(ASG), 7단계는 여러 동네에 사옥 분산(Multi-AZ), 8단계는 상시 직원만 정규직(RI), 임시 직원은 일당(Spot)으로 비용 최적화. 이렇게 풀면 시험장에서 단계 순서가 헷갈릴 일이 없어요.
여기서 시험 함정이 하나 있어요. AWS 리소스(ELB·CloudFront 등)의 동적 IP를 Route 53에서 가리킬 때 — 보기에 A 레코드가 나오면 거의 100% 오답입니다. 정답은 무조건 Alias 레코드예요. AWS 리소스 IP는 자주 바뀌니까 Alias가 자동으로 따라가 줍니다.
핵심 4가지를 정리하면:
- AWS 리소스(ELB·CloudFront)의 동적 IP를 Route 53에서 가리킬 때는 반드시 Alias 레코드 (A 레코드 X)
- EC2가 ELB를 통해서만 트래픽을 받게 하려면 EC2 SG 인바운드 소스를 ELB의 SG ID로 지정 (IP 대신)
- 고가용성 = Multi-AZ (단일 장애점 제거)
- 상시 가동 기본 용량 → Reserved Instance, 변동 트래픽 → On-Demand/Spot 혼합
클래식 패턴 2 — 온라인 쇼핑몰 예시 (Multi-AZ 3계층 쇼핑몰의 세션 관리)
웹앱이 무상태(Stateless)일 때는 위 패턴 1로 끝나는데, 쇼핑 카트처럼 상태(State)가 생기면 이야기가 한층 복잡해집니다. 손님이 첫 번째 사옥에서 카트에 옷을 담았는데 다음 클릭에서 두 번째 사옥으로 갔더니 카트가 비어 있다 — 이건 안 되니까요.
세션 상태를 어디 둘지에 길은 셋이에요.
| 방법 | 단점 |
|---|---|
| ELB 스티키 세션 | 그 EC2 장애 시 세션 데이터 소실 |
| 웹 쿠키 (클라이언트) | HTTP 무거워짐, 변조 가능, 4KB 제한 |
| ElastiCache / DynamoDB | AWS 권장 베스트 프랙티스 |
답은 마지막입니다. 쿠키에는 세션 ID만 두고, 실제 카트 데이터는 ElastiCache 또는 DynamoDB에 저장하는 거예요. 회사 비유로 — 손님 손에 든 종이는 회원증 번호만 적힌 카드, 실제 쇼핑 정보는 공용 사물함(ElastiCache) 에 보관해 두는 식. 어떤 사옥에 가도 같은 사물함을 보니까 카트가 살아 있어요.
DB 계층은 두 갈래로 확장합니다.
- 장기 데이터 저장 — RDS (사용자 정보·주소 같은 영구 데이터)
- 읽기 성능 확장 — RDS Read Replicas(최대 15개)로 읽기 트래픽 분산, ElastiCache Lazy Loading으로 자주 찾는 데이터 캐싱
고가용성을 전 계층에 적용하려면:
- Route 53 → 기본적으로 HA
- ELB + ASG → Multi-AZ 배포
- RDS Multi-AZ → 장애 시 Standby로 자동 페일오버
- ElastiCache Multi-AZ → 활성화 권장
보안 그룹 계층은 IP가 아닌 SG 참조로 묶는 게 핵심이에요.
인터넷(HTTPS) → ELB SG → EC2 SG (ELB SG에서 오는 트래픽 허용)
→ RDS SG (EC2 SG에서 오는 트래픽 허용)
→ ElastiCache SG (EC2 SG에서 오는 트래픽 허용)이렇게 하면 Auto Scaling으로 EC2 IP가 매번 바뀌어도 SG ID 자체는 그대로니까 규칙을 다시 짤 필요가 없어요. 이게 SG 참조 패턴이 시험에 매번 나오는 이유입니다.
RDS Multi-AZ = 고가용성/DR (동기 복제, 자동 페일오버), RDS Read Replica = 읽기 성능 확장 (비동기 복제). 이 둘은 목적이 완전히 다릅니다. 시험에 거의 매번 헷갈리게 출제되니 절대 섞지 마세요. "장애 대비"가 키워드면 Multi-AZ, "읽기 부하 분산"이면 Read Replica.
클래식 패턴 3 — 블로그 호스팅 예시 (Multi-AZ 공유 스토리지 패턴)
여러 EC2에서 같이 돌아가는 WordPress가 사용자 업로드 이미지를 공유해야 하는 상황입니다. 핵심 비교는 EBS vs EFS.
| 항목 | EBS | EFS |
|---|---|---|
| 연결 방식 | 한 시점에 1 EC2만 (AZ 종속) | 여러 AZ 수백 EC2 동시 공유 |
| 접근 방식 | 블록 스토리지 | NFS (네트워크 파일 시스템) |
| AZ 분산 | 단일 AZ 종속 | 각 AZ에 ENI로 접근 |
| 비용 | 저렴 | EBS보다 비쌈 |
| 사용 시점 | 단일 인스턴스, OS 부팅 | 다중 AZ 분산 앱 공유 스토리지 |
회사 비유로 — EBS는 개인 USB 드라이브(한 사람만 꽂아 쓸 수 있음), EFS는 공용 파일 서버(여러 사람이 동시에 같은 폴더를 봄). WordPress 이미지 같은 건 공용 파일 서버여야 모든 EC2가 같은 이미지를 볼 수 있어요.
문제 — A 인스턴스 EBS에 이미지를 업로드했는데 B 인스턴스에서 접속하면 이미지가 안 보이는 데이터 불일치. 해결 — EFS로 모두가 같은 파일 시스템을 보게 만듦.
DB는 RDS MySQL과 Aurora MySQL 사이에서 한 번 더 고민이 필요해요.
| 항목 | RDS MySQL | Aurora MySQL |
|---|---|---|
| 운영 오버헤드 | 상대적으로 높음 | 적음 |
| Read Replicas | 최대 5개 | 최대 15개 |
| Multi-AZ | 지원 | 기본 지원 |
| 글로벌 DB | 미지원 | Aurora Global Database |
| 권장 | 기본 사용 | 글로벌·대규모 |
시험에서 "여러 리전을 가로지르는 글로벌 서비스 + 관계형 DB" 시나리오가 나오면 답은 거의 항상 Aurora Global Database 입니다. RDS는 글로벌이 안 돼요.
클래식 패턴 4 — 빠른 인스턴스화 전략
EC2를 처음부터 설치·구성하지 않고 가장 빠르게 띄우는 방법은 시험 단골이에요. Auto Scaling 시 부팅 속도가 곧 서비스 응답 속도라서요.
| 전략 | 개념 | 장점 |
|---|---|---|
| Golden AMI | OS·앱·종속성이 모두 사전 설치된 커스텀 AMI | 부팅 즉시 앱 실행, ASG 반응 속도 극대화 |
| EC2 User Data | 인스턴스 첫 시작 시 실행 스크립트 | 동적 구성(DB URL·암호)에만 사용. 설치 목적으로 쓰면 느림 |
| 하이브리드 (Golden AMI + User Data) | 무거운 설치 = AMI / 동적 = User Data | 빠른 시작 + 유연성. Beanstalk가 내부적으로 사용 |
회사 비유로 — Golden AMI는 신입 직원이 책상에 앉기도 전에 컴퓨터·계정·소프트웨어가 다 세팅된 상태, User Data는 책상에 앉아서 그날 비밀번호·서버 주소를 입력하는 단계. 무거운 설치를 User Data로 처리하면 신입 직원이 한참 동안 컴퓨터 세팅하느라 일을 못 하는 셈이에요.
DB·스토리지를 빠르게 배포하려면 — RDS는 스냅샷 복원(INSERT 스크립트보다 훨씬 빠름), EBS는 스냅샷에서 볼륨 생성(포맷 + 데이터 복사 과정 없이 즉시 사용). 시험에 "DB를 빠르게 복제·테스트 환경 구축" 시나리오가 나오면 답은 RDS 스냅샷 복원입니다.
클래식 패턴 5 — Elastic Beanstalk
코드만 업로드하면 인프라(EC2·ELB·ASG·모니터링)를 자동 배포·관리해 주는 PaaS가 Elastic Beanstalk 입니다. 회사 비유로는 — 인테리어·전기·통신을 한 번에 해 주는 턴키 사옥 임대 서비스예요. 사장(개발자)은 직원과 사업 계획만 들고 가면 되는 식.
자동화 항목 — 용량 프로비저닝·로드 밸런싱·오토 스케일링·앱 상태 모니터링. 그런데도 기저 리소스(EC2·ASG 등)는 사용자가 완전히 제어 가능합니다(Full Control). 자동이라고 해서 손을 못 대는 건 아니에요.
요금은 — Beanstalk 서비스 자체는 무료, 생성된 EC2·ELB·RDS 등 리소스에만 비용 청구. 내부 동작 — 백그라운드에서 AWS CloudFormation을 사용해 리소스 생성.
구성 요소가 셋이에요.
| 요소 | 설명 |
|---|---|
| 애플리케이션(Application) | 환경·버전·구성을 묶은 논리적 최상위 컨테이너 |
| 애플리케이션 버전(Version) | 배포 가능한 코드의 특정 버전 (v1·v2·...) |
| 환경(Environment) | 특정 버전을 실행하는 AWS 리소스 집합 (Dev·Test·Prod) |
환경에는 두 가지 계층이 있고, 이게 시험 단골이에요.
| 계층 | 용도 | 구성 |
|---|---|---|
| Web Server Tier | 일반 웹앱·REST API | ELB → EC2 (ASG 내) |
| Worker Tier | 백그라운드·비동기 처리 | SQS 대기열 → EC2 (메시지 수에 따라 자동 확장) |
> 아키텍처 팁 — Web Server Tier에서 SQS로 메시지를 보내고 Worker Tier가 그걸 Pull해서 처리하는 구조. 두 환경을 SQS로 디커플링(Decoupling) 해서 운영합니다. "비동기 백그라운드 처리"가 키워드면 거의 무조건 Worker Tier + SQS.
배포 모드는 두 가지예요.
| 모드 | 용도 | 구성 |
|---|---|---|
| 단일 인스턴스 | Dev/Test 환경 | ELB 없음, EC2 1대 + Elastic IP |
| 고가용성 | Production 환경 | Multi-AZ + ELB + ASG |
필수 IAM 역할도 시험에 자주 나옵니다.
- 서비스 역할(Service Role) — Beanstalk가 EC2·ELB 등을 사용자 대신 만들 권한
- EC2 인스턴스 프로파일(Instance Profile) — 생성된 EC2 안의 앱이 S3·DynamoDB 같은 다른 AWS 서비스에 접근할 권한
지원 플랫폼 — Go·Java(SE/Tomcat)·.NET·Node.js·PHP·Python·Ruby·Docker.
Beanstalk vs CloudFormation 차이도 짚어 둘게요. Beanstalk는 코드/앱 중심(웹앱을 빠르고 쉽게 배포), CloudFormation은 인프라 중심(모든 종류의 AWS 리소스를 IaC 템플릿으로 정의). 시험에 "코드 한 줄 업로드로 웹앱 배포" → Beanstalk, "조직 전체의 모든 리소스를 코드로 정의" → CloudFormation입니다.
클래식 패턴 6 — 단일 EC2 Multi-AZ HA 3가지 패턴
EC2와 EBS는 기본적으로 단일 AZ에 종속이에요. 그런데 단일 EC2를 다른 AZ로 자동 페일오버하려면 어떻게? — 여기서 시험 함정이 하나 있어요, 패턴 A·B·C 중 어느 게 정답인지가 시나리오 키워드에 따라 갈립니다. 한 번 깔끔하게 정리할게요.
패턴 A — CloudWatch + Lambda + Elastic IP (대기 인스턴스 활용) CloudWatch가 EC2 상태를 감시하다 알람 발생 → Lambda 트리거 → Lambda가 대기 인스턴스를 시작하고 Elastic IP를 재연결(Remapping). 사용자는 동일한 EIP로 접속하니 백엔드 장애를 인지하지 못해요. 키워드 — "대기 인스턴스", "EIP 재연결".
패턴 B — ASG (Min=1, Max=1, Desired=1) + User Data + Elastic IP 2개 AZ에 걸쳐 ASG를 만들고 용량을 1로 고정해 둡니다. 인스턴스 장애 시 ASG가 감지해서 다른 AZ에 새 인스턴스를 자동 생성하고, User Data 스크립트가 API를 호출해 EIP를 자기에게 연결해요. 중요 — EC2가 API를 호출하려면 적절한 권한의 IAM 역할(Instance Profile) 이 연결돼 있어야 합니다. 키워드 — "ASG 1·1·1", "User Data", "API 호출".
패턴 C — ASG + Lifecycle Hook + EBS Snapshot (Stateful HA) Stateful 앱(데이터가 EBS에 저장된 DB 등)에 사용해요. 흐름은 — 장애 발생 → Lifecycle Hook(Terminating) 으로 종료를 일시 중지 → EBS 스냅샷 생성 → 다른 AZ에 새 인스턴스 시작 → Lifecycle Hook(Launching) 또는 User Data로 스냅샷에서 새 EBS 볼륨 생성 → 인스턴스에 연결 → EIP 연결. 키워드 — "Stateful", "EBS 스냅샷 보존", "Lifecycle Hook".
회사 비유로 풀면 — A는 대타 직원이 항상 대기, B는 자리가 비면 자동으로 새 직원이 그 자리를 채움, C는 직원이 떠날 때 자기 책상 서랍을 통째로 박스에 담아서 새 직원이 그대로 받음(데이터 보존). Stateful 앱에는 C가 정답이에요.
이벤트 드리븐 — DLQ 위치의 결정적 함정
이벤트 드리븐 아키텍처에서 시험 단골이 SQS와 SNS의 Lambda 통합 차이입니다. 처음 보면 둘 다 비슷해 보이는데, DLQ를 어디에 다는지가 다르다는 게 핵심이에요.
SQS + Lambda — Lambda가 큐를 폴링(Pull). 처리 실패 시 메시지가 큐로 돌아가서 무한 반복 가능. 그래서 DLQ를 SQS 측에 설정해서 불량 메시지(Poison Pill)를 격리합니다.
SNS + Lambda — SNS가 Lambda를 비동기 Push. 처리 실패 시 Lambda 내부에서 재시도(최대 3번). DLQ는 Lambda 측에 설정해요.
| 통합 | 방향 | DLQ 위치 |
|---|---|---|
| SQS → Lambda | Pull | SQS 측 |
| SNS → Lambda | Push | Lambda 측 |
여기서 시험 함정이 하나 있어요 — 누가 누구를 호출하는지(누가 능동적인지)에 따라 DLQ 위치가 결정됩니다. SQS는 Lambda가 능동적으로 가져오니까 DLQ가 SQS 쪽, SNS는 SNS가 능동적으로 보내니까 DLQ가 받는 쪽(Lambda)입니다. 이 한 줄만 기억하면 안 헷갈려요.
SQS FIFO도 함정이 있어요. 메시지 순서가 보장되는 대신, 처리 실패 시 전체 큐가 차단(Block) 됩니다. 그래서 FIFO에서도 DLQ로 불량 메시지를 격리하는 게 필수예요.
Fan-out 패턴 — 한 이벤트를 여러 시스템에
Fan-out도 자주 나오는 패턴입니다. 문제 상황은 — 앱이 여러 SQS 큐에 순차적으로 메시지를 보내다가 중간에 크래시 나면 일부 큐만 메시지가 들어가서 데이터 불일치가 생긴다는 거예요. 회사 비유로 치면 우체국 직원이 편지 5장을 한 통씩 우편함에 넣다가 3번째에서 쓰러진 격이죠.
해결 — 앱이 단일 SNS Topic에 메시지를 한 번 보내면, 여러 SQS 큐가 그 SNS를 구독해서 SNS가 모든 큐에 병렬 전달해 줍니다. 결합도 ↓, 신뢰성 ↑.
앱 → SNS Topic ─┬─→ SQS 큐 A
├─→ SQS 큐 B
└─→ SQS 큐 CS3 이벤트 처리 — 기본 알림 vs EventBridge
이것도 시험에 자주 나옵니다.
| 방식 | 필터링 | 목적지 |
|---|---|---|
| 기본 S3 이벤트 알림 | 이름(접두사·접미사)만 | SNS·SQS·Lambda 3가지만 |
| S3 + EventBridge | 고급(메타데이터·객체 크기 등) | 18+ AWS 서비스 (Step Functions·Firehose 등), 아카이브·재생 지원 |
객체 크기 기반 필터링이나 Step Functions 트리거 같은 고급 시나리오는 무조건 EventBridge예요. 보기에 "객체 크기" 또는 "Step Functions"가 보이면 EventBridge가 정답.
부수 패턴 둘 더 짚고 갑니다.
CloudTrail + EventBridge (API 호출 모니터링)
특정 API 호출 (예: DynamoDB DeleteTable)
→ CloudTrail이 기록
→ EventBridge가 가로챔
→ SNS로 관리자에게 경고 이메일외부 이벤트 수집 아키텍처
외부 클라이언트 → API Gateway → Kinesis Streams → Kinesis Firehose → S3캐싱 4계층 — 어디에 두느냐의 분류
캐싱은 위치에 따라 네 계층으로 나뉩니다. 시험에 "지연 시간을 줄이려면?" 시나리오의 답은 거의 매번 이 표 안에서 나와요.
| 계층 | 서비스 | 위치 | 특징 | 주의점 |
|---|---|---|---|---|
| 엣지 캐싱 | CloudFront | 엣지 로케이션 (사용자와 가장 가까운 곳) | 정적·동적 콘텐츠, 최저 지연 | TTL 설정, Invalidation으로 즉시 갱신 가능 |
| 리전 캐싱 | API Gateway 캐싱 | 리전 레벨 | API 백엔드 호출 ↓ | 사용자 ↔ API GW 네트워크 지연은 여전 |
| DB 앞 캐싱 | ElastiCache (Redis/Memcached) | 앱 서버 근처 | RDS 읽기 부하 ↓, 마이크로초 응답 | 캐시 유지보수 (Lazy Loading 패턴) |
| DynamoDB 전용 | DAX (DynamoDB Accelerator) | DynamoDB 앞단 | DynamoDB 마이크로초, 앱 변경 최소 | DynamoDB에만 사용 |
회사 비유로 — CloudFront는 손님 동네에 있는 임시 매장, API Gateway 캐싱은 본사 1층 안내데스크, ElastiCache는 창고 옆 자주 찾는 물건 진열대, DAX는 DynamoDB 전용 진열대예요.
선택 가이드를 한 줄로 묶으면:
- 글로벌 지연 시간 ↓ → CloudFront
- API 백엔드 호출 ↓ → API Gateway 캐싱
- RDS 읽기 부하 ↓ → ElastiCache
- DynamoDB 읽기 부하 ↓ → DAX
네트워크 보안 계층 — CloudFront + ALB 함정
EC2에 직접 접근할 때 보안 계층이 셋이 겹쳐 있어요.
인터넷
↓ 1차 방어: NACL (서브넷 수준, Allow/Deny 모두 지원, 특정 IP 차단에 적합)
↓ 2차 방어: 보안 그룹 (EC2 수준, Allow만 지원, 거부 규칙 없음)
↓ 3차 방어: EC2 내부 방화벽 (OS 수준, CPU 자원 소모 주의)
EC2CloudFront + ALB 구조의 결정적 함정
이게 시험에 거의 매번 나오는 함정이에요. 한 번 천천히 풀게요.
클라이언트 → CloudFront → ALB (퍼블릭 서브넷) → EC2 (프라이빗)여기서 시험 함정이 하나 있어요. ALB 서브넷 앞에 NACL을 두고 거기서 클라이언트의 악성 IP를 차단하려고 시도하면 — 실패합니다. 왜냐하면 ALB는 CloudFront를 거쳐 들어오는 트래픽만 받으니까 ALB 서브넷의 NACL 입장에서는 출발지가 항상 CloudFront IP로 보이거든요. 진짜 클라이언트 IP는 NACL 단에서 보이지 않아요.
올바른 설정은 다음과 같습니다.
- ALB 보안 그룹 — CloudFront 퍼블릭 IP 대역만 허용 (AWS 관리형 Prefix List 활용해서 자동으로 갱신)
- 국가 단위 차단 — CloudFront Geo-Restriction 기능 사용
- 특정 클라이언트 IP 차단 — CloudFront에 AWS WAF 연결해서 IP 필터링
WAF는 ALB 또는 CloudFront에 붙여서 SQL 인젝션·XSS 같은 7계층 공격을 막아 줍니다. 추가 비용은 발생해요.
> "CloudFront + ALB 구조에서 클라이언트 IP 차단" → CloudFront에 WAF 연결. 이 한 줄을 통째로 외워두면 시험장에서 함정에 안 빠집니다.
HPC — 키워드 매칭으로 푸는 영역
고성능 컴퓨팅(HPC)은 단시간에 대량 리소스를 띄워 연산 시간을 줄이고, 끝나면 즉시 해체하는 게 클라우드의 강점이에요. 게놈학·계산 화학·금융 리스크 모델링·기상 예보·ML/딥러닝·자율주행 같은 게 대표 사용 사례입니다.
HPC는 시험에서 키워드 매칭으로 풀 수 있게 출제되는 경향이 있어요. 키워드만 잡으면 답이 거의 바로 나오는 영역.
데이터 전송 — Direct Connect·Snow·DataSync
- AWS Direct Connect — 프라이빗 보안 네트워크, GB/s 단위 전송
- AWS Snowball/Snowmobile — PB급 대용량 데이터 물리적 이동
- AWS DataSync — 온프레미스(NFS·SMB) ↔ AWS 스토리지(S3·EFS·FSx) 대량 동기화
컴퓨팅 & 네트워킹
| 기술 | 설명 | 성능 |
|---|---|---|
| 클러스터 배치 그룹 | 단일 AZ, 동일 랙 | 10Gbps, 노드 간 통신 최적 |
| ENA (Elastic Network Adapter) | Enhanced Networking (SR-IOV) | 최대 100Gbps |
| Intel 82599 VF | Enhanced Networking 레거시 | 최대 10Gbps |
| EFA (Elastic Fabric Adapter) | HPC 전용 ENA 개선판, Linux에서만 작동 | MPI 활용, OS 우회(Bypass) 로 극저지연, 밀접 결합 워크로드 전용 |
> 시험 키워드 — "밀접하게 결합된 워크로드(Tightly Coupled)", "Linux", "OS 우회(Bypass)", "MPI" → EFA.
스토리지
| 스토리지 | IOPS | 특징 |
|---|---|---|
| EBS io2 Block Express | 256K | 인스턴스 연결 |
| Instance Store | 수백만, 초저지연 | 인스턴스 종료 시 데이터 소실 (임시) |
| Amazon EFS | 확장형 | 공유 파일 시스템 |
| FSx for Lustre | 수백만 | HPC 최적화, S3와 원활하게 연동 |
> 시험 키워드 — "HPC 파일 시스템", "수백만 IOPS", "S3 연동" → FSx for Lustre.
자동화·오케스트레이션
- AWS Batch — 다중 노드 병렬 작업 지원, 스케줄링·EC2 자동 관리
- AWS ParallelCluster — AWS에 HPC를 배포하는 오픈소스 클러스터 관리 툴, 텍스트 파일로 VPC·서브넷·인스턴스 유형 구성, EFA 파라미터 설정으로 네트워크 성능 극대화
시나리오별 서비스 선택 — 시험 직전 매칭표
이 표가 13편의 결론에 가장 가깝습니다. 시험에 자주 나오는 시나리오 → 정답 서비스를 한 표에 정리해 둘게요. 시험 전날 한 번만 다시 훑으면 머리에 남아요.
| 시나리오 | 정답 | 핵심 이유 |
|---|---|---|
| Linux EC2 다중 AZ 파일 공유 | EFS | NFS 기반, 여러 AZ 동시 접근 |
| Windows 파일 공유 | FSx for Windows | SMB 프로토콜 |
| HPC 고성능 파일 시스템 | FSx for Lustre | 수백만 IOPS, S3 백엔드 |
| 글로벌 정적 캐싱 | CloudFront | 엣지 로케이션 |
| 수평 확장 웹앱 | ALB + ASG (Multi-AZ) | HA + 자동 확장 |
| 하나의 이벤트 → 여러 시스템 | SNS + SQS Fan-out 또는 EventBridge | 결합도 ↓ |
| 비동기 백그라운드 처리 | SQS + Lambda | 디커플링 |
| 실시간 대용량 스트리밍 | Kinesis Data Streams | 대용량 실시간 |
| 스트리밍 → S3 | Kinesis Firehose | 완전 관리형 전달 |
| 관계형 DB HA | RDS Multi-AZ | 자동 페일오버 |
| 관계형 DB 읽기 확장 | RDS Read Replicas | 읽기 부하 분산 |
| 관계형 DB 글로벌 | Aurora Global Database | 리전 간 |
| NoSQL 서버리스 | DynamoDB | 완전 관리형 |
| DynamoDB 마이크로초 | DAX | 앱 변경 최소 |
| 컨테이너 서버리스 | ECS Fargate | 서버 관리 X |
| 쿠버네티스 | EKS | K8s 호환 |
| 빠른 앱 배포 (인프라 X) | Elastic Beanstalk | PaaS |
| IaC | CloudFormation | 모든 리소스 템플릿 |
| 온프레 DB 마이그레이션 | DMS | 동종/이종, 무중단 |
| 서버 리프트앤시프트 | MGN | 에이전트 기반 |
| 온프레 ↔ AWS 동기화 | DataSync | 대용량 |
| PB급 물리 이동 | Snowball/Snowmobile | 오프라인 |
| 악성 IP 즉시 무료 차단 | NACL | 서브넷 Deny |
| CloudFront+ALB 클라이언트 IP 차단 | CloudFront에 WAF 연결 | NACL은 CF IP만 봄 |
| EC2 시작 시간 ↓ (ASG) | Golden AMI | 부팅 즉시 실행 |
| DB 빠른 복제·테스트 | RDS 스냅샷 복원 | INSERT보다 빠름 |
핵심 비교표 5종 — 저장본
시험 직전 한 번 더 보고 갈 표 5개입니다.
스토리지
| 서비스 | 유형 | AZ | 용도 |
|---|---|---|---|
| EBS | 블록 | 단일 AZ | OS 부팅·DB |
| EFS | NFS 공유 | Multi-AZ | WordPress 공유 |
| FSx Windows | SMB 공유 | Multi-AZ | Windows 공유 |
| FSx Lustre | 고성능 | 단일 AZ | HPC + S3 |
| Instance Store | 임시 블록 | 단일 AZ | 임시 캐시 (종료 시 소실) |
| S3 | 객체 | 리전 | 백업·정적 호스팅 |
DB
| 서비스 | HA | Read 확장 | 글로벌 |
|---|---|---|---|
| RDS | Multi-AZ | RR 5개 | X |
| Aurora | 내장 | RR 15개 | Global DB |
| DynamoDB | 내장 | Global Tables | Global Tables |
| ElastiCache | Multi-AZ | RR | X |
| DAX | 내장 | — | X |
메시징
| 서비스 | 패턴 | 순서 | 지속성 |
|---|---|---|---|
| SQS Standard | Pull | X | 14일 |
| SQS FIFO | Pull | O | 14일 |
| SNS | Push | X | 없음 |
| EventBridge | 이벤트 버스 | — | 아카이브 |
| Kinesis Streams | Pull | 샤드 내 | 365일 |
네트워크 인터페이스 (HPC)
| 인터페이스 | 대역폭 | 특징 |
|---|---|---|
| ENI | 일반 | 기본 |
| ENA | 100Gbps | Enhanced (SR-IOV) |
| EFA | 100Gbps+ | MPI, OS 우회, Linux 전용 |
배치 그룹
| 유형 | 배치 방식 | 사용 |
|---|---|---|
| Cluster | 단일 AZ 동일 랙 | HPC, 빅데이터 |
| Spread | 여러 AZ 다른 랙 (AZ당 7개) | 중요 인스턴스 HA |
| Partition | 여러 AZ 파티션별 독립 랙 | Hadoop, Cassandra, Kafka |
Multi-AZ 아키텍처 설계 5대 원칙
이 다섯 원칙이 13편 전체의 압축이라고 봐도 됩니다. 시험장에서 보기 4개 중에 헷갈릴 때, 이 다섯 줄에 비춰 보면 답이 나와요.
- 고가용성 = Multi-AZ — ELB·ASG·RDS·ElastiCache 모두 Multi-AZ 적용
- 보안 그룹 참조 — IP 대신 SG ID를 소스로 지정 (Auto Scaling 시 자동 적용)
- Stateless EC2 — 세션·상태 데이터는 ElastiCache 또는 DynamoDB에 분리
- Route 53 레코드 — AWS 리소스 가리킴 = Alias / 직접 IP만 A 레코드
- EC2 비용 전략 — 상시 가동 = RI(72%↓) / 변동 = On-Demand / 배치 = Spot
시험 직전 한 번 더 — 자주 헷갈리는 함정 압축
여기까지가 13편 핵심입니다. 시험 직전 다시 펼쳐 볼 압축 노트를 마지막에 박아 둘게요. 이 부분만 한 번 더 읽으면 단원 전체가 거의 다 떠오릅니다.
- 글로벌 서비스 4총사 — IAM·Route 53·CloudFront·WAF
- 리전 선택 4요인 — Compliance > Latency > Availability > Pricing
- AWS 리소스 가리키는 Route 53 레코드 = Alias (A 레코드 X)
- EC2 SG 인바운드 소스 = ELB SG ID (IP X)
- 세션 상태 = ElastiCache 또는 DynamoDB (스티키·쿠키 X)
- RDS Multi-AZ = HA·DR(동기) / Read Replica = 읽기 확장(비동기)
- 다중 EC2 공유 스토리지 = EFS (EBS X)
- 글로벌 관계형 DB = Aurora Global Database
- 빠른 인스턴스화 = Golden AMI, 빠른 DB 배포 = RDS 스냅샷 복원
- Beanstalk 내부 = CloudFormation / Worker Tier = SQS
- 단일 EC2 HA — A: CloudWatch+Lambda+EIP / B: ASG(1·1·1)+UserData / C: ASG+LifecycleHook+Snapshot
- SQS+Lambda = SQS DLQ / SNS+Lambda = Lambda DLQ
- Fan-out = SNS Topic → 여러 SQS 구독
- S3 객체 크기 필터·Step Functions 트리거 = EventBridge
- 캐싱 4계층 — CloudFront / API GW 캐싱 / ElastiCache / DAX
- CloudFront+ALB 클라이언트 IP 차단 = CloudFront에 WAF
- HPC 키워드 — 밀접 결합·Linux·OS 우회·MPI = EFA
- HPC 파일 시스템·수백만 IOPS·S3 연동 = FSx for Lustre
- HPC 클러스터 자동 배포 = ParallelCluster
- 최저 지연 인스턴스 배치 = 클러스터 배치 그룹
여기까지가 SAA-C03 Multi-AZ 솔루션 아키텍처 패턴 종합입니다. 1편부터 12편까지의 개별 서비스 지식이 13편의 시나리오 매칭표로 변환되는 순간이 시험장에서 가장 결정적이에요. 표를 한 번에 다 외우려 하지 마시고, 각 시나리오 키워드 → 정답 Multi-AZ 서비스 → 핵심 이유의 흐름으로 천천히 짚어 가시면 머리에 남습니다.
다음 글(14편, 마지막)에서는 시험 직전 정리 — 시험 개요·Well-Architected Framework·헷갈리는 함정·숫자 암기·전략을 한 번에 묶어 14편 시리즈를 마무리합니다.
시리즈 다른 편
같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.