

# 지출 및 사용량 인식
<a name="a-expenditure-and-usage-awareness"></a>

**Topics**
+ [COST 2  사용량을 어떻게 관리합니까?](w2aac19c13b7b5.md)
+ [COST 3  사용량과 비용을 어떻게 모니터링합니까?](w2aac19c13b7b7.md)
+ [COST 4  리소스를 어떻게 폐기합니까?](w2aac19c13b7b9.md)

# COST 2  사용량을 어떻게 관리합니까?
<a name="w2aac19c13b7b5"></a>

목표 달성 과정에서 발생하는 비용을 적정 수준으로 유지하는 정책과 메커니즘을 설정합니다. ‘견제와 균형’ 방식을 도입하면 비용을 과도하게 지출하지 않고 혁신을 이룰 수 있습니다. 

**Topics**
+ [COST02-BP01 조직 요구 사항에 따라 정책 개발](cost_govern_usage_policies.md)
+ [COST02-BP02 목표 및 타겟 이행](cost_govern_usage_goal_target.md)
+ [COST02-BP03 계정 구조 구현](cost_govern_usage_account_structure.md)
+ [COST02-BP04 그룹 및 역할 만들기](cost_govern_usage_groups_roles.md)
+ [COST02-BP05 비용 제어 기능 구현](cost_govern_usage_controls.md)
+ [COST02-BP06 프로젝트 수명 주기 추적](cost_govern_usage_track_lifecycle.md)

# COST02-BP01 조직 요구 사항에 따라 정책 개발
<a name="cost_govern_usage_policies"></a>

 조직에서 리소스를 관리하는 방법을 정의하는 정책을 개발합니다. 정책은 리소스 수명 주기 동안의 생성, 수정, 폐기를 포함한 리소스와 워크로드의 비용 측면을 다루어야 합니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

비용 및 사용량을 효과적으로 관리하고 비용 절감 기회를 식별하려면 조직의 비용 및 동인을 파악하는 것이 중요합니다. 조직에서는 일반적으로 여러 팀이 운영하는 여러 워크로드를 운영합니다. 이러한 팀은 매출원이 각기 다른 개별 조직 단위 소속일 수 있습니다. 워크로드, 개별 조직 또는 제품 책임자에게 리소스 비용을 귀속하는 기능은 효율적인 사용 행동 양식으로 이어지고 낭비되는 요소를 줄여줍니다. 비용 및 사용량을 정확하게 모니터링하면 각 조직 단위와 제품의 수익성 수준을 이해할 수 있으며, 관련 정보를 근거로 하여 조직 내에서 리소스를 할당할 위치를 더 적절하게 결정할 수 있습니다. 비용은 사용량에 따라 변경되므로 비용 변경을 주도하려면 조직의 모든 수준에서 사용량을 인식하는 것이 필수적입니다. 사용량 및 지출을 적절하게 파악하려면 다각적 방식을 사용하는 것이 좋습니다.

거버넌스를 수행하는 첫 번째 단계는 조직의 요구 사항을 활용하여 클라우드 사용에 대한 정책을 개발하는 것입니다. 이러한 정책은 조직에서 클라우드를 사용하는 방법과 리소스를 관리하는 방법을 정의합니다. 정책에는 리소스 수명 주기 동안의 리소스 생성, 수정, 폐기를 비롯하여 비용 또는 사용량과 관련된 워크로드의 모든 측면이 포함되어야 합니다.

정책은 조직 전체에서 쉽게 이해할 수 있고 효과적으로 구현할 수 있을 만큼 단순해야 합니다. 허용되는 지리적 리전 사용량 또는 리소스가 실행되어야 하는 시간 등 넓은 범위의 상위 수준 정책부터 시작합니다. 그런 다음 다양한 조직 단위 및 워크로드에 대한 정책을 점진적으로 구체화합니다. 일반적인 정책에는 사용할 수 있는 서비스 및 기능(예: 테스트 또는 개발 환경의 저성능 스토리지)과 그룹별로 사용할 수 있는 리소스 유형(예: 개발 계정에서 사용할 수 있는 가장 큰 리소스 크기는 중간 크기)이 포함됩니다.

