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

개념정리

AWS Backup

 

1. 중앙 집중화된 백업 관리

• AWS Backup은 Amazon EC2, Amazon RDS, Amazon DynamoDB, Amazon EFS, Amazon S3, AWS Storage Gateway 등 다양한 AWS 서비스의 백업을 하나의 콘솔에서 관리할 수 있습니다.
• 이를 통해 각 서비스마다 개별적으로 백업을 설정할 필요 없이, 한 곳에서 모든 백업을 일괄적으로 관리할 수 있습니다.

2. 자동화된 백업 일정 및 보존 정책

• 사용자 정의 백업 일정과 보존 정책을 생성할 수 있어, 백업 프로세스를 자동화할 수 있습니다.
• 주기적으로 백업이 생성되고, 설정한 보존 기간에 따라 백업을 자동으로 삭제하는 등의 관리가 가능해 장기 보존이나 규정 준수 요구사항에 유용합니다.

3. 데이터 보존 및 규정 준수

• AWS Backup은 데이터를 특정 기간 동안 안전하게 보관할 수 있도록 설정할 수 있어, 데이터 보존 규정이나 컴플라이언스 요구사항을 충족하는 데 도움을 줍니다.
• AWS Backup Vault와 AWS Backup Vault Lock을 사용해 보존 설정을 잠글 수도 있어, 백업 데이터의 삭제나 변경을 방지하고 장기 보존 요구사항을 지원합니다.

4. 백업 암호화 및 보안 관리

• AWS Backup은 백업 데이터를 암호화하여 안전하게 보관합니다. AWS Key Management Service(KMS)를 통해 데이터 암호화와 키 관리도 지원합니다.
• 또한, IAM 정책을 통해 백업 리소스에 대한 접근을 제어할 수 있어, 특정 사용자나 역할이 백업 리소스에 접근하지 못하도록 할 수 있습니다.

5. 다중 리전 및 다중 계정 백업 지원

• AWS Backup은 백업을 다른 리전이나 다른 AWS 계정으로 전송하여 보관할 수 있는 기능을 제공합니다.
• 이 기능은 재해 복구(DR) 및 높은 가용성을 요구하는 경우에 유용하며, 여러 리전에 데이터를 분산하여 저장함으로써 더욱 안정적인 데이터 보존을 가능하게 합니다.

6. 비용 효율성

• AWS Backup은 사용한 만큼만 비용을 지불하는 구조로, 각 서비스별 백업 요구 사항에 맞춰 비용을 절감할 수 있는 유연성을 제공합니다.
• 백업 데이터를 Amazon S3와 같은 저렴한 스토리지에 보관하면서도, 자동 백업과 보존 관리를 통해 추가적인 비용 절감을 할 수 있습니다.

7. 통합된 백업 모니터링 및 알림

• AWS Backup은 백업 상태와 관련된 모니터링 및 알림 기능을 제공합니다. AWS CloudWatch와 통합되어 백업 작업의 성공 여부, 오류, 경고 등에 대한 알림을 받을 수 있습니다.
• 이를 통해 백업 실패나 오류 발생 시 빠르게 대응할 수 있습니다.

8. 사용 예시

• 규정 준수를 위해 데이터를 장기 보존해야 하는 경우, AWS Backup을 이용하여 일정과 보존 정책을 설정하면 자동으로 데이터를 보호할 수 있습니다.
• 여러 리전에 걸친 백업을 통해 재해 복구를 위한 백업 계획을 수립할 때 AWS Backup을 사용하면 비용을 절감하고 관리 효율성을 높일 수 있습니다.

Amazon CloudWatch Synthetics 카나리아

1. 개념 : 애플리케이션의 엔드포인트 및 사용자 흐름을 시뮬레이션하고 모니터링하여 애플리케이션의 가용성과 성능을 검증하는 뎃 사용되는 도구입니다. 카나리아는 실제 사용자가 애플리케이션을 사용할 때 발생할 수 있는 문제를 사전에 발견할 수 있도록 도와줍니다.
2. 주요 기능 :
   • 엔드포인트 모니터링
     • 카나리아는 애플리케이션의 엔드포인트가 예상대로 응답하지 않거나, 응답 시간이 느려질 경우 이를 탐지하고 문제를 조기에 식별할 수 있습니다.
     • 카나리아는 JavaScript를 통해 웹 애플리케이션 상의 다양한 사용자 시나리오를 자동화하여 실제 사용자가 애플리케이션을 사용하는 것처럼 시뮬레이션할 수 있습니다.
   • 사용자 시나리오 시뮬레이션
     • 예를 들어, 로그인, 검색, 쇼핑 카트 추가, 결제 과정 등을 시뮬레이션하여 특정 사용자 경로가 정상적으로 작동하는지 모니터링할 수 있습니다.
     • 카나리아는 JavaScript를 통해 웹 애플리케이션 상의 다양한 사용자 시나리오를 자동화하여 실제 사용자가 애플리케이션을 사용하는 것처럼 시뮬레이션할 수 있습니다.
   • 지표 및 로그 수집
     • 지표는 평균 응답 시간, 성공 및 실패 비율 등 애플리케이션의 성능 상태를 평가하는 데 도움이 됩니다.
     • 카나리아 실행 중 수집된 모든 지표와 로그는 Amazon CloudWatch에 저장되며, 이 데이터를 통해 시스템의 성능 및 가용성을 추적할 수 있습니다.
   • 알림 설정
     • 이를 통해 성능 저하나 애플리케이션 가용성 문제를 빠르게 감지하고 대응할 수 있습니다.
     • CloudWatch Synthetics는 CloudWatch 경보와 연동되어 문제가 발생했을 때 자동으로 알림을 보낼 수 있습니다.
   • 스크린샷 및 HTTP 트래픽 저장
     • 이 기능을 통해 문제를 시각적으로 확인하고 디버깅하는 데 도움을 받을 수 있습니다.
     • 테스트 중 발생한 문제의 원인을 파악하기 위해 화면의 스크린샷이나 HTTP 요청 및 응답을 기록할 수 있습니다.
   • 자주 반복되는 검사
     • 설정에 따라 1분, 5분, 10분, 또는 15분 간격으로 주기적인 검사를 수행할 수 있습니다.
     • 카나리아는 분 단위로 설정이 가능하여 자주 반복되는 검사를 통해 애플리케이션의 안정성을 계속 확인할 수 있습니다.

