[Associate SAA-C03] - dump 정리 701 ~ 730

클라우드/AWS

[Associate SAA-C03] - dump 정리 701 ~ 730

코딩하는 도람쥐 2024. 10. 13. 22:49

728x90

701
ALB 뒤의 EC2 인스턴스에서 실행되는 웹 애플리케이션 + 불규칙한 성능 보고 + 무작위 IP 주소에서 발생하는 DDOS 공격과 관련 → 최소한의 구성 변경이 필요하고 DDOS 소스에 대한 감사 추적을 제공하는 솔루션

C. AWS Shield Advanced에 가입하세요. AWS DDoS 대응팀(DRT)에 연락하여 완화 제어를 서비스에 통합하세요.

* Amazon Inspector: 소프트웨어 취약성 및 의도하지 않은 네트워크 노출에 대해 AWS 워크로드를 지속적으로 스캔하는 자동화된 취약성 관리 서비스

* AWS Shield Advanced: 네트워크 트래픽에 대한 상시 작동, 흐름 기반 모니터링과 적극적인 애플리케이션 모니터링을 통해 의심되는 DDoS 공격에 대한 거의 실시간 알림을 제공

AWS WAF는 특정 공격 패턴을 감지할 수 있지만, 대규모 DDoS 공격을 방어는 Shield Advanced + Cloudfront는 새로운 구성 요소이므로 최소한의 구성 변경x

702

200TB의 데이터를 AWS Snowball Edge Storage Optimized 디바이스에 복사 + 고성능 컴퓨팅(HPC)클러스터를 보유 → Snowball 디바이스의 데이터에 대한 일관된 밀리초 미만의 지연시간과 고처리량 액세스 제공

B. Amazon S3 버킷을 만듭니다. S3 버킷으로 데이터를 가져옵니다. Amazon FSx for Lustre 파일 시스템을 구성하고 S3 버킷과 통합합니다. HPC 클러스터 인스턴스에서 FSx for Lustre 파일 시스템에 액세스합니다.

⇒ AWS Lustre: 기계 학습, 고성능 컴퓨팅(HPC) 등 속도가 중요한 워크로드에 사용
Snowball과 Lustre FSx 간의 직접 통합 불가능 → S3 를 통해야함

703
온프레미스 데이터 센터에 NFS 서버 + 이 서버에서 소량의 데이터를 주기적으로 S3에 백업해야함 + 가장 비용 효율적 충족

B. 온프레미스 서버에 AWS DataSync 에이전트를 설정하고 데이터를 Amazon S3와 동기화합니다.

* AWS DataSync: AWS로 데이터 마이그레이션을 간소화 및 가속화하고 온프레미스 스토리지와 AWS 스토리지 간 데이터를 빠르고 안전하게 이동하는 서비스 ⇒ NFS와 같은 파일 시스템에 최적화. 비용 효율적. 주기적인 백업 및 동기화

* AWS DirectConnect: 대규모 데이터 전송. 높은 대역폭과 안정성 제공, 설정과 유지 관리 비용 높음. ⇒ 비용 비효율적
* AWS Transfer Family: SFTP 프로토콜 사용이므로 NFS와 호환X

704

비디오 게임회사 +게임 서버에 대해 초저 지연 시간을 유지 → 매 초 수백만 개의 UDP 인터넷 트래픽 요청을 처리하는 솔루션 + 가장 비용 효율적

C. 인터넷 트래픽에 필요한 프로토콜과 포트로 네트워크 로드 밸런서를 구성합니다. EC2 인스턴스를 대상으로 지정합니다.

⇒ Network Load Balancer 사용

705

데이터베이스 계층은 RDS for MYSQL DB 인스턴스 사용 + RDS for MYSQL을 Aurora PostgreSQL DB 클러스터로 마이그레이션 → 마이그레이션 동안 발생하는 데이터 변경 사항을 복제하는 솔루션

A. AWS Database Migration Service(AWS DMS) 스키마 변환을 사용하여 데이터베이스 객체를 변환합니다.

D. 변경 데이터 캡처(CDC)를 사용하여 데이터를 마이그레이션하기 위한 AWS Database Migration Service(AWS DMS) 작업을 정의합니다.

⇒ CDC(Change Data Capture) 변경 데이터 캡쳐 사용
MYSQL → PostgreSQL로 변환해야 하므로 스키마 변환 사용 ⇒ 스키마 변환은 읽기 복제본에 적용 X

