AWS 자격증이 실무에서 쓰이나요? : AWS SA-Professional 1

AWS 자격증이 실무에서 쓰이나요? : AWS Solutions Architect - Professional (SAP) Certification 1

Written by Minhyeok Cha

오늘은 AWS 자격증 중 Solutions Architect - Professional(SAP) 의 시험 문제가 실제 콘솔에서 또는 아키텍처 구조 형식이 어떤지 정리해 보았습니다.

---

문제 1.

회사는 하이브리드 DNS 솔루션을 설계해야 합니다. 이 솔루션은 VPC 내에 저장된 리소스에 대해 cloud.example.com 도메인에 대한 Amazon Route 53 프라이빗 호스팅 영역을 사용합니다.

회사에는 다음과 같은 DNS 확인 요구 사항이 있습니다.

• 온프레미스 시스템은 cloud.example.com을 확인하고 연결할 수 있어야 합니다.

• 모든 VPC는 cloud.example.com을 확인할 수 있어야 합니다.

• 온프레미스 기업 네트워크와 AWS Transit Gateway 간에는 이미 AWS Direct Connect 연결이 있습니다.

최고의 성능으로 이러한 요구 사항을 충족하려면 회사에서 어떤 아키텍처를 사용해야 합니까?

ⓐ프라이빗 호스팅 영역을 모든 VPC에 연결합니다. 공유 서비스 VPC에서 Route 53 인바운드 해석기를 생성합니다. 모든 VPC를 전송 게이트웨이에 연결하고 인바운드 확인자를 가리키는 cloud.example.com에 대한 온프레미스 DNS 서버에서 전달 규칙을 생성합니다.

ⓑ 프라이빗 호스팅 영역을 모든 VPC에 연결합니다. 공유 서비스 VPC에 Amazon EC2 조건부 전달자를 배포합니다. 모든 VPC를 전송 게이트웨이에 연결하고 조건부 전달자를 가리키는 cloud.example.com에 대한 온프레미스 DNS 서버에서 전달 규칙을 생성합니다.

ⓒ 프라이빗 호스팅 영역을 공유 서비스 VPC에 연결합니다. 공유 서비스 VP에서 Route 53 아웃바운드 해석기를 생성합니다. 모든 VPC를 전송 게이트웨이에 연결하고 아웃바운드를 가리키는 cloud.example.com에 대한 온프레미스 DNS 서버에서 전달 규칙을 생성합니다.

ⓓ 프라이빗 호스팅 영역을 공유 서비스 VPC에 연결합니다. 공유 서비스 VPC에서 Route 53 인바운드 해석기를 생성합니다. 공유 서비스 VPC를 전송 게이트웨이에 연결하고 인바운드 확인자를 가리키는 cloud.example.com에 대한 온프레미스 DNS 서버에서 전달 규칙을 생성합니다.

풀이

이 문제의 핵심은 결국 하이브리드 클라우드를 AWS 서비스로 중앙 집중식 DNS 관리를 어떻게 하느냐에 대한 문제입니다. 그리고 회사 측의 요구 조건을 결합하면 정답은 A가 되겠습니다. 이를 한번 하나씩 살펴보며 풀어보겠습니다.

정답 A

문제의 DNS 요구 사항 부분을 하나씩 파헤쳐 보면

첫 번째로 프라이빗 호스팅 영역을 모든 VPC에 연결하는 것은 다음과 같은 구성입니다.

이런 식의 설정을 통해 프라이빗 호스팅이라도 직접 VPC와 연결하여 트래픽을 라우팅하도록 설정합니다.

위에 파란 박스로 확인할 수 있듯 해당 기능을 사용하려면 VPC설정에서 enableDnsHostnames 및 enableDnsSupport 를 true로 설정해야 합니다.

