# COST 2 사용량을 어떻게 관리합니까?
목표 달성 과정에서 발생하는 비용을 적정 수준으로 유지하는 정책과 메커니즘을 설정합니다. ‘견제와 균형’ 방식을 도입하면 비용을 과도하게 지출하지 않고 혁신을 이룰 수 있습니다.
**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 조직 요구 사항에 따라 정책 개발
조직에서 리소스를 관리하는 방법을 정의하는 정책을 개발합니다. 정책은 리소스 수명 주기 동안의 생성, 수정, 폐기를 포함한 리소스와 워크로드의 비용 측면을 다루어야 합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
비용 및 사용량을 효과적으로 관리하고 비용 절감 기회를 식별하려면 조직의 비용 및 동인을 파악하는 것이 중요합니다. 조직에서는 일반적으로 여러 팀이 운영하는 여러 워크로드를 운영합니다. 이러한 팀은 매출원이 각기 다른 개별 조직 단위 소속일 수 있습니다. 워크로드, 개별 조직 또는 제품 책임자에게 리소스 비용을 귀속하는 기능은 효율적인 사용 행동 양식으로 이어지고 낭비되는 요소를 줄여줍니다. 비용 및 사용량을 정확하게 모니터링하면 각 조직 단위와 제품의 수익성 수준을 이해할 수 있으며, 관련 정보를 근거로 하여 조직 내에서 리소스를 할당할 위치를 더 적절하게 결정할 수 있습니다. 비용은 사용량에 따라 변경되므로 비용 변경을 주도하려면 조직의 모든 수준에서 사용량을 인식하는 것이 필수적입니다. 사용량 및 지출을 적절하게 파악하려면 다각적 방식을 사용하는 것이 좋습니다.
거버넌스를 수행하는 첫 번째 단계는 조직의 요구 사항을 활용하여 클라우드 사용에 대한 정책을 개발하는 것입니다. 이러한 정책은 조직에서 클라우드를 사용하는 방법과 리소스를 관리하는 방법을 정의합니다. 정책에는 리소스 수명 주기 동안의 리소스 생성, 수정, 폐기를 비롯하여 비용 또는 사용량과 관련된 워크로드의 모든 측면이 포함되어야 합니다.
정책은 조직 전체에서 쉽게 이해할 수 있고 효과적으로 구현할 수 있을 만큼 단순해야 합니다. 허용되는 지리적 리전 사용량 또는 리소스가 실행되어야 하는 시간 등 넓은 범위의 상위 수준 정책부터 시작합니다. 그런 다음 다양한 조직 단위 및 워크로드에 대한 정책을 점진적으로 구체화합니다. 일반적인 정책에는 사용할 수 있는 서비스 및 기능(예: 테스트 또는 개발 환경의 저성능 스토리지)과 그룹별로 사용할 수 있는 리소스 유형(예: 개발 계정에서 사용할 수 있는 가장 큰 리소스 크기는 중간 크기)이 포함됩니다.
**구현 단계**
+ **팀원과의 만남: **정책 개발을 위해 조직의 모든 팀원이 요구 사항을 지정하고 적절히 문서화하도록 합니다. 광범위하게 시작하여 반복적인 접근 방식을 취하고 각 단계에서 가장 작은 단위까지 계속 세분화합니다. 팀원에는 조직 단위 또는 애플리케이션 소유자와 같이 워크로드에 직접적인 관심이 있는 멤버뿐만 아니라 보안 및 재무 팀과 같은 지원 그룹이 포함됩니다.
+ ** 워크로드 위치 정의: **국가와 국가 내 지역을 포함한 워크로드의 작동 위치를 정의합니다. 이 정보는 AWS 리전 및 가용 영역에 매핑하는 데 사용됩니다.
+ ** 서비스와 리소스 정의 및 그룹화: **워크로드에 필요한 서비스를 정의합니다. 서비스마다 필요한 리소스 유형, 크기 및 수를 지정합니다. 애플리케이션 서버나 데이터베이스 스토리지와 같은 기능별로 리소스 그룹을 정의합니다. 리소스는 여러 그룹에 속할 수 있습니다.
+ **역할별로 사용자 정의 및 그룹화: **누구인지 또는 조직에서 어떤 직책을 맡고 있는지가 아니라 무슨 일을 하며 워크로드를 어떻게 사용하는지에 초점을 두고, 워크로드와 밀접한 일을 하는 사용자를 정의합니다. 유사한 사용자나 역할을 함께 그룹화합니다. AWS 관리형 정책을 가이드로 사용할 수 있습니다.
+ ** 작업 정의:** 이전에 식별된 위치, 리소스 및 사용자를 사용하여 수명 주기(개발, 운영 및 폐기) 동안 각자 워크로드 성과를 거두는 데 필요한 작업을 정의합니다. 각 위치에서 그룹의 개별 요소가 아니라 그룹을 기반으로 작업을 식별합니다. 읽기 또는 쓰기로 광범위하게 시작한 다음 각 서비스에 대한 특정 작업까지 세분화합니다.
+ ** 검토 기간 정의:** 워크로드와 조직 요구 사항은 시간이 지나면서 바뀔 수 있습니다. 조직의 우선 순위와 일치하도록 워크로드 검토 일정을 정의합니다.
+ **정책 문서화: **정의된 정책에 조직의 필요에 따라 액세스할 수 있는지 확인합니다. 이러한 정책은 환경의 액세스를 구현, 유지 관리 및 감사하는 데 사용됩니다.
## 리소스
**관련 문서:**
+ [직무 역할에 대한 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 목표 및 타겟 이행
워크로드에 대한 비용 및 사용량 목표를 모두 이행합니다. 목표는 조직에 비용 및 사용량에 대한 방향을 제공하고, 타겟은 워크로드에 대한 측정 가능한 결과를 제공합니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
조직의 비용과 사용량에 대한 목표와 타겟을 개발합니다. 목표는 예상 결과에 대한 지침과 방향을 조직에 제공합니다. 타겟은 달성해야 할 구체적이고 측정 가능한 결과를 제공합니다. 예를 들어 목표는 비용을 조금(비선형) 늘리면서 플랫폼 사용량을 크게 늘리는 것입니다. 타겟은 플랫폼 사용량을 20% 늘리고 비용 증가를 5% 미만으로 유지하는 것입니다. 워크로드 효율성을 6개월마다 개선하는 것은 일반적인 목표의 또 다른 예입니다. 여기에 수반되는 타겟은 워크로드의 결과당 비용을 6개월마다 5% 줄이는 것이 될 수 있습니다.
클라우드 워크로드의 일반적인 목표는 워크로드 효율성을 높이고 시간이 지남에 따라 워크로드의 비즈니스 결과당 비용을 줄이는 것입니다. 모든 워크로드에 대해 이 목표를 구현하고 6\$112개월마다 효율성 5% 증가와 같은 목표를 설정하는 것이 좋습니다. 클라우드에서는 비용 최적화 기능의 구축과 새로운 서비스 및 서비스 기능의 릴리스를 통해 이러한 목표를 달성할 수 있습니다.
**구현 단계**
+ **예상 사용량 수준 정의: **먼저 사용량 수준에 초점을 맞추십시오. 애플리케이션 소유자, 마케팅 및 더 큰 비즈니스 팀과 협력하여 워크로드의 예상 사용량 수준을 파악합니다. 시간 경과에 따라 고객 수요는 어떻게 바뀔 것인지, 계절에 따른 증가나 마케팅 캠페인으로 인한 변화가 있을지도 알아봅니다.
+ ** 워크로드 리소싱 및 비용 정의: **사용량 수준을 정의한 후 이러한 사용량 수준을 충족하는 데 필요한 워크로드 리소스의 변경 사항을 수량화합니다. 워크로드 구성 요소의 리소스 크기 또는 수를 늘리거나, 데이터 전송을 늘리거나, 워크로드 구성 요소를 특정 수준의 다른 서비스로 변경해야 할 수 있습니다. 이러한 각 주요 지점에서 비용은 어떻게 될 것이며, 사용량에 변화가 있을 때 비용은 어떻게 바뀔지 지정합니다.
+ **비즈니스 목표 정의: **예상 사용량 및 비용 변화의 결과를 예상되는 기술 변화나 실행 중인 모든 프로그램과 결합하고 워크로드에 대한 목표를 개발합니다. 목표가 사용량, 비용 및 이 둘의 관계를 충족해야 합니다. 사용량 변화 없이 비용 변화만 예상되는 경우 훈련 및 교육 등의 기능 구축과 같은 조직 프로그램이 있는지 확인합니다.
+ **타겟 정의: **정의된 각 목표에 대해 측정 가능한 타겟을 지정합니다. 워크로드의 효율성을 높이는 것이 목표라면 타겟은 소비한 달러당 비즈니스 성과의 개선량과 제공 시점을 수량화합니다.
## 리소스
**관련 문서:**
+ [직무 역할에 대한 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 계정 구조 구현
조직에 적합한 계정 구조를 구현합니다. 이를 통해 조직 전체에서 비용을 쉽게 할당하고 관리할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
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와 별도의 청구서가 필요한 경우 여러 관리 또는 지급인 계정을 정의합니다. 이 경우 멤버 계정마다 고유의 관리 또는 지급인 계정이 있습니다. 리소스는 항상 멤버 또는 연결 계정에 배치되어야 합니다. 관리 또는 지급인 계정은 관리에만 사용해야 합니다.
## 리소스
**관련 문서:**
+ [직무 역할에 대한 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 그룹 및 역할 만들기
정책에 따라 그룹과 역할을 만들고 각 그룹에서 인스턴스와 리소스를 생성, 수정 또는 폐기할 수 있는 사용자를 제어합니다. 예를 들어 개발, 테스트 및 프로덕션 그룹을 만듭니다. 이는 AWS 서비스와 타사 솔루션에 적용됩니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
정책을 개발한 후에는 조직 내부 사용자의 논리적 그룹 및 역할을 생성하여 권한을 할당하고 사용량을 제어할 수 있습니다. 개괄적인 수준에서 사람을 그룹화하는 것으로 시작합니다. 일반적으로 조직 단위 및 직무 역할(예: IT 부서의 시스템 관리자 또는 재무 관리자)이 여기에 해당합니다. 그룹에는 유사한 작업을 수행하고 유사한 접근 권한이 필요한 사람이 포함됩니다. 역할은 그룹이 수행해야 할 작업을 정의합니다. 예를 들어 IT의 시스템 관리자는 모든 리소스를 생성할 수 있는 접근 권한이 필요하지만 분석 팀원은 분석 리소스만 생성하면 됩니다.
**구현 단계**
+ ** 그룹 만들기: **조직 정책에 정의된 사용자 그룹을 사용하여 필요한 경우 해당 그룹을 만듭니다. 사용자, 그룹 및 인증에 대한 모범 사례는 보안 원칙을 참조하십시오.
+ ** 역할 및 정책 만들기: **조직 정책에 정의된 작업을 사용하여 필요한 역할과 액세스 정책을 생성합니다. 역할 및 정책에 대한 모범 사례는 보안 원칙을 참조하십시오.
## 리소스
**관련 문서:**
+ [직무에 관한 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 비용 제어 기능 구현
조직 정책과 정의된 그룹 및 역할을 기준으로 제어 기능을 만듭니다. 이렇게 하면 조직 요구 사항에 따라 정의된 비용만 발생합니다. 예를 들어 AWS Identity and Access Management(IAM) 정책을 사용하여 리전 또는 리소스 유형 액세스를 제어할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
비용 제어를 구현하기 위한 일반적인 첫 번째 단계는 비용 또는 사용량 이벤트가 조직 정책 범위를 벗어날 때 알림을 설정하는 것입니다. 이렇게 하면 워크로드 또는 새로운 활동에 대한 제한 또는 부정적인 영향 없이 신속하게 조치를 취하고 교정 조치가 필요한지 여부를 확인할 수 있습니다. 워크로드 및 환경 제한을 파악한 후에는 거버넌스를 시행할 수 있습니다. 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 정책에 여러 조직 정책이 포함될 수 있습니다. 정책을 정의한 것과 동일한 방식으로 광범위하게 시작한 다음 각 단계에서 보다 세분화된 제어를 적용합니다. 서비스 한도도 효과적인 사용량 제어 방식입니다. 모든 계정에 올바른 서비스 한도를 설정합니다.
## 리소스
**관련 문서:**
+ [직무에 관한 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 프로젝트 수명 주기 추적
프로젝트, 팀 및 환경의 수명 주기를 추적, 측정 및 감사하여 불필요한 리소스 사용 및 이에 따른 비용 지출을 막으십시오.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
워크로드의 전체 수명 주기를 추적해야 합니다. 수명 주기를 추적하면 워크로드 또는 워크로드 구성 요소가 더 이상 필요하지 않을 때 이를 폐기하거나 수정할 수 있습니다. 이 기능은 새로운 서비스 또는 기능을 릴리스할 때 특히 유용합니다. 사용 중인 것처럼 보일 수 있는 기존 워크로드 및 구성 요소를 폐기하여 고객을 새 서비스로 리디렉션해야 합니다. 워크로드의 이전 단계를 확인하십시오. 워크로드가 프로덕션 단계로 전환된 후에는 이전 환경을 폐기하거나 다시 필요할 때까지 용량을 크게 줄일 수 있습니다.
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) 를 참조하십시오.
**구현 단계**
+ ** 워크로드 검토 수행: **조직 정책에 정의된 대로 기존 프로젝트를 감사합니다. 감사에 드는 노력은 조직의 대략적인 위험, 가치 또는 비용에 비례해야 합니다. 감사에 포함할 주요 영역은 조직의 인시던트 또는 가동 중단 위험, 가치 또는 조직에 대한 기여도(수익 또는 브랜드 평판으로 측정), 워크로드 비용(총 리소스 비용 및 운영 비용으로 측정), 워크로드 사용량(단위 시간당 조직 성과 수로 측정)입니다. 수명 주기 동안 이러한 영역이 변경되면 전체 또는 부분 폐기와 같은 워크로드 조정이 필요합니다.
## 리소스
**관련 문서:**
+ [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/)