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

개념정리

Amazon ElasticCache

• AWS에서 제공하는 완전 관리형 인메모리 캐시 서비스
• Redis와 Memcached 같은 오픈 소스 인메모리 데이터 스토어를 클라우드 환경에서 쉽게 배포, 운영 및 확장할 수 있도록 함
• 주로 애플리케이션의 성능을 향상시키기 위해 사용되며, 특히 데이터베이스에 대한 읽기 요청이 많거나 데이터에 빠르게 액세스해야하는 경우 유용함
• DB의 부하를 줄이고 성능을 최적화하는데 사용함

Amazon EMR[Elastic MapReduce]

• 클라우드 기반 빅데이터 처리 서비스
• Apache Hadoop, Apache Spark, HDFS 등을 사용하여 대규모 데이터 세트를 효율적으로 처리하고 분석할 수 있도록 지원
• EMR을 사용하면 복잡한 데이터 처리작업을 손쉽게 설정하고 자동으로 확장 가능한 클러스터에서 실행 가능

용어 정리

관리 오버헤드가 크다 : 시스템이나 애플리케이션을 운영하고 유지 관리하는 데 있어서 추가적인 작업과 복잡성이 많다는 것을 의미함.예를 들어, EC2의 경우에는 복잡한 설정 및 운영관리, 자동화가 부족하고, 비용 관리 필요, 복잡한 인프라 관리 등으로 인해 관리 오버헤드가 크다라고 설명할 수 있다. 

문제풀이

문제 : AWS에서 쇼핑 애플리케이션을 구축하는 상황에서, 각 사용자의 장바구니 데이터가 항상 보존되도록 하기 위해 어떤 솔루션을 설계해야 하는지 묻는 문제이다. 특히, 트래픽 양에 따라 확장할 수 있고, 사용자가 연결을 끊었다가 다시 연결하더라도 사용자 세션 데이터가 보존되는 것이 중요함. [답 : B]

 

A. Amazon Aurora의 카탈로그에 액세스하기 위해 고정 세션 기능(세션 선호도)을 활성화하도록 Application Load Balancer를 구성합니다.

• Aurora는 관계형 데이터베이스 서비스로 높은 성능과 가용성을 제공합니다. 하지만 이 옵션은 세션 데이터 보존을 직접적으로 해결하는 데 적합하지 않습니다. 세션 선호도(스티키 세션)는 동일한 사용자 요청을 동일한 서버로 보내도록 하는 기능이지만, 사용자가 연결을 끊었다가 다시 연결하는 경우에는 세션 데이터를 보존하는 데 한계가 있습니다.

B. Amazon DynamoDB의 카탈로그 데이터와 사용자 세션의 장바구니 데이터를 캐시하도록 Amazon ElastiCache를 구성합니다.

• 이 옵션은 사용자 세션 데이터를 빠르게 저장하고 검색할 수 있도록 ElastiCache를 사용합니다. ElastiCache는 인메모리 데이터 스토어로 Redis와 Memcached를 지원하여, 세션 데이터를 캐싱함으로써 빠른 액세스를 제공합니다. 이 접근 방식은 사용자가 다시 연결했을 때 빠르게 세션 데이터를 복원할 수 있게 합니다.

C. Amazon DynamoDB의 카탈로그 데이터와 사용자 세션의 장바구니 데이터를 캐시하도록 Amazon Elasticsearch Service(Amazon ES)를 구성합니다.

• 설명: Elasticsearch는 검색과 분석에 최적화된 서비스입니다. 세션 데이터를 캐시하는 용도로는 적합하지 않으며, 일반적으로 실시간 검색 및 로그 분석에 사용됩니다. 따라서 세션 데이터를 보존하는 솔루션으로는 적합하지 않습니다.

D. 카탈로그 및 장바구니용 Amazon Elastic Block Store(Amazon EBS) 스토리지로 Amazon EC2 인스턴스를 구성합니다. 자동화된 스냅샷을 구성합니다.

• 설명: EBS는 블록 스토리지 서비스로, EC2 인스턴스와 함께 사용되며, 주로 데이터베이스나 파일 시스템 저장에 사용됩니다. 스냅샷은 데이터를 백업하는 용도로 사용되지만, 실시간 세션 데이터를 관리하고 복원하는 데는 적합하지 않습니다.

문제 : VPC와 온프레미스 서버 간의 네트워크 연결이 이미 VPN으로 설정된 상태에서, 인터넷 사용자를 위해 온프레미스 서버에 TCP 트래픽을 전달하는 가장 적합한 솔루션을 찾는 것이다. 요구 사항은 가용성과 확장성이 뛰어난 솔루션을 제공하는 것이다. 

 

A. 인터넷 연결 NLB(Network Load Balancer)를 시작하고 NLB에 온프레미스 IP 주소를 등록합니다.