706
데이터베이스에 대해 실행되는 스크립트는 중요한 애플리케이션의 성능에 부정적인 영향

→ 최소한의 비용으로 성능 개선 + 최소한의 운영 오버헤드

B. 데이터베이스의 읽기 복제본을 만듭니다. 전체 새 항목을 보고하기 위해 읽기 복제본만 쿼리하도록 스크립트를 구성합니다.

성능 관련 Issue ⇒ 데이터베이스 읽기 복제본 생성

707
ALB 사용하여 애플리케이션 제공 + 비정상적인 트래픽 액세스 패턴 찾기 + 비정상을 잘 이해할 수 있도록 인프라에 대한 가시성 개선 + 가장 운영 효율적인 솔루션

B. Amazon S3에 ALB 액세스 로깅을 활성화합니다. Amazon Athena에 테이블을 만들고 로그를 쿼리합니다.

S3 + ALB 액세스 로깅 + Athena 테이블 ⇒ 로그 쿼리

* AWS CloudTrail: AWS 계정의 API 호출 및 변경을 위함

708
NAT 게이트웨이 + 프라이빗 서브넷에 있는 EC2 인스턴스를 퍼블릭 인터넷에 연결

C. EC2 인스턴스와 동일한 VPC의 공용 서브넷에 공용 NAT 게이트웨이를 만듭니다.
→ 퍼블릭 서브넷에 NAT 게이트웨이 사용(Public Subnet의 Public NAT GW여야함)

개인 NAT 게이트웨이는 인터넷과의 통신을 지원x

709
Organizations에 조직 + 루트 조직 단위(OU)에 있는 4개의 AWS계정에서 EC2 인스턴스 실행 + 비생산 계정 3개, 생산 계정 1개

→ 사용자가 비생산 계정에서 특정 크기의 EC2 인스턴스를 시작하는 것을 금지 → 금지된 유형을 사용하는 시작 인스턴스에 대한 액세스를 거부하는 SCP(서비스 제어 정책) 생성

B. SCP를 3개의 비생산 조직 회원 계정에 연결합니다.

E. 필요한 계정에 대한 OU를 만듭니다. SCP를 OU에 연결합니다. 비생산 멤버 계정을 새 OU로 이동합니다.

⇒ SCP를 3개의 비생산 조직 회원 계정에 연결 + 필요한 계정에 대한 OU(Organization Unit)생성 + SCP를 OU에 연결, 비생산 멤버 계정을 새 OU로 이동

710
웹 사이트 S3에 저장된 기밀 데이터를 처리 + 보안 문제로 인해 회사는 EC2 리소스와 S3 간에 비공개적이고 안전한 연결 필요

A. VPC 엔드포인트에서 액세스를 허용하도록 S3 버킷 정책을 설정합니다.
→ VPC 엔드포인트 사용: 프라이빗하게 연결

711
애플리케이션은 기본 DB에 대해 Multi-AZ 모드에서 Aurora PostgreSQL 클러스터 사용 → 최근 많은 읽기 및 쓰기 부하 경험 + 시간 초과 문제 → 더 확장 가능하고 고가용성으로

C. Aurora 클러스터에 추가 읽기 인스턴스를 추가합니다. Aurora 클러스터에 대한 Amazon RDS 프록시 대상 그룹을 만듭니다.

⇒ 읽기 복제본 생성 + RDS Proxy 사용

* RDS Proxy: 운영 오버헤드를 줄여 성능 최적화, 완전 관리형, 고가용성, 확장 가능한 프록시로, Lambda에서 실행되는 애플리케이션에서 RDS 인스턴스에 쉽게 연결 가능. 데이터베이스에 대한 연결 관리를 오프로드하여 성능과 안정성 개선

RDS Proxy 지원 데이터베이스 엔진

- Amazon RDS MySQL

- Amazon RDS PostgreSQL

- Amazon Aurora MySQL

- Amazon Aurora PostgreSQL

* Zero-Downtime Restart (ZDR): 시스템이나 애플리케이션을 재시작할 때 서비스 중단 없이 이를 수행하는 기능