웜 스탠바이(Warm Standby)

• 설명: 웜 스탠바이는 DR 리전에서 애플리케이션의 핵심 구성 요소와 데이터를 부분적으로 활성화된 상태로 유지하는 방식입니다. 주요 서버(예: 웹 서버와 데이터베이스)는 DR 리전에서 낮은 성능이나 최소한의 리소스 상태로 가동 중이며, 재해 발생 시 즉각 확장하여 완전한 기능을 제공할 수 있습니다.
• 구성 요소: 애플리케이션의 핵심 기능을 복제하여 저용량(낮은 스펙) 인스턴스로 실행하고, 주 리전에서 문제가 발생할 경우 DR 리전에서 자원을 확장해 빠르게 전환합니다.
• 복구 시간(RTO): 짧은 복구 시간을 제공합니다. 필요한 구성 요소가 이미 실행 중이기 때문에, 장애 발생 시 빠르게 인스턴스를 확장하여 전체 서비스를 복구할 수 있습니다.
• 비용: 주 리전에서 사용하는 전체 리소스의 저비용 버전을 DR 리전에서 실행하고 있기 때문에, 파일럿 라이트보다 비용이 더 들 수 있습니다.
• 예시: DR 리전에서 저사양 EC2 인스턴스와 RDS 인스턴스를 실행하고, 문제가 발생하면 인스턴스의 크기와 수를 확장하여 주 리전과 동일한 수준의 서비스로 전환합니다.

파일럿 라이트(Pilot Light)

• 설명: 파일럿 라이트는 필요 최소한의 구성 요소만 DR 리전에 유지하는 방식입니다. 데이터베이스와 같은 중요한 데이터와 설정 정보는 DR 리전에 준비되어 있지만, 애플리케이션 서버나 웹 서버는 미실행 상태로 유지됩니다. 장애 발생 시 이 최소 구성 요소를 기반으로 전체 시스템을 활성화합니다.
• 구성 요소: 데이터베이스와 같은 중요 구성 요소만 DR 리전에 복제하고, 나머지 애플리케이션과 서버는 전환 시점에 필요할 때만 활성화합니다.
• 복구 시간(RTO): 복구 시간이 상대적으로 길 수 있습니다. DR 리전에서 필요한 자원을 추가로 프로비저닝하고 애플리케이션을 기동해야 하므로, 웜 스탠바이보다 복구 시간이 길어질 수 있습니다.
• 비용: 필요한 최소한의 리소스만 유지하기 때문에 비용이 상대적으로 저렴합니다.
• 예시: DR 리전에서 데이터베이스만 동기화하고, 장애 발생 시 애플리케이션 서버와 웹 서버를 새로 프로비저닝하여 전체 서비스를 복구합니다.

컴퓨팅 노드의 부하를 기준으로 확장하는 방식

• 기준: 이 방식은 CPU 사용률, 메모리 사용량, 네트워크 트래픽 등 EC2 인스턴스의 현재 자원 사용량을 기준으로 Auto Scaling을 수행합니다.
• 동작 원리: 설정된 임계값을 기준으로 인스턴스의 부하가 일정 수준을 초과하면 새로운 인스턴스를 추가하고, 부하가 낮아지면 인스턴스 수를 줄입니다.
• 반응 속도: 컴퓨팅 노드의 부하가 높아진 후에 인스턴스를 추가하기 때문에 반응 속도가 상대적으로 느릴 수 있습니다. 이미 부하가 발생한 후에 추가 인스턴스를 시작하기 때문에 스케일 아웃이 늦어질 수 있습니다.
• 적합한 상황: 자원 사용량이 급격하게 변하지 않는 애플리케이션에 적합합니다. 예를 들어, 일정한 트래픽이 있는 웹 서버나 간헐적으로 높은 부하가 발생하는 애플리케이션에 잘 맞습니다.

동적 확장 (대기열 크기를 기준으로 확장하는 방식)

• 기준: 이 방식은 작업의 수나 대기열의 크기를 기준으로 합니다. 예를 들어, Amazon SQS 대기열의 메시지 수를 기준으로 Auto Scaling이 동작합니다.
• 동작 원리: 대기열에 쌓인 메시지의 수가 증가하면, 이를 처리할 수 있는 추가 인스턴스를 자동으로 생성합니다. 반대로 대기열의 메시지가 줄어들면 인스턴스를 축소하여 탄력적으로 대응합니다.
• 반응 속도: 대기열의 크기를 기준으로 확장하므로, 부하가 발생하기 전에 반응할 수 있습니다. 작업이 대기열에 쌓이는 시점에 확장이 이루어지기 때문에 스케일 아웃이 빠르게 이루어집니다.
• 적합한 상황: 작업의 양이 빠르게 변하는 상황에 적합하며, 비동기 작업이나 이벤트 기반 처리에 유용합니다. 예를 들어, 백엔드에서 이미지 처리나 비디오 인코딩과 같은 비동기 작업을 수행하는 경우에 잘 맞습니다.

예시

• 컴퓨팅 노드 부하 기반 확장: 웹 서버의 CPU 사용량이 70% 이상이 되면 추가 서버를 프로비저닝하고, 30% 이하로 떨어지면 서버를 축소하는 방식입니다. 일반적인 웹 서버 트래픽 처리에는 적합하지만, 작업이 많아지는 시점에 늦게 대응할 수 있습니다.
• 대기열 기반 동적 확장: SQS 대기열에 메시지가 50개 이상 쌓이면 인스턴스를 확장하고, 10개 이하로 줄어들면 인스턴스를 축소하는 방식입니다. 백엔드에서 비동기식으로 이미지나 동영상 처리를 해야 하는 상황에서 대기열에 작업이 쌓이는 즉시 추가 인스턴스가 시작되기 때문에, 빠르게 처리량을 늘릴 수 있습니다.

아카이빙(Archiving)

• 개념 : 데이터를 오랫동안 보관하거나 필요할 때 다시 사용하기 위해 저비용 스토리지에 데이터를 저장하는 것을 의미합니다. 주로 오래된 데이터나 자주 접근하지 않는 데이터를 대상으로 하며, 빠르게 접근할 필요가 없는 데이터들을 장기적으로 저장하기 위한 방법입니다.
• 아카이빙의 목적
  • 비용 절감: 오래된 데이터를 고성능 스토리지에 보관하는 대신 저렴한 스토리지로 이동시켜 전체적인 저장 비용을 줄입니다.
  • 저장 공간 확보: 자주 사용하지 않는 데이터를 아카이빙하여, 고성능 스토리지의 용량을 확보하고 운영 효율성을 높입니다.
  • 장기 보관: 법적 요구사항, 규제 준수, 백업 등 다양한 이유로 데이터를 오래 보관해야 할 때 사용합니다.