• Network Load Balancer(NLB)는 TCP 및 UDP 트래픽을 처리하는 데 최적화되어 있으며, 매우 낮은 지연 시간과 높은 처리량을 제공합니다. 온프레미스 서버의 IP 주소를 NLB에 등록하면, NLB가 인터넷에서 들어오는 트래픽을 온프레미스 서버로 전달할 수 있습니다. NLB는 고정 IP 주소를 제공하며, 확장성과 가용성이 뛰어납니다. 이 선택지는 가장 적합한 솔루션입니다.

B. 인터넷 연결 ALB(Application Load Balancer)를 시작하고 ALB에 온프레미스 IP 주소를 등록합니다.

• •Application Load Balancer(ALB)는 주로 HTTP 및 HTTPS 트래픽을 처리하는 데 사용되며, L7 계층에서 동작합니다. TCP 트래픽을 처리하기에는 적합하지 않으며, 온프레미스 서버의 IP 주소를 ALB에 등록하는 것은 일반적이지 않습니다.

C. Amazon EC2 인스턴스를 시작하여 탄력적 IP 주소로 연결하고 온프레미스 서버에 트래픽을 분산합니다.

• 이 방법은 EC2 인스턴스를 사용하여 트래픽을 수신하고 온프레미스 서버로 전달하는 방식입니다. 그러나 이는 EC2 인스턴스의 네트워크 성능에 제한을 받을 수 있으며, NLB를 사용하는 것보다 확장성이나 가용성 면에서 부족할 수 있습니다.

D. Auto Scaling 그룹에서 퍼블릭 IP 주소로 Amazon EC2 인스턴스를 시작하고 온프레미스 서버로 트래픽을 분산합니다.

• 이 방법은 EC2 인스턴스를 Auto Scaling 그룹을 통해 확장하며 트래픽을 분산시키는 방법입니다. 그러나 NLB를 사용하는 것보다 설정이 복잡하며, EC2 인스턴스를 통한 트래픽 분산은 네트워크 성능 측면에서 효율적이지 않을 수 있습니다.

1. 네트워크 성능 제한

• 네트워크 처리 능력: EC2 인스턴스는 각 인스턴스 유형에 따라 네트워크 처리 능력이 다릅니다. 네트워크 처리 능력은 인스턴스의 크기와 유형에 따라 제한되며, 더 높은 처리량이 필요한 경우에는 더 큰 인스턴스를 사용해야 하지만, 그럼에도 불구하고 하드웨어적인 한계가 있습니다.
• 단일 지점 병목: EC2 인스턴스는 기본적으로 하나의 서버로 작동합니다. 이 경우, 모든 네트워크 트래픽이 단일 인스턴스를 통해 흐르게 되어 병목 현상이 발생할 수 있습니다. 이는 특히 높은 트래픽을 처리할 때 성능 저하로 이어질 수 있습니다.

2. 확장성 부족

• 수동 확장: EC2 인스턴스를 통해 트래픽을 처리할 때는 트래픽 증가에 대응하여 인스턴스를 수동으로 확장해야 합니다. 자동 확장을 위해 Auto Scaling을 사용할 수 있지만, 설정이 복잡하며, 필요한 네트워크 트래픽을 즉각적으로 처리할 수 있도록 적절하게 확장하는 것이 쉽지 않을 수 있습니다.
• 복잡성: 확장을 위해 여러 개의 EC2 인스턴스를 설정하고 이를 관리하는 것은 복잡하며, 시간이 많이 소요될 수 있습니다. 반면, NLB는 자동으로 확장되어 여러 인스턴스에 트래픽을 분산할 수 있습니다.

3. 가용성 부족

• 단일 장애점(Single Point of Failure): 단일 EC2 인스턴스를 사용하면 그 인스턴스에 장애가 발생했을 때 모든 네트워크 트래픽이 중단될 수 있습니다. 이로 인해 애플리케이션의 가용성이 크게 저하될 수 있습니다.
• 수동 장애 조치: 장애 발생 시, EC2 인스턴스의 수동으로 장애 조치를 해야 하는 반면, NLB는 기본적으로 높은 가용성을 제공하며, 백엔드 인스턴스가 실패했을 때 자동으로 트래픽을 다른 인스턴스로 라우팅할 수 있습니다.

NLB의 장점

• 고가용성 및 자동 장애 조치: NLB는 여러 가용 영역(AZ)에 걸쳐 분산될 수 있으며, 인스턴스의 장애가 발생할 경우에도 자동으로 트래픽을 다른 가용한 인스턴스로 분산시킵니다. 이는 애플리케이션의 가용성을 보장합니다.
• 자동 확장: NLB는 트래픽 양에 따라 자동으로 확장되며, 이를 위해 추가적인 설정이 필요하지 않습니다. 트래픽 양이 증가해도 추가 설정 없이 부하를 처리할 수 있습니다.
• 고정 IP 및 로드 밸런싱 기능: NLB는 고정 IP 주소를 제공하며, 트래픽을 여러 백엔드 인스턴스로 효율적으로 분산합니다. 이는 클라우드 환경에서의 탄력성과 안정성을 높입니다.

