Amazon AWS Certified SA - Associate 1~5번

1. 솔루션 아키텍트는 사용자가 기본 웹사이트가 사용 불가능한 경우 백업 정적 오류 페이지로 연결되는 솔루션을 설계하고 있다. 기본 웹사이트의 DNS 레코드는 Amazon Route 53에서 호스팅되며, 도메인은 Application Load Balancer (ALB)를 가리키고 있다. 솔루션 아키텍트가 회사의 요구 사항을 충족시키면서 변경 사항과 인프라 오버헤드를 최소화하기 위해 어떤 구성을 사용해야 하는가?

 

A. Route 53 별칭 레코드를 ALB를 원천 중 하나로 가진 Amazon CloudFront 배포로 가리키게 한다. 그런 다음 배포를 위한 사용자 정의 오류 페이지를 생성한다.

 

B. Route 53 액티브-패시브 장애 조치(failover) 구성을 설정한다. Route 53 건강 검사가 ALB 엔드포인트가 비정상임을 확인할 경우 Amazon S3 버킷 내에 호스팅된 정적 오류 페이지로 트래픽을 전송한다.

 

C. Route 53 레코드를 지연 기반 라우팅 정책을 사용하도록 업데이트한다. Amazon S3 버킷 내에 호스팅된 백업 정적 오류 페이지를 레코드에 추가하여 트래픽이 가장 반응이 빠른 엔드포인트로 전송된다.

 

D. ALB와 정적 오류 페이지를 호스팅하는 Amazon EC2 인스턴스를 엔드포인트로 가진 Route 53 액티브-액티브 구성을 설정한다. Route 53은 ALB에 대한 건강 검사가 실패할 경우에만 인스턴스로 요청을 보낸다.

 

해설

A. 이 옵션은 Amazon CloudFront 배포를 사용하여 ALB를 원천으로 설정하고 사용자 정의 오류 페이지를 생성하는 방법입니다. 그러나 이것은 최소한의 변경과 인프라 오버헤드를 유지하면서 요구 사항을 충족시키기 위한 최적의 선택은 아닙니다. 이 옵션은 Amazon CloudFront를 사용해 웹 사이트를 제공하고, 사용자 정의 오류 페이지를 만드는 방법입니다. 그러나 이 방법은 요구 사항을 충족시키기 위해 더 많은 변경과 추가 인프라가 필요하므로 최적의 선택이 아닙니다. B. 이 옵션은 Route 53에서 액티브-패시브 장애 조치를 설정하여 ALB 엔드포인트가 비정상인 경우 Amazon S3 버킷에 호스팅된 정적 오류 페이지로 트래픽을 전송하는 방법입니다. 이것은 최소한의 변경과 인프라 오버헤드를 유지하면서 요구 사항을 충족시키는 방법이므로, 이 선택지는 좋은 해결책입니다. 이 옵션은 Route 53에서 웹 사이트가 작동하지 않을 때 S3 버킷의 정적 오류 페이지로 트래픽을 전송하는 방법입니다. 이 방법은 변경과 인프라 오버헤드를 최소화하면서 요구 사항을 충족시키기 때문에 좋은 해결책입니다. C. 이 옵션은 Route 53 레코드를 지연 기반 라우팅 정책을 사용하도록 업데이트하고 Amazon S3 버킷에 호스팅된 백업 정적 오류 페이지를 추가하는 방법입니다. 그러나 이 구성은 오류 페이지에 대한 트래픽을 라우팅하는 것이 아니라, 가장 반응이 빠른 엔드포인트로 트래픽을 전송하므로 요구 사항을 충족시키지 않습니다. 이 옵션은 Route 53에서 트래픽을 가장 빠른 엔드포인트로 전송하는 방법입니다. 그러나 이 방법은 오류 페이지를 표시하는 것이 아니기 때문에 요구 사항을 충족시키지 않습니다. D. 이 옵션은 Route 53의 액티브-액티브 구성을 사용하여 ALB와 정적 오류 페이지를 호스팅하는 Amazon EC2 인스턴스를 엔드포인트로 설정하는 방법입니다. 그러나 이 구성은 ALB에 대한 건강 검사가 실패할 경우에만 인스턴스로 요청을 보내므로, 추가 인프라 오버헤드가 발생하고 변경이 더 필요합니다. 이 옵션은 Route 53에서 웹 사이트가 작동하지 않을 때 EC2 인스턴스의 정적 오류 페이지로 트래픽을 전송하는 방법입니다. 그러나 이 방법은 추가 인프라가 필요하고 더 많은 변경을 필요로 하므로 최적의 선택이 아닙니다. 결론적으로, 옵션 B가 회사의 요구 사항을 충족시키면서 변경 사항과 인프라 오버헤드를 최소화하는 데 가장 적합한 구성입니다. 이 구성은 Route 53 액티브-패시브 장애 조치를 설정하여 ALB 엔드포인트가 비정상인 경우 Amazon S3 버킷에 호스팅된 정적 오류 페이지로 트래픽을 전송하게 됩니다.

