본문 바로가기
AWS/SAA 준비

AWS SAA 합격으로 가는 길 #7: [EC2 인스턴스] 마스터하기

by Pacloud 2024. 8. 23.
반응형

안녕하세요, AWS SAA(Solution Architect Associate) 자격증을 준비하시는 여러분!

저는 넥스트클라우드에서 SA로 활동하고 있는 강준우라고 합니다. 😊

 

문제는 세 가지 단계를 거치며 풀어나갈 거예요:

 

  1. 문제의 요구사항 분석하기
  2. 관련 AWS 서비스 생각하기
  3. 선택지 분석하기

 

자, 그럼 첫 번째 문제부터 살펴볼까요?


문제

회사는 단일 VPC의 Amazon EC2 인스턴스에서 고가용성 이미지 처리 애플리케이션을 실행합니다. EC2 인스턴스는 여러 가용 영역에 걸쳐 여러 서브넷 내에서 실행됩니다. EC2 인스턴스는 서로 통신하지 않습니다. 그러나 EC2 인스턴스는 Amazon S3에서 이미지를 다운로드하고 단일 NAT 게이트웨이를 통해 Amazon S3에 이미지를 업로드 합니다. 회사는 데이터 전송 요금에 대해 우려하고 있습니다.

회사가 지역 데이터 전송 요금을 피하는 가장 비용 효율적인 방법은 무엇입니까?

선택지

1. 각 가용 영역에서 NAT 게이트웨이를 시작합니다.

2. NAT 게이트웨이를 NAT 인스턴스로 교체합니다.

3. Amazon S3용 게이트 웨이 VPC 엔드포인트를 배포합니다.

4. EC2 인스턴스를 실행할 EC2 전용 호스트를 프로비저닝 합니다.


요구사항에 맞는 서비스

1. 단일 NAT 게이트웨이를 통해 Amazon S3에 업로드

  • Amazon S3에 대한 게이트웨이 엔드포인트 : VPC에서 게이트웨이 VPC 엔드포인트를 사용하여 Amazon S3에 액세스할 수 있습니다. 게이트웨이 엔드포인트를 생성한 후 VPC에서 Amazon S3로 전송되는 트래픽에 대해 해당 엔드포인트를 라우팅 테이블의 대상으로 추가할 수 있습니다. 게이트웨이 엔드포인트 사용에 따르는 추가 요금은 없습니다.

최적의 정답 선택하기

선택지 1번은 “각 가용 영역에서 NAT 게이트웨이를 시작합니다.”입니다.

 선택지가 정답이 아닌 이유는 각 가용 영역에 NAT 게이트웨이를 배포하는 것은 고가용성을 높일 수 있지만, NAT 게이트웨이는 인터넷을 통해 데이터를 전송하기 때문에 여전히 데이터 전송 요금이 발생하기 때문에 정답이 아닙니다.

 

선택지 2번은 “NAT 게이트웨이를 NAT 인스턴스로 교체합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 NAT 인스턴스는 NAT 게이트웨이에 비해 비용을 절감할 수는 있지만, 여전히 인터넷을 통해 데이터를 전송하기 때문에 데이터 전송 요금이 발생합니다. 따라서 지역 데이터 전송 요금을 줄이는 가장 비용 효율적인 방법이 아닙니다.

 

선택지 3번은 "Amazon S3용 게이트 웨이 VPC 엔드포인트를 배포합니다.”입니다.

 이 선택지는 EC2가 S3에 업로드 및 다운로드 과정에서 가장 비용 효율적인 방법입니다. Amazon S3와의 통신이 인터넷을 경유하지 않고 AWS 네트워크 내에서 이루어지기 때문에 데이터 전송 요금이 발생하지 않습니다. 이는 가장 비용 효율적인 방법입니다. 게이트웨이 VPC 엔드포인트는 VPC 내부의 리소스가 S3에 액세스할 수 있게 하며, 데이터 전송이 AWS 네트워크 내부에서 이루어지므로 지역 간 데이터 전송 요금이 발생하지 않기 때문에 가장 비용 효율적인 방법이므로 정답입니다.

 