문제 : 백엔드 프로세서에서 접수된 업데이트를 스트리밍하여 리더보드에 결과를 게시하는 모바일 게임을 개발하는 상황에서, 대규모 트래픽 급증을 처리할 수 있는 솔루션을 설계하는 것이다. 또한, 처리된 업데이트는 저장되어야 하며, 고가용성 데이터베이스에서 유지 관리될 필요가 있다. [정답 : A]

 

A. Amazon Kinesis Data Streams에 대한 푸시 접수 업데이트 AWS Lambda를 사용하여 Kinesis Data Streams의 업데이트 처리 처리된 업데이트를 Amazon DynamoDB에 저장

• Amazon Kinesis Data Streams는 대규모의 실시간 데이터 스트리밍을 처리하는 데 사용되며, AWS Lambda를 사용하여 데이터를 처리하면 서버리스 환경에서 자동으로 스케일링됩니다. 처리된 데이터를 DynamoDB에 저장하면, 빠른 읽기와 쓰기가 가능하며, 게임 리더보드와 같은 실시간 애플리케이션에 적합합니다. 이 접근법은 오버헤드를 최소화하고, 확장성 및 고가용성을 보장합니다.

B. Amazon Kinesis Data Streams에 대한 푸시 접수 업데이트 Auto Scaling에 대해 설정된 Amazon EC2 인스턴스 집합으로 업데이트 처리 처리된 업데이트를 Amazon Redshift에 저장

• Kinesis Data Streams에서 데이터를 처리하기 위해 EC2 인스턴스를 사용하는 것은 확장성을 제공할 수 있지만, Lambda를 사용하는 것보다 더 많은 관리 오버헤드가 발생합니다. 또한, Redshift는 데이터 웨어하우스로, 대규모 분석 쿼리에 최적화되어 있지만 실시간 처리에는 적합하지 않을 수 있습니다.

C. Amazon Simple Notification Service(Amazon SNS) 주제에 대한 푸시 접수 업데이트 업데이트를 처리하기 위해 SNS 주제에 AWS Lambda 함수 구독 Amazon EC2에서 실행되는 SQL 데이터베이스에 처리된 업데이트 저장

• SNS와 Lambda를 사용하는 것은 유연한 이벤트 기반 아키텍처를 제공하지만, SQL 데이터베이스에 저장하는 것은 데이터 처리와 관련된 오버헤드가 클 수 있으며, 게임 리더보드와 같은 실시간 요구 사항을 충족하는 데 적합하지 않을 수 있습니다.

D. Amazon Simple Queue Service(Amazon SQS) 대기열에 접수 업데이트 푸시 Auto Scaling과 SQS 대기열에서 업데이트 처리 처리된 업데이트를 Amazon RDS 다중 AZ DB 인스턴스에 저장

• SQS는 메시지를 대기열에 넣고, EC2 인스턴스 집합으로 처리하는 방식으로 안정성을 제공할 수 있습니다. 그러나 이 방식은 관리 오버헤드가 크고, EC2 인스턴스와 SQS의 결합이 Lambda와 같은 서버리스 환경보다 비효율적일 수 있습니다.

문제 : 새로운 웹 애플리케이션을 AWS에서 호스팅할 계획을 세우고, 매우 높은 트래픽을 예측하고 있는 상황에서 최적의 솔루션을 설계하는 것이다. 요구사항은 최소 대기 시간과 높은 가용성 및 내결함성을 제공하는 것이다.[정답 : B]

 

A. Amazon Route 53 라우팅 정책을 사용하여 각각 하나의 Amazon EC2 인스턴스가 있는 2개의 AWS 리전에 요청을 배포합니다.

• Route 53은 AWS의 DNS 서비스로, 지리적 라우팅 정책을 통해 서로 다른 리전의 EC2 인스턴스에 트래픽을 분배할 수 있습니다. 그러나 각 리전에 하나의 EC2 인스턴스만 있는 경우, 인스턴스에 문제가 발생할 경우 트래픽이 중단될 수 있어 고가용성을 보장하지 못합니다. 내결함성 측면에서도 부족할 수 있습니다.

B. 여러 가용 영역에서 Application Load Balancer가 있는 Auto Scaling 그룹의 Amazon EC2 인스턴스 사용