**구현 단계**
+  **팀원과의 만남: **정책 개발을 위해 조직의 모든 팀원이 요구 사항을 지정하고 적절히 문서화하도록 합니다. 광범위하게 시작하여 반복적인 접근 방식을 취하고 각 단계에서 가장 작은 단위까지 계속 세분화합니다. 팀원에는 조직 단위 또는 애플리케이션 소유자와 같이 워크로드에 직접적인 관심이 있는 멤버뿐만 아니라 보안 및 재무 팀과 같은 지원 그룹이 포함됩니다. 
+ ** 워크로드 위치 정의: **국가와 국가 내 지역을 포함한 워크로드의 작동 위치를 정의합니다. 이 정보는 AWS 리전 및 가용 영역에 매핑하는 데 사용됩니다. 
+ ** 서비스와 리소스 정의 및 그룹화: **워크로드에 필요한 서비스를 정의합니다. 서비스마다 필요한 리소스 유형, 크기 및 수를 지정합니다. 애플리케이션 서버나 데이터베이스 스토리지와 같은 기능별로 리소스 그룹을 정의합니다. 리소스는 여러 그룹에 속할 수 있습니다. 
+  **역할별로 사용자 정의 및 그룹화: **누구인지 또는 조직에서 어떤 직책을 맡고 있는지가 아니라 무슨 일을 하며 워크로드를 어떻게 사용하는지에 초점을 두고, 워크로드와 밀접한 일을 하는 사용자를 정의합니다. 유사한 사용자나 역할을 함께 그룹화합니다. AWS 관리형 정책을 가이드로 사용할 수 있습니다. 
+ ** 작업 정의:** 이전에 식별된 위치, 리소스 및 사용자를 사용하여 수명 주기(개발, 운영 및 폐기) 동안 각자 워크로드 성과를 거두는 데 필요한 작업을 정의합니다. 각 위치에서 그룹의 개별 요소가 아니라 그룹을 기반으로 작업을 식별합니다. 읽기 또는 쓰기로 광범위하게 시작한 다음 각 서비스에 대한 특정 작업까지 세분화합니다. 
+ ** 검토 기간 정의:** 워크로드와 조직 요구 사항은 시간이 지나면서 바뀔 수 있습니다. 조직의 우선 순위와 일치하도록 워크로드 검토 일정을 정의합니다. 
+  **정책 문서화: **정의된 정책에 조직의 필요에 따라 액세스할 수 있는지 확인합니다. 이러한 정책은 환경의 액세스를 구현, 유지 관리 및 감사하는 데 사용됩니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [직무 역할에 대한 AWS 관리형 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 
+  [AWS 다중 계정 결제 전략](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [AWS 서비스에 사용되는 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html) 
+  [클라우드 제품](https://aws.amazon.com/products/) 
+  [IAM 정책을 사용하여 AWS 리전에 대한 액세스 제어](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+  [글로벌 인프라 리전 및 AZ](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) 

# COST02-BP02 목표 및 타겟 이행
<a name="cost_govern_usage_goal_target"></a>

 워크로드에 대한 비용 및 사용량 목표를 모두 이행합니다. 목표는 조직에 비용 및 사용량에 대한 방향을 제공하고, 타겟은 워크로드에 대한 측정 가능한 결과를 제공합니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

조직의 비용과 사용량에 대한 목표와 타겟을 개발합니다. 목표는 예상 결과에 대한 지침과 방향을 조직에 제공합니다. 타겟은 달성해야 할 구체적이고 측정 가능한 결과를 제공합니다. 예를 들어 목표는 비용을 조금(비선형) 늘리면서 플랫폼 사용량을 크게 늘리는 것입니다. 타겟은 플랫폼 사용량을 20% 늘리고 비용 증가를 5% 미만으로 유지하는 것입니다. 워크로드 효율성을 6개월마다 개선하는 것은 일반적인 목표의 또 다른 예입니다. 여기에 수반되는 타겟은 워크로드의 결과당 비용을 6개월마다 5% 줄이는 것이 될 수 있습니다.

클라우드 워크로드의 일반적인 목표는 워크로드 효율성을 높이고 시간이 지남에 따라 워크로드의 비즈니스 결과당 비용을 줄이는 것입니다. 모든 워크로드에 대해 이 목표를 구현하고 6\$112개월마다 효율성 5% 증가와 같은 목표를 설정하는 것이 좋습니다. 클라우드에서는 비용 최적화 기능의 구축과 새로운 서비스 및 서비스 기능의 릴리스를 통해 이러한 목표를 달성할 수 있습니다.

**구현 단계**
+  **예상 사용량 수준 정의: **먼저 사용량 수준에 초점을 맞추십시오. 애플리케이션 소유자, 마케팅 및 더 큰 비즈니스 팀과 협력하여 워크로드의 예상 사용량 수준을 파악합니다. 시간 경과에 따라 고객 수요는 어떻게 바뀔 것인지, 계절에 따른 증가나 마케팅 캠페인으로 인한 변화가 있을지도 알아봅니다. 
+ ** 워크로드 리소싱 및 비용 정의: **사용량 수준을 정의한 후 이러한 사용량 수준을 충족하는 데 필요한 워크로드 리소스의 변경 사항을 수량화합니다. 워크로드 구성 요소의 리소스 크기 또는 수를 늘리거나, 데이터 전송을 늘리거나, 워크로드 구성 요소를 특정 수준의 다른 서비스로 변경해야 할 수 있습니다. 이러한 각 주요 지점에서 비용은 어떻게 될 것이며, 사용량에 변화가 있을 때 비용은 어떻게 바뀔지 지정합니다. 
+  **비즈니스 목표 정의: **예상 사용량 및 비용 변화의 결과를 예상되는 기술 변화나 실행 중인 모든 프로그램과 결합하고 워크로드에 대한 목표를 개발합니다. 목표가 사용량, 비용 및 이 둘의 관계를 충족해야 합니다. 사용량 변화 없이 비용 변화만 예상되는 경우 훈련 및 교육 등의 기능 구축과 같은 조직 프로그램이 있는지 확인합니다. 
+  **타겟 정의: **정의된 각 목표에 대해 측정 가능한 타겟을 지정합니다. 워크로드의 효율성을 높이는 것이 목표라면 타겟은 소비한 달러당 비즈니스 성과의 개선량과 제공 시점을 수량화합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [직무 역할에 대한 AWS 관리형 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 
+  [AWS 다중 계정 결제 전략](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [IAM 정책을 사용하여 AWS 리전에 대한 액세스 제어](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 

# COST02-BP03 계정 구조 구현
<a name="cost_govern_usage_account_structure"></a>

 조직에 적합한 계정 구조를 구현합니다. 이를 통해 조직 전체에서 비용을 쉽게 할당하고 관리할 수 있습니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

AWS에는 관리 계정(상위, 이전의 지급 계정)과 멤버 계정(하위, 이전의 연결된 계정)이라고 하는 일대다의 상위 및 하위 계정 구조가 존재합니다. 모범 사례는 조직의 규모나 사용량에 관계없이 하나의 멤버 계정이 포함된 하나 이상의 관리 계정을 보유하는 것입니다. 모든 워크로드 리소스는 멤버 계정 내에만 존재해야 합니다.

필요한 AWS 계정 수는 경우에 따라 다릅니다. 현재 및 향후의 운영 모델과 비용 모델을 평가하여 AWS 계정 구조가 조직의 목표를 반영하는지 확인해야 합니다. 일부 회사에서는 비즈니스 이유로 다음과 같은 여러 AWS 계정을 생성합니다.
+ 조직 단위, 비용 센터 또는 특정 워크로드 간에 관리 및/또는 재무 및 결제 작업을 분리해야 하는 경우
+ 특정 워크로드별로 AWS 서비스 한도가 설정되어 있는 경우
+ 워크로드와 리소스 간에 격리 및 분리에 대한 요구 사항이 있는 경우

다음 내부에서 [AWS Organizations](https://aws.amazon.com/organizations/), [통합 결제](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) 를 사용하면 하나 이상의 멤버 계정과 관리 계정 간의 구조가 생성됩니다. 멤버 계정을 사용하면 비용과 사용량을 그룹으로 분리하고 구별할 수 있습니다. 각 조직 단위(재무, 마케팅, 영업 등) 또는 각 환경 수명 주기(개발, 테스트, 프로덕션 등) 또는 각 워크로드(워크로드 a, b, c)용으로 별도의 멤버 계정을 생성한 다음 통합 결제를 사용해 이러한 연결 계정을 집계하는 방식이 흔히 사용됩니다.

통합 결제에서는 여러 멤버 AWS 계정의 결제를 하나의 관리 계정에 통합할 수 있으며, 각 연결 계정의 활동은 계속 확인할 수 있습니다. 관리 계정에 비용 및 사용량이 집계되므로 서비스 대량 구매 할인율을 극대화하고 약정 할인(절감형 플랜 및 예약 인스턴스)을 최대한 활용하여 가장 높은 할인을 받을 수 있습니다.

[AWS Control Tower](https://aws.amazon.com/controltower/) 를 사용하면 여러 AWS 계정을 빠르게 설정하고 구성하여 조직의 요구 사항에 부합하는 거버넌스를 시행할 수 있습니다.

**구현 단계**
+  **분리 요구 사항 정의: **분리에 대한 요구 사항은 보안, 안정성, 재무 구조와 같은 여러 요인을 결합한 것입니다. 각 요인을 순서대로 살펴보고 워크로드 또는 워크로드 환경이 다른 워크로드와 분리되어야 하는지 여부를 지정합니다. 보안을 통해 액세스 및 데이터 요구 사항을 준수할 수 있습니다. 안정성은 한도를 관리하여 환경과 워크로드가 다른 요인에 영향을 미치지 않도록 합니다. 재무 구조는 엄격한 재무 분리 및 회계 책임을 보장합니다. 분리의 일반적인 예로는 별도의 계정에서 실행 중인 프로덕션 및 테스트 워크로드 또는 송장 및 결제 데이터를 타사 조직에 제공하기 위한 별도의 계정을 사용이 있습니다. 
+  **그룹화 요구 사항 정의:** 그룹화 요구 사항은 분리 요구 사항에 우선하지 않지만 관리를 지원하는 데 사용됩니다. 분리할 필요가 없는 유사한 환경 또는 워크로드를 함께 그룹화합니다. 예를 들어 하나 이상의 워크로드에 속하는 여러 테스트 또는 개발 환경을 함께 그룹화합니다. 
+  **계정 구조 정의: **이러한 분리와 그룹화를 사용하여 각 그룹에 대한 계정을 지정하고 분리 요구 사항이 유지되도록 합니다. 이러한 계정은 멤버 또는 연결된 계정입니다. 이러한 멤버 계정을 하나의 관리 또는 지급인 계정으로 그룹화하면 사용량이 결합되어 모든 계정에서 더 큰 대량 구매 할인을 받을 수 있고 모든 계정에 대해 단일 청구서가 제공됩니다. 결제 데이터를 분리하고 각 멤버 계정에 결제 데이터의 개별 보기를 제공할 수 있습니다. 멤버 계정의 사용 내역 또는 결제 데이터가 다른 계정에 표시되지 않아야 하거나 AWS와 별도의 청구서가 필요한 경우 여러 관리 또는 지급인 계정을 정의합니다. 이 경우 멤버 계정마다 고유의 관리 또는 지급인 계정이 있습니다. 리소스는 항상 멤버 또는 연결 계정에 배치되어야 합니다. 관리 또는 지급인 계정은 관리에만 사용해야 합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [직무 역할에 대한 AWS 관리형 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 
+  [AWS 다중 계정 결제 전략](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [IAM 정책을 사용하여 AWS 리전에 대한 액세스 제어](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+  [AWS Control Tower](https://aws.amazon.com/controltower/) 
+  [AWS Organizations](https://aws.amazon.com/organizations/) 
+  [통합 결제](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) 

 **관련 예시:** 
+  [CUR 분리 및 액세스 공유](https://wellarchitectedlabs.com/Cost/Cost_and_Usage_Analysis/300_Splitting_Sharing_CUR_Access/README.html) 

# COST02-BP04 그룹 및 역할 만들기
<a name="cost_govern_usage_groups_roles"></a>

 정책에 따라 그룹과 역할을 만들고 각 그룹에서 인스턴스와 리소스를 생성, 수정 또는 폐기할 수 있는 사용자를 제어합니다. 예를 들어 개발, 테스트 및 프로덕션 그룹을 만듭니다. 이는 AWS 서비스와 타사 솔루션에 적용됩니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음 

## 구현 가이드
<a name="implementation-guidance"></a>

정책을 개발한 후에는 조직 내부 사용자의 논리적 그룹 및 역할을 생성하여 권한을 할당하고 사용량을 제어할 수 있습니다. 개괄적인 수준에서 사람을 그룹화하는 것으로 시작합니다. 일반적으로 조직 단위 및 직무 역할(예: IT 부서의 시스템 관리자 또는 재무 관리자)이 여기에 해당합니다. 그룹에는 유사한 작업을 수행하고 유사한 접근 권한이 필요한 사람이 포함됩니다. 역할은 그룹이 수행해야 할 작업을 정의합니다. 예를 들어 IT의 시스템 관리자는 모든 리소스를 생성할 수 있는 접근 권한이 필요하지만 분석 팀원은 분석 리소스만 생성하면 됩니다.

**구현 단계**
+ ** 그룹 만들기: **조직 정책에 정의된 사용자 그룹을 사용하여 필요한 경우 해당 그룹을 만듭니다. 사용자, 그룹 및 인증에 대한 모범 사례는 보안 원칙을 참조하십시오. 
+ ** 역할 및 정책 만들기: **조직 정책에 정의된 작업을 사용하여 필요한 역할과 액세스 정책을 생성합니다. 역할 및 정책에 대한 모범 사례는 보안 원칙을 참조하십시오. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [직무에 관한 AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 
+  [AWS 다중 계정 결제 전략](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [IAM 정책을 사용하여 AWS 리전에 대한 액세스 제어](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+  [Well-Architected 보안 원칙](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) 

 **관련 예시:** 
+  [Well-Architected 실습: 기본 자격 증명 및 액세스](https://wellarchitectedlabs.com/Security/100_Basic_Identity_and_Access_Management_User_Group_Role/README.html) 

# COST02-BP05 비용 제어 기능 구현
<a name="cost_govern_usage_controls"></a>

 조직 정책과 정의된 그룹 및 역할을 기준으로 제어 기능을 만듭니다. 이렇게 하면 조직 요구 사항에 따라 정의된 비용만 발생합니다. 예를 들어 AWS Identity and Access Management(IAM) 정책을 사용하여 리전 또는 리소스 유형 액세스를 제어할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음 

## 구현 가이드
<a name="implementation-guidance"></a>

비용 제어를 구현하기 위한 일반적인 첫 번째 단계는 비용 또는 사용량 이벤트가 조직 정책 범위를 벗어날 때 알림을 설정하는 것입니다. 이렇게 하면 워크로드 또는 새로운 활동에 대한 제한 또는 부정적인 영향 없이 신속하게 조치를 취하고 교정 조치가 필요한지 여부를 확인할 수 있습니다. 워크로드 및 환경 제한을 파악한 후에는 거버넌스를 시행할 수 있습니다. AWS에서 알림은 AWS 비용, 사용량 및 약정 할인(절감형 플랜 및 예약 인스턴스)에 대한 월 예산을 정의할 수 있는 AWS Budgets를 통해 시행됩니다. 집계 비용 수준(예: 모든 비용)에서 예산을 생성하거나 연결 계정, 서비스, 태그 또는 가용 영역과 같은 특정 차원만 포함하는 보다 세분화된 수준에서 예산을 생성할 수 있습니다.

두 번째 단계로, AWS에서 [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM) 및 [AWS Organizations SCP(서비스 제어 정책)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)를 사용하여 거버넌스 정책을 적용할 수 있습니다. IAM은 AWS 서비스 및 리소스에 대한 접근을 안전하게 관리할 수 있는 기능을 제공합니다. IAM을 사용하면 AWS 리소스를 생성 및 관리할 수 있는 사용자, 생성할 수 있는 리소스 유형 및 리소스 생성 위치를 제어할 수 있습니다. 이렇게 하면 필요하지 않은 리소스의 생성이 최소화됩니다. 이전에 생성한 역할 및 그룹을 사용하고 [IAM 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) 을 할당하여 올바른 사용을 시행할 수 있습니다. SCP를 사용하면 조직 내 모든 계정에 대해 사용 가능한 최대 권한을 중앙에서 제어하여 계정이 접근 제어 지침을 준수하는지 확인할 수 있습니다. SCP는 모든 기능이 활성화된 조직에서만 사용할 수 있으며, 기본적으로 멤버 계정에 대한 작업을 거부하거나 허용하도록 SCP를 구성할 수 있습니다. 접근 관리 구현에 대한 자세한 내용은 [Well-Architected 보안 원칙 백서](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) 를 참조하십시오.

Service Quotas 관리를 통해 거버넌스를 구현할 수도 있습니다. 오버헤드를 최소화하는 방식으로 서비스 할당량을 설정하고 정확하게 유지 관리하면 조직의 요구 사항에 포함되지 않는 리소스 생성을 최소화할 수 있습니다. 이렇게 하려면 요구 사항 변경 속도와 진행 중인 프로젝트(리소스 생성 및 폐기)를 파악하고 할당량 변경을 구현할 수 있는 속도를 고려해야 합니다. [Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 를 사용하여 필요에 따라 할당량을 늘릴 수 있습니다.

**구현 단계**
+ ** 지출에 대한 알림 구현:** 정의된 조직 정책으로 AWS 예산을 생성하여 지출이 정책을 벗어날 때 알림을 제공합니다. 전체 계정 지출에 대해 알리는 비용 예산을 계정당 하나씩 여러 개 구성합니다. 그런 다음 각 계정 내에서 해당 계정 내의 더 작은 단위에 대한 추가 비용 예산을 구성합니다. 이러한 단위는 계정 구조에 따라 다릅니다. 일반적인 예로 AWS 리전, 워크로드(태그 사용) 또는 AWS 서비스가 있습니다. 개인의 이메일 계정이 아닌 이메일 배포 목록을 알림에 대한 수신자로 구성해야 합니다. 금액을 초과할 때에 대한 실제 예산을 구성하거나 예상 예산을 사용하여 예상 사용량에 대해 알릴 수 있습니다. 
+ ** 사용량에 대한 제어 구현: **정의된 조직 정책으로 IAM 정책 및 역할을 만들어서 사용자가 수행할 수 있는 작업과 수행할 수 없는 작업을 지정합니다. AWS 정책에 여러 조직 정책이 포함될 수 있습니다. 정책을 정의한 것과 동일한 방식으로 광범위하게 시작한 다음 각 단계에서 보다 세분화된 제어를 적용합니다. 서비스 한도도 효과적인 사용량 제어 방식입니다. 모든 계정에 올바른 서비스 한도를 설정합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [직무에 관한 AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 
+  [AWS 다중 계정 결제 전략](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [IAM 정책을 사용하여 AWS 리전에 대한 액세스 제어](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 

 **관련 예시:** 
+  [Well-Architected 실습: 비용 및 사용 거버넌스](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) 
+  [Well-Architected 실습: 비용 및 사용 거버넌스](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_2_Cost_and_Usage_Governance/README.html) 

# COST02-BP06 프로젝트 수명 주기 추적
<a name="cost_govern_usage_track_lifecycle"></a>

 프로젝트, 팀 및 환경의 수명 주기를 추적, 측정 및 감사하여 불필요한 리소스 사용 및 이에 따른 비용 지출을 막으십시오. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음 

## 구현 가이드
<a name="implementation-guidance"></a>

워크로드의 전체 수명 주기를 추적해야 합니다. 수명 주기를 추적하면 워크로드 또는 워크로드 구성 요소가 더 이상 필요하지 않을 때 이를 폐기하거나 수정할 수 있습니다. 이 기능은 새로운 서비스 또는 기능을 릴리스할 때 특히 유용합니다. 사용 중인 것처럼 보일 수 있는 기존 워크로드 및 구성 요소를 폐기하여 고객을 새 서비스로 리디렉션해야 합니다. 워크로드의 이전 단계를 확인하십시오. 워크로드가 프로덕션 단계로 전환된 후에는 이전 환경을 폐기하거나 다시 필요할 때까지 용량을 크게 줄일 수 있습니다.

AWS는 엔터티 수명 주기 추적에 사용할 수 있는 다양한 관리 및 거버넌스 서비스를 제공합니다. 여러분은 [AWS Config](https://aws.amazon.com/config/) 또는 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 를 사용하여 AWS 리소스 및 구성에 대한 상세한 인벤토리를 제공할 수 있습니다. 추적 기능을 기존 프로젝트 또는 자산 관리 시스템에 통합하여 조직 내의 진행 중인 프로젝트와 제품을 추적하는 것이 좋습니다. AWS에서 제공하는 다양한 이벤트 및 지표 집합과 현재 시스템을 통합하면 중요한 수명 주기 이벤트 뷰(view)를 작성하고 리소스를 사전에 관리하여 불필요한 비용을 줄일 수 있습니다.

엔터티 수명 주기 추적 구현에 대한 자세한 내용은 [Well-Architected 운영 우수성 원칙 백서](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html) 를 참조하십시오.

**구현 단계**
+ ** 워크로드 검토 수행: **조직 정책에 정의된 대로 기존 프로젝트를 감사합니다. 감사에 드는 노력은 조직의 대략적인 위험, 가치 또는 비용에 비례해야 합니다. 감사에 포함할 주요 영역은 조직의 인시던트 또는 가동 중단 위험, 가치 또는 조직에 대한 기여도(수익 또는 브랜드 평판으로 측정), 워크로드 비용(총 리소스 비용 및 운영 비용으로 측정), 워크로드 사용량(단위 시간당 조직 성과 수로 측정)입니다. 수명 주기 동안 이러한 영역이 변경되면 전체 또는 부분 폐기와 같은 워크로드 조정이 필요합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Config](https://aws.amazon.com/config/) 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [직무에 관한 AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 
+  [AWS 다중 계정 결제 전략](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [IAM 정책을 사용하여 AWS 리전에 대한 액세스 제어](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 

# COST 3  사용량과 비용을 어떻게 모니터링합니까?
<a name="w2aac19c13b7b7"></a>

비용을 모니터링하고 적절하게 할당하기 위한 정책 및 절차를 구성합니다. 이렇게 하면 이 워크로드의 비용 효율성을 측정하고 개선할 수 있습니다.

**Topics**
+ [COST03-BP01 세부 정보 소스 구성](cost_monitor_usage_detailed_source.md)
+ [COST03-BP02 비용 귀속 범주 식별](cost_monitor_usage_define_attribution.md)
+ [COST03-BP03 조직 지표 설정](cost_monitor_usage_define_kpi.md)
+ [COST03-BP04 결제 및 비용 관리 도구 구성](cost_monitor_usage_config_tools.md)
+ [COST03-BP05 비용 및 사용량에 조직 정보 추가](cost_monitor_usage_org_information.md)
+ [COST03-BP06 워크로드 지표를 기준으로 비용 할당](cost_monitor_usage_allocate_outcome.md)

# COST03-BP01 세부 정보 소스 구성
<a name="cost_monitor_usage_detailed_source"></a>

 AWS Cost and Usage Report와 Cost Explorer에서 시간 단위의 세분 수준을 구성하여 자세한 비용 및 사용량 정보를 제공합니다. 전송된 모든 비즈니스 성과에 대한 로그 항목을 생성하도록 워크로드를 구성합니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

AWS Cost Explorer에서 시간 단위 세분화를 활성화하고 [AWS Cost and Usage Report(CUR)를 생성합니다](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/). 이러한 데이터 원본은 전체 조직의 비용 및 사용량을 가장 정확하게 보여줍니다. CUR은 모든 청구 가능한 AWS 서비스에 대해 일 또는 시간 단위 사용량 세분화, 요금, 비용 및 사용량 속성을 제공합니다. 태그 지정, 위치, 리소스 속성 및 계정 ID를 포함하여 가능한 모든 차원을 CUR에서 사용할 수 있습니다.

다음과 같은 사용자 지정을 사용하여 CUR을 구성합니다.
+ 리소스 ID 포함
+ CUR 자동 새로 고침
+ 시간 단위 세분화
+ **버전 관리:** 기존 보고서 덮어쓰기
+ **데이터 통합:** Amazon Athena(Parquet 형식 및 압축)

참고로, [AWS Glue](https://aws.amazon.com/glue/) 를 사용하여 분석에 사용할 데이터를 준비하고 [Amazon Athena](https://aws.amazon.com/athena/) 를 사용하여 데이터 분석을 수행하며 SQL을 사용하여 데이터를 쿼리합니다. 또한 [Amazon Quick](https://aws.amazon.com/quicksight/) 를 사용하여 사용자 지정된 복합적인 시각화를 작성하고 조직 전체에 배포할 수도 있습니다.

**구현 단계**
+ ** 비용 및 사용 보고서 구성: **결제 콘솔을 사용하여 하나 이상의 비용 및 사용 보고서를 구성합니다. 모든 식별자 및 리소스 ID를 포함하는 시간 단위의 세분 수준으로 보고서를 구성합니다. 다른 세부 수준의 다른 보고서를 생성하여 더 개략적인 요약 정보를 제공할 수도 있습니다. 
+ ** Cost Explorer에서 시간 단위의 세분 수준 구성: **결제 콘솔을 사용하여 시간 단위 및 리소스 수준 데이터를 사용합니다. 
**참고**  
이 기능 사용에 따른 비용이 발생합니다. 자세한 내용은 요금을 참조하십시오. 
+  **애플리케이션 로깅 구성:** 애플리케이션에서 제공하는 각 비즈니스 성과를 로깅하여 추적하고 측정할 수 있는지 확인합니다. 비용 및 사용량 데이터와 일치하도록 이 데이터의 세부 수준이 시간 단위 이상인지 확인합니다. 로깅 및 모니터링에 대한 자세한 내용은 [AWS Well-Architected 운영 우수성 원칙](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html) 을 참조하십시오. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS 계정 설정](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html) 
+  [AWS Cost and Usage Report(CUR)](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/) 
+  [AWS Glue](https://aws.amazon.com/glue/) 
+  [Amazon Quick](https://aws.amazon.com/quicksight/) 
+  [AWS 비용 관리 요금](https://aws.amazon.com/aws-cost-management/pricing/) 
+  [AWS 리소스 태그 지정](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [AWS Budgets를 통해 비용 분석](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Cost Explorer를 사용한 비용 분석](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [AWS Cost and Usage Report 관리](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 
+  [AWS Well-Architected 운영 우수성 원칙](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html) 

 **관련 예시:** 
+  [AWS 계정 설정](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html) 

# COST03-BP02 비용 귀속 범주 식별
<a name="cost_monitor_usage_define_attribution"></a>

 조직 내에서 비용을 할당하는 데 사용할 수 있는 조직 범주를 파악합니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

재무 팀 및 기타 이해관계자와 협력하여 조직 내의 비용 할당 방식에 관한 요구 사항을 파악합니다. 워크로드 비용은 개발, 테스트, 프로덕션 및 폐기를 포함한 전체 수명 주기에 걸쳐 할당되어야 합니다. 조직에서 학습, 직원 개발 및 아이디어 창출에 대해 발생한 비용의 귀속 방법을 파악합니다. 그러면 이 목적으로 사용되는 계정을 일반적인 IT 비용 예산 대신 교육 및 개발 예산에 올바르게 할당할 수 있습니다.

**구현 단계**
+  **조직 범주 정의:** 이해 관계자를 만나 조직의 구조 및 요구 사항을 반영하는 범주를 정의합니다. 이들은 사업부, 예산, 비용 센터 또는 부서와 같은 기존 재무 범주의 구조에 직접 매핑됩니다. 교육과 같이 클라우드가 비즈니스에 제공하는 성과를 살펴보십시오. 이들은 조직 범주이기도 합니다. 한 리소스에 여러 범주를 할당할 수 있으며 리소스는 서로 다른 여러 범주에 있을 수 있으므로 필요한 만큼 범주를 정의합니다. 
+  **역할 범주 정의:** 이해 관계자를 만나 비즈니스 내에서 자신의 역할을 반영하는 범주를 정의합니다. 역할 범주는 워크로드 또는 애플리케이션 이름과 프로덕션, 테스트, 개발 등의 환경 유형일 수 있습니다. 한 리소스에 여러 범주를 할당할 수 있으며 리소스는 서로 다른 여러 범주에 있을 수 있으므로 필요한 만큼 범주를 정의합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS 리소스 태그 지정](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [AWS Budgets를 통해 비용 분석](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Cost Explorer를 사용한 비용 분석](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [AWS Cost & Usage Report 관리](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

# COST03-BP03 조직 지표 설정
<a name="cost_monitor_usage_define_kpi"></a>

 이 워크로드에 필요한 조직 지표를 설정합니다. 워크로드 지표의 예로는 생성된 고객 보고서 또는 고객에게 제공된 웹 페이지가 있습니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

비즈니스 성공을 기준으로 워크로드의 결과를 측정하는 방법을 파악합니다. 일반적으로 각 워크로드에는 성능을 나타내는 소규모의 주요 결과 세트가 있습니다. 구성 요소가 많은 복잡한 워크로드가 있는 경우 목록의 우선 순위를 지정하거나 각 구성 요소에 대한 지표를 정의하고 추적할 수 있습니다. 팀과 협력하여 사용할 지표를 파악하십시오. 이 단위는 워크로드의 효율성 또는 각 비즈니스 결과의 비용을 파악하는 데 사용됩니다.

**구현 단계**
+  **워크로드 성과 정의: **비즈니스 이해 관계자를 만나 워크로드에 대한 성과를 정의합니다. 이는 고객 사용량의 기본 척도이며 기술 지표가 아니라 비즈니스 지표여야 합니다. 워크로드당 거시 지표 수가 적어야 합니다(5개 미만). 워크로드가 서로 다른 사용 사례에 대해 여러 성과를 생성하는 경우 이들을 단일 지표로 그룹화합니다. 
+  **워크로드 구성 요소 성과 정의: **크고 복잡한 워크로드가 있거나 잘 정의된 입력 및 출력을 사용하여 워크로드를 마이크로서비스 등의 구성 요소로 쉽게 나눌 수 있는 경우 각 구성 요소에 대한 지표를 정의합니다. 노력은 구성 요소의 가치와 비용을 반영해야 합니다. 가장 큰 구성 요소로 시작하여 더 작은 구성 요소로 진행합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS 리소스 태그 지정](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [AWS Budgets를 통해 비용 분석](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Cost Explorer를 사용한 비용 분석](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [AWS 비용 및 사용 보고서 관리](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

# COST03-BP04 결제 및 비용 관리 도구 구성
<a name="cost_monitor_usage_config_tools"></a>

 조직 정책에 맞게 AWS Cost Explorer와 AWS Budgets를 구성합니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

사용량을 수정하고 비용을 조정하려면 조직의 각 사용자가 비용 및 사용량 정보에 접근할 수 있어야 합니다. 클라우드를 사용하는 모든 워크로드 및 팀을 위해 다음과 같은 도구를 구성하는 것이 좋습니다.
+ **보고서:** 모든 비용 및 사용량 정보를 요약합니다.
+ **알림:** 비용 또는 사용량이 정의된 제한을 벗어날 때 알림을 제공합니다.
+ **현재 상태: **현재 비용 및 사용량 수준을 보여주는 대시보드를 구성합니다. 대시보드는 작업 환경 내의 가시성이 높은 위치에서 사용할 수 있어야 합니다(작업 대시보드와 유사함).
+ **트렌드: **필요한 기간의 비용 및 사용량 변동을 보여주는 기능을 필요한 세부 수준으로 제공합니다.
+ **예측: **향후 예상 비용을 보여주는 기능을 제공합니다.
+ **추적: **구성된 목표 또는 타겟을 기준으로 현재 비용 및 사용량을 보여줍니다.
+ **분석: **가능한 모든 차원에서 시간 단위 세부 수준까지 사용자 지정 심층 분석을 수행할 수 있는 기능을 팀원에게 제공합니다.

AWS 기본 도구(예: [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/), [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 및 [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway) )를 [Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway) 와 함께 사용하여 이 기능을 제공할 수 있습니다. 서드파티 도구를 사용할 수도 있지만, 해당하는 서드파티 도구의 비용이 조직에 가치를 제공하는지 확인해야 합니다.

**구현 단계**
+ ** 비용 최적화 그룹 생성: **계정을 구성하고 필요한 비용 및 사용 보고서에 액세스할 수 있는 그룹을 생성합니다. 이 그룹에는 애플리케이션을 소유하거나 관리하는 모든 팀의 담당자가 포함되어야 합니다. 그래야 모든 팀에서 비용 및 사용량 정보에 액세스할 수 있습니다. 
+ ** AWS Budgets 구성:** 워크로드의 모든 계정에서 AWS Budgets를 구성합니다. 태그를 사용하여 전체 계정 지출에 대한 예산과 워크로드에 대한 예산을 설정합니다. 
+ ** AWS Cost Explorer 구성: **워크로드와 계정에 대해 AWS Cost Explorer를 구성합니다. 전체 지출과 워크로드의 주요 사용량 지표를 추적하는 워크로드에 대한 대시보드를 생성합니다. 
+ ** 고급 도구 구성: **조직에 대한 추가 세부 정보와 세부 수준을 제공하는 사용자 지정 도구를 생성할 수도 있습니다. 다음을 사용하여 고급 분석 기능을 구현할 수 있습니다. [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway)및 다음을 사용한 대시보드 [Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway). 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS 리소스 태그 지정](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [AWS Budgets를 통해 비용 분석](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Cost Explorer를 사용한 비용 분석](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [AWS 비용 및 사용 보고서 관리](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

 **관련 예시:** 
+  [Well-Architected 실습 - AWS 계정 설정](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html/) 
+  [Well-Architected 실습: 결제 시각화](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/README.html) 
+  [Well-Architected 실습: 비용 및 사용 거버넌스](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) 
+  [Well-Architected 실습: 비용 및 사용량 분석](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_4_Cost_and_Usage_Analysis/README.html) 
+  [Well-Architected 실습: 비용 및 사용량 시각화](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 

# COST03-BP05 비용 및 사용량에 조직 정보 추가
<a name="cost_monitor_usage_org_information"></a>

 조직, 워크로드 속성 및 비용 할당 범주를 기준으로 하는 태그 지정 스키마를 정의합니다. 모든 리소스에 태그를 지정합니다. Cost Categories를 사용하여 조직 속성에 따라 비용과 사용량을 그룹화합니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 낮음 

## 구현 가이드
<a name="implementation-guidance"></a>

AWS에서는 [태그를 지정하여](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 조직 정보를 리소스에 추가할 수 있습니다. 이러한 조직 정보는 다시 비용 및 사용량 정보에 추가됩니다. 태그는 키–값 페어입니다. 키는 정의되며 조직 전체에서 고유해야 하고 값은 리소스 그룹에 고유해야 합니다. 예를 들어 키가 Environment이고 값은 Production인 키-값 페어가 있을 수 있습니다. 프로덕션 환경의 모든 리소스에는 이 키–값 페어가 있습니다. 태그 지정을 통해 의미 있고, 관련성 있는 조직 정보를 사용하여 비용을 분류하고 추적할 수 있습니다. 조직 범주(예: 원가 중심점, 애플리케이션 이름, 프로젝트 또는 소유자)를 나타내는 태그를 적용하고 워크로드 및 워크로드의 특성(예: 테스트 또는 프로덕션)을 식별하여 조직 전체의 비용 및 사용량을 해당하는 개체에 귀속할 수 있습니다.

Amazon Elastic Compute Cloud 인스턴스 또는 Amazon Simple Storage Service 버킷과 같은 AWS 리소스에 태그를 적용하고 활성화하면 AWS가 비용 및 사용 보고서에 이 정보를 추가합니다. 태그가 지정된 리소스와 지정되지 않은 리소스에 대해 보고서를 실행하고 분석을 수행하면 내부 비용 관리 정책에 대한 규정 준수를 개선하고 정확한 귀속을 보장할 수 있습니다.

조직 전체 계정에 적용되는 AWS 태그 지정 표준을 생성하고 구현하면 통일성 있는 일관된 방식으로 AWS 환경을 관리하고 제어할 수 있습니다. 사용 [태그 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) 을 AWS Organizations에서 사용하여 AWS Organizations의 계정에 포함된 AWS 리소스에 태그를 사용하는 방법에 대한 규칙을 정의할 수 있습니다. 태그 정책을 사용하면 AWS 리소스 태그 지정에 대한 표준화된 접근 방식을 쉽게 도입할 수 있습니다.

[AWS Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) 를 사용하면 여러 리소스의 태그를 추가, 삭제 및 관리할 수 있습니다.

[AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 를 사용하면 리소스에 태그를 지정할 필요 없이 조직의 의미를 비용에 지정할 수 있습니다. 비용 및 사용량 정보를 고유한 내부 조직 구조에 매핑할 수도 있습니다. 계정 및 태그와 같은 결제 차원을 사용하여 비용을 매핑하고 분류하는 범주 규칙을 정의하면 태그 지정에 더해 또 다른 수준의 관리 기능을 제공할 수 있습니다. 특정 계정과 태그를 여러 프로젝트에 매핑할 수도 있습니다.

**구현 단계**
+  **태그 지정 스키마 정의:** 비즈니스 전반의 모든 이해 관계자를 모아 스키마를 정의합니다. 여기에는 대개 기술직, 재무직 및 경영진이 포함됩니다. 모든 리소스가 보유해야 하는 태그 목록과 리소스가 보유해야 하는 태그 목록을 정의합니다. 조직 전체에 걸쳐 태그 이름과 값이 일치하는지 확인합니다. 
+ ** 리소스 태그 지정: **정의된 비용 속성 범주를 사용하여 범주에 따라 워크로드의 모든 리소스에 태그를 지정합니다. CLI, Tag Editor 또는 Systems Manager와 같은 도구를 사용하여 효율성을 높입니다. 
+  **Cost Categories 만들기: **태그 지정을 구현하지 않고 Cost Categories를 만들 수 있습니다. Cost Categories는 기존 비용 및 사용량 규모를 사용합니다. 스키마에서 범주 규칙을 생성하여 Cost Categories에 구현합니다. 
+  **태그 지정 자동화:** 모든 리소스에서 많은 태그 지정을 유지하려면 리소스가 생성될 때 자동으로 태그가 지정되도록 태그 지정을 자동화합니다. 서비스 내의 기능이나 AWS CloudFormation과 같은 서비스를 사용하여 리소스를 생성할 때 태그가 지정되도록 합니다. 또한 워크로드를 주기적으로 스캔하고 태그가 지정되지 않은 리소스를 제거하는 사용자 지정 마이크로서비스를 생성할 수 있습니다. 이는 테스트 및 개발 환경에서 매우 유용합니다. 
+ ** 태그 지정 모니터링 및 보고: **조직 전체에서 많은 태그 지정을 유지하려면 워크로드 전체의 태그를 보고하고 모니터링합니다. AWS Cost Explorer를 사용하여 태그가 지정되거나 태그가 지정되지 않은 리소스의 비용을 보거나 Tag Editor와 같은 서비스를 사용할 수 있습니다. 태그가 지정되지 않은 리소스의 수를 정기적으로 검토하고 원하는 태그 지정 수준에 도달할 때까지 태그를 추가하는 작업을 수행합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS CloudFormation 리소스 태그](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html) 
+  [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 
+  [AWS 리소스 태그 지정](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [Amazon EC2 및 Amazon EBS는 생성 시 리소스의 태그 지정을 지원함](https://aws.amazon.com/about-aws/whats-new/2017/03/amazon-ec2-and-amazon-ebs-add-support-for-tagging-resources-upon-creation-and-additonal-resource-level-permissions/) 
+  [AWS Budgets를 통해 비용 분석](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Cost Explorer를 사용한 비용 분석](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [AWS 비용 및 사용 보고서 관리](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

# COST03-BP06 워크로드 지표를 기준으로 비용 할당
<a name="cost_monitor_usage_allocate_outcome"></a>

 지표 또는 비즈니스 성과에 따라 워크로드의 비용을 할당하여 워크로드 비용 효율성을 측정합니다. 인사이트와 차지백 기능을 제공할 수 있는 [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway)와 함께 AWS 비용 및 사용량 보고서를 분석하는 프로세스를 구현합니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 낮음 

## 구현 가이드
<a name="implementation-guidance"></a>

비용 최적화는 최저 가격으로 비즈니스 성과를 제공하는 것입니다. 이를 위해서는 워크로드 지표(워크로드 효율성으로 측정됨)를 기준으로 워크로드 비용을 할당해야 합니다. 로그 파일 또는 기타 애플리케이션 모니터링을 통해 정의된 워크로드 지표를 모니터링하십시오. 이 데이터를 워크로드 비용과 결합합니다. 워크로드 비용은 특정 태그 값 또는 계정 ID에 연결된 비용을 조회하여 확인할 수 있습니다. 이 분석은 시간 단위 수준으로 수행하는 것이 좋습니다. 정적 비용 구성 요소(예: 상시 실행되는 백엔드 데이터베이스)가 일부 있고 요청 비율이 가변적인 경우(오전 9시부터 오후 5시까지 사용량이 많고 야간에는 요청 수가 적음)에는 효율성이 변경되는 것이 일반적입니다. 정적 비용과 가변 비용 간의 관계를 이해하면 최적화 활동에 집중하는 데 도움이 됩니다.

**구현 단계**
+ ** 워크로드 지표에 비용 할당: **정의된 지표와 구성된 태그 지정을 사용하여 워크로드 출력과 워크로드 비용을 결합하는 지표를 생성합니다. Amazon Athena 및 Quick와 같은 분석 서비스를 사용하여 전체 워크로드와 모든 구성 요소에 대한 효율성 대시보드를 생성합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS 리소스 태그 지정](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [AWS Budgets를 통해 비용 분석](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Cost Explorer를 사용한 비용 분석](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [AWS 비용 및 사용 보고서 관리](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

# COST 4  리소스를 어떻게 폐기합니까?
<a name="w2aac19c13b7b9"></a>

프로젝트 시작부터 마지막까지의 전체 과정에서 변경 제어 및 리소스 관리를 구현합니다. 그러면 사용되지 않은 리소스를 종료하여 낭비되는 리소스를 줄일 수 있습니다.

**Topics**
+ [COST04-BP01 수명 주기에 걸친 리소스 추적:](cost_decomissioning_resources_track.md)
+ [COST04-BP02 폐기 프로세스 구현](cost_decomissioning_resources_implement_process.md)
+ [COST04-BP03 리소스 폐기](cost_decomissioning_resources_decommission.md)
+ [COST04-BP04 리소스 자동 폐기](cost_decomissioning_resources_decomm_automated.md)

# COST04-BP01 수명 주기에 걸친 리소스 추적:
<a name="cost_decomissioning_resources_track"></a>

 : 수명 주기 동안 리소스 및 리소스와 시스템의 관련성을 추적하는 방법을 정의하고 구현합니다. 태그 지정 기능을 사용하여 리소스의 워크로드나 기능을 파악할 수 있습니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

더 이상 필요하지 않은 워크로드 리소스를 폐기합니다. 일반적으로 테스트에 사용되는 리소스가 그 예입니다. 테스트가 완료된 후에는 리소스를 제거해도 됩니다. 태그를 사용하여 리소스를 추적하고 해당 태그에 대한 보고서를 실행하면 폐기할 자산을 식별하는 데 도움이 됩니다. 태그를 사용하면 리소스에 기능별 레이블을 지정하거나 폐기할 수 있는 알려진 날짜를 지정하여 리소스를 효과적으로 추적할 수 있습니다. 그런 다음 이러한 태그에 대해 보고를 실행할 수 있습니다. 특징 태그 지정 값의 예로는 `feature-X 테스팅이` 있으며 워크로드 수명 주기의 측면에서 리소스의 목적을 식별하는 데 사용됩니다. 

**구현 단계**
+ ** 태그 지정 체계 구현: **리소스가 속한 워크로드를 식별하는 태그 지정 체계를 구현하여 워크로드 내의 모든 리소스에 태그가 적절히 지정되는지 확인합니다. 
+ ** 워크로드 처리량 또는 출력 모니터링을 구현합니다. **워크로드 처리량 모니터링 또는 경보를 구현하여 입력 요청 또는 출력 완료 시 트리거합니다. 워크로드 요청 또는 출력이 0으로 떨어질 때 즉, 워크로드 리소스가 더 이상 사용되지 않을 때 알림을 제공하도록 구성합니다. 워크로드가 정상 조건에서 주기적으로 0으로 떨어질 경우 시간 계수를 통합합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [AWS 리소스 태그 지정](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 

# COST04-BP02 폐기 프로세스 구현
<a name="cost_decomissioning_resources_implement_process"></a>

 분리된 리소스를 파악하고 폐기하는 프로세스를 구현합니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

조직 전체에서 미사용 리소스를 식별하고 제거하는 표준화된 프로세스를 구현합니다. 이 프로세스에서는 검색 수행 빈도와 리소스를 제거하여 모든 조직 요구 사항이 충족되는지 확인하는 프로세스를 정의해야 합니다.

**구현 단계**
+  **폐기 프로세스 생성 및 구현: **워크로드 개발자 및 소유자와 협력하여 워크로드와 해당 리소스에 대한 폐기 프로세스를 구축합니다. 이 프로세스에서는 워크로드가 사용 중이고 각 워크로드 리소스도 사용 중인지 확인하는 메서드를 다룹니다. 또한 이 프로세스에서는 리소스를 폐기하여 규제 요구 사항을 준수하면서 서비스에서 리소스를 제거하는 데 필요한 단계도 다루어야 합니다. 라이선스 또는 연결된 스토리지와 같은 관련 리소스도 다룹니다. 프로세스에서 워크로드 소유자에게 폐기 프로세스가 실행되었음을 알려야 합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 

# COST04-BP03 리소스 폐기
<a name="cost_decomissioning_resources_decommission"></a>

 정기적 감사 또는 사용량 변화와 같은 이벤트에 의해 트리거된 리소스를 폐기합니다. 폐기는 일반적으로 주기적으로 수행되며 수동 또는 자동입니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>

사용되지 않는 리소스를 검색하는 빈도 및 작업은 잠재적 절감을 고려하여 결정해야 합니다. 비용이 높은 계정은 비용이 낮은 계정보다 더 자주 분석되어야 합니다. 워크로드의 상태 변경(예: 제품 EOL 또는 교체)을 통해 검색 및 폐기 이벤트를 트리거할 수 있습니다. 검색 및 폐기 이벤트는 시장 상황의 변화나 제품 종료와 같은 외부 이벤트에 의해 트리거될 수도 있습니다.

**구현 단계**
+  **리소스 폐기: **폐기 프로세스를 사용하여 분리된 것으로 식별된 각 리소스를 폐기합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 

# COST04-BP04 리소스 자동 폐기
<a name="cost_decomissioning_resources_decomm_automated"></a>

 중요하지 않은 리소스, 필수가 아닌 리소스 또는 사용률이 낮은 리소스를 파악하고 폐기하는 과정에서 워크로드가 리소스 종료를 정상적으로 처리하도록 설계합니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음 

## 구현 가이드
<a name="implementation-guidance"></a>

자동화를 사용하여 폐기 프로세스와 관련된 비용을 줄이거나 제거합니다. 자동 폐기를 수행하도록 워크로드를 설계하면 수명 주기 동안 전체 워크로드 비용을 절감할 수 있습니다. 여러분은 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 을 사용하여 폐기 프로세스를 수행할 수 있습니다. 또한 [API 또는 SDK](https://aws.amazon.com/developer/tools/) 를 사용하여 워크로드 리소스를 자동으로 폐기하는 사용자 지정 코드를 구현할 수도 있습니다.

**구현 단계**
+ ** AWS Auto Scaling 구현: **지원되는 리소스의 경우 AWS Auto Scaling을 사용하여 리소스를 구성합니다. 
+ ** 인스턴스를 종료하도록 CloudWatch 구성:** CloudWatch 경보를 사용하여 인스턴스를 종료하도록 구성할 수 있습니다. 폐기 프로세스의 지표를 사용하여 Amazon Elastic Compute Cloud(Amazon EC2) 작업으로 경보를 구현합니다. 롤아웃하기 전에 비 프로덕션 환경에서 작업을 확인합니다. 
+  **워크로드 내에서 코드 구현:** AWS SDK 또는 AWS CLI를 사용하여 워크로드 리소스를 폐기할 수 있습니다. 애플리케이션 내에서 AWS와 통합되고 더 이상 사용되지 않는 리소스를 종료하거나 제거하는 코드를 구현합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [인스턴스를 중지, 종료, 재부팅 또는 복구하는 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html) 
+  [Amazon EC2 Auto Scaling 시작하기](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 