1. DNS 레코드는 무엇이고 Route53에 호스팅 한다는 것은 무엇인가요? DNS 레코드는 도메인 이름 시스템 (DNS)에서 도메인 이름을 IP 주소로 변환하는 데 사용되는 정보입니다. DNS 레코드는 여러 유형이 있으며, 웹 사이트, 이메일 서버, 데이터베이스 서버 등의 호스트에 대한 네트워크 정보를 제공합니다. Route 53은 아마존 웹 서비스 (AWS)에서 제공하는 클라우드 기반의 도메인 이름 시스템 (DNS) 웹 서비스입니다. Route 53에 DNS 레코드를 호스팅한다는 것은 해당 DNS 레코드가 Route 53 서비스에서 관리되고 저장되어, 웹 사이트나 서비스에 대한 접근을 가능하게 하는 것을 의미합니다. 2. 인프라 오버헤드를 최소화 한다는 것은 무엇입니까? 인프라 오버헤드를 최소화한다는 것은 인프라 관련 비용, 복잡성, 관리 노력 등을 줄이는 것을 의미합니다. 이는 불필요한 서비스나 리소스를 줄여, 전체 시스템의 효율성과 성능을 향상시키는 것을 목표로 합니다. 인프라 오버헤드를 최소화하면, 비용 절감뿐만 아니라 시스템의 안정성과 유지 관리 용이성도 향상됩니다. 3. 액티브_패시브 장애조치란? 액티브-패시브 장애조치란 하나의 시스템(액티브)이 작동 중일 때 다른 시스템(패시브)이 대기 상태에 있고, 액티브 시스템에 문제가 발생하면 패시브 시스템이 작동하여 서비스가 중단되지 않도록 하는 방식입니다. 이 구성에서 패시브 시스템은 일반적으로 액티브 시스템의 백업 역할을 하며, 액티브 시스템에 문제가 발생하면 자동으로 작동하여 서비스를 계속 제공합니다. 4. ALB 엔드포인트란? ALB 엔드포인트란 Application Load Balancer의 액세스 가능한 인터넷 주소를 의미합니다. 사용자는 이 주소를 통해 ALB에 연결하고, ALB는 요청을 적절한 대상(예: EC2 인스턴스)으로 분배합니다. ALB 엔드포인트는 사용자의 웹 사이트나 애플리케이션에 대한 트래픽을 처리하는 데 사용됩니다. 5. S3 버킷의 정적 오류 페이지로 트래픽을 전송하는 이유는? S3 버킷의 정적 오류 페이지로 트래픽을 전송하는 이유는 기본 웹 사이트가 작동하지 않을 때 사용자에게 오류 메시지를 안내하기 위함입니다. 이 방식으로 사용자는 웹 사이트나 애플리케이션에 일시적인 문제가 발생했음을 인지할 수 있으며, 서비스 제공자는 최소한의 인프라 변경으로 이러한 안내를 제공할 수 있습니다. 6. Route 53 레코드란? Route 53 레코드는 도메인 이름 시스템(DNS)의 일부로, 도메인 이름(예: example.com)을 IP 주소 또는 다른 리소스로 매핑하는 데 사용되는 항목입니다. Route 53에서 DNS 레코드를 관리하면 사용자는 웹 사이트, 이메일 서버, 데이터베이스 서버 등의 호스트에 대한 네트워크 정보를 제공할 수 있습니다. 7. 액티브-액티브 구성이란? 액티브-액티브 구성이란 두 개 이상의 시스템이 동시에 작동하며, 각 시스템이 일부 트래픽을 처리하는 방식입니다. 이 구성은 시스템의 가용성과 부하 분산을 개선할 수 있으며, 한 시스템에 문제가 발생하더라도 다른 시스템이 계속 작동하여 서비스가 중단되지 않습니다. 이러한 구성은 고가용성 및 트래픽을 요구하는 시나리오에서 유용합니다. 액티브-액티브 구성에서 각 시스템은 일종의 동시 백업 역할을 하며, 한 시스템에 문제가 발생할 경우 나머지 시스템이 서비스를 지속적으로 제공할 수 있습니다. 이 방식은 시스템 전체의 안정성을 높이고, 문제 발생 시 자동으로 조치를 취할 수 있는 높은 유연성을 제공합니다. 그러나 이러한 구성은 일반적으로 추가 인프라 및 관리 노력이 필요합니다.

---