• 이 옵션은 여러 가용 영역(AZ)에 걸쳐 Auto Scaling을 사용하는 EC2 인스턴스에 트래픽을 분산시키는 방법입니다. Application Load Balancer(ALB)는 웹 애플리케이션의 트래픽을 여러 인스턴스에 분산하여 고가용성을 제공하며, Auto Scaling을 통해 트래픽 증가에 자동으로 대처할 수 있습니다. 이는 높은 가용성과 내결함성을 제공하는 이상적인 솔루션입니다.

C. 여러 가용 영역에서 Application Load Balancer가 있는 클러스터 배치 그룹의 Amazon EC2 인스턴스 사용

• 이 방법은 B와 유사하지만 “클러스터 배치 그룹”은 고밀도 컴퓨팅 작업을 위해 EC2 인스턴스를 물리적으로 가까운 곳에 배치하는 방법입니다. 이는 주로 고성능 컴퓨팅(HPC) 워크로드에 사용되며, 웹 애플리케이션의 트래픽 처리와는 직접적인 관련이 없습니다. 또한 클러스터 배치 그룹은 단일 가용 영역 내에 인스턴스를 배치해야 하기 때문에 가용성 측면에서 부족할 수 있습니다.

D. 클러스터 배치 그룹에서 Amazon EC2 인스턴스를 사용하고 새 Auto Scaling 그룹 내에 클러스터 배치 그룹을 포함합니다.

• 클러스터 배치 그룹을 사용하는 것은 고밀도 컴퓨팅 및 네트워크 지연을 최소화하기 위한 방법입니다. 그러나 이는 고가용성 또는 내결함성보다는 고성능을 위한 구성입니다. 웹 애플리케이션의 트래픽 처리와 관련하여 여러 가용 영역에 걸쳐 분산시키는 것보다 덜 적합합니다.

문제 : 온프레미스 네트워크 연결 파일 시슽템에서 Amazon S3 Glacier로 750TB의 데이터를 전송해야 하는 상황에서, 네트워크 연결 속도가 제한된 (10Mbps) 환경에서 이를 효율적으로 수행할 방법을 찾는 것이다. 

 

A. S3 버킷에 대한 AWS Site-to-Site VPN 터널 생성 AWS CLI를 사용하여 파일을 직접 전송합니다.

• 이 방법은 데이터를 네트워크를 통해 직접 전송하는 방법입니다. 하지만 10Mbps의 느린 연결 속도를 감안할 때, 750TB의 데이터를 전송하는 데 매우 오랜 시간이 걸릴 것입니다. 따라서 이 방법은 비효율적입니다.

B. AWS Snowball Edge Storage Optimized 장치 10개를 주문하고 S3 Glacier 볼트를 대상으로 선택합니다.

• AWS Snowball Edge는 대규모 데이터 마이그레이션을 위해 설계된 물리적 장치로, 데이터를 AWS로 전송하기 위해 인터넷 대신 물리적 장치를 사용합니다. 이 방법은 네트워크 제한을 우회할 수 있으며, 대규모 데이터를 안전하고 효율적으로 AWS로 전송할 수 있는 최적의 솔루션입니다. 또한 S3 Glacier 볼트를 대상으로 선택하면 데이터가 직접 Glacier에 저장됩니다.

C. 네트워크 연결 파일 시스템을 S3 버킷에 마운트하고 파일을 직접 복사합니다. S3 수명 주기 정책을 생성하여 S3 객체를 S3 Glacier로 전환합니다.

• 이 방법은 네트워크를 통해 데이터를 직접 S3 버킷으로 전송한 다음, S3 수명 주기 정책을 사용하여 Glacier로 전환하는 방식입니다. 그러나 이 방법 역시 네트워크 속도가 느리기 때문에 대규모 데이터 전송에는 적합하지 않습니다.

D. AWS Snowball Edge Storage Optimized 장치 10개를 주문하고 S3 버킷을 대상으로 선택합니다. S3 수명 주기 정책을 생성하여 S3 객체를 S3 Glacier로 전환합니다.

• 이 방법은 Snowball Edge 장치를 사용하여 데이터를 S3 버킷으로 전송한 후, S3 수명 주기 정책을 통해 데이터를 Glacier로 이동시키는 방식입니다. 이 방법도 네트워크 속도의 영향을 받지 않지만, 데이터가 S3에 먼저 저장되기 때문에 추가적인 수명 주기 정책 설정이 필요합니다.

문제 : 온라인 마켓플레이스 웹 애플리케이션에서 금융 거래에 대한 민감한 데이터를 처리하고, 이를 다른 내부 애플리케이션과 공유하기 위한 효율적인 솔루션을 설계하는 상황입니다. 민감한 데이터를 제거하고, 짧은 검색 시간을 위해 문서 데이터베이스에 저장하기 전 트랜잭션을 처리해야 한다는 요구 사항이 주어졌습니다.

 

