[AWS - SAA] 개념정리 및 문제풀이 10일차

개념정리

 

AWS Global Accelerator

• 개념 : AWS에서 제공하는 네트워크 서비스로, 전 세계적으로 분산된 애플리케이션을 사용하는 사용자에게 빠르고 일관된 성능을 제공합니다. Global Accelerator는 지연 시간을 최소화하고 애플리케이션의 가용성을 높이는 데 초점을 맞춘 서비스로, 이를 통해 인터넷 트래픽을 최적의 경로로 전달할 수 있습니다.
• 주요 특징:
  • 1. 전 세계적으로 트래픽 라우팅:
    • AWS Global Accelerator는 사용자의 위치에 따라 가장 가까운 AWS 글로벌 네트워크 엣지 로케이션으로 트래픽을 라우팅합니다. 이를 통해 인터넷의 공용 경로를 우회하고, AWS의 글로벌 전용 네트워크로 트래픽을 전송하여 지연 시간을 줄입니다.
  • 2. 고정된 Anycast IP 주소:
    • Global Accelerator는 애플리케이션의 여러 AWS 리전에서 고정된 Anycast IP 주소를 제공합니다. 사용자는 해당 IP 주소로 요청을 보내면, AWS Global Accelerator가 사용자의 위치에 따라 최적의 리전으로 트래픽을 라우팅합니다. 이 방식은 네트워크 변동성에 영향을 받지 않으며, 고가용성을 유지하는 데 도움이 됩니다.
  • 3. 지연 시간 최소화:
    • Global Accelerator는 사용자가 트래픽을 보낼 때 가장 짧은 지연 시간을 제공하는 경로를 선택합니다. 글로벌 네트워크를 활용해 AWS 네트워크로 트래픽을 전송하고, 지리적으로 가까운 AWS 리전으로 연결되도록 하여 응답 시간을 최적화합니다.
  • 4. 트래픽 관리 및 자동 장애 조치:
    • Global Accelerator는 여러 AWS 리전에서 실행 중인 애플리케이션을 모니터링하고, 장애가 발생하면 자동으로 다른 리전으로 트래픽을 리디렉션합니다. 이를 통해 애플리케이션의 가용성을 높일 수 있습니다. 리전의 가용 영역이 손상되었을 때도 사용자가 중단 없이 서비스를 이용할 수 있도록 합니다.
  • 5. AWS 서비스와의 통합:
    • Global Accelerator는 Application Load Balancer(ALB), Network Load Balancer(NLB), EC2 인스턴스, Elastic IP 등 다양한 AWS 서비스와 통합될 수 있습니다. 이를 통해 로드 밸런싱 및 트래픽 분산과 같은 기능을 제공하여 애플리케이션 성능을 최적화합니다.
  • 6. 트래픽 제어 기능:
    • Global Accelerator는 트래픽 가중치 제어를 제공하여 트래픽이 특정 AWS 리전으로 더 많이 분산되도록 설정할 수 있습니다. 또한 트래픽 용량을 조정하여 특정 리전에 더 많은 요청을 보내거나, 장애 발생 시 다른 리전으로 트래픽을 유연하게 이동시킬 수 있습니다.
• 사용 사례:
  • 게임 서버: 전 세계 사용자들이 이용하는 멀티플레이어 게임 서버에서 Global Accelerator를 사용하면, 각 사용자에게 가장 가까운 서버로 트래픽이 자동으로 라우팅되어 최저 지연 시간을 제공할 수 있습니다.
  • 미디어 스트리밍: 글로벌 사용자에게 동영상 콘텐츠를 제공할 때, 트래픽이 최적의 경로로 전송되어 끊김 없는 스트리밍 경험을 제공합니다.
  • 글로벌 애플리케이션: 여러 리전에 분산된 애플리케이션을 사용하는 환경에서 Global Accelerator는 트래픽을 최적의 리전으로 자동으로 라우팅하여 지연 시간을 줄이고 장애 복구 기능을 제공합니다.

Amazon Inspector

• 개념 : 주로 보안 취약점을 탐지하고 자동으로 애플리케이션과 인프라를 평가하는 서비스입니다. 이 서비스는 AWS에서 실행되는 애플리케이션이 보안 모범 사례를 준수하고 있는지, 취약점이 없는지를 검사하는 데 사용됩니다.
• 주요 기능:
  • 취약점 분석: Inspector는 인프라의 보안 취약점을 찾아내고 보고서를 생성합니다. 특히, EC2 인스턴스와 컨테이너 이미지의 보안 취약점과 잘못된 설정을 분석합니다.
  • CVE(Common Vulnerabilities and Exposures) 기반 평가: 알려진 취약점 목록인 CVE 데이터베이스와 비교하여 시스템의 취약점을 평가합니다.
  • 보안 규정 준수 검사: AWS 환경에서 보안 모범 사례와의 차이를 검사하여 잘못된 설정이나 보안 약점을 찾아냅니다.
  • 자동화된 평가: 주기적으로 보안 평가를 자동으로 수행하며, 새로운 취약점이 발견되면 즉시 알림을 제공합니다.
• 활용 사례:
  • AWS 환경에서 취약점을 자동으로 평가하고, 지속적으로 애플리케이션 보안성을 개선하려는 경우.
  • AWS 인프라를 PCI-DSS, GDPR 등 보안 표준에 맞게 유지하려는 기업에서 사용됩니다.

Amazon QuickSight