• 아카이빙의 예
  • Amazon S3 Glacier 및 S3 Glacier Deep Archive: AWS에서 제공하는 장기 아카이빙 스토리지 서비스로, 데이터 접근 빈도가 낮고 비용 절감이 중요한 데이터에 적합합니다.
  • S3 Glacier는 보통 몇 분에서 몇 시간 내에 데이터 접근이 가능하며, 비용이 매우 저렴합니다.
  • S3 Glacier Deep Archive는 비용이 더 저렴하지만 데이터 접근 시간이 수 시간에서 하루 정도 걸릴 수 있습니다.
• 아카이빙의 특징
  • 저렴한 비용: 자주 사용하지 않는 데이터는 고비용의 고성능 스토리지보다는 저렴한 아카이빙 스토리지에 보관할 수 있습니다.
  • 느린 접근성: 아카이빙된 데이터는 즉시 접근하기 어려운 경우가 많습니다. 보통 복원이 필요하며, 복원 과정에서 몇 시간에서 며칠이 소요될 수 있습니다.
  • 장기 보관에 최적화: 데이터가 필요할 때만 복원하여 사용할 수 있도록, 장기적인 데이터 보관이 목적입니다.
• 아카이빙이 필요한 경우
  • 규제에 따른 데이터 보관: 금융 및 의료 업계처럼 특정 데이터 보관 기간이 요구되는 경우.
  • 백업 및 복구: 데이터 손실에 대비한 장기적인 백업 솔루션으로 사용.
  • 역사적인 데이터 저장: 기업에서 과거 데이터를 보관하고 분석에 활용해야 할 때.

Redis용 Amazon ElastiCache와 Memcached용 Amazon ElastiCache

 

1. 데이터 구조 지원

• Redis: 키-값 저장소 외에도 리스트, 해시, 셋, 정렬된 셋, 비트맵 등 다양한 데이터 구조를 지원합니다. 이러한 복잡한 데이터 구조를 활용하면 데이터 처리에 더 많은 유연성을 제공할 수 있습니다.
• Memcached: 단순한 키-값 저장소로만 작동합니다. 키에 해당하는 값은 문자열이나 간단한 데이터 구조만 저장할 수 있으며, Redis처럼 다양한 데이터 구조를 지원하지 않습니다.

2. 데이터 지속성

• Redis: 데이터 지속성을 옵션으로 제공합니다. Redis는 스냅샷을 생성하거나 AOF(Append-Only File) 방식을 통해 데이터를 디스크에 저장할 수 있어, 서버가 재시작되거나 종료될 때 데이터가 유지됩니다.
• Memcached: 데이터 지속성을 제공하지 않습니다. Memcached는 메모리 내의 데이터를 유지하지만, 서버가 종료되거나 재시작되면 데이터가 손실됩니다. 따라서 Memcached는 영구 데이터 저장이 필요 없는 단순 캐싱 용도로 사용됩니다.

3. 분산 및 확장성

• Redis: 클러스터링 기능을 통해 여러 Redis 노드를 클러스터로 구성할 수 있어, 데이터 분할(sharding)이 가능합니다. 이를 통해 수평적 확장이 가능하며, 클러스터링된 노드 간에 데이터가 자동으로 분산됩니다.
• Memcached: 기본적으로 클러스터링 기능이 없습니다. 대신 클라이언트가 데이터를 분할하여 여러 Memcached 인스턴스에 분배하는 방식으로 확장이 이루어집니다. AWS ElastiCache에서 Memcached는 클라이언트가 직접 데이터를 분산 처리해야 하므로, Redis보다 확장성 관리가 복잡할 수 있습니다.

4. 고가용성

• Redis: 복제를 통해 고가용성을 제공합니다. Redis는 기본(primary)과 복제(replica) 노드 구조를 구성할 수 있어, 기본 노드에 장애가 발생해도 복제본으로 장애 조치(failover)가 가능하여 가용성을 보장합니다.
• Memcached: 기본적으로 복제 기능이 없습니다. Memcached는 장애가 발생한 노드의 데이터를 복구하는 기능이 없으며, 데이터 손실이 발생할 수 있습니다. 데이터의 신뢰성이 중요한 경우에는 적합하지 않습니다.

5. 성능 및 활용 사례

• Redis: 여러 데이터 구조와 데이터 지속성을 제공하므로 세션 관리, 실시간 분석, 큐(Queue), 순위표 관리 등 다양한 애플리케이션에 사용됩니다. 복잡한 데이터 작업이 필요한 경우에도 유용합니다.
• Memcached: 단순한 키-값 저장소로서, 주로 웹 페이지 캐싱, 데이터베이스 쿼리 결과 캐싱 등 단순 캐싱이 필요한 경우에 사용됩니다. 빠르고 간단한 캐시 솔루션이 필요할 때 적합합니다.

특징	Redis	Memcached
데이터구조	리스트, 해시, 셋 등 다양한 구조 지원	단순 키 - 값 저장소
영속성	지원(디스크에 저장 가능)	미지원(순수 인메모리)
복제 및 고가용성	마스터-슬레이브 복제, 자동 페일오버	미지원
트랜잭션	지원	미지원
Pub/Sub	지원	미지원
백업 및 복원	자동 백업, 특정 시점 복원 지원	미지원
지리공간 데이터	인덱싱 및 쿼리 지원	미지원
멀티스레딩	단일 스레드	멀티스레드 지원

 

용어정리

 

아카이빙 : 중요한 데이터지만 자주 사용하지 않는 데이터를 저비용 스토리지에 보관해, 필요 시에만 복원하여 사용하는 경제적인 데이터 관리 방식입니다.

Redis용 Amazon ElastiCache : 데이터 지속성, 다양한 데이터 구조, 고가용성, 클러스터링 등을 제공하므로 복잡한 데이터 처리와 높은 가용성이 필요한 애플리케이션에 적합합니다.

Memcached용 Amazon ElastiCache : 단순한 캐시로서 빠르게 읽기 성능을 높이는 단순 캐싱 작업에 적합합니다.

