게임 출시 기간 동안 한 회사는 Network Load Balancer 뒤에서 12개의 r6g.16xlarge(메모리 최적화) Amazon EC2 인스턴스를 실행했습니다. 모니터링 결과 실제 사용량은 예상 CPU 및 메모리의 약 1/4에 불과했습니다. 이제 수요가 감소하여 변동성이 커졌습니다. 회사는 비용을 최소화하기 위해 고정 플릿을 CPU 및 메모리를 기반으로 확장되는 Auto Scaling 그룹으로 교체할 것입니다. 요구 사항을 충족하면서 가장 비용 효율적인 Auto Scaling 구성은 무엇입니까?

원래 r6g.16xlarge 인스턴스 12개가 사용되었고, 실제 사용량은 예상 CPU 및 메모리의 약 1/4에 불과했습니다. 이는 각 인스턴스가 과도하게 프로비저닝되었음을 의미합니다. r6g.16xlarge 인스턴스는 64 vCPU와 512GB 메모리를 제공하므로, 1/4 사용량은 약 16 vCPU와 128GB 메모리에 해당합니다. r6g.4xlarge 인스턴스는 16 vCPU와 128GB 메모리를 제공하여, 기존 인스턴스 1개의 1/4 사용량과 일치합니다. 따라서 r6g.4xlarge 인스턴스 3개는 원래 12개의 r6g.16xlarge 인스턴스와 동일한 총 용량을 제공합니다 (12 1/4 = 3). 최소 용량 3, 원하는 용량 3, 최대 용량 12는 초기 요구 사항을 충족하면서 비용 효율적인 확장을 가능하게 합니다. c6g.4xlarge는 컴퓨팅 최적화, m6g.4xlarge는 범용이므로 메모리 최적화된 기존 워크로드에 적합하지 않습니다. r6g.8xlarge는 여전히 과도하게 프로비저닝될 수 있으며, 2개의 인스턴스로 시작하는 것은 충분한 용량을 제공하지 못할 수 있습니다.