• 개념 : 비즈니스 인텔리전스(BI) 도구로, 다양한 데이터 소스를 시각화하고 분석하는 데 사용됩니다. 데이터를 직관적으로 대시보드로 표현하여 경영진이 데이터 기반 의사 결정을 내릴 수 있도록 지원합니다.
• 주요 기능:
  • 데이터 시각화: 다양한 차트, 그래프, 지도 등을 통해 데이터를 시각적으로 표현합니다.
  • 자동 ML Insights: 기계 학습(ML)을 기반으로 자동으로 데이터를 분석하고 이상 징후나 패턴을 감지합니다.
  • 대화형 대시보드: 실시간 데이터 업데이트와 상호작용이 가능한 대시보드를 제공하여 사용자가 데이터를 직접 분석할 수 있습니다
  • 다양한 데이터 소스 연동: S3, Redshift, RDS, Athena 등 여러 AWS 서비스와의 원활한 통합이 가능합니다.
  • 서버리스: QuickSight는 서버리스 방식으로 제공되어, 사용자는 인프라 관리 없이 대규모 데이터 분석을 할 수 있습니다.
• 활용 사례:
  • 경영진이 실시간 데이터 시각화를 통해 데이터 기반 의사결정을 할 때.
  • 기업에서 운영 데이터를 시각화하여 성과를 모니터링하거나, 마케팅, 재무 데이터 등을 분석할 때.

Amazon GuardDuty

• 개념 : AWS 계정에서 위협 탐지를 자동화하는 서비스로, 악의적인 활동이나 비정상적인 트래픽을 탐지하는 데 사용됩니다. GuardDuty는 네트워크 트래픽을 모니터링하여 AWS 계정에서 발생할 수 있는 보안 위험을 자동으로 감지합니다.
• 주요 기능:
  • 위협 탐지: GuardDuty는 AWS 환경에서 비정상적이거나 악의적인 활동을 탐지합니다. 예를 들어, 외부로부터 의심스러운 IP 주소가 EC2 인스턴스에 접근하려고 하거나 데이터 유출이 의심되는 트래픽을 감지할 수 있습니다.
  • 자동화된 보안 모니터링: 보안 이벤트를 실시간으로 감시하고, 위험이 감지되면 즉시 경고를 생성합니다.
  • 위협 인텔리전스 통합: AWS 보안 데이터와 외부 위협 인텔리전스를 통합하여 공격을 탐지하고 분석합니다.
  • AWS 서비스 통합: CloudTrail, VPC 흐름 로그, DNS 로그 등을 분석하여 위협을 탐지하고, Lambda 함수를 통해 위협에 대응할 수 있습니다.
• 활용 사례:
  • AWS 환경에서 실시간 보안 위협 모니터링을 하고, 악성 행위나 데이터 유출을 빠르게 감지하고자 하는 경우.
  • 침해 사고 대응을 자동화하여 AWS 계정의 보안 상태를 개선하고자 할 때.

Amazon Macie

• 개념 : 데이터 보호 및 개인 정보 보호를 위한 서비스로, 특히 민감한 데이터(Personal Identifiable Information, PII)를 식별하고 보호하는 데 특화되어 있습니다. Macie는 S3 버킷에 저장된 데이터를 자동으로 스캔하고, PII나 민감한 정보를 탐지해 보안 정책을 준수하도록 돕습니다.
• 주요 기능:
  • 민감한 데이터 스캔: Amazon Macie는 S3 버킷에서 PII(개인 식별 정보)나 민감한 데이터를 스캔하고 식별합니다. 예를 들어, 이름, 주소, 주민등록번호, 신용카드 정보 등이 포함된 데이터를 자동으로 탐지합니다.
  • 데이터 분류: 탐지된 데이터를 분류하고 민감한 정보가 있는지 평가하며, 보안 및 규정 준수를 위해 데이터를 보호할 수 있는 정보를 제공합니다.
  • 자동화된 데이터 보호: Macie는 기계 학습(ML)을 사용하여 대규모 데이터에서도 자동으로 민감한 정보를 탐지하고 리포팅합니다.
  • 위험 평가: 데이터 보안 위험을 평가하고, 잠재적인 위협이나 규정 위반 가능성을 사전에 알립니다.
• 활용 사례:
  • 민감한 정보 보호가 필요한 경우, 특히 기업에서 PII 데이터를 스캔하여 식별하고 보호하고자 할 때.
  • 데이터 보안 및 규정 준수를 위해 S3 버킷에 저장된 민감한 데이터를 자동으로 관리할 때.

용어정리