A. 트랜잭션 데이터를 Amazon DynamoDB에 저장. DynamoDB에 규칙을 설정하여 쓰기 시 DynamoDB 스트림을 사용하여 트랜잭션 데이터를 다른 애플리케이션과 공유.

• 장점: DynamoDB는 빠른 읽기와 쓰기 성능을 제공합니다. 또한, DynamoDB Streams는 데이터가 DynamoDB에 쓰일 때 실시간으로 이를 스트리밍하여 다른 애플리케이션과 공유할 수 있습니다.
• 단점: 이 방법은 민감한 데이터를 제거하는 과정이 포함되어 있지 않아, 요구 사항을 완전히 충족하지 못합니다.

B. 트랜잭션 데이터를 Amazon Kinesis Data Firehose로 스트리밍하여 Amazon DynamoDB 및 Amazon S3에 데이터를 저장합니다. Kinesis Data Firehose와 AWS Lambda 통합을 사용하여 민감한 데이터를 제거합니다. 다른 애플리케이션은 Amazon S3에 저장된 데이터를 사용할 수 있습니다.

• 단점: 오류 - Kinesis Data Firehose는 데이터를 DynamoDB에 직접 저장할 수 없습니다. Firehose는 데이터를 Amazon S3, Amazon Redshift, Amazon Elasticsearch Service, 및 Splunk로만 보낼 수 있습니다. 따라서 이 선택지는 잘못된 정보입니다.

C. 트랜잭션 데이터를 Amazon Kinesis Data Streams로 스트리밍합니다. AWS Lambda 통합을 사용하여 모든 트랜잭션에서 중요한 데이터를 제거한 다음 Amazon DynamoDB에 트랜잭션 데이터를 저장합니다. 다른 애플리케이션은 Kinesis Data Streams에서 트랜잭션 데이터를 사용할 수 있습니다.

• 장점: Kinesis Data Streams는 실시간으로 대규모 데이터를 스트리밍할 수 있습니다. AWS Lambda와의 통합을 통해 민감한 데이터를 실시간으로 제거하고, 처리된 데이터를 Amazon DynamoDB에 저장할 수 있습니다. 또한, 다른 애플리케이션이 Kinesis Data Streams에서 실시간으로 데이터를 사용할 수 있습니다.
• 적합성: 이 방법은 실시간 처리, 민감한 데이터 제거, 그리고 데이터 저장을 모두 제공하여 요구 사항에 가장 적합합니다.

D. Amazon S3에 배치된 트랜잭션 데이터를 파일로 저장합니다. AWS Lambda를 사용하여 Amazon S3에서 파일을 업데이트하기 전에 모든 파일을 처리하고 중요한 데이터를 제거합니다. 그런 다음 Lambda 함수는 Amazon DynamoDB에 저장된 데이터를 업데이트합니다. 다른 애플리케이션은 Amazon S3에서 저장된 트랜잭션 파일을 사용할 수 있습니다.

• 장점: 이 방법은 데이터를 S3에 저장하고 Lambda를 사용하여 처리할 수 있습니다.
• 단점: 이 방법은 실시간 처리가 아니며, 파일 기반으로 데이터를 처리하기 때문에 지연 시간이 발생할 수 있습니다. 이로 인해 “거의 실시간 솔루션”을 요구하는 상황에는 적합하지 않을 수 있습니다.

문제 : 솔루션 아키텍트가 새로운 VPC 설계를 생성 중입니다. 로드 밸런서용 퍼블릭 서브넷 2개, 웹 서버용 프라이빗 서브넷 2개, MySQL용 프라이빗 서브넷 2개 웹 서버는 HTTPS만 사용합니다. 솔루션 아키텍트는 이미 로드 밸런서를 위한 보안 그룹을 생성했습니다. 0 0 0 0/0에서 포트 443을 허용하려면 회사 정책에 따라 각 리소스에 차가 있어야 합니다. 해당 작업을 계속 수행하려면 액세스가 필요합니다. 이러한 요구 사항을 충족하기 위해 솔루션 설계자가 사용해야 하는 추가 구성 전략은 무엇입니까?

A. 웹 서버에 대한 보안 그룹 생성 및 0.0.0.0/0에서 포트 443 허용. MySQL 서버에 대한 보안 그룹 생성 및 웹 서버 보안 그룹으로부터의 포트 3306 허용

• 웹 서버에 대해 0.0.0.0/0에서 포트 443을 허용하는 것은 인터넷으로부터의 HTTPS 트래픽을 허용하는 적절한 설정입니다.
• MySQL 서버에 대해서는 웹 서버에서만 포트 3306(MySQL)이 열리도록 설정하는 것은 보안 측면에서 올바른 설정입니다. 이렇게 하면 외부에서 MySQL에 직접 접근할 수 없고, 오직 웹 서버를 통해서만 접근이 가능합니다.
• 적합성: 이 설정은 인터넷으로부터의 웹 트래픽을 허용하고, MySQL 서버는 웹 서버를 통해서만 접근할 수 있도록 제한하여 보안이 강화된 적절한 설정입니다.