문제풀이

 

문제 1 :회사는 사용자 트랜잭션 데이터를 Amazon DynamoDB 테이블에 보관해야 합니다. 회사는 데이터를 7년간 보관해야 합니다.

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

 

A. DynamoDB 지정 시간 복구(point-in-time recovery)를 사용하여 테이블을 지속적으로 백업합니다.

• 지정 시간 복구 기능은 테이블을 일정 시점으로 복원할 수 있도록 지속적인 백업을 수행하지만, 장기 보관보다는 단기적인 데이터 보호에 적합합니다. 7년이라는 장기 보존 요구 사항을 만족하지 못하므로 적절하지 않습니다.
• 자동 백업은 최대 35일까지만 백업 가능

B. AWS Backup을 사용하여 테이블에 대한 백업 일정 및 보존 정책을 생성합니다.

• AWS Backup은 중앙 집중식으로 백업 일정과 보존 정책을 설정할 수 있는 서비스로, 여러 AWS 리소스의 백업을 관리할 수 있습니다. 또한, 백업 데이터를 장기간 저장하고 보존할 수 있는 기능을 제공하므로 7년간의 데이터 보존 요구 사항을 충족할 수 있습니다. 따라서 이 선택지가 가장 적합해 보입니다.

C. DynamoDB 콘솔을 사용하여 테이블의 온디맨드 백업을 생성합니다. 백업을 Amazon S3 버킷에 저장합니다. S3 버킷에 대한 S3 수명 주기 구성을 설정합니다.

• 온디맨드 백업은 필요할 때마다 수동으로 수행해야 하므로 지속적인 백업 관리가 어렵습니다. 자동화된 일정 백업을 지원하지 않으므로 장기적인 보존 관리에 효율적이지 않습니다.
• 온디맨드 백업을 바로 S3로 내보낼 수 없음

D. AWS Lambda 함수를 호출하는 Amazon EventBridge 규칙을 생성하여 백업을 S3 버킷에 저장하도록 Lambda 함수를 구성합니다. S3 버킷에 대한 S3 수명 주기 구성을 설정합니다.

• 이 방법은 백업을 자동화할 수 있지만, AWS Backup을 사용하는 것보다 복잡합니다. 또한, AWS Backup은 내장된 보존 정책을 제공하여 장기 보존이 더욱 용이합니다.

문제 2 : 회사는 사용자 업로드 문서를 Amazon EBS 볼륨에 저장하는 단일 Amazon EC2 인스턴스를 사용하여 AWS에서 웹 애플리케이션을 호스팅하고 있습니다. 더 나은 확장성과 가용성을 위해 이 회사는 아키텍처를 복제하고 두 번째 EC2 인스턴스와 EBS 볼륨을 다른 가용 영역에 생성하여 둘 다 Application Load Balancer 뒤에 배치했습니다. 이 변경을 완료한 후 사용자는 웹 사이트를 새로 고칠 때마다 문서의 하나의 하위 집합 또는 다른 걸 볼 수 있지만 동시에 모든 문서를 절대 볼 수 없다고 보고했습니다. 솔루션 설계자는 사용자가 모든 문서를 한 번에 볼 수 있도록 무엇을 제안해야 합니까?

 

A. 두 EBS 볼륨에 모든 문서가 포함되도록 데이터를 복사합니다.

• 이 방법은 문서 데이터를 중복으로 저장해야 하므로 관리가 복잡해지고 스토리지 비용이 증가할 수 있습니다. 또한, 문서를 업데이트할 때 두 볼륨에 동일한 업데이트를 수행해야 하므로 비효율적입니다.

B. 문서가 있는 서버로 사용자를 안내하도록 Application Load Balancer 구성

• Application Load Balancer는 상태 검사에 따라 트래픽을 분산시킬 수 있지만, 문서가 각각의 EBS 볼륨에 분산되어 있기 때문에 사용자가 문서를 요청할 때마다 올바른 서버를 항상 보장할 수는 없습니다. 이 방법은 사용자가 모든 문서에 액세스할 수 있도록 보장하지 않으므로 부적합합니다.

C. 두 EBS 볼륨의 데이터를 Amazon EFS로 복사해 새 문서를 Amazon EFS에 저장하도록 애플리케이션 수정

• Amazon EFS는 공유 파일 시스템으로, 여러 EC2 인스턴스에서 동시에 액세스할 수 있습니다. EFS를 사용하면 문서를 중앙화하여 EC2 인스턴스가 각각 동일한 파일 시스템을 공유할 수 있습니다. 따라서 사용자들은 모든 문서에 일관되게 접근할 수 있습니다. 또한 EFS는 확장성이 높아 확장성과 가용성 요구 사항에도 잘 맞습니다.

D. 두 서버 모두에 요청을 보내도록 Application Load Balancer를 구성합니다. 올바른 서버에서 각 문서를 반환합니다.

• 이 방법은 Application Load Balancer의 목적에 맞지 않으며, 모든 요청을 각 서버에 보내는 것은 불필요한 오버헤드를 초래합니다. 따라서 비효율적이고 문제가 될 수 있습니다.
• 두 서버에 모든 요청을 보내게 되면 트래픽이 두 배로 증가하여 불필요한 리소스 소모를 발생시킵니다.
• Application Load Balancer는 일반적으로 여러 서버로 트래픽을 분산시켜 고가용성을 보장하지만, 이 방식은 두 서버 모두에 요청을 보내는 구조이기 때문에 모든 요청이 두 번씩 처리됩니다. 

문제 3 : 회사에서 AWS에 새로운 공개 웹 애플리케이션을 배포하고 있습니다. 애플리케이션은 ALB(Application Load Balancer) 뒤에서 실행됩니다. 애플리케이션은 외부 CA(인증 기관)에서 발급한 SSL/TLS 인증서를 사용하여 에지(Edge)에서 암호화해야 합니다. 인증서가 만료되기 전에 매년 인증서를 교체해야 합니다. 솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?

 

A. AWS Certificate Manager(ACM)를 사용하여 SSL/TLS 인증서를 발급합니다. 인증서를 ALB에 적용하고, 관리형 갱신 기능을 사용하여 인증서를 자동으로 교체합니다.