2. 한 솔루션 설계자가 Amazon EC2에서 고성능 컴퓨팅(HPC) 워크로드를 설계하고 있습니다. EC2 인스턴스는 서로 자주 통신해야 하며 지연 시간이 짧고 처리량이 높은 네트워크 성능이 필요합니다. 이러한 요구 사항을 충족하는 EC2 구성은 무엇입니까?

 

A. 하나의 가용성 영역에 있는 클러스터 배치 그룹에서 EC2 인스턴스를 시작합니다.

B. 하나의 가용 영역에 있는 분산 배치 그룹에서 EC2 인스턴스를 시작합니다.

C. 두 리전의 자동 확장 그룹에서 EC2 인스턴스를 시작하고 VPC를 피어링합니다.

D. 여러 가용 영역에 걸`쳐 있는 자동 스케일링 그룹에서 EC2 인스턴스를 시작합니다.

 

해설

A 옵션은 고성능 컴퓨팅(HPC) 워크로드에 필요한 낮은 지연 시간과 높은 처리량을 제공하는 Amazon EC2 인스턴스 구성을 제안합니다. 클러스터 플레이스먼트 그룹은 한 가용 영역 내에서 물리적으로 서로 가까운 위치에 인스턴스를 시작합니다. 이렇게 함으로써 인스턴스 간의 통신이 빠르고 효율적이므로, 낮은 지연 시간과 높은 처리량을 달성할 수 있습니다. 따라서 이 옵션은 요구 사항을 충족하는 EC2 구성입니다. B, C, D 옵션은 HPC 워크로드에 필요한 낮은 지연 시간과 높은 처리량을 제공하지 못합니다. 이들 옵션은 인스턴스 간의 거리가 더 멀거나 다른 가용 영역이나 리전에 분산되어 있어, 인스턴스 간 통신에 더 많은 지연 시간이 발생할 수 있습니다. 이러한 구성은 HPC 워크로드에 적합하지 않습니다. A. 정답입니다. 한 가용 영역에서 클러스터 플레이스먼트 그룹으로 인스턴스를 시작하면, 인스턴스들이 물리적으로 가까이 위치하게 되어 인스턴스 간의 통신이 빠르게 이루어집니다. 따라서, HPC 워크로드에 필요한 낮은 지연 시간과 높은 처리량을 제공할 수 있습니다. B. 틀린 이유: 스프레드 플레이스먼트 그룹은 가용 영역 내에서 인스턴스를 분산시키기 때문에, 인스턴스 간의 통신이 상대적으로 느려집니다. 이로 인해 낮은 지연 시간과 높은 처리량이 요구되는 HPC 워크로드에 적합하지 않습니다. C. 틀린 이유: 두 개의 리전에서 오토 스케일링 그룹으로 인스턴스를 시작하고 VPC를 피어링하면, 인스턴스들이 리전 간에 분산되어 통신 지연 시간이 크게 증가합니다. 이 구성은 HPC 워크로드에 필요한 낮은 지연 시간과 높은 처리량을 제공하지 못합니다. D. 틀린 이유: 여러 가용 영역에 걸쳐 오토 스케일링 그룹으로 인스턴스를 시작하면, 인스턴스 간의 거리가 멀어져 통신 지연 시간이 증가할 수 있습니다. 이러한 구성은 HPC 워크로드에 필요한 낮은 지연 시간과 높은 처리량을 제공하지 못합니다. 요약하면, 옵션 A는 인스턴스 간의 거리를 최소화하여 HPC 워크로드에 필요한 빠른 통신과 낮은 지연 시간을 제공합니다. 반면, 옵션 B, C, D는 인스턴스 간의 거리가 더 멀거나 다른 가용 영역이나 리전에 분산되어 있어, 인스턴스 간 통신에 더 많은 지연 시간이 발생할 수 있으며 HPC 워크로드에 적합하지 않습니다.

1. 고성능 컴퓨팅(HPC) 워크로드란? 고성능 컴퓨팅(HPC) 워크로드란 많은 양의 데이터를 처리하거나 복잡한 계산을 수행해야 하는 애플리케이션을 위한 컴퓨팅 작업입니다. HPC 워크로드는 과학, 공학, 금융, 의학 등 다양한 분야에서 사용되며, 대규모 시뮬레이션, 예측 모델링, 빅 데이터 분석 등의 작업을 처리할 수 있습니다. 2. EC2와 EC2 인스턴스란? EC2는 Amazon Elastic Compute Cloud의 약자로, AWS에서 제공하는 가상 서버 호스팅 서비스입니다. 사용자는 EC2를 사용하여 다양한 용도의 가상 서버(인스턴스)를 실행할 수 있습니다. EC2 인스턴스란 EC2 서비스에서 실행되는 가상 서버를 의미하며, 원하는 운영 체제와 소프트웨어를 설치하고 구성하여 사용할 수 있습니다.