# 모범 사례 17.4 - SAP 구성 요소에 대한 크기, 세분 수준 및 사용 가능한 최신 EC2 인스턴스 검토 더 작은 EC2 인스턴스가 SAP 워크로드에서 비용 유연성이 더 큽니다. 컴퓨팅을 사용하지 않을 때 종료하거나 피크 로드 중에만 확장할 수 있는 수평 확장 옵션을 제공하기 때문입니다. 애플리케이션 계층에서 일관된 EC2 인스턴스 크기를 채택하면 모든 워크로드에서 예약 인스턴스 및 Savings Plans 약정의 이점을 극대화하는 데 도움이 됩니다. 사용 가능한 최신 AWS SAP 인증 인스턴스를 고려합니다. 각 구성 요소에 대한 운영 영향, 라이선스 비용, 지원, 공유 및 재사용 가능성도 평가해야 합니다. **제안 사항 17.4.1 – 유연성을 제공하기 위해 더 작은 애플리케이션 서버를 여러 개 배포하는 경우의 비용 이점을 평가** 많은 SAP 워크로드의 경우 애플리케이션 서버를 변경할 수 없도록 설계할 수 있습니다. 기본 유닛을 복제하여 수평으로 확장되는 표준 애플리케이션 서버 구성이 있으면 일관된 반복 가능한 유닛에 대한 옵션이 확보됩니다. 장점에는 재사용 가능성, 컴퓨팅 사용률, 예약 및 자동화가 있습니다. 운영 체제 라이선싱, 스토리지 복제 및 관리 비용과 같은 유닛별 요구 사항을 평가에 고려해야 합니다. 다음 사항을 고려하세요. + SAP on AWS 블로그: [DevOps for SAP – Driving Innovation and Lowering Costs(SAP용 DevOps - 혁신을 촉진하고 비용을 절감)](https://aws.amazon.com/blogs/awsforsap/devops-for-sap-driving-innovation-and-lowering-costs/) . + SAP on AWS 블로그: [AWS를 사용하여 SAP Application Auto Scaling 활성화](https://aws.amazon.com/blogs/awsforsap/using-aws-to-enable-sap-application-auto-scaling/) **제안 사항 17.4.2 - 지원되는 경우 SAP HANA 스케일 아웃 구성의 비용 이점을 평가** SAP OLAP 워크로드는 [스케일 업 및 스케일 아웃](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/a165e192ba374c2a8b17566f89fe8419.html) 구성 모두에서 배포할 수 있습니다. SAP는 운영 복잡성을 줄이기 위해 스케일 아웃 전에 스케일 업할 것을 권장합니다. 하지만 스케일 아웃 구현은 상당한 컴퓨팅(SAPS)이 필요한 대규모 분석 또는 네이티브 SAP HANA 워크로드에 적용될 수 있습니다. 일부 경우에는 S/4HANA가 스케일 아웃 구성도 지원하지만 제한 사항이 있습니다. 다음 SAP Note를 참조하세요. [2408419 - SAP S/4HANA - Multi-Node Support](https://launchpad.support.sap.com/#/notes/2408419) [SAP 포털 액세스 권한 필요]. 스케일 업과 스케일 아웃을 비교할 때 다음을 고려하세요. + [인증 EC2 인스턴스 크기](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=iaas;ve:23;v:105) (스케일 업 및 스케일 아웃에 사용 가능) + 각 인스턴스 패밀리의 EC2 메모리 GiB당 비용. 큰 EC2 인스턴스는 일반적으로 작은 인스턴스보다 GiB당 비용이 더 높습니다. + 스케일 아웃 배포에서 가중되는 데이터 배포 관리의 복잡성 및 운영 오버헤드. 다음 SAP Note를 참조하세요. [2081591 - FAQ: SAP HANA Table Distribution](https://launchpad.support.sap.com/#/notes/2081591) [SAP 포털 액세스 권한 필요]