기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 태그 지정 사용 사례
**Topics**
+ [비용 할당 및 재무 관리를 위한 태그](tags-for-cost-allocation-and-financial-management.md)
+ [운영 및 지원을 위한 태그](tags-for-operations-and-support.md)
+ [데이터 보안, 위험 관리 및 액세스 제어를 위한 태그](tags-for-data-security-risk-management-and-access-control.md)
# 비용 할당 및 재무 관리를 위한 태그
조직에서 가장 먼저 다루는 태그 지정 사용 사례 중 하나는 비용 및 사용량에 대한 가시성과 관리입니다. 일반적으로 여기에는 몇 가지 이유가 있습니다.
+ **이는 일반적으로 잘 이해되는 시나리오이며 요구 사항도 잘 알려져 있습니다.** 예를 들어 재무 팀은 여러 서비스, 기능, 계정 또는 팀에 걸친 워크로드 및 인프라의 총 비용을 확인하려고 합니다. 이러한 비용 가시성을 확보하는 한 가지 방법은 리소스에 일관된 태그를 지정하는 것입니다.
+ **태그와 그 값은 명확하게 정의되어 있습니다.** 일반적으로 비용 할당 메커니즘은 조직의 재무 시스템에 이미 존재합니다(예: 비용 센터, 사업부, 팀 또는 조직 기능별 추적).
+ **빠르고 입증 가능한 투자 수익** 리소스에 일관되게 태그가 지정되면 시간 경과에 따른 비용 최적화 추세를 추적할 수 있습니다(예: 적정 규모, 자동 크기 조정 또는 일정에 따른 리소스).
에서 비용이 발생하는 방식을 이해 AWS 하면 정보에 입각한 재무 결정을 내릴 수 있습니다. 리소스, 워크로드, 팀 또는 조직 수준에서 비용이 어디서 발생했는지 알면 달성한 비즈니스 성과와 비교할 때 해당 수준에서 제공되는 가치를 더 잘 이해할 수 있습니다.
엔지니어링 팀은 리소스의 재무 관리 경험이 없을 수도 있습니다. AWS 재무 관리의 기본 사항에 대해 엔지니어링 및 개발 팀을 교육하고 재무와 엔지니어링 간의 관계를 구축하여 FinOps 문화를 조성할 수 있는 AWS 재무 관리 전문 기술을 갖춘 사람을 연결하면 비즈니스에서 측정 가능한 성과를 달성하고 팀이 비용을 염두에 두고 구축하도록 장려하는 데 도움이 됩니다. Well-Architected Framework의 [비용 최적화 요소](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html)는 훌륭한 금융 관행을 수립하는 것에 대해 자세히 다루지만 이 백서에서는 몇 가지 기본 원칙을 다룰 것입니다.
# 비용 할당 태그
비용 할당이란 정의된 프로세스에 따라 발생한 비용을 해당 비용의 사용자 또는 수익자에게 할당하거나 분배하는 것을 말합니다. 이 백서에서는 비용 할당을 *쇼백*과 *차지백*이라는 두 가지 유형으로 구분합니다.
*쇼백* 도구 및 메커니즘은 비용에 대한 인식을 높이는 데 도움이 됩니다. *차지백*은 비용 회수에 도움이 되며 비용 인식을 촉진합니다. *쇼백*은 사업부, 애플리케이션, 사용자 또는 비용 센터와 같은 특정 주체가 부담한 요금을 제시, 계산 및 보고하는 것을 말합니다. 예를 들어 “인프라 엔지니어링 팀은 지난 달에 X달러의 AWS 지출을 담당했습니다.” *차지백*이란 금융 시스템이나 저널 바우처와 같은 조직의 내부 회계 프로세스를 통해 발생한 비용을 해당 엔터티에 실제로 청구하는 것을 말합니다. 예: “인프라 엔지니어링 팀의 AWS 예산에서 \$1X가 공제되었습니다.” 두 경우 모두 리소스에 적절하게 태그를 지정하면 엔터티에 비용을 할당하는 데 도움이 될 수 있습니다. 유일한 차이점은 누군가가 지불할 것으로 예상되는지 여부입니다.
조직의 재무 거버넌스를 위해서는 애플리케이션, 사업부, 비용 센터 및 팀 수준에서 발생하는 비용을 투명하게 계산해야 할 수 있습니다. [비용 할당 태그](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)가 지원하는 비용 분담을 수행하면 적절하게 태그가 지정된 리소스에서 엔터티에서 발생한 비용을 정확하게 귀속시키는 데 필요한 데이터가 제공됩니다.
+ **책임** - 리소스 사용을 책임지는 사람에게 비용이 할당되도록 하세요. 단일 서비스 지점 또는 그룹이 지출 검토 및 보고를 담당할 수 있습니다.
+ **재무 투명성** - 리더십을 위한 효과적인 대시보드와 의미 있는 비용 분석을 만들어 IT에 대한 현금 할당을 명확하게 보여 줍니다.
+ **정보에 입각한 IT 투자** - 프로젝트, 애플리케이션 또는 비즈니스 라인을 기반으로 ROI를 추적하고 팀이 더 나은 비즈니스 결정을 내릴 수 있도록 지원합니다. 예를 들어 수익 창출 애플리케이션에 더 많은 자금을 할당합니다.
요약하면 비용 할당 태그는 다음과 같은 정보를 제공하는 데 도움이 될 수 있습니다.
+ 지출을 담당하고 최적화를 책임지는 사람은 누구입니까?
+ 지출이 발생하는 워크로드, 애플리케이션 또는 제품은 무엇입니까? 어떤 환경 또는 스테이지입니까?
+ 가장 빠르게 성장하고 있는 지출 영역은 어디입니까?
+ 과거 추세에 따라 AWS 예산에서 얼마나 많은 지출을 공제할 수 있습니까?
+ 특정 워크로드, 애플리케이션 또는 제품 내에서 비용 최적화 노력이 미친 영향은 무엇이었습니까?
비용 할당을 위해 리소스 태그를 활성화하면 지출 책임에 대한 투명성을 높이는 AWS 사용량 가시성을 제공하는 데 사용할 수 있는 조직 내 측정 관행을 정의하는 데 도움이 됩니다. 또한 비용 및 사용량 가시성과 관련하여 적절한 수준의 세분성을 확보하고 비용 할당 보고 및 KPI 추적을 통해 클라우드 소비 행동에 영향을 미치는 데 중점을 둡니다.
# 비용 할당 전략 구축
## 비용 할당 모델 정의 및 구현
배포 중인 리소스에 대한 계정 및 비용 구조를 생성합니다 AWS. AWS 지출 비용, 해당 비용이 발생한 방식, 해당 비용이 발생한 사람 또는 대상 간의 관계를 설정합니다. 일반적인 비용 구조는 사업부 또는 워크로드와 같은 조직 내 AWS Organizations AWS 계정, 환경 및 엔터티를 기반으로 합니다. 비용 구조는 여러 속성을 기반으로 하여 비용을 다양한 방식이나 다양한 수준으로 세분화하여 검토할 수 있습니다. 예를 들어 개별 워크로드의 비용을 해당 업무별로 합산할 수 있습니다.
원하는 결과에 맞는 비용 구조를 선택할 때는 *구현의 용이성*과 *원하는 정확성*을 기준으로 비용 할당 메커니즘을 평가합니다. 여기에는 책임, 도구 가용성, 문화적 변화에 대한 고려 사항이 포함될 수 있습니다. AWS 고객이 일반적으로 시작하는 세 가지 인기 있는 비용 할당 모델은 다음과 같습니다.
+ **계정 기반 -**이 모델은 최소한의 노력이 필요하고 쇼백 및 차지백에 대한 높은 정확도를 제공하며, 정의된 계정 구조(및 [여러 계정을 사용하여 AWS 환경 구성](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) 백서의 권장 사항과 일치)가 있는 조직에 적합합니다. 이를 통해 계정별로 비용을 명확하게 파악할 수 있습니다. 비용 가시성 및 할당을 위해 [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html), [Cost & Usage Report](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)와 비용 모니터링 및 추적을 위한 [AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)를 사용할 수 있습니다. 이러한 도구는 필터링 및 그룹화 옵션을 제공합니다 AWS 계정. 비용 할당 관점에서 보면 이 모델은 개별 리소스의 정확한 태그 지정에 의존할 필요가 없습니다.
+ **사업부 또는 팀 기반** - 기업 내 팀, 사업부 또는 조직에 비용을 할당할 수 있습니다. 이 모델은 적당한 노력이 필요하고 쇼백 및 차지백에 대한 높은 정확도를 제공하며 다양한 팀, 애플리케이션 및 워크로드 유형을 구분하여 정의된 계정 구조(일반적으로 AWS Organizations사용)를 가진 조직에 적합합니다. 이를 통해 팀과 애플리케이션 전반의 비용을 명확하게 파악할 수 있으며 추가 혜택으로 단일 AWS 계정내의 [AWS 서비스 할당량](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 한도에 도달할 위험을 줄일 수 있습니다. 예를 들어 각 팀은 5개의 계정(`prod`, `staging`, `test`, `dev`, `sandbox`)을 가질 수 있으며 두 팀과 애플리케이션이 동일한 계정을 공유하지 않을 수 있습니다. 이러한 구조를 통해 [AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html)는 계정 또는 기타 태그(“meta-tagging”)를 범주로 그룹화하는 기능을 제공하며 이 범주는 이전 예제에서 언급한 도구에서 추적할 수 있습니다. 는 계정 및 조직 단위(OUs)의 태그 지정을 AWS Organizations 허용하지만 이러한 태그는 비용 할당 및 결제 보고에는 적용되지 않습니다(즉, OU AWS Cost Explorer 별로 비용을 그룹화하거나 필터링할 수 없음). AWS Cost Categories는이 용도로 사용해야 합니다.
+ **태그 기반** - 이 모델은 이전 두 모델에 비해 더 많은 노력이 필요하며 요구 사항 및 최종 목표에 따라 쇼백 및 차지백에 대한 높은 정확도를 제공합니다. [여러 계정을 사용하여 AWS 환경 구성](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) 백서에 설명된 사례를 채택하는 것이 좋습니다. 하지만 실제로 고객은 마이그레이션하는 데 시간이 걸리는 혼합적이고 복잡한 계정 구조를 발견하는 경우가 많습니다. 이 시나리오에서는 엄격하고 효과적인 태그 지정 전략을 구현한 다음 Billing and Cost Management 콘솔에서 [비용 할당을 위한 관련 태그를 활성화합니다](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)(에서 AWS Organizations태그는 Management Payer 계정에서만 비용 할당을 위해 활성화할 수 있음). 비용 할당을 위해 태그를 활성화한 후에는 이전 방법에서 언급한 비용 파악 및 할당 도구를 쇼백 및 차지백에 사용할 수 있습니다. 비용 할당 태그는 소급 적용되지 않으며 비용 할당을 위해 활성화된 후에만 청구 보고 및 비용 추적 도구에 표시됩니다.
요약하자면, 사업부별로 비용을 추적해야 하는 경우 [AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html)를 사용하여 AWS 조직 내에서 연결된 계정을 적절히 그룹화하고 결제 보고서에서이 그룹화를 볼 수 있습니다. 프로덕션 및 비프로덕션 환경에 대해 별도의 계정을 만드는 경우 [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html) 등과 같은 도구에서 환경과 관련된 비용을 필터링하거나 [AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)를 사용하여 해당 비용을 추적할 수도 있습니다. 마지막으로 예를 들어 개별 워크로드 또는 애플리케이션별로 보다 세부적인 비용 추적이 필요한 사용 사례의 경우 해당 계정 내의 리소스에 적절하게 태그를 지정하고 관리 계정에서 [비용 할당을 위해 해당 태그 키를 활성화](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)한 다음 청구 보고 도구의 태그 키를 기준으로 비용을 필터링할 수 있습니다.
## 비용 보고 및 모니터링 프로세스 수립
먼저 내부 이해관계자에게 중요한 비용 유형(예: 일일 지출, 계정별 비용, X 기준 비용, 상각 비용)을 파악합니다. 이렇게 하면 최종 인 AWS 보이스를 기다리는 것보다 예기치 않거나 비정상적인 지출과 관련된 예산 위험을 더 빠르게 완화할 수 있습니다. 태그는 이러한 보고 시나리오를 가능하게 하는 속성을 제공합니다. 보고를 통해 얻은 인사이트는 변칙적이고 예상치 못한 재정 예산 지출로 인한 영향을 줄이기 위한 조치를 취할 수 있습니다. 비용이 예상치 않게 급증하는 경우 제공되는 가치가 예상치 않게 급증했는지 평가하여 필요한 조치가 필요한지 판단하는 것이 중요합니다.
비용 할당을 지원하기 위한 태그 지정 전략을 개발할 때 다음 사항에 유의하세요.
+ **AWS Organizations** - 여러 계정 내의 비용 할당은 계정, 계정 그룹 또는 해당 계정의 리소스에 대해 생성된 태그 그룹별로 수행할 수 있습니다. 의 개별 계정에 있는 리소스에 대해 생성된 태그는 관리 계정에서만 비용 할당에 사용할 AWS Organizations 수 있습니다.
+ **AWS 계정** - 서비스 또는 리전과 같은 추가 차원을 통해 하나의 내에서 비용 할당을 수행할 AWS 계정 수 있습니다. 계정 내에서 리소스에 추가로 태그를 지정하고 해당 리소스 태그 그룹과 함께 작업할 수 있습니다.
+ **비용 할당 태그** - 필요한 경우 사용자가 만든 태그와 AWS 생성 태그를 모두 비용 할당을 위해 활성화할 수 있습니다. 결제 콘솔(의 관리 계정 AWS Organizations)에서 비용 할당 태그를 활성화하면 쇼백 및 차지백에 도움이 됩니다.
+ **Cost Categories** - AWS Cost Categories는 AWS 조직 내에서 계정 그룹화 및 태그 그룹화(“메타 태그 지정”)를 허용하며, AWS Cost Explorer AWS 예산 및 비용 및 사용 보고서와 같은 도구를 통해 이러한 범주와 관련된 AWS 비용을 분석할 수 있는 기능을 추가로 제공합니다.
## 기업 내 사업부, 팀 또는 조직에 대한 쇼백 및 차지백 수행
비용 구조 및 비용 할당 태그가 지원하는 비용 할당 프로세스를 사용하여 비용을 계산합니다. 태그를 사용하여 비용을 직접 지불할 책임이 없지만 해당 비용이 발생했을 책임이 있는 팀에 쇼백을 제공할 수 있습니다. 이 접근 방식을 통해 지출 기여도와 이러한 비용이 어떻게 발생하는지를 파악할 수 있습니다. 비용을 직접 담당하는 팀에 차지백을 수행하여 해당 팀이 소비한 리소스의 비용을 회수하고 해당 비용과 발생 경위를 파악할 수 있도록 합니다.
## 효율성 또는 가치 KPI 측정 및 순환
일련의 단위 비용 또는 KPI 지표에 합의하여 클라우드 재무 관리 투자의 영향을 측정합니다. 이 실습을 통해 절대적인 총지출에만 초점을 맞춘 이야기가 아니라 기술 및 비즈니스 이해관계자 간에 공통된 언어를 만들고 효율성을 기반으로 한 이야기를 들려줍니다. 자세한 내용은 [단위 메트릭이 비즈니스 기능 간의 조정에 어떻게 도움이 될 수 있는지](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metrics-help-create-alignment-between-business-functions/) 설명하는 이 블로그를 확인하세요.
## 할당할 수 없는 지출 할당
조직의 회계 관행에 따라 청구 유형에 따라 다르게 처리해야 할 수도 있습니다. 태그를 지정할 수 없는 리소스 또는 비용 범주를 식별합니다. 사용하는 서비스와 사용할 예정인 서비스에 따라 할당할 수 없는 이러한 지출을 처리하고 측정하는 방법에 대한 메커니즘에 동의합니다. 예를 들어 및 *AWS Resource Groups 태그 사용 설명서*에서 [AWS Resource Groups 및 Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/supported-resources.html)에서 지원하는 리소스 목록을 확인합니다.
태그를 지정할 수 없는 비용 범주의 일반적인 예로는 예약형 인스턴스(RI) 및 절감형 플랜(SP)과 같은 약정 기반 할인에 대한 일부 수수료가 있습니다. 구독료와 미사용 SP 및 RI 요금을 청구 보고 도구에 표시하기 전에 미리 태그를 지정할 수는 없지만 사후에 AWS Organizations 에서 계정, 리소스 및 태그에 RI와 SP 할인이 어떻게 적용되는지 추적할 수 있습니다. 예를 들어 분할 상환 비용을 AWS Cost Explorer 살펴보고 관련 태그 키를 기준으로 지출하는 그룹을 구성하고 사용 사례와 관련된 필터를 적용할 수 있습니다. AWS CUR(Cost & Usage Report)에서 RI 및 SP 할인이 적용되는 사용량에 해당하는 줄을 필터링하고(자세한 내용은 [CUR 설명서](https://docs.aws.amazon.com/cur/latest/userguide/use-cases.html)의 사용 사례 섹션 참조) 해당 항목에만 해당하는 열을 선택할 수 있습니다. 비용 할당을 위해 활성화된 각 태그 키는 [월별 비용 할당 보고서](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html)와 같은 다른 기존 결제 보고서에 표시되는 방식과 유사하게 CUR 보고서 끝에 별도의 열에 표시됩니다. 추가 참조는 [AWS Well-Architected Labs](https://www.wellarchitectedlabs.com/cost/300_labs/300_cur_queries/)에서 CUR 데이터에서 비용 및 사용량 인사이트를 얻는 예제를 확인하세요.
## 보고
쇼백 및 차지백을 지원하는 AWS 도구 외에도 태그가 지정된 리소스의 비용을 모니터링하고 태그 지정 전략의 효과를 측정하는 데 도움이 되는 다양한 기타 AWS 생성 및 타사 솔루션이 있습니다. 조직의 요구 사항과 최종 목표에 따라 시간과 리소스를 투자하여 맞춤형 솔루션을 구축하거나 [AWS 클라우드 관리 도구 컴피턴시 파트너](https://aws.amazon.com/products/management-tools/partner-solutions/?partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=%2Aall&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-use-case=%2Aall&awsf.partner-solutions-filter-partner-location=%2Aall) 중 한 곳에서 제공하는 도구를 구매할 수 있습니다. 비즈니스와 관련된 제어된 파라미터를 사용하여 고유한 *신뢰할 수 있는 단일 소스* 비용 할당 도구를 생성하기로 결정한 경우 AWS 비용 및 사용 보고서(CUR)는 가장 상세한 비용 및 사용 데이터를 제공하고 사용자 지정 최적화 대시보드를 생성하여 계정, 서비스, 비용 범주, 비용 할당 태그 및 기타 여러 차원별로 필터링 및 그룹화할 수 있습니다. 이러한 도구 중 하나로 사용할 수 AWS 있는에서 개발한 CUR 기반 솔루션 중에서 AWS Well-Architected Labs 웹 사이트에서 [Cloud Intelligence Dashboards](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/)를 확인하세요.
# 운영 및 지원을 위한 태그
AWS 환경에는 운영 요구 사항이 서로 다른 여러 계정, 리소스 및 워크로드가 있습니다. 태그를 사용하여 운영 팀을 지원하는 데 필요한 컨텍스트와 지침을 제공하여 서비스 관리를 개선할 수 있습니다. 또한 태그를 사용하여 관리 리소스의 운영 거버넌스 투명성을 제공할 수 있습니다.
운영 태그의 일관된 정의를 이끄는 몇 가지 주요 요인은 다음과 같습니다.
+ **자동화된 인프라 활동 중에 리소스를 필터링합니다.** 리소스를 배포, 업데이트 또는 삭제하는 경우를 예로 들 수 있습니다. 또 다른 하나는 비용 최적화를 위한 리소스 확장과 근무 시간 외 사용량 감소를 들 수 있습니다. 실제 예제는 [AWS 인스턴스 스케줄러](https://aws.amazon.com/solutions/implementations/instance-scheduler/) 솔루션을 참조하세요.
+ **격리되거나 더 이상 사용되지 않는 리소스 식별** 정의된 수명을 초과했거나 내부 메커니즘에 의해 격리 대상으로 지정된 리소스는 지원 담당자가 조사하는 데 도움이 되도록 적절하게 태그를 지정해야 합니다. 지원 중단된 리소스는 격리, 보관, 삭제 전에 태그를 지정해야 합니다.
+ **리소스 그룹에 대한 지원 요구 사항** 리소스의 지원 요구 사항이 서로 다른 경우가 많습니다. 예를 들어 이러한 요구 사항은 팀 간에 협상하거나 애플리케이션 중요도의 일부로 설정할 수 있습니다. 운영 모델에 대한 추가 지침은 [운영 우수성 요소](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html)에서 확인할 수 있습니다.
+ **인시던트 관리 프로세스를 개선합니다.** 지원 팀과 엔지니어, 주요 인시던트 관리(MIM) 팀은 인시던트 관리 프로세스의 투명성을 높이는 태그로 리소스에 태그를 지정함으로써 이벤트를 보다 효과적으로 관리할 수 있습니다.
+ **백업** 또한 태그를 사용하여 리소스를 백업해야 하는 빈도, 백업 복사본을 이동해야 하는 위치 또는 백업을 복원할 위치를 식별할 수 있습니다. [에 대한 백업 및 복구 접근 방식에 대한 권장 지침 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/welcome.html)입니다.
+ **패치 적용** 에서 실행되는 변경 가능한 인스턴스에 패치를 적용하는 AWS 것은 중요한 패치 전략과 제로데이 취약성의 패치 적용 모두에서 매우 중요합니다. 광범위한 패치 전략에 대한 심층적인 지침은 [규범적 지침](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html)에서 확인할 수 있습니다. 이 [블로그](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/)에서는 제로데이 취약성의 패치에 대해 설명합니다.
+ **운영 관찰성** 운영 KPI 전략을 리소스 태그로 변환하면 운영 팀이 비즈니스 요구 사항을 개선하기 위한 목표 달성 여부를 더 잘 추적할 수 있습니다. KPI 전략을 개발하는 주제는 별개이지만 안정된 상태에서 운영되는 비즈니스 또는 변화의 영향과 결과를 측정할 수 있는 영역에 초점을 맞추는 경향이 있습니다. [KPI 대시보드](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/cost-usage-report-dashboards/dashboards/2c_kpi_dashboard/)(AWS Well-Architected Labs)와 운영 KPI 워크숍([AWS Enterprise Support 선제적 서비스](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/))은 모두 안정적인 상태에서 성능을 측정합니다. AWS 기업 전략 블로그 기사 [변환의 성공 측정](https://aws.amazon.com/blogs/enterprise-strategy/measuring-the-success-of-your-transformation/)에서는 IT 현대화 또는 온프레미스에서 로 마이그레이션과 같은 변환 프로그램에 대한 KPI 측정을 살펴봅니다 AWS.
# 자동화된 인프라 활동
인프라를 관리할 때 다양한 자동화 활동에 태그를 사용할 수 있습니다. 예를 들어 [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/index.html)를 사용하면 사용자가 생성하는 정의된 키-값 쌍으로 지정된 리소스에 대한 자동화 및 런북을 관리할 수 있습니다. 관리형 노드의 경우 운영 체제 및 환경별로 노드를 추적하거나 대상으로 삼는 태그 세트를 정의할 수 있습니다. 그런 다음 그룹의 모든 노드에 대해 업데이트 스크립트를 실행하거나 해당 노드의 상태를 검토할 수 있습니다. 또한 [Systems Manager 리소스에](https://docs.aws.amazon.com/systems-manager/latest/userguide/taggable-resources.html) 태그를 지정하여 자동화된 활동을 더욱 세분화하고 추적할 수 있습니다.
환경 리소스의 시작 및 중지 수명 주기를 자동화하면 모든 조직의 비용을 크게 절감할 수 있습니다. [AWS의 인스턴스 스케줄러](https://aws.amazon.com/solutions/implementations/instance-scheduler/)는 필요하지 않을 때 Amazon EC2 및 Amazon RDS 인스턴스를 시작하고 중지할 수 있는 솔루션의 한 예입니다. 예를 들어 주말에 실행할 필요가 없는 Amazon EC2 또는 Amazon RDS 인스턴스를 사용하는 개발자 환경은 해당 인스턴스의 종료가 제공할 수 있는 비용 절감 잠재력을 활용하지 못하고 있습니다. 팀과 환경의 요구 사항을 분석하고 이러한 리소스에 적절하게 태그를 지정하여 관리를 자동화하면 예산을 효과적으로 활용할 수 있습니다.
*Amazon EC2 인스턴스의 인스턴스 스케줄러가 사용하는 스케줄 태그의 예:*
```
{
"Tags": [
{
"Key": "Schedule",
"ResourceId": "i-1234567890abcdef8",
"ResourceType": "instance",
"Value": "mon-9am-fri-5pm"
}
]
}
```
# 워크로드 수명 주기
**지원 운영 데이터의 정확성을 검토합니다.** 워크로드 수명 주기와 관련된 태그를 정기적으로 검토하고 적절한 이해관계자가 이러한 검토에 참여하는지 확인하세요.
*표 7 – 워크로드 수명 주기의 일부로서 운영 태그 검토*
| 사용 사례 | 태그 키 | 이론적 근거 | 예제 값 |
| --- | --- | --- | --- |
| 계정 소유자 | example-inc:account-owner:owner | 계정 소유자 및 계정에 포함된 리소스 | ops-center, dev-ops, app-team |
| 계정 소유자 검토 | example-inc:account-owner:review | 계정 소유권 세부 정보가 최신 상태이고 정확한지 검토합니다. | <태그 지정 라이브러리에 정의된 올바른 형식의 검토 날짜> |
| 데이터 소유자 | example-inc:data-owner:owner | 데이터가 있는 계정의 데이터 소유자 | bi-team, logistics, security |
| 데이터 소유자 검토 | example-inc:data-owner:review | 데이터 소유권 세부 정보가 최신 상태이고 정확한지 검토합니다. | <태그 지정 라이브러리에 정의된 올바른 형식의 검토 날짜> |
## 일시 중지된 OU로 마이그레이션하기 전에 일시 중지 계정에 태그 할당
[여러 계정을 사용하여 AWS 환경 구성](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) 백서에 설명된 대로 계정을 일시 중지하고 일시 중지된 OU로 이동하기 전에 계정에 태그를 추가하여 계정 수명 주기의 내부 추적 및 감사를 지원해야 합니다. 예를 들어 조직의 ITSM 티켓팅 시스템에 있는 상대 URL 또는 티켓 참조는 일시 중지된 애플리케이션의 감사 추적을 보여 줍니다.
*표 8 - 워크로드 수명 주기가 새로운 단계로 접어들 때 운영 태그 추가*
| 사용 사례 | 태그 키 | 이론적 근거 | 예제 값 |
| --- | --- | --- | --- |
| 계정 소유자 | example-inc:account-owner:owner | 계정 소유자 및 계정에 포함된 리소스 | ops-center, dev-ops, app-team |
| 데이터 소유자 | example-inc:data-owner:owner | 데이터가 있는 계정의 데이터 소유자 | bi-team, logistics, security |
| 일시 중지된 날짜 | example-inc:suspension:date | 계정이 일시 중지된 날짜 | <태그 지정 라이브러리에 정의된 올바른 형식의 일시 중지된 날짜> |
| 일시 중지 승인 | example-inc:suspension:approval | 계정 일시 중지 승인 링크 | workload/deprecation |
# 인시던트 관리
태그는 인시던트 로깅, 우선순위 지정, 조사, 커뮤니케이션, 해결에서 종료에 이르기까지 인시던트 관리의 모든 단계에서 중요한 역할을 할 수 있습니다.
태그에는 인시던트를 로깅해야 하는 위치, 인시던트를 알려야 하는 팀, 정의된 에스컬레이션 우선순위가 상세히 명시될 수 있습니다. 태그는 암호화되지 않는다는 점을 기억해야 합니다. 따라서 태그에 어떤 정보를 저장할지 고려하세요. 또한 조직, 팀, 보고 라인의 책임도 달라지므로 이 정보를 보다 효과적으로 관리할 수 있는 보안 포털로 연결되는 링크를 저장하는 것도 고려하세요. 이러한 태그는 배타적일 필요는 없습니다. 예를 들어 애플리케이션 ID를 사용하여 IT 서비스 관리 포털에서 에스컬레이션 경로를 조회할 수 있습니다. 운영 정의에서 이 태그가 다양한 용도로 사용되고 있다는 점을 분명히 하세요.
운영 요구 사항 태그도 자세히 작성하여 인시던트 관리자와 운영 담당자가 인시던트 또는 이벤트에 대응하여 목표를 더욱 구체화하는 데 도움이 될 수 있습니다.
대응 팀이 해당 프로세스, 절차 및 문서를 식별하는 데 도움이 되도록 [런북](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.runbook.en.html) 및 [플레이북](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.playbook.en.html)의 관련 링크(지식 시스템 기반 URL)를 태그로 포함할 수 있습니다.
*표 9 - 운영 태그를 사용하여 인시던트 관리 정보 제공*
| 사용 사례 | 태그 키 | 이론적 근거 | 예제 값 |
| --- | --- | --- | --- |
| 인시던트 관리 | example-inc:incident-management:escalationlog | 지원 팀이 인시던트를 로깅하는 데 사용하는 시스템 | jira, servicenow, zendesk |
| 인시던트 관리 | example-inc:incident-management:escalationpath | 에스컬레이션 경로 | ops-center, dev-ops, app-team |
| 비용 할당 및 인시던트 관리 | example-inc:cost-allocation:CostCenter | 비용 센터별 비용 모니터링 다음은 비용 센터를 인시던트 로깅을 위한 애플리케이션 코드로 사용하는 이중 용도 태그의 예입니다. | 123-\$1 |
| 백업 일정 | example-inc:backup:schedule | 리소스의 백업 일정 | Daily |
| 플레이북/인시던트 관리 | example-inc:incident-management:playbook | 문서화된 플레이북 | webapp/incident/playbook |
# 패치 적용
조직은 AWS Systems Manager Patch Manager 및 AWS Lambda를 사용하여 변경 가능한 컴퓨팅 환경에 대한 패치 전략을 자동화하고 변경 가능한 인스턴스를 해당 애플리케이션 환경의 정의된 패치 기준선에 맞춰 유지할 수 있습니다. 이러한 환경 내의 변경 가능한 인스턴스에 대한 태그 지정 전략은 해당 인스턴스를 **패치 그룹** 및 **유지 관리 창**에 할당하여 관리할 수 있습니다. 개발 → 테스트 → 제품 분할에 대한 다음 예를 참조하세요. [변경 가능한 인스턴스의 패치 관리](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html)를 위한 AWS 규범적 지침이 제공됩니다.
*표 10 - 운영 태그는 환경에 따라 다를 수 있음*
| 개발 | Staging | 프로덕션 |
| --- | --- | --- |
| {
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab111",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#1 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab222",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab333",
"ResourceType": "instance",
"Value": "WEBAPP-DEV-AL2"
}
]
}
| {
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab444",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#2 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab555",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab666",
"ResourceType": "instance",
"Value": "WEBAPP-TEST-AL2"
}
]
}
| {
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab777",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#3 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab888",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab999",
"ResourceType": "instance",
"Value": "WEBAPP-PROD-AL2"
}
]
}
|
패치 전략을 보완하기 위해 태그를 정의하여 제로데이 취약성을 관리할 수도 있습니다. 자세한 지침은 [AWS Systems Manager를 사용하여 당일 보안 패치로 제로데이 취약성 방지](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/)를 참조하세요.
# 운영 관찰성
환경 성능에 대한 실행 가능한 인사이트를 얻고 문제를 감지하고 조사하는 데 도움이 되려면 관찰성이 필요합니다. 또한 가동 시간과 같은 핵심 성과 지표(KPI)와 서비스 수준 목표(SLO)를 정의하고 측정할 수 있는 보조 목적도 있습니다. 대부분의 조직에서 중요한 운영 KPI는 인시던트로부터의 평균 감지 시간(MTTD)과 평균 복구 시간(MTTR)입니다.
데이터를 수집한 다음 관련 태그를 수집하기 때문에 관찰성 전반에서 컨텍스트가 중요합니다. 초점을 맞추고 있는 서비스, 애플리케이션 또는 애플리케이션 계층에 관계없이 해당 특정 데이터 세트를 필터링하고 분석할 수 있습니다. 태그를 사용하여 CloudWatch 경보에 대한 온보딩을 자동화하여 특정 지표 임계값 위반 시 적절한 팀에 알림을 보낼 수 있습니다. 예를 들어 태그 키 `example-inc:ops:alarm-tag` 및 그 값은 CloudWatch 경보가 생성되었음을 나타낼 수 있습니다. 이를 보여 주는 솔루션은 [태그를 사용하여 Amazon EC2 인스턴스에 대한 Amazon CloudWatch 경보 생성 및 유지 관리](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/)에 설명되어 있습니다.
경보를 너무 많이 구성하면 알림 폭풍이 쉽게 발생할 수 있습니다. 운영자가 개별 경보를 수동으로 분류하고 우선순위를 정하는 과정에서 많은 수의 경보나 알림이 운영자에게 빠르게 부담을 주고 전반적인 효율성을 떨어뜨릴 수 있습니다. 경보에 대한 추가 컨텍스트를 태그 형태로 제공할 수 있습니다. 즉, Amazon EventBridge 내에서 규칙을 정의하여 다운스트림 종속성 대신 업스트림 문제에 초점을 맞출 수 있습니다.
DevOps와 함께 운영의 역할을 간과하는 경우가 많지만 많은 조직에서 중앙 운영팀은 정규 업무 시간 외에도 중요한 첫 대응을 제공합니다. (이 모델에 대한 자세한 내용은 [운영 우수성 백서](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html)에서 확인할 수 있습니다.) 워크로드를 소유한 DevOps 팀과 달리 일반적으로 동일한 깊이의 지식이 없으므로 태그가 대시보드 및 알림 내에서 제공하는 컨텍스트가 문제에 대한 올바른 런북으로 전달하거나 자동화된 런북을 시작할 수 있습니다(블로그 게시물 [Amazon CloudWatch 경보 자동화 AWS Systems Manager](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/) 참조).
# 데이터 보안, 위험 관리 및 액세스 제어를 위한 태그
조직은 데이터 스토리지 및 처리의 적절한 처리와 관련하여 충족해야 할 다양한 요구 사항과 의무를 가지고 있습니다. 데이터 분류는 액세스 제어, 데이터 보존, 데이터 분석 및 규정 준수와 같은 여러 사용 사례의 중요한 선행 요소입니다.
# 데이터 보안 및 위험 관리
AWS 환경 내에서 규정 준수 및 보안 요구 사항이 다른 계정이 있을 수 있습니다. 예를 들어 개발자 샌드박스가 있고 결제 처리와 같이 규제가 엄격한 워크로드를 위한 프로덕션 환경을 호스팅하는 계정이 있을 수 있습니다. 이들을 서로 다른 계정으로 분리하면 [별도의 보안 제어를 적용](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#apply-distinct-security-controls-by-environment)하고 [민감한 데이터에 대한 액세스를 제한](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#constrain-access-to-sensitive-data)하고 규제된 워크로드의 감사 범위를 줄일 수 있습니다.
모든 워크로드에 대해 단일 표준을 채택하면 문제가 발생할 수 있습니다. 많은 제어 항목이 환경 전체에 동일하게 적용되지만 특정 규제 프레임워크를 충족할 필요가 없는 계정 및 개인 식별 데이터가 전혀 없는 계정(예: 개발자 샌드박스 또는 워크로드 개발 계정)에는 일부 제어 항목이 과도하거나 관련이 없습니다. 이로 인해 일반적으로 아무 조치도 취하지 않고 분류하고 종료해야 하는 오탐지 보안 결과가 발생하므로 조사해야 할 결과에 대한 노력이 줄어듭니다.
*표 11 – 데이터 보안 및 위험 관리 태그의 예*
| 사용 사례: | 태그 키 | 이론적 근거 | 예제 값 |
| --- | --- | --- | --- |
| 인시던트 관리 | example-inc:incident- management:escalationlog | 지원 팀이 인시던트를 로깅하는 데 사용하는 시스템 | jira, servicenow, zendesk |
| 인시던트 관리 | example-inc:incident- management:escalationpath | 에스컬레이션 경로 | ops-center, dev-ops, app-team |
| 데이터 분류 | example-inc:data:classification | 규정 준수 및 거버넌스를 위한 데이터 분류 | Public, Private, Confidential, Restricted |
| 규정 준수 | example-inc:compliance:framework | 워크로드에 적용되는 규정 준수 프레임워크 식별 | PCI-DSS, HIPAA |
AWS 환경 전체에서 서로 다른 제어를 수동으로 관리하는 것은 시간이 많이 걸리고 오류가 발생하기 쉽습니다. 다음 단계는 적절한 보안 제어 항목의 배포를 자동화하고 해당 계정의 분류에 따라 리소스 검사를 구성하는 것입니다. 계정과 계정 내 리소스에 태그를 적용하면 제어 항목 배포를 자동화하고 워크로드에 맞게 구성할 수 있습니다.
**예: **
워크로드에는 `Private` 값이 있는 `example-inc:data:classification` 태그가 있는 Amazon S3 버킷이 포함됩니다. 보안 도구 자동화는 Amazon S3 버킷의 퍼블릭 액세스 차단 설정, 버킷 정책 및 버킷 액세스 제어 목록(ACL)을 `s3-bucket-public-read-prohibited`확인하는 AWS Config 규칙를 배포하여 버킷의 구성이 데이터 분류에 적합한지 확인합니다. 버킷 콘텐츠가 분류와 일치하도록 [Amazon Macie를 구성하여 개인 식별 정보(PII)를 확인할 수 있습니다](https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-macie-supports-criteria-based-bucket-selection-sensitive-data-discovery-jobs/). [Amazon Macie를 사용하여 S3 버킷 데이터 분류 검증](https://aws.amazon.com/blogs/architecture/using-amazon-macie-to-validate-s3-bucket-data-classification/) 블로그에서는 이 패턴을 더 자세히 살펴봅니다.
보험 및 의료와 같은 특정 규제 환경에는 필수 데이터 보존 정책이 적용될 수 있습니다. Amazon S3 수명 주기 정책과 함께 태그를 사용한 데이터 보존은 객체 전환 범위를 다른 스토리지 계층으로 지정하는 효과적이고 간단한 방법이 될 수 있습니다. Amazon S3 수명 주기 규칙을 사용하여 필수 보류 기간이 만료된 후 데이터 삭제를 위해 객체를 만료시킬 수도 있습니다. 이 프로세스에 대한 심층 가이드는 [Amazon S3 수명 주기와 함께 객체 태그를 사용하여 데이터 수명 주기 단순화](https://aws.amazon.com/blogs/storage/simplify-your-data-lifecycle-by-using-object-tags-with-amazon-s3-lifecycle/)를 참조하세요.
또한 보안 탐지 결과를 분류하거나 처리할 때 태그를 사용하면 조사자에게 위험을 판단하는 데 도움이 되는 중요한 컨텍스트를 제공하고 해당 팀이 결과를 조사하거나 완화하도록 유도하는 데 도움이 될 수 있습니다.
# 자격 증명 관리 및 액세스 제어에 대한 태그
를 사용하여 AWS 환경 전체에서 액세스 제어를 관리할 때 AWS IAM Identity Center태그는 조정을 위한 여러 패턴을 활성화할 수 있습니다. 적용할 수 있는 위임 패턴은 여러 가지가 있으며 일부는 태그 지정을 기반으로 합니다. 이를 개별적으로 다루고 각각에 대해 자세히 알아볼 수 있는 링크를 제공할 것입니다.
# 개별 리소스에 대한 ABAC
IAM Identity Center 사용자 및 IAM 역할은 태그를 기반으로 작업 및 리소스에 대한 액세스를 정의할 수 있는 속성 기반 액세스 제어(ABAC)를 지원합니다. ABAC를 사용하면 권한 정책을 업데이트해야 할 필요성을 줄이고 회사 디렉터리의 직원 속성을 기반으로 액세스할 수 있습니다. 이미 다중 계정 전략을 사용하고 있는 경우 역할 기반 액세스 제어(RBAC)와 함께 ABAC를 사용하여 동일한 계정을 운영하는 여러 팀이 서로 다른 리소스에 세밀하게 액세스할 수 있도록 할 수 있습니다. 예를 들어 IAM Identity Center 사용자 또는 IAM 역할에는 특정 Amazon EC2 인스턴스에 대한 액세스를 제한하는 조건이 포함될 수 있습니다. 그렇지 않으면 액세스하려면 각 정책에 명시적으로 나열되어야 하는 조건이 있습니다.
ABAC 인증 모델은 태그에 따라 운영 및 리소스에 액세스하므로 의도하지 않은 액세스를 방지하는 가드레일을 제공하는 것이 중요합니다. SCP는 특정 조건에서만 태그 수정을 허용하여 조직 전체에서 태그를 보호하는 데 사용할 수 있습니다. [AWS Organizations에서 서비스 제어 정책을 사용하여 권한 부여에 사용되는 리소스 태그 보호](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/) 및 [IAM 엔터티의 권한 경계](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) 블로그에서는 이를 구현하는 방법에 대한 정보를 제공합니다.
수명이 긴 Amazon EC2 인스턴스를 사용하여 보다 전통적인 운영 방식을 지원하는 경우 이 접근 방식을 활용할 수 있습니다. [Amazon EC2 인스턴스용 IAM Identity Center ABAC 구성 및 Systems Manager Session Manager](https://aws.amazon.com/blogs/security/configure-aws-sso-abac-for-ec2-instances-and-systems-manager-session-manager/) 블로그에서는 이러한 형태의 속성 기반 액세스 제어에 대해 자세히 설명합니다. 앞서 언급했듯이 모든 리소스 유형이 태그 지정을 지원하는 것은 아니며 지원하는 리소스 유형도 모두 태그 정책을 사용한 적용을 지원하는 것은 아니므로 이 전략을 AWS 계정에 구현하기 전에 먼저 이를 평가하는 것이 좋습니다.
ABAC를 지원하는 서비스에 대해 알아보려면 [IAM을 사용하는AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하세요.