B. 웹 서버에 대한 네트워크 ACL을 생성하고 0.0.0.0/0에서 포트 443을 허용. MySQL 서버에 대한 네트워크 ACL 생성 및 웹 서버 보안 그룹으로부터의 포트 3306 허용

• 네트워크 ACL은 VPC의 서브넷 수준에서 트래픽을 제어하는 기능입니다. 그러나 네트워크 ACL은 특정 인스턴스에 대한 접근 제어보다는 서브넷 수준에서 트래픽을 관리하는 용도로 사용됩니다.
• MySQL 서버에 대해 포트 3306을 네트워크 ACL로 제한하는 것은 인스턴스 수준에서 필요한 보안 제어가 아니므로, 이 방식은 비효율적일 수 있습니다.
• 적합성: 네트워크 ACL보다는 보안 그룹을 사용하는 것이 더 적절하며, 이 방법은 인스턴스 수준의 보안 설정이 부족할 수 있습니다.

C. 웹 서버에 대한 보안 그룹 생성 및 로드 밸런서로부터 포트 443 허용. MySQL 서버에 대한 보안 그룹 생성 및 웹 서버 보안 그룹으로부터의 포트 3306 허용

• 웹 서버 보안 그룹은 로드 밸런서에서 들어오는 트래픽을 허용하며, MySQL 서버에 대해서는 웹 서버 보안 그룹에서만 접근할 수 있도록 설정하는 것은 이상적인 보안 설정입니다.
• 적합성: 웹 서버와 MySQL 서버 모두 필요한 보안 수준을 제공하므로, 이 옵션도 적절한 선택입니다.

D. 웹 서버에 대한 네트워크 ACL 생성 및 로드 밸런서로부터 포트 443 허용. MySQL 서버에 대한 네트워크 ACL 생성 및 웹 서버 보안 그룹으로부터의 포트 3306 허용

• 네트워크 ACL을 사용하여 트래픽을 제어하는 것은 서브넷 수준의 트래픽을 관리할 때 유용하지만, 개별 인스턴스에 대한 세부적인 제어는 보안 그룹으로 관리하는 것이 일반적입니다.
• 적합성: 이 방법은 불필요하게 네트워크 ACL을 사용하는 설정으로, 보안 그룹을 사용하는 것보다 효율적이지 않습니다.

문제 : CloudFront를 사용하여 글로벌 사용자에게 정적 콘텐츠를 빠르게 제공하는 웹사이트에서, 애플리케이션의 고가용성을 최적화하는 방법을 묻고 있습니다. CloudFront는 전 세계에 분산된 엣지 로케이션을 사용하여 콘텐츠를 캐시하고, 사용자에게 가장 가까운 위치에서 빠르게 제공하는 콘텐츠 전송 네트워크(CDN)입니다. 여기에서 선택지는 CloudFront와 관련된 다양한 최적화 전략입니다.

 

A. CloudFront에 Lambda@Edge 사용

• Lambda@Edge는 CloudFront 엣지 로케이션에서 Lambda 함수를 실행할 수 있는 기능입니다. 이를 통해 요청 또는 응답을 처리하는 동안 코드 실행이 가능합니다. 주로 HTTP 요청을 맞춤화하거나, 헤더 수정, 리다이렉션, 권한 부여 등의 작업을 처리할 수 있습니다. 하지만 이는 주로 콘텐츠의 맞춤화 및 요청 처리 로직에 활용되며, 고가용성 자체를 크게 향상시키지는 않습니다.
• 적합성: 이 선택지는 콘텐츠 전달을 맞춤화할 수 있지만, 애플리케이션의 고가용성 최적화와는 직접적인 연관이 부족합니다.

B. CloudFront에 Amazon S3 Transfer Acceleration 사용

•  Amazon S3 Transfer Acceleration은 S3 버킷으로 데이터를 업로드할 때, CloudFront 엣지 로케이션을 사용해 전송 속도를 가속화하는 기능입니다. 이 기능은 주로 데이터 업로드 성능을 높이기 위한 것이며, 애플리케이션의 콘텐츠 전송 속도를 최적화하는 데 도움을 줍니다. 그러나 이 역시 고가용성 자체와는 직접적인 관련이 없습니다.
• 적합성: 이 옵션은 데이터 업로드 성능 최적화에 적합하나, 고가용성 측면에서는 부적합합니다.

C. 다른 가용 영역에 다른 EC2 인스턴스를 오리진 그룹의 일부로 구성

