
안녕하세요! 넥스트클라우드의 테크니컬 트레이너 김서윤입니다. 🍂
어느새 10월의 첫 금요일입니다! 아침저녁으로 공기가 제법 선선해져서 책상 앞에 앉아 있기 좋은 계절이 되었는데요, 한 주를 마무리하는 오늘도 가볍게 세 문제 함께 풀어 보시면 좋겠습니다. 오늘은 사용자의 위치에 따라 알맞은 콘텐츠를 보내는 방법, DNS 서버를 손쉽게 옮기는 방법, 그리고 데이터베이스 버전을 안전하게 올리는 방법을 다룹니다. 그럼 시작하겠습니다! 😊
문제는 세 가지 단계를 거치며 풀어가겠습니다.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 문제 풀이 시작합니다.
문제1
한 회사가 여러 Application Load Balancer 뒤에 웹사이트를 호스팅하고 있습니다. 회사는 전 세계적으로 콘텐츠에 대해 다양한 배포 권한을 가지고 있습니다. 솔루션 설계자는 배포 권한을 위반하지 않고 사용자에게 올바른 콘텐츠가 제공되도록 해야 합니다.
솔루션 설계자는 이러한 요구 사항을 충족하기 위해 어떤 구성을 선택해야 합니까?
선택지
A. AWS WAF로 Amazon CloudFront를 구성합니다.
B. AWS WAF로 Application Load Balancer 구성
C. 지리적 위치 정책으로 Amazon Route 53 구성
D. 지리 근접 라우팅 정책으로 Amazon Route 53 구성
풀이
콘텐츠 배포 권한이 국가나 지역마다 다르므로, 사용자가 어느 위치에서 접속했는지를 기준으로 알맞은 콘텐츠로 안내해야 합니다. Route 53의 지리적 위치 라우팅은 사용자의 대륙이나 국가에 따라 응답할 대상을 지정할 수 있어, 권한 범위에 맞는 Application Load Balancer로 정확히 연결할 수 있습니다.
정답 : C
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 지역별로 다른 콘텐츠 배포 권한의 준수
- 사용자 위치에 맞는 올바른 콘텐츠 제공
- 여러 Application Load Balancer로의 트래픽 분배
2. 관련 AWS 서비스 생각하기
- Amazon Route 53 : 도메인 이름을 실제 서버 주소로 바꿔 주는 DNS 서비스를 AWS가 완전관리형으로 제공하는 서비스입니다. 전 세계에 분산된 DNS 서버에서 응답하므로 가용성이 매우 높고, 같은 도메인 이름이라도 어떤 기준으로 응답할지를 정하는 다양한 라우팅 정책을 지원합니다. 라우팅 정책에 따라 사용자를 가장 가까운 리전으로 보내거나, 장애가 난 대상을 피해 다른 곳으로 보내는 등 트래픽 흐름을 DNS 단계에서 제어할 수 있습니다.
- 지리적 위치(Geolocation) 라우팅 정책 : 사용자의 DNS 질의가 시작된 위치를 대륙, 국가, 미국의 경우 주 단위로 판별해 지정한 대상으로 응답하는 정책입니다. 위치별로 응답 대상을 명확히 나눌 수 있어 국가마다 다른 언어의 콘텐츠를 제공하거나, 특정 지역에만 콘텐츠를 배포해야 할 때 활용됩니다. 어느 위치에도 해당하지 않는 사용자를 위한 기본 레코드를 함께 두는 것이 권장됩니다.
- 지리 근접(Geoproximity) 라우팅 정책 : 사용자와 리소스 사이의 지리적 거리를 기준으로 가장 가까운 대상에 연결하는 정책입니다. 바이어스 값을 조정해 특정 리소스로 향하는 트래픽의 범위를 넓히거나 좁힐 수 있어, 리전 간 부하를 조절하는 데 유용합니다. 다만 국가나 지역의 경계가 아니라 거리를 기준으로 판단하므로, 경계에 가까운 사용자는 다른 나라의 리소스로 연결될 수 있습니다.
- Amazon CloudFront : 전 세계에 분산된 엣지 로케이션에 콘텐츠를 캐싱해 사용자와 가까운 곳에서 빠르게 전달하는 콘텐츠 전송 네트워크(CDN, Content Delivery Network) 서비스입니다. 원본 서버의 부담을 줄이고 응답 속도를 높여 주며, 특정 국가의 사용자 접근을 허용하거나 차단하는 지리적 제한 기능도 제공합니다. 다만 지리적 제한은 접근을 막거나 허용하는 기능이므로, 위치에 따라 서로 다른 원본의 콘텐츠로 안내하려면 별도의 구성이 필요합니다.
- AWS WAF(Web Application Firewall) : 웹 애플리케이션으로 들어오는 HTTP 요청을 규칙에 따라 검사해 허용하거나 차단하는 웹 방화벽 서비스입니다. Amazon CloudFront나 Application Load Balancer 등과 연결해 사용하며, SQL 인젝션이나 크로스 사이트 스크립팅 같은 일반적인 공격을 막는 데 주로 쓰입니다. 요청이 시작된 국가를 기준으로 차단하는 규칙도 만들 수 있지만, 요청을 걸러내는 역할이므로 사용자를 알맞은 콘텐츠로 보내 주는 라우팅 기능은 갖고 있지 않습니다.
3. 선택지 분석하기
A. AWS WAF로 Amazon CloudFront를 구성합니다.
→ 국가별 차단은 되지만 위치에 맞는 콘텐츠로 안내하기는 어렵습니다.
B. AWS WAF로 Application Load Balancer 구성
→ 요청 허용·차단에 그쳐 지역별 콘텐츠 제공에는 적절치 않습니다.
C. 지리적 위치 정책으로 Amazon Route 53 구성
→ 사용자 국가·대륙 기준으로 권한에 맞는 대상에 연결하는 표준 방식입니다.
D. 지리 근접 라우팅 정책으로 Amazon Route 53 구성
→ 거리 기준이라 국경 부근 사용자가 권한 밖 콘텐츠로 연결될 수 있습니다.
이어서 다음 문제입니다.
문제2
회사에서 두 개의 DNS 서버를 AWS로 마이그레이션하려고 합니다. 서버는 총 약 200개 영역을 호스팅하고 매일 평균 100만 건의 요청을 받습니다. 회사는 두 서버의 관리와 관련된 운영 오버헤드를 최소화하면서 가용성을 극대화하기를 원합니다.
솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 권장해야 합니까?
선택지
A. Amazon Route 53 콘솔 가져오기 영역 파일에서 200개의 새로운 호스팅 영역을 생성합니다.
B. 단일 대형 Amazon EC2 인스턴스 가져오기 영역 파일을 시작합니다. 가동 중지 시간에 대해 회사에 알리도록 Amazon CloudWatch 경보 및 알림을 구성합니다.
C. AWS Server Migration Service(AWS SMS)를 사용하여 서버를 AWS로 마이그레이션합니다. 가동 중지 시간에 대해 회사에 알리도록 Amazon CloudWatch 경보 및 알림을 구성합니다.
D. 두 개의 가용 영역에 걸쳐 Auto Scaling 그룹에서 Amazon EC2 인스턴스를 시작합니다. 영역 파일을 가져옵니다. Auto Scaling 그룹에 대해 원하는 용량을 1로, 최대 용량을 3으로 설정합니다. CPU 사용률에 따라 조정되도록 조정 경보를 구성합니다.
풀이
DNS 서버를 직접 운영하지 않으면서 가용성을 최대로 높이는 것이 핵심입니다. Route 53은 기존 DNS 서버의 영역 파일을 가져와 호스팅 영역을 만들 수 있고, AWS가 전 세계에 분산된 DNS 인프라를 직접 관리해 주므로 서버 이중화나 패치 같은 운영 부담 없이 높은 가용성을 확보할 수 있습니다.
정답 : A
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 약 200개 DNS 영역의 AWS 이전
- DNS 서버 관리에 드는 운영 오버헤드의 최소화
- DNS 서비스 가용성의 극대화
2. 관련 AWS 서비스 생각하기
- Amazon Route 53 : 도메인 이름을 IP 주소로 변환해 주는 DNS 기능을 AWS가 완전관리형으로 제공하는 서비스입니다. 전 세계 여러 위치에 분산된 DNS 서버가 질의에 응답하므로 서버를 직접 띄우거나 이중화할 필요가 없고, AWS는 Route 53에 대해 100% 가용성을 목표로 하는 서비스 수준 협약(SLA)을 제공합니다. 질의량이 늘어나도 자동으로 처리되며, 요금은 호스팅 영역 수와 질의 수에 따라 사용한 만큼 발생합니다.
- 호스팅 영역(Hosted Zone) : 하나의 도메인과 그 하위 도메인에 대한 DNS 레코드를 담아 두는 단위입니다. 퍼블릭 호스팅 영역은 인터넷에서의 이름 조회를, 프라이빗 호스팅 영역은 VPC 내부에서의 이름 조회를 담당합니다.
- 영역 파일 가져오기 : 기존 DNS 서버에서 내보낸 BIND 형식의 영역 파일을 콘솔에서 불러와 레코드를 한 번에 만들어 주는 기능입니다. 레코드를 하나하나 다시 입력하지 않아도 되므로, 운영 중이던 DNS 영역을 빠르고 정확하게 옮길 수 있습니다.
- Amazon EC2(Elastic Compute Cloud) : 클라우드에서 원하는 사양의 가상 서버를 몇 분 만에 만들어 쓸 수 있는 컴퓨팅 서비스입니다. 운영체제와 소프트웨어를 자유롭게 설치할 수 있어 거의 모든 종류의 서버를 그대로 옮겨 실행할 수 있다는 장점이 있습니다. 다만 운영체제 패치, 소프트웨어 업데이트, 장애 대응과 이중화 구성은 사용자가 직접 책임져야 하므로, 관리형 서비스에 비해 운영 부담이 큰 편입니다.
- Amazon EC2 Auto Scaling : 미리 정한 조건에 따라 EC2 인스턴스 수를 자동으로 늘리거나 줄여 주는 서비스입니다. 여러 가용 영역(AZ)에 인스턴스를 분산하고 상태가 나빠진 인스턴스를 자동으로 교체해 애플리케이션의 가용성을 높여 줍니다. 그러나 인스턴스 안에서 실행되는 소프트웨어의 설정과 데이터 동기화는 여전히 사용자가 관리해야 하며, 새 인스턴스가 준비되기까지는 어느 정도 시간이 걸립니다.
- AWS SMS(Server Migration Service) : 온프레미스의 가상 머신을 AWS로 옮겨 EC2 인스턴스로 실행할 수 있게 도와주던 마이그레이션 서비스입니다. 서버를 통째로 복제해 옮기는 방식이라 기존 환경을 크게 바꾸지 않고 이전할 수 있었지만, 옮긴 뒤에도 서버 운영은 사용자의 몫으로 남습니다. 현재는 지원이 종료되어 AWS MGN(Application Migration Service)이 그 역할을 대신하고 있습니다.
3. 선택지 분석하기
A. Amazon Route 53 콘솔 가져오기 영역 파일에서 200개의 새로운 호스팅 영역을 생성합니다.
→ 영역 파일을 가져와 관리형 DNS로 운영하는 표준 방식입니다.
B. 단일 대형 Amazon EC2 인스턴스 가져오기 영역 파일을 시작합니다. 가동 중지 시간에 대해 회사에 알리도록 Amazon CloudWatch 경보 및 알림을 구성합니다.
→ 단일 인스턴스는 장애 시 전체가 멈출 수 있어 가용성 요구를 충족하기 어렵습니다.
C. AWS Server Migration Service(AWS SMS)를 사용하여 서버를 AWS로 마이그레이션합니다. 가동 중지 시간에 대해 회사에 알리도록 Amazon CloudWatch 경보 및 알림을 구성합니다.
→ 서버를 옮겨도 DNS 직접 운영 부담은 그대로 남아 적절치 않습니다.
D. 두 개의 가용 영역에 걸쳐 Auto Scaling 그룹에서 Amazon EC2 인스턴스를 시작합니다. 영역 파일을 가져옵니다. Auto Scaling 그룹에 대해 원하는 용량을 1로, 최대 용량을 3으로 설정합니다. CPU 사용률에 따라 조정되도록 조정 경보를 구성합니다.
→ 평소 인스턴스 1대에 운영 부담도 남아 효율적이지 않습니다.
마지막 문제 살펴보겠습니다.
문제3
한 회사가 MySQL용 Amazon RDS에서 프로덕션 데이터베이스를 실행하고 있습니다. 회사에서는 보안 규정 준수를 위해 데이터베이스 버전을 업그레이드하려고 합니다. 데이터베이스에는 중요한 데이터가 포함되어 있으므로 회사에서는 데이터 손실 없이 기능을 업그레이드하고 테스트할 수 있는 빠른 솔루션을 원합니다.
최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. RDS 수동 스냅샷을 생성합니다. MySQL용 Amazon RDS의 새 버전으로 업그레이드하세요.
B. 기본 백업 및 복원을 사용합니다. 업그레이드된 새 버전의 MySQL용 Amazon RDS로 데이터를 복원합니다.
C. AWS Database Migration Service(AWS DMS)를 사용하여 업그레이드된 새 버전의 MySQL용 Amazon RDS에 데이터를 복제합니다.
D. Amazon RDS 블루/그린 배포를 사용하여 프로덕션 변경 사항을 배포하고 테스트합니다.
풀이
운영 중인 데이터베이스를 건드리지 않고 새 버전을 미리 시험해 본 뒤, 데이터 손실 없이 빠르게 전환하는 방법이 필요합니다. RDS 블루/그린 배포는 프로덕션과 동기화되는 별도 환경에서 업그레이드와 테스트를 마친 뒤 짧은 시간 안에 전환할 수 있고, 엔드포인트도 그대로 유지되어 요구를 가장 간단히 충족합니다.
정답 : D
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 보안 규정 준수를 위한 데이터베이스 버전 업그레이드
- 업그레이드 과정에서의 데이터 손실 방지
- 프로덕션 반영 전 새 버전의 기능 테스트
- 최소한의 운영 오버헤드로 빠른 전환
2. 관련 AWS 서비스 생각하기
- Amazon RDS(Relational Database Service) : MySQL, PostgreSQL 같은 관계형 데이터베이스를 AWS가 대신 설치하고 운영해 주는 관리형 데이터베이스 서비스입니다. 하드웨어 준비, 운영체제 패치, 백업, 장애 조치 같은 번거로운 관리 작업을 AWS가 맡아 주므로 사용자는 데이터와 애플리케이션에 집중할 수 있습니다. 데이터베이스 엔진 버전 업그레이드도 콘솔에서 몇 번의 선택으로 진행할 수 있으며, 업그레이드 방식에 따라 서비스 중단 시간과 위험도가 달라집니다.
- 블루/그린 배포(Blue/Green Deployments) : 현재 운영 중인 블루 환경을 그대로 복제해 그린 환경이라는 스테이징 환경을 만들고, 블루 환경의 변경 사항을 그린 환경으로 계속 복제해 두 환경의 데이터를 맞춰 주는 기능입니다. 그린 환경에서 엔진 버전 업그레이드나 설정 변경을 적용하고 충분히 테스트한 뒤, 준비가 되면 전환을 실행해 그린 환경을 새 프로덕션으로 승격합니다. 전환 과정에서는 복제가 따라잡았는지 등을 확인하는 보호 장치가 작동하고, 엔드포인트 이름이 그대로 유지되어 애플리케이션을 수정할 필요가 없습니다. 전환은 일반적으로 1분 이내에 완료됩니다.
- 스냅샷 : 특정 시점의 데이터베이스 상태를 통째로 저장해 두는 백업입니다. 업그레이드 전에 수동 스냅샷을 만들어 두면 문제가 생겼을 때 이전 상태로 복원할 수 있지만, 스냅샷 이후에 들어온 데이터는 복원 시 포함되지 않습니다.
- AWS DMS(Database Migration Service) : 원본 데이터베이스를 운영하면서 다른 데이터베이스로 데이터를 옮기고, 변경 사항을 계속 복제해 주는 마이그레이션 서비스입니다. 같은 엔진 사이는 물론 서로 다른 엔진 사이의 이전도 지원해 데이터베이스 이전 작업에 널리 쓰입니다. 다만 복제 인스턴스와 엔드포인트, 작업을 직접 구성하고 관리해야 하며, 전환 시점에는 애플리케이션의 연결 대상을 바꿔 주는 작업도 별도로 필요합니다.
3. 선택지 분석하기
A. RDS 수동 스냅샷을 생성합니다. MySQL용 Amazon RDS의 새 버전으로 업그레이드하세요.
→ 사전 테스트가 어렵고 롤백 시 이후 데이터가 사라질 수 있습니다.
B. 기본 백업 및 복원을 사용합니다. 업그레이드된 새 버전의 MySQL용 Amazon RDS로 데이터를 복원합니다.
→ 백업 이후 변경분이 빠지고 수작업이 많아 빠른 방안이 되기 어렵습니다.
C. AWS Database Migration Service(AWS DMS)를 사용하여 업그레이드된 새 버전의 MySQL용 Amazon RDS에 데이터를 복제합니다.
→ 복제 구성과 연결 전환을 직접 관리해야 해 운영 부담이 큽니다.
D. Amazon RDS 블루/그린 배포를 사용하여 프로덕션 변경 사항을 배포하고 테스트합니다.
→ 동기화된 환경에서 테스트 후 손실 없이 빠르게 전환하는 표준 방식입니다.
오늘 세 문제는 모두 "직접 운영하는 대신 AWS가 제공하는 기능을 얼마나 잘 활용하는가"로 정리할 수 있습니다. 첫 번째 문제에서는 Route 53의 지리적 위치 라우팅과 지리 근접 라우팅의 차이를, 두 번째 문제에서는 DNS 서버를 직접 띄우는 것보다 관리형 DNS가 운영과 가용성 면에서 유리하다는 점을 기억해 두시면 좋겠습니다. 세 번째 문제의 블루/그린 배포는 데이터베이스 업그레이드 문제에서 자주 등장하니 스냅샷, DMS와 어떻게 다른지 나란히 비교해 보세요. 선선한 가을 주말, 푹 쉬시고 다음 주에 또 만나요! 😊
'AWS > SAA 준비' 카테고리의 다른 글
| AWS SAA 합격으로 가는 길 #212 (0) | 2026.10.09 |
|---|---|
| AWS SAA 합격으로 가는 길 #211 (0) | 2026.10.05 |
| AWS SAA 합격으로 가는 길 #209 (0) | 2026.09.28 |
| AWS SAA 합격으로 가는 길 #208 (0) | 2026.09.25 |
| AWS SAA 합격으로 가는 길 #207 (0) | 2026.09.21 |