712
웹 애플리케이션 설계 + 기존 데이터 센터와 회사의 VPN 연결을 사용 + DNS 서비스로 Route 53 사용 → VPC에서 온프레미스 서비스와 통신하기 위해 Private DNS 레코드 사용 + 가장 안전한 방식

A. Route 53 Resolver 아웃바운드 엔드포인트를 만듭니다. Resolver 규칙을 만듭니다. Resolver 규칙을 VPC와 연결합니다.

* Route 53 Resolver: VPC 내에서 DNS 쿼리 처리. 온프레미스와 하이브리드 클라우드 설정

- 인바운드 엔드포인트: 온프레미스 → VPC의 DNS 쿼리에 사용
- 아웃바운드 엔드포인트: VPC → 온프레미스의 DNS 쿼리에 사용

* Route 53 개인 호스팅 존: VPC 내부의 DNS 레코드 관리에 사용
* Route 53 퍼블릭 호스팅 존: 인터넷에서 사용자가 도메인 이름을 통해 웹사이트와 애플리케이션에 접근.

713
us-east-1 지역에서 사진 호스팅 서비스 운영 + 여러 국가의 사용자가 사진을 업로드하고 볼 수 있음 + 일부 사진은 몇달동안 많이 조회되고, 다른 사진은 일주일도 채 지나지 않아 조회 + 각 사진에 대해 최대 20MB의 업로드 허용 → 가장 비용 효율적으로 적절한 사용자 액세스 제공

B. Amazon S3 Intelligent-Tiering 스토리지 클래스에 사진을 저장합니다. DynamoDB에 사진 메타데이터와 S3 위치를 저장합니다.

* Amazon S3 Intelligent-Tiering: 사용 패턴에 따라 데이터 관리. 액세스 패턴을 모니터링.

→ 무작위의 액세스 패턴(빈번한 액세스 및 드문 액세스) ⇒ S3 Intelligent-Tiering 사용

714
회사가 ALB 뒤의 EC2 인스턴스에서 고가용성 웹 애플리케이션 실행 + CloudWatch 메트릭 사용 + 트래픽 증가에 따라 일부 EC2 인스턴스는 많은 미처리 요청으로 인해 과부하 발생 → 회사는 이미 과부화된 EC2 인스턴스로 새 요청을 전달하기를 원하지 않음

B. RequestCountPerTarget 및 ActiveConnectionCount CloudWatch 메트릭을 기반으로 가장 덜 처리된 요청 알고리즘을 사용합니다.

* RequestCount는 전체 로드 밸런서 수준에서 들어오는 모든 HTTP 요청의 총 수

* RequestCountPerTarget는 로드 밸런서의 각 대상(즉, EC2 인스턴스 또는 기타 대상)에 대해 전달된 요청

라운드 로빈: 순서대로 요청을 처리. 성능 고려x → 실제 부하는 균등하지 않을 수 있음.

715
EC2, Fargate, Lambda를 사용하여 회사의 계정에서 여러 워크로드 실행 → Compute Savings Plan을 최대한 활용하고자함 + Compute Savings Plans의 적용 범위가 줄어들 때 알림을 받고자 함 + 가장 높은 운영 효율성

A. AWS Budgets를 사용하여 Savings Plans에 대한 일일 예산을 만듭니다. 적절한 이메일 메시지 수신자에게 알림을 보내기 위해 적용 범위 임계값으로 예산을 구성합니다.

* AWS Budgets: AWS 비용과 사용량을 모니터링하고 예산 설정을 도와주는 서비스 기간에 대한 예산을 설정하고 실제 사용량이나 비용이 초과하거나 절감하고자 하는 목표를 달성 할 경우 알람을 받을 수 있음, 추가적인 리소스 필요 없으므로 비용 효율적

716

실시간 데이터 수집 솔루션 + Amazon Managed Streaming for Apache Kafka(Amazon MSK)로 구성 → 인터넷을 통해 공개적으로 사용할 수 있도록 데이터 수집 솔루션을 설계 + 전송 중인 데이터도 암호화 해야함 + 가장 높은 운영 효율성

A. 기존 VPC에서 퍼블릭 서브넷을 구성합니다. 퍼블릭 서브넷에 MSK 클러스터를 배포합니다. MSK 클러스터 보안 설정을 업데이트하여 상호 TLS 인증을 활성화합니다.

실시간 데이터 ⇒ UDP 패킷 ⇒ ALB는 될 수가 없음
새로운 VPC 생성하면 이전 VPC와 이어야하기때문에 오버헤드 발생