• 오리진 그룹(Origin Group)은 CloudFront가 여러 오리진 서버에 요청을 분배할 수 있도록 설정하는 기능입니다. 오리진 그룹은 기본 오리진이 실패하면 대체 오리진으로 요청을 리디렉션하는 기능을 제공합니다. 따라서 이 방법을 사용하면 고가용성이 크게 향상됩니다. 다른 가용 영역(AZ)에 여러 EC2 인스턴스를 배치하여 오리진 그룹을 구성하면, 한 인스턴스 또는 가용 영역에 문제가 발생해도 다른 인스턴스를 통해 서비스를 지속할 수 있습니다.
• 적합성: 이 선택지는 애플리케이션의 고가용성을 최적화하는 매우 적절한 방법입니다.

D. 동일한 가용 영역에서 원본 서버 클러스터의 일부로 다른 EC2 인스턴스를 구성

• 설명: 동일한 가용 영역 내에서 추가 인스턴스를 구성하는 것은 성능을 향상시킬 수 있지만, 가용성 측면에서는 불리할 수 있습니다. 한 가용 영역(AZ)에서 문제가 발생하면 해당 영역의 모든 인스턴스에 접근할 수 없기 때문에, 고가용성을 확보하는 데는 적합하지 않습니다.
• 적합성: 이 방법은 고가용성 측면에서는 적절하지 않습니다.

문제 : 회사는 교차 통신을 허용하기 위해 단일 리전에서 VPC를 연결하기 위해 VPC 피어링 전략을 사용하고 있습니다. 최근 계정 생성 및 VPC가 증가하면서 VPC 피어링 전략을 유지하기가 어려워졌으며 회사는 수백 개의 VPC로 성장할 것으로 예상하고 있습니다. 일부 VPC에서 사이트 간 VPN을 생성하라는 새로운 요청도 있습니다. 솔루션 설계자는 여러 계정, VPC 및 VPN에 대한 중앙 관리형 네트워킹 설정을 생성하는 임무를 받았습니다.

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

 

A. 공유 VPC와 VPN을 구성하여 서로 공유합니다.

• 공유 VPC는 여러 AWS 계정이 하나의 VPC를 공유할 수 있게 하여 리소스의 효율적인 배포와 관리가 가능하도록 합니다. 그러나 공유 VPC는 계정 간 리소스 공유에 초점을 맞춘 것이므로, 여러 VPC와 VPN 간의 중앙 관리형 연결 요구 사항을 충족시키지 않습니다.
• 적합성: 이 방법은 계정 간의 리소스 공유에는 유리할 수 있지만, 여러 VPC 및 VPN을 연결하는 데는 적합하지 않습니다.

B. 허브 및 스포크 VPC를 구성하고 VPC 피어링을 통해 모든 트래픽을 라우팅합니다.

• 허브 및 스포크 방식은 하나의 중앙 허브 VPC를 통해 여러 스포크 VPC를 연결하는 방식입니다. VPC 피어링은 두 VPC 간의 직접적인 통신을 허용하는 방법이지만, 많은 VPC가 있을 경우 관리가 매우 복잡해집니다. 이 구조는 수백 개의 VPC가 연결된 경우에는 확장성의 한계가 있습니다.
• 적합성: VPC 피어링은 큰 규모의 VPC 및 VPN 환경에서 관리와 확장성이 부족하기 때문에 적합하지 않습니다.

C. 모든 VPC와 VPN 간에 AWS Direct Connect 연결을 구성합니다.

• AWS Direct Connect는 온프레미스 네트워크와 AWS 간의 전용 물리적 연결을 제공하여 네트워크 성능을 향상시키는 솔루션입니다. 하지만, 이 옵션은 VPC 간 연결보다는 온프레미스와 AWS 간의 연결에 더 적합하며, VPC 및 VPN 간의 중앙 관리형 네트워크 설정을 해결하는 데는 적합하지 않습니다.
• 적합성: Direct Connect는 온프레미스와의 연결에 사용되는 것이므로, VPC 및 VPN 간의 중앙 집중형 연결 요구 사항을 충족시키지는 못합니다.

D. Transit Gateway로 Transit Gateway를 구성하고 모든 VPC와 VPN을 연결합니다.

• 설명: AWS Transit Gateway는 여러 VPC와 온프레미스 네트워크(VPN 포함)를 중앙에서 연결하고 관리할 수 있는 서비스입니다. 트래픽은 Transit Gateway를 통해 효율적으로 라우팅되며, 수백 개의 VPC가 연결된 환경에서도 확장성이 뛰어납니다. 또한, 중앙 집중형 관리가 가능해 대규모 네트워크에서 최적의 솔루션입니다.
• 적합성: 이 방법은 여러 VPC 및 VPN 간의 중앙 관리형 연결과 확장성을 제공하여 요구 사항을 완벽히 충족시킵니다.