선택지 4번은 “EC2 인스턴스를 실행할 EC2 전용 호스트를 프로비저닝 합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 EC2 전용 호스트를 사용하면 라이선스 비용을 절감할 수 있지만, 데이터 전송 요금 문제와는 관련이 없습니다. 또한 전용 호스트는 보통 비용 절감보다는 규정 준수나 특정 요구 사항을 만족시키기 위해 사용되기 때문에 데이터 전송 요금 문제를 해결하지 못합니다.

 

 

문제에 대한 정답은 선택지 3번입니다!

자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

더보기
더보기

첫 번째 과정은 “문제의 요구사항 분석하기”입니다.

이 문제에서는 1가지의 요구사항이 존재해요. 

  1. EC2 인스턴스가 Amazon S3에서 이미지를 다운로드하고 단일 NAT 게이트웨이를 통해 Amazon S3에 이미지를 업로드할 때 가장 비용 효율적인 방법

 

두 번째 과정은 “요구사항과 관련된 AWS 서비스 생각하기”입니다.

1. 단일 NAT 게이트웨이를 통해 Amazon S3에 이미지를 업로드

  • Amazon S3에 대한 게이트웨이 엔드포인트 : VPC에서 게이트웨이 VPC 엔드포인트를 사용하여 Amazon S3에 액세스할 수 있습니다. 게이트웨이 엔드포인트를 생성한 후 VPC에서 Amazon S3로 전송되는 트래픽에 대해 해당 엔드포인트를 라우팅 테이블의 대상으로 추가할 수 있습니다. 게이트웨이 엔드포인트 사용에 따르는 추가 요금은 없습니다.

 

마지막 과정은 “위의 정보들을 토대로 정답 선택하기”입니다.

선택지 1번은 "각 가용 영역에서 NAT 게이트웨이를 시작합니다." 입니다.

  • NAT 게이트 웨이 : VPC에서 프라이빗 서브넷에 있는 인스턴스가 인터넷으로 나가는 트래픽을 허용하는 AWS 관리형 서비스입니다.

이 선택지가 정답이 아닌 이유는 각 가용 영역에 NAT 게이트웨이를 배포하는 것은 고가용성을 높일 수 있지만, NAT 게이트웨이는 인터넷을 통해 데이터를 전송하기 때문에 여전히 데이터 전송 요금이 발생하기 때문에 정답이 아닙니다.

 

선택지 2번은 "NAT 게이트웨이를 NAT 인스턴스로 교체합니다." 입니다.

  • NAT 인스턴스 : VPC에서 NAT 기능을 수행하는 EC2 인스턴스입니다. 프라이빗 서브넷에 있는 인스턴스가 인터넷에 접속할 수 있게 하며, 이 인스턴스로 직접적인 외부 트래픽을 차단합니다.

이 선택지가 정답이 아닌 이유는 NAT 인스턴스는 NAT 게이트웨이에 비해 비용을 절감할 수는 있지만, 여전히 인터넷을 통해 데이터를 전송하기 때문에 데이터 전송 요금이 발생합니다. 따라서 지역 데이터 전송 요금을 줄이는 가장 비용 효율적인 방법이 아닙니다.

 

선택지 3번은 "Amazon S3용 게이트 웨이 VPC 엔드포인트를 배포합니다. " 입니다.

  • Amazon S3용 게이트웨이 VPC 엔드포인트 : VPC에서 게이트웨이 VPC 엔드포인트를 사용하여 Amazon S3에 액세스할 수 있습니다.

선택지가 정답인 이유는 Amazon S3와의 통신이 인터넷을 경유하지 않고 AWS 네트워크 내에서 이루어지기 때문에 데이터 전송 요금이 발생하지 않습니다. 이는 가장 비용 효율적인 방법입니다. 게이트웨이 VPC 엔드포인트는 VPC 내부의 리소스가 S3에 액세스할 수 있게 하며, 데이터 전송이 AWS 네트워크 내부에서 이루어지므로 지역 간 데이터 전송 요금이 발생하지 않습니다.

 

선택지 4번은 "EC2 인스턴스를 실행할 EC2 전용 호스트를 프로비저닝 합니다." 입니다.

  • EC2 전용 호스트 : 고객에게 물리적으로 완전히 격리된 EC2 서버를 제공하여 사용자의 특정 요구 사항을 충족할 수 있는 AWS 서비스입니다.