• Kinesis Data Streams: 대규모 실시간 데이터를 처리하는 서비스로, 수백만 개의 데이터를 초당 빠르게 수집하고 처리할 수 있습니다. 실시간으로 데이터를 스트리밍할 수 있지만, 데이터는 일정 시간이 지나면 자동으로 삭제되기 때문에 영구적인 저장소로 사용하기에는 적합하지 않습니다.
• Kinesis Data Analytics: Kinesis Data Streams에서 수집된 데이터를 실시간으로 분석하는 서비스입니다. 실시간 데이터 처리가 필요한 경우 유용하지만, 영구적인 저장소는 아니며 분석 결과는 주로 실시간에 국한됩니다.
• Amazon Kinesis Data Firehose: 데이터를 실시간으로 수집하고 Amazon S3, Redshift, Elasticsearch 등으로 자동 전달해주는 서비스입니다. 데이터를 영구적으로 저장하는 용도로 적합하며, 실시간으로 데이터를 수집하고 처리하는 데 자주 사용됩니다.
• Amazon Redshift: 대규모 데이터를 저장하고, SQL 쿼리를 통해 데이터를 처리하는 완전 관리형 데이터 웨어하우스 서비스입니다. 실시간 대규모 데이터 쿼리와 영구적인 데이터 저장소를 제공하며, 데이터 분석에 매우 적합합니다.
• Amazon Athena: S3에 저장된 데이터를 쿼리하는 서버리스 쿼리 서비스입니다. 즉시 쿼리를 실행할 수 있지만, 실시간 데이터 스트리밍 및 대규모 실시간 분석에는 적합하지 않을 수 있습니다.
• Amazon Redis (ElastiCache): Redis는 인메모리 데이터베이스로, 주로 데이터 캐싱에 사용됩니다. 빠른 데이터 액세스를 제공하지만, 영구적인 데이터 저장에는 적합하지 않으며, 실시간 데이터 분석에 필요한 대규모 데이터를 처리하는 데 적합하지 않습니다.
• Amazon Inspector: AWS 인프라의 보안 취약점을 탐지하고 평가하는 서비스.
• Amazon GuardDuty: AWS 환경의 위협을 자동으로 탐지하고 보안 모니터링을 제공하는 서비스.
• Amazon Macie: 민감한 데이터, 특히 PII를 탐지하고 관리하며, S3 버킷 내의 데이터를 보호하는 서비스.
• Amazon QuickSight: 비즈니스 인텔리전스(BI) 도구로, 데이터를 시각화하고 분석하는 서비스.

문제풀이

 

문제 1 : 회사에 Amazon RDS의 데이터베이스에 목록을 저장하는 자동차 판매 웹 사이트가 있습니다. 자동차가 판매되면 목록을 웹 사이트에서 제거해야 하고 데이터를 여러 대상 시스템으로 보내야 합니다. 솔루션 아키텍트는 어떤 디자인을 추천해야 할까요?

 

A. Amazon RDS의 데이터베이스가 업데이트될 때 대상이 소비할 Amazon Simple Queue Service(SQS) 대기열로 정보를 전송하도록 트리거되는 AWS Lambda 함수를 생성합니다.

• 분석: SQS는 큐잉 시스템으로 단일 소비자에게 적합합니다. 따라서 여러 대상 시스템에 데이터를 보내야 하는 상황에서는 적합하지 않습니다.

B. Amazon RDS의 데이터베이스가 업데이트될 때 대상이 소비할 Amazon Simple Queue Service(SQS) FIFO 대기열로 정보를 전송하도록 트리거되는 AWS Lambda 함수를 생성합니다.

• 분석: FIFO 대기열을 사용하여 순서 보장이 필요할 때 유용하지만, 이 방식도 단일 소비자에게 적합하므로 여러 시스템에 데이터를 전송해야 하는 이 시나리오에는 맞지 않습니다.

C. RDS 이벤트 알림을 구독하고 Amazon Simple Queue Service(SQS) 대기열을 여러 Amazon Simple Notification Service(SNS) 주제로 보냅니다. AWS Lambda 함수를 사용하여 대상 업데이트.

• 분석: SNS는 여러 소비자에게 데이터를 전송하는 퍼블리시-서브스크라이브 모델을 제공합니다. 여러 시스템으로 데이터를 보내기 위해 적합할 수 있으나, D 선택지에 비해 Lambda 함수 사용이 비효율적일 수 있습니다.

D. RDS 이벤트 알림을 구독하고 Amazon Simple Notification Service(SNS) 주제를 여러 Amazon Simple Queue Service(SQS)에 보냅니다. AWS Lambda 함수를 사용하여 대상 업데이트.

• 분석: 이 구조는 SNS를 사용하여 여러 시스템에 데이터를 전달하며, SQS와 Lambda를 연계해 데이터를 처리할 수 있는 확장성 높은 솔루션입니다. 여러 시스템에 데이터를 전달하기 위한 가장 적절한 아키텍처입니다.

회사는 Amazon EC2 인스턴스 집합을 사용하여 온프레미스 데이터 원본에서 데이터를 수집하고 있습니다. 데이터는 JSON 형식이며 수

집 속도는 최대 1MB/s입니다. EC2 인스턴스가 재부팅되면 진행 중인 데이터가 손실됩니다. 회사의 데이터 과학 팀은 수집된 데이터를 거의 실시간으로 쿼리하려고 합니다. 최소한의 데이터 손실로 확장 가능한 거의 실시간 데이터 쿼리를 제공하는 솔루션은 무엇입니까?

 

A. Amazon Kinesis Data Streams에 데이터를 게시하고 Kinesis Data Analytics를 사용하여 데이터를 쿼리합니다.

• 분석:
  • Kinesis Data Streams는 대규모 데이터를 실시간으로 처리할 수 있는 스트리밍 서비스입니다. 데이터를 빠르게 수집하고 처리할 수 있지만, 영구적인 데이터 저장소는 아닙니다. (365일까지 보관가능)
  • Kinesis Data Analytics는 Kinesis Data Streams에서 수집된 데이터를 실시간으로 분석하는 데 적합합니다. 하지만 데이터는 임시적으로 처리되며, 영구적인 데이터 보관 및 복잡한 쿼리 기능을 제공하지는 않습니다.
  • 결론: 이 선택지는 실시간 분석에 적합하나, 영구적으로 데이터를 저장하고 복잡한 쿼리를 처리하는 데는 적합하지 않습니다.