프라이빗 서브넷은 외부에서 접근이 불가능하므로 요구사항 충족 x

* MSK: 클러스터를 설정, 관리할 필요 없이 데이터 스트리밍 애플리케이션을 쉽게 구축하고 운영

717
레거시 애플리케이션은 온프레미스 ERP 시스템에서 고객 주문 파일 수집 + 파일을 SFTP 서버에 업로드 + 매시간 주문 파일을 확인하는 예약된 작업 사용 + 이미 온프레미스 네트워크에 연결된 AWS 계정을 가지고 있음 + 새 애플리케이션은 기존 ERP 시스템과의 통합을 지원 → 안전하고 복원력 + SFTP 프로토콜을 사용하여 ERP 시스템에서 즉시 주문을 처리해야함

D. 두 개의 가용 영역에 AWS Transfer Family SFTP 내부 서버를 만듭니다. Amazon S3 스토리지를 사용합니다. 주문 파일을 처리하는 AWS Lambda 함수를 만듭니다. Transfer Family 관리 워크플로를 사용하여 Lambda 함수를 호출합니다.

안전 ⇒ 고가용성 ⇒ 2개의 AZ 사용
복원력 ⇒ EFS < S3 사용 : S3는 여러 AZ에 데이터 저장.
SFTP 프로토콜 사용 ⇒ AWS Transfer Family 사용
인터넷 연결 필요 x (보안성) ⇒ 내부 서버

718
애플리케이션은 Apache Hadoop과 Apache Spark를 사용하여 온프레미스 데이터를 처리 + 기존 인프라는 확장성이 없고 관리하기 복잡 → 운영 복잡성을 줄이는 확장 가능한 솔루션을 설계 + 솔루션은 온프레미스에서 데이터 처리를 유지해야함

C. Apache Hadoop 애플리케이션과 Apache Spark 애플리케이션을 AWS Outposts의 Amazon EMR 클러스터로 마이그레이션합니다. EMR 클러스터를 사용하여 데이터를 처리합니다.

* AWS Outposts: 온프레미스 데이터 센터에 설치할 수 있는 완전 관리형 AWS 인프라 및 서비스, AWS의 클라우드 서비스를 온프레미스 환경에서 사용

* Amazon EMR: 확장 가능한 Hadoop 및 Spark 클러스터를 제공하는 AWS의 완전 관리형 서비스

719
온프레미스 스토리지에서 AWS로의 대량의 데이터 마이그레이션 + 동일한 AWS 리전의 Windows, Mac, Linux 기반 EC2 인스턴스는 SMB 및 NFS 스토리지 프로토콜을 사용하여 데이터에 액세스 + 일부 데이터에 정기적 + 나머지 데이터에 드물게 액세스 → 데이터를 호스팅하기 위한 솔루션+ 최소한의 운영 오버헤드

B. Amazon FSx for ONTAP 인스턴스를 만듭니다. 자동 계층화 정책을 사용하는 루트 볼륨이 있는 FSx for ONTAP 파일 시스템을 만듭니다. 데이터를 FSx for ONTAP 볼륨으로 마이그레이션합니다

* Amazon FSx for NetApp ONTAP: NFS,SMB 및 iSCSI 프로토콜을 통해 Linux, Windows, macOS 컴퓨팅 인스턴스에게 광범위하게 액세스 할 수 있는 고성능 파일 스토리지 제공

* FSx for OpenZFS: NFS, SMB

C. S3 Intelligent-Tiering을 사용하는 Amazon S3 버킷을 만듭니다. AWS Storage Gateway Amazon S3 File Gateway를 사용하여 데이터를 S3 버킷으로 마이그레이션합니다.

⇒ 자주 액세스되는 데이터와 드물게 액세스되는 데이터를 자동으로 계층화

720
AWS에서 보고서 생성 애플리케이션 생성 + 각 보고서를 약 20분만에 생성 + 애플리케이션은 단일 EC2 인스턴스에서 실행되는 모놀리스로 구축 → 모듈을 자주 업데이트 + 소프트웨어 모듈을 패치할때마다 애플리케이션은 다운타임을 겪음 + 중단 후 처음부터 다시 시작해야함 + 유연하고 확장 가능해야하며 점진적으로 개선 + 다운타임을 최소화