이 선택지가 정답이 아닌 이유는 EC2 전용 호스트를 사용하면 라이선스 비용을 절감할 수 있지만, 데이터 전송 요금 문제와는 관련이 없습니다. 또한 전용 호스트는 보통 비용 절감보다는 규정 준수나 특정 요구 사항을 만족시키기 위해 사용되기 때문에 데이터 전송 요금 문제를 해결하지 못합니다.

 

 

이어서 두 번째 문제 살펴볼게요.


문제

한 회사가 프로덕션 애플리케이션의 재해 복구(DR) 전략을 설계하고 있습니다. 애플리케이션은 us-east-1 지역의 Amazon Aurora 클러스터에 있는 MySQL 데이터베이스의 지원을 받습니다. 회사는 us-west-1 지역을 DR지역으로 선택했습니다.

회사의 목표 복구 지점 목표(RPO)는 5분이고 목표 복구 시간 목표(RTO)는 20분입니다. 회사에서는 구성 변경을 최소화하려고 합니다.

가장 효율적인 운영 효율성으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

선택지

1. 프로덕션 애플리케이션의 Aurora MySQL 클러스터 라이터 인스턴스와 비슷한 크기로 us-west-1에 Aurora 읽기 전용본을 생성합니다.

2. Aurora 클러스터를 Aurora 글로벌 데이터베이스로 변환하십시오. 관리형 장애 조치를 구성합니다.

3. 교차 리전 복제 기능이 있는 us-west-1에 새 Aurora 클러스터를 생성합니다.

4. us-west-1에 새 Aurora 클러스터를 생성합니다. AWS Database Migration Service(AWS DMS)를 사용하여 두 클러스터를 모두 동기화 합니다.


요구사항에 맞는 서비스

1. 재해 복구 전략 설계와 가장 효율적인 운영 효율성

    • Amazon Aurora Global Database : 여러 AWS 리전에 걸쳐 데이터베이스를 복제하여 글로벌 애플리케이션의 가용성을 높이고 재해 복구 시간을 최소화할 수 있습니다. Aurora Global Database는 리전 간 데이터 복제를 1초 미만의 지연 시간으로 제공하며, 재해 발생 시 DR 리전으로의 페일오버 시간을 최소화할 수 있습니다.
    • Amazon RDS Multi-AZ 배포: 고가용성을 보장하기 위해 RDS에서 지원하는 기능으로, 자동으로 데이터를 여러 가용 영역(AZ)에 복제합니다. 이 설정을 통해 DR 리전에서 데이터베이스를 신속하게 복구할 수 있으며, RTO 및 RPO 요구사항을 충족할 수 있습니다.

2. 목표 복구 지점 목표 5분, 목표 복구 시간 목표 20분 및 구상 변경 최소화

  • 목표 복구 지점 목표 
    • Amazon Aurora Backtrack: 특정 시점으로 데이터베이스를 신속하게 복구할 수 있는 기능으로, RPO를 효과적으로 관리할 수 있습니다. Backtrack을 사용하면 데이터 손실을 최소화하면서 매우 빠른 시간 내에 복구할 수 있습니다.
  • 목표 복구 시간 목표
    • AWS Elastic Disaster Recovery (DRS): 애플리케이션을 다른 AWS 리전으로 신속하게 복구할 수 있는 서비스로, RTO를 20분 이내로 달성할 수 있도록 지원합니다. DRS는 재해 발생 시 자동으로 복구를 시작하고 필요한 리소스를 프로비저닝합니다.
  • 구상 변경 최소화
    • AWS CloudFormation: 인프라를 코드로 관리하는 서비스로, DR 환경을 기존 프로덕션 환경과 동일하게 설정할 수 있습니다. 기존 환경을 변경하지 않고 DR 환경을 자동으로 설정하고 관리할 수 있어 구성 변경을 최소화할 수 있습니다.

최적의 정답 선택하기

선택지 1번은 “프로덕션 애플리케이션의 Aurora MySQL 클러스터 라이터 인스턴스와 비슷한 크기로 us-west-1에 Aurora 읽기 전용본을 생성합니다.”입니다.