B. Amazon Redshift를 대상으로 하여 Amazon Kinesis Data Firehose에 데이터를 게시하고 Amazon Redshift를 사용하여 데이터를 쿼리합니다.

• 분석:
  • Amazon Kinesis Data Firehose는 데이터를 실시간으로 캡처하고, Amazon S3, Amazon Redshift, Amazon Elasticsearch 등으로 전달할 수 있습니다.
  • Amazon Redshift는 대규모 데이터 웨어하우스 서비스로, 데이터를 영구적으로 저장하며, 실시간으로 대규모 데이터 쿼리를 처리할 수 있습니다. Redshift는 복잡한 SQL 쿼리도 빠르게 처리하며, 다양한 데이터 분석에 적합합니다.
  • 결론: 이 선택지는 실시간 데이터 수집(Kinesis Data Firehose)과 영구 저장 및 실시간 쿼리 기능(Redshift)을 모두 제공하므로, 문제의 요구 사항을 가장 잘 충족하는 답입니다.

C. 수집된 데이터를 EC2 인스턴스 스토어에 저장하고, Amazon S3를 대상으로 하여 Amazon Kinesis Data Firehose에 데이터를 게시합니다.

• 분석:
  • EC2 인스턴스 스토어는 인스턴스가 중지되거나 재부팅될 때 데이터가 손실될 수 있습니다. 영구적인 데이터 저장을 원하지 않는 경우에는 사용할 수 있지만, 이 문제에서는 데이터 손실 방지가 중요합니다.
  • Amazon S3는 영구적인 데이터 스토리지를 제공하지만, 실시간 쿼리 및 분석에 적합하지 않습니다.
  • Kinesis Data Firehose는 데이터를 실시간으로 S3에 게시할 수 있으나, S3는 실시간 데이터 쿼리에 적합하지 않으며, EC2 인스턴스 스토어는 데이터 손실의 위험이 있습니다.
  • 결론: 이 선택지는 실시간 데이터 처리와 영구 저장에 적합하지 않으므로 적절하지 않습니다.

D. 수집된 데이터를 Amazon Elastic Block Store(Amazon EBS)에 저장하고, Amazon ElastiCache 또는 Redis에 데이터를 게시하여 Redis 채널을 구독하여 데이터를 쿼리합니다.

• 분석:
  • Amazon EBS는 영구 블록 스토리지이지만, 실시간 쿼리나 데이터 분석에 적합하지 않습니다.
  • Redis는 인메모리 데이터베이스로, 실시간 데이터 처리를 지원하지만 영구 저장소로 사용되지는 않습니다. 또한 Redis는 데이터를 캐시하는 데 주로 사용되며, 대규모 데이터를 쿼리하는 데는 적합하지 않습니다.
  • 결론: 이 선택지는 데이터 손실 방지나 실시간 데이터 쿼리에 적합하지 않습니다.

문제 3 : 회사에 AWS에서 실행되는 인기 있는 게임 플랫폼이 있습니다. 대기 시간이 사용자 경험에 영향을 미치고 일부 플레이어에 불공정

한 이점을 도입할 수 있기 때문에 애플리케이션은 대기 시간에 민감합니다. 애플리케이션은 모든 AWS 리전에 배포되었습니다. 애플리케이션은 ALB(Application Load Balancer) 뒤에 구성된 Auto Scaling 그룹의 일부로 Amazon EC2 인스턴스에서 실행됩니다. 솔루션 설계자는 애플리케이션의 핵심을 모니터링하고 트래픽을 정상 엔드포인트로 리디렉션하는 메커니즘을 구현해야 합니다.

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

 

해석 포인트:

• 애플리케이션은 AWS 리전에서 ALB(애플리케이션 로드 밸런서)를 통해 배포됩니다.
• 대기 시간을 줄이고, 트래픽을 최적화할 필요가 있습니다.
• 각 리전의 엔드포인트로 트래픽을 효율적으로 리디렉션하는 메커니즘이 필요합니다.

A. AWS Global Accelerator에서 액셀러레이터를 구성. 애플리케이션이 수신 대기하는 포트에 수신 대기를 추가합니다. 각 리전의 리전 엔드포인트에 연결합니다. ALB를 엔드포인트로 추가합니다.

• 분석:
  • AWS Global Accelerator는 지연 시간을 줄이고, 여러 AWS 리전에서 실행되는 애플리케이션에 대한 글로벌 사용자를 더 빠르게 연결할 수 있도록 설계된 서비스입니다.
  • Global Accelerator는 최적의 네트워크 경로를 사용해 트래픽을 전송하며, 지연 시간을 최소화하고 더 나은 사용자 경험을 제공합니다. ALB를 엔드포인트로 연결하면 애플리케이션에 대한 글로벌 트래픽을 자동으로 가장 가까운 리전으로 라우팅할 수 있습니다.
  • 결론: Global Accelerator는 여러 리전에서 애플리케이션을 실행하는 경우, 트래픽을 최적의 경로로 리디렉션하여 대기 시간을 줄이고 성능을 개선할 수 있어 이 문제의 요구사항에 부합합니다. 이 선택지가 정답일 가능성이 큽니다.

B. Amazon CloudFront 배포를 생성하고 ALB를 오리진 서버로 지정. 오리진 캐시 헤더를 사용하여 트래픽 최적화.

