# COST 6. 리소스 유형, 크기 및 수 선택을 통해 비용 목표를 어떻게 달성하나요?
진행 중인 작업에 대해 적절한 리소스 크기와 리소스 수를 선택해야 합니다. 가장 비용 효율적인 유형, 크기 및 수를 선택하여 리소스 낭비를 최소화할 수 있습니다.
**Topics**
+ [
# COST06-BP01 비용 모델링 수행
](cost_type_size_number_resources_cost_modeling.md)
+ [
# COST06-BP02 데이터를 기준으로 리소스 유형, 크기, 개수 선택
](cost_type_size_number_resources_data.md)
+ [
# COST06-BP03 지표를 기준으로 리소스 유형, 크기, 개수 자동 선택
](cost_type_size_number_resources_metrics.md)
+ [
# COST06-BP04 공유 리소스 사용 고려
](cost_type_size_number_resources_shared.md)
# COST06-BP01 비용 모델링 수행
조직 요구 사항(예: 비즈니스 요구 사항 및 기존 약정)을 파악하고 워크로드 및 각 구성 요소의 비용 모델링(전반적인 비용)을 수행합니다. 그리고 예상되는 다양한 부하에서 워크로드의 벤치마크 활동을 수행하여 비용을 비교합니다. 모델링 작업은 잠재적 이점을 반영해야 합니다. 예를 들면 구성 요소의 비용과 비례하여 시간을 소비해야 합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
워크로드와 각 구성 요소에 대한 비용 모델링을 수행하여 리소스 간의 균형을 파악하고 특정 성능 수준을 고려하여 워크로드의 각 리소스에 대해 적합한 크기를 찾습니다. 비용 고려 사항을 이해하면 계획된 워크로드 배포에 대한 가치 실현 성과를 평가할 때 조직의 비즈니스 사례 및 의사 결정 프로세스를 알릴 수 있습니다.
그리고 예상되는 다양한 부하에서 워크로드의 벤치마크 활동을 수행하여 비용을 비교합니다. 모델링 작업은 잠재적 이점을 반영해야 합니다(예: 소요 시간이 구성 요소 비용 또는 예상 절감액에 비례). 모범 사례는 [AWS Well-Architected Framework 성능 효율성 원칙의 검토 섹션](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/review.html)을 참조하세요.
예를 들어, 컴퓨팅 리소스로 구성된 워크로드에 대한 비용 모델링을 생성하기 위해 [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)에서 워크로드 실행을 위한 비용 모델링을 지원할 수 있습니다. 이 서비스는 사용량 기록을 기준으로 컴퓨팅 리소스에 적합한 크기 권장 사항을 제공합니다. AWS Compute Optimizer 내에서 보다 정확한 권장 사항을 제공하는 데 도움이 되는 메모리 지표를 수집하도록 CloudWatch 에이전트가 Amazon EC2 인스턴스에 배포되었는지 확인합니다. 기계 학습을 활용하여 위험 수준에 따라 여러 권장 사항을 제시하는 무료 서비스이므로 컴퓨팅 리소스에 사용하기에 적합한 데이터 소스입니다.
다른 서비스 및 워크로드 구성 요소(예: [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/), [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 및 [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html))에 대한 작업 크기를 올바르게 조정하기 위해 사용자 지정 로그와 함께 데이터 소스로 사용할 수 있는 [여러 서비스](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)가 있습니다. AWS Trusted Advisor는 리소스를 확인하여 사용률이 낮은 리소스에 플래그를 지정합니다. 그러면 리소스의 크기를 올바르게 조정하고 비용 모델링을 생성할 수 있습니다.
다음은 비용 모델링 데이터 및 지표에 대한 권장 사항입니다.
+ 모니터링은 최종 사용자 환경을 정확하게 반영해야 합니다. 기간의 정확한 세부 수준을 선택하고, 평균이 아닌 최대값이나 99번째 백분위수를 적절하게 선택합니다.
+ 모든 워크로드 주기를 포함하는 데 필요한 분석 기간의 정확한 세부 수준을 선택합니다. 예를 들어 분석을 2주 동안 수행하는 경우 사용률이 높은 월 단위 주기를 분석하지 못하여 리소스가 너무 적게 프로비저닝될 수 있습니다.
+ 기존 약정, 다른 워크로드에 대해 선택한 요금 모델, 더 빠르게 혁신하는 기능을 고려하여 계획된 워크로드에 대해 올바른 AWS 서비스를 선택하고 핵심 비즈니스 가치에 집중합니다.
**구현 단계 **
+ **리소스에 대한 비용 모델링 수행:** 테스트할 특정 리소스 유형 및 크기의 별도 계정에 워크로드 또는 개념 증명을 배포합니다. 테스트 데이터로 워크로드를 실행하고 테스트 실행 시간의 비용 데이터와 함께 출력 결과를 기록합니다. 그런 다음 워크로드를 다시 배포하거나 리소스 유형 및 크기를 변경하고 테스트를 다시 실행합니다. 비용 모델링을 생성하는 동안 이러한 리소스와 함께 사용할 수 있는 제품의 라이선스 비용과 이러한 리소스를 배포하고 관리하기 위한 예상 운영(노동력 또는 엔지니어링) 비용을 포함합니다. 기간(시간별, 일별, 월별, 연간 또는 3년)에 따른 비용 모델링을 고려합니다.
## 리소스
**관련 문서:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [ 올바른 크기 조정을 위한 기회 식별 ](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)
+ [Amazon CloudWatch의 기능](https://aws.amazon.com/cloudwatch/features/)
+ [Cost Optimization: Amazon EC2 Right Sizing](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html)
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
+ [AWS 요금 계산기](https://calculator.aws/#/)
**관련 예제:**
+ [ 데이터 기반 비용 모델링 수행](https://aws.amazon.com/blogs/mt/how-to-use-aws-well-architected-with-aws-trusted-advisor-to-achieve-data-driven-cost-optimization/)
+ [ 계획된 AWS 리소스 구성 비용 예측 ](https://aws.amazon.com/premiumsupport/knowledge-center/estimating-aws-resource-costs/)
+ [ Choose the right AWS tools ](https://www.learnaws.org/2019/09/27/choose-right-aws-tools/)
# COST06-BP02 데이터를 기준으로 리소스 유형, 크기, 개수 선택
워크로드 및 리소스 특성에 대한 데이터를 기준으로 리소스 크기나 유형을 선택합니다. 예를 들어, 컴퓨팅, 메모리, 처리량, 쓰기 집약형과 같은 기준이 적용됩니다. 일반적으로는 워크로드의 이전(온프레미스) 버전, 설명서 또는 워크로드와 관련된 기타 정보 출처를 사용해 리소스 사용량을 선택합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
Amazon EC2는 다양한 사용 사례에 맞게 선택할 수 있도록 CPU, 메모리, 스토리지 및 네트워킹 용량 수준이 서로 다른 광범위한 인스턴스 유형을 제공합니다. 이러한 인스턴스 유형에는 CPU, 메모리, 스토리지, 네트워킹 기능이 서로 다르게 조합되어 있어 프로젝트에 적합한 리소스 조합을 다양하게 선택할 수 있습니다. 인스턴스 유형마다 크기가 다양하므로 워크로드의 수요에 따라 리소스를 조정할 수 있습니다. 필요한 인스턴스 유형을 결정하려면 인스턴스에서 실행하려는 애플리케이션 또는 소프트웨어의 시스템 요구 사항에 관한 세부 정보를 수집해야 합니다. 이러한 세부 정보에는 다음이 포함되어야 합니다.
+ 운영 체제
+ CPU 코어 수
+ GPU 코어
+ 시스템 메모리(RAM) 용량
+ 스토리지 유형 및 공간
+ 네트워크 대역폭 요구 사항
컴퓨팅 요구 사항의 목적과 필요한 인스턴스를 파악한 다음 다양한 Amazon EC2 인스턴스 패밀리를 살펴봅니다. Amazon은 다음 인스턴스 유형 패밀리를 제공합니다.
+ 범용
+ 컴퓨팅 최적화
+ 메모리 최적화
+ 스토리지 최적화
+ 가속 컴퓨팅
+ HPC 최적화
특정 Amazon EC2 인스턴스 패밀리가 충족할 수 있는 구체적인 목적과 사용 사례를 더 자세히 이해하려면 [AWS 인스턴스 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)을 참조하세요.
시스템 요구 사항 수집은 요구 사항에 가장 적합한 구체적인 인스턴스 패밀리와 인스턴스 유형을 선택하는 데 매우 중요합니다. 인스턴스 유형 이름은 패밀리 이름과 인스턴스 크기로 구성됩니다. 예를 들어 t2.micro 인스턴스는 T2 패밀리에 속하며 마이크로 크기입니다.
워크로드 및 리소스 특성(예: 컴퓨팅, 메모리, 처리량, 쓰기 집약형)을 기준으로 리소스 크기나 유형을 선택합니다. 일반적으로는 비용 모델링, 온프레미스 버전과 같은 워크로드의 이전 버전, 설명서 또는 워크로드와 관련된 기타 정보 출처(백서 또는 게시된 솔루션)를 사용하여 선택합니다. AWS 요금 계산기 또는 비용 관리 도구를 사용하면 정보를 바탕으로 인스턴스 유형, 크기 및 구성에 대해 결정을 내리는 데 도움이 될 수 있습니다.
### 구현 단계
+ **데이터를 기반으로 리소스 선택:** 비용 모델링 데이터를 사용하여 예상 워크로드 사용 수준을 선택하고 지정된 리소스 유형과 크기를 선택합니다. 비용 모델링 데이터를 기반으로 인스턴스에 필요한 데이터 전송 속도를 고려하여 가상 CPU 수, 총 메모리(GiB), 로컬 인스턴스 스토어 볼륨(GB), Amazon EBS 볼륨, 네트워크 성능 수준을 결정합니다. 항상 상세한 분석과 정확한 데이터를 기반으로 선택하여 비용을 효과적으로 관리하는 동시에 성능을 최적화합니다.
## 리소스
**관련 문서:**
+ [AWS 인스턴스 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [Amazon CloudWatch의 기능](https://aws.amazon.com/cloudwatch/features/)
+ [Cost Optimization: EC2 Right Sizing](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html)
**관련 비디오:**
+ [ Selecting the right Amazon EC2 instance for your workloads ](https://www.youtube.com/watch?v=q5Dn9gcmpJg)
+ [ Right size your service ](https://youtu.be/wcp1inFS78A)
**관련 예제:**
+ [ It just got easier to discover and compare Amazon EC2 instance types ](https://aws.amazon.com/blogs/compute/it-just-got-easier-to-discover-and-compare-ec2-instance-types/)
# COST06-BP03 지표를 기준으로 리소스 유형, 크기, 개수 자동 선택
현재 실행 중인 워크로드의 지표를 사용하여 비용을 최적화하기에 적합한 크기와 유형을 선택합니다. 컴퓨팅, 스토리지, 데이터 및 네트워킹 서비스의 처리량, 크기 및 스토리지를 적절하게 프로비저닝합니다. 자동 조정 등의 피드백 루프나 워크로드의 사용자 지정 코드로 이 프로비저닝을 수행할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 지침
실행 중인 워크로드에서 나오는 활성 지표를 사용하여 해당 워크로드를 변경하는 피드백 루프를 워크로드 내에 생성합니다. [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)과 같은 관리형 서비스를 사용하여 규모 조정 작업을 대신 수행하도록 해당 서비스를 구성할 수 있습니다. 또한 AWS에서는 최소한의 노력으로 리소스를 수정할 수 있는 [API, SDK](https://aws.amazon.com/developer/tools/) 및 기능을 제공합니다. Amazon EC2 인스턴스를 중지하고 시작하도록 워크로드를 프로그래밍하면 인스턴스 크기 또는 인스턴스 유형을 변경할 수 있습니다. 이렇게 하면 변경에 필요한 거의 모든 운영 비용을 절감하면서 규모 조정의 이점을 실현할 수 있습니다.
일부 AWS 서비스에는 [Amazon Simple Storage Service Intelligent-Tiering](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/)과 같은 자동 유형 또는 크기 선택 기능이 기본적으로 포함되어 있습니다. Amazon S3 Intelligent Tiering은 사용 패턴에 따라 자주 접근하고 자주 접근하지 않는 두 개의 접근 계층 간에 자동으로 데이터를 이동합니다.
**구현 단계**
+ **워크로드 지표를 구성하여 관찰성 개선:** 워크로드의 핵심 지표를 캡처합니다. 이러한 지표는 워크로드 출력과 같은 고객 경험을 나타내며 CPU 및 메모리 사용량과 같은 리소스 유형 및 크기 간의 차이에 부합합니다. 컴퓨팅 리소스의 경우 성능 데이터를 분석하여 Amazon EC2 인스턴스 크기를 적절하게 조정합니다. 유휴 인스턴스와 사용률이 낮은 인스턴스를 식별합니다. 확인해야 할 핵심 지표는 CPU 사용량 및 메모리 사용률(예를 들어, [AWS Compute Optimizer 및 메모리 사용률을 활성화하여 적절한 크기 지정](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)에서 설명한 대로 90%의 시간에 40%의 CPU 사용률)입니다. 4주 동안 최대 CPU 사용량과 메모리 사용률이 40% 미만인 인스턴스를 식별합니다. 이것이 비용을 절감하기 위해 적정하게 크기를 조정하는 인스턴스입니다. Amazon S3와 같은 스토리지 리소스의 경우 [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)를 사용할 수 있으며, 이를 통해 기본적으로 버킷 수준에서 다양한 범주의 28개 지표와, 대시보드에서 14일의 기록 데이터를 확인할 수 있습니다. 요약 및 비용 최적화 또는 이벤트를 기준으로 Amazon S3 Storage Lens 대시보드를 필터링하여 특정 지표를 분석할 수 있습니다.
+ **적정 크기 조정 권장 사항 보기:** 비용 관리 콘솔에서 AWS Compute Optimizer 및 Amazon EC2 적정 크기 조정 도구의 적정 크기 조정 권장 사항을 사용하거나, 리소스의 AWS Trusted Advisor 적정 크기 조정을 검토하여 워크로드를 조정합니다. 서로 다른 리소스의 크기를 적절하게 조정할 때는 [올바른 도구](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)를 사용하고 Amazon EC2 인스턴스, AWS 스토리지 클래스 또는 Amazon RDS 인스턴스 유형에 관계없이 [적정 크기 조정 지침](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)을 따르는 것이 중요합니다. 스토리지 리소스의 경우 객체 스토리지 사용량, 활동 추세에 대한 가시성을 제공하고 비용 최적화를 위한 실행 가능한 권장 사항을 제시하며 데이터 보호 모범 사례를 적용할 수 있는 Amazon S3 Storage Lens를 사용할 수 있습니다. [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)가 조직 전체의 지표 분석에서 도출한 상황별 권장 사항을 사용하여 스토리지를 최적화하는 즉각적인 단계를 수행할 수 있습니다.
+ **지표를 기준으로 리소스 유형 및 크기 자동 선택:** 워크로드 지표를 사용하여 워크로드 리소스를 수동 또는 자동으로 선택합니다. 컴퓨팅 리소스의 경우, AWS Auto Scaling을 구성하거나 애플리케이션 내에서 코드를 구현하면 자주 변경해야 하는 경우 필요한 작업량을 줄이고 수동 프로세스보다 빨리 변경 사항을 구현할 수 있습니다. 단일 Auto Scaling 그룹 내에서 온디맨드 인스턴스 및 스팟 인스턴스 플릿를 자동으로 확장할 수 있습니다. 스팟 인스턴스 사용에 대한 할인을 받을 수 있을 뿐만 아니라 예약 인스턴스 또는 Savings Plans를 사용하여 일반 온디맨드 인스턴스 요금의 할인된 요금을 받을 수 있습니다. 이 모든 요소를 결합하여 Amazon EC2 인스턴스의 비용 절감을 최적화하고 애플리케이션에 대해 원하는 규모와 성능을 결정할 수 있습니다. 또한 [Auto Scaling 그룹(ASG)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)의 [속성 기반 인스턴스 유형 선택(ABS)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) 전략을 사용하여 vCPU, 메모리 및 스토리지와 같은 일련의 속성으로서의 인스턴스 요구 사항을 표현할 수 있습니다. 신세대 인스턴스 유형이 릴리스되면 이를 자동으로 사용하고 Amazon EC2 스팟 인스턴스를 통해 더 광범위한 용량에 액세스할 수 있습니다. Amazon EC2 플릿과 Amazon EC2 Auto Scaling은 지정된 속성에 맞는 인스턴스를 선택하고 시작하여 인스턴스 유형을 수동으로 선택할 필요성이 사라집니다. 스토리지 리소스의 경우, 데이터 액세스 패턴이 변경되면 성능 영향이나 운영 오버헤드 없이 자동으로 스토리지 비용이 절감되는 스토리지 클래스를 자동으로 선택할 수 있는 [Amazon S3 Intelligent Tiering](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/) 및 [Amazon EFS Infrequent Access](https://aws.amazon.com/efs/features/infrequent-access/) 기능을 사용할 수 있습니다.
## 리소스
**관련 문서:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Right-Sizing](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/right-sizing/)
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
+ [Amazon CloudWatch의 기능](https://aws.amazon.com/cloudwatch/features/)
+ [CloudWatch Getting Set Up](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/GettingSetup.html)
+ [CloudWatch Publishing Custom Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Getting Started with Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)
+ [Amazon S3 Intelligent-Tiering](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/)
+ [Amazon EFS Infrequent Access](https://aws.amazon.com/efs/features/infrequent-access/)
+ [Launch an Amazon EC2 Instance Using the SDK](https://docs.aws.amazon.com/sdk-for-net/v2/developer-guide/run-instance.html)
**관련 비디오:**
+ [Right Size Your Services](https://www.youtube.com/watch?v=wcp1inFS78A)
**관련 예제:**
+ [Attribute based Instance Type Selection for Auto Scaling for Amazon EC2 Fleet](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [Optimizing Amazon Elastic Container Service for cost using scheduled scaling ](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/)
+ [Predictive scaling with Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [Amazon S3 Storage Lens로 비용 최적화 및 사용량에 대한 가시성 확보](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)
# COST06-BP04 공유 리소스 사용 고려
여러 사업부를 위해 조직 수준에서 이미 배포된 서비스의 경우 공유 리소스를 사용하여 활용도를 높이고 총 소유 비용(TCO)을 줄이는 것을 고려합니다. 공유 리소스는 기존 솔루션을 사용하거나 구성 요소를 공유하거나 두 가지 방법을 모두 사용하여 관리 및 비용을 중앙 집중화하는 비용 효과적인 옵션이 될 수 있습니다. 모니터링, 백업 및 연결과 같은 일반적인 기능을 계정 경계 내에서 또는 전용 계정에서 관리합니다. 또한 표준화를 구현하고, 중복을 줄이고, 복잡성을 줄임으로써 비용을 절감할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
여러 워크로드로 인해 동일한 기능이 발생하는 경우 기존 솔루션과 공유 구성 요소를 사용하여 관리를 개선하고 비용을 최적화합니다. 비프로덕션 데이터베이스 서버 또는 디렉터리 서비스와 같은 기존 리소스(특히 공유 리소스)를 사용하여 보안 모범 사례 및 조직 규정에 따라 클라우드 비용을 절감하는 것을 고려합니다. 최적의 가치 실현과 효율성을 위해서는 쇼백 및 차지백을 사용하여 소비를 발생시키는 비즈니스의 관련 영역에 비용을 다시 할당하는 것이 중요합니다.
*쇼백*은 클라우드 비용을 소비자, 사업부, 총계정원장 계정 또는 기타 책임 주체와 같이 비용의 원인이 될 수 있는 범주로 분류한 보고서입니다. 쇼백의 목표는 팀, 사업부 또는 개인에게 사용된 클라우드 리소스의 비용을 보여 주는 것입니다.
*차지백*은 특정 재무 관리 프로세스에 적합한 전략을 기반으로 중앙 서비스 지출을 비용 단위에 할당하는 것을 의미합니다. 고객의 경우 차지백은 하나의 공유 서비스 계정에서 발생한 비용을 고객 보고 프로세스에 적합한 여러 금융 비용 범주에 청구합니다. 차지백 메커니즘을 설정하여 여러 사업부, 제품 및 팀에서 발생한 비용을 보고할 수 있습니다.
워크로드는 중요한 워크로드와 중요하지 않은 워크로드로 분류할 수 있습니다. 이 분류에 따라 덜 중요한 워크로드에 대해서는 일반 구성이 적용된 공유 리소스를 사용합니다. 비용을 더욱 최적화하려면 중요한 워크로드에 사용할 전용 서버를 예약합니다. 리소스를 공유하거나 여러 계정에 프로비저닝하여 효율적으로 관리합니다. 개발, 테스트 및 프로덕션 환경이 서로 다르더라도 안전한 공유가 가능하며 조직 구조를 변경하지 않아도 됩니다.
컨테이너식 애플리케이션에 대한 이해도를 높이고 비용 및 사용을 최적화하려면 애플리케이션이 공유 컴퓨팅 및 메모리 리소스를 사용하는 방식을 기반으로 개별 비즈니스 엔터티에 비용을 할당하는 데 도움이 되는 분할 비용 할당 데이터를 사용합니다. 분할 비용 할당 데이터를 사용하면 Amazon Elastic Container Service(Amazon ECS) 또는 Amazon Elastic Kubernetes Service(Amazon EKS)에서 실행되는 컨테이너 워크로드에서 작업 수준의 쇼백 및 차지백을 달성할 수 있습니다.
분산 아키텍처의 경우 각 VPC의 워크로드에 필요한 공유 서비스에 대한 중앙 집중식 액세스를 제공하는 공유 서비스 VPC를 구축합니다. 이러한 공유 서비스에는 디렉터리 서비스 또는 VPC 엔드포인트와 같은 리소스가 포함될 수 있습니다. 관리 오버헤드와 비용을 줄이려면 각 VPC에 리소스를 구축하는 대신 중앙 위치에서 리소스를 공유합니다.
공유 리소스를 사용하면 운영 비용을 절감하고 리소스 활용도를 극대화하며 일관성을 개선할 수 있습니다. 다중 계정 설계에서는 일부 AWS 서비스를 중앙에서 호스팅하고 허브에 있는 여러 애플리케이션 및 계정을 사용하여 이러한 서비스에 액세스하면 비용을 절감할 수 있습니다. [AWS Resource Access Manager(AWS RAM)](https://aws.amazon.com/ram/)를 사용하여 [VPC 서브넷 및 AWS Transit Gateway Attachment](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc), [AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall) 또는 [Amazon SageMaker AI 파이프라인](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker)과 같은 기타 공통 리소스를 공유할 수 있습니다. 다중 계정 환경에서 AWS RAM을 사용하면 리소스를 한 번 생성하여 다른 계정과 공유할 수 있습니다.
조직은 공유 비용에 효과적으로 태그를 지정하고 비용 중 상당 부분에 태그가 지정되지 않았거나 할당되지 않은 상태는 아닌지 확인해야 합니다. 공유 비용을 효과적으로 할당하지 않고 공유 비용 관리를 책임지는 사람이 없는 경우 공유 클라우드 비용이 급증할 수 있습니다. 리소스, 워크로드, 팀 또는 조직 수준에서 비용이 발생한 부분을 알아야 합니다. 이러한 지식이 있다면 달성한 비즈니스 성과와 비교할 때 해당 수준에서 얼마나 큰 가치가 제공되었는지 더욱 정확하게 이해할 수 있기 때문입니다. 궁극적으로 조직은 클라우드 인프라 공유를 통해 비용을 절감할 수 있습니다. 공유 클라우드 리소스에 대한 비용 할당을 장려하여 클라우드 지출을 최적화합니다.
### 구현 단계
+ **기존 리소스 평가:** 워크로드에 유사한 서비스를 사용하는 기존 워크로드를 검토합니다. 워크로드의 구성 요소에 따라 비즈니스 논리 또는 기술 요구 사항이 허용하는 경우 기존 플랫폼을 고려합니다.
+ **AWS RAM에서 리소스 공유 사용 및 그에 따라 제한:** 조직 내 다른 AWS 계정과 리소스를 공유하는 데 AWS RAM를 사용합니다. 리소스를 공유할 때 여러 계정에 리소스를 복제할 필요가 없으므로 리소스 유지 관리에 따른 운영 부담이 최소화됩니다. 이 프로세스는 또한 생성한 리소스를 계정의 역할 및 사용자는 물론 다른 AWS 계정과 안전하게 공유하는 데 도움이 됩니다.
+ **리소스에 태그 지정:** 비용 보고 후보인 리소스에 태그를 지정하고 비용 범주 내에서 분류합니다. 비용 할당을 위해 이러한 비용 관련 리소스 태그를 활성화하여 AWS 리소스 사용을 명확하게 확인할 수 있도록 합니다. 비용 및 사용 가시성을 적절한 수준으로 세분화하는 데 집중하고, 비용 할당 보고 및 KPI 추적을 통해 클라우드 소비 행동에 영향을 미칩니다.
## 리소스
**관련 모범 사례:**
+ [SEC03-BP08 안전하게 조직과 리소스 공유](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**관련 문서:**
+ [ What is AWS Resource Access Manager? ](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)
+ [AWS services that you can use with AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [ Shareable AWS resources ](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html)
+ [AWS Cost and Usage (CUR) Queries ](https://catalog.workshops.aws/cur-query-library/en-US)
**관련 비디오:**
+ [AWS Resource Access Manager - granular access control with managed permissions ](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [ How to design your AWS cost allocation strategy ](https://pages.awscloud.com/aws-cfm-talks-how-to-design-your-AWS-cost-allocation-strategy-01122022.html)
+ [AWS Cost Categories ](https://www.youtube.com/watch?v=84GYnBBM0Cg)
**관련 예제:**
+ [ How-to chargeback shared services: An AWS Transit Gateway example ](https://aws.amazon.com/blogs/aws-cloud-financial-management/gs-chargeback-shared-services-an-aws-transit-gateway-example/)
+ [ How to build a chargeback/showback model for Savings Plans using the CUR ](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-build-a-chargeback-showback-model-for-savings-plans-using-the-cur/)
+ [ Using VPC Sharing for a Cost-Effective Multi-Account Microservice Architecture ](https://aws.amazon.com/blogs/architecture/using-vpc-sharing-for-a-cost-effective-multi-account-microservice-architecture/)
+ [ Improve cost visibility of Amazon EKS with AWS Split Cost Allocation Data ](https://aws.amazon.com/blogs/aws-cloud-financial-management/improve-cost-visibility-of-amazon-eks-with-aws-split-cost-allocation-data/)
+ [AWS 분할 비용 할당 데이터를 사용하여 Amazon ECS 및 AWS Batch의 비용 가시성 향상 ](https://aws.amazon.com/blogs/aws-cloud-financial-management/la-improve-cost-visibility-of-containerized-applications-with-aws-split-cost-allocation-data-for-ecs-and-batch-jobs/)