선택지가 정답이 아닌 이유는 읽기 전용본은 주로 읽기 작업을 분산시켜 성능을 최적화하기 위한 용도입니다. 이 선택지는 DR(재해 복구) 환경에서 중요한 쓰기 기능을 지원하지 않으며, us-west-1에서의 장애 조치 시 RTO 및 RPO 요구사항을 충족하지 못할 가능성이 높습니다.

 

선택지 2번은 “Aurora 클러스터를 Aurora 글로벌 데이터베이스로 변환하십시오. 관리형 장애 조치를 구성합니다.”입니다.

→ 이 선택지가 정답인 이유는 Aurora 글로벌 데이터베이스는 RPO 5분, RTO 20분의 요구사항을 충족할 수 있는 가장 적합한 선택지입니다. 관리형 장애 조치를 통해 DR 리전으로 신속하게 페일오버가 가능하며, 구성 변경도 최소화할 수 있기 때문에 정답입니다.

 

선택지 3번은 “교차 리전 복제 기능이 있는 us-west-1에 새 Aurora 클러스터를 생성합니다.”입니다.

 선택지가 정답이 아닌 이유는 교차 리전 복제는 Aurora 글로벌 데이터베이스에 비해 RTO와 RPO를 보장하기에 충분하지 않을 수 있으며, 수동으로 장애 조치를 구성하는 데 추가적인 운영 오버헤드가 발생할 수 있습니다. 관리형 장애 조치 기능이 없는 점이 단점입니다.

 

선택지 4번은 “us-west-1에 새 Aurora 클러스터를 생성합니다. AWS Database Migration Service(AWS DMS)를 사용하여 두 클러스터를 모두 동기화합니다.”입니다.

 선택지가 정답이 아닌 이유는 DMS를 사용한 동기화는 Aurora 글로벌 데이터베이스의 관리형 복제 및 장애 조치 기능에 비해 운영 오버헤드가 크고, 복구 시간도 더 길어질 수 있습니다. 또한, DMS는 주로 마이그레이션 작업에 사용되므로 DR 환경에서 실시간 동기화로 RTO와 RPO를 충족하기 어렵습니다.

 

 

문제에 대한 정답은 선택지 2번입니다!

자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

더보기
더보기

첫 번째 과정은 “문제의 요구사항 분석하기”입니다.

이 문제에서는 3가지의 요구사항이 존재해요. 

  1. 재해 복구 전략 설계와 가장 효율적인 운영 효율성(즉, 고가용성)
  2. 목표 복구 지점 목표 5분, 목표 복구 시간 목표 20분
  3. 구상 변경 최소화

 

두 번째 과정은 “요구사항과 관련된 AWS 서비스 생각하기”입니다.

1. 재해 복구 전략 설계

  • Amazon Aurora Global Database : 여러 AWS 리전에 걸쳐 데이터베이스를 복제하여 글로벌 애플리케이션의 가용성을 높이고 재해 복구 시간을 최소화할 수 있습니다. Aurora Global Database는 리전 간 데이터 복제를 1초 미만의 지연 시간으로 제공하며, 재해 발생 시 DR 리전으로의 페일오버 시간을 최소화할 수 있습니다.
  • Amazon RDS Multi-AZ 배포: 고가용성을 보장하기 위해 RDS에서 지원하는 기능으로, 자동으로 데이터를 여러 가용 영역(AZ)에 복제합니다. 이 설정을 통해 DR 리전에서 데이터베이스를 신속하게 복구할 수 있으며, RTO 및 RPO 요구사항을 충족할 수 있습니다.

2. 목표 복구 지점 목표, 목표 복구 시간 목표

  • Amazon RDS Multi-AZ 배포: 고가용성을 보장하기 위해 RDS에서 지원하는 기능으로, 자동으로 데이터를 여러 가용 영역(AZ)에 복제합니다. 이 설정을 통해 DR 리전에서 데이터베이스를 신속하게 복구할 수 있으며, RTO 및 RPO 요구사항을 충족할 수 있습니다.
  • AWS Backup: AWS 리소스에 대한 백업을 자동화하고 관리하는 서비스로, 데이터베이스의 백업 주기를 5분 이내로 설정하여 RPO 요구사항을 충족할 수 있습니다.
  • AWS Elastic Disaster Recovery (DRS): 애플리케이션을 다른 AWS 리전으로 신속하게 복구할 수 있는 서비스로, RTO를 20분 이내로 달성할 수 있도록 지원합니다. DRS는 재해 발생 시 자동으로 복구를 시작하고 필요한 리소스를 프로비저닝합니다.