• 분석:
  • Amazon CloudFront는 글로벌 콘텐츠 전송 네트워크(CDN)로, 정적 및 동적 콘텐츠를 빠르게 제공하는 데 유리합니다.
  • ALB를 오리진 서버로 지정하고 CloudFront를 사용하면 콘텐츠를 캐시하여 사용자에게 더 빠르게 전달할 수 있지만, 이 솔루션은 주로 정적 콘텐츠에 적합하며, 대기 시간 최적화가 주요 목표인 이 시나리오에는 적합하지 않을 수 있습니다.
  • 결론: CloudFront는 캐싱을 통한 성능 개선에는 유리하지만, 대기 시간을 줄이고 트래픽을 리디렉션하는 데는 적합하지 않습니다.

C. Amazon CloudFront 배포를 생성하고 Amazon S3를 오리진 서버로 지정합니다. 오리진 캐시 헤더를 사용하여 트래픽 최적화.

• 분석:
  • S3는 정적 콘텐츠를 저장하고 제공하는 데 적합하며, CloudFront와 함께 사용하여 콘텐츠를 캐싱할 수 있습니다.
  • 하지만 S3는 정적 파일을 제공하는 데 주로 사용되므로, 동적인 사용자 트래픽을 다루기 위한 솔루션에는 적합하지 않습니다.
  • 결론: 이 선택지도 트래픽 최적화에는 적합하지 않습니다.

D. 애플리케이션의 데이터 저장소 역할을 하도록 Amazon DynamoDB 데이터베이스 구성. 애플리케이션 데이터를 호스팅하는 DynamoDB의 메모리 캐시 역할을 할 DynamoDB Accelerator(DAX) 클러스터 생성.

• 분석:
  • DynamoDB는 빠르고 확장 가능한 NoSQL 데이터베이스로, 데이터를 저장하는 데 적합합니다.
  • DynamoDB Accelerator(DAX)는 DynamoDB의 성능을 개선하는 메모리 캐시입니다. 하지만 이 문제는 데이터베이스 성능보다는 트래픽 라우팅 및 대기 시간 최적화에 관한 문제이므로, DynamoDB 및 DAX는 이 시나리오에 적합하지 않습니다.
  • 결론: 데이터베이스 성능을 높이는 솔루션이므로, 이 문제의 요구사항과는 맞지 않습니다.

문제 4 : 회사에 IPv6 주소가 있는 Amazon EC2 인스턴스에서 호스팅되는 애플리케이션이 있습니다. 응용 프로그램은 인터넷을 사용하

여 다른 외부 응용 프로그램과 통신을 시작해야 합니다. 그러나 회사의 보안 정책에 따르면 외부 서비스는 EC2 인스턴스에 대한 연결을 시작할 수 없습니다.솔루션 설계자는 이 문제를 해결하기 위해 무엇을 권장해야 합니까?

 

해석 포인트:

• IPv6 주소를 사용하여 Amazon EC2 인스턴스가 외부 서비스와 통신해야 합니다.
• EC2 인스턴스는 직접 인터넷에 연결될 수 없습니다.
• 이를 해결하기 위한 게이트웨이를 설정해야 합니다.

A. NAT 게이트웨이를 생성하고 서브넷의 라우팅 테이블의 대상으로 만듭니다.

• 분석:
  • NAT 게이트웨이는 IPv4 트래픽에 대해서만 동작합니다. IPv6 트래픽에는 NAT가 적용되지 않으므로, NAT 게이트웨이는 이 시나리오에 적합하지 않습니다.
  • 결론: NAT 게이트웨이는 IPv6 환경에서 적절한 선택이 아닙니다.

B. 인터넷 게이트웨이를 생성하고 서브넷의 라우팅 테이블의 대상으로 만듭니다.

• 분석:
  • 인터넷 게이트웨이는 VPC와 인터넷 간의 트래픽을 중계하는 역할을 합니다. 특히, IPv6 트래픽을 처리할 수 있어, 이 문제에서 요구하는 IPv6 주소를 사용하는 인스턴스가 외부와 통신할 수 있도록 합니다.
  • 결론: 인터넷 게이트웨이를 사용하는 것은 적절한 선택입니다. EC2 인스턴스는 인터넷과 통신할 수 있으면서도 보안 정책에 따라 트래픽이 중계됩니다. 그러나, 외부 서비스가 연결 가능하므로 적절한 솔루션은 아닙니다. 

C. 가상 프라이빗 게이트웨이를 생성하고 서브넷의 라우팅 테이블의 대상으로 만듭니다.

• 분석:
  • 가상 프라이빗 게이트웨이(Virtual Private Gateway)는 VPC와 온프레미스 네트워크 간의 연결을 설정하는 데 사용됩니다. 이 게이트웨이는 인터넷 연결이 아닌 VPN이나 Direct Connect와 같은 프라이빗 네트워크 연결을 위한 것입니다.
  • 결론: 이 옵션은 인터넷과의 통신을 위한 솔루션이 아니므로 부적절합니다.

D. 송신 전용 인터넷 게이트웨이를 생성하고 서브넷의 라우팅 테이블의 대상으로 만듭니다.