• AWS Certificate Manager(ACM)는 SSL/TLS 인증서를 발급하고 관리할 수 있는 서비스입니다. ACM은 AWS 내의 여러 서비스와 연동하여 인증서를 쉽게 적용할 수 있으며, 관리형 갱신 기능이 있어 인증서가 만료되기 전에 자동으로 갱신할 수 있습니다.
• 이 방법은 외부 CA 인증서를 사용할 필요가 없는 경우 적합합니다. 그러나 문제에서 외부 CA에서 발급받은 인증서를 사용하라고 했으므로 조건에 맞지 않습니다.

B. AWS Certificate Manager(ACM)를 사용하여 SSL/TLS 인증서를 발급합니다. 인증서에서 키 구성 요소를 가져옵니다. 인증서를 ALB에 적용하고, 관리형 갱신 기능을 사용하여 인증서를 자동으로 교체합니다.

• ACM은 SSL/TLS 인증서를 발급하고, ALB에 적용할 수 있습니다. 관리형 갱신 기능을 통해 인증서를 자동으로 갱신할 수 있지만, 외부 CA를 직접 언급하지 않아 문제 조건을 충족하지 않습니다.
• ACM에서 직접 발급한 인증서를 사용하는 경우에 적합하지만, 외부 CA에서 발급한 인증서를 관리해야 하는 조건에는 맞지 않습니다.

C. AWS Certificate Manager(ACM) 사설 인증 기관을 사용하여 루트 CA에서 SSL/TLS 인증서를 발급합니다. 인증서를 ALB에 적용합니다. 관리형 갱신 기능을 사용하여 인증서를 자동으로 교체합니다.

• ACM Private CA는 사설 인증서를 발급하는 데 사용되며, 외부에서 신뢰받는 공용 SSL 인증서가 아닌 내부 사용에 적합합니다.
• 외부 CA에서 발급한 공용 인증서를 요구하는 문제 상황에는 적합하지 않습니다.

D. AWS Certificate Manager(ACM)를 사용하여 SSL/TLS 인증서를 가져옵니다. 인증서를 ALB에 적용합니다. Amazon EventBridge(Amazon CloudWatch Events)를 사용하여 인증서가 만료될 때 알림을 보냅니다. 인증서를 수동으로 교체합니다.

• 이 옵션은 외부 CA에서 발급된 인증서를 ACM에 가져와 사용할 수 있습니다. ACM의 “가져오기” 기능을 통해 외부 CA에서 발급받은 인증서를 관리할 수 있으며, EventBridge를 사용하여 인증서 만료 알림을 설정할 수 있습니다.
• 인증서 갱신이 자동화되지 않고 수동으로 교체해야 하는 점이 단점이지만, 외부 CA에서 발급받은 인증서 요구 사항을 충족합니다.

문제 4 : 회사는 온-프레미스 서버에서 Amazon EC2 인스턴스로 애플리케이션을 마이그레이션하고 있습니다. 마이그레이션 설계 요구 사항의 일부로 솔루션 설계자는 인프라 메트릭 경보(infrastructure metric alarms)를 구현해야 합니다. CPU 사용률이 단기간에 50% 이상으로 증가하는 경우 회사는 조치를 취할 필요가 없습니다. 하지만 CPU 사용률이 50% 이상으로 증가하고 디스크의 읽기 IOPS가 동시에 높다면 회사에서 최대한 빨 리 조치를 취해야 합니다. 솔루션 설계자는 또한 오경보를 줄여야 합니다. 솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?

 

A. 가능한 경우 Amazon CloudWatch 복합 경보(composite alarms)를 생성합니다.

• CloudWatch 복합 경보는 여러 경보를 결합하여 조건이 모두 충족될 때만 경보를 발생시킬 수 있습니다. 예를 들어, CPU 사용률이 50% 이상이고 동시에 디스크 IOPS가 높은 경우에만 경보를 설정할 수 있습니다.
• 이 기능을 통해 여러 지표를 조합하여 단일 경보를 설정할 수 있으므로, 이 문제의 요구 사항을 충족하는 데 적합한 솔루션입니다.

B. Amazon CloudWatch 대시보드를 생성하여 지표를 시각화하고 문제에 신속하게 대응합니다.

• 대시보드를 통해 지표를 시각화할 수 있지만, 단일 경보로 특정 조건을 만족할 때만 알림을 보내는 기능은 제공하지 않습니다.
• 문제 발생 시 경보를 통해 즉각적인 알림이 필요하기 때문에, 시각화만으로는 요구 사항을 충족하지 못합니다.

C. Amazon CloudWatch Synthetics 카나리아를 생성하여 애플리케이션을 모니터링하고 경보를 발생시킵니다.

• CloudWatch Synthetics는 애플리케이션의 가용성을 모니터링하기 위해 사용되며, 애플리케이션 엔드포인트를 지속적으로 확인하는 기능을 제공합니다.
• 이는 지표를 기반으로 하는 인프라 경보 대신, 애플리케이션 레벨에서의 가용성을 모니터링하는 도구이므로 문제의 조건과 맞지 않습니다.

D. 가능한 경우 여러 지표 임계값으로 단일 Amazon CloudWatch 지표 경보를 생성합니다.

• CloudWatch에서 단일 경보에 여러 지표의 조건을 설정할 수는 있지만, 여러 지표를 동시에 감지하는 기능은 복합 경보를 통해서만 가능합니다.
• 따라서 이 방법으로는 CPU 사용률과 디스크 IOPS의 조건을 동시에 감지할 수 없습니다.

문제 5 : 빠르게 성장하는 전자 상거래 회사는 단일 AWS 리전에서 워크로드를 실행하고 있습니다. 솔루션 설계자는 다양한 AWS 리전을 포함하는 재해 복구(DR) 전략을 생성해야 합니다. 회사는 DR 리전에서 가능한 최소 지연 시간으로 데이터베이스를 최신 상태로 유지하기를 원합니다. DR 리전의 나머지 인프라는 감소된 용량으로 실행해야 합니다. 필요에 따라 확장할 수 있어야 합니다. 가장 낮은 RTO(복구 시간 목표)로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

A. 파일럿 라이트 배포와 함께 Amazon Aurora 글로벌 데이터베이스 사용

• 파일럿 라이트 배포 방식은 DR 리전에서 필요한 최소한의 구성 요소만 활성화한 상태로 유지합니다. 데이터베이스와 같은 필수 요소는 준비되지만, 애플리케이션 서버와 같은 나머지 인프라는 미활성 상태입니다.
• 장애 발생 시 전체 시스템을 새로 프로비저닝하고 활성화해야 하므로, 상대적으로 시간이 걸릴 수 있습니다.
• Amazon Aurora 글로벌 데이터베이스를 통해 빠르게 데이터를 복제할 수 있지만, 파일럿 라이트 배포 방식의 특성상 복구 시간이 길어질 수 있습니다.