3. 구상 변경 최소화

  • AWS CloudFormation: 인프라를 코드로 관리하는 서비스로, DR 환경을 기존 프로덕션 환경과 동일하게 설정할 수 있습니다. 기존 환경을 변경하지 않고 DR 환경을 자동으로 설정하고 관리할 수 있어 구성 변경을 최소화할 수 있습니다.
  • AWS Systems Manager: 인프라 관리 및 운영을 위한 서비스로, 구성 변경 없이 기존 환경의 설정을 자동으로 복제하고 관리할 수 있습니다. Systems Manager를 사용하면 애플리케이션 구성의 일관성을 유지하면서 DR 환경을 설정할 수 있습니다.

 

 

마지막 과정은 “위의 정보들을 토대로 정답 선택하기”입니다.

선택지 1번은 "프로덕션 애플리케이션의 Aurora MySQL 클러스터 라이터 인스턴스와 비슷한 크기로 us-west-1에 Aurora 읽기 전용본을 생성합니다. " 입니다.

  • Aurora 읽기 전용본: Amazon Aurora의 읽기 전용 복제본은 기본적으로 고가용성을 제공하며, 다중 가용 영역(AZ) 간에 복제할 수 있습니다. 그러나 읽기 전용본은 쓰기 작업을 지원하지 않으며, 장애 발생 시 읽기 전용본을 사용하여 즉각적인 복구를 수행할 수 없습니다. 따라서, 이 접근 방식은 재해 복구(RTO, RPO) 요구사항을 충족하기에는 적합하지 않습니다.

이 선택지가 정답이 아닌 이유는 읽기 전용본은 주로 읽기 작업을 분산시켜 성능을 최적화하기 위한 용도입니다. 이 선택지는 DR(재해 복구) 환경에서 중요한 쓰기 기능을 지원하지 않으며, us-west-1에서의 장애 조치 시 RTO 및 RPO 요구사항을 충족하지 못할 가능성이 높습니다.

 

선택지 2번은 "Aurora 클러스터를 Aurora 글로벌 데이터베이스로 변환하십시오. 관리형 장애 조치를 구성합니다 " 입니다.

  • Aurora 글로벌 데이터베이스: 여러 리전 간의 데이터 복제를 지원하는 기능으로, 하나의 Aurora 데이터베이스를 여러 리전에 걸쳐 운영할 수 있습니다. 글로벌 데이터베이스는 리전 간 1초 미만의 지연 시간으로 데이터를 복제하며, 재해 발생 시 빠르게 다른 리전으로 장애 조치를 수행할 수 있습니다.

이 선택지가 정답인 이유는 Aurora 글로벌 데이터베이스는 RPO 5분, RTO 20분의 요구사항을 충족할 수 있는 가장 적합한 선택지입니다. 관리형 장애 조치를 통해 DR 리전으로 신속하게 페일오버가 가능하며, 구성 변경도 최소화할 수 있기 때문에 정답입니다.

 

선택지 3번은 "교차 리전 복제 기능이 있는 us-west-1에 새 Aurora 클러스터를 생성합니다. " 입니다.

  • 교차 리전 복제: 교차 리전 복제는 AWS에서 지원하는 기능으로, 두 리전 간에 데이터베이스를 복제하여 고가용성을 보장합니다. 그러나 이 방법은 Aurora 글로벌 데이터베이스와 달리 복제 지연이 발생할 수 있으며, 수동으로 장애 조치를 수행해야 할 수 있습니다.

이 선택지가 정답이 아닌 이유는 교차 리전 복제는 Aurora 글로벌 데이터베이스에 비해 RTO와 RPO를 보장하기에 충분하지 않을 수 있으며, 수동으로 장애 조치를 구성하는 데 추가적인 운영 오버헤드가 발생할 수 있습니다. 관리형 장애 조치 기능이 없는 점이 단점이기 때문에 정답이 아닙니다.

 