두 번째는 Direct Connect 연결 또는 VPN을 통해 인바운드 해석기 엔드포인트 IP 주소에 연결하는 작업입니다. 이를 통해 온프레미스에서도 cloud.example.com을 확인하고 연결할 수 있게 됩니다.

이때 DX와 VPN이 작업 되었다는 가정하에 Route 53 resolver의 엔드포인트를 구현할 경우 다음과 같은 아키텍처가 완성됩니다.

위의 문제를 딴 아키텍처로는 다음과 같이 만들 수 있겠으며 각 인바운드, 아웃바운드 엔드포인트(VPC 지정)를 지정하고 지정된 엔드포인트에 대한 VPC Route53 프라이빗 호스팅 영역을 생성해야 하는데 이때 사용하는 것이 첫 번째 방법입니다.

해당 작업을 끝마침으로써 모든 VPC(따로 지정은 해줘야 하지만 모든 VPC를 지정함으로써 클리어)의 도메인 확인과 온프레미스에서의 확인 또한 AWS Transit Gateway와 DX(혹은 VPN)을 통해 연결함으로써 도메인 확인이 가능한 것을 확인할 수 있습니다.

※ 참고

다음 명령어를 통해 간단하게 연결된 도메인을 확인할 수 있습니다.

telnet 명령을 사용한 포트 53의 인바운드 엔드포인트 해석기 IP 주소 간의 연결 확인

• telnet <inbound endpoint resolver IP address> 53.

도메인 확인의 유효성을 확인하려면 온프레미스 DNS 서버 또는 로컬 호스트에서 도메인 이름 조회를 완료합니다.

• Windows의 경우: nslookup <private hosted zone domain name>

• Linux 또는 macOS의 경우: dig <private hosted zone domain name>

이전 명령으로 레코드를 반환하지 못하면 온프레미스 DNS 서버를 우회할 수 있습니다. 다음 명령을 사용하여 인바운드 해석기 엔드포인트 IP 주소로 직접 DNS 쿼리를 보냅니다.

• Windows의 경우: nslookup <프라이빗 호스팅 영역 도메인 이름> @ <인바운드 엔드포인트 IP 주소>

• Linux 또는 macOS의 경우: dig <프라이빗 호스팅 영역 도메인 이름> @ <인바운드 엔드포인트 IP 주소>

---

문제 2

한 회사가 REST 기반 API를 통해 여러 고객에게 날씨 데이터를 제공하고 있습니다. API는 Amazon API Gateway에서 호스팅되며 각 API 작업에 대해 다양한 AWS Lambda 함수와 통합됩니다. 이 회사는 DNS에 Amazon Route 53을 사용하고 Weather.example.com이라는 리소스 레코드를 생성했습니다. 회사는 API에 대한 데이터를 Amazon DynamoDB 테이블에 저장합니다. 회사에는 API에 다른 AWS 리전으로 장애 조치할 수 있는 기능을 제공하는 솔루션이 필요합니다.

어떤 솔루션이 이러한 요구 사항을 충족합니까?

ⓐ 새 지역에 새로운 Lambda 함수 세트를 배포합니다. 두 리전의 Lambda 함수를 대상으로 하여 엣지 최적화 API 엔드포인트를 사용하도록 API Gateway API를 업데이트합니다. DynamoDB 테이블을 전역 테이블로 변환합니다.

ⓑ 다른 지역에 새로운 API Gateway API 및 Lambda 함수를 배포합니다. Route 53 DNS 레코드를 다중값 응답으로 변경합니다. 답변에 두 API 게이트웨이 API를 모두 추가합니다. 대상 상태 모니터링을 활성화합니다. DynamoDB 테이블을 전역 테이블로 변환합니다.

ⓒ 다른 지역에 새로운 API Gateway API 및 Lambda 함수를 배포합니다. Route 53 DNS 레코드를 장애 조치 레코드로 변경합니다. 대상 상태 모니터링을 활성화합니다. DynamoDB 테이블을 전역 테이블로 변환합니다.

