# 20 – 가시성, 계획 및 거버넌스로 비용 관리
**비용 최적화 및 인식을 보장하기 위해 클라우드 재무 관리(CFM)를 어떻게 실행합니까?** 시작부터 운영에 이르기까지 어떻게 SAP 클라우드 인프라 예산 관리를 설정하고 비즈니스 요구 사항에 맞춰 지속적으로 사용량을 최적화합니까?
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/design-principle-20.html)
# 모범 사례 20.1 - 프로젝트 단계에서 소비 모델 및 환경 사용량 계획
마이그레이션 또는 구현 프로젝트 등 프로젝트 중에 단계적 접근 방식으로 시스템을 배포하는 경우가 많습니다. 또한 크기 조정 및 사용 프로필을 설정하는 안정화 기간도 있습니다. 이 기간 동안 유연성과 온디맨드 인스턴스 기능을 활용하여 비용을 최소화합니다.
**제안 사항 20.1.1 – 필요한 경우에만 시스템을 배포하도록 계획**
리드 타임을 단축하려면 필요한 경우에만 시스템을 배포할 수 있는 옵션을 제공해야 합니다. 단기 프로젝트 시스템의 경우 온디맨드 인스턴스를 사용하여 필요한 기간 동안 프로젝트 시스템을 구축합니다.
**제안 사항 20.1.2 – 예상 기간 및 사용 프로필에 따라 요금 옵션을 평가**
프로젝트 기간과 업무 시간은 요금 모델에 영향을 미칩니다. 온디맨드 요금 모델이 프로젝트 시작 시 기본적으로 선택되는 경우가 많습니다. 적절한 경우 더 저렴한 옵션으로 조정할 수 있도록 예산을 정의하고 평가합니다.
**제안 사항 20.1.3 – 사용하지 않는 시스템을 일시 중단 또는 폐기하도록 계획**
프로젝트가 더 이상 활성 상태가 아니거나 목적을 달성한 경우 인스턴스 종료에 따른 비용 절감과 폐기에 따른 스토리지 절감을 고려합니다. 일반적으로 프로젝트는 마이그레이션 중에 시스템의 복사본을 여러 개 생성합니다. 사용되지 않는 시스템은 종료해야 합니다.
# 모범 사례 20.2 - 다양한 가격 책정 방식을 활용하는 다년 계획 비용 모델 설정
요금 모델을 최대한 활용하여 AWS에서 제공하는 할인을 극대화할 수 있도록 용량 요구 사항에 대한 다년 계획을 수립합니다. 비용 기준을 설정하고 비용을 추적합니다. 클라우드 요금 모델은 변화하는 비즈니스 요구 사항에 대응하여 탄력적으로 인프라를 조정할 수 있는 유연성을 제공합니다. 장기 Savings Plan 또는 예약 인스턴스를 약정하기 전에 최소 3년간 예상되는 SAP 시스템 사용량을 이해하고 계획합니다. 테스트, SAP Quick Sizer 출력 및 증가 예측을 사용하여 데이터를 기반으로 약정 계획을 수립하고 워크로드에 대한 최대 할인을 활용합니다.
**제안 사항 20.2.1 – 주요 비즈니스 이벤트를 이해하여 용량 추정치를 설정**
SAP 워크로드는 일반적으로 사용 패턴 및 운영 시간이 알려져 있어 안정적입니다. SAP 시스템에 대해 잘 파악된 안정 상태 용량 기준을 설정합니다. 이 작업은 배포 초기 몇 주 동안 성능 테스트 및 프로덕션 환경 모니터링을 통해 수행할 수 있습니다.
다음을 고려하여 안정 상태 용량 추정치를 최소 3년 범위로 확장합니다.
+ 인수, 합병, 매각과 같은 주요 비즈니스 이벤트
+ 데이터 스토리지 요구 사항 또는 비즈니스 프로세스 빈도에 영향을 줄 수 있는 규정 변경
+ 정상적인 비즈니스 운영으로 인한 데이터 증가(데이터가 스토리지 크기 외에 컴퓨팅 크기에도 영향을 미치므로 SAP HANA와 같은 인 메모리 데이터베이스에 특히 중요)
+ 주요 시스템 업그레이드, 시스템 교체 또는 폐기
**제안 사항 20.2.2 – 1년 또는 3년 약정이 적절한지 평가**
용량 추정치를 사용하여 3년 약정 컴퓨팅을 활용할 때 가능한 할인을 극대화할 수 있는 SAP 워크로드의 양을 평가합니다. 다음 사항을 고려하세요.
+ SAP 워크로드의 모든 컴퓨팅 요구 사항에 3년 약정을 고려할 수 있습니까?
+ 변화하지 않을 것이라고 확신하는 일부 요구 사항에 3년 약정을 고려할 수 있습니까? 예: SAP 기본 애플리케이션 서버 또는 프라이머리 데이터베이스.
+ SAP 워크로드가 향후 SAP 용량 요구 사항의 변화로 인해 컴퓨팅 요구 사항이 감소할 때 초과 컴퓨팅 약정을 사용할 수 있는 보다 광범위한 AWS 조직의 일부입니까?
+ SAP 워크로드가 보다 광범위한 AWS 조직의 일부이며 연중무휴 24시간 운영할 필요가 없는 비프로덕션 환경에 대한 컴퓨팅 약정을 공유할 수 있습니까?
+ 중기 용량 변화의 경우 3년 컴퓨팅 계획을 약정하는 이점이 초과 또는 미사용 용량 낭비보다 더 큽니까(예: 단기 약정 대비 손익분기점이 20개월)?
+ 단기적으로 주요 비즈니스 변경 또는 교체의 영향을 받을 가능성이 있는 애플리케이션에 대해 단기 약정(1년)을 고려할 수 있습니까?
+ 환율 변동이 고려해야 할 문제입니까? AWS 요금은 미국 달러(USD)입니다(AWS 중국 제외). 고정 환율이 바람직한 경우 가능하면 전체 선결제 요금 모델을 고려할 수 있습니다.
할인을 극대화하기 위해 워크로드 용량 요구 사항을 약정 기간과 일치시키는 계획을 수립합니다.
![\[Timeline showing SAP workload capacity allocation over 3 years with different commitment types.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/images/example-timeline-of-planning-sap-on-aws-compute-commitments.png)
**제안 사항 20.2.3 – 할인폭을 늘리기 위해 컴퓨팅 유형을 고정하는 것이 적절한지 평가**
SAP 워크로드는 일반적으로 제한된 세트의 AWS 컴퓨팅 유형만 사용하므로 할인을 극대화하기 위해 특정 컴퓨팅 패밀리 또는 특정 인스턴스 유형을 약정하는 것이 워크로드에 적합한지 고려해야 합니다. 컴퓨팅에 대한 가장 할인이 높은 두 요금 모델은 EC2 Instance Savings Plans 및 표준 예약 인스턴스입니다.
다음 사항을 고려하세요.
+ 환경에서 자주 사용되는 컴퓨팅 유형을 식별하여 이에 대한 특정 EC2 Instance Savings Plans 또는 표준 예약 인스턴스를 구매하는 것을 고려합니다. 예를 들어 여러 SAP 애플리케이션을 위한 애플리케이션 서버에 `m5.xlarge` 를 사용 중인 경우입니다. 항상 이 약정을 사용할 가능성이 높기 때문에 이는 EC2 전용 Savings Plan 또는 표준 예약 인스턴스를 구매하기에 좋은 후보입니다.
+ 워크로드 증가 또는 비즈니스 이벤트로 인해 EC2 패밀리를 변경할 가능성이 높은 컴퓨팅 구성 요소를 식별합니다. 이러한 항목에는 보다 일반적인 Compute Savings Plans 또는 컨버터블 예약 인스턴스를 구매하는 것이 좋습니다. 예를 들어 SAP HANA 데이터베이스가 6개월 만에 크기 증가로 인해 EC2 `r5` 에서 `x1e` 컴퓨팅 패밀리로 이동해야 하는 경우입니다. 이는 단기 컨버터블 예약 인스턴스 또는 Compute Savings Plans에 적합한 후보입니다.
+ 일반 컴퓨팅 가격과 특정 컴퓨팅 가격의 손익분기점을 식별하고 약정 유형을 선택할 때 이를 고려합니다. 예를 들어 3년 차에 크기 조정 변경이 있는 경우 3년 컨버터블 예약 인스턴스를 약정하는 것보다 3년 동안 표준 예약 인스턴스를 구매하는 것이 더 저렴할 수 있습니다. AWS 예약 인스턴스 Marketplace에서 잔여 예약 인스턴스 가치를 판매하는 것도 고려할 수 있습니다.
+ 인스턴스 유형을 변경하기 전에 AWS Marketplace 판매자 비공개 제안 또는 연간 구독 소프트웨어의 사용을 식별합니다. 이렇게 하면 추가 소프트웨어 비용이 발생하지 않습니다. 두 플랜 모두 지정된 기간 동안 한 Amazon EC2 인스턴스에서 소프트웨어 제품을 실행하도록 약정함으로써 비용을 절감할 수 있습니다. 예를 들어 `r4.xlarge` 인스턴스에서 실행할 소프트웨어에 대한 연간 구독을 구매했습니다. 인스턴스 유형을 `r5.xlarge` 로 변경하기로 결정했습니다. 연간 구독은 더 이상 인스턴스에 연결되지 않지만 여전히 활성 상태입니다. 그 결과 `r5.xlarge` 에서 소프트웨어에 대한 추가 온디맨드 요금이 설정됩니다. 인스턴스 크기를 변경하기 전에 연간 구독이 만료될 때까지 기다리는 것이 좋습니다.
**제안 사항 20.2.4 – Savings Plans, 예약 인스턴스 또는 둘 다 더 적합한지 평가**
SAP 워크로드에 적합한 경우 Savings Plans와 예약 인스턴스를 혼합하여 다양한 모델의 이점을 확보합니다. 약정 기간 및 컴퓨팅 요구 사항을 전체적으로 계산한 다음 요금 모델을 선택합니다.
Savings Plans와 예약 인스턴스의 차이점에 대한 자세한 내용은 [비용 최적화]: [모범 사례 18.1 - Amazon EC2에 사용할 수 있는 결제 및 약정 옵션 이해](best-practice-18-1.md) 및 [Compute Savings Plans 및 예약 인스턴스](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html#sp-ris) 에서 찾을 수 있습니다.
[안정성]: [모범 사례 10.2 - 가용성 및 용량 요구 사항에 적합한 아키텍처 선택](best-practice-10-2.md) 을 고려하세요. 여기서는 Savings Plans와 예약 인스턴스 간의 용량 예약 기능 차이점과 절충에 대해 설명합니다.
**제안 사항 20.2.5 – 예산 및 추적 목적을 위해 용량 계획을 비용 모델로 변환**
Savings Plans, 예약 인스턴스 선택, 온디맨드 예산을 최소 3년간의 SAP 환경에 대한 AWS 지출을 추정하는 비용 계획으로 전환합니다. 컴퓨팅 추정치를 다른 AWS 비용과 결합하여 예산 책정 및 추적 목적으로 SAP 워크로드 비용 모델을 완성합니다.
SAP 비용을 추정할 때 다음 항목을 포함해야 합니다.
+ 컴퓨팅 연결 스토리지 비용(예: Amazon EBS 볼륨)
+ 공유 파일 스토리지 비용(예: Amazon EFS 및 Amazon FSx)
+ 백업 스토리지 비용(예: Amazon S3 및 Amazon S3 Glacier)
+ 네트워크 및 VPC 비용(예: Elastic Load Balancer, NAT 게이트웨이, Transit Gateway, 네트워크 아웃바운드 비용, Direct Connect 및 VPN)
+ 관리 및 거버넌스 서비스 비용(예: CloudWatch 세부 지표, AWS CloudTrail 및 AWS Config)
+ 보안 서비스 비용(예: AWS WAF, Amazon GuardDuty 및 AWS Shield)
+ AWS Support 비용(Business 또는 Enterprise)
+ 자격이 있는 기업 할인 프로그램 또는 대량 구매 할인을 고려합니다(자세한 내용은 AWS 계정 관리자에게 문의).
+ 통화: AWS 요금은 미국 달러(USD)입니다. 청구 통화를 선택할 수 있으며 청구서는 USD로 계산되며 경쟁력 있는 환율로 원하는 통화로 환산됩니다.
# 모범 사례 20.3 - 이상 탐지를 포함하여 비용 할당 및 추적을 위한 예산 및 메커니즘 수립
Well-Architected Framework에는 재무 관리를 구현하기 위한 [지침](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/expenditure-and-usage-awareness.html) 이 있습니다. 비즈니스 요구 사항에 따라 연간, 분기별, 월별 또는 일일 예산으로 클라우드 비용 예상치를 설정합니다. 정기적으로 사용량에 따라 예측을 조정하고 패턴 및 이상을 식별합니다. 계정 및 태깅 전략을 사용하여 비용 할당 메커니즘을 설정합니다.
**제안 사항 20.3.1 – 비용 및 결제 도구를 사용하여 지출 가시성을 확보**
SAP 시스템은 사용 패턴이 정적인 경우가 많습니다. 영구적으로 또는 프로젝트 단계에서 온디맨드 요금 모델을 사용하는 경우 Amazon EC2 비용이 변동할 수 있습니다. 데이터 볼륨 관리 전략이 수립되지 않으면 Amazon EBS 및 Amazon S3 비용이 예상보다 높을 수 있습니다.
적은 설정 작업으로 지출 가시성을 확보할 수 있는 도구는 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 입니다. 고급 기계 학습(ML) 기술을 사용하여 비정상적인 지출 및 근본 원인을 식별하므로 조치를 취할 수 있습니다. [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 를 사용하여 예상 비용 및 사용량을 기반으로 맞춤 예산을 설정합니다. 임계값을 초과할 경우 알리도록 예산 경고를 구성합니다.
[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/?track=costop_bottom) 및 [AWS 결제 및 비용 관리](https://docs.aws.amazon.com/account-billing/) 는 가시성 및 분석을 위한 도구를 제공합니다.
추가 지침은 Well-Architected Framework [비용 최적화]: [지출 및 사용량 인식](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/expenditure-and-usage-awareness.html) 에서 찾을 수 있습니다.
**제안 사항 20.3.2 – 태그를 사용하여 지출을 분석 및 할당**
개별 계정, 리소스, 사업부 및 SAP 환경을 기반으로 AWS 리소스 요금을 식별하는 데 도움이 되는 [비용 할당 태그](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html#allocation-what) 를 생성할 수 있습니다. 이러한 태그는 AWS 결제 보고서에 표시되며 Cost Explorer를 사용하여 분석할 수 있습니다. 비용 할당 태그를 사용하여 개별 SAP 환경과 관련된 비용을 결정할 수 있습니다. 더 이상 필요하지 않은 임시 환경 또는 프로젝트 환경과 같은 특정 환경과 관련된 비용을 축소하거나 제거하기 위해 조치를 취해야 하는지 여부를 알리는 데 도움이 됩니다. 비용 할당 태그가 연결되지 않은 리소스를 식별하는 프로세스가 있어야 합니다. 이러한 리소스에 비용 할당 태그를 추가하는 데 필요한 작업을 구현합니다.
+ SAP on AWS 블로그: [SAP on AWS 태깅 권장 사항](https://aws.amazon.com/blogs/awsforsap/tagging-recommendations-for-sap-on-aws/)
# 모범 사례 20.4 - 비용 관련 승인 절차 및 제어 설정
클라우드 준비를 위해 기존 비용 평가 프로세스를 조정해야 할 수도 있습니다. 올바른 재무 관행 및 정책을 구현하는 방법을 숙지하기 위해 [AWS 클라우드 금융 관리 안내서](https://aws.amazon.com/executive-insights/content/cloud-financial-management-reference-guide)를 검토합니다.
**제안 사항 20.4.1 – 관리자에게 비용 영향을 교육**
책임을 할당하고 비용 최적화에 대한 인센티브를 제공하는 메커니즘을 도입합니다.
**제안 사항 20.4.2 – IAM 제어를 사용하여 특정 사용자만 인스턴스를 프로비저닝할 수 있도록 허용**
비용 관리를 보장하기 위해 계정 경계 내에서 리소스 유형 및 직무에 부합하는 IAM 정책을 사용합니다. 예를 들어 샌드박스 계정의 소규모 시스템은 프로젝트 팀 내에서 제어하도록 허용하지만 프로덕션 계정의 대규모 인스턴스에는 추가 승인 프로세스 및 액세스 제한이 있을 수 있습니다.
# 모범 사례 20.5 - 최적화 기회를 위해 사용량을 검토
정기적으로 SAP 워크로드를 검토하여 비용 최적화 기회를 식별합니다. 정기 검토는 다음 사항에 중점을 두어야 합니다. AWS 청구서와 SAP 워크로드 예산 간에 발견되는 차이 및 이상을 최소화, 모든 SAP 클라우드 리소스의 크기가 적절하고 과도하게 프로비저닝되지 않았는지 확인, SAP 워크로드의 비용 효율성을 향상시킬 수 있는 새로운 AWS 서비스 릴리스 또는 비용 절감을 이해.
**제안 사항 20.5.1 – 초기 계획보다 사용량이 많은 경우 추가 비용을 최소화**
계획되지 않은 비즈니스 이벤트 또는 추가로 필요한 성능으로 인해 클라우드 사용량이 예상 비용 모델을 초과하여 증가할 수 있습니다. 새로운 비용을 최적화하기 위해 이러한 변경 사항을 분석합니다. 변경 사항이 지속적인 경우 추가 Savings Plan 약정 또는 예약 인스턴스를 고려합니다.
단기간만 추가 용량이 필요한 경우 추가 비용을 최소화하기 위해 자동 크기 조정 또는 예약된 온디맨드 인스턴스 용량을 사용하는 수평적 확장 메커니즘(예: 추가 SAP 애플리케이션 서버)을 고려합니다.
**제안 사항 20.5.2 – SAP 워크로드 사용량 지표를 검토하고 가능한 경우 추가로 적절히 크기 조정**
SAP 시스템을 지원하는 구성 요소를 정기적으로 검토하여 적절한 크기인지 확인합니다. CloudWatch 지표를 사용하여 다음을 고려합니다.
+ SAP EC2 컴퓨팅이 적절한 크기입니까? CPU 또는 메모리 사용률이 낮습니까? 더 작은 EC2 인스턴스 크기로 이동할 수 있습니까?
+ SAP 스토리지가 적절한 크기입니까? 프로비저닝되었지만 사용되지 않은 초과 공간이 있습니까? 볼륨 크기를 줄일 수 있습니까?
+ SAP 스토리지의 성능이 적절합니까? 줄일 수 있는 초과 IOPS 또는 MBps가 프로비저닝되었습니까?
+ 백업 및 스냅샷이 적절하게 관리되고 있습니까? Amazon S3 Infrequently Accessed 또는 Amazon S3 Glacier에 아카이브할 수 있는 백업 복사본이 S3 Standard에 너무 많습니까?
+ 최적화를 위한 추가 영역을 식별하려면 [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 및 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) 와 같은 도구를 사용합니다. SAP Note: [1656099 - AWS의 SAP 애플리케이션: DB/OS 및 Amazon EC2 제품 지원](https://launchpad.support.sap.com/#/notes/1656099) [SAP 포털 액세스 권한 필요]에 따라 SAP 특정 컴퓨팅 및 스토리지 제한 사항을 인식합니다.
조사 결과를 사용하여 정기적으로 SAP 워크로드 구성 요소를 계속 적절한 크기로 조정하고 Savings Plans 및 예약 인스턴스 사용을 극대화합니다.
**제안 사항 20.5.3 – 새로운 AWS 서비스를 이해하고 추가 비용 최적화를 달성할 수 있는 경우 구현을 계획**
AWS는 정기적으로 새로운 서비스를 출시하고 주기적으로 가격을 인하합니다. 새로운 SAP on AWS 서비스 발표를 검토하고 최소 12개월마다 아키텍처에서 이를 활용할 계획을 수립합니다. AWS와의 Enterprise Support 계약의 일부로 테크니컬 어카운 관리자(TAM)가 있는 경우 정기 신규 서비스 브리핑 및 최적화 논의에서 도움을 받을 수 있습니다.
최신 발표 및 뉴스를 위해 [SAP on AWS 블로그](https://aws.amazon.com/blogs/awsforsap/) 및 [새로운 소식](https://aws.amazon.com/new/) 피드를 구독합니다.
SAP 워크로드의 지속적인 최적화에 대한 자세한 내용은 [운영 우수성]: [모범 사례 4.4 - 주기적 워크로드 검토를 수행하여 복원력, 성능, 민첩성 및 비용 최적화](best-practice-4-4.md) 를 참조하세요.