C. 서비스 자동 확장 기능을 갖춘 마이크로서비스로 Amazon Elastic Container Service(Amazon ECS)에서 애플리케이션을 실행합니다.

⇒ Amazon ECS: 컨테이너 오케이스트레이션 서비스 → 애플리케이션을 여러 마이크로서비스로 분리하여 관리 가능 , 각 모듈을 독립적으로 개발, 배포 및 확장하여 유연성과 확장성을 높임 + 마이크로서비스는 한 모듈의 업데이트가 전체 애플리케이션의 다운타임을 초래하지 않음, 각 서비스는 독립적으로 배포 + 다른 서비스에 영향 X → 업데이트 중에도 계속 애플리케이션 실행 가능

721
대규모 웹 애플리케이션을 서버리스 마이크로서비스 아키텍처로 재구성 + EC2 인스턴스 사용, Python 으로 작성 → 마이크로서비스로 테스트 + 매초 수백 개의 요청을 지원 + Python을 지원하는 AWS 솔루션에서 마이크로서비스를 만들고 테스트해야함 → 자동으로 확장, 최소한의 인프라와 최소한의 운영 지원 필요

D. 맞춤으로 개발된 코드를 실행하는 AWS Lambda 함수를 사용합니다.

⇒ EKS + EC2(운영 오버헤드)
⇒ Lambda만 사용해도 충분

722
온프레미스 위치에서 AWS 계정으로 Direct Connect 연결을 사용 + 동일한 AWS 리전에 30개의 다른 VPC가 존재 + 개인 가상 인터페이스(VIF)를 사용 → 각 VPC가 다른 모든 VPC 및 온프레미스 네트워크와 통신할 수 있도록 하는 동시에 네트워킹 아키텍처를 중앙에서 관리 + 최소한의 운영 오버헤드

A. 트랜짓 게이트웨이를 만들고 Direct Connect 연결을 새 트랜짓 VIF와 연결합니다. 트랜짓 게이트웨이의 경로 전파 기능을 켭니다.

* Transit Gateway: VPC Peering과 마찬가지로 서로 다른 VPC 간에 통신이 가능하게 하는 서비스(여러 VPC 간 연결 정책 중앙에서 관리 가능)

723
EC2 인스턴스에서 실행되는 애플리케이션 + 연관된 정책이 있는 IAM 역할을 사용하여 RDS 데이터베이스에 연결 → 실행중인 애플리케이션을 중단하지 않고도 Systems Manager 사용하여 EC2 인스턴스에 패치를 적용하려함

C. Systems Manager에서 기본 호스트 구성 관리를 활성화하여 EC2 인스턴스를 관리합니다.

⇒ 중단 없이 패치 적용 가능.

1. Session Manager를 사용하여 안전하게 EC2 인스턴스에 연결

2. Patch Manager를 사용하여 자동 패치 스캔을 수행
3. Systems Manager Inventory를 사용하여 인스턴스에 대한 세부 정보 확인
4. Fleet Manager를 사용하여 인스턴스를 추적하고 관리
5. SSM Agent를 자동으로 최신 상태로 유지

* AmazonSSMManagedInstanceCore: Systems Manager에서 관리되는 인스턴스에 필요 권한을 부여하는 IAM 정책.

724
작업 부하 일정x + 클러스터가 최대 용량에 도달했을때 노드 수가 자동으로 확장 X → 가장 적은 운영 관리 오버헤드로 문제 해결

B. Kubernetes Cluster Autoscaler를 사용하여 클러스터의 노드 수를 관리합니다.

⇒ Kubernetes Cluster Autoscaler : 포드가 실패하거나 다른 노드로 다시 예약될 때 클러스터의 노드 수를 자동으로 조정( 작업 부하가 증가하고 기존 노드가 최대 용량에 도달하면 추가 노드가 필요하다는 것 감지 → 기본 인프라에 요청)

725

매달 Amazon S3 Standard 스토리지에 약 300TB를 유지 관리 + S3 객체는 각각 약 50GB 크기 + 글로벌 애플리케이션에서 자주 다중 파트 업로드로 대체 + S3 객체의 수와 크기는 일정 → S3 스토리지 비용은 매달 증가

S3 스토리지 비용 증가 + 멀티 파트 업로드 사용