문제 : 한 회사에서 새로운 온라인 게임 애플리케이션을 개발 중입니다. 애플리케이션은 여러 AWS 리전의 Amazon EC2 인스턴스에서 실행되며 전 세계적으로 많은 수의 사용자가 분산됩니다. 솔루션 설계자는 사용자의 네트워크 지연 시간을 최적화하도록 애플리케이션을 설계해야 합니다.

이러한 요구 사항을 충족하기 위해 솔루션 설계자는 어떤 조치를 취해야 합니까? (2개를 선택하십시오.)

A. AWS Global Accelerator 구성 EC2 집합이 호스팅되는 각 리전에서 리전 엔드포인트 그룹 생성

• 설명: AWS Global Accelerator는 여러 AWS 리전에서 실행 중인 애플리케이션을 전 세계적으로 사용자가 빠르게 액세스할 수 있도록 트래픽을 최적화합니다. Global Accelerator는 전 세계에 있는 사용자를 가장 가까운 AWS 네트워크 엣지 로케이션으로 라우팅하고, 최적의 리전으로 트래픽을 전송하여 네트워크 성능을 크게 향상시킬 수 있습니다. 특히 실시간 애플리케이션이나 게임과 같이 지연 시간이 중요한 경우 매우 유용합니다.
• 적합성: 지연 시간을 최소화하기 위한 매우 적합한 솔루션입니다.

B. Amazon CloudFront를 사용하여 콘텐츠 전송 네트워크(CDN) 생성 정적 및 동적 콘텐츠에 대한 캐싱 활성화 및 높은 만료 기간 지정

• 설명: CloudFront는 AWS의 콘텐츠 전송 네트워크(CDN)로, 정적 및 동적 콘텐츠를 전 세계 엣지 로케이션에 캐싱하여 사용자에게 가장 가까운 곳에서 제공할 수 있습니다. 이를 통해 게임 애플리케이션의 정적 콘텐츠(이미지, HTML 파일 등)와 동적 콘텐츠의 전송 속도를 높일 수 있습니다.
• 적합성: CDN을 사용하여 지연 시간을 줄이는 적합한 선택지입니다.

C. AWS Client VPN을 애플리케이션에 통합합니다. 사용자에게 애플리케이션을 시작한 후 가장 가까운 리전을 선택하도록 지시합니다. 해당 지역에 대한 VPN 연결 설정

• 설명: AWS Client VPN은 사용자가 안전한 방식으로 AWS 리소스에 연결할 수 있도록 하는 서비스입니다. 하지만 이 방법은 VPN을 통한 연결이므로 일반적으로 네트워크 성능을 크게 향상시키지 않으며, 지연 시간을 줄이는 데 효과적이지 않을 수 있습니다. 이 방법은 지연 시간을 줄이는 데 적합하지 않습니다.
• 적합성: 지연 시간을 줄이는 데 적합하지 않습니다.

D. Amazon Route 53 가중 라우팅 정책 생성 리전 전에서 사용자 수가 가장 많은 EC2 인스턴스에 가장 높은 가중치를 부여하도록 라우팅 정책을 구성합니다.

• 설명: Route 53의 가중 라우팅 정책은 트래픽을 여러 리전 또는 EC2 인스턴스 간에 분배할 수 있는 방법입니다. 각 리전에 가중치를 설정하여 트래픽을 비율에 맞게 분배할 수 있습니다. 이 방법은 특정 리전에 트래픽을 집중시킬 수 있으므로, 리소스 사용량이 불균형하게 분배될 수 있는 단점이 있습니다.
• 적합성: 여러 리전에서 트래픽을 관리하는 데는 적합하지 않으며, 지연 시간 최적화보다는 트래픽 분배에 초점이 맞춰져 있습니다.

E. EC2 집합이 호스팅되는 각 리전에서 Amazon API Gateway 엔드포인트 구성 애플리케이션을 선택한 후 사용자에게 가장 가까운 리전을 선택하도록 지시합니다. 가장 가까운 API 엔드포인트를 사용하십시오.

• 설명: API Gateway는 주로 API 요청을 관리하는 데 사용되며, 전 세계 사용자에게 API 요청을 전달하기 위한 엔드포인트 구성으로도 사용할 수 있습니다. 하지만 이 방법은 게임 애플리케이션의 전체적인 지연 시간을 최적화하는 데는 직접적인 연관성이 크지 않습니다. 특히 실시간 사용자 트래픽 라우팅이나 네트워크 최적화에는 적합하지 않습니다. API는 온라인 게임 사용자 연결을 위한 솔루션이 아닌 애플리케이션 인터페이스 솔루션이다.
• 적합성: 지연 시간 최적화와는 직접적으로 적합하지 않습니다.