# 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 조직 요구 사항에 따라 정책 개발
조직에서 리소스를 관리하는 방법을 정의하는 정책을 개발하고 정기적으로 검사합니다. 정책에서는 리소스 수명 주기 동안의 생성, 수정, 폐기를 포함한 리소스 및 워크로드의 비용 측면을 다루어야 합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
비용 및 사용량을 효과적으로 관리하고 비용 절감 기회를 파악하려면 조직의 비용 및 동인을 파악하는 것이 중요합니다. 조직에서는 일반적으로 여러 팀이 운영하는 여러 워크로드를 운영합니다. 이러한 팀은 매출원이 각기 다른 개별 조직 단위 소속일 수 있습니다. 워크로드, 개별 조직 또는 제품 책임자에게 리소스 비용을 귀속하는 기능은 효율적인 사용 행동으로 이어지고 낭비되는 요소를 줄여줍니다. 정확한 비용 및 사용량 모니터링을 통해 워크로드가 얼마나 최적화되었는지, 조직 단위 및 제품의 수익성이 어느 정도인지 이해할 수 있습니다. 이를 통해 조직 내에서 리소스를 할당할 위치에 대해 더 많은 정보를 활용하여 의사 결정을 내릴 수 있습니다. 비용은 사용량에 따라 변경되므로 비용 변경을 주도하려면 조직의 모든 수준에서 사용량을 인식하는 것이 필수적입니다. 사용량 및 지출을 적절하게 파악하려면 다각적 방식을 사용하는 것이 좋습니다.
거버넌스를 수행하는 첫 번째 단계는 조직의 요구 사항을 활용하여 클라우드 사용에 대한 정책을 개발하는 것입니다. 이러한 정책은 조직에서 클라우드를 사용하는 방법과 리소스를 관리하는 방법을 정의합니다. 정책에서는 리소스 수명 주기 동안의 생성, 수정, 폐기를 비롯하여 비용 또는 사용량과 관련된 워크로드의 모든 측면을 다루어야 합니다. 정책과 절차를 준수하고 클라우드 환경의 모든 변화에 대비하여 구현되었는지 확인합니다. IT 변경 관리 회의에서 계획된 변경 사항의 비용 영향, 즉 증가 및 감소 여부, 비즈니스 타당성, 예상 결과에 대해 질문합니다.
정책은 조직 전체에서 쉽게 이해할 수 있고 효과적으로 구현할 수 있을 만큼 단순해야 합니다. 또한 정책은 준수 및 해석하기 쉬워야 하고(그래야 정책이 사용될 수 있음) 구체적이어야 합니다(그래야 팀 간에 오해가 없음). 또한 당사의 메커니즘과 같이 정기적으로 점검하고 고객의 비즈니스 상황 또는 우선순위가 바뀌면 정책이 상황에 맞지 않을 수 있으므로 업데이트해야 합니다.
사용할 지리적 리전, 리소스를 실행해야 하는 하루 중 시간 등과 같이 넓은 범위의 상위 수준 정책부터 시작합니다. 그런 다음 다양한 조직 단위 및 워크로드에 대한 정책을 점진적으로 구체화합니다. 가장 많이 사용하는 정책에는 사용할 수 있는 서비스와 기능(예: 테스트 및 개발 환경의 비교적 성능이 낮은 스토리지), 각 그룹에서 사용할 수 있는 리소스 유형(예: 개발 계정에서 사용할 수 있는 가장 큰 리소스 크기는 중간 규모), 리소스 사용 시간(임시, 단기 또는 특정 기간)이 있습니다.
**정책 예제**
다음은 비용 최적화에 중점을 둔 자체 클라우드 거버넌스 정책을 작성하기 위해 검토할 수 있는 샘플 정책입니다. 조직의 요구 사항과 이해관계자의 요청에 따라 정책을 조정해야 합니다.
+ **정책 이름:** 리소스 최적화 및 비용 절감 정책과 같은 명확한 정책 이름을 정의합니다.
+ **목적:** 이 정책을 사용해야 하는 이유와 예상되는 결과를 설명합니다. 이 정책의 목적은 비즈니스 요구 사항을 충족하기 위해 원하는 워크로드를 배포하고 실행하는 데 필요한 최소 비용이 있는지 확인하는 것입니다.
+ **범위:** 이 정책을 누가 언제 사용해야 하는지 명확하게 정의합니다. 예를 들어 DevOps X Team은 X 환경(프로덕션 또는 비프로덕션)에서 미국 동부 고객에게 이 정책을 사용해야 합니다.
**정책 문**
1. 워크로드의 환경 및 비즈니스 요구 사항(개발, 사용자 승인 테스트, 사전 프로덕션 또는 프로덕션)에 따라 us-east-1 또는 여러 개의 미국 동부 리전을 선택합니다.
1. 오전 6시\$1오후 8시(동부 표준시(EST)) 사이에 실행되도록 Amazon EC2 및 Amazon RDS 인스턴스를 예약합니다.
1. 8시간 동안 활동이 없으면 사용하지 않는 모든 Amazon EC2 인스턴스를 중지하고 24시간 동안 활동이 없으면 사용하지 않는 Amazon RDS 인스턴스를 중지합니다.
1. 비프로덕션 환경에서는 24시간 동안 활동이 없으면 사용하지 않는 모든 Amazon EC2 인스턴스를 종료합니다. Amazon EC2 인스턴스 소유자(태그 기준)에게 프로덕션 환경에서 중지된 Amazon EC2 인스턴스를 검토하도록 요청하고 사용하지 않을 경우 72시간 이내에 해당 Amazon EC2 인스턴스가 종료될 것임을 알립니다.
1. 일반 인스턴스 패밀리 및 크기(예: m5.large)를 사용한 다음 AWS Compute Optimizer를 사용하여 CPU 및 메모리 사용률에 따라 인스턴스 크기를 조정합니다.
1. Auto Scaling을 사용하여 우선순위를 지정해 트래픽에 따라 실행 중인 인스턴스 수를 동적으로 조정합니다.
1. 중요하지 않은 워크로드에는 스팟 인스턴스를 사용합니다.
1. 용량 요구 사항을 검토하여 예측 가능한 워크로드를 위한 절감형 플랜 또는 예약형 인스턴스를 약정하고 클라우드 재무 관리 팀에 알립니다.
1. Amazon S3 수명 주기 정책을 사용하여 자주 액세스하지 않는 데이터를 저렴한 스토리지 계층으로 이동합니다. 보존 정책이 정의되지 않은 경우 Amazon S3 Intelligent Tiering을 사용하여 객체를 자동으로 아카이브 계층으로 이동합니다.
1. Amazon CloudWatch를 사용하여 리소스 사용률을 모니터링하고 경보를 설정하여 규모 조정 이벤트를 트리거합니다.
1. 각 AWS 계정에 대해 AWS Budgets를 사용하여 비용 센터 및 사업부를 기준으로 계정의 비용 및 사용 예산을 설정합니다.
1. 계정의 비용 및 사용 예산을 설정하는 데 AWS Budgets를 사용하면 지출을 확실히 파악하고 예상치 못한 청구서를 피할 수 있으므로 비용을 더 잘 관리할 수 있습니다.
**절차:** 이 정책을 구현하기 위한 세부 절차를 제공하거나 각 정책 문을 구현하는 방법을 설명하는 다른 문서를 소개합니다. 이 섹션에서는 정책 요구 사항을 수행하기 위한 단계별 지침을 제공해야 합니다.
이 정책을 구현하려면 다양한 서드파티 도구 또는 AWS Config 규칙을 사용하여 정책 문 준수 여부를 확인하고 AWS Lambda 함수를 사용하여 자동화된 수정 작업을 트리거할 수 있습니다. AWS Organizations를 사용하여 정책을 적용할 수도 있습니다. 또한 정기적으로 리소스 사용량을 검토하고 필요에 따라 정책을 조정하여 비즈니스 요구 사항을 계속 충족하는지 확인해야 합니다.
## 구현 단계
+ **이해관계자와 만남:** 정책을 개발하려면 조직 내 이해관계자(클라우드 비즈니스 오피스, 엔지니어 또는 정책 시행을 위한 기능적 의사 결정권자)에게 요구 사항을 지정하고 문서화하도록 요청합니다. 광범위하게 시작하여 반복적인 접근 방식을 취하고 각 단계에서 가장 작은 단위까지 계속 세분화합니다. 팀원에는 조직 단위 또는 애플리케이션 소유자와 같이 워크로드에 직접적인 관심이 있는 구성원뿐만 아니라 보안 및 재무 팀과 같은 지원 그룹이 포함됩니다.
+ **확인 받기:** 각 팀이 AWS 클라우드에 액세스하고 배포할 수 있는 정책에 동의하는지 확인합니다. 각 팀이 조직 정책을 준수하고, 리소스 생성이 합의된 정책 및 절차에 적합한지 확인합니다.
+ **온보딩 교육 세션 생성:** 새로운 조직 구성원에게 온보딩 교육 과정을 이수하도록 하여 비용과 조직 요구 사항에 대해 인식하도록 합니다. 이전의 경험과 정책이 다를 것으로 가정하거나, 전혀 생각하고 있지 않을 수 있습니다.
+ ** 워크로드 위치 정의:** 국가, 국가 내 지역을 포함하여 워크로드가 운영되는 곳을 정의합니다. 이 정보는 AWS 리전 및 가용 영역에 매핑하는 데 사용됩니다.
+ ** 서비스와 리소스 정의 및 그룹화:** 워크로드에 필요한 서비스를 정의합니다. 서비스마다 필요한 리소스 유형, 크기 및 수를 지정합니다. 애플리케이션 서버나 데이터베이스 스토리지와 같은 기능별로 리소스 그룹을 정의합니다. 리소스는 여러 그룹에 속할 수 있습니다.
+ **기능별 사용자 정의 및 그룹화:** 누구인지 또는 조직에서 어떤 직책을 맡고 있는지가 아니라 무슨 일을 하며 워크로드를 어떻게 사용하는지에 초점을 두고 워크로드와 밀접한 일을 하는 사용자를 정의합니다. 유사한 사용자나 역할을 함께 그룹화합니다. AWS 관리형 정책을 가이드로 사용할 수 있습니다.
+ ** 작업 정의:** 이전에 식별된 위치, 리소스 및 사용자를 사용하여 수명 주기(개발, 운영 및 폐기) 동안 각자 워크로드 성과를 거두는 데 필요한 작업을 정의합니다. 각 위치에서 그룹의 개별 요소가 아니라 그룹을 기반으로 작업을 식별합니다. 읽기 또는 쓰기로 광범위하게 시작한 다음 각 서비스에 대한 특정 작업까지 세분화합니다.
+ **검토 기간 정의:** 워크로드 및 조직 요구 사항은 시간이 지남에 따라 변경될 수 있습니다. 조직의 우선순위와 일치하도록 워크로드 검토 일정을 정의합니다.
+ **정책 문서화:** 정의된 정책에 조직의 필요에 따라 액세스할 수 있는지 확인합니다. 이러한 정책은 환경의 액세스를 구현, 유지 관리 및 감사하는 데 사용됩니다.
## 리소스
**관련 문서:**
+ [Change Management in the Cloud](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-cloud.html)
+ [직무 기능에 대한 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/)
+ [Actions, Resources, and Condition Keys for AWS Services](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html)
+ [AWS의 관리 및 거버넌스](https://aws.amazon.com/products/management-and-governance/)
+ [Control access to AWS 리전 using IAM policies](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/)
**관련 비디오:**
+ [AWS Management and Governance at Scale](https://www.youtube.com/watch?v=xdJSUnPcPPI)
# COST02-BP02 목표 및 타겟 이행
워크로드에 대한 비용 및 사용량 목표와 타겟을 모두 이행합니다. 목표는 예상 결과에 대한 조직의 방향성을 제공하고, 타겟은 워크로드에 대해 달성할 수 있는 구체적인 측정 가능한 결과를 제공합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
조직의 비용과 사용량에 대한 목표와 타겟을 설정합니다. AWS에서 성장하는 조직으로서 비용 최적화를 위한 목표를 설정하고 추적하는 것이 중요합니다. 이러한 목표 또는 [핵심 성과 지표(KPI)](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metric-the-touchstone-of-your-it-planning-and-evaluation/)에는 온디맨드 지출 비율이나 AWS Graviton 인스턴스 또는 gp3 EBS 볼륨 유형과 같은 최적화된 특정 서비스의 채택 등이 포함될 수 있습니다. 측정 가능하고 달성 가능한 목표를 설정하여 비즈니스 운영에 중요한 효율성 개선을 측정할 수 있습니다. 목표를 통해 조직은 원하는 성과를 달성하는데 필요한 지침을 얻고 나아갈 방향을 알 수 있습니다.
타겟을 통해 달성해야 할 구체적이고 측정 가능한 결과를 파악할 수 있습니다. 간단히 말해 목표는 나아가고자 하는 방향이고 타겟은 그 방향과의 거리와 목표 달성 시점에 해당합니다(구체성, 측정 가능성, 할당성, 현실성, 적시성(SMART) 지침 활용). 예를 들어, 목표는 비용은 조금(비선형) 늘리면서 플랫폼 사용량은 크게 늘리는 것입니다. 타겟은 플랫폼 사용량을 20% 늘리고 비용 증가를 5% 미만으로 유지하는 것입니다. 워크로드 효율성을 6개월마다 개선하는 것은 일반적인 목표의 또 다른 예입니다. 이에 따른 타겟은 비즈니스당 비용 지표를 6개월마다 5%씩 줄이는 것이 될 수 있습니다. 올바른 지표를 사용하고 조직에 대해 계산된 KPI를 설정하세요. 기본 KPI로 시작하여 나중에 비즈니스 요구 사항에 따라 발전시켜 나갈 수 있습니다.
비용 최적화의 목표는 워크로드 효율성을 높이는 것이며, 이는 즉 시간이 지남에 따라 워크로드의 비즈니스 결과당 비용을 줄이는 것입니다. 이 목표를 모든 워크로드에 적용하고 6개월에서 1년마다 효율성을 5% 높이는 것과 같은 타겟을 설정하세요. 클라우드에서는 비용 최적화 기능과 새로운 서비스 및 기능 릴리스를 통해 이를 달성할 수 있습니다.
타겟은 목표 달성을 위해 도달하고자 하는 정량화할 수 있는 벤치마크이며, 벤치마크는 실제 결과를 타겟과 비교합니다. KPI로 컴퓨팅 서비스(예: 스팟 채택, Graviton 채택, 최신 인스턴스 유형, 온디맨드 적용 범위), 스토리지 서비스(예: EBS GP3 채택, 오래된 EBS 스냅샷, Amazon S3 Standard 스토리지) 또는 데이터베이스 서비스 사용(예: RDS 오픈 소스 엔진, Graviton 채택, 온디맨드 적용 범위)의 단위당 비용에 대한 벤치마크를 설정합니다. 이러한 벤치마크와 KPI는 가장 비용 효과적인 방식으로 AWS 서비스를 사용하고 있는지 확인하는 데 도움이 될 수 있습니다.
다음 표에는 참조용 표준 AWS 지표 목록이 나와 있습니다. 각 조직은 이러한 KPI에 대해 서로 다른 타겟 값을 가질 수 있습니다.
| 범주 | KPI(%) | 설명 |
| --- | --- | --- |
| 컴퓨팅 | EC2 사용 범위 | EC2 인스턴스의 전체 비용(또는 시간)을 기준으로 SP\$1RI\$1스팟을 사용하는 EC2 인스턴스 비용(또는 시간) 비교 |
| 컴퓨팅 | 컴퓨팅 SP/RI 사용률 | 총 가용 SP 또는 RI 시간을 기준으로 SP 또는 RI 사용 시간 비교 |
| 컴퓨팅 | EC2/시간당 비용 | EC2 비용을 해당 시간에 실행 중인 EC2 인스턴스 수로 나눈 값 |
| 컴퓨팅 | vCPU 비용 | 모든 인스턴스의 vCPU당 비용 |
| 컴퓨팅 | 최신 인스턴스 세대 | Graviton(또는 기타 최신 세대 인스턴스 유형)의 인스턴스 비율 |
| 데이터베이스 | RDS 적용 범위 | RDS 인스턴스의 총 비용(또는 시간)을 기준으로 RI를 사용한 RDS 인스턴스 비용(또는 시간) 비교 |
| 데이터베이스 | RDS 사용률 | 총 가용 RI 시간을 기준으로 RI 사용 시간 비교 |
| 데이터베이스 | RDS 가동 시간 | RDS 비용을 해당 시간에 실행 중인 RDS 인스턴스 수로 나눈 값 |
| 데이터베이스 | 최신 인스턴스 세대 | Graviton(또는 기타 최신 인스턴스 유형)의 인스턴스 비율 |
| 스토리지 | 스토리지 사용률 | 최적화된 스토리지 비용(예: Glacier, Deep Archive 또는 Infrequent Access)을 총 스토리지 비용으로 나눈 값 |
| 태그 지정 | 태그가 지정되지 않은 리소스 | Cost Explorer: 1. 크레딧, 할인, 세금, 환불, 마켓플레이스를 필터링하고 최근 월별 비용을 복사합니다. 2. Cost Explorer에서 **태그 없는 리소스만 표시**를 선택합니다. 3. **태그 없는 리소스**의 양을 월별 비용으로 나눕니다. |
이 표를 사용하여 조직의 목표를 기반으로 계산해야 하는 타겟 값 또는 벤치마크 값을 포함합니다. 정확하고 현실적인 KPI를 정의하려면 비즈니스에 대한 특정 지표를 측정하고 해당 워크로드의 비즈니스 성과를 이해해야 합니다. 조직 내에서 성과 지표를 평가할 때는 각기 다른 용도에 맞는 여러 유형의 지표를 구별해야 합니다. 이러한 지표는 전반적인 비즈니스 영향을 직접 측정하기보다는 주로 기술 인프라의 성능과 효율성을 측정합니다. 예를 들어 서버 응답 시간, 네트워크 지연 시간 또는 시스템 가동 시간을 추적할 수 있습니다. 이러한 지표는 인프라가 조직의 기술 운영을 얼마나 잘 지원하는지 평가하는 데 중요합니다. 그러나 고객 만족, 수익 성장 또는 시장 점유율과 같은 광범위한 비즈니스 목표에 대한 직접적인 인사이트를 제공하지는 않습니다. 비즈니스 성과를 포괄적으로 이해하려면 이러한 효율성 지표를 비즈니스 성과와 직접 연관되는 전략적 비즈니스 지표로 보완하세요.
KPI 및 관련 비용 절감 기회를 거의 실시간으로 파악하고 시간 경과에 따른 진행 상황을 추적합니다. KPI 목표 정의 및 추적을 시작하려면 [Cloud Intelligence Dashboards](https://wellarchitectedlabs.com/cloud-intelligence-dashboards/)(CID)의 KPI 대시보드를 권장합니다. 비용 및 사용량 보고서(CUR)의 데이터를 기반으로 KPI 대시보드는 맞춤형 목표를 설정하고 시간 경과에 따른 진행 상황을 추적할 수 있는 일련의 권장 비용 최적화 KPI를 제공합니다.
KPI 목표를 설정하고 추적할 수 있는 다른 솔루션이 있다면 조직의 모든 클라우드 재무 관리 이해관계자가 이러한 방법을 채택하도록 해야 합니다.
### 구현 단계
+ **예상 사용량 수준 정의:** 먼저 사용량 수준에 초점을 맞춥니다. 애플리케이션 소유자, 마케팅 팀, 규모가 큰 비즈니스 팀과 협력하여 워크로드의 예상 사용량 수준을 파악합니다. 시간이 지남에 따라 고객 수요는 어떻게 변화할 수 있으며 시즌성 증가 또는 마케팅 캠페인으로 인해 어떤 변화가 있을 수 있나요?
+ **워크로드 리소싱 및 비용 정의:** 사용량 수준을 정의한 후 이러한 사용량 수준을 충족하는 데 필요한 워크로드 리소스의 변경 사항을 수량화합니다. 워크로드 구성 요소의 리소스 크기 또는 수를 늘리거나, 데이터 전송을 늘리거나, 워크로드 구성 요소를 특정 수준의 다른 서비스로 변경해야 할 수 있습니다. 각 주요 지점의 비용을 지정하고 사용량이 변경될 때 비용 변동을 예측합니다.
+ **비즈니스 목표 정의:** 예상 사용량과 비용 변화의 결과를 예상되는 기술 변화나 실행 중인 모든 프로그램과 결합하고 워크로드에 대한 목표를 설정합니다. 목표는 사용량과 비용 그리고 둘 사이의 관계를 다루어야 합니다. 목표는 간단하고 간략하며, 기업에서 어떤 결과를 원하는지 이해하는 데 도움이 되어야 합니다(예: 미사용 리소스는 특정 비용 수준 미만으로 유지). 각각의 사용하지 않은 리소스 유형에 대해 목표를 정의하거나 목표와 타겟에 손실을 초래하는 비용을 정의할 필요는 없습니다. 사용량 변화 없이 비용 변화만 예상되는 경우, 조직 프로그램(예: 훈련 및 교육을 통한 역량 쌓기)이 있는지 확인합니다.
+ **타겟 정의:** 정의된 각 목표에 대해 측정 가능한 타겟을 지정합니다. 워크로드의 효율성을 높이는 것이 목표라면, 타겟은 개선 수치(일반적으로 소비한 USD당 비즈니스 성과)와 달성 시점을 정량화합니다. 예를 들어, 과다 공급으로 인한 낭비를 최소화하겠다는 목표를 설정할 수 있습니다. 이 목표에서는 프로덕션 워크로드의 첫 번째 계층에서 컴퓨팅 오버프로비저닝으로 인한 낭비가 계층 컴퓨팅 비용의 10%를 초과하지 않도록 하는 것을 타겟으로 삼을 수 있습니다. 또한 두 번째 타겟은 프로덕션 워크로드의 두 번째 계층에서 컴퓨팅 오버프로비저닝으로 인한 낭비가 계층 컴퓨팅 비용의 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/)
+ [Control access to AWS 리전 using IAM policies](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [S.M.A.R.T. Goals](https://en.wikipedia.org/wiki/SMART_criteria)
+ [How to track your cost optimization KPIs with the CID KPI Dashboard](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
**관련 비디오:**
+ [Well-Architected Labs: Goals and Targets (Level 100)](https://catalog.workshops.aws/well-architected-cost-optimization/en-US/2-expenditure-and-usage-awareness/150-goals-and-targets)
**관련 예제:**
+ [What is a unit metric](https://aws.amazon.com/blogs/aws-cloud-financial-management/what-is-a-unit-metric/)?
+ [Selecting a unit metric to support your business](https://aws.amazon.com/blogs/aws-cost-management/selecting-a-unit-metric-to-support-your-business/)
+ [Unit metrics in practice – lessons learned](https://aws.amazon.com/blogs/aws-cost-management/unit-metrics-in-practice-lessons-learned/)
+ [How unit metrics help create alignment between business functions](https://aws.amazon.com/blogs/aws-cost-management/unit-metrics-help-create-alignment-between-business-functions/)
# COST02-BP03 계정 구조 구현
조직에 적합한 계정 구조를 구현합니다. 이를 통해 조직 전체에서 비용을 쉽게 할당하고 관리할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
AWS Organizations를 사용하여 다수의 AWS 계정을 생성할 수 있으며, 이를 통해 AWS 기반 워크로드가 확장함에 따라 환경을 중앙에서 통제할 수 있습니다. 조직 단위(OU) 구조로 AWS 계정을 그룹화하고 각 OU에 다수의 AWS 계정을 생성하여 조직 계층 구조를 모델링할 수 있습니다. 계정 구조를 생성하려면 어떤 AWS 계정이 관리 계정인지 먼저 결정해야 합니다. 그런 다음 [관리 계정 모범 사례](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html) 및 [구성원 계정 모범 사례](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html)를 따라 설계된 계정 구조를 기반으로 새 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 계정의 결제를 하나의 관리 계정에 통합할 수 있으며, 각 연결 계정의 활동은 계속 확인할 수 있습니다. 관리 계정에 비용 및 사용량이 집계되므로 서비스 대량 구매 할인율을 극대화하고 약정 할인(절감형 플랜 및 예약형 인스턴스)을 최대한 활용하여 가장 높은 할인을 받을 수 있습니다.
다음 다이어그램은 조직 단위(OU)로 AWS Organizations를 사용하여 다양한 계정을 그룹화하고 각 OU에 다양한 AWS 계정을 배치하는 방법을 보여줍니다. 계정 구성을 위한 패턴을 제공하는 다양한 사용 사례 및 워크로드에는 OU를 사용하는 것이 좋습니다.
![\[조직 단위에 여러 계정을 그룹화하는 방법을 보여주는 트리 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/images/aws-organizations-ou-grouping.png)
[AWS Control Tower](https://aws.amazon.com/controltower/)를 사용하면 여러 AWS 계정을 빠르게 설정하고 구성하여 조직의 요구 사항에 부합하는 거버넌스를 시행할 수 있습니다.
**구현 단계**
+ **분리 요구 사항 정의:** 분리 요구 사항은 보안, 신뢰성, 재무 구조와 같은 여러 요인을 결합한 것입니다. 각 요인을 순서대로 살펴보고 워크로드 또는 워크로드 환경이 다른 워크로드와 분리되어야 하는지 여부를 지정합니다. 보안은 액세스 및 데이터 요구 사항에 대한 준수를 촉진합니다. 신뢰성은 한도를 관리하여 환경과 워크로드가 다른 요인에 영향을 미치지 않도록 합니다. Well-Architected 프레임워크의 보안과 신뢰성 원칙을 정기적으로 검토하고 제공된 모범 사례를 따릅니다. 재무 구조는 재무를 엄격하게 분리합니다(각기 다른 비용 센터, 워크로드 소유권 및 책임). 분리의 일반적인 예로는 별도의 계정에서 실행 중인 프로덕션 및 테스트 워크로드 또는 인보이스 및 결제 데이터를 계정을 소유한 조직의 개별 사업부나 부서 또는 이해관계자에 제공하기 위한 별도의 계정을 사용하는 등이 있습니다.
+ **그룹화 요구 사항 정의:** 그룹화 요구 사항은 분리 요구 사항에 우선하지 않지만 관리를 지원하는 데 사용됩니다. 분리할 필요가 없는 유사한 환경 또는 워크로드를 함께 그룹화합니다. 예를 들어, 하나 이상의 워크로드에 속하는 여러 테스트 또는 개발 환경을 함께 그룹화합니다.
+ **계정 구조 정의:** 이러한 분리와 그룹화를 사용하여 각 그룹에 대한 계정을 지정하고 분리 요구 사항을 유지 관리합니다. 이러한 계정은 구성원 또는 연결된 계정입니다. 이러한 구성원 계정을 하나의 관리 또는 지급인 계정으로 그룹화하면 사용량이 결합되어 모든 계정에서 더 큰 대량 구매 할인을 받을 수 있고 모든 계정에 대해 단일 청구서가 제공됩니다. 결제 데이터를 분리하고 각 구성원 계정에 결제 데이터의 개별 보기를 제공할 수 있습니다. 구성원 계정의 사용 내역 또는 결제 데이터가 다른 계정에 표시되지 않아야 하거나 AWS와 별도의 청구서가 필요한 경우 여러 관리 또는 지급인 계정을 정의합니다. 이 경우 구성원 계정마다 고유의 관리 또는 지급인 계정이 있습니다. 리소스는 항상 구성원 또는 연결 계정에 배치되어야 합니다. 관리 또는 지급인 계정은 관리에만 사용해야 합니다.
## 리소스
**관련 문서:**
+ [비용 할당 태그 사용](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)
+ [직무에 관한 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/)
+ [Control access to AWS 리전 using IAM policies](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/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html) 및 [구성원 계정](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html)의 모범 사례
+ [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [Turning on shared reserved instances and Savings Plans discounts](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-on-process.html)
+ [Consolidated billing](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html)
+ [Consolidated billing](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html)
**관련 예제:**
+ [Splitting the CUR and Sharing Access](https://wellarchitectedlabs.com/Cost/Cost_and_Usage_Analysis/300_Splitting_Sharing_CUR_Access/README.html)
**관련 비디오:**
+ [ Introducing AWS Organizations](https://www.youtube.com/watch?v=T4NK8fv8YdI)
+ [ Set Up a Multi-Account AWS Environment that Uses Best Practices for AWS Organizations](https://www.youtube.com/watch?v=uOrq8ZUuaAQ)
**관련 예제:**
+ [Defining an AWS Multi-Account Strategy for telecommunications companies](https://aws.amazon.com/blogs/industries/defining-an-aws-multi-account-strategy-for-telecommunications-companies/)
+ [Best Practices for Optimizing AWS 계정](https://aws.amazon.com/blogs/architecture/new-whitepaper-provides-best-practices-for-optimizing-aws-accounts/)
+ [Best Practices for Organizational Units with AWS Organizations](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/?org_product_gs_bp_OUBlog)
# COST02-BP04 그룹 및 역할 구현
정책에 따라 그룹과 역할을 구현하고 각 그룹에서 인스턴스와 리소스를 생성, 수정 또는 폐기할 수 있는 사용자를 제어합니다. 예를 들어 개발, 테스트 및 프로덕션 그룹을 구현합니다. 이는 AWS 서비스와 서드파티 솔루션에 적용됩니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 지침
사용자 역할 및 그룹은 안전하고 효율적인 시스템을 설계하고 구현하는 데 필요한 기본 구성 요소입니다. 역할 및 그룹은 조직이 통제의 필요성과 유연성 및 생산성에 대한 요구 사항의 균형을 맞추어 궁극적으로 조직의 목표를 달성하고 사용자 요구를 충족하는 데 도움이 됩니다. AWS Well-Architected Framework 보안 원칙의 [ID 및 액세스 관리](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html) 섹션에서 권장하는 바와 같이, 올바른 조건에서 올바른 사용자에게 올바른 리소스에 대한 액세스를 제공하려면 강력한 ID 관리 및 권한이 필요합니다. 사용자는 작업을 완료하는 데 필요한 액세스 권한만 받습니다. 이렇게 하면 무단 액세스 또는 오용과 관련된 위험을 최소화할 수 있습니다.
정책을 개발한 후에는 조직 내에서 논리적 그룹과 사용자 역할을 만들 수 있습니다. 이를 통해 권한을 할당하고, 사용을 제어하며, 강력한 액세스 제어 메커니즘을 구현하여 민감한 정보에 대한 무단 액세스를 방지할 수 있습니다. 개괄적인 수준에서 사람을 그룹화하는 작업부터 시작합니다. 일반적으로 이렇게 구성되는 그룹은 조직 단위 및 직무 역할(예: IT 부서의 시스템 관리자 또는 재무 관리자, 비즈니스 분석가)과 일치합니다. 유사한 작업을 수행하고 유사한 접근 권한이 필요한 사람이 각각의 그룹으로 분류됩니다. 역할은 그룹이 수행해야 할 작업을 정의합니다. 개별 사용자보다 그룹 및 역할에 대한 권한을 관리하는 것이 더 쉽습니다. 역할과 그룹을 사용하면 모든 사용자에게 일관되고 체계적으로 권한을 할당하여 오류와 불일치를 예방할 수 있습니다.
사용자의 역할이 변경되었을 때, 관리자는 개별 사용자 계정을 재구성하는 대신 역할 또는 그룹 수준에서 액세스를 조정할 수 있습니다. 예를 들어 IT의 시스템 관리자는 모든 리소스를 생성할 수 있는 접근 권한이 필요하지만 분석 팀원은 분석 리소스만 생성하면 됩니다.
### 구현 단계
+ ** 그룹 구현:** 조직 정책에 정의된 사용자 그룹을 사용하여 필요한 경우 해당 그룹을 만듭니다. 사용자, 그룹 및 인증에 대한 모범 사례는 AWS Well-Architected 프레임워크의 [보안 원칙](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)을 참조하세요.
+ ** 역할 및 정책 구현:** 조직 정책에 정의된 작업을 사용하여 필요한 역할과 액세스 정책을 생성합니다. 역할 및 정책에 대한 모범 사례는 AWS Well-Architected Framework의 [보안 원칙](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)을 참조하세요.
## 리소스
**관련 문서:**
+ [직무에 관한 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 Well-Architected Framework 보안 원칙](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)
+ [AWS Identity and Access Management (IAM) ](https://aws.amazon.com/iam/)
+ [AWS Identity and Access Management 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)
**관련 비디오:**
+ [ Why use Identity and Access Management ](https://www.youtube.com/watch?v=SXSqhTn2DuE)
**관련 예제:**
+ [Control access to AWS 리전 using IAM policies](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [ Starting your Cloud Financial Management journey: Cloud cost operations ](https://aws.amazon.com/blogs/aws-cloud-financial-management/op-starting-your-cloud-financial-management-journey/)
# COST02-BP05 비용 제어 기능 구현
조직 정책 및 정의된 그룹과 역할을 기준으로 제어 기능을 구현합니다. 이렇게 하면 조직 요구 사항에 따라 정의된 비용만 발생합니다. 예를 들어 리전 또는 리소스 유형 액세스를 제어할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
비용 제어를 구현하기 위한 일반적인 첫 번째 단계는 비용 또는 사용량 이벤트가 정책 범위를 벗어날 때 알림을 설정하는 것입니다. 워크로드 또는 새로운 활동에 대한 제한 또는 부정적인 영향 없이 신속하게 조치를 취하고 교정 조치가 필요한지 여부를 확인할 수 있습니다. 워크로드 및 환경 제한을 파악한 후에는 거버넌스를 시행할 수 있습니다. [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)를 사용하면 AWS 비용, 사용량 및 약정 할인(절감형 플랜 및 예약형 인스턴스)에 대한 알림을 설정하고 월간 예산을 정의할 수 있습니다. 집계 비용 수준(예: 모든 비용)에서 예산을 생성하거나 연결 계정, 서비스, 태그 또는 가용 영역과 같은 특정 차원만 포함하는 보다 세분화된 수준에서 예산을 생성할 수 있습니다.
AWS Budgets를 통해 예산 한도를 설정한 후 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)을 사용하여 예상치 못한 비용을 줄일 수 있습니다. AWS Cost Anomaly Detection은 기계 학습을 사용하여 비용과 사용량을 지속적으로 모니터링함으로써 비정상적인 지출을 탐지하는 비용 관리 서비스입니다. 이를 통해 비정상적인 지출과 근본 원인을 식별하여 빠르게 조치를 취할 수 있습니다. 먼저 AWS Cost Anomaly Detection에서 비용 모니터링을 생성한 후 달러 임곗값을 설정하여 알림 기본 설정을 선택합니다(예: 1,000 USD 이상의 영향이 있는 이상을 알림). 알림을 수신하고 나면 이상과 비용의 영향에 대한 근본 원인을 분석할 수 있습니다. 또한 AWS Cost Explorer에서 자체적인 이상 분석을 모니터링 및 수행할 수도 있습니다.
[AWS Identity and Access Management](https://aws.amazon.com/iam/) 및 [AWS Organizations 서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html)을 통해 AWS에서 거버넌스 정책을 시행합니다. 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)를 참조하세요.
[AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)의 관리를 통해 거버넌스를 구현할 수도 있습니다. 오버헤드를 최소화하는 방식으로 서비스 할당량을 설정하고 정확하게 유지 관리하면 조직의 요구 사항에 포함되지 않는 리소스 생성을 최소화할 수 있습니다. 이렇게 하려면 요구 사항 변경 속도와 진행 중인 프로젝트(리소스 생성 및 폐기)를 파악하고 할당량 변경을 구현할 수 있는 속도를 고려해야 합니다. 필요한 경우 [Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)를 사용하여 할당량을 늘릴 수 있습니다.
**구현 단계**
+ ** 지출에 대한 알림 구현:** 정의된 조직 정책으로 [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)를 생성하여 지출이 정책을 벗어날 때 이를 알립니다. 전체 계정 지출에 대해 알리는 비용 예산을 계정당 하나씩 여러 개 구성합니다. 각 계정 내에서 해당 계정 내의 더 작은 단위에 대한 추가 비용 예산을 구성합니다. 이러한 단위는 계정 구조에 따라 다릅니다. 일반적인 예로 AWS 리전, 워크로드(태그 사용) 또는 AWS 서비스가 있습니다. 개인의 이메일 계정이 아닌 이메일 배포 목록을 알림에 대한 수신자로 구성합니다. 금액을 초과할 때에 대한 실제 예산을 구성하거나 예상 예산을 사용하여 예상 사용량에 대해 알릴 수 있습니다. 또한 특정 IAM 또는 SCP 정책을 시행하거나, 대상 Amazon EC2 또는 Amazon RDS 인스턴스를 중지할 수 있는 AWS 예산 작업을 사전 구성할 수 있습니다. 예산 작업은 자동으로 시작하거나 워크플로 승인이 필요할 수 있습니다.
+ **비정상적인 지출에 대한 알림 구현:** [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)을 사용하여 조직 내 뜻밖의 비용을 줄이고 비정상적인 지출 가능성의 근본 원인을 분석할 수 있습니다. 비용 모니터링을 생성하여 지정된 세분화에서 비정상적인 지출을 식별하고 AWS Cost Anomaly Detection에서 알림을 구성하면, 비정상적인 지출이 감지되었을 때 알림이 전송됩니다. 이를 통해 이상의 근본 원인을 분석하고 비용에 대한 영향을 이해할 수 있습니다. AWS Cost Categories를 사용하는 동시에 AWS Cost Anomaly Detection을 구성하여 어떤 프로젝트 팀이나 사업부에서 예상치 못한 비용의 근본 원인을 분석하고, 시기 적절하며 필요한 조치를 취할지 식별할 수 있습니다.
+ ** 사용량에 대한 제어 구현:** 정의된 조직 정책으로 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/)
+ [Control access to AWS 리전 using IAM policies](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)
+ [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)
+ [AWS 비용 관리](https://aws.amazon.com/getting-started/hands-on/control-your-costs-free-tier-budgets/)
**관련 비디오:**
+ [How can I use AWS Budgets to track my spending and usage](https://www.youtube.com/watch?v=Ris23gKc7s0)
**관련 예제:**
+ [IAM 액세스 관리 정책 예](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html)
+ [Example service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
+ [AWS 예산 작업](https://aws.amazon.com/blogs/aws-cloud-financial-management/get-started-with-aws-budgets-actions/)
+ [태그로 EC2 리소스 액세스를 제어하는 IAM 정책 생성](https://aws.amazon.com/premiumsupport/knowledge-center/iam-ec2-resource-tags/)
+ [특정 Amazon EC2 리소스에 대한 IAM Identity 액세스 제한](https://aws.amazon.com/premiumsupport/knowledge-center/restrict-ec2-iam/)
+ [채팅 애플리케이션 내 Amazon Q Developer를 사용한 비용 이상 탐지를 위한 Slack 통합](https://aws.amazon.com/aws-cost-management/resources/slack-integrations-for-aws-cost-anomaly-detection-using-aws-chatbot/)
# COST02-BP06 프로젝트 수명 주기 추적
프로젝트, 팀 및 환경의 수명 주기를 추적, 측정 및 감사하여 불필요한 리소스 사용 및 이에 따른 비용 지출을 막으세요.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
조직은 프로젝트 수명 주기를 효과적으로 추적함으로써 향상된 계획, 관리 및 리소스 최적화를 통해 더 나은 비용 관리를 실현할 수 있습니다. 추적을 통해 얻은 인사이트는 비용 효과성과 프로젝트의 전반적인 성공에 기여하는 정보 기반 의사 결정에 매우 중요합니다.
워크로드의 전체 수명 주기를 추적하면 워크로드 또는 워크로드 구성 요소가 더 이상 필요하지 않은 시기를 파악할 수 있습니다. 기존 워크로드와 구성 요소가 사용 중인 것처럼 보일 수 있지만 AWS에서 새 서비스나 기능이 출시되면 폐기되거나 채택될 수 있습니다. 워크로드의 이전 단계를 확인합니다. 워크로드가 프로덕션 단계로 전환된 후에는 이전 환경을 폐기하거나 다시 필요할 때까지 환경의 용량을 크게 줄일 수 있습니다.
리소스에 타임프레임 또는 알림을 태그하여 워크로드가 검토된 시간을 지정할 수 있습니다. 예를 들어 개발 환경을 몇 달 전에 마지막으로 검토했다면 다시 검토하여 새로운 서비스를 채택할 수 있는지 또는 환경이 사용 중인지 알아보는 것이 좋습니다. AWS의 [myApplications](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/aws-myApplications.html)를 사용하여 애플리케이션을 그룹화하고 태그를 지정하여 중요도, 환경, 최근 검토 날짜, 비용 센터와 같은 메타데이터를 관리하고 추적할 수 있습니다. 워크로드의 수명 주기를 추적하고 애플리케이션의 비용, 상태, 보안 태세 및 성능을 모니터링하고 관리할 수 있습니다.
AWS는 엔터티 수명 주기 추적에 사용할 수 있는 다양한 관리 및 거버넌스 서비스를 제공합니다. [https://aws.amazon.com/config/](https://aws.amazon.com/config/) 또는 [https://aws.amazon.com/systems-manager/](https://aws.amazon.com/systems-manager/)를 사용하여 AWS 리소스 및 구성에 대한 상세한 인벤토리를 제공할 수 있습니다. 추적 기능을 기존 프로젝트 또는 자산 관리 시스템에 통합하여 조직 내의 진행 중인 프로젝트와 제품을 추적하는 것이 좋습니다. AWS에서 제공하는 다양한 이벤트 및 지표와 현재 시스템을 통합하면 중요한 수명 주기 이벤트 보기를 만들고 리소스를 사전에 관리하여 불필요한 비용을 줄일 수 있습니다.
[애플리케이션 수명 주기 관리(ALM)](https://aws.amazon.com/what-is/application-lifecycle-management/)와 마찬가지로 프로젝트 수명 주기 추적에는 설계 및 개발, 테스트, 프로덕션, 지원, 워크로드 이중화 등 여러 프로세스, 도구 및 팀이 함께 작업해야 합니다.
프로젝트 수명 주기의 각 단계를 주의 깊게 모니터링함으로써 중요한 인사이트를 얻고 통제를 강화하여 성공적인 프로젝트 계획, 구현 및 완료를 촉진합니다. 이렇게 세심한 감독을 거치면 프로젝트가 품질 표준을 충족할 뿐만 아니라 제시간에 예산 범위 내에서 납품되어 전반적인 비용 효율성을 높인다는 것을 확인할 수 있습니다.
엔터티 수명 주기 추적에 대한 자세한 내용은 [https://aws.amazon.com/architecture/well-architected/](https://aws.amazon.com/architecture/well-architected/)를 참조하세요.
### 구현 단계
+ **프로젝트 수명 주기 모니터링 프로세스 수립:** [Cloud Center of Excellence 팀](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_cloud_financial_management_function.html)은 프로젝트 수명 주기 모니터링 프로세스를 수립해야 합니다. 프로젝트의 통제, 가시성 및 성과를 개선하기 위해 워크로드 모니터링에 대한 구조적이고 체계적인 접근 방식을 수립합니다. 모니터링 프로세스를 투명하고 협력적이며 지속적인 개선에 집중하도록 만들어 효과와 가치를 극대화합니다.
+ **워크로드 검토 수행:** 조직 정책에 정의된 대로 일정한 주기를 설정하여 기존 프로젝트를 감사하고 워크로드 검토를 수행합니다. 감사에 드는 노력은 조직의 대략적인 위험, 가치 또는 비용에 비례해야 합니다. 감사에 포함할 주요 영역은 조직의 인시던트 또는 가동 중단 위험, 가치 또는 조직에 대한 기여도(수익 또는 브랜드 평판으로 측정), 워크로드 비용(총 리소스 비용 및 운영 비용으로 측정), 워크로드 사용량(단위 시간당 조직 성과 수로 측정)입니다. 수명 주기 동안 이러한 영역이 변경되면 전체 또는 부분 폐기와 같은 워크로드 조정이 필요합니다.
## 리소스
**관련 문서:**
+ [Guidance for Tagging on AWS](https://aws.amazon.com/solutions/guidance/tagging-on-aws/)
+ [애플리케이션 수명 주기 관리(ALM)란 무엇인가요?](https://aws.amazon.com/what-is/application-lifecycle-management/)
+ [직무에 관한 AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)
**관련 예제:**
+ [Control access to AWS 리전 using IAM policies](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
**관련 도구**
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/?c=mg&sec=srv)