• 분석:
  • 송신 전용 인터넷 게이트웨이(Egress-Only Internet Gateway)는 IPv6 트래픽을 처리하며, 외부로의 아웃바운드 통신만 허용합니다. 즉, EC2 인스턴스는 외부로 요청을 보낼 수 있지만, 외부에서 인스턴스로의 트래픽은 차단됩니다.
  • 결론: 송신 전용 인터넷 게이트웨이는 외부에서 인스턴스로의 트래픽을 차단하면서, 인스턴스가 외부로 데이터를 전송할 수 있도록 하는 보안적인 선택입니다. 이 문제의 요구 사항에 잘 맞는 솔루션입니다.

문제 5 : 한 회사에서 Amazon S3 버킷에 대량의 데이터를 수집할 새로운 데이터 분석 애플리케이션을 구축하고 있습니다. 회사는 개인 식

별 정보(Pll)와 같은 민감한 정보에 대해 우려하고 있습니다. 수집되는 일부 데이터에 포함될 수 있습니다. 회사는 민감한 데이터를 스캔하고 결과를 기록할 솔루션이 필요합니다.

이러한 요구 사항을 충족하기 위해 솔루션 설계자는 무엇을 권장해야 합니까?

 

해석 포인트:

• Amazon S3에 저장된 데이터를 스캔하여 개인 식별 정보(PII) 및 민감한 데이터를 탐지해야 합니다.
• 결과를 기록할 수 있는 로깅 기능이 필요합니다.
• 보안 및 규정 준수 요구 사항을 충족하는 데이터 처리 솔루션을 찾는 것이 목표입니다.

A. 수집된 데이터를 스캔하도록 Amazon Inspector를 배포합니다. Amazon Inspector가 민감한 데이터를 찾으면 Amazon CloudWatch에 결과를 기록하도록 Amazon Inspector를 구성합니다.

• 분석:
  • Amazon Inspector는 주로 취약점 탐지 및 애플리케이션 보안 관련 문제를 자동으로 스캔하는 서비스입니다. 데이터 파일이나 PII(개인 식별 정보)를 탐지하는 데는 적합하지 않습니다.
  • 결론: Amazon Inspector는 주로 보안 평가를 목적으로 하므로 민감한 데이터 스캔에는 적합하지 않습니다.

B. Amazon QuickSight를 배포하여 수집된 데이터를 스캔합니다. QuickSight가 민감한 데이터를 찾으면 Amazon CloudWatch에 결과를 기록하도록 QuickSight를 구성합니다.

• 분석:
  • Amazon QuickSight는 비즈니스 인텔리전스(BI) 도구로서 데이터를 시각화하고 분석하는 데 사용됩니다. 그러나 데이터 내에서 민감한 정보를 스캔하거나 탐지하는 기능을 제공하지는 않습니다.
  • 결론: QuickSight는 데이터 시각화 및 분석 도구이므로 PII 탐지와 같은 작업에는 적합하지 않습니다.

C. 수집된 데이터의 스캔을 수행하기 위해 Amazon GuardDuty를 호출하는 일련의 AWS Lambda 함수를 생성합니다. GuardDuty가 민감한 데이터를 찾으면 Lambda 함수를 호출하여 Amazon CloudWatch에 결과를 기록합니다.

• 분석:
  • Amazon GuardDuty는 주로 보안 위협 탐지 및 악의적인 활동 감지를 위한 서비스입니다. 데이터 내 민감한 정보 스캔에는 적합하지 않으며, PII 데이터를 탐지하는 기능은 제공하지 않습니다.
  • 결론: GuardDuty는 보안 위협에 적합하지만 민감한 데이터 탐지에는 적합하지 않습니다.

D. 수집된 데이터의 스캔을 수행하기 위해 Amazon Macie를 호출하는 일련의 AWS Lambda 함수를 생성합니다. Macie가 민감한 데이터를 찾으면 Lambda 함수를 호출하여 Amazon CloudWatch에 결과를 기록합니다.

• 분석:
  • Amazon Macie는 데이터 보호 및 개인 정보 보호에 중점을 둔 서비스로, 특히 S3 버킷에 저장된 데이터 내에서 PII 및 기타 민감한 정보를 탐지하는 데 매우 적합합니다. Macie는 데이터를 스캔하고, 민감한 정보가 포함된 데이터를 식별하며, 결과를 CloudWatch나 다른 로깅 시스템에 기록할 수 있습니다.
  • 결론: Amazon Macie는 이 문제의 요구 사항인 PII 탐지와 결과 기록에 가장 적합한 서비스입니다.

문제 6 : 모놀리식 애플리케이션이 최근 AWS로 마이그레이션되어 현재 단일 Amazon EC2 인스턴스에서 실행 중입니다. 애플리케이션

제한으로 인해 오토 스케일링을 사용하여 애플리케이션을 확장할 수 없습니다. CTO(최고 기술 책임자)는 기본 하드웨어에 장애가 발생할 경우 EC2 인스턴스를 복원하는 자동화된 솔루션을 원합니다. EC2 인스턴스를 최대한 빨리 자동 복구할 수 있는 방법은 무엇입니까?

 

해석 포인트:

• 단일 EC2 인스턴스에서 애플리케이션이 실행되고 있습니다.
• EC2 인스턴스가 손상될 경우, 자동으로 인스턴스를 복구해야 합니다.
• 신속한 복구를 통해 장애에 대처할 수 있어야 합니다.

A. EC2 인스턴스가 손상된 경우 복구를 트리거하는 Amazon CloudWatch 경보를 구성합니다.

