# COST 5. 서비스를 선택할 때 비용을 어떻게 평가하나요?
Amazon EC2, Amazon EBS 및 Amazon S3는 기본 구성 AWS 서비스입니다. Amazon RDS 및 Amazon DynamoDB와 같은 관리형 서비스는 더 높은 수준이거나 애플리케이션 수준의 AWS 서비스입니다. 기본 구성 서비스와 관리형 서비스를 적절히 선택하여 이 워크로드의 비용을 최적화할 수 있습니다. 예를 들어 관리형 서비스를 사용하면 관리 및 운영 고정 비용을 상당 부분 줄이고, 애플리케이션 및 비즈니스 관련 활동에 집중할 수 있습니다.
**Topics**
+ [COST05-BP01 조직의 비용 요구 사항 파악](cost_select_service_requirements.md)
+ [COST05-BP02 워크로드의 모든 구성 요소 분석](cost_select_service_analyze_all.md)
+ [COST05-BP03 각 구성 요소의 철저한 분석 수행](cost_select_service_thorough_analysis.md)
+ [COST05-BP04 비용 효율적인 라이선스가 포함된 소프트웨어 선택](cost_select_service_licensing.md)
+ [COST05-BP05 조직의 우선순위에 따라 비용을 최적화할 이 워크로드의 구성 요소 선택](cost_select_service_select_for_cost.md)
+ [COST05-BP06 시간별로 사용량이 달라지는 경우 비용 분석 수행](cost_select_service_analyze_over_time.md)
# COST05-BP01 조직의 비용 요구 사항 파악
팀원과 협의하여 이 워크로드의 비용 최적화와 기타 원칙(예: 성능, 신뢰성) 사이의 균형을 정의합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 가이드
대부분의 조직에서 정보 기술(IT) 부서는 여러 소규모 팀으로 구성되어 있으며, 팀마다 팀원의 전문성과 기술을 반영하여 고유한 과제와 중점 영역을 가지고 있습니다. 조직의 전반적인 목표, 우선순위, 세부 목표 및 각 부서 또는 프로젝트가 이러한 전반적인 목표에 어떻게 기여하는지 이해해야 합니다. 인력, 장비, 기술, 자재 및 외부 서비스를 포함한 모든 필수 리소스를 분류하는 것은 조직 목표를 달성하고 종합적인 예산 계획을 수립하는 데 매우 중요합니다. 비용 식별 및 이해를 위해 이러한 체계적인 접근 방식을 채택하는 것은 조직에서 현실적이고 강력한 비용 계획을 수립하는 데 필수적입니다.
워크로드에 사용할 서비스를 선택할 때는 조직의 우선순위를 이해하는 것이 중요합니다. 비용 최적화와 기타 AWS Well-Architected Framework 원칙(예: 성능 및 신뢰성) 사이에서 균형을 맞춥니다. 이 프로세스는 조직의 목표, 시장 상황 및 운영 역학의 변화를 반영하기 위해 체계적이고 정기적으로 수행되어야 합니다. 완전한 비용 최적화 워크로드는 조직의 요구 사항과 가장 일치하는 솔루션을 의미하며 꼭 비용이 가장 낮은 솔루션이 아닐 수 있습니다. 조직 내 모든 팀(예: 제품, 비즈니스, 기술, 재무)과 회의를 통해 정보를 수집합니다. 주력할 영역을 결정하거나 수행할 조치를 선택할 때 정보를 토대로 결정을 내릴 수 있도록 상충하는 이해관계나 대안 사이에서 장단점의 영향을 평가합니다.
예를 들어, 비용 최적화보다 새로운 기능의 시장 출시를 앞당기는 데 더 역점을 둘 수 있습니다. 아니면 데이터 유형에 최적화된 데이터베이스로 마이그레이션하고 애플리케이션을 업데이트하는 대신, 시스템 마이그레이션 작업을 간소화하기 위해 비관계형 데이터용 솔루션으로 관계형 데이터베이스를 선택할 수도 있습니다.
### 구현 단계
+ ** 조직의 비용 요구 사항 파악:** 제품 관리, 애플리케이션 소유자, 개발 및 운영 팀, 관리 및 재무 역할 등 조직의 다양한 팀원을 만납니다. 이 워크로드와 그 구성 요소에 대해 Well-Architected 원칙의 우선순위를 정합니다. 원칙을 순서대로 나열해야 합니다. 각 원칙에 가중치를 더할 수도 있습니다. 이를 통해 원칙에 얼마나 더 많은 초점이 맞춰져 있는지 또는 두 원칙 사이에 초점이 얼마나 비슷한지 알 수 있습니다.
+ **기술적 부채 해결 및 문서화:** 워크로드 검토 중에 기술 부채를 해결합니다. 백로그 항목을 문서화하여 향후 워크로드를 재검토합니다. 워크로드를 리팩터링 또는 다시 설계하여 한층 더 최적화하는 것을 목표로 합니다. 장단점을 다른 이해관계자에게 명확하게 전달하는 것이 중요합니다.
## 리소스
**관련 모범 사례:**
+ [REL11-BP07 가용성 목표 및 가동 시간 서비스 수준에 관한 계약(SLA)을 충족하도록 제품 설계](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_service_level_agreements.html)
+ [OPS01-BP06 장단점 평가](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
**관련 문서:**
+ [AWS 총 소유 비용(TCO) 계산기](https://aws.amazon.com/tco-calculator/)
+ [Amazon S3 storage classes](https://aws.amazon.com/s3/storage-classes/)
+ [클라우드 제품](https://aws.amazon.com/products/)
# COST05-BP02 워크로드의 모든 구성 요소 분석
현재 크기나 비용을 막론하고 모든 워크로드 구성 요소가 분석되도록 해야 합니다. 검토 작업은 현재 비용과 예상 비용 등의 잠재적인 이점을 반영해야 합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
조직에 비즈니스 가치를 제공하도록 설계된 워크로드 구성 요소에는 다양한 서비스가 포함될 수 있습니다. 각 구성 요소에 대해 비즈니스 요구 사항을 해결하기 위해 특정 AWS 클라우드 서비스를 선택할 수도 있습니다. 이 선택은 이러한 서비스에 대한 친숙도나 사용 경험 등 여러 요인의 영향을 받을 수 있습니다.
[COST05-BP01 조직의 비용 요구 사항 파악](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_select_service_requirements.html)에서 언급한 대로, 조직의 요구 사항을 파악한 후 워크로드의 모든 구성 요소를 철저히 분석합니다. 현재 및 예상 비용과 크기를 고려하여 각 구성 요소를 분석합니다. 수명 주기 동안 발생할 수 있는 워크로드 절감 효과와 비교하여 분석 비용을 고려합니다. 이 워크로드의 모든 구성 요소를 분석하는 데 드는 노력은 구성 요소를 최적화함으로써 예상되는 잠재적 절감 또는 개선 효과에 상응해야 합니다. 예를 들어 제안된 리소스의 비용이 월 10 USD이고 과소 예측된 로드가 월 15 USD를 초과하지 않는 경우, 비용을 50%(월 5 USD) 절감하기 위해 들여야 하는 하루분의 노력이 시스템 수명 동안 얻을 수 있는 잠재적 이점보다 더 클 수 있습니다. 더 빠르고 효율적인 데이터 기반 추정을 사용하면 이 구성 요소에 대해 전반적으로 가장 좋은 결과를 얻을 수 있습니다.
워크로드는 시간이 지남에 따라 변경될 수 있으며 워크로드 아키텍처 또는 사용량이 변경되면 워크로드에 가장 적합한 서비스 세트도 변경될 수 있습니다. 서비스 선택을 분석할 때는 현재 및 향후 워크로드 상태 및 사용량 수준을 포함해야 합니다. 향후 워크로드 상태 또는 사용량에 대한 서비스를 구현하면 향후 변경에 필요한 노력을 줄이거나 제거하여 전반적인 비용을 절감할 수 있습니다. 예를 들어 처음에는 EMR 서버리스를 사용하는 것이 적절할 수 있습니다. 그러나 이 서비스의 소비가 증가함에 따라 EMR on EC2로 전환하면 워크로드의 해당 구성 요소에 대한 비용을 줄일 수 있습니다.
[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 및 AWS Cost and Usage Report([CUR](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/))를 사용하여 개념 증명(PoC) 또는 환경 실행 비용을 분석할 수 있습니다. [AWS Pricing Calculator](https://calculator.aws/#/)를 사용하여 워크로드 비용을 추정할 수도 있습니다.
기술 팀이 워크로드를 검토하기 위해 따라야 할 워크플로를 작성하세요. 이 워크플로를 단순하게 유지하되, 팀이 워크로드의 각 구성 요소와 가격을 이해할 수 있도록 필요한 모든 단계를 다루어야 합니다. 그러면 조직은 각 팀의 특정 요구 사항에 따라 이 워크플로를 따르고 사용자 지정할 수 있습니다.
1. **워크로드에 사용 중인 각 서비스 나열:** 이는 좋은 출발점입니다. 현재 사용 중인 모든 서비스와 비용의 출처를 파악하세요.
1. **해당 서비스의 요금 책정 방식 이해:** 각 서비스의 [요금 모델](https://aws.amazon.com/pricing/)을 이해합니다. AWS 서비스마다 사용량, 데이터 전송, 기능별 요금 등의 요소에 따라 가격 책정 모델이 다릅니다.
1. **예상치 못한 워크로드 비용이 발생하고 예상 사용량 및 비즈니스 성과와 일치하지 않는 서비스에 집중:** AWS Cost Explorer 또는 AWS Cost and Usage Report를 사용하여 비용이 가치나 사용량에 비례하지 않는 이상치 또는 서비스를 식별합니다. 비용을 비즈니스 성과와 연관시켜 최적화 작업의 우선순위를 정하는 것이 중요합니다.
1. **AWS Cost Explorer, CloudWatch Logs, VPC 흐름 로그 및 Amazon S3 Storage Lens를 통해 이러한 고비용의 근본 원인 파악:** 이러한 도구는 고비용을 진단하는 데 중요한 역할을 합니다. 각 서비스는 사용량과 비용을 확인하고 분석하기 위한 다양한 렌즈를 제공합니다. 예를 들어 Cost Explorer에서는 전체 비용 추세를 파악할 수 있고, CloudWatch Logs는 운영 인사이트를 제공하며, VPC 흐름 로그는 IP 트래픽을 표시하고, Amazon S3 Storage Lens는 스토리지 분석에 유용합니다.
1. **AWS Budgets를 사용하여 서비스 또는 계정의 일정 금액에 대한 예산 설정:** 예산을 설정하면 비용을 사전에 관리할 수 있습니다. AWS Budgets를 사용하여 사용자 지정 예산 임곗값을 설정하고 비용이 임곗값을 초과할 경우 알림을 받습니다.
1. **Amazon CloudWatch 경보를 구성하여 청구 및 사용 알림 전송:** 비용 및 사용량 지표에 대한 모니터링 및 알림을 설정합니다. CloudWatch 경보를 통해 특정 임곗값 위반 시 이를 알릴 수 있으므로 개입 응답 시간이 향상됩니다.
현재 속성에 관계없이 모든 워크로드 구성 요소에 대한 전략적 검토를 통해 시간이 지남에 따라 눈에 띄는 개선과 비용 절감이 이루어지도록 합니다. 이 검토 프로세스에 투자하는 노력은 실현될 수 있는 잠재적 이점을 주의 깊게 고려하여 신중하게 이루어져야 합니다.
### 구현 단계
+ **워크로드 구성 요소 나열:** 워크로드 구성 요소 목록을 작성합니다. 이 목록을 사용하여 각 구성요소가 분석되었는지 확인할 수 있습니다. 여기에 드는 노력은 조직의 우선순위에 정의된 워크로드에 대한 중요도를 반영해야 합니다. 리소스를 그룹화하면 프로덕션 데이터베이스 스토리지의 경우처럼 데이터베이스가 여러 개인 경우 효율성이 향상됩니다.
+ **구성 요소 목록의 우선순위 지정:** 구성 요소 목록을 가져와서 작업량순으로 우선순위를 지정합니다. 일반적으로 구성 요소의 비용(가장 비싼 것부터 가장 싼 것까지) 또는 조직 우선순위에 정의된 중요도의 순서를 따릅니다.
+ **분석 수행:** 목록의 각 구성 요소에 대해 사용 가능한 옵션과 서비스를 검토하고 조직의 우선순위에 가장 잘 맞는 옵션을 선택합니다.
## 리소스
**관련 문서:**
+ [AWS Pricing Calculator](https://calculator.aws/#/)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ [Amazon S3 storage classes](https://aws.amazon.com/s3/storage-classes/)
+ [AWS 클라우드 제품](https://aws.amazon.com/products/)
**관련 비디오:**
+ [AWS Cost Optimization Series: CloudWatch](https://www.youtube.com/watch?v=6imTJUGEzjU)
# COST05-BP03 각 구성 요소의 철저한 분석 수행
조직에서 발생하는 각 구성 요소의 전반적인 비용을 확인합니다. 그런 다음 운영 및 관리 비용을 감안하여 총 소유 비용을 계산합니다(특히, 클라우드 제공업체에서 관리형 서비스를 사용하는 경우). 검토 작업은 잠재적 이점을 반영해야 합니다(예를 들어 분석에 소요된 시간이 구성 요소의 비용에 비례).
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
팀에서는 이렇게 절약된 시간을 기술적 부채 청산, 혁신 및 부가 가치 기능과 비즈니스를 차별화할 수 있는 요인을 만드는 데 집중할 수 있다는 점을 고려하세요. 예를 들어 온프레미스 환경에서 클라우드로 데이터베이스를 최대한 빠르게 리프트 앤 시프트(리호스팅이라고도 함)하고 최적화는 나중에 수행해야 할 수 있습니다. AWS에서 라이선스 비용이 거의 발생하지 않거나, 전혀 발생하지 않을 수 있는 관리형 서비스를 사용하여 실현한 비용 절감 이점을 파악하는 것이 좋습니다. AWS의 관리형 서비스는 서비스 유지 관리를 위한 운영 및 관리 부담(예: OS 패치 적용 또는 업그레이드)을 없애 혁신 및 비즈니스에 집중할 수 있도록 합니다.
관리형 서비스는 클라우드 규모로 운영되므로 거래 또는 서비스당 비용을 절감할 수 있습니다. 애플리케이션의 핵심 아키텍처를 변경하지 않고 실질적인 이점을 달성하기 위해 잠재적인 최적화를 수행할 수 있습니다. 예를 들어, [Amazon Relational Database Service(RDS)](https://aws.amazon.com/rds/) 등과 같은 서비스형 데이터베이스 플랫폼으로 마이그레이션하거나 [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/)과 같은 완전관리형 플랫폼으로 애플리케이션을 마이그레이션하여 데이터베이스 인스턴스를 관리하는 데 소요되는 시간을 단축할 수 있습니다.
관리형 서비스에는 대개 충분한 용량을 보장하기 위해 설정할 수 있는 속성이 있습니다. 초과 용량을 최소한으로 유지하면서 성능은 극대화할 수 있도록 이러한 속성을 설정하고 모니터링해야 합니다. AWS Management Console 또는 AWS API 및 SDK를 사용해 AWS Managed Services의 속성을 수정하여 변화하는 수요에 맞게 리소스 요구를 조정할 수 있습니다. 예를 들어, Amazon EMR 클러스터나 Amazon Redshift 클러스터의 노드 수를 늘리거나 줄여서 스케일 아웃 또는 스케일 인할 수 있습니다.
또한 AWS 리소스의 여러 인스턴스를 압축하여 리소스 사용 밀도를 높일 수도 있습니다. 예를 들어 단일 Amazon Relational Database Service(RDS) 데이터베이스 인스턴스에 소형 데이터베이스 여러 개를 프로비저닝할 수 있습니다. 그리고 사용량이 증가하면 스냅샷 및 복원 프로세스를 사용하여 데이터베이스 중 하나를 전용 Amazon RDS 데이터베이스 인스턴스로 마이그레이션할 수 있습니다.
관리형 서비스에서 워크로드를 프로비저닝할 때는 서비스 용량 조정 요구 사항을 파악해야 합니다. 일반적으로 이러한 요구 사항은 시간, 작업량 및 정상 워크로드 작동에 미치는 영향을 의미합니다. 리소스를 프로비저닝할 때는 변경이 발생하기까지 소요되는 시간을 고려하여 이 시간을 허용하는 데 필요한 오버헤드를 프로비저닝해야 합니다. Amazon CloudWatch 등의 시스템 및 모니터링 도구와 통합된 API와 SDK를 사용하면 서비스를 수정하는 데 필요한 지속적인 작업을 사실상 수행하지 않아도 됩니다.
[Amazon RDS](https://aws.amazon.com/rds/), [Amazon Redshift](https://aws.amazon.com/redshift/), [Amazon ElastiCache](https://aws.amazon.com/elasticache/)에서는 관리형 데이터베이스 서비스를 제공합니다. [Amazon Athena](https://aws.amazon.com/athena/), [Amazon EMR](https://aws.amazon.com/emr/), [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/)에서는 관리형 분석 서비스를 제공합니다.
[AMS](https://aws.amazon.com/managed-services/)는 엔터프라이즈 고객 및 파트너를 대신하여 AWS 인프라를 운영하는 서비스입니다. 이 서비스를 사용하면 규정을 준수하는 안전한 환경에 워크로드를 배포할 수 있습니다. AMS는 자동화가 포함된 엔터프라이즈 클라우드 운영 모델을 사용하므로 고객은 조직 요구 사항을 충족하면서 클라우드로 더 빠르게 이전하고 지속적인 관리 비용을 절감할 수 있습니다.
**구현 단계**
+ ** 철저한 분석 수행:** 구성 요소 목록을 사용하여 가장 높은 우선순위부터 가장 낮은 우선순위까지 각 구성 요소를 살펴봅니다. 우선순위가 높고 비용이 많이 드는 구성 요소의 경우 추가 분석을 수행하고 사용 가능한 모든 옵션과 장기적인 영향을 평가합니다. 우선순위가 낮은 구성 요소의 경우 사용량 변화로 인해 구성 요소의 우선순위가 변경되는지 평가한 다음 적절한 작업에 대한 분석을 수행합니다.
+ **관리형 및 비관리형 리소스 비교:** 관리하는 리소스의 운영 비용을 고려하고 AWS 관리형 리소스와 비교합니다. 예를 들어, Amazon EC2 인스턴스에서 실행 중인 데이터베이스를 검토한 다음, Amazon EC2 기반 Apache Spark를 실행하는 것에 비해 Amazon RDS 옵션(AWS 관리형 서비스) 또는 Amazon EMR을 사용하는 경우를 비교합니다. 자체 관리형 워크로드에서 AWS 완전관리형 워크로드로 이전하는 경우 옵션을 주의해서 살펴보세요. 여기서 고려해야 할 가장 중요한 세 가지 요소는 사용하려는 [관리형 서비스의 유형](https://aws.amazon.com/products/?&aws-products-all.q=managed), [데이터 마이그레이션](https://aws.amazon.com/big-data/datalakes-and-analytics/migrations/)에 사용할 프로세스 및 [AWS 공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)에 대한 이해도입니다.
## 리소스
**관련 문서:**
+ [AWS 총 소유 비용(TCO) 계산기](https://aws.amazon.com/tco-calculator/)
+ [Amazon S3 storage classes](https://aws.amazon.com/s3/storage-classes/)
+ [AWS 클라우드 제품](https://aws.amazon.com/products/)
+ [AWS Shared Responsibility Model ](https://aws.amazon.com/compliance/shared-responsibility-model/)
**관련 비디오:**
+ [ Why move to a managed database? ](https://www.youtube.com/watch?v=VRFdc-MVa4I)
+ [ What is Amazon EMR and how can I use it for processing data? ](https://www.youtube.com/watch?v=jylp2atrZjc)
**관련 예제:**
+ [ Why to move to a managed database ](https://aws.amazon.com/getting-started/hands-on/move-to-managed/why-move-to-a-managed-database/)
+ [ Consolidate data from identical SQL Server databases into a single Amazon RDS for SQL Server database using AWS DMS](https://aws.amazon.com/blogs/database/consolidate-data-from-identical-sql-server-databases-into-a-single-amazon-rds-for-sql-server-database-using-aws-dms/)
+ [ Deliver data at scale to Amazon Managed Streaming for Apache Kafka (Amazon MSK) ](https://aws.amazon.com/getting-started/hands-on/deliver-data-at-scale-to-amazon-msk-with-iot-core/?ref=gsrchandson)
+ [ Migrate an ASP.NET web application to AWS Elastic Beanstalk](https://aws.amazon.com/getting-started/hands-on/migrate-aspnet-web-application-elastic-beanstalk/?ref=gsrchandson&id=itprohandson)
# COST05-BP04 비용 효율적인 라이선스가 포함된 소프트웨어 선택
오픈 소스 소프트웨어에는 워크로드 비용에서 상당한 부분을 차지할 수 있는 소프트웨어 라이선스 비용이 없습니다. 라이선스가 부여된 소프트웨어가 필요한 경우 CPU와 같은 임의의 속성에 바인딩된 라이선스를 피하고 결과 또는 성과에 바인딩된 라이선스를 찾습니다. 이러한 라이선스의 비용은 해당 라이선스가 제공하는 혜택에 더 근접하게 조정됩니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 지침
오픈 소스는 소프트웨어가 특정 무료 배포 기준을 준수함을 알리는 소프트웨어 개발이라는 맥락에서 시작되었습니다. 오픈 소스 소프트웨어는 누구나 검사, 수정, 개선할 수 있는 소스 코드로 구성됩니다. 라이선스 비용을 최소화하기 위해 비즈니스 요구 사항, 엔지니어의 역량, 예상 사용량 또는 기타 기술 종속성에 따라 AWS에서 오픈 소스 소프트웨어를 사용하는 것을 고려할 수 있습니다. 즉, [오픈 소스 소프트웨어](https://aws.amazon.com/what-is/open-source/)를 사용하면 소프트웨어 라이선스 비용을 줄일 수 있습니다. 라이선스 비용은 워크로드 규모가 확장됨에 따라 워크로드 비용에 상당한 영향을 미칠 수 있습니다.
총 비용 대비 라이선스 소프트웨어의 이점을 측정하여 워크로드를 최적화하세요. 라이선스 변경 사항과 이러한 변경 사항이 워크로드 비용에 미치는 영향을 모델링합니다. 공급업체가 데이터베이스 라이선스 비용을 변경하는 경우 이 비용이 워크로드의 전반적인 효율성에 어떤 영향을 미치는지 조사합니다. 공급업체의 기간별 요금 발표를 고려하여 제품 전반의 라이선스 변경 추세를 파악합니다. 또한 라이선스 비용은 하드웨어에 따라 확장되는 라이선스(CPU 바인딩 라이선스)와 같이 처리량이나 사용량에 관계없이 확장될 수 있습니다. 이러한 라이선스는 해당하는 결과 없이 비용이 빠르게 증가할 수 있으므로 피해야 합니다.
예를 들어 Linux 운영 체제로 us-east-1에서 Amazon EC2 인스턴스를 운영하면 Windows에서 실행되는 다른 Amazon EC2 인스턴스를 실행하는 것에 비해 비용을 약 45% 절감할 수 있습니다.
[AWS Pricing Calculator](https://calculator.aws/)는 Amazon RDS 인스턴스 및 다양한 데이터베이스 엔진과 같은 다양한 라이선스 옵션을 사용하여 다양한 리소스의 비용을 비교할 수 있는 포괄적인 방법을 제공합니다. 또한 AWS Cost Explorer는 기존 워크로드, 특히 다른 라이선스와 함께 제공되는 워크로드의 비용에 대해 매우 유용한 관점을 제공합니다. 라이선스 관리를 위해 [AWS License Manager](https://aws.amazon.com/license-manager)에서는 소프트웨어 라이선스를 감독하고 처리할 수 있는 간소화된 방법을 제공합니다. AWS 클라우드에서 선호하는 오픈 소스 소프트웨어를 배포하고 운영할 수 있습니다.
### 구현 단계
+ ** 라이선스 옵션 분석:** 사용 가능한 소프트웨어의 라이선스 약관을 검토합니다. 필요한 기능을 갖춘 오픈 소스 버전을 찾고 라이선스가 부여된 소프트웨어의 혜택이 비용보다 큰지 확인합니다. 소프트웨어에서 제공하는 이점과 소프트웨어의 비용이 일치하는 것이 유리한 약관입니다.
+ ** 소프트웨어 공급자 분석:** 공급자의 과거 요금 또는 라이선스 변경을 검토합니다. 특정 공급자의 하드웨어 또는 플랫폼에서 실행에 대한 징벌적 조건과 같이 성과에 부합하지 않는 변경 사항을 찾습니다. 또한 공급업체가 감사를 수행하는 방법과 부과될 수 있는 페널티를 알아봅니다.
## 리소스
**관련 문서:**
+ [ Open Source at AWS](https://aws.amazon.com/opensource/)
+ [AWS 총 소유 비용(TCO) 계산기](https://aws.amazon.com/tco-calculator/)
+ [Amazon S3 storage classes](https://aws.amazon.com/s3/storage-classes/)
+ [클라우드 제품](https://aws.amazon.com/products/)
**관련 예제:**
+ [ Open Source Blogs ](https://aws.amazon.com/blogs/opensource/)
+ [AWS Open Source Blogs ](https://aws.github.io/)
+ [ Optimization and Licensing Assessment ](https://aws.amazon.com/optimization-and-licensing-assessment/)
# COST05-BP05 조직의 우선순위에 따라 비용을 최적화할 이 워크로드의 구성 요소 선택
워크로드에 대한 모든 구성 요소를 선택할 때는 비용을 고려해야 합니다. 여기에는 애플리케이션 수준 및 관리형 서비스 또는 서버리스, 컨테이너 또는 이벤트 기반 아키텍처를 사용한 전반적인 비용 절감이 포함됩니다. 오픈 소스 소프트웨어, 라이선스 요금이 없는 소프트웨어 또는 비용 절감을 위한 대안을 사용하여 라이선스 비용을 최소화합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
모든 구성 요소를 선택할 때 서비스 및 옵션 비용을 고려합니다. 이 과정에서 [Amazon Relational Database Service](https://aws.amazon.com/rds/)(RDS), [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), [Amazon Simple Notification Service](https://aws.amazon.com/sns/)(SNS), [Amazon Simple Email Service](https://aws.amazon.com/ses/)(Amazon SES) 등의 애플리케이션 수준 서비스와 관리형 서비스를 사용하여 전체적인 조직 비용을 절감할 수 있습니다.
컴퓨팅 구성 요소의 경우에는 서버리스 서비스와 컨테이너를 사용합니다(예: 정적 웹 사이트의 경우 [AWS Lambda](https://aws.amazon.com/lambda/) 및 [Amazon Simple Storage Service](https://aws.amazon.com/s3/)(S3)). 가능하면 애플리케이션을 컨테이너화하고 [Amazon Elastic Container Service](https://aws.amazon.com/ecs/)(Amazon ECS) 또는 [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/)(Amazon EKS)와 같은 AWS 관리형 컨테이너를 사용합니다.
오픈 소스 소프트웨어 또는 라이선스 요금이 없는 소프트웨어를 사용하여 라이선스 비용을 최소화합니다(예: 컴퓨팅 워크로드용 Amazon Linux 또는 Amazon Aurora로 데이터베이스 마이그레이션).
[Lambda](https://aws.amazon.com/lambda/), [Amazon Simple Queue Service(Amazon SQS)](https://aws.amazon.com/sqs/), [Amazon SNS](https://aws.amazon.com/sqs/), [Amazon SES](https://aws.amazon.com/ses/)와 같은 서버리스 또는 애플리케이션 수준 서비스를 사용할 수 있습니다. 이러한 서비스를 사용하면 리소스를 관리할 필요가 없으며 코드 실행, 대기열 서비스 및 메시지 전송 기능이 제공됩니다. 또 다른 이점은 사용량에 따라 성능과 비용이 조정되므로 효율적인 비용 할당 및 귀속이 가능하다는 것입니다.
[이벤트 기반 아키텍처](https://aws.amazon.com/what-is/eda/) 사용은 서버리스 서비스에서도 가능합니다. 이벤트 기반 아키텍처는 푸시 기반이므로 이벤트가 라우터에 나타날 때 모든 것이 온디맨드 방식으로 발생합니다. 이렇게 하면 이벤트가 있는지 확인하기 위한 지속적인 폴링 비용을 지불하지 않습니다. 즉, 네트워크 대역폭 소비, CPU 사용률, 유휴 플릿 용량, SSL/TLS 핸드셰이크가 줄어듭니다.
서버리스에 대한 자세한 내용은 [Well-Architected Serverless Application Lens 백서](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html)를 참조하세요.
### 구현 단계
+ **각 서비스를 선택하여 비용 최적화:** 우선순위가 지정된 목록 및 분석을 사용하여 조직의 우선순위와 가장 잘 일치하는 각 옵션을 선택합니다. 수요를 충족하기 위해 용량을 늘리는 대신 더 저렴한 비용으로 더 뛰어난 성능을 선사할 수 있는 다른 옵션을 고려해 보세요. 예를 들어, AWS에서 데이터베이스에 대해 예상되는 트래픽을 검토해야 하는 경우 인스턴스 크기를 늘리거나 Amazon ElastiCache 서비스(Redis 또는 Memcached)를 사용하여 데이터베이스에 캐시된 메커니즘을 제공하는 것을 고려하세요.
+ **이벤트 기반 아키텍처 평가:** 서버리스 아키텍처를 사용하면 분산된 마이크로서비스 기반 애플리케이션을 위한 이벤트 기반 아키텍처를 구축할 수도 있습니다. 이러한 아키텍처는 확장 가능하고 복원력이 있으며 민첩하고 비용 효과적인 솔루션을 구축하는 데 도움이 됩니다.
## 리소스
**관련 문서:**
+ [AWS 총 소유 비용(TCO) 계산기](https://aws.amazon.com/tco-calculator/)
+ [AWS Serverless](https://aws.amazon.com/serverless/)
+ [이벤트 기반 아키텍처(EDA)란 무엇인가요?](https://aws.amazon.com/what-is/eda/)
+ [Amazon S3 storage classes](https://aws.amazon.com/s3/storage-classes/)
+ [클라우드 제품](https://aws.amazon.com/products/)
+ [Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/elasticache/redis)
**관련 예제:**
+ [Getting started with event-driven architecture](https://aws.amazon.com/blogs/compute/getting-started-with-event-driven-architecture/)
+ [이벤트 중심 아키텍처](https://aws.amazon.com/event-driven-architecture/)
+ [How Statsig runs 100x more cost-effectively using Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/blogs/database/how-statsig-runs-100x-more-cost-effectively-using-amazon-elasticache-for-redis/)
+ [AWS Lambda 함수 작업의 모범 사례](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html)
# COST05-BP06 시간별로 사용량이 달라지는 경우 비용 분석 수행
워크로드는 시간이 지남에 따라 바뀔 수 있습니다. 일부 서비스 또는 기능은 다양한 사용 수준에서 더 비용 효율적입니다. 예상 사용량에 따라 시간별로 각 구성 요소 분석을 수행하면 수명 주기 동안 워크로드를 비용 효과적으로 유지할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
AWS에서 새로운 서비스와 기능이 릴리스되면 워크로드에 대한 최적의 서비스가 변경될 수 있습니다. 필요한 노력에는 잠재적 이점이 반영되어야 합니다. 워크로드 검토 빈도는 조직의 요구 사항에 따라 다릅니다. 비용이 높은 워크로드인 경우 새로운 서비스를 빨리 구현할수록 비용 절감이 극대화되므로 검토를 자주 수행하는 것이 좋습니다. 사용량 패턴이 변경되는 경우에도 검토를 다시 시작해야 합니다. 사용량의 큰 변화는 대체 서비스가 더 적합하다는 의미일 수 있습니다.
데이터를 AWS 클라우드로 이전해야 하는 경우 데이터세트가 파일, 데이터베이스, 머신 이미지, 블록 볼륨 또는 테이프 백업이든 상관없이 AWS에서 제공하는 광범위한 서비스 및 파트너 도구를 사용하여 데이터세트를 마이그레이션할 수 있습니다. 예를 들어, 많은 양의 데이터를 AWS 안팎으로 이동하거나 엣지에서 데이터를 처리하기 위해 AWS 목적별 디바이스 중 하나를 사용하여 페타바이트 단위의 데이터를 오프라인에서 비용 효율적으로 이동할 수 있습니다. 또 다른 예로, 더 빠른 데이터 전송 속도의 경우 직접 연결 서비스가 비즈니스에 필요한 일관된 연결을 제공하는 VPN보다 더 저렴할 수 있습니다.
시간의 흐름에 따라 달라지는 사용량에 대한 비용 분석을 기반으로 규모 조정 활동을 검토합니다. 결과를 분석하여 여러 인스턴스 유형 및 구매 옵션으로 인스턴스를 추가하도록 규모 조정 정책을 조정할 수 있는지 알아봅니다. 설정을 검토하여 플릿 크기가 더 작은 사용자 요청을 처리하기 위해 최솟값을 줄일 수 있는지 확인하고 더 많은 리소스를 추가하여 예상되는 높은 수요를 충족합니다.
조직의 이해관계자와 논의하여 시간의 흐름에 따라 달라지는 사용량에 대한 비용 분석을 수행하고 [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html)의 예측 기능을 사용하여 서비스 변경이 미치는 잠재적인 영향을 예측합니다. AWS Budgets, CloudWatch 결제 경보 및 AWS Cost Anomaly Detection을 사용하여 사용 수준 트리거를 모니터링해 가장 비용 효과적인 서비스를 식별하여 더 빠르게 구현합니다.
**구현 단계**
+ ** 예측된 사용 패턴 정의:** 마케팅 및 제품 소유자와 같은 조직과 협력하여 워크로드의 예상 사용 패턴과 예측 사용 패턴을 문서화합니다. 비즈니스 이해관계자와 과거 비용 및 예측 비용과 사용량 증가에 대해 논의하여 비즈니스 요구 사항에 따라 증가되도록 합니다. 더 많은 사용자가 AWS 리소스를 사용할 것으로 예상되는 일, 주 또는 월을 식별합니다. 리소스 사용이 늘어난다는 것은 기존 리소스 용량을 증가하거나 추가 서비스를 채택하여 비용을 줄이고 성능을 개선해야 함을 나타냅니다.
+ ** 예측 사용량에 대한 비용 분석 수행:** 정의된 사용 패턴을 사용하여 이러한 각 지점에서 분석을 수행합니다. 분석 작업은 잠재적 성과를 반영해야 합니다. 예를 들어 사용량 변화가 큰 경우 비용과 변경 사항을 확인하기 위해 철저한 분석을 수행해야 합니다. 다시 말해, 비용이 높아지면 비즈니스를 위한 사용량도 따라서 증가해야 합니다.
## 리소스
**관련 문서:**
+ [AWS 총 소유 비용(TCO) 계산기](https://aws.amazon.com/tco-calculator/)
+ [Amazon S3 storage classes](https://aws.amazon.com/s3/storage-classes/)
+ [클라우드 제품](https://aws.amazon.com/products/)
+ [ Amazon EC2 Auto Scaling ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [ Cloud Data Migration ](https://aws.amazon.com/cloud-data-migration/)
+ [AWS Snow Family](https://aws.amazon.com/snow/)
**관련 비디오:**
+ [AWS OpsHub for Snow Family](https://www.youtube.com/watch?v=0Q7s7JiBCf0)