B. 웜 스탠바이 배포와 함께 Amazon Aurora 글로벌 데이터베이스 사용

• 웜 스탠바이 배포는 DR 리전에서 핵심 인프라가 저용량 상태로 실행 중인 방식입니다. 애플리케이션 서버와 데이터베이스가 낮은 스펙으로 가동되고 있어 필요 시 빠르게 확장하여 전체 서비스로 전환할 수 있습니다.
• Amazon Aurora 글로벌 데이터베이스는 여러 리전에 데이터를 거의 실시간으로 복제하며, 장애 발생 시 Aurora 리전 간의 전환이 빠르게 이루어져 복구 시간을 줄일 수 있습니다.
• 애플리케이션 서버와 데이터베이스가 이미 준비되어 있어 RTO가 낮으며, 빠르게 서비스 복구가 가능합니다.

C. 파일럿 라이트 배포와 함께 Amazon RDS 다중 AZ DB 인스턴스 사용

• RDS 다중 AZ는 동일 리전 내의 가용 영역 간에 데이터 복제를 수행하여 데이터베이스의 고가용성을 제공합니다. 하지만 리전 간 장애 복구에는 적합하지 않습니다.
• 파일럿 라이트 배포 방식을 사용할 경우 DR 리전에서 추가로 자원을 프로비저닝해야 하므로 RTO가 길어질 수 있습니다.
• 여러 리전 간 복구를 요구하는 상황에서 다중 AZ 구성을 사용하면 적합하지 않습니다.

D. 웜 스탠바이 배포와 함께 Amazon RDS 다중 AZ DB 인스턴스 사용

• RDS 다중 AZ는 DR 리전이 아닌 동일 리전 내의 가용 영역 간 복제를 통해 장애 복구를 제공하기 때문에, 다중 리전 재해 복구를 보장하지 않습니다.
• 웜 스탠바이 배포 방식은 빠른 복구가 가능하지만, Amazon RDS 다중 AZ 구성은 글로벌 DR 전략에 적합하지 않기 때문에 조건에 맞지 않습니다.

문제 6 : 한 회사가 분산 애플리케이션을 AWS로 마이그레이션하고 있습니다. 애플리케이션이 다양한 워크로드를 처리합니다. 레거시 플랫폼은 기본 서 버 평가판으로 구성되어 여러 컴퓨팅 노드에서 작업을 조정합니다. 회사는 탄력성과 확장성을 극대화하는 솔루션으로 애플리케이션을 현대화 하려고 합니다. 솔루션 설계자는 이러한 요구사항을 충족하기 위해 어떻게 설계해야 할까요?

 

A. Amazon Simple Queue Service(SQS) 대기열을 작업의 대상으로 구성. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 컴퓨팅 노드를 구현. 예약된 조정을 사용하도록 EC2 Auto Scaling 구성

• SQS는 분산 애플리케이션에서 작업을 처리하기 위해 대기열을 통해 메시지를 전달하는 데 유용하며, 확장성 요구 사항을 지원합니다.
• 예약된 조정은 특정 시간에 따라 Auto Scaling 그룹을 확장 또는 축소하는 데 사용되지만, 이는 워크로드가 특정 시간에만 변화하는 경우에 적합합니다.
• 그러나, 이 문제에서는 작업량에 따라 Auto Scaling이 동적으로 이루어져야 하므로 예약된 조정은 비효율적입니다.

B. Amazon Simple Queue Service(SQS) 대기열을 작업 대상으로 구성. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 컴퓨팅 노드 구현. 대기열 크기에 따라 EC2 Auto Scaling 구성

• SQS 대기열 크기는 현재 대기 중인 작업 수에 따라 Auto Scaling 그룹의 인스턴스를 동적으로 확장하거나 축소하는 데 활용될 수 있습니다.
• 대기열의 메시지 수를 기반으로 EC2 인스턴스를 자동으로 확장하거나 축소하면, 애플리케이션의 부하가 변할 때 신속하게 대응할 수 있습니다.
• 이 방법은 탄력성을 최대화하면서 필요할 때만 인스턴스를 확장하는 방식이므로 매우 효과적입니다.

C. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 기본 서버 및 컴퓨팅 노드를 구현. 서버의 로드를 기반으로 EC2 Auto Scaling 구성

• 이 선택지는 SQS와 같은 메시지 대기열을 사용하지 않고, EC2 인스턴스의 로드를 기준으로 확장/축소를 설정합니다.
• 하지만 로드를 기반으로 확장하는 방식은 부하 변화에 대한 즉각적인 대응이 어려울 수 있습니다.
• 작업을 처리하기 위해 메시지 대기열이 필요하다면 이 방법은 적합하지 않습니다.

D. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 기본 서버 및 컴퓨팅 노드 구현. 작업의 대상으로 Amazon EventBridge(Amazon CloudWatch Events) 사용. 컴퓨팅 노드의 부하를 기반으로 EC2 Auto Scaling 구성

• 이 선택지는 EventBridge와 CloudWatch Events를 활용해 작업을 트리거하는 방식입니다. EventBridge는 이벤트 기반으로 작동하며, 주로 서버리스 애플리케이션에서 사용됩니다.
• 컴퓨팅 노드의 부하를 기준으로 확장하는 방식이기 때문에 작업의 동적 확장에 비효율적일 수 있습니다.
• 따라서 이 방법은 SQS 대기열을 통한 동적 확장에 비해 덜 효과적입니다.

문제 7 : 한 회사는 최근 AWS 계정의 Amazon EC2 인스턴스에서 다양한 새로운 워크로드를 출시했습니다. 회사는 인스턴스에 원격으로 안전하게 액세스하고 관리하는 전략을 수립해야 합니다. 회사는 기본 AWS 서비스와 함께 작동하고 AWS Well-Architected 프레임워크를 따르는 반복 가능한 프로세스를 구현해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

A. EC2 직렬 콘솔(serial console)을 사용하여 관리를 위해 각 인스턴스의 터미널 인터페이스에 직접 액세스합니다.