• 분석:
  • Amazon CloudWatch는 EC2 인스턴스의 상태를 모니터링할 수 있으며, 인스턴스가 손상되었을 때 **경보(Alert)**를 설정하여 복구 작업을 자동으로 수행하도록 트리거할 수 있습니다. CloudWatch 경보는 EC2 인스턴스의 상태가 ‘비정상’ 상태로 변경될 경우 자동으로 복구 작업을 트리거할 수 있습니다.
  • 결론: CloudWatch를 통해 EC2 인스턴스의 상태를 모니터링하고, 비정상 상태일 때 자동 복구를 트리거하는 방식은 이 문제의 요구 사항을 충족합니다. 적절한 답변입니다.

B. EC2 인스턴스가 손상될 때 CTO에게 경고하는 SNS 메시지를 트리거하도록 Amazon CloudWatch 경보를 구성합니다.

• 분석:
  • SNS(Simple Notification Service)는 알림 메시지를 전송할 수 있지만, 이는 단지 인스턴스 손상에 대한 경고 메시지일 뿐 직접적인 복구를 수행하지 않습니다. 이 방식은 문제에서 요구하는 ‘자동화된 복구’를 수행하지 않기 때문에 부적절합니다.
  • 결론: 이 선택지는 알림을 제공할 뿐, 자동 복구를 제공하지 않으므로 적절하지 않습니다.

C. EC2 인스턴스의 상태를 모니터링하도록 AWS CloudTrail을 구성하고 손상된 경우 인스턴스 복구를 트리거합니다.

• 분석:
  • AWS CloudTrail은 AWS API 호출 및 계정 활동을 추적하는 서비스로, 주로 감사 및 추적 목적으로 사용됩니다. CloudTrail은 주로 활동 기록을 위해 사용되며, 실시간으로 EC2 인스턴스 상태를 모니터링하거나 자동 복구를 트리거하는 데는 적합하지 않습니다.
  • 결론: CloudTrail은 인스턴스의 복구를 위한 적절한 서비스가 아니므로 부적절한 선택입니다.

D. EC2 인스턴스의 상태를 확인하고 EC2 인스턴스가 비정상인 경우 인스턴스 복구를 트리거하도록 Amazon EventBridge 이벤트를 구성합니다.

• 분석:
  • Amazon EventBridge는 AWS 서비스 간 이벤트를 연결하는 서비스입니다. EventBridge를 사용하면 EC2 인스턴스의 상태가 비정상인 경우 이를 자동으로 감지하고 Lambda 함수와 같은 다른 서비스와 연계하여 인스턴스를 자동으로 복구할 수 있습니다.
  • 결론: EventBridge는 이벤트 기반 복구 메커니즘을 제공할 수 있지만, 이 문제의 시나리오에서 인스턴스 복구에 대한 요구 사항을 충족하는 방식은 CloudWatch 경보와 비교해 복잡할 수 있습니다.

문제 7 : 회사는 사용자 평가판 API를 제공하여 품목 가격을 기반으로 세금 계산을 위한 조회를 자동화합니다. 회사는 휴가철에만 더 많은 문

의를 받고 응답 시간이 느려집니다. 솔루션 설계자는 확장 가능하고 탄력적인 솔루션을 설계해야 합니다.

솔루션 설계자는 이를 달성하기 위해 무엇을 해야 합니까?

 

해석 포인트:

• API를 통해 세금 계산을 처리해야 합니다.
• 요청이 증가하는 시기(휴가철 등)에 대비한 확장성과 탄력성이 필요합니다.
• API의 빠른 응답 시간을 유지해야 합니다.

A. Amazon EC2 인스턴스에서 호스팅되는 API를 제공합니다. EC2 인스턴스는 API 요청이 있을 때 필요한 계산을 수행합니다.

• 분석:
  • 이 방식은 단순히 EC2 인스턴스에서 API를 호스팅하여 요청을 처리하는 것입니다. 그러나 단일 EC2 인스턴스만 사용하면 요청량이 증가할 때 확장성 문제와 탄력성 부족 문제가 발생할 수 있습니다. 특히 휴가철과 같은 많은 요청이 있을 때 응답 시간이 느려질 수 있습니다.
  • 결론: 이 선택지는 확장성과 탄력성 측면에서 적합하지 않으므로 적절하지 않습니다.

B. Amazon API Gateway를 사용하여 항목 이름을 수락하는 REST API 설계. API Gateway는 세금 계산을 위해 항목 이름을 AWS Lambda에 전달합니다.

• 분석:
  • Amazon API Gateway는 확장성 있고 관리형 API 서비스를 제공합니다. 특히, REST API를 설계하여 요청을 수락하고 AWS Lambda를 통해 백엔드에서 계산을 수행할 수 있습니다. Lambda는 서버리스 방식으로 요청량이 많아질 때 자동으로 확장되며, 비용 효율적입니다.
  • 이 방식은 특히 휴가철처럼 트래픽이 급증할 때도 확장성과 탄력성을 제공할 수 있습니다.
  • 결론: 이 선택지는 문제의 요구 사항을 충족하며, 확장성, 탄력성, 비용 효율성 모두를 고려한 최적의 솔루션입니다.

C. Application Load Balancer 생성 매트 뒤에 두 개의 Amazon EC2 인스턴스가 있습니다. EC2 인스턴스는 수신된 항목 이름에 대한 세금을 계산합니다.