선택지 4번은 "us-west-1에 새 Aurora 클러스터를 생성합니다. AWS Database Migration Service(AWS DMS)를 사용하여 두 클러스터를 모두 동기화합니다." 입니다.

  • AWS Database Migration Service (DMS): DMS는 데이터베이스 간의 실시간 동기화 및 마이그레이션을 지원하는 서비스입니다. 이 방법을 사용하면 두 클러스터 간의 데이터를 동기화할 수 있지만, 실시간으로 모든 데이터를 동기화하는 데 지연이 발생할 수 있으며, 운영 오버헤드가 증가할 수 있습니다.

이 선택지가 정답이 아닌 이유는 DMS를 사용한 동기화는 Aurora 글로벌 데이터베이스의 관리형 복제 및 장애 조치 기능에 비해 운영 오버헤드가 크고, 복구 시간도 더 길어질 수 있습니다. 또한, DMS는 주로 마이그레이션 작업에 사용되므로 DR 환경에서 실시간 동기화로 RTO와 RPO를 충족하기 어렵습니다.

 

 

마지막 문제 살펴볼게요.


문제

회사는 ALB(Application Load Balancer) 뒤에 있는 Amazon EC2 인스턴스에서 웹 사이트를 호스팅합니다. 웹사이트는 정적 콘텐츠를 제공합니다. 웹사이트 트래픽이 증가하고 있습니다. 회사는 웹사이트 호스팅 비용을 최소화하려고 합니다.

이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

선택지

1. 웹 사이트를 Amazon S3 버킷으로 이동합니다. S3 버킷에 대한 Amazon CloudFront 배포를 구성합니다.

2. 웹 사이트를 Amazon S3 버킷으로 이동합니다. S3 버킷에 대한 Amazon ElastiCache 클러스터를 구성합니다.

3. 웹 사이트를 AWS Amplify로 미동합니다. Amplify 웹 사이트를 확인하도록 ALB를 구성합니다.

4. 웹 사이트를 AWS Amplify로 이동합니다. 웹 사이트를 캐시하도록 EC2 인스틴스를 구성합니다.


요구사항에 맞는 서비스

1. 정적 콘텐츠 호스팅과 호스팅 비용 최소

  • Amazon S3 : Amazon S3는 확장성이 뛰어나고 내구성이 높은 객체 스토리지 서비스입니다. 정적 웹 콘텐츠를 호스팅하는 데 매우 적합하며, 정적 웹사이트를 S3에 호스팅하면 비용을 크게 절감할 수 있습니다. 정적 콘텐츠는 S3를 통해 직접 제공되며, 서버 측 관리가 필요하지 않아 운영 오버헤드가 줄어듭니다.

2. 트래픽 증가 대비

  • Amazon CloudFront : Amazon CloudFront는 콘텐츠 전송 네트워크(CDN) 서비스로, 웹사이트의 정적 콘텐츠를 전 세계 엣지 로케이션에서 캐시하여 사용자에게 신속하게 제공할 수 있습니다. 이를 통해 트래픽 증가에도 빠른 응답 속도를 유지할 수 있습니다. CloudFront를 사용하면 S3와 연계하여 전 세계 사용자에게 빠르게 정적 콘텐츠를 제공할 수 있으며, 동시에 S3에서 발생하는 트래픽을 줄여 비용을 절감할 수 있습니다.
    •  

최적의 정답 선택하기

선택지 1번은 “웹 사이트를 Amazon S3 버킷으로 이동합니다. S3 버킷에 대한 Amazon CloudFront 배포를 구성합니다. ”입니다.

이 선택지가 정답인 이유는 정적 콘텐츠를 제공하는 웹사이트의 요구사항에 가장 적합한 솔루션입니다. S3와 CloudFront를 결합하면 트래픽이 증가해도 비용 효율적으로 대응할 수 있으며, 웹사이트의 성능도 향상됩니다. 또한, 서버리스 아키텍처이므로 운영 오버헤드가 매우 낮기 때문에 정답입니다.

 