ⓓ 새 지역에 새 API 게이트웨이 API를 배포합니다. Lambda 함수를 전역 함수로 변경합니다. Route 53 DNS 레코드를 다중값 응답으로 변경합니다. 답변에 두 API 게이트웨이 API를 모두 추가합니다. 대상 상태 모니터링을 활성화합니다. DynamoDB 테이블을 전역 테이블로 변환합니다.

풀이

문제 2번은 AWS에서 자주 쓰는 서비스의 연동 API Gateway - Lambda - DynamoDB 조합이며 DNS로는 Route 53 서비스의 레코드를 생성하여 사용 중에 있습니다.

이번 문제는 위의 서비스 조합으로 사용 중에 있으나 API가 다른 리전으로의 장애가 발생할 경우 조치 가능한 조합을 찾고 있습니다.

고객 니즈에 장애 조치가 있으니 보기 C에 있는 “Route 53 DNS 레코드를 장애 조치 레코드로 변경합니다.”만 보시고 정답이라고 생각하신 분들이 있으실 겁니다.

그런데 의외로 반전(?)인 부분이 정답은 C가 맞습니다.

정답 C

일단 DNS를 사용하는 데 있어서 장애가 발생하는 경우 다른 리전으로 장애를 조치하는 방법을 구사하려면 다음과 같은 구성이 필요합니다.

1. 메인이 되는 리전에 API 리소스 생성 (도메인)

2. 서브로 되는 리전에 API 리소스 생성 (도메인)

3. 위에 생성한 API를 사용자 지정 도메인에 매핑

4. Route 53 DNS 장애 조치 레코드 생성

뿐만 아니라 문제를 계속 읽어보면 상태 모니터링 활성 및 DynamoDB 글로벌 테이블까지 있습니다.

여기까지 완성하면 다음과 같은 아키텍처로 만들 수 있습니다.

사실 이 문제는 장애 발생 대비를 위한 솔루션만 구축하면 되지만 이번엔 API 설계부터 같이 풀어가도록 하겠습니다.

1. 메인과 서브가 될 API를 생성합니다. (리전은 별도로 하여 구성)

API Gateway만 만드는 건 간단하나 우리가 필요한 건 도메인 이름입니다. 그리고 AWS API G/W에는 커스텀 도메인 생성이 있습니다.

만드는 건 쉬우나 사진과 같이 TLS 즉 ACM 인증서가 필요하니 참고하시면 됩니다.

각 리전마다 필요한 작업이니 서브가 될 리전에도 같은 작업을 하시면 됩니다.

2. Route 53 상태 검사 생성

위에서 만든 API 메인 리전 도메인을 여기에 먼저 사용합니다.

이 상태 검사에서 장애가 발생하면 서브 리전으로 스위칭 되도록 하는 알람을 구성하는 단계입니다.

3. 라우팅 정책 - 장애 조치 구성

이 단계는 Route 53에는 다양한 레코드 정책 방식이 있다는 걸 알고 있어야 합니다.

다양한 정책 방식이 있지만 그중 우리가 확인할 방식은 장애 조치 방식입니다.

메인이 되는 리전 - 각 생성한 API 도메인 - 레코드 유형에서 바라보는 기본(메인 리전)과 보조(서브 리전)를 사용하여 레코드를 추가만 하시면 완성입니다.

4. DynamoDB Global table

DB는 글로벌 테이블 복제본 생성하는 란이 따로 있으니 간단하게 찾으실 수 있습니다.

마무리

오늘 풀어본 문제들이 여러분의 자격증 준비에 도움이 되었길 바랍니다. 다음 게시글에서는 더 깊이 있는 문제 해설과 핵심 전략들을 공유할 예정이니 많이 기대해 주세요! 또한, 풀이에 대해 궁금하다거나 틀린 부분이 있는 경우 언제든지 partner@smileshark.kr로 연락 주시기 바랍니다.