• 분석:
  • Application Load Balancer(ALB)는 여러 EC2 인스턴스에 트래픽을 분산할 수 있지만, 여전히 EC2 인스턴스를 직접 사용하는 방식입니다. EC2 인스턴스를 추가하여 트래픽을 분산할 수 있지만, 서버리스인 Lambda를 사용하는 것만큼 자동으로 확장되지 않으며 비용이 많이 들 수 있습니다.
  • 결론: 이 방식은 확장성과 탄력성 측면에서 어느 정도의 해결책이 될 수 있지만, 서버리스 아키텍처만큼 효율적이지 않습니다.

D. Amazon EC2 인스턴스에서 호스팅되는 API와 연결하는 Amazon API Gateway를 사용하여 REST API를 설계합니다. API Gateway는 세금 계산을 위해 항목 이름을 수락하고 EC2 인스턴스로 전달합니다.

• 분석:
• 이 선택지는 API Gateway를 사용하는 점에서는 좋지만, 백엔드로 여전히 EC2 인스턴스를 사용하고 있어 자동 확장성이 부족할 수 있습니다. 트래픽 증가에 따라 인스턴스를 자동으로 확장하는 Lambda와 비교해 효율적이지 않으며, 요청이 많아지면 성능에 영향을 받을 수 있습니다.
• 결론: EC2 인스턴스를 사용하는 점에서 확장성과 탄력성에 한계가 있으므로 적절하지 않습니다.

문제 8 : 회사에는 관리 및 프로덕션이라는 두 개의 VPC가 있습니다. 관리 VPC는 고객 게이트웨이를 통해 VPN을 사용하여 데이터 센터의

단일 장치에 연결합니다. 프로덕션 VPC는 두 개의 연결된 AWS Direct Connect 연결이 있는 가상 프라이빗 게이트웨이를 사용합니다. 관리 및 프로덕션 VPC는 모두 단일 VPC 피어링 연결을 사용하여 애플리케이션 간 통신을 허용합니다.

이 아키텍쳐에서 단일 실패 지점을 완화하기 위해 솔루션 아키텍트는 무엇을 해야 합니까? C

 

A. 관리 VPC와 프로덕션 VPC 간에 VPN 세트를 추가하십시오.

• 분석:
  • VPN 연결은 인터넷을 통해 설정되는 암호화된 통신 방식입니다. 두 VPC 간에 VPN을 설정하면 데이터 통신을 보안할 수 있지만, VPC 피어링 연결을 통해 이미 안정적인 프라이빗 네트워크 통신이 이루어지고 있기 때문에 이 방식은 추가적인 가용성을 제공하지 않습니다.
  • 결론: 이 방식은 이미 설정된 VPC 피어링 연결을 강화하지 못하며, 단일 실패 지점을 해결하는 데 적합하지 않습니다.

B. 두 번째 가상 프라이빗 게이트웨이를 추가하고 관리 VPC에 연결하십시오.

• 분석:
  • 가상 프라이빗 게이트웨이는 AWS와 온프레미스 네트워크 간의 프라이빗 연결을 설정하는 데 주로 사용됩니다. 관리 VPC와 프로덕션 VPC 사이에 직접적인 통신을 위한 설정이므로, 이 선택지는 문제의 요구 사항을 해결하는 데 적합하지 않습니다.
  • 결론: 이 선택지는 단일 실패 지점을 해결하지 못하므로 부적절합니다.

C. 두 번째 고객 게이트웨이 장치에서 관리 VPC에 두 번째 VPN 세트를 추가하십시오.

• 분석:
  • 두 번째 고객 게이트웨이를 추가하고 관리 VPC에 두 번째 VPN 세트를 설정하면, 두 VPC 간의 네트워크 연결이 이중화되어 한 개의 VPN 연결에 문제가 발생하더라도 다른 연결을 통해 통신이 유지됩니다. 이로 인해 단일 실패 지점을 해결할 수 있습니다.
  • 고객 게이트웨이는 AWS 외부 네트워크 장치와의 연결을 위한 구성 요소로, 온프레미스 네트워크와 AWS VPC 간에 안전한 통신을 설정합니다. 두 번째 VPN 세트를 추가하면 네트워크 연결의 이중화가 제공되어 더 높은 가용성을 확보할 수 있습니다.
  • 관리 VPC에 VPN 세트를 추가함으로써 관리 VPC와 외부 네트워크 간의 네트워크 연결을 이중화하고 고가용성을 확보할 수 있습니다. 
  • 결국, 두 VPC 간의 직접적인 연결 이중화가 아니라, 관리 VPC와 온프레미스 간의 이중화를 통해 관리 VPC의 안정성을 확보하고, 이를 통해 관리 VPC가 프로덕션 VPC와 안정적으로 통신할 수 있으며, 결과적으로 전체 네트워크의 안정성을 높이는 효과가 있다. 
  • 결론: 이 선택지는 단일 실패 지점을 해결하는 데 적합한 선택입니다.

D. 관리 VPC와 프로덕션 VPC 사이에 두 번째 VPC 피어링 연결을 추가하십시오.

• 분석:
• VPC 피어링 연결은 두 VPC 간에 프라이빗 네트워크 통신을 설정하는 방식입니다. 두 번째 VPC 피어링 연결을 추가하여 이중화할 수 있지만, VPC 피어링은 주로 VPC 간의 통신을 위한 것이며 외부 네트워크와의 통신을 이중화하는 데에는 적합하지 않습니다. 또한, 관리 VPC는 외부 데이터 센터와 연결되어 있기 때문에 이 방식은 그 문제를 해결하지 못합니다.
• 결론: VPC 피어링 추가는 이 문제의 해결책이 아닙니다.