선택지 2번은 “웹 사이트를 Amazon S3 버킷으로 이동합니다. S3 버킷에 대한 Amazon ElastiCache 클러스터를 구성합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 Amazon ElastiCache는 주로 데이터베이스 성능을 개선하기 위한 서비스로, 정적 콘텐츠를 제공하는 S3와 결합할 때는 큰 이점을 제공하지 않습니다. 또한, S3 자체가 이미 정적 콘텐츠를 효과적으로 제공할 수 있기 때문에, ElastiCache를 추가하는 것은 불필요한 복잡성을 초래할 수 있습니다. 따라서 이 선택지는 트래픽 증가에 대한 비용 절감 요구사항을 제대로 충족하지 못합니다.

 

선택지 3번은 " 웹 사이트를 AWS Amplify로 이동합니다. Amplify 웹 사이트를 확인하도록 ALB를 구성합니다.”입니다.

 선택지가 정답이 아닌 이유는 AWS Amplify는 웹 애플리케이션을 빠르게 배포하고 관리하는 데 유용하지만, 정적 콘텐츠 제공을 위한 비용 최적화에는 S3와 CloudFront 조합만큼 효과적이지 않습니다. 또한, ALB를 사용하면 EC2 인스턴스 비용이 발생할 수 있어 비용 절감 목표와 상충될 수 있습니다.

 

선택지 4번은 “웹 사이트를 AWS Amplify로 이동합니다. 웹 사이트를 캐시하도록 EC2 인스턴스를 구성합니다.”입니다.

→ 선택지가 정답이 아닌 이유는 AWS Amplify와 EC2 인스턴스를 사용하여 웹사이트를 호스팅하고 캐시하도록 제안합니다. 그러나 EC2 인스턴스는 비용이 추가로 발생하며, 정적 콘텐츠를 제공하는 데 있어 S3와 CloudFront 조합만큼 비용 효율적이지 않습니다. 또한, EC2에서 캐싱을 관리하는 것은 운영 오버헤드를 증가시킬 수 있습니다.

 

 

문제에 대한 정답은 선택지 1번입니다!

자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

더보기
더보기

첫 번째 과정은 “문제의 요구사항 분석하기”입니다.

이 문제에서는 2가지의 요구사항이 존재해요. 

  1. 정적 콘텐츠 호스팅과 호스팅 비용 최소화
  2. 트래픽 증가

 

두 번째 과정은 “요구사항과 관련된 AWS 서비스 생각하기”입니다.

1. 정적 콘텐츠 호스팅과 호스팅 비용 최소화

  • Amazon S3 : Amazon S3는 확장성이 뛰어나고 내구성이 높은 객체 스토리지 서비스입니다. 정적 웹 콘텐츠를 호스팅하는 데 매우 적합하며, 정적 웹사이트를 S3에 호스팅하면 비용을 크게 절감할 수 있습니다. 정적 콘텐츠는 S3를 통해 직접 제공되며, 서버 측 관리가 필요하지 않아 운영 오버헤드가 줄어듭니다.

2. 트래픽 증가

  • Amazon CloudFront : Amazon CloudFront는 콘텐츠 전송 네트워크(CDN) 서비스로, 웹사이트의 정적 콘텐츠를 전 세계 엣지 로케이션에서 캐시하여 사용자에게 신속하게 제공할 수 있습니다. 이를 통해 트래픽 증가에도 빠른 응답 속도를 유지할 수 있습니다. CloudFront를 사용하면 S3와 연계하여 전 세계 사용자에게 빠르게 정적 콘텐츠를 제공할 수 있으며, 동시에 S3에서 발생하는 트래픽을 줄여 비용을 절감할 수 있습니다.

 

마지막 과정은 “위의 정보들을 토대로 정답 선택하기”입니다.

선택지 1번은 "웹 사이트를 Amazon S3 버킷으로 이동합니다. S3 버킷에 대한 Amazon CloudFront 배포를 구성합니다." 입니다.

  • Amazon S3: 객체 스토리지 서비스로, 정적 콘텐츠를 저장하고 제공하는 데 매우 적합합니다. S3에 웹사이트를 호스팅하면 서버 비용을 절감할 수 있습니다.
  • Amazon CloudFront: 글로벌 콘텐츠 전송 네트워크(CDN) 서비스로, S3 버킷에 저장된 정적 콘텐츠를 전 세계 사용자에게 빠르게 전달합니다. CloudFront를 사용하면 S3 버킷에 대한 요청을 줄여 비용을 추가로 절감할 수 있습니다.