• 이 방법은 긴급 상황이나 특별한 경우에 유용할 수 있지만, 다수의 인스턴스를 효율적으로 관리하기에는 적합하지 않습니다. 또한 Well-Architected 프레임워크의 보안 원칙에 부합하지 않을 수 있습니다.

B. 각 기존 인스턴스와 새 인스턴스에 적절한 IAM 역할을 연결합니다. AWS Systems Manager Session Manager를 사용하여 원격 SSH 세션을 설정합니다.

• 이 방법이 가장 적절합니다. IAM 역할을 사용하면 보안을 강화하고, Systems Manager Session Manager를 통해 중앙집중식으로 인스턴스를 관리할 수 있습니다. 이는 AWS Well-Architected 프레임워크의 보안 및 운영 우수성 원칙에 부합합니다.
• 인바운드 포트를 오픈하거나, SSH키를 사용할 필요없이 원격접속이 가능하므로 가장 작은 오버헤드로 구현가능

C. 관리 SSH 키 쌍을 만듭니다. 공개 키를 각 EC2 인스턴스에 로드합니다. 퍼블릭 서브넷에 베스천 호스트를 배포하여 각 인스턴스의 관리를 위한 터널을 제공합니다.

• 이 방법은 작동할 수 있지만, 베스천 호스트 관리에 추가적인 복잡성이 발생하고 보안 위험이 증가할 수 있습니다. Systems Manager를 사용하는 것보다 덜 효율적입니다.
• SSH는 리눅스 인스턴스만 가능

D. AWS Site-to-Site VPN 연결을 설정합니다. 관리자에게 로컬 온프레미스 머신을 사용하여 VPN 터널에서 SSH 키를 사용하여 인스턴스에 직접 연결하도록 지시합니다.

• 이 방법은 복잡하고 관리하기 어려울 수 있습니다. 또한 온프레미스 인프라가 필요하며, 각 관리자의 로컬 머신에 대한 보안 관리가 추가로 필요합니다.

문제 8 : 회사는 회사 웹 사이트에 널리 사용되는 CMS(콘텐츠 관리 시스템)를 사용합니다. 그러나 필요한 패치 및 유지 관리가 부담됩니다. 회사는 웹사 이트를 재설계하고 있으며 새로운 솔루션을 원합니다. 웹사이트는 1년에 4번 업데이트되며 사용 가능한 동적 콘텐츠가 필요하지 않습니다. 솔 루션은 높은 확장성과 향상된 보안을 제공해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 변경 조합은 무엇입니까? (2개를 선택하세요.)

 

A. HTTPS를 사용하여 웹사이트 앞에 Amazon CloudFront 구성

• CloudFront는 전 세계의 엣지 로케이션을 통해 콘텐츠를 캐싱하여 빠르고 안정적으로 콘텐츠를 제공할 수 있습니다.
• CloudFront는 HTTPS를 지원하므로 보안 강화에 도움을 주며, 캐싱을 통해 운영 오버헤드를 줄이고 성능을 향상시킬 수 있습니다.
• 이 옵션은 확장성과 보안을 강화하기 위한 요구사항을 충족합니다.

B. 웹 사이트 앞에 AWS WAF 웹 ACL을 배포하여 HTTPS 기능 제공

• AWS WAF는 웹 애플리케이션 방화벽으로, 다양한 보안 규칙을 설정하여 악의적인 트래픽을 필터링하고 공격으로부터 보호할 수 있습니다.
• 웹사이트를 HTTPS로 보호하고 WAF를 사용해 보안 규칙을 설정함으로써 보안을 강화할 수 있습니다.
• WAF Web ACL은 HTTPS 기능을 제공하지 않고, HTTPS 트래픽 필터링과 보호 기능을 제공하는 솔루션입니다.
• 정적 웹 사이트에 불필요한 보안 오버헤드와 추가적인 비요ㅕㅇ이 발생하여 운영 오버헤드가 발생합니다.

C. 웹사이트 콘텐츠를 관리하고 제공하기 위한 AWS Lambda 함수 생성 및 배포

• Lambda는 서버리스 컴퓨팅을 제공하며, 특정 이벤트가 발생할 때 코드를 실행합니다. 하지만 정적인 웹사이트의 콘텐츠를 제공하는 용도로는 적합하지 않습니다.
• 주기적인 업데이트와 정적 콘텐츠 제공에는 Lambda를 활용하는 방식이 비효율적이므로, 이 옵션은 적합하지 않습니다.

D. 새 웹 사이트 및 Amazon S3 버킷 생성. 웹 사이트 호스팅이 활성화된 S3 버킷에 웹 사이트 배포

• Amazon S3는 정적 웹 호스팅을 지원하여, 정적인 콘텐츠를 저렴한 비용으로 호스팅할 수 있습니다. 특히, 연간 4번 정도 업데이트가 필요한 웹사이트의 경우, S3 버킷을 통해 효율적으로 관리할 수 있습니다.
• S3는 운영 오버헤드가 적고, 높은 확장성을 제공하므로 정적 콘텐츠를 제공하는 사이트에 적합합니다.

E. 새로운 웹사이트를 생성합니다. Application Load Balancer 뒤에서 Amazon EC2 인스턴스의 Auto Scaling 그룹을 사용하여 웹 사이트를 배포

• EC2 인스턴스와 ALB를 활용한 배포는 동적 웹사이트와 고성능 애플리케이션을 위해 설계된 방식입니다. 하지만 이 경우에는 정적 콘텐츠를 관리하는 것이므로 과도한 인프라 리소스가 필요하지 않습니다.
• 운영 오버헤드와 비용이 증가하므로, 이 요구사항에는 적합하지 않습니다.

문제 9 : 회사는 데이터 센터에서 SMB 파일 서버를 실행하고 있습니다. 파일 서버는 파일이 생성된 후 처음 며칠 동안 자주 액세스하는 대용량 파일을 저장합니다. 7일이 지나면 파일에 거의 액세스하지 않습니다. 총 데이터 크기가 증가하고 있으며 회사의 총 저장 용량에 가깝습니다. 솔루션 설 계자는 가장 최근에 액세스한 파일에 대한 저 지연(low latency) 액세스를 잃지 않으면서 회사의 사용 가능한 저장 공간을 늘려야 합니다. 솔루션 설계자는 향후 스토리지 문제를 방지하기 위해 파일 수명 주기 관리도 제공해야 합니다.

 