B. 완료되지 않은 다중 파트 업로드를 삭제하는 S3 수명 주기 정책을 활성화합니다.
⇒ 불필요한 멀티파트 업로드 삭제 (S3 수명주기 정책 이용)

726
모바일 기기에 멀티플레이어 게임을 배포 + 위도와 경도를 기반으로 플레이어의 실시간 위치 추적이 필요 + 데이터 저장소는 위치의 빠른 업데이트와 검색을 지원해야함 → 읽기 복제본이 있는 RDS for PostgreSQL DB 인스턴스를 사용하여 위치 데이터 저장 → 최대
사용 기간 동안 데이터베이스는 업데이트를 읽고 쓰는데 필요한 성능을 유지할 수 없음 + 사용자는 꾸준히 증가

D. 기존 DB 인스턴스 앞에 Amazon ElastiCache for Redis 클러스터를 배포합니다. Redis를 사용하도록 게임을 수정합니다

* PostgreSQL: 관계형 DB

* DynamoDB : 비관계형 DB → ( RDS는 MySQL, PostgreSQL, Oracle, SQL Server 등 관계형 데이터베이스 지원 )
* ElastiCache: 유연하고 실시간 사용 사례를 지원하는 마이크로초 단위의 읽기 및 쓰기 지연 시간을 제공하는 완전 관리형 인메모리 캐싱 서비스. 위치 데이터와 같이 변화하는 데이터 처리에 적합. 자주 접근하는 데이터 캐시.

727
DynamoDB 테이블에 중요한 데이터 저장 + 관리자가 실수로 DynamoDB 테이블을 삭제 → 이런 종류의 중단을 방지하고 싶음 + 최소한의 운영 오버헤드

C. DynamoDB 테이블에 삭제 보호를 구성합니다.
⇒ 삭제 보호 기능은 테이블이 실수로 삭제되는 것을 방지

728
스토리지 용량이 부족한 온프레미스 데이터 센터 + 대역폭 비용을 최소화하면서 스토리지 인프라를 AWS로 마이그레이션 → 추가 비용 없이 데이터를 즉시 검색할 수 있어야함

B. 캐시된 볼륨을 사용하여 AWS Storage Gateway를 배포합니다. Storage Gateway를 사용하여 Amazon S3에 데이터를 저장하고 자주 액세스하는 데이터 하위 집합의 사본을 로컬에 보관합니다.

⇒ Storage Gateway: 파일 기반 게이트웨이, 볼륨 기반, 테이프 기반 솔루션
- 캐시된 볼륨: 자주 액세스 하는 데이터에 대한 저지연 액세스 유지
- 저장된 볼륨: 모든 데이터를 로컬에 저장하도록함

데이터를 즉시 검색할 수 있어야함 ⇒ 캐시된 볼륨 사용

729
각 리소스의 일일 및 주간 과거 워크로드 추세를 분석하는 자동 확장 계획 수립 + 예측 및 사용률의 실시간 변경에 따라 리소스를 적절히 확장

B. 예측 및 확장을 위해 예측적 확장을 활성화합니다. 대상 추적을 사용하여 동적 확장을 구성합니다
⇒ 타겟 추적을 통해 동적 스케일링을 구성함으로써 회사는 예상 수요에 따라 리소스를 자동으로 조정하는 동시에 활용도의 실시간 변경에도 대응

동적확장: 리소스를 자동으로 조정하여 현재의 수요에 적합하게 만드는 프로세스. 특정 기준에 따라 자동으로 추가, 제거

EX. ASG, ELB

730
패키지 배달 회사에 EC2 인스턴스와 Aurora MYSQL DB 클러스터를 사용하는 애플리케이션 + 읽기 복제본을 추가하여 단기간 DB 클러스터 사용량을 줄임 → 부하는 계속 증가 → 사용량 증가를 유발하는 작업은 모두 배달 세부 정보와 관련된 반복 읽기 명령문 + DB 클러스터에서 반복 읽기 영향을 완화해야함

A. 애플리케이션과 DB 클러스터 사이에 Redis 클러스터용 Amazon ElastiCache를 구현합니다.

⇒ Cache: 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소
AWS ElastiCache: 인 메모리 데이터베이스 캐싱 시스템을 제공하여 애플리케이션이 데이터를 검색할 수있는 성능, 속도 및 중복성을 향상시키는 캐싱 서비스

728x90