이 선택지가 정답인 이유는 정적 콘텐츠를 제공하는 웹사이트의 요구사항에 가장 적합한 솔루션입니다. S3와 CloudFront를 결합하면 트래픽이 증가해도 비용 효율적으로 대응할 수 있으며, 웹사이트의 성능도 향상됩니다. 또한, 서버리스 아키텍처이므로 운영 오버헤드가 매우 낮기 때문에 정답입니다.

 

선택지 2번은 "웹 사이트를 Amazon S3 버킷으로 이동합니다. S3 버킷에 대한 Amazon ElastiCache 클러스터를 구성합니다." 입니다.

  • Amazon S3: 정적 콘텐츠를 저장하고 제공하는 객체 스토리지 서비스입니다. S3에 웹사이트를 호스팅하면 비용 절감이 가능합니다.
  • Amazon ElastiCache: 관리형 인메모리 캐시 서비스로, Redis 또는 Memcached를 지원합니다. 주로 데이터베이스 응답 속도를 개선하기 위해 사용됩니다.

이 선택지가 정답이 아닌 이유는 Amazon ElastiCache는 주로 데이터베이스 성능을 개선하기 위한 서비스로, 정적 콘텐츠를 제공하는 S3와 결합할 때는 큰 이점을 제공하지 않습니다. 또한, S3 자체가 이미 정적 콘텐츠를 효과적으로 제공할 수 있기 때문에, ElastiCache를 추가하는 것은 불필요한 복잡성을 초래할 수 있습니다. 따라서 이 선택지는 트래픽 증가에 대한 비용 절감 요구사항을 제대로 충족하지 못합니다.

 

선택지 3번은 "웹사이트를 AWS Amplify로 이동합니다. Amplify 웹 사이트를 확인하도록 ALB를 구성합니다. " 입니다.

  • AWS Amplify: 서버리스 웹 애플리케이션 프레임워크로, 정적 및 동적 웹사이트를 손쉽게 배포할 수 있습니다. CI/CD 파이프라인을 통해 애플리케이션의 업데이트도 자동화할 수 있습니다.
  • Application Load Balancer (ALB): 트래픽을 여러 Amazon EC2 인스턴스에 분산시키는 로드 밸런서입니다.

이 선택지가 정답이 아닌 이유는 AWS Amplify는 웹 애플리케이션을 빠르게 배포하고 관리하는 데 유용하지만, 정적 콘텐츠 제공을 위한 비용 최적화에는 S3와 CloudFront 조합만큼 효과적이지 않습니다. 또한, ALB를 사용하면 EC2 인스턴스 비용이 발생할 수 있어 비용 절감 목표와 상충될 수 있습니다.

 

선택지 4번은 "웹사이트를 AWS Amplify로 이동합니다. 웹 사이트를 캐시하도록 EC2 인스턴스를 구성합니다." 입니다.

  • AWS Amplify: 정적 및 동적 콘텐츠를 쉽게 배포할 수 있는 서비스입니다.
  • Amazon EC2: 가상 서버 인스턴스로, 웹사이트를 호스팅하거나 애플리케이션을 실행하는 데 사용할 수 있습니다.

이 선택지가 정답이 아닌 이유는 AWS Amplify와 EC2 인스턴스를 사용하여 웹사이트를 호스팅하고 캐시하도록 제안합니다. 그러나 EC2 인스턴스는 비용이 추가로 발생하며, 정적 콘텐츠를 제공하는 데 있어 S3와 CloudFront 조합만큼 비용 효율적이지 않습니다. 또한, EC2에서 캐싱을 관리하는 것은 운영 오버헤드를 증가시킬 수 있습니다.

 

 

여러분, 오늘은 금요일입니다. 이번주는 다들 어떠셨을까요?

내일이면 주말인 만큼 오늘을 통해 이번주를 마무리하는 시간을 가져보세요!

이번 주도 열심히 달려온 이유, 우리의 목표가 무엇인지 잊지 말고 힘내 봅시다!!

처음 글을 작성하는 데에 있어서 실수는 귀엽게 봐주시면 감사하겠습니다..!

오늘 글이 유익하셨길 바라며, 다음에는 또 다른 문제로 찾아뵙겠습니다.

 

감사합니다. 다음 글에서 만나요! 😊