A. AWS DataSync를 사용하여 SMB 파일 서버에서 AWS로 7일이 지난 데이터를 복사합니다.

• AWS DataSync는 온프레미스 데이터와 AWS 간의 데이터 전송을 자동화하는 서비스입니다. SMB 파일 서버에서 AWS로 데이터 복사 및 이동 작업을 효율적으로 수행할 수 있습니다.
• 그러나, 7일이 지난 데이터를 자동으로 복사한 이후의 스토리지 정책이나 아카이빙에 대한 언급이 없습니다. 또한, 저렴한 스토리지로 데이터를 전환하거나 데이터 보관 정책을 구현하는 데 적합하지 않을 수 있습니다.
• 따라서, DataSync만으로는 저비용 아카이빙 정책을 완전히 충족하지 않습니다.

B. Amazon S3 파일 게이트웨이를 생성하여 회사의 저장 공간을 확장합니다. S3 수명 주기 정책을 생성하여 7일 후에 데이터를 S3 Glacier Deep Archive로 전환합니다.

• Amazon S3 파일 게이트웨이는 온프레미스 파일 서버를 Amazon S3에 연결하여, 데이터를 S3로 직접 저장할 수 있도록 합니다. 이를 통해 파일 서버에 무제한 스토리지를 제공할 수 있습니다.
• S3의 수명 주기 정책을 사용하면 특정 기간 후 데이터를 S3 Glacier Deep Archive로 자동으로 이동시킬 수 있습니다. 이렇게 하면, 7일이 지난 데이터를 저렴한 S3 Glacier Deep Archive 스토리지로 전환하여 비용을 절감할 수 있습니다.
• S3 파일 게이트웨이와 수명 주기 정책의 조합은 저비용, 저지연 스토리지를 제공하면서 오래된 데이터는 자동으로 아카이빙하므로, 요구 사항을 충족하는 적합한 솔루션입니다.

C. Amazon FSx for Windows 파일 서버 파일 시스템을 생성하여 회사의 저장 공간을 확장합니다.

• Amazon FSx for Windows는 Windows 기반 애플리케이션에 네이티브 파일 스토리지 서비스를 제공합니다. FSx는 SMB 프로토콜을 지원하므로 기존 파일 서버를 대체할 수 있습니다.
• 그러나, FSx는 저비용 아카이빙 기능이나 자동으로 7일이 지난 데이터를 Glacier와 같은 저렴한 스토리지로 전환하는 기능을 제공하지 않습니다.
• 이 방식은 아카이빙 요구 사항을 충족하지 않기 때문에 적합하지 않습니다.

D. 각 사용자의 컴퓨터에 유틸리티를 설치하여 Amazon S3에 액세스합니다. S3 수명 주기 정책을 생성하여 7일 후 데이터를 S3 Glacier Flexible Retrieval로 전환합니다.

• 이 선택지는 각 사용자 컴퓨터에 유틸리티를 설치하여 S3에 직접 접근하도록 합니다.
• 이 방법은 관리와 운영 측면에서 번거롭고, 다수의 사용자에게 S3 접근을 위한 유틸리티 설치를 요구하므로 유지보수 비용이 많이 발생할 수 있습니다.
• 또한, 파일 서버와 S3 간 직접 연결이 아닌 사용자마다 개별 설정이 필요해 운영 효율성이 떨어집니다.

 

문제 10 : 회사는 Amazon EC2 인스턴스에서 배치 애플리케이션을 실행하고 있습니다. 애플리케이션은 여러 Amazon RDS 데이터베이스가 있는 백엔드로 구성됩니다. 애플리케이션으로 인해 데이터베이스에서 많은 수의 리드가 발생합니다. 솔루션 설계자는 고가용성을 보장하면서 데이터베이스 읽기 수를 줄여야 합니다. 솔루션 설계자는 이 요구 사항을 충족하기 위해 무엇을 해야 합니까? A

 

A. Amazon RDS 읽기 전용 복제본 추가

• Amazon RDS는 읽기 전용 복제본(Read Replica)을 지원하여 데이터베이스의 읽기 트래픽을 분산할 수 있습니다. 복제본은 기본 데이터베이스의 데이터를 실시간으로 복제하여 여러 인스턴스에서 읽기 요청을 처리할 수 있게 합니다.
• 따라서, 이 방식은 데이터베이스에 대한 읽기 트래픽을 분산시키기 위한 적절한 솔루션입니다.
• 읽기 전용 복제본은 읽기 요청이 많은 애플리케이션에 매우 유용하며, 기본 인스턴스에 과도한 부하가 걸리는 것을 방지할 수 있습니다.

B. Redis용 Amazon ElastiCache 사용

• Amazon ElastiCache는 데이터베이스의 읽기 요청을 줄이기 위해 캐시를 사용하는 서비스입니다. Redis는 메모리 기반의 고속 캐시로서, 자주 조회되는 데이터를 캐싱하여 데이터베이스로의 요청을 줄여줍니다.
• 캐싱을 통해 데이터베이스의 부하를 상당히 줄이고, 읽기 성능을 향상시키는 데 매우 효과적입니다.
• Redis는 RDS로부터 자주 조회되는 데이터를 메모리에 저장하고, 애플리케이션이 이 캐시에 직접 접근하도록 하여 데이터베이스 부담을 줄일 수 있습니다.

C. Amazon Route 53 DNS 캐싱 사용

• Route 53 DNS 캐싱은 주로 DNS 쿼리 응답 속도를 높이기 위해 사용되며, 도메인 이름을 IP 주소로 변환하는 작업을 가속화합니다.
• 이 기능은 애플리케이션의 데이터베이스 읽기 성능 개선과는 관련이 없습니다. 따라서, Route 53 DNS 캐싱은 이 문제를 해결하는 데 적합하지 않습니다.

D. Memcached용 Amazon ElastiCache 사용

• ElastiCache Memcached는 기본적인 메모리 캐시 역할을 합니다. Redis와 유사하게 데이터를 메모리에 저장하지만, Redis와 달리 데이터 지속성 기능이 제한적이며, 고급 기능이 부족합니다.
• Redis는 다양한 데이터 구조 지원, 데이터 복제 및 고가용성 구성 등 더 풍부한 기능을 제공하며, 읽기 성능 향상과 데이터 관리 측면에서 더 적합합니다.
• 특히, Redis는 데이터 복제와 클러스터링을 통해 더 강력한 확장성과 